CompTIA SY0-701: Data Security, Privacy & Cryptography — Study Guide

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Part of the CompTIA Security+ SY0-701 — Complete Study Guide. Practice with verified answers in the CompTIA exam hub, or take timed practice tests on ExamRoll.io.

Data is the ultimate target of most attacks, and cryptography is the primary technical mechanism for protecting it in transit, at rest, and in use. Understanding the properties, limitations, and correct application of cryptographic primitives is foundational — not just for the exam, but for designing systems that remain secure when individual controls fail.

Data Classification and Handling

Data classification assigns sensitivity labels that drive handling requirements. Government frameworks use Unclassified, Confidential, Secret, and Top Secret. Commercial frameworks typically use Public, Internal, Confidential, and Restricted (or equivalent). Classification must be driven by the data’s sensitivity and regulatory obligations, not by convenience.

Data Loss Prevention (DLP) systems enforce handling policies by inspecting content at endpoints, network egress points, and cloud storage. A DLP rule might block email attachments containing 16-digit strings matching credit card patterns, or alert when a user uploads a file containing the phrase “acquisition target” to a personal cloud storage service. DLP effectiveness depends on accurate classification — if sensitive data is not labeled, DLP cannot protect it.

Data sovereignty concerns where data physically resides and which jurisdiction’s laws apply. GDPR requires that EU personal data transferred outside the EU be protected by adequacy decisions, Standard Contractual Clauses, or Binding Corporate Rules. Organizations operating globally must map data flows and ensure that storage and processing locations comply with applicable regulations.

Encryption in Transit and at Rest

TLS 1.3 is the current standard for encrypting data in transit. It eliminates weak cipher suites, mandates forward secrecy (ephemeral Diffie-Hellman key exchange), and reduces the handshake to one round trip. TLS 1.0 and 1.1 are deprecated; TLS 1.2 remains acceptable but should be configured with strong cipher suites. An Nginx configuration enforcing current standards:

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

Encryption at rest protects data on storage media. Full-disk encryption (BitLocker, FileVault, LUKS) encrypts the entire volume; file-level encryption (EFS, VeraCrypt containers) encrypts individual files. Database-level encryption (Transparent Data Encryption in SQL Server and Oracle) encrypts data files and backups. The critical nuance: encryption at rest protects against physical media theft but does not protect against a compromised application that has already decrypted the data to process it.

Cryptographic Primitives

Symmetric algorithms (AES-128, AES-256, ChaCha20) use one shared key and are fast, suitable for bulk data. Asymmetric algorithms (RSA, ECDSA, Ed25519, ECDH) use key pairs and enable key exchange, digital signatures, and identity binding, but are computationally expensive. Hybrid systems — such as TLS — use asymmetric cryptography to negotiate a symmetric session key, then encrypt bulk traffic symmetrically.

Hashing (SHA-256, SHA-3) is a one-way function producing a fixed-length digest. Hashes are not encryption: they cannot be reversed with a key because there is no key. Salted password hashes (using bcrypt, scrypt, Argon2, or PBKDF2) add a per-user random value to defeat rainbow tables. Hashes provide integrity verification; HMAC combines a hash with a secret key to provide both integrity and authenticity.

Cipher modes matter as much as the algorithm. AES in ECB mode encrypts each block independently, producing identical ciphertext for identical plaintext blocks — a catastrophic property that leaks data patterns. AES-GCM (Galois/Counter Mode) provides both confidentiality and integrity in a single pass and is the standard for modern protocols. CBC mode with proper padding and an HMAC is acceptable but more complex to implement correctly.

Key Management and Storage

Cryptography is only as strong as its key management. Keys must be generated with strong entropy, stored separately from the data they protect, rotated on a schedule, and destroyed when retired. Hardware Security Modules (HSMs) provide tamper-resistant key storage and cryptographic acceleration. A Trusted Platform Module (TPM) is a chip on endpoints that stores keys used by BitLocker and measured boot. Key escrow places a copy of keys with a trusted third party for lawful recovery, while key recovery agents allow enterprises to decrypt employee data when necessary. Cloud KMS services (AWS KMS, Azure Key Vault, Google Cloud KMS) offer envelope encryption, where a data encryption key (DEK) protects data and is itself encrypted by a key encryption key (KEK) held in the HSM.

Public Key Infrastructure

PKI binds identities to public keys through certificates issued by a Certificate Authority (CA). A subordinate CA chains up to a root CA whose certificate must be pre-trusted. The certificate lifecycle begins with a Certificate Signing Request (CSR) generated alongside a private key:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

The CA validates the requester, signs the CSR, and issues an X.509 certificate. Revocation is published through Certificate Revocation Lists (CRLs) — periodically downloaded lists of revoked serial numbers — or Online Certificate Status Protocol (OCSP) responders that answer per-certificate queries in real time. OCSP stapling lets the server present a recent, signed status during the TLS handshake, avoiding client-to-CA lookups. Certificates expire and must be renewed; automation via ACME (Let’s Encrypt, internal ACME servers) prevents outages from lapsed certificates.

Code Signing and Integrity Validation

Code signing uses a developer’s private key to sign a software artifact; recipients verify the signature with the developer’s certificate, confirming both integrity and origin. This protects against supply-chain tampering. File integrity monitoring tools (Tripwire, AIDE) and hash publication (sha256sum values alongside downloads) similarly detect unauthorized modification, but hashing alone proves only that the file matches a value — it does not authenticate who produced that value. Only a digital signature, backed by PKI, provides both integrity and non-repudiation.

Retention, Sanitization, and Secure Disposal

Retention policies define how long each data class must be kept and when it must be deleted. Regulations often mandate both minimums (financial records for seven years) and maximums (personal data retained no longer than necessary). Backups are not exempt: if a subject exercises a right to erasure, the organization must have a defensible process for removing that data from backups or documenting the technical constraints and compensating controls. Legal holds override normal retention and freeze data during litigation.

When media reaches end of life, sanitization must match the data’s sensitivity and the medium’s disposition. NIST SP 800-88 defines three levels: Clear (logical overwrite, sufficient for reuse within the organization), Purge (cryptographic erase, block erase, or degaussing, sufficient for reuse outside), and Destroy (shredding, disintegration, incineration, pulverization). Cryptographic erasure — destroying the encryption key so ciphertext becomes unrecoverable — is fast and effective for self-encrypting drives being repurposed. Degaussing renders magnetic media unusable and does not work on SSDs. Physical destruction is the only assured method for damaged media or the highest classifications.

Practical Scenario: Key Management Failure Leading to Breach

A SaaS company encrypted its customer database using AES-256, but stored the encryption key in a plaintext configuration file in the same repository as the application code. When a developer accidentally pushed the repository to a public GitHub account, an automated credential-scanning bot discovered the key within 11 minutes. The attacker used the key to decrypt a database backup that had been stored in a publicly accessible S3 bucket (a separate misconfiguration). The encryption was technically correct — AES-256 is unbreakable by brute force — but the key management was catastrophically flawed. Proper key management would have stored the key in a secrets manager (AWS Secrets Manager, HashiCorp Vault) with access controlled by IAM roles, never in source code or configuration files.

← Cloud · All domains · Business Continuity →

Practice these questions → · Timed practice on ExamRoll.io →