Missing encryption of sensitive data is usually caused by default-off settings, implementation gaps, poor data classification, or systems that move data without applying protection. It also happens when teams assume a platform encrypts data automatically. Defenders should identify sensitive data flows, confirm encryption in storage and transit, and check that key management is actually enforced.
Why missing encryption usually happens
Missing encryption is rarely one single failure. More often, it is the result of default-off settings, an implementation that never reached completion, or a design choice that treated encryption as optional instead of part of the data path. It also shows up when teams move data between systems and assume the platform will protect it automatically.
The practical issue is that encryption has to be applied at the right points, to the right data, and with the right keys. If teams do not identify where sensitive data is created, stored, copied, exported, or transmitted, encryption gaps are easy to miss even in otherwise mature environments.
That is why encryption programs often fail at the boundary between architecture and operations. A design may call for protection, but the implementation is incomplete, a legacy system does not support it, or a downstream integration strips it away before the data reaches its next destination.
Where implementation gaps are most likely
Implementation gaps usually appear in data flows that cross system boundaries: database replication, ETL pipelines, message queues, file transfers, backup jobs, analytics exports, and application integrations. The data may be protected in one place and exposed in another because the control was only applied to the primary application, not the full path.
Classification failures are another common cause. If sensitive records are not labeled correctly, teams may encrypt only the most obvious stores and miss fields, exports, logs, caches, or test copies. This is why data discovery and flow mapping matter as much as the encryption technology itself.
In practice, this is also where guidance on storage, transit, and key custody becomes important. NHIMG’s Encryption Guide is useful when the question is not just whether encryption exists, but where it is actually enforced across the lifecycle of the data.
Why teams think they are protected when they are not
One of the most common causes is false assurance from the platform layer. Teams may see “encryption available” in a cloud service, database, or application stack and assume sensitive data is automatically covered. In reality, many controls depend on explicit configuration, correct deployment choices, and separate handling of keys, certificates, and application logic.
Another recurring pattern is that data is encrypted at rest but still exposed in transit, or protected in transit but left in cleartext in logs, exports, replicas, or cached files. That creates a partial-control problem: the organisation believes the dataset is protected, but the sensitive copy that matters most is still readable somewhere else.
For a concrete example of how easy it is to miss that distinction, DeepSeek database exposure 2025 shows how an exposed database can reveal plaintext data and related secrets when access controls and protective handling are not enforced end to end.
What to check before you assume encryption is in place
Before trusting encryption claims, confirm the sensitive data path from source to destination. That means identifying where the data is generated, where it is stored, where it is replicated, and where it is exported or processed by third-party tools. If any of those stages lack protection, the overall control is incomplete.
Next, verify the operational details: whether encryption is enabled by policy or merely supported, whether transit protection is mandatory, whether storage encryption is uniform across all environments, and whether key management is actually enforced rather than documented only. Missing encryption often hides behind a control that exists on paper but is not consistently applied.
Database and storage systems deserve special attention because they often sit at the centre of sensitive-data exposure. NHIMG’s Database Security Guide is a useful companion when the failure is not the database itself, but the way encryption, authentication, and auditing are implemented around it.
Risk and Threat Considerations
Missing encryption increases the blast radius of every later mistake. If sensitive data is stored or transmitted in cleartext, any misconfiguration, credential exposure, logging failure, or interception event becomes much more damaging because the data is directly readable rather than protected by an additional control layer.
Failure mechanism: Sensitive data is left unencrypted at one or more points in its lifecycle, then copied, logged, backed up, exported, or transmitted without compensating protection. That creates multiple readable versions of the same data and makes exposure more likely when a system or account is compromised.
Impact: Attackers, internal users, or exposed integrations can read or exfiltrate the data directly, and defenders lose the protection that encryption would have provided during storage, transit, or recovery operations. The consequence is usually broader disclosure, higher regulatory exposure, and a harder containment problem after discovery.
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 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-28 — Protection of Information at Rest | Sensitive data left unencrypted at rest maps directly to this control. |
| SC-8 — Transmission Confidentiality and Integrity | Missing encryption in transit is a direct transmission-protection failure. | |
| IA-5 — Authenticator Management | Key and secret handling are central when encryption depends on enforced credential and key lifecycle. | |
| Recommendation — Encrypt stored sensitive data and verify the control is enforced across all repositories. Require encrypted transport for sensitive flows and block cleartext paths. Manage encryption keys and related authenticators through controlled lifecycle processes. | ||
| NIST SP 800-57 | 1 — Key Management, Part 1: General | Encryption only works when key generation, storage, rotation and destruction are controlled. |
| Recommendation — Apply key lifecycle governance so encryption keys are generated, protected, rotated and retired correctly. | ||
Practitioner Guidance
What to verify: Treat encryption as a control over data flows, not as a checkbox on a platform. Confirm that sensitive data is encrypted at rest and in transit, and that every copy created by backup, replication, export, or analytics still inherits the intended protection.
Decision rule: If you cannot show where sensitive data is protected at each hop, assume the control is incomplete until proven otherwise. If the issue is a legacy or third-party system, prioritise compensating controls and key enforcement over assuming the vendor default is enough.
Practitioner takeaway: Missing encryption is usually a lifecycle and configuration failure, not a cryptography failure, so the right fix is to trace the data path, validate the defaults, and prove that protection survives every copy.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org