How to know what data you hold, hold less of it, encrypt what remains under keys you actually control, and get your cryptography off algorithms that have a published expiry date.
Who needs this: CISO, Data Protection Officer, Head of Infrastructure, Platform and Cloud Engineering leads, Legal Liaison, Enterprise Architect | Read time: 22 min | Maps to: CSF 2.0 IDENTIFY (ID.AM, ID.RA), PROTECT (PR.DS, PR.AA, PR.PS), GOVERN (GV.PO) | CIS Controls 3, 11 | ISO/IEC 27001:2022 A.5.9–A.5.11, A.5.28, A.8.13
Fellow defenders, let's start with the part of the Equifax breach nobody puts on a slide. The Struts vulnerability gets the headlines. The expired certificate that blinded traffic inspection for the entire breach window gets an honourable mention. But buried in GAO's report is the sentence that should keep every data owner awake: attackers "gained access to a database that contained unencrypted credentials for accessing additional databases" (GAO-18-559). One foothold, one plaintext credential store, and the blast radius stopped being a dispute portal and started being 148 million people. GAO also notes the databases were not isolated from each other, and that nobody rate-limited the roughly 9,000 queries the attackers ran on the way out.
That is what a data-security failure actually looks like. Not a broken cipher. A pile of data nobody had catalogued, sitting next to the keys to more data nobody had catalogued, with no boundary between them and no counter watching the door.
Meanwhile a second, quieter clock is running. The joint advisory on Salt Typhoon (AA25-239A, 27 August 2025, issued by agencies in thirteen countries) describes state actors sitting on telecom backbone and provider-edge routers across 600+ organizations in 80 countries, active since at least 2019, persisting via added SSH authorized keys and log clearing (CISA AA25-239A). That is not a data-theft campaign in the ordinary sense. That is a collection position — precisely what "harvest now, decrypt later" requires. Traffic you protected with RSA and ECC in 2026 can be copied today and read whenever the mathematics catches up.
So this chapter runs two clocks. The breach clock, which starts when someone reaches your data and ends in a regulator's inbox. And the quantum clock, which started years ago, has published deadlines attached, and does not care whether you noticed. Both are answered by the same unglamorous asset: an inventory of what you hold, where it lives, how long it must stay secret, and which key protects it. Everything else here is built on that one table.
Most classification programs die the same death. Someone designs seven tiers with beautiful handling rules, ships a 40-page policy, runs an awareness campaign, and eighteen months later almost everything is labeled "Internal" because that is the default and nobody can tell tier 3 from tier 4 at 4:55pm on a Friday. The scheme was not wrong. It was unusable, which is the same thing.
A classification scheme is a control interface, not a taxonomy. Every tier you add is a decision you are asking a non-security employee to make correctly, forever, without training you will not fund. Three tiers is the number that survives:
| Tier | Plain-language test | Default handling |
|---|---|---|
| Public | Already published, or we would not care if it were | No controls beyond integrity |
| Internal | Ordinary business data; embarrassing but not damaging if leaked | Authenticated access, at-rest encryption, no external sharing by default |
| Restricted | Loss triggers a legal, contractual, safety or existential consequence | Named-owner access, logged access, encryption with a customer-managed key, no copies outside approved stores, egress monitored |
Then stop adding tiers, and add two orthogonal fields instead — because the things people actually need to know about a data set are not a single axis:
Discovery has to come first, and it is where the budget argument shows up. Enterprise data-discovery platforms are genuinely useful and genuinely expensive. If you cannot buy one this year you are not excused from knowing what you hold — you are just doing it in a different order. The cheap version:
StartResourceScan API or the console Rescan link (IAM Access Analyzer).Actionable takeaway: Ship a three-tier scheme plus a regulatory flag and a confidentiality-lifetime field this quarter, and require the lifetime number on every Restricted data set before you accept the inventory as complete. If a data owner cannot say how many years their data must stay secret, they do not yet own it.
Every record you keep is a record you can lose. That sounds obvious and is almost never applied, because storage is cheap and deleting things requires someone to take responsibility for deleting things. So the analytics team keeps a full copy of production in a warehouse "for now," a data scientist snapshots it into a notebook, a vendor integration replicates it into a SaaS platform, and the record you collected once now exists in six places under four different key policies. Not every database needs to be one misconfigured bucket away from disaster, and most of them are only there because nobody ever said no.
Minimization is the cheapest control in this book. It costs engineering time and political capital, not license fees.
Compartmentalization is minimization's twin, and Equifax is the case study: databases that were not isolated from each other let attackers reach far beyond the system they had actually compromised, and no rate limiting meant roughly 9,000 queries drew no alarm (GAO-18-559). The controls that would have changed that are boring and mostly free:
| Control | What it stops | Cheap version |
|---|---|---|
| Separate credentials per data store, never shared | One compromise becoming all compromises | Distinct DB users per application, no shared service account |
| Network path restricted to the applications that need it | Lateral reach from a compromised web tier | Security-group or firewall rules by application, denied by default |
| Query-volume and bulk-export alerting | Mass exfiltration looking like normal use | Alert on row counts above a fixed threshold per role, per hour |
| Separate cloud account/subscription/project per trust domain | Blast radius crossing an IAM boundary | One extra account for the crown-jewel store; the account is free |
The bulk-export alert deserves a note, because it is the control that would have fired at Equifax and it costs nothing but a threshold. Pick the highest legitimate export volume any role performs in a normal month, set the alert at that number, and route it to a human. You will tune it twice and then it will sit there quietly being worth every minute.
Actionable takeaway: Pick your single most sensitive data store and, within 30 days, give it its own credentials, its own network path, and a bulk-read alert with a numeric threshold. Then repeat on the next one. Compartmentalization is done one store at a time or it is not done at all.
Data loss prevention has a reputation problem it partly earned. Deployed as a broad content-inspection dragnet across every channel, it generates an alert volume nobody can triage, blocks a legitimate business process in week two, gets moved to monitor-only "temporarily," and then sits there for four years producing a report that proves the license was purchased. If your DLP has been in monitor-only mode for more than two quarters, you own a very expensive logging product.
DLP works well in a narrow band and badly outside it, and the band is defined by two properties: the data has a recognisable structure, and the channel is one you control.
Where it works: structured identifiers with checksums — card numbers, social security and national insurance numbers, IBANs, medical record numbers — because the format validates and the false-positive rate stays low. Egress channels you own end to end: corporate email, managed endpoints, sanctioned SaaS via API-based inspection. And above all, blocking the accident, because the overwhelming majority of true positives are a well-meaning person attaching the wrong spreadsheet. Bulk downloads from a repository during someone's notice period are the other reliable win, though there DLP earns its keep as detection input rather than as a block.
Where it is theatre: against a determined insider who can encrypt, rename, retype, screenshot or photograph — assume defeat and rely on access control and monitoring instead. Against an external attacker holding valid credentials, because Mandiant's 2026 picture has operators moving through backups, identity services and virtualization planes in a recovery-denial pattern (M-Trends 2026); exfiltration in that world rides your own approved tooling, from a machine identity, on a path DLP was configured to trust. Against unstructured intellectual property — designs, source code, strategy documents — where regex has nothing to match and label-driven policy is the only workable approach, which loops straight back to classification. And on any channel you do not terminate: personal devices, personal cloud, a phone camera.
Tuning is where the program lives or dies, and the sequence matters:
| # | Step | Why the wrong order fails |
|---|---|---|
| 1 | Run in monitor-only against one channel and one data type | Enabling everything at once makes it impossible to attribute noise to a rule |
| 2 | Measure the true-positive rate for two full business cycles | Month-end, payroll and quarter-close generate legitimate bulk movement that looks exactly like exfiltration |
| 3 | Fix the business process the rule keeps catching | If Finance emails a spreadsheet of account numbers every month, a DLP rule will not stop them — it will teach them to use personal email. Give them a sanctioned path first |
| 4 | Move that one rule to block, with a documented self-service exception path | Blocking without an exception path guarantees an executive override that becomes permanent |
| 5 | Only then add the next data type | Each rule pair must be independently measurable |
The exception path in step 4 is not a weakness, it is the control that keeps the block enabled. A user who can justify and unblock their own transfer in 30 seconds — with that justification logged and reviewed — will use the sanctioned channel. A user who must file a ticket and wait a day will find another way, and you will have lost both the block and the visibility.
Actionable takeaway: If your DLP is in monitor-only mode, pick the single highest-confidence rule you have, fix the business process behind its most frequent hit, and move that one rule to block within 60 days. One enforcing rule is worth a hundred observing ones.
Encryption at rest gets bought for the wrong reason and then relied on for the wrong threat, so let me be blunt about what it does.
It protects against physical media loss, a decommissioned disk, a stolen laptop, a snapshot copied somewhere it should not be, and a cloud provider employee with storage-layer access. All real, all worth defending.
It does not protect against an attacker with a valid credential, ransomware, SQL injection, or a compromised service account reading through the application's own decryption path. In every one of those the platform decrypts the data for the attacker exactly as designed, because to the storage layer the attacker is an authorized caller. If your data-protection strategy is "the database is encrypted at rest," you have defended against the theft of a hard drive from a data centre you cannot physically enter anyway.
Where at-rest encryption does pay disproportionately is the legal aftermath, and this is the argument that funds it. GDPR Article 34 removes the obligation to notify data subjects where the data was rendered unintelligible — strong encryption is the named example (Art. 33/34 GDPR). HIPAA's breach clock runs on unsecured PHI (HHS). Most US state statutes carry an encryption safe harbour, and the FCC's telecom rules carry a harm-based exception where the carrier reasonably determines no harm is likely, with encrypted data as the example. Those safe harbours are conditional and fact-specific and Chapter 15 owns the mechanics, but the direction is unambiguous: encrypted-and-key-not-compromised is a materially different regulatory event from plaintext.
Enforce TLS everywhere, including inside the perimeter, and do not accept "it's internal" as an exemption — Salt Typhoon's business model was sitting on the routers between your endpoints. Then take Equifax's other lesson: an expired certificate meant traffic was not being inspected throughout the entire breach (GAO-18-559). Certificate expiry is not a hygiene issue, it is a detection outage. Every certificate is an asset with an owner and an expiry alert, and every inspection point that depends on one is monitored for silence — a decryption point that stops producing events is an incident, not a quiet day.
This is the question executives should be asking and usually are not, because the answer determines what happens in two very specific situations: a ransomware event, and a subpoena served on your provider.
| Model | Who can decrypt without you | Ransomware relevance | Subpoena relevance |
|---|---|---|---|
| Provider-managed keys | The provider, operationally | None — attacker uses your credentials anyway | Provider can be compelled to produce plaintext; you may not be notified |
| Customer-managed key in provider KMS | Provider, if compelled, but with your key policy and access logs in the picture | Key policy can deny a compromised principal; key access is logged evidence | Provider still holds the key material; your policy and audit trail are yours |
| Customer-held key material (BYOK / external HSM) | Nobody but you | You can revoke access to the key and render a stolen snapshot useless | Provider genuinely cannot produce plaintext; the process comes to you |
| Client-side / end-to-end encryption | Nobody but you | Strongest; provider-side compromise yields ciphertext | Provider cannot produce plaintext |
The custody question has a hard operational edge too. AWS documents it plainly for forensics: if a snapshot is encrypted, sharing it across accounts requires sharing the customer-managed KMS key as well, not just the snapshot (AWS forensic environment strategies). Teams discover this at T+3h, while the forensics account stares at an unreadable volume. Rehearse the cross-account evidence path before you need it — Chapter 13's evidence discipline meeting Chapter 6's cloud boundary.
And the recovery edge, which is Chapter 12's territory but belongs on your key inventory: if your backups are encrypted with a key held in the environment you are recovering from, you do not have backups. The hardened-repository principle generalises — the credentials and keys protecting the recovery path must live in a separate trust domain from the production identity plane.
Actionable takeaway: Produce a one-page key custody table for your top five data stores — key type, who can decrypt, where the key material lives, who can change the key policy, and whether the recovery path depends on it. If any row says "we would have to ask the provider," you have found this quarter's project.
The Equifax detail from the opening — attackers reaching a database of unencrypted credentials for other databases — is not history. It is the dominant escalation pattern in modern intrusions, and the last two years made it worse, because the secrets are now harvested by automation at ecosystem scale.
The Nx "s1ngularity" compromise (August 2025) is the clearest demonstration: malicious package versions detected locally installed AI developer CLIs and invoked them with permission-bypassing flags to enumerate secrets across the filesystem, harvesting 2,349 credentials from 1,079 developer systems; a second wave used the stolen GitHub tokens to flip private repositories public (GitGuardian; The Hacker News). Shai-Hulud (npm, September 2025) went further — a self-replicating worm harvesting secrets from CI/CD pipelines and cloud metadata endpoints, exfiltrating through attacker-created repositories and republishing itself under compromised maintainer accounts, which drew a CISA alert (CISA; Unit 42). And the Trivy → LiteLLM chain (March 2026) showed the transitive version: a backdoored GitHub Action stole PyPI publishing tokens, which shipped a poisoned package, which harvested credentials, moved laterally across Kubernetes clusters and installed a persistent backdoor — across five ecosystems in five days (Resecurity).
Read those three together and the rule falls out: a long-lived secret written to disk anywhere in your build or developer estate should be assumed harvestable. The controls, in the order they pay off:
| # | Control | What it removes |
|---|---|---|
| 1 | Eliminate long-lived static credentials in favor of short-lived, workload-bound identity (OIDC federation for CI, instance/pod identity for workloads) | The thing being harvested. Nothing else on this list matters as much |
| 2 | Every remaining secret lives in a managed secret store, injected at runtime, never in an image layer, environment file, repository or ticket | The filesystem enumeration path |
| 3 | Pre-commit and CI secret scanning, plus a scan of full repository history | The credential committed in 2019 that still works |
| 4 | Automated rotation with a measured, tested rotation time per secret class | The window between exposure and revocation |
| 5 | Metadata-endpoint hardening on every compute workload | The cloud credential path Shai-Hulud specifically targeted |
| 6 | Access logging on the secret store, alerting on a principal reading a secret it has never read before | Detection, when 1–5 have failed |
Two sequencing rules that teams get wrong under pressure:
Actionable takeaway: Run a full-history secret scan across every repository you own this month, and treat every hit as live until someone confirms revocation at the issuing system. Then set the target that actually fixes the class: no static long-lived cloud credentials in CI by the end of the year, replaced by OIDC federation.
Here is the part people file under "2030 problem" and should not.
The strategy is exactly what it sounds like: collect encrypted traffic and encrypted data today, store it, and decrypt it when a cryptographically relevant quantum computer exists. What makes it a today problem is not a prediction about quantum computing — it is arithmetic about your data. Anything with a long confidentiality lifetime that crosses a network today is at risk from a machine that does not exist yet (Palo Alto Networks). And the collection position is not hypothetical: six hundred organizations across eighty countries, telecom backbone and edge routers, persistence since at least 2019 (CISA AA25-239A). Someone is already doing the "harvest" half. That is the entire argument.
Vendors are already selling "quantum-safe" everything. The defense against that is knowing the actual document numbers, because a product that cannot tell you which FIPS it implements is not implementing one.
| Standard | Algorithm | Purpose | Status |
|---|---|---|---|
| FIPS 203 | ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism; formerly CRYSTALS-Kyber) | Key establishment | Finalized August 2024 |
| FIPS 204 | ML-DSA (Module-Lattice-Based Digital Signature Algorithm; formerly CRYSTALS-Dilithium) | Digital signatures | Finalized August 2024 |
| FIPS 205 | SLH-DSA (Stateless Hash-Based Digital Signature Algorithm; formerly SPHINCS+) | Digital signatures, hash-based backup | Finalized August 2024 |
| FIPS 206 (draft) | FN-DSA (formerly FALCON) | Digital signatures | Not yet finalized |
| HQC | Hamming Quasi-Cyclic | Backup KEM on different mathematics | Selected March 2025 as a fourth-round backup KEM; standardization ongoing — not a finalized FIPS |
(NIST Post-Quantum Cryptography project)
The deprecation frame matters as much as the new algorithms. NIST IR 8547 sets RSA-2048 and ECC-256 as deprecated by 2030 and disallowed after 2035, with NIST intending to remove quantum-vulnerable algorithms from its standards by 2035 (NIST PQC project). Translation for the board: the cryptography in most of your estate has a published end-of-life, and it is closer than the depreciation schedule on the hardware running it.
This is the calculation that turns PQC from a philosophy debate into a prioritized backlog, and it needs three numbers per data set:
If L + M exceeds the years remaining until Q, that data set is already exposed and belongs at the top of the migration queue.
Worked examples, using a 2035 planning horizon (nine years from 2026):
| Data set | L (years) | M (years) | L + M | Verdict |
|---|---|---|---|---|
| Genomic or biometric records | 50+ | 3 | 53 | Exposed now. Migrate first; consider whether it should be crossing a network at all |
| Long-term commercial contracts, M&A files, litigation archives | 20 | 2 | 22 | Exposed now. Priority tier |
| Signing keys for firmware with a 15-year field life | 15 | 4 | 19 | Exposed now, and worse — a forged signature is an integrity failure, not just a confidentiality one |
| Patient records under long retention | 25 | 3 | 28 | Exposed now. Priority tier |
| Employee PII held for statutory retention | 7 | 2 | 9 | At the line. Plan it into the normal cycle |
| Session tokens, ephemeral API traffic | <1 | 2 | 3 | Low priority for confidentiality; still migrates on the platform's schedule |
Two things fall out of that table. First, long-lived signing keys are a bigger near-term problem than most confidentiality data, which is why CNSA 2.0 puts software and firmware signing first: a device you ship in 2027 that trusts an ECC-256 signing key for fifteen years is a forgery waiting for the mathematics. Second, M dominates for exactly the systems you least want to touch — OT, embedded, appliances, anything where the vendor controls the crypto stack. That conversation starts with procurement, not engineering, which is Chapter 11's territory.
Sequence is content here. Every organization that skips a step ends up repeating it.
| # | Phase | What "done" looks like | Why it must come first |
|---|---|---|---|
| 1 | Cryptographic inventory | A queryable list of every place you use cryptography: TLS endpoints and their negotiated suites, certificates and their issuing chains, code and firmware signing keys, VPN and SSH configurations, database and storage encryption, HSM and KMS key inventories, embedded libraries in your own applications, and the crypto your vendors use on your behalf | You cannot migrate what you cannot enumerate, and every subsequent decision is a prioritization decision that needs this list as input. This is the NCSC's 2028 milestone |
| 2 | Crypto-agility | Algorithms are configuration, not code. A cipher change is a deployment, not a project. Certificate lifecycle is automated. No algorithm identifier is hard-coded in an application you own | If you migrate to ML-KEM without agility, you have bought one migration and will pay full price again for the next one. HQC exists precisely because NIST expects the backup to be needed |
| 3 | Prioritize by data lifetime | The L + M calculation run across the inventory, producing an ordered backlog with owners and dates | Prioritizing by "what's easy" migrates your web front end and leaves the twenty-year archive on RSA |
| 4 | Migrate, highest exposure first | Key establishment before signatures for confidentiality-driven risk; signing keys first where integrity and long device life dominate | HNDL only threatens confidentiality. Signature forgery needs the quantum computer to exist, which buys time — but only where the key's lifetime is short |
| 5 | Verify and attest | Evidence that the negotiated algorithms in production match the policy, continuously, not at a point in time | Configuration drifts, and a fallback path that silently negotiates the old suite is the default failure mode |
Ask your architecture team a simple question: where do we use RSA? Most organizations cannot answer it, and the inability is the finding. Not because anyone was negligent — because cryptography was implemented once, per system, by whoever built that system, over twenty years, and nobody was ever asked to keep a list.
That inability is what makes the 2030 and 2035 dates hard. The algorithms are standardized and the libraries exist. The expensive part is finding all the places, and then discovering that changing an algorithm requires a code change, a vendor release, a regression cycle and a change window — per system, times four hundred systems.
Crypto-agility converts every future cryptographic transition from a program into a deployment. Concretely, in your own code and platforms:
For a small organization with no architecture function, the cheap version is one spreadsheet and one question. The spreadsheet lists every system, its vendor, its TLS endpoints and its certificates. The question, added to every renewal and every new purchase from today: "State your product's roadmap for FIPS 203, 204 and 205 support, with dates." You will be astonished how much inventory arrives in the replies, and how quickly the vendors with no answer identify themselves.
Actionable takeaway: Start the cryptographic inventory this quarter, and put the vendor PQC question into your standard procurement template this week. Not next budget cycle. This week. The inventory is due in 2028 under NCSC's timeline and it is the longest-lead item in the entire migration.
Retention is a data-security control wearing an accounting costume. Data you deleted on a documented schedule cannot be breached, cannot be discovered, and does not appear in a notification count.
"Defensible" means three things: a written schedule derived from legal and business requirements rather than storage cost; consistent execution, so deletion is automatic and not discretionary; and evidence that both were true. The failure mode is not deleting too much — it is deleting inconsistently, which looks exactly like spoliation to opposing counsel.
Which is why the ordering rule below is not negotiable:
The two instruments worth knowing by name:
s3:PutObjectLegalHold (S3 Object Lock). Two traps: holds and retention apply to object versions, so they do not prevent new versions or delete markers being created; and Governance mode is not immutability — it is overridable by a principal with s3:BypassGovernanceRetention, and the S3 console sends that header by default. Governance mode plus a console-capable admin equals no protection at all. Compliance mode is what you want for evidence; Chapter 12 covers the backup-immutability implications.Three practices make retention defensible rather than aspirational. A schedule per data class signed by Legal with the statutory basis cited per line, because "seven years because Finance said so" does not survive a deposition. Automated, logged deletion, because a manual process is a discretionary one and discretion is what plaintiffs' counsel attacks. And a tested hold-release process, because holds that are never released turn a retention schedule into an indefinite one — and every extra year of retention is another year of breach exposure and another year of confidentiality lifetime you are quietly extending, which, per the arithmetic above, is also a post-quantum decision.
Actionable takeaway: Get a signed retention schedule with a statutory basis per line, automate the deletion, and run one hold-and-release drill a year against a real data store. If nobody has ever released a hold, you do not have a retention program — you have an archive.
[IG1] [ID.AM] [CIS 3][IG1] [ID.AM] [CIS 3][IG2] [PR.DS][IG1] [PR.DS] [CIS 3][IG2] [PR.DS][IG2] [PR.AA] [PR.DS][IG2] [DE.CM] [CIS 3][IG2] [PR.DS][IG2] [PR.DS][IG2] [PR.DS][IG2] [PR.DS][IG1] [PR.DS] [DE.CM][IG2] [PR.AA][IG1] [PR.AA] [CIS 3][IG3] [DE.CM] [CIS 8][IG2] [ID.AM] [PR.DS][IG2] [ID.RA][IG1] [GV.SC][IG3] [PR.PS][IG2] [PR.PS][IG3] [PR.PS] [GV.SC][IG1] [GV.PO][IG2] [GV.PO] [PR.DS][IG3] [PR.DS] [A.5.28][IG2] [A.5.28] [RS.MA]Know what you hold, hold less of it, and be able to say out loud where every key lives. Then go start the crypto inventory — because 2035 is not a deadline for the algorithms, it is a deadline for you finding them. Stay classified, stay compartmentalised, and stay ahead of the math.