Avoid Fines: Make Rest And Transit Encryption Reasonable

Understand when encryption at rest and in transit is truly “reasonable” so you can defend your security program to regulators, customers and auditors without overpaying for complexity you do not need.

Security and privacy laws love vague phrases like “reasonable security measures” or “appropriate
technical safeguards”. When you read enforcement cases, two words keep appearing: encryption at rest and
encryption in transit. But what exactly counts as “reasonable” in real life? Do you need to encrypt every
byte everywhere, or is that overkill? In this guide, we break down the concepts, show practical models and help you
defend your decisions when someone eventually asks: “why did you think this was enough?”.

Encryption at rest vs in transit: core concepts

What “encryption at rest” really means in practice

Encryption at rest protects data stored on disks, SSDs, tapes, database files, backups and device storage.
When the system is powered off or an attacker steals a physical drive, the data should be unreadable without the
proper keys. Common forms include full-disk encryption, database-level encryption and encrypted storage volumes in
cloud environments.

From a legal and compliance perspective, encryption at rest is often mentioned as a way to reduce breach impact:
if an attacker steals a lost laptop or a backup tape but cannot read the data, regulators may see the incident as
less severe than a clear-text disclosure.

What “encryption in transit” covers

Encryption in transit protects data while it travels between systems: browser to website, app to API,
service to database, office to cloud, site-to-site links and remote workers over the internet. The most visible
example is HTTPS using TLS, but it also includes secure VPN tunnels, encrypted messaging protocols and secure email
gateways.

In many investigations, regulators ask a simple question: “was sensitive data transmitted in plain text over public
networks?”. If the answer is yes, it is very hard to argue that your security was “reasonable”.

Linking encryption choices to “reasonable” expectations

Why “reasonable” depends on data type, context and risk

There is no single law that says “you must always encrypt everything, everywhere”. Instead, regulators and courts
ask whether your measures were proportionate to the sensitivity of the data and the risks involved.
That is why encrypting a public marketing brochure is irrelevant, but encrypting health records, payment card
details or government IDs is usually mandatory in practice.

To judge if your encryption controls are “reasonable”, look at:

• Data sensitivity: personal data, health data, financial data, trade secrets or low-risk content.
• Threat landscape: internet exposure, insider risk, physical theft of devices, cloud misconfigurations.
• Regulatory environment: privacy laws, sector rules (financial, healthcare, education), contracts.
• Industry norms: what similar organizations do; what major cloud and SaaS providers treat as default.

If your controls are significantly weaker than your peers, it becomes hard to defend them as “reasonable”.

How laws and standards shape expectations

Many privacy and security frameworks do not prescribe specific algorithms but still send a clear message. For
example, they require “state of the art” or “industry-standard” security measures, reference encryption as a
recommended safeguard, or reduce penalties when compromised data was properly encrypted and keys were not exposed.

In audits and investigations, organizations that can show strong encryption at rest and in transit, proper key
management and documented risk assessments usually have better outcomes than those with weak or inconsistent
controls.

Designing a practical encryption strategy

Step 1: Classify data and map where it lives and travels

You cannot decide what to encrypt until you know what you have. A practical first step is a simple data map:

• Classify data into levels (public, internal, confidential, highly sensitive).
• List where each category is stored (laptops, servers, cloud buckets, databases, backups).
• List where each category is transmitted (web apps, APIs, file transfers, email, VPNs).

Even a spreadsheet with systems in rows and “at rest / in transit” columns is enough to see which flows handle
sensitive data and must be prioritized for encryption.

Step 2: Encrypt high-value data by default

For data that could cause significant harm if exposed, do not debate whether to encrypt – treat it as a default.
This usually includes:

• Government identification numbers, financial account numbers, payment data.
• Health information, insurance claims, disability or benefits details.
• Authentication secrets, passwords, access tokens, private keys.
• Trade secrets, sensitive contracts, litigation or investigation files.

Use hardened, vendor-supported mechanisms: full-disk encryption on endpoints, encrypted volumes and managed keys in
cloud storage, database encryption for core systems and encrypted backups.

Step 3: Make encryption in transit the default setting

In modern environments, plain-text traffic over the internet or shared networks is rarely defensible. Instead:

• Require HTTPS/TLS for all public and internal web applications.
• Use secure protocols such as TLS for APIs, databases and messaging systems.
• Encrypt remote access through VPNs or zero-trust network access tools.
• Configure strong cipher suites and disable obsolete versions of TLS.

The goal is simple: if an attacker captures network traffic, they should see only encrypted data.

Step 4: Do not forget keys, access and monitoring

Encryption is only as strong as your key management. If keys are stored in plain text next to the data, or if
too many people have uncontrolled access, regulators may treat the data as effectively unencrypted.

Reasonable key management typically includes:

• Using hardware security modules or cloud key management services where feasible.
• Separating duties: the person managing keys is not the same person reading sensitive data.
• Rotating keys periodically and after suspected compromise.
• Logging key access and cryptographic operations for investigations.

Combine this with monitoring tools that alert when encryption is disabled, misconfigured or bypassed.

Examples and models you can adapt

Example 1: Small clinic storing and sending patient records

A small clinic handles health records, test results and insurance claims. A reasonable setup could be:

• Full-disk encryption on all laptops and desktops used to access patient data.
• Encrypted database for the electronic health record (EHR) system.
• Backups stored in encrypted cloud storage managed by the provider.
• All web portals (staff and patient) served over HTTPS with modern TLS.
• Secure email gateway or portal for sending sensitive results instead of plain email attachments.

This combination shows a good-faith effort proportionate to the sensitivity of the data.

Example 2: Online retailer with customer accounts

An e-commerce site handles addresses, order history and partial payment data. A reasonable approach may be:

• Do not store full card numbers; rely on payment gateways.
• Encrypt customer databases at rest and use full-disk encryption on servers.
• HTTPS/TLS for all pages, not just the checkout.
• Encrypted connections to payment processors and logistics partners.
• Keys stored in a managed key service, separated from application servers.

Common mistakes when deciding what is “reasonable”

• Assuming data is “not sensitive” without a formal classification or risk assessment.
• Encrypting production data but leaving backups and test environments in clear text.
• Using TLS for public websites but sending internal APIs and database traffic unencrypted.
• Storing encryption keys on the same server, in plain text, as the encrypted data.
• Relying on outdated algorithms or protocol versions considered weak by today’s standards.
• Documenting encryption policies but never checking if systems actually follow them.

Conclusion: clarity, consistency and documentation

Encryption at rest and in transit is no longer a luxury; it is a core part of what many regulators and customers
see as “reasonable security”. The challenge is not to encrypt everything blindly, but to align your controls with
data sensitivity and risk, then apply them consistently across storage, networks and backups.

When you can show that sensitive data is encrypted where it lives and where it travels, that keys are handled with
care, and that your decisions are backed by risk assessments and industry standards, you are in a much stronger
position. You reduce breach impact, reassure your customers and give auditors a clear story: your approach to
encryption is not perfect, but it is thoughtful, proportionate and defensible.