Why do industries that process personal data need different privacy controls for data in transit and data at rest?

Data in transit faces interception risk as it moves between systems, while data at rest is exposed through storage misconfiguration, overbroad access, or weak retention practices. Strong privacy programmes use different controls for each state because the threats are different. Encryption, secure APIs, VPNs, and access governance should be combined so protection follows the data end to end.

Why privacy controls should differ by data state

Data in transit and data at rest face different exposure paths, so a single control rarely covers both well. Moving data can be intercepted, altered, or sent to the wrong endpoint, while stored data is more likely to be exposed through weak access control, insecure backups, retention drift, or configuration mistakes. Privacy controls should therefore match the state-specific failure mode, not just the data classification.

That distinction matters because the control objective changes. In transit, the goal is to protect the communication path and verify the receiving endpoint. At rest, the goal is to restrict who can open, copy, export, or retain the stored information. Good privacy design treats these as linked but separate problems, so the same dataset keeps its protections as it moves across systems and storage layers.

What controls fit data in transit versus data at rest?

For data in transit, the priority is encryption over trusted channels, endpoint validation, and transport controls that reduce interception or tampering risk. That usually means TLS for application traffic, secure APIs, VPNs where network exposure matters, and strong authentication between systems where tokens or certificates are used to establish trust. The main question is whether the data can be observed or redirected before it reaches the intended recipient.

For data at rest, the priority shifts to storage encryption, key protection, access governance, and retention discipline. If stored data is broadly readable, weakly segregated, or kept longer than necessary, encryption alone will not solve the privacy problem. At-rest controls must also consider backups, replicas, archives, logs, and exports, because those copies often outlive the primary system and can become the real exposure point.

The best programme combines both layers so the controls follow the data end to end. That is why privacy engineering often pairs transport protection with storage protection, plus governance over who may access, move, or retain the data in either state. Strong design also pays attention to whether the data is in a workflow, a queue, a database, or a file store, because each state changes which control failure is most likely.

Where privacy programmes fail in practice

A common failure is assuming encryption is enough everywhere. It is not, because encrypted traffic can still be sent to the wrong service, and encrypted storage can still be exposed to too many people or systems. Another common failure is using the same rule set for both states, which leaves one side overcontrolled and the other underprotected. Privacy controls work best when they are specific to the exposure pattern and the operational environment.

For privacy-focused industries, this also means control evidence should show more than a policy statement. Teams should be able to demonstrate protected transport paths, access limits on stored records, and clear retention or deletion rules for data that no longer needs to exist. That is especially important when personal data moves through analytics, integration, or backup workflows, where risk often accumulates outside the primary application.

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 GDPR defines the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	A.25 — Data protection by design and by default	Requires privacy controls to be built around how personal data is processed and moved.
	A.32 — Security of processing	Supports choosing controls that reduce interception, access, and storage exposure risks.
Recommendation — Design separate safeguards for transit and storage so privacy protection follows the data lifecycle. Apply appropriate technical and organisational controls for both network transfer and stored data.
NIST SP 800-53 Rev 5	SC-8 — Transmission Confidentiality and Integrity	Directly addresses protecting data while it moves between systems.
	SC-28 — Protection of Information at Rest	Directly addresses protecting stored information from unauthorized disclosure.
	AC-6 — Least Privilege	Supports limiting who can read or export personal data once it is stored.
Recommendation — Use transmission controls that preserve confidentiality and integrity across network paths. Encrypt and constrain access to stored data, including backups and replicas. Restrict stored-data access to the minimum set of roles and services that need it.

Practitioner Guidance

What to prioritise: Start by mapping where personal data changes state, because the right control set depends on the actual movement path. If the data crosses networks, secure transport and endpoint trust come first; if it sits in databases, backups, or file stores, access restrictions and retention controls become the primary concern.

What to verify: Check that encryption is paired with key protection, access governance, and deletion or retention rules, not treated as a standalone fix. A useful test is whether a stolen backup, exported file, or intercepted session would still expose usable personal data.

Practitioner takeaway: The practical goal is state-aware privacy control, not one universal safeguard. Protect the path in transit, protect the storage location at rest, and make sure governance covers the copies and transitions in between.