Security+ 801 Countdown, T-19: Data Types, Classifications, and Deidentification

Data protection begins with a sorting problem. Before a control can be chosen, three questions have to be answered about the data itself: what form it takes (a database column or a recorded phone call), how sensitive it is (a label such as Confidential or Secret), and which legal or contractual regime reaches it (HIPAA for a diagnosis, PCI DSS for a card number). Only then does the choice of transformation make sense: encrypt the value, replace it with a token, hash it, mask it on screen, filter which rows a user can see, shuffle it for a test database, or strip the identifiers out altogether.

SY0-801 objective 3.3 covers protecting data and expands the topic in each of those directions: data types sorted by structure, seven classification labels, a new Data compliance heading with seven categories, and three added protection methods, Filtering, Data transpose, and Deidentification (CompTIA 2025). Data roles, handling, and the data life cycle are covered at T-18. This post works through the sort, then applies every method to one fictional record so the differences between them are visible rather than asserted.

Sorting data by structure, label, and regime

Structure

Structured data is data with a schema: tables, columns, typed fields, and keys that relate one record to another. Unstructured data is everything without that scaffolding. NIST describes unstructured data as formats that “often lack explicit structure that relates data to individuals, such as text, pictures, audio, and video” (NIST n.d.). The distinction matters because the schema is what the controls hang on. With a schema you can encrypt a column, mask a field, or filter rows by a predicate; documents and recordings offer no such handles, so they need discovery (finding where they are), labeling at creation, and data loss prevention inspection on the way out (T-16).

The two categories also nest. A free-text “notes” column inside a patient table is unstructured content living in a structured container (Garfinkel et al. 2023); column-level encryption on the diagnosis code next to it does nothing about a clinician typing the same diagnosis and a phone number into the notes field.

Labels

A classification label is a short name for how much damage disclosure would cause, attached to the data so that handling rules can follow it. The seven labels in SY0-801 come from two families. Executive Order 13526 defines the three US government levels by expected damage to national security: Top Secret (“exceptionally grave damage”), Secret (“serious damage”), and Confidential (“damage”), and it adds that “no other terms shall be used to identify United States classified information” (Obama 2009). Sensitive, Restricted, and Critical are therefore never government levels; they belong to the organizational family, where a company ranks its own information for its own reasons. Confidential is the one label that sits in both families.

CompTIA defines none of the seven, so any ordering of the business labels is organizational convention rather than standard, and reading Critical as an availability-driven label (data the business cannot operate without) is interpretation. Classification is also distinct from security categorization: FIPS 199 rates confidentiality, integrity, and availability impact separately for federal systems and explicitly excludes classified national security information (NIST 2004).

Regime

The third sort is by the rules that reach the data. The Data compliance heading in SY0-801 names seven categories, each anchored here to an example regime:

Category	Example regime	Anchor
Health data	HIPAA Privacy Rule	De-identification standard, 45 CFR 164.514
Personal information	GDPR	Pseudonymized data stays personal data
Financial	GLBA Safeguards Rule; PCI DSS	Encryption in transit and at rest, 16 CFR 314.4(c)(3)
Child/minor data	COPPA, 16 CFR Part 312	“Child” means under 13
Intellectual property	Trade secret law	18 U.S.C. 1839(3)
Legal data	Privilege, litigation material	Legal hold (T-4)
Standards	ISO/IEC 27001:2022, PCI DSS	Requirements you are assessed against

Child data shows how the categories overlap. The FTC’s amended COPPA Rule took effect June 23, 2025, with compliance due April 22, 2026 for all but three safe harbor program provisions (FTC 2025). It reaches online operators collecting from children under 13, not a pediatric clinic’s charts, which are HIPAA protected health information. The Safeguards Rule at 16 CFR 314.4(c)(3) requires encryption of customer information in transit and at rest (eCFR n.d.-a), and ISO/IEC 27001:2022 is a standard an organization is assessed against rather than a law it is subject to (ISO 2022). Intellectual property carries a condition: trade secret status requires that the owner take “reasonable measures to keep such information secret” (Legal Information Institute n.d.), which is one reason the labels in the previous section are not paperwork. Privacy rights and legal compliance more broadly are covered at T-4.

Eight methods applied to one record

Take one fictional row: Avery Rivera, avery.rivera@example.com, born 1984-03-07, ZIP 23219, card 4111111111111111, salary 68000, diagnosis asthma. When I teach this in ITN 260 I run every method against the same record, because the differences between them only show when the input is held constant. The hash, HMAC, and ciphertext values below are real OpenSSL 4.0.3 output from October 12, 2026, trimmed for width.

