A design engineer has legitimate access to a manufacturer’s prototype files. The engineer opens the files on a managed workstation, saves a copy in a personal cloud account and shares a link with a former colleague. The company’s disks are encrypted, its web connections use TLS and the employee signed a confidentiality agreement. None of those facts, by itself, stopped the information leaving an approved business boundary.
This is the central distinction in CompTIA Security+ SY0-701 objective 3.3: protecting data means understanding what the information is, which uses are permitted, where copies move and what control operates at each stage. Classification, encryption, access restriction, data loss prevention and disposal have different jobs. A useful architecture joins them into a data-handling system rather than treating them as competing product names.
Start with the information and its business owner
“Confidential” is meaningful only when the organization defines who may read the material, what sharing is allowed and what should happen when its purpose ends. A prototype formula might be a trade secret; an employee bank account is sensitive financial information; a clinical record may have additional regulated restrictions. A public product specification may require integrity and availability even when confidentiality is not the primary concern.
The data owner is accountable for the classification and permitted business use. Technical custodians implement storage, access, backups and monitoring, but should not invent the policy because it is convenient for a platform. A classification exercise should consider the consequences of unauthorized disclosure, modification or loss, the intended recipients, existing contracts and any applicable legal obligations. Organizations may choose labels such as Public, Internal, Confidential or Restricted, but those names are not universal regulatory definitions.
Data discovery needs to look beyond the primary database. An exported report, development copy, downloaded attachment, automated analytics feed, cached object or backup may contain the same information. If the inventory knows only the original location, a correct access policy at that location can coexist with uncontrolled copies elsewhere.
Protect data according to its actual state and activity
Information at rest is stored in devices, objects, databases, archives and backups. Encryption at rest can limit disclosure when storage media is lost or accessed outside its approved key boundary. It does not prevent an overprivileged application from reading data after legitimate decryption. Storage permissions, key custody, classification and retention therefore remain important.
Information in transit crosses a network or service connection. Appropriate transport encryption and endpoint authentication can protect its confidentiality and integrity against interception. Yet TLS may securely deliver data to an unauthorized destination: a protected connection is not a decision that the recipient was entitled to receive the file.
Information in use is being processed, displayed, queried or transformed. Here, resource authorization, memory and endpoint protection, least-privilege processing, output controls and user behavior matter. A database connection may be encrypted and still allow a user to export far more records than their role should access. Different safeguards apply because the failure mechanism is different.
| Business activity | What can fail | Control that changes the risk |
|---|---|---|
| Store confidential engineering designs | Lost drive or unintended backup reader recovers source files. | Appropriate at-rest encryption, key protection, storage entitlement and copy inventory. |
| Send records to an approved processor | Traffic is intercepted or sent to an unapproved identity or region. | Authenticated transport, recipient validation and approved processing policy. |
| Work with designs on an endpoint | An authorized reader exports them to unmanaged cloud storage. | Least-privilege access plus endpoint/cloud DLP and enforced sharing restrictions. |
| Produce a report with personal fields | Reports reveal identifiers unrelated to the intended task. | Purpose-limited extraction, masking or tokenization where appropriate, and output review. |
| Retire a project | Snapshots, archives and third-party copies remain accessible. | Approved retention, disposal, credential closure and verification of derived copies. |
Worked case: stopping a confidential design from leaving the company
Consider the prototype engineer again. The application correctly allows design engineers to download an approved drawing for work. The files carry a Restricted classification and company policy permits transfers only to an approved manufacturer. An employee attempts to upload a drawing to a personal cloud workspace; a separate engineer tries to email an Internal-status meeting note to a private address for permitted remote reading.
Define what the policy is really protecting. The first transfer threatens disclosure of a trade secret to an unapproved destination. The second may be lower risk or may still violate a general no-personal-storage policy. The organization should not assume that all external destinations are forbidden for every class, nor that a trusted employee can send Restricted material anywhere. The data owner defines the permitted recipient and the reason.
Choose an enforcing path. An endpoint DLP rule can inspect or use labels on the file and consider the transfer medium, user, destination and business context. A suitable cloud control can apply rules to uploads or storage in supported applications. Email DLP can assess protected attachments and recipients. No one sensor necessarily covers all three channels: deployment mode, encrypted traffic visibility, endpoint capability and approved exception handling determine the effective coverage.
Design a denied test, not just an alert. Try an authorized test document bearing the Restricted label from an ordinary engineer account to the personal destination. Verify that the attempted transfer is blocked or handled as policy requires and that an appropriate protected event is generated. Then test an approved manufacturer transfer and a legitimate low-sensitivity document to check that the policy does not unnecessarily stop the business.
Investigate actual bypass paths. If clipboard copying, printing, screenshots, an unmanaged browser or a different cloud client remain permitted, the organization’s protection may be incomplete. The decision is not simply to buy another DLP product; it is to understand which authorized workflows and outputs must be governed, what can be inspected and where residual risk needs owner acceptance.
Close the case with evidence. Record the effective rule, label, tested source/destination and the result of both allowed and denied operations. If an employee already transferred the data, handle the potential disclosure through the incident process: identify the recipient, restrict access where possible and evaluate contractual or reporting obligations. A blocked future upload does not erase an earlier copy.
CISA’s Continuous Diagnostics and Mitigation technical capabilities distinguish discovery/classification, data protection, data loss prevention and information rights management. The practical value of that separation is that each capability must address a different failure path; an encryption deployment should not be reported as proof that uncontrolled sharing has been stopped.
Encryption, tokenization, masking and hashing are not substitutes
Encryption transforms readable information into ciphertext under a key. It can protect confidentiality in transit or at rest, but applications with decryption access still need authorization and monitoring. The most important operational questions often concern key access, rotation, backup and which component can obtain plaintext.
Tokenization substitutes a value that maps back to a protected original through a controlled token service or vault. A payment workflow may retain tokens instead of raw account numbers where the architecture and rules support it. A compromised token may still have value within the system that accepts it; tokenization is not the same as deleting the protected information or eliminating every access requirement.
Masking obscures selected values from a particular use or view, such as showing only a few digits in a support interface. The full value may still exist in another controlled system, so masking must be integrated with role rights and source-data protection. A screenshot showing masked fields does not prove that an API response or export cannot expose the underlying data.
Hashing produces a one-way digest useful in appropriate contexts for integrity checks or carefully designed credential storage. It does not allow ordinary authorized decryption of the original value. Storing passwords securely also depends on suitable purpose-built password hashing, salts and parameters, not applying a general-purpose checksum once and declaring the result safe.
Rights management can enforce restrictions on supported protected documents or content types after distribution. It can complement DLP when a recipient is authorized to receive a file but should not be allowed to perform every possible action with it. Actual platform compatibility and legitimate recovery paths need to be tested.
Classification must follow copies and derived information
A confidential file can become several datasets: an analytics extract, an email attachment, a support ticket, a machine-learning sample, or a report aggregating many customer details. Transformation is not automatically declassification. Sometimes aggregation reduces identifying detail; sometimes combining harmless-looking columns makes a person or trade secret easier to identify.
A useful data map records where content originates, where it goes, who is responsible at each stage and why that processing occurs. It also records whether the receiving service is permitted to access the data and how long derived copies should remain. This provides the evidence needed for access reviews, breach investigations and final disposal rather than forcing each team to reconstruct flows after an incident.
Location and data sovereignty questions belong here too. A region approved for the main database may not be approved for a backup, log exporter, external processor or application telemetry store. Encrypted transport does not automatically make a restricted cross-region transfer lawful or contractually permitted. Identify the relevant obligations before selecting deployment locations and check the actual data paths.
Retention, deletion and disposal complete the protection plan
Reducing unneeded data can be more effective than building another layer around a permanent archive. Define the purpose and the retention rule with the appropriate business and legal owners; apply it to primary and derived copies; identify lawful preservation exceptions and verify the actual lifecycle. An automatic deletion job that misses historical exports is only a partial implementation.
At retirement, distinguish logical deletion, access revocation, backup lifecycle and appropriate sanitization of media. A cloud resource being removed from a dashboard is not evidence every snapshot or recovery copy disappeared. For physical storage and device handoff, see the separate CompTIA Security+ SY0-701 asset inventory and secure disposal guide, which deals with custody and media disposition rather than classification and permitted data use.
A compliance or incident preservation hold can require retaining a limited set of records beyond ordinary schedules. That exception should have an owner, justified scope and end condition. Deleting everything immediately may destroy necessary evidence, while holding every copy forever can create a different privacy or confidentiality problem.
How to test this objective without memorizing a product list
Build an authorized mock workspace containing a public product brochure, an internal staff note and a Restricted design file. Write classification and sharing rules for each. Define one permitted read, one disallowed export and a documented exception path. Explain which security control would enforce each decision at rest, in transit and in use.
Next, introduce a complication: the restricted file has a backup, the collaboration tool moves processing to another country, or a departing contractor still owns a shared link. The best answer changes because the state and location of data changed. Your analysis should identify the asset owner, permitted recipient, control that genuinely blocks the unwanted path and evidence of enforcement.
Practice those distinctions using the existing CompTIA Security+ SY0-701 data-protection practice test. Once you can explain why encryption alone does not stop an improper export, the CompTIA Security+ SY0-701 exam-preparation resources provide a natural next step across the other security architecture and operations objectives.
The decisive question is not whether the company purchased encryption, DLP or a classification tool. It is whether sensitive information can move only through approved uses, and whether the company can demonstrate that boundary across every meaningful copy and processing stage.
