CompTIA Security+ SY0-801 Data Protection: States, Classifications, Methods and Roles

Data type describes how data is organized; data state describes what is happening to it right now. The two are independent: a database row is structured data whether it sits on disk, crosses the network or is loaded into memory, and each combination needs a different control.

Structured and unstructured data

Structured data lives in fixed fields with a defined schema, such as relational database tables and well-formed spreadsheets. Because every value sits in a known column, controls can target it precisely: column-level encryption, field masking, per-column permissions. Unstructured data has no field layout: word-processing files, PDF contracts, slide decks, chat transcripts, photographs, voicemail and video. Sensitive details can sit anywhere inside free text, audio or pixels, so controls that work by naming a column have nothing to point at. Unstructured data is protected with file-level encryption, content-inspecting discovery and DLP, labeling and handling rules instead. Between the two sits semi-structured data such as JSON, XML or log records, which carries tags or keys but no fixed table schema; content with no tags or keys at all is unstructured.

Data at rest, in transit and in use

Two behaviours decide most scenarios. First, full-disk encryption is transparent while the system is running: it protects against someone who removes a powered-off drive, but once the system has booted and unlocked the volume, every account and process with permission to open a file reads plaintext. Disk encryption is not an access control. Second, protecting one state does not protect the others. However well data is encrypted on disk and on the wire, it is decrypted in memory to be processed, so an attacker who can read memory there (RAM scraping, memory dumps) sees plaintext. Only isolated processing addresses that state: a secure enclave or confidential-computing environment keeps the data's memory encrypted and walled off from other code, including the operating system. Protections designed to stop an attack from starting are a different job from keeping data confidential while it is being processed.

A data classification is a label for how much harm the organization suffers if data is disclosed, altered or lost, and it sets how the data must be handled. The objective lists two families of labels.

Government levels (ranked by damage)

Top secret is the highest of the three and confidential the lowest. Each level is defined by its damage threshold, so a description of the expected damage is enough to place data at a level. (Unclassified is used for government information that does not meet any of these thresholds.)

Commercial labels

• Public: meant for anyone, such as brochures, press releases and published web content. Disclosure causes no harm.
• Sensitive: data that needs protection beyond ordinary internal use. In common Security+ teaching the label is applied to regulated personal data (PII), health information (PHI) and intellectual property. Some organizations instead use it for a lower internal tier, such as internal procedures.
• Confidential: data limited to those with a business need, such as customer records or contracts; disclosure causes real harm.
• Restricted: the most tightly controlled tier in many schemes, limited to named people or roles, such as merger plans or cardholder data.
• Critical: data the organization cannot operate without. The concern is availability and integrity, not secrecy.

Organizations name and rank their own commercial tiers, so treat any ordering of sensitive, confidential and restricted as a typical scheme rather than a fixed standard. The distinction to hold onto is critical versus the disclosure tiers: public, sensitive, confidential and restricted describe who may see data; critical describes what happens when it is lost or corrupted. The two can diverge. A retailer's product catalog is published on its website, so it is public, yet if the copy the ordering system runs on were deleted or tampered with, sales would stop. Data can be harmless to disclose and still critical.

Choose the data-securing method by what must still be possible afterwards: recovering the original, verifying it, or merely displaying part of it. These four are the methods most often confused.

Hashing versus encryption

Hashing suits anything you only ever compare. A forensic investigator hashes a disk image when it is acquired and again before it is presented, and matching digests show it was not altered. Systems that check a secret, such as a password or PIN, store its digest and compare the digest of what is presented. Because nothing turns a digest back into its input, a stolen table of digests gives an attacker no stored secrets to read (only the option of guessing and comparing, which is why strong secrets and salting matter). Any reversible method, by contrast, is only as safe as its key or vault, and the system that verifies is usually the one allowed to reverse it. The opposite requirement points the other way: anything that must later be restored to its original form needs encryption, because every one-way or irreversible method fails that test. (How hash algorithms, salting and key management work is covered under cryptographic solutions in objective 1.3.)