Method	Avery’s row becomes	Reversible?
Encryption (AES-256-CBC)	Card U2FsdGVkX194w7hV...Bl2Z	Yes, with the key
Tokenization (vault)	Card tok_f41e2df1fe9f6abc	Only through the vault
Hashing, unkeyed SHA-256	Email d436ec10...8bb33afd	No, but guessable
Hashing, keyed HMAC	Email 7159336d...45fc15	No; a stable pseudonym
Masking	Card **** **** **** 1111 on screen	Dynamic: stored value intact
Filtering	Row absent for other regions	Data unchanged
Data transpose	Salary from another row	Only with the original table
Deidentification	No name, email, or card; born 1984; ZIP 232	Not if anonymized

The Reversible column is the organizing idea. Encryption transforms data under a key so that only a key holder can recover it; the protection is as good as the key management. Obfuscation, the umbrella term for making data harder to read, differs in kind: on its own it relies on a secret method rather than a secret key, and a method, once learned, protects nothing.

Tokenization replaces a sensitive value with a surrogate and keeps the mapping somewhere else. In vault-based (random) tokenization the token has no mathematical relationship to the card number, so possessing the token is worthless without the vault. That property is not universal: PCI also defines cryptographic and irreversible tokens, and a token derived by encryption “is an encrypted PAN.” Tokenization can shrink PCI DSS scope but does “not eliminate the need to maintain and validate PCI DSS compliance” (PCI SSC 2011; PCI SSC 2015).

Hashing produces a fixed-length digest that cannot be run backward, but the input space matters. An unkeyed hash of an email address falls to anyone who hashes candidate addresses and compares; “Hashing without a key generally does not confer security” (Garfinkel et al. 2023). Adding a secret key, as an HMAC does, removes the guessing attack and yields a stable, joinable pseudonym: the same address always maps to the same value, so records can be linked without the address being present. That is pseudonymization, not anonymization, a distinction the final section returns to.

Masking alters what is displayed, not necessarily what is stored. Static masking rewrites a copy of the data for non-production use. Dynamic masking alters only query results: in SQL Server, ADD MASKED WITH (FUNCTION = 'email()') leaves the stored value unchanged, GRANT UNMASK reveals it to a privileged user, and a range query such as WHERE Salary > 99999 and Salary < 100001 can infer a masked value one probe at a time (Microsoft n.d.). Dynamic masking is a display control with an inference hole, not a substitute for encryption.

Filtering is the one method on the list that CompTIA does not define, so the following is interpretation: masking returns every row with values altered; filtering returns fewer rows with values intact. Row-level security in PostgreSQL is the model. CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user); limits the managers role to rows where the manager column matches the connecting user (documented syntax, not run here). With row security enabled and no policy defined, a table is default-deny, and table owners bypass policies unless FORCE ROW LEVEL SECURITY is set (PostgreSQL n.d.). The outbound sense of filtering, blocking sensitive content from leaving the organization, is data loss prevention, covered at T-16.

Data transpose: shuffling values across rows

The SY0-801 objectives list Data transpose without defining it (CompTIA 2025), and two practitioner readings exist, both of which are interpretation:

• Value-level transposition: swap “one value with another, or a portion of one string with another” in a consistent pattern, e.g., the first and last four digits of a test card number (Lane 2012). Anyone who learns the pattern can reverse it.
• Column shuffling: move real values across rows so that each value is genuine but attached to the wrong record. Securosis calls this shuffling; NIST SP 800-188 calls it attribute or record swapping.

Neither reading is a transposition cipher, and neither is a spreadsheet TRANSPOSE. The second reading is the one that explains why the method exists: a test database needs salaries that look like salaries and add up like salaries, without any salary staying attached to its real owner. A shuffle of six fictional salaries in SQLite 3.54.0, run October 12, 2026:

WITH s AS (SELECT salary, row_number() OVER (ORDER BY random()) AS rn FROM employees),
     o AS (SELECT id, row_number() OVER (ORDER BY id) AS rn FROM employees)
UPDATE emp_test SET salary =
  (SELECT s.salary FROM s JOIN o USING (rn) WHERE o.id = emp_test.id);

id    dept    prod_salary  test_salary
101  Finance        68000        68000
102  Finance        91000        63000
103  IT             74000       102000
104  IT            102000        59000
105  HR             59000        74000
106  HR             63000        91000

