Leadership asks you to encrypt all sensitive data with symmetric encryption. Since the application must hold the key in order to use the data, explain what threats this actually removes, what it does not, and how you would decide where the encryption boundaries go.

## The reframe 'Encrypt everything sensitive' sounds like a security control. It is really a *relocation*: after encryption, reading the data requires the key, so the confidentiality of the data is exactly the confidentiality of the key plus the trustworthiness of everything that can invoke decryption. If the key is reachable from the same place the data is reachable, nothing changed except CPU cost and operational complexity. So the first question in any such conversation is not 'which cipher' but 'which principal must be unable to read this, and is the key outside that principal's reach?'. ## What it genuinely removes There is a real and valuable class of attacker who obtains bytes without obtaining the key: - **Storage-layer exposure**: stolen or improperly decommissioned drives, a misconfigured object store, a cloud snapshot shared too widely. - **Backups and copies**: backup files travel further and live longer than anyone intends, and they are frequently restored into less protected environments. - **Replicas and exports**: the analytics copy, the data-warehouse feed, the anonymised set that was not anonymised. These are typically read by systems that were never in scope for the original authorisation model. - **Lower-privileged principals inside the system**: a database account, a DBA, a support tool or an operator that can read rows but was never granted key use. This is where field-level encryption earns its keep, because it splits 'can read the store' from 'can read the value'. - **Accidental disclosure**: crash dumps, debug logs, an error page. If the field was encrypted at the boundary, the accident leaks ciphertext. Note the shape: every item is an attacker who is *outside* the decrypting process. ## What it does not remove - **Compromise of the decrypting process.** If an attacker runs code in the application, it has the application's identity and can call the same decrypt path. The key being in a hardware module does not help - the module is happy to serve the authorised caller. - **Flaws in the application's own read path.** An authorisation bug or an injection that reaches the app's legitimate query surface produces decrypted data, because the app decrypts on the way out. Encryption is orthogonal to authorisation. - **Credential theft against the key service.** If the app's credentials or role can be assumed, so can its decryption ability. The key service boundary is only as strong as the identity that crosses it. - **Inference from ciphertext.** The moment you require equality search or an index over an encrypted column, you need deterministic encryption for that column, and deterministic ciphertext leaks equality and frequency: which rows share a value, and how the values are distributed. On low-cardinality fields that is often enough to recover the plaintext by frequency alone. This is a real trade, not a bug, and it must be made explicitly. ## The decision method For each dataset, in order: 1. **Name the adversary you are excluding.** Concretely: 'someone with the backup', 'the analytics team', 'the DBA', 'a compromised app instance'. Vague answers produce vague designs. 2. **Place the key outside that adversary's domain.** If the adversary is the storage layer, keys held by the application suffice. If the adversary is the application operator, the key must belong to the customer or to a separate service the operator cannot invoke. If the adversary is the application process itself, encryption is the wrong control and you need the data not to be there: tokenisation, where the app holds only a surrogate and a separate vault holds the mapping, or client-side encryption where the key never reaches your infrastructure at all. 3. **Rank the work** by sensitivity multiplied by reachability multiplied by whether custody separation is achievable. A high-sensitivity field whose key must live in the app is a poor investment compared with a moderate field where custody can genuinely be split. 4. **Choose the key scope.** One key per tenant, per dataset or per record changes what a single leak costs and whether you can perform a per-tenant crypto-shred. One key for everything is the version of this project that gets shipped by default and is worth almost nothing. ## The control ordering The usual ranking applies, weakening from guarantee to heuristic. **Structural separation** is strongest: the key never exists in the compromised domain - client-side keys, a separate service with its own identity boundary, hardware that never exports material. Next, **transformation**: wrapping, tokenisation and surrogates, which reduce what the compromised domain holds but do not eliminate its access to the mapping. Next, **validation**: policy on who may call which key operation on which data, which is enforcement by rules that can be misconfigured or bypassed by an authorised-but-compromised caller. Last, **detection**: audit trails, anomaly detection and rate limits on the decrypt path, which do not prevent anything but make sustained bulk decryption visible. When custody cannot be separated, the detection rung is what you are actually buying, and it should be described that way rather than dressed up as prevention. ## The costs you must state Encryption is not free, and a serious answer names the bill: keys have a lifecycle that someone must own; the key service becomes an availability dependency, so its outage becomes your outage and you need caching and failure policy; searching, sorting and indexing on encrypted fields is lost or degraded, and restoring it via deterministic encryption reintroduces leakage; and broad mandates typically produce one key used everywhere, which delivers the operational cost of the programme with none of the separation that justified it.