Tokenization versus encryption

Ciphertext is mathematically derived from the original, so whoever obtains or breaks the key recovers the value. In the vault-based tokenization model that Security+ describes, a token is a random value with no mathematical relationship to what it replaces; it is generated independently, and only a lookup in the isolated vault maps it back. Stealing tokens therefore yields nothing to decrypt, and the only route back is the vault, which is tightly controlled and audited. That also shrinks compliance scope: systems that hold only such tokens do not store cardholder data, whereas systems holding encrypted card numbers generally remain in PCI DSS scope for an organization that can decrypt them. (PCI guidance also recognizes cryptographic tokens produced by encryption or format-preserving encryption; those keep a mathematical link to the value, and their systems stay in scope.) Unlike a hash, a token can still be redeemed for the original by the one authorized service that calls the vault.

Static and dynamic masking

Dynamic masking changes only what a user sees, at query or display time: a help-desk screen might show a customer's email address as j***@example.com while the stored address is unchanged. The real data is still there, so dynamic masking does nothing for a copy of the data that leaves your control. Static masking permanently rewrites the values in a copy, such as a training data set or an analytics sandbox, with realistic, format-valid substitutes and keeps no mapping back, so the copy contains no real values to recover.

These methods reduce what data reveals, by stripping identity, leaving fields out, rearranging values or making content hard to interpret.

Deidentification: anonymization versus pseudonymization

The deciding test is whether a way back to identity still exists anywhere. If a lookup table or key is held, even by a separate team in a separate system, the data is pseudonymized, not anonymized. Pseudonyms can be random values recorded in a lookup table or values derived with a secret key; either way it is the retained means of re-identification that makes it pseudonymization. Because a consistent pseudonym repeats for the same person, pseudonymized records can still be joined across time or across data sets, which anonymization deliberately prevents. Pick anonymization when no one ever needs to know who a record was about or to connect a person's records; pick pseudonymization when linking or later re-identification must stay possible for an authorized party.

Filtering

Filtering removes records or fields the recipient does not need, so they are simply not in the output. Sending an auditor only the transactions from the audit period, without staff home addresses, is filtering. It can be applied per recipient, so each consumer of the same source receives only the fields it is entitled to while the source keeps the full data for those who need it. That differs from masking and tokenization, which leave the field present with a partial or substitute value.

Data transpose

Data transposition rearranges data, for example moving characters or values into different positions according to a pattern, or swapping the rows and columns of a table, so values no longer read in their original order. Every original element is still present and reversing the pattern restores it. Because the pattern is the only secret, transposition is a weak obscuring step, not a substitute for encryption.

Obfuscation

Obfuscation makes data or code hard for a person to understand while it remains usable. Minifying and scrambling a web application's JavaScript so its logic is hard to follow is obfuscation: the browser still runs the code and no key is involved. Encryption, by contrast, must be decrypted with a key before the content can be used.

Data protection roles separate who is accountable for data, who operates its controls, who keeps it accurate, who works with it, and, for personal data, who decides its purpose and who processes it on that party's behalf.

Two pairs cause most confusion. Owner versus custodian: the owner decides, the custodian does. Handling data constantly does not make someone its owner; the IT staff who carry out the owner's access and protection decisions are custodians. Steward versus owner: the steward looks after the data's quality, definitions and correct labeling, but accountability and access decisions stay with the owner. CompTIA does not publish its own definition of data operator; the defensible reading is a person who works with the data day to day through the access they are given, working only within the access granted by others; the policy, the data definitions and the systems themselves belong to other roles.

Controllers, processors and subprocessors

Follow the chain to identify each party. A university that decides to run a student survey and what to do with the answers is the controller; the online survey platform it hires is a processor; the cloud infrastructure provider the platform hosts responses on is a subprocessor. (If two organizations decide the purposes and means together, they are joint controllers.) Under GDPR Article 28(2), a processor may not engage another processor without the controller's prior specific or general written authorization; with general authorization, the processor must tell the controller about changes so it can object. The authorization runs from the controller to the processor, and holding the data does not turn a subprocessor into a controller. Governance aspects of these roles, with data retention requirements and legal hold, also appear under security compliance in objective 5.4.

Data handling covers where copies of data end up and how people and tools recognize how sensitive each copy is.

Endpoints

Laptops, phones, tablets and removable media hold copies outside central controls. Server-side encryption, access control and TLS protect the server copy and the trip to the device; they do nothing for the copy once it lands there. Match the control to the path the data can take:

Choose the control that covers the place where the data is actually exposed; a control on a different location does not reduce that exposure.

Marking and labeling

Marking is a visible indicator for people, such as a classification banner on a slide, a watermark or a stamp on a paper form. Labeling is classification metadata attached to a file or message, which tools such as DLP and rights management read to enforce policy. Each audience needs its own form: tools cannot read a visual mark, and people cannot see metadata, so data that exists both as files and on paper or screen needs both.

A label protects only the copy that carries it. Content moved into a new file, by copy and paste, export or screenshot, keeps its sensitivity but not its label unless the labeling system detects the content or inherits the label, and label-driven tools then treat it as unclassified. The remedies are labels that follow content (automatic, content-based labeling or label inheritance) and training people to label what they create.

Geofencing is about where the device requesting the data is; data location and data placement are about where the data itself is stored.

CompTIA lists data location and data placement separately without defining them, so this lesson uses the distinction above: location is geographic and legal (it ties into data sovereignty, covered with architecture considerations in objective 3.1), while placement is architectural, a decision about which systems are allowed to store a class of data. A rule that names a country or region is about location; a rule that names segments, servers or device types is about placement. Neither is about how long data is kept (retention) or how it is labeled.

The data management life cycle follows data from creation to disposal, and each stage is a point where a different control applies.

A failure often surfaces at a later stage than where it happened. Disposal can destroy only the copies the organization still controls; if copies were sent out freely earlier, they survive however carefully the internal copies are destroyed. The root cause then lies at distribution, where sharing methods that create uncontrolled copies should have been replaced by ones that can be revoked or expire. Retention sets how long data is kept; disposal is the act of destroying it afterwards. (Sanitization methods and certificates of destruction are covered with asset management in objective 4.2; retention requirements and legal hold also appear under compliance in objective 5.4.)

Legal holds

A legal hold (litigation hold) requires the organization to preserve data relevant to actual or reasonably anticipated litigation, unchanged, and it suspends routine disposal for that data until the legal department lifts it. It overrides the retention schedule, and it binds every process that could destroy or alter the held data, not only the schedule itself:

• Scheduled deletion and automated purge jobs must exclude held data.
• Re-imaging, reassigning or retiring a device must not wipe held data stored on it.
• Backup media that hold relevant data must be withdrawn from rotation and overwriting.

The duty to preserve can begin as soon as litigation is reasonably anticipated, which may come before any notice is sent; it applies at the latest from the moment the hold is issued, not from some later step such as a court order.

Data compliance categories group data by the rules that govern it, and the category decides which obligations apply on top of general security practice.

Many records fit more than one category, so choose the one that most directly drives the obligation in question. Almost every category above also contains personal information, but the more specific category is usually the one whose rules create the requirement: health-specific rules for medical records, child-protection rules when the people described are children, privilege and preservation for material gathered for a case.

Standards versus laws

A standard is a set of requirements an organization adopts or is bound to by contract, while a law is imposed by a government. PCI DSS is a standard, maintained by the PCI Security Standards Council and enforced by the card brands through the agreements that let a business accept or process cards. Its obligations flow from those agreements, so it applies to every entity that stores, processes or transmits cardholder data whatever the local law says, and it sits alongside privacy law rather than being one.