The Departed Analyst and the Orphaned Encryption Keys
A mid-size insurer's sole data-encryption analyst resigned abruptly. She personally held the only two copies of the KEK wrapping key: one on a hardware token in her desk drawer, one in a personal password manager. The token was recovered but its PIN was not documented. Data at rest in the claims warehouse (about 40 TB) is encrypted with DEKs wrapped by this KEK; backups exist but are also wrapped by the same KEK. The CISO wants to know whether the data is recoverable, what the immediate risk exposure is, and what governance failure allowed this. Legal has flagged that the warehouse contains PHI and a breach notification clock may start if confidentiality is assumed compromised. The board meets in 48 hours.
1. What is the immediate confidentiality and availability posture, and what should the CISO do in the next 48 hours?
Read the worked answer
Separate the two risks.
Availability: The KEK is not necessarily lost - the token exists and PIN recovery via the token vendor's escrow/reset process is plausible. The password-manager copy is unrecoverable (personal account). So availability is degraded but likely recoverable; this is not yet a confirmed data-loss event.
Confidentiality: The KEK was held in a personal, unmanaged store. That is an uncontrolled copy - you cannot assert it wasn't exposed. Treat confidentiality as potentially compromised until you can rule it out.
48-hour actions:
- Engage the token vendor for PIN reset/escrow - confirm whether recovery is possible before the board meeting; that single fact changes the narrative.
- Do not assume breach yet, but start the legal/privacy assessment against the notification standard (is the key exposure likely to result in unauthorized access?). Document the reasoning either way.
- Preserve evidence: token, logs of key use, the analyst's access records.
- If recovery fails, plan DEK re-encryption from plaintext sources where they exist (upstream systems) - map which data has a plaintext origin and which does not.
Key judgement: availability and confidentiality are different questions with different clocks. Don't let the breach-notification question force you to declare the data unrecoverable, and don't let the recovered token lull you into declaring confidentiality intact.
2. What governance failures does this reveal, and what controls would prevent recurrence?
Read the worked answer
Root-cause failures (map to controls):
- No key escrow / split knowledge: a single person was a single point of failure for a critical key. Fix: M-of-N key splitting or enterprise key management with documented recovery, held by the organization not an individual.
- Keys in personal stores: violates asset ownership and acceptable-use. Fix: managed secrets vault, no personal password managers for corporate secrets, technical blocking where feasible.
- No documented recovery procedure: the PIN wasn't recorded anywhere sanctioned. Fix: tested key-recovery runbook, exercised periodically.
- Single-person dependency (no separation of duties): Fix: at least two custodians, rotation, and succession coverage.
- No key inventory / lifecycle register: Fix: a KMS with inventory, rotation schedule, and custody records.
Framing for the board: this is a governance and availability failure more than a proven confidentiality breach. The corrective program (escrow, vaulting, runbook, dual custody) is the deliverable; the notification decision is a separate, evidence-driven call. Avoid conflating 'we had a bad process' with 'PHI was exposed.'
3. The recovered token's PIN is eventually reset and the KEK is confirmed intact. Does that close the matter?
Read the worked answer
No. Confirming the KEK is intact resolves availability but not the confidentiality question. The uncontrolled copy in the personal password manager still existed for an unknown period and may have been synced, exported, or breached. Because you cannot prove the personal copy was never exposed, the conservative position is that the KEK's confidentiality is unverified.
Therefore:
- Treat the KEK as potentially compromised and rotate it - rewrap the DEKs under a new KEK held under proper custody. This is cheap relative to the risk and converts an unknown into a known.
- Only after rotation can you credibly assert the data is protected.
- Document the decision: 'recovered ≠ uncompromised.' The exam-tested instinct is that restoring availability does not restore confidentiality; the two must be reasoned about independently.
Trap to avoid: declaring the incident closed because the data is readable again. Readable is the availability answer; trustworthy is the confidentiality answer.