Why do organisations still need encryption if they already have access controls and DLP?

Access controls and DLP reduce misuse, but they do not eliminate exposure once data is copied, transmitted, or stored in an unsafe place. Encryption adds a separate protection layer that keeps data unreadable without the key. That matters for privacy, breach containment, regulatory compliance, and limiting the impact of stolen files or compromised infrastructure.

Why This Matters for Security Teams

Access control decides who should be allowed to reach data, and DLP tries to stop data from leaving approved boundaries. Encryption answers a different question: what happens if data is copied, cached, forwarded, backed up, logged, or recovered from a system that should not have had it in the first place. That distinction is why guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls still treats cryptographic protection as a core safeguard, not an optional add-on.

Practitioners often overestimate what policy enforcement can do after data leaves its intended context. DLP may detect known patterns, but it does not make a spreadsheet safe if it is emailed externally, synced to an unmanaged endpoint, or exposed through a misconfigured cloud share. Encryption reduces the blast radius by keeping content unusable without keys, even when perimeter assumptions fail. That is especially important for regulated records, intellectual property, credentials, and identity data.

In practice, many security teams encounter the value of encryption only after a copy has already been exfiltrated, rather than through intentional design.

How It Works in Practice

Encryption works best when it is applied in layers. At rest, it protects stored files, databases, backups, object storage, and endpoint disks. In transit, it protects traffic between users, services, partners, and APIs. In some environments, application-level or field-level encryption is also needed so that sensitive values remain protected even if the database or storage layer is accessed directly. The security model is simple: if the key is not available, the data should remain unreadable.

That said, encryption is only as strong as key management. If keys are stored beside the data, reused too broadly, or accessible to overly privileged service accounts, the protection becomes fragile. This is where identity and secrets governance matters, including controls for human administrators and non-human identities. The OWASP Non-Human Identity Top 10 is relevant because automated workloads often need access to encrypted data, and those identities can become the weakest link if their credentials, tokens, or certificates are not tightly controlled.

• Use encryption at rest for storage systems, backups, and removable media.
• Use encryption in transit for internal service calls, remote access, and external sharing.
• Separate encryption keys from the protected data wherever possible.
• Restrict key usage with least privilege, rotation, and audit logging.
• Match the protection to the sensitivity of the data and the likely failure mode.

For payment data, PCI DSS v4.0 keeps encryption central because cardholder data can be exposed through many operational paths, not just direct access. These controls tend to break down when organisations centralise keys without strong segregation of duties because privileged operators can then access both the ciphertext and the means to decrypt it.

Common Variations and Edge Cases

Tighter encryption often increases operational overhead, requiring organisations to balance stronger confidentiality against usability, recovery, and monitoring complexity. That tradeoff is real, especially in environments where search, analytics, incident response, or lawful access are needed. Best practice is evolving toward selective, risk-based encryption rather than treating every dataset identically. Full-disk encryption protects lost devices well, but it does not help much if an authorised user exports plain text from an application that never encrypts sensitive fields.

There is no universal standard for this yet in every cloud or SaaS workflow, so teams should define where encryption is mandatory, where tokenisation is acceptable, and where DLP is only a detection layer. In hybrid and multi-cloud environments, encryption often fails through poor boundary management: unmanaged backups, service-to-service secrets, weak KMS permissions, or third-party integrations that cannot support customer-managed keys. That is why the governance model should align to broader control sets such as CIS Controls v8 and ISO/IEC 27001:2022 Information Security Management, not just one technical safeguard.

For identity-heavy systems, encryption also intersects with credential lifecycle management because automated services frequently decrypt data on behalf of users. If those services are over-permissioned, the confidentiality benefit erodes quickly. The control goal is not simply to encrypt more, but to ensure the keys, identities, and recovery paths are governed as carefully as the data itself.

Related resources from NHI Mgmt Group

• Should organisations keep classic PAM if they are moving to dynamic access controls?
• Why do organisations need access management if they already have access control?
• Why do organisations need IGA if IAM already controls access?
• Should organisations keep legacy SEG controls if they already use Microsoft 365?