Objective 3.3: Compare and contrast concepts and strategies to protect data
Cert: CompTIA Security+ (SY0-701) Domain: 3.0 Security Architecture Weight: ~18% of SY0-701 (Domain 3 total) Depth: Compare and contrast. Be able to name the data types, classify a record at the right level, identify the data state, and pick the protection method that fits the state and the classification.
What this objective tests
Data protection is the part of security architecture that decides what kind of information you have, how sensitive it is, where it lives, and what you do to keep it safe. This objective is mostly vocabulary plus pattern matching. You are given a scenario (a database column, a credit card field on a help-desk screen, an EU customer record, a laptop SSD), and you have to name the data type, the classification, the state, and the right method. The exam will mix and match. A regulated record at rest on a laptop needs encryption. A regulated record in use on a help-desk view needs masking. A trade-secret record that has to leave the country triggers a data sovereignty question. Knowing the seven methods (encryption, hashing, masking, tokenization, obfuscation, segmentation, permission restrictions) and which state each one fits is the win condition.
Key facts
Data types
The objective names six data types. These describe what kind of information you have, not how sensitive it is.
| Type | Plain-English definition | Real example |
|---|---|---|
| Regulated | Information governed by a law or regulation. Disclosure carries legal penalties. | PII (Personally Identifiable Information), PHI (Protected Health Information), PCI (Payment Card Industry) cardholder data |
| Trade secret | Confidential business information that gives the company a competitive edge. Not patented. Protected only as long as it stays secret. | Recipe for a soda formula, manufacturing process, pricing model |
| Intellectual property | Patents, copyrights, trademarks. Often public but legally owned. | Source code, a published book, a registered logo |
| Legal information | Documents tied to legal matters or attorney-client work. | Case files, contracts, deposition transcripts |
| Financial information | Records about money flow, accounts, and balances. | Bank statements, payroll, invoices, ledger entries |
| Human-readable vs non-human-readable | Human-readable can be opened and understood by a person without special tools. Non-human-readable is binary, encoded, or otherwise needs decoding. | Human: a .docx file. Non-human: a compiled .exe, a database dump, an encrypted blob |
The point of the human-readable vs non-human-readable distinction is that protection strategy can change. A non-human-readable binary still needs encryption at rest if it contains regulated data. Format does not equal protection.
Data classifications
The objective names six classifications. These describe how sensitive the data is and who can see it.
| Classification | What it means | Who can see it | Example |
|---|---|---|---|
| Public | Already meant to be released to the world. No confidentiality risk. | Anyone | Marketing site copy, published whitepaper |
| Private | Internal to the company. Not for outside release. | Employees | Internal org chart, internal SharePoint pages |
| Sensitive | Internal data that would harm the company if leaked, but not at a regulatory level. | Defined employee groups | Sales forecasts, internal financial projections |
| Confidential | Strong internal restriction. Often tied to NDAs (Non-Disclosure Agreements) and contracts. | Named individuals or roles | M&A (Merger and Acquisition) plans, client contract terms |
| Restricted | Highly sensitive. Access tightly controlled and logged. Includes most regulated data. | Named individuals with documented need to know | Customer PII, PHI medical records, source code for a security product |
| Critical | If lost or exposed, the business or its customers face severe harm. Often a subset of restricted, called out separately because of impact. | Smallest possible group | Encryption keys, root credentials, the master customer database |
Two things to notice. First, "sensitive" sits between private and confidential in most organizations, but the exact ladder varies. Second, "critical" is about business impact, not legal exposure. A trade-secret recipe can be critical without being regulated.
Data states
There are three states. Every piece of data is in exactly one at any moment.
| State | What it means | Where it lives | Typical method |
|---|---|---|---|
| At rest | Stored. Not moving. | Disk, SSD, tape, cloud object storage, database file | Encryption (BitLocker, FileVault, TDE for databases, S3 server-side encryption) |
| In transit | Moving across a network. | Wire, fiber, Wi-Fi, cellular, internet | TLS (Transport Layer Security), IPsec, SFTP, VPN tunnels |
| In use | Loaded into memory and being processed. | RAM, CPU cache, an open file, an active database row | Masking, field-level access control, secure enclaves, RBAC (Role-Based Access Control) |
In use is the hardest state to protect because the data has to be readable to be useful. That is why masking, tokenization, and permission restrictions matter so much. Encryption usually has to come off before processing, which is the window an attacker tries to hit.
Data sovereignty and geolocation
Data sovereignty. The principle that data is subject to the laws of the country where it is stored. If a German company stores customer data in a US data center, US law (including subpoenas) reaches that data. If a company moves the same data to a Frankfurt data center, German and EU law (GDPR) apply.
Geolocation. The actual physical location of the data. Cloud providers expose this through region selection. AWS eu-central-1 is Frankfurt. Azure germanywestcentral is Germany. Choosing the wrong region can violate a sovereignty requirement without anyone noticing until an audit.
A typical exam scenario sounds like this. A multinational stores EU customer records in a US-region bucket. The compliance team flags it. What is the concept at play? Data sovereignty. What is the fix? Move the data to an EU region (geolocation control), and add a geographic restriction at the application layer so future writes cannot land outside the EU.
Methods to secure data
Seven methods are named in the objective. Each one fits one or more data states better than others.
| Method | What it does | Reversible | Best state | Real use |
|---|---|---|---|---|
| Encryption | Transforms data with a key so only key holders can read it | Yes (with key) | At rest, in transit | BitLocker disk, TLS web traffic, IPsec VPN |
| Hashing | One-way function that produces a fixed-length fingerprint | No | Stored passwords, integrity checks | bcrypt password hash, file integrity hash |
| Masking | Hides part of a value while preserving format | Sometimes (depends on impl.) | In use | Help-desk view of a credit card as ---1234 |
| Tokenization | Replaces sensitive data with a non-sensitive token. Original lives in a separate vault. | Yes (via vault lookup) | At rest, in use | PCI tokenization replacing PAN with a token in the order system |
| Obfuscation | Makes data harder to interpret but does not provide strong protection | Sometimes | In use, at rest (weak) | Obfuscated source code, deliberately confusing data formats |
| Segmentation | Separates regulated or sensitive systems onto their own network or trust zone | N/A | At rest, in transit, in use | PCI cardholder data environment on its own VLAN |
| Permission restrictions | Limits which accounts can read or write the data | N/A | All states | RBAC on a SharePoint site, ACL on a file share |
Encryption vs hashing vs tokenization is the most-tested distinction in this set.
- Encryption is reversible by anyone with the key. You use it when you need the data back.
- Hashing is not reversible. You use it when you only need to verify, never read. Passwords. File integrity. Digital signatures.
- Tokenization replaces the data entirely with a placeholder. The placeholder has no math link to the original. The original lives in a vault. You use it when you want to shrink PCI scope or hide the original from most of the system.
Masking vs obfuscation trips students up too.
- Masking hides specific characters of a real value (last 4 digits visible, rest hidden). The format is preserved so apps and humans can still work with it.
- Obfuscation makes data harder to read but is not a strong control. Renaming columns to nonsense, scrambling, or using uncommon encodings counts. Treat obfuscation as a speed bump, not a lock.
Segmentation and permission restrictions are about who can reach the data, not what shape the data is in. Segmentation puts the data in its own network zone. Permission restrictions put a guard on the door. Both are critical for in-use data, where the data itself has to be readable.
Common gotchas
- Hashing is not encryption. If a scenario asks how to store passwords, the answer is a hash (bcrypt, Argon2), not encryption. If the scenario asks how to protect a customer record at rest so it can be read later by the app, the answer is encryption, not a hash.
- Tokenization does not encrypt the original. It replaces it. The original sits in a vault that has its own protections. Calling tokenization "a kind of encryption" loses you the point.
- Masking is for the display layer. It does not protect the data at rest. If a help-desk view masks a credit card but the database stores the full number unencrypted, the data is not protected.
- Data sovereignty is not the same as encryption. A scenario about EU records in a US region is asking about sovereignty and geolocation, not crypto. Picking encryption as the answer is a mistake.
- In use is the hardest state. When a scenario describes a record open in an application, encryption alone is not the answer. Look for masking, permission restrictions, or tokenization.
- Public does not mean unprotected. Public data still needs integrity controls. A defacement of a public marketing site is still an incident.
- Restricted vs critical. Restricted is about access tightness. Critical is about business impact if lost. The same record can be both.
- Regulated data drives controls, not the other way around. PCI-DSS, HIPAA, and GDPR each prescribe what controls apply. The job is to recognize which framework applies and pull from its requirement set, not to invent a control list.
Real-world context
A SOC Tier 1 analyst at a community bank gets a DLP (Data Loss Prevention) alert at 9:14 AM. The alert says an outbound email from an employee to a personal Gmail address contained a CSV with 142 records that match the PCI cardholder number pattern. The analyst opens the alert and has to answer a chain of architecture questions. What classification is the data? Restricted, because it is regulated PCI data. What state was the data in when it left? In transit, over SMTP. What method should have stopped the leak? The bank's DLP policy with content inspection, plus permission restrictions on the source system that should not have allowed bulk export, plus tokenization in the order system so the PAN (Primary Account Number) never appeared in a CSV in the first place. What method protects the data still sitting on the source database? TDE (Transparent Data Encryption) at rest, plus RBAC so only payment-processing roles can read the column.
A compliance lead at the same bank has a parallel job. She maps every PCI data store to PCI-DSS requirements. She maps every PII data store to NIST SP 800-122 guidance on PII confidentiality. She tags every record set by classification (restricted, critical, confidential, private, public) so retention and access policies can be applied automatically. She watches the cloud region picker on every new project, because data sovereignty for the bank's EU subsidiary means new buckets must land in eu-central-1, not us-east-1.
The architect in the room has a third view. He looks at the seven methods and asks which combinations cover the data lifecycle. Encryption at rest. TLS in transit. Tokenization to shrink the PCI scope. Masking on the help-desk view. Segmentation to isolate the cardholder environment. Permission restrictions on every layer. Hashing for passwords and integrity. No single method is a complete answer. Defense-in-depth across states is the answer.
Sources
- CompTIA Security+ SY0-701 Exam Objectives 7.0 (Domain 3.3)
- NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization
- NIST SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)
- NIST SP 800-60 Vol. 1 Rev. 1, Guide for Mapping Types of Information and Information Systems to Security Categories
- NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- PCI Security Standards Council, PCI DSS v4.0
- HHS, HIPAA Security Rule (45 CFR Part 164, Subpart C)
- EU GDPR (Regulation 2016/679), Articles 5, 32, 44 to 49