What are common mistakes with data at rest and data in transit?

Why teams get data-at-rest and data-in-transit protection wrong

The most common failure is treating these as interchangeable problems. Encryption in transit protects data moving between endpoints, but it does not secure files, backups, databases, or snapshots once they are stored. Encryption at rest reduces exposure if storage is copied, lost, or mounted elsewhere, but it does not stop interception or tampering on the wire. The control has to match the data state.

A second mistake is over-relying on transport security as a blanket answer for storage exposure. That gap shows up when organisations secure TLS on the application path but leave exported data, archives, replica sets, or disaster-recovery copies either unencrypted or protected with weak handling. It also appears when teams assume a single platform control covers every copy of the data, rather than checking each storage layer and transfer path separately.

A third issue is weak cryptographic operations around the encryption itself. The technical mechanism matters less than the operational discipline around it, especially when key rotation, certificate handling, and recovery procedures are inconsistent. Good encryption can still be undermined by poor key custody, expired or mishandled certificates, or backup workflows that silently break the protection model.

Where the protection boundary breaks in practice

Teams often define the wrong boundary. “At rest” is not just the primary production database, it includes replicated data, snapshots, object storage, removable media, test copies, and archived exports. “In transit” is not just browser-to-app traffic, it also includes service-to-service calls, administrative access, data replication, and outbound transfers to third parties or cloud services.

That is why a control can appear strong in one environment and fail in another. A system may use encrypted transport everywhere while internal batch jobs, backup restoration, or cross-region replication move plaintext or weakly protected data. The reverse also happens: disks are encrypted, but APIs, admin sessions, or integration traffic expose the same data in transit. The practical test is whether the protection survives every copy and every route the data can take.

Teams should also separate confidentiality from integrity. Transport protection can help with both, but storage protection is often judged only by whether the volume is encrypted. That is too narrow if the real issue is whether the data can be read, copied, restored, or altered after storage compromise. For operational detail on the encryption controls themselves, see NHIMG’s Encryption Guide.

What good verification looks like for both states

Verification should be state-specific and evidence-based. For data at rest, confirm where encryption is applied, who controls the keys, how backups are protected, and whether exported datasets inherit the same safeguards. For data in transit, confirm which protocols are in use, whether certificates are valid and managed, and whether internal as well as external traffic is protected.

Practitioners should test the failure paths, not just the happy path. That means checking restore jobs, replication flows, data exports, and service integrations for plaintext leakage or missing controls. It also means validating that certificate expiry, key rotation, and backup recovery do not create a hidden exception where protection drops off exactly when the organisation relies on it most.

For teams that need a wider control lens, NHIMG’s Top 10 Data Security Risks is a useful companion for the storage, access, and exposure side of the problem, while the CISA Known Exploited Vulnerabilities Catalog is a reminder to treat exposed or poorly protected systems as potentially exploitable, not merely misconfigured.

Risk and Threat Considerations

Data protection mistakes matter because attackers rarely need every copy of the data, they only need one unprotected path or one unencrypted repository. A missed backup, an exposed export, or an internal transfer that skips transport protection can create a clean exfiltration route even when the primary system looks compliant.

Failure mechanism: Organisations protect one data state but leave another state, such as backups, replicas, exports, or internal service traffic, exposed through weak encryption, poor key handling, or missing certificate controls.

Impact: Confidential data can be read, copied, restored, or intercepted outside the intended trust boundary, and the weakest copy often becomes the compromise point.

Practitioner Guidance

What to verify: Treat “at rest” and “in transit” as separate control tests. Verify storage encryption, backup encryption, certificate validity, and key rotation independently, then compare the result against every copy and transfer path that carries the same dataset.

Common mistake: Do not assume a secure network or a single platform feature closes the gap. If a dataset can be exported, replicated, restored, or moved to another service, each of those paths needs its own proof of protection.

Practitioner takeaway: The right question is not whether the data is encrypted somewhere, it is whether every meaningful state transition preserves the intended protection boundary.

Related resources from NHI Mgmt Group

• How should security teams choose an AES mode for protecting sensitive data at rest and in transit?
• How should security teams implement encryption across data at rest and data in transit?
• What are the common mistakes teams make when building data retention and minimization programmes?
• What are the common mistakes teams make when they rely on regex for sensitive data discovery?