Gallery

Contacts

405 W. Greenlawn Ave Lansing, Michigan 48910

contact@techjacksolutions.com

+1-616-320-4064

3.3 Domain 3 · Security Architecture

Concepts and Strategies to Protect Data

Data types, classifications, the three data states, sovereignty, and the toolbox — encryption, hashing, masking, tokenization, DLP — that keeps sensitive information from walking out the door.

Concept
2
Textbook
3
Reference
4
Real Scenario
5
Hard Choice
6
Common Traps
7
Exam Signal
The Concept

Data protection is not one control — it is a stack of controls matched to where the data lives and who is allowed to see it. Every Domain 3.3 question tests whether you can pick the right tool for the right state: at rest, in transit, or in use.

Three mental hooks carry most questions: (1) Classify before you protect — you cannot defend what you have not labeled (public, sensitive, confidential, restricted, private, critical). (2) State drives the control — TLS for transit, disk/field-level encryption for rest, enclaves or tokenization for in-use. (3) Sovereignty is a legal layer on top of technical protection — encryption does not exempt you from GDPR or data-residency law. The exam repeatedly distinguishes hashing from encryption, masking from obfuscation, and tokenization from encryption — learn those four pairs cold.

Data types. The first job is knowing what kind of data you are holding, because different types trigger different legal and business obligations. Regulated data is governed by law — GDPR for EU personal data, HIPAA for US health information, PCI DSS for card data, SOX for financial reporting. Trade secrets derive value from being kept secret (formulas, proprietary algorithms). Intellectual property (IP) covers patents, copyrights, and trademarks. Legal information includes privileged communications and litigation holds. Financial information covers accounts, transactions, and M&A data. Data may be human-readable (documents, emails) or non-human-readable (binary protocol payloads, machine logs) — both can be sensitive.

Data classifications. Classification is the label that drives handling. The Security+ objectives call out: sensitive (non-public, protection required), confidential (internal; disclosure would harm the organization), public (approved for external release), restricted (tightly controlled, need-to-know, often regulated or top secret), private (personal/individual-linked data — PII), and critical (essential to business operations). Labels should be simple enough that staff apply them correctly; over-classification is as bad as under-classification.

Data states. Every piece of data is in exactly one of three states at any moment. Data at rest sits on disk, tape, or object storage — protect it with full-disk encryption (BitLocker, LUKS), transparent database encryption (TDE), field-level encryption, and access control lists. Data in transit moves across a network — protect it with TLS 1.2+ for application traffic, IPSec for VPN tunnels. Data in use is in RAM or CPU registers while being processed — the hardest state. Protections include memory encryption, confidential computing, and secure enclaves like Intel SGX and AMD SEV, which isolate sensitive computation from the host OS and even the hypervisor.

Data sovereignty and geolocation. Sovereignty is the legal principle that data is subject to the laws of the country where it physically resides. EU, Russia, China, and many others have enacted data-residency laws that restrict cross-border transfer. Geolocation is the physical location of the data — drives sovereignty obligations and also latency and disaster-recovery design. Cloud providers offer region selection precisely so customers can meet these constraints; use tagging and policy to enforce.

Methods to secure data. Geographic restrictions: cloud region locking and policy to prevent out-of-region writes. Encryption: symmetric (AES) or asymmetric (RSA, ECC) transformation requiring a key to reverse — protects confidentiality and is applied to all three states. Hashing: one-way transformation producing a fixed-length digest; used for integrity (file verification) and password storage (always with a salt and a key-stretching function such as bcrypt, scrypt, or Argon2). Masking: display-time partial obfuscation (show last 4 of SSN); the underlying value is unchanged. Tokenization: replace the sensitive value with a random token and keep the original in a tightly controlled vault; PCI DSS scope is dramatically reduced because the token has no mathematical relationship to the PAN. Obfuscation: make data harder to read without cryptographic guarantee (base64, hex encoding) — a speed bump, not a protection. Segmentation: isolate data stores by sensitivity (separate databases, VLANs, or tenants). Permission restrictions: least privilege enforced through ACLs, RBAC, or ABAC — the everyday control most incidents bypass because it was misconfigured.

Data Loss Prevention (DLP). Content inspection that searches traffic, endpoints, or cloud storage for sensitive patterns — credit card numbers, SSNs, intellectual-property markers. Three deployment points: endpoint DLP (agent on the device, can stop a USB copy), network DLP (inline at egress or email gateway, inspects outbound traffic), and cloud DLP (typically via a Cloud Access Security Broker, scans SaaS stores). Common actions: block, quarantine, alert, redact. Tuning is the hard part — too strict breaks the business, too loose misses the breach.

