Mitigations for Missing Encryption of Sensitive Data are to encrypt sensitive information in transit and at rest wherever it is stored, processed or transferred. Protect keys separately, classify data so requirements are clear, and verify that backups, exports and replicas are covered. Review exceptions because unencrypted copies often appear in overlooked systems.
Where Missing Encryption Shows Up First
Encryption gaps are rarely limited to a single database table or a single application boundary. They usually appear where data moves, not where teams think of it as “stored”, such as backups, exports, replicas, file shares, object storage, logs, queues, and temporary processing areas. That is why the safest mitigation is to treat encryption as a property of the data flow, not just the primary system.
In practice, that means covering information in transit and at rest wherever it is stored, processed, or transferred, then checking whether exceptions are already hiding in adjacent systems. For storage-heavy environments, a broader Database Security Guide can help teams review encryption alongside backups, authentication, and hardening so the control is not applied only to the live database.
Encryption also fails when teams assume one control tier covers every copy. A production volume may be encrypted while a report export, analytics extract, or disaster-recovery replica remains plaintext. That is why classification matters: if sensitivity is not clearly labelled, encryption requirements drift into best-effort language and exceptions start multiplying.
Protecting Keys, Copies, and Recovery Paths
Encrypting data only helps if the key management model is separated from the data path. If the same environment or team that stores the sensitive data also exposes the keys too broadly, encryption can become little more than obscurity. Key custody, rotation, and access boundaries matter because the compromise of the key can expose every protected copy at once.
Recovery paths deserve equal attention. Backups, snapshots, archives, and disaster-recovery replicas often sit outside the main application workflow, which makes them a common place for unencrypted copies to survive long after the primary system has been fixed. A practical control set should therefore verify encryption status for those secondary stores, not just the live service.
Teams that need deeper coverage of how encryption, secret custody, and data protection fit together should align this work with Encryption Guide and, where the concern is broader data sprawl and exposure, the Data Security Guide.
When organisations also use tokenisation or masking to reduce exposure, those techniques should be chosen deliberately rather than treated as interchangeable with encryption. They are often useful for specific business flows, but they do not replace encryption where confidentiality must remain intact across transport, storage, and replicas.
What Good Mitigation Looks Like in Operations
Good mitigation is visible in operations, not just in policy. Teams should be able to show that encryption requirements are embedded in provisioning standards, that exceptions are approved and time-bound, and that system owners can prove coverage across every place the data may land. The most useful evidence is not a policy statement, but an inventory of systems, copies, and controls that matches reality.
Operational checks should also include detection for plaintext leakage. If sensitive data appears in exports, debug logs, object storage, email attachments, or test environments, the problem is not simply a missing encryption setting, it is a broken data-handling path. For that reason, encryption work often pairs well with discovery and classification so teams know what must be protected before they start tuning controls.
Tokenisation and Data Masking Guide is useful when the mitigation goal is to reduce where cleartext appears, while Data Retention and Secure Deletion Guide helps prevent stale copies from surviving after they should have been removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-28 — Protection of Information at Rest | Directly addresses encrypting sensitive data stored in systems and backups. |
| SC-13 — Cryptographic Protection | Covers cryptographic protection for sensitive data in transit and at rest. | |
| IA-5 — Authenticator Management | Key custody and rotation are central when encryption depends on protected keys. | |
| Recommendation — Encrypt sensitive data at rest across all storage locations and replicas. Apply approved cryptography to protect sensitive data in transit and storage. Manage encryption keys and related authenticators separately from protected data. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Requires cryptographic controls for protecting information confidentiality. |
| A.8.13 — Information backup | Backups are a common place where unencrypted copies persist. | |
| Recommendation — Implement cryptography wherever sensitive information needs confidentiality protection. Verify backups are encrypted and covered by the same protection standard as primary data. | ||
Practitioner Guidance
What to verify: Confirm encryption coverage on every copy of the data, including backups, replicas, exports, logs, and test data. A control is not credible until the weakest storage path is checked, because that is where plaintext most often survives.
Decision rule: If a system can store or transmit sensitive data outside the main application path, require encryption by default and treat any exception as temporary, documented, and reviewable. If you cannot prove the handling of a copy, assume it is unprotected until validated.
What practitioners underestimate: The most common failure is not the lack of an encryption product, but the assumption that one encrypted system means the whole lifecycle is protected. Sensitive data usually becomes exposed through overlooked secondary systems and recovery artefacts.
Practitioner takeaway: The real test is whether sensitive data stays encrypted across every place it travels, not whether the primary system has an encryption setting enabled.
Related resources from NHI Mgmt Group
- Why does missing encryption create operational and regulatory risk for sensitive data platforms?
- What mitigations reduce the risk of Insertion of Sensitive Information Into Sent Data?
- How should teams reduce the risk of exposed AI credentials being abused?
- How should teams reduce risk from malicious npm package installs?