tbl   n  total    mean
prod  6  457000  76167.0
test  6  457000  76167.0

 dept    prod_avg  test_avg
Finance   79500.0   65500.0
HR        61000.0   82500.0
IT        88000.0   80500.0

The total and mean survive exactly, which is the point of the method. Everything finer-grained breaks. Department averages change (Finance falls from 79500 to 65500), which is NIST’s warning that swapping “may damage or destroy important relationships within the data,” and the method carries no formal privacy guarantee (Garfinkel et al. 2023). Two more cautions come straight from the output. Avery’s 68000 landed back on Avery’s row: a random shuffle of six values leaves at least one in place about 63 percent of the time, so the result has to be checked, not assumed. And the names never moved, so transposition alone does not remove direct identifiers; it has to be combined with deidentification to produce a safe test set.

Deidentification and re-identification

Deidentification is the removal or alteration of information that could identify a person. NIST SP 800-188 uses de-identification as the umbrella term, reserves anonymization for processes that “cannot be reversed,” and treats pseudonymization as replacing identity with pseudonyms (Garfinkel et al. 2023). The keyed HMAC applied to Avery’s email above is pseudonymization: the identity is gone from the row, but the mapping still exists. Anonymization means no such mapping exists anywhere.

HIPAA turns that definition into two concrete routes in 45 CFR 164.514(b). Expert Determination is a documented finding that “the risk is very small,” with no numeric threshold. Safe Harbor is a checklist with two conditions: remove 18 identifier categories, and have no actual knowledge that the remaining data could identify someone. ZIP codes shrink to three digits (and only where that three-digit area exceeds 20,000 people), dates to the year, and ages over 89 to 90 or older (eCFR n.d.-b). Partial identifiers fail the test: HHS rejects initials and “the last four digits of a Social Security number” (HHS n.d.). A third category, the limited data set, keeps dates and ZIP codes, stays protected health information, and needs a data use agreement.

GDPR draws the same line. Pseudonymized data remains personal data and stays inside the regulation; truly anonymized data falls outside it (EDPB 2025; European Commission n.d.). A 2025 CJEU ruling under the parallel regulation for EU institutions holds that this need not be true for every recipient (CJEU 2025), but the exam answer stands: pseudonymized is still personal.

Removing names is not enough. NIST IR 8053 recounts Sweeney re-identifying Massachusetts Governor William Weld’s hospital records by matching birth date, ZIP code, and sex against a $20 Cambridge voter list (Garfinkel 2015). The attack works because three fields that are harmless alone pick out a single row together. The same test on seven fictional visits (SQLite, October 12, 2026), first on raw fields and then after Safe Harbor-style generalization:

zip      dob      sex  k
23219  1984-03-07  F    1
23219  1984-11-22  F    1
23220  1984-06-30  F    1

zip3  birth_year  sex  k
232   1984        F    3
232   1991        M    3
232   90+         F    1

The column k counts how many rows share the same combination of ZIP, birth date, and sex. On the raw fields every row is unique (k = 1), which is Weld’s situation exactly. Safe Harbor-style generalization lifts most rows to k = 3, but the patient over 89 stays alone at k = 1. Safe Harbor is a checklist, not a k-anonymity guarantee; a policy that requires k = 3 has to suppress that row rather than release it.

What you need to know for SY0-801

• Data types describe form: structured (schema, column-level controls) versus unstructured (text, images, audio, video; discover and label first).
• Regulated, Trade secret, and the other SY0-701 data types were regulation-based vocabulary; in SY0-801, data type means structure, and regulation lives under Data compliance.
• Top Secret, Secret, and Confidential mean exceptionally grave damage, serious damage, and damage. Sensitive, Restricted, and Critical are organizational labels only.
• Classification labels sensitivity; FIPS 199 categorization rates confidentiality, integrity, and availability impact separately and excludes classified information (NIST 2004).
• Encryption reverses with a key, vault tokens only through the vault, and hashes not at all, though unkeyed hashes of guessable values fall to brute force.
• Cues: “test totals must match” means transpose; “card numbers out of the order database” means tokenization; “agent sees only the last four” means dynamic masking; “users see only their region” means filtering.
• Anonymized data is outside GDPR; pseudonymized data is still personal data; a HIPAA limited data set is still PHI.
• Safe Harbor means 18 identifier categories removed plus no actual knowledge; partial identifiers fail it.

Check yourself

These are original practice questions, not exam items.