StateWhere it livesPrimary controlsExam cue
At restDisk, tape, object storage, backupsBitLocker/LUKS, TDE, field encryption, ACLs“Laptop stolen”, “Backup tape lost”
In transitNetwork, API calls, replicationTLS 1.2+, IPSec, SSH“User uploads to S3”, “App calls database”
In useRAM, CPU registers, cacheEnclaves (SGX/SEV), confidential computing, tokenization“Processing PAN in memory”, “Protect key during compute”
TechniqueReversible?When to useCommon confusion
EncryptionYes, with keyConfidentiality for any stateNot integrity by itself
HashingNo (one-way)Integrity, password storage (+ salt + bcrypt/scrypt/Argon2)Not encryption — no key
MaskingPartial (display only)Showing last-4 of SSN/PAN to call-center repsUnderlying value is unchanged
TokenizationOnly via vault lookupPCI PAN storage, removing systems from scopeToken has no math link to original
ObfuscationTriviallyDeter casual observation (base64, hex)Not a security control by itself
ClassificationMeaningTypical example
PublicApproved for external releaseMarketing site, published annual report
PrivateIndividual-linked data (PII)Employee home address, customer email
SensitiveNon-public; protection requiredInternal roadmap, non-PII HR data
ConfidentialDisclosure would harm the orgM&A plans, source code
RestrictedNeed-to-know; often regulatedCardholder data (PCI), PHI (HIPAA), classified
CriticalEssential to business operationsCustomer database, production encryption keys

A mid-size retailer is preparing for its PCI DSS assessment. The e-commerce platform stores the full primary account number (PAN) in a central orders database to support refunds and recurring billing. The QSA has flagged the orders database, the analytics warehouse, the customer-service tooling, and the reporting BI system as “in scope” — four systems now subject to the full PCI controls regime. The CISO is meeting the lead DBA to decide how to fix it.

Meeting
CISO ↔ Lead DBA
PCI Scope Reduction
DBA
“We’re already encrypting the database at rest with TDE. Why isn’t that enough?”
CISO
“TDE protects the file on disk if the drive walks out the door. It does not reduce PCI scope, because anything with the decrypted PAN in memory or in a query result is still in scope. That’s why analytics, CS, and BI all got flagged.”
DBA
“So we add field-level encryption on just the PAN column?”
CISO
“Helps, but anywhere we decrypt for use is still in scope — and we still have a key to protect. Tokenization is the scope reducer. Replace every PAN with a token; store the real PAN in a vault run by the payment processor. Analytics, CS, and BI see the token only — they’re out of scope entirely.”
DBA
“And when we need the real PAN for a refund?”
CISO
“The refund service calls the vault over a mutually authenticated API. That service stays in scope, but the blast radius collapses from four systems to one.”
Key Insight
Encryption protects the data. Tokenization shrinks the scope. For PCI, the exam-relevant advantage of tokenization is that downstream systems never see the real PAN — so they are removed from the audit boundary.
Compensating Controls
Still needed after tokenization: encryption at rest on the vault, TLS between the refund service and the vault, strong authentication on vault APIs, key rotation, segregation of duty for vault administrators, and DLP on any system that could receive tokens plus PANs during migration.

Your customer-service agents verify callers by confirming the last four digits of a card on file. The current console displays the full PAN from the database. You must change it — but the reps still need something to verify callers. You can modify the console, the database, or both. Budget is small; the change ships in two sprints.

Option A
Data masking at the console

Leave the database as-is; change the console to render only the last four digits of the PAN. Reps can verify callers but cannot see or export the full number.

Option B
Tokenize the PAN at the database

Replace every PAN in the database with a token; store the real PAN in a vault. Console only ever shows the token’s last-four metadata.

Option A is the right call for this scope.

The requirement is display-level: reps need to confirm the last four, nothing more. Masking at the console satisfies that in one change, in one sprint, on one codebase. It keeps the underlying data available for legitimate business operations (refunds, chargebacks) without forcing a full tokenization project.

Why Option B is the wrong fit here: tokenization is the right answer when the goal is to reduce PCI scope across multiple downstream systems. For a single console change, it is a hammer for a thumbtack — the vault, migration, and API redesign cost months, not two sprints. Save tokenization for the scope-reduction project and use masking for the display-only fix.

Both Options are valid controls — the exam tests whether you know which control fits which problem. Masking hides part of the display; tokenization replaces the stored value. Problem = display → masking. Problem = scope reduction → tokenization.