1. A payroll team needs test data in which salaries look real and the total matches production exactly, but no salary stays attached to its real employee. Which method fits best?

• A. Dynamic data masking.
• B. Tokenization.
• C. Data transpose.
• D. Hashing.

Answer: C. Shuffling real salaries across rows keeps the total exact and breaks the salary-to-person link. Masking and tokenization replace values, and hashes are not usable salaries.

2. A hospital research extract drops names, addresses, full dates, and full SSNs but keeps initials and the last four SSN digits for matching. Researchers need data that is no longer PHI. What is the BEST assessment?

• A. It meets Safe Harbor because no full identifier remains.
• B. It fails Safe Harbor because partial identifiers still count.
• C. It is a limited data set, so it is no longer PHI.
• D. It meets HIPAA if the SSN digits are hashed without a key.

Answer: B. HHS says initials and the last four SSN digits do not meet Safe Harbor. A limited data set is still PHI, and an unkeyed hash of four digits has only 10,000 possible inputs.

3. A contractor’s handling guide covers information whose unauthorized disclosure could reasonably be expected to cause serious damage to national security. Which label applies?

• A. Restricted.
• B. Top secret.
• C. Secret.
• D. Critical.

Answer: C. Executive Order 13526 ties serious damage to Secret and exceptionally grave damage to Top Secret. Restricted and Critical are organizational labels, and no other terms may name US classified information.

This is T-19 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-18: Data Roles, Handling, and Life Cycle Move Into Architecture. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

CJEU (Court of Justice of the European Union). 2025. “Judgment of the Court in Case C-413/23 P, EDPS v SRB.” Press Release No 107/25, September 4, 2025.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

eCFR (Electronic Code of Federal Regulations). n.d.-a. “16 CFR Part 314: Standards for Safeguarding Customer Information.” Accessed October 12, 2026.

eCFR (Electronic Code of Federal Regulations). n.d.-b. “45 CFR 164.514: Other Requirements Relating to Uses and Disclosures of Protected Health Information.” Accessed October 12, 2026.

EDPB (European Data Protection Board). 2025. Guidelines 01/2025 on Pseudonymisation. Version for public consultation, adopted January 16, 2025.

European Commission. n.d. “Application of the GDPR.” Accessed October 12, 2026.

FTC (Federal Trade Commission). 2025. “Children’s Online Privacy Protection Rule.” Federal Register 90, no. 76: 16918 to 16983. FR Doc. 2025-05904.

Garfinkel, Simson. 2015. De-Identification of Personal Information. NIST IR 8053. Gaithersburg, MD: National Institute of Standards and Technology.

Garfinkel, Simson, Joseph Near, Aref N. Dajani, Phyllis Singer, and Barbara Guttman. 2023. De-Identifying Government Datasets: Techniques and Governance. NIST SP 800-188. Gaithersburg, MD: National Institute of Standards and Technology.

HHS (U.S. Department of Health and Human Services), Office for Civil Rights. n.d. “Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.” HHS.gov. Content last reviewed February 3, 2025.

ISO (International Organization for Standardization). 2022. “ISO/IEC 27001:2022, Information Security Management Systems.” ISO catalog. Accessed October 12, 2026.

Lane, Adrian. 2012. “Understanding and Selecting Data Masking: Defining Data Masking.” Securosis, May 23, 2012.

Legal Information Institute. n.d. “18 U.S. Code 1839, Definitions.” Cornell Law School. Accessed October 12, 2026.

Microsoft. n.d. “Dynamic Data Masking.” Microsoft Learn. Accessed October 12, 2026.

NIST (National Institute of Standards and Technology). 2004. Standards for Security Categorization of Federal Information and Information Systems. FIPS PUB 199. Gaithersburg, MD: National Institute of Standards and Technology.

NIST (National Institute of Standards and Technology). n.d. “Unstructured Data.” CSRC Glossary, citing NIST SP 800-226. Accessed October 12, 2026.

Obama, Barack. 2009. “Executive Order 13526: Classified National Security Information.” December 29, 2009. National Archives, Information Security Oversight Office.

PCI SSC (PCI Security Standards Council). 2011. PCI DSS Tokenization Guidelines. Information Supplement.

PCI SSC (PCI Security Standards Council). 2015. Tokenization Product Security Guidelines: Irreversible and Reversible Tokens. Information Supplement, version 1.0.

PostgreSQL Global Development Group. n.d. “Row Security Policies.” PostgreSQL 18 Documentation, section 5.9. Accessed October 12, 2026.