1
Calling hashing a form of encryption
Trap: “We hashed the file, so it’s encrypted.” Hashing is one-way; there is no key and no path back to the original. It provides integrity, not confidentiality.
Exam signal: any question pairing “password storage” with “encryption” is likely wrong. Passwords should be hashed, with salt and a slow function (bcrypt/scrypt/Argon2).
2
Tokenization vs. encryption confusion
Trap: Treating tokenization as “encryption with a fancy name.” Tokenization replaces the value with an unrelated token; the original is retrieved by vault lookup, not by decryption with a key.
Exam signal: when PCI scope reduction is mentioned, tokenization is almost always the intended answer because downstream systems never see the PAN.
3
Masking vs. obfuscation
Trap: Using the words interchangeably. Masking hides part of the display while keeping the underlying value intact; obfuscation tries to hide the whole value with weak transformations (base64, hex) that any attacker can reverse.
Exam signal: “display only the last four of the SSN” is masking. “We base64-encoded the API key in the config file” is obfuscation — and not a security control.
4
Data sovereignty ≠ data locality
Trap: Saying “we stored it in EU-West-1, so GDPR is covered.” Locality is the physical location. Sovereignty is the legal regime that applies because of that location (and sometimes because of the citizenship of the data subject). They are related but distinct.
Exam signal: any answer implying that an EU region automatically handles GDPR compliance is oversimplified; legal review and data-transfer mechanisms (SCCs, adequacy decisions) are still required.
5
Treating DLP as a silver bullet
Trap: “We bought a DLP tool, we’re good.” DLP only catches what you teach it to look for — tuned patterns, fingerprinted documents, classifier policies. Encrypted exfil, novel data formats, and insider-approved channels can all bypass it.
Exam signal: DLP is part of a layered approach — classification, access control, segmentation, and monitoring all still matter. Pure “deploy DLP” answers are usually distractors.
Signal
Data-protection questions almost always encode the state of the data in the scenario. Is the data on a laptop? At rest. Moving from app to database? In transit. Being processed in memory? In use. Once you name the state, the control set narrows to a handful of options and the distractors become obvious.
Practice Question 1 of 3
A payment processing application holds the primary account number (PAN) briefly in memory while authorizing a transaction. Which control best protects the PAN while it is being processed?
  • A Full-disk encryption on the application server
  • B TLS 1.3 between the app and the card network
  • C A secure enclave (Intel SGX or AMD SEV) to isolate the processing from the host OS
  • D Daily tape backups of the transaction log

Correct: C. The data is in use — actively in RAM. Enclaves (SGX/SEV) and confidential computing are the Security+-cited controls for that state, because they protect the computation from the host OS and even the hypervisor.

A wrong: full-disk encryption protects data at rest. B wrong: TLS protects data in transit — not in memory. D wrong: backups are a recovery control, not a data-in-use protection.

Source: CompTIA SY0-701 Objectives v5.0 — 3.3 Data Protection

Practice Question 2 of 3
A retailer wants to remove its analytics warehouse and reporting tools from PCI DSS scope while still allowing those systems to reference past card transactions. Which control meets the requirement most directly?
  • A Encrypt the PAN column with TDE
  • B Replace the PAN with a vault-backed token; share only the token with downstream systems
  • C Mask the PAN to show only the last four digits in reports
  • D Hash the PAN using SHA-256 before writing to the warehouse

Correct: B. Tokenization replaces the PAN with a random value that has no mathematical relationship to the original. Systems that never see the real PAN fall out of PCI scope, which is the specific business goal stated.

A wrong: TDE still leaves the PAN accessible to queries, so downstream systems remain in scope. C wrong: masking is a display-layer control and does not change the stored data, so scope is unchanged. D wrong: hashing is one-way; reporting would lose the ability to correlate transactions to a customer, which defeats the use case (and PCI still treats truncated or hashed PANs carefully).

Source: CompTIA SY0-701 Objectives v5.0 — 3.3 Data Protection

Practice Question 3 of 3
An EU-based customer demands written assurance that their personal data will remain subject to EU privacy law. Which statement best reflects the Security+ distinction between data sovereignty and data locality?
  • A Storing data in a Frankfurt region guarantees it is governed only by EU law
  • B Locality is the physical storage location; sovereignty is the legal regime that applies, and the two can require separate controls and agreements
  • C Sovereignty only applies to government data; commercial data uses locality rules
  • D Both terms refer to the same concept and can be used interchangeably

Correct: B. The Security+ objectives treat locality and sovereignty as related-but-distinct: where data is vs. what law applies. Parent-company jurisdiction, cross-border transfer mechanisms, and customer nationality can all add obligations beyond the physical region.

A wrong: region placement is necessary but not sufficient — cross-border access by staff or parent-company law can still trigger other regimes. C wrong: sovereignty applies broadly, including to commercial data. D wrong: the exam explicitly distinguishes the terms.

Source: CompTIA SY0-701 Objectives v5.0 — 3.3 Data Protection

Disclaimer: This content is provided for educational and exam preparation purposes only. It is not official CompTIA content, is not endorsed by CompTIA, and does not guarantee exam success. All practice questions are original and based on the published CompTIA SY0-701 Exam Objectives (v5.0). Always refer to the official CompTIA Security+ Exam Objectives as your primary reference.