Encryption at Rest Requirements by Region: GDPR vs SOC 2 vs ISO 27001

Encryption at rest requirements are less prescriptive than most IT content claims, but the compliance gap is real. No major framework mandates AES-256 by name. GDPR does not require full-disk encryption. SOC 2 does not specify an algorithm. What auditors actually look for is evidence that encryption is present, documented, and appropriate to the sensitivity of the data. For a distributed fleet spanning multiple jurisdictions, that distinction matters more than the algorithm debate.

This post covers what GDPR Article 32, SOC 2, ISO 27001:2022, and key regional laws actually say about encryption at rest, what auditors look for as evidence, and how to build a defensible encryption policy across regions.

For the broader context on device security across the employee lifecycle, the main guide on securing devices across the full IT lifecycle for distributed teams is the right place to start.

What Do Compliance Frameworks Actually Require for Encryption at Rest?

Most major frameworks treat encryption at rest requirements as a risk control, not a technical mandate. GDPR lists encryption as an example measure. SOC 2 requires evidence of logical access controls. ISO 27001:2022 requires a cryptography policy aligned to risk. None specify an algorithm, key length, or tool. The practical requirement is: encryption present, documented, and appropriate to data sensitivity.

The gap between "required" and "mandated with specifics" is where most IT teams get into trouble. They either over-engineer a policy around an algorithm no auditor asked for, or they under-document controls that are actually in place and fail an audit on evidence rather than practice.

The frameworks also differ in enforcement mechanism. GDPR is enforced by national data protection authorities with fines up to 4% of global annual turnover. SOC 2 is a voluntary attestation with consequences that live in your customer contracts. ISO 27001 is a certification your registrar can revoke. Understanding which framework applies in which jurisdiction is the first step to building a policy that holds across regions.

Device encryption compliance is not just a technical problem. It is a documentation and process problem: which controls are in place, whether they are consistently applied, and whether the evidence exists to prove both.

What Does GDPR Article 32 Actually Say About GDPR Encryption Requirements?

GDPR Article 32 does not mandate encryption. It states that controllers and processors shall implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk, and lists "the pseudonymisation and encryption of personal data" as an example of such a measure. Encryption is illustrative, not obligatory. The practical incentive comes from Article 34.

Under GDPR Article 32, the requirement is to demonstrate that your chosen measures are proportionate to the risk. If you process sensitive personal data (health records, financial data, biometrics) without encryption and suffer a breach, you will need to explain to your supervisory authority why you made that choice.

GDPR Article 34 is where encryption becomes a real operational incentive. Article 34 requires notification to affected individuals after a high-risk breach, unless the data was encrypted and the keys were not compromised. If an encrypted laptop is stolen and the keys are secure, you may avoid individual notification obligations entirely. That provision is the strongest practical driver for endpoint encryption under GDPR, and it is almost never mentioned in commercial content on GDPR encryption requirements.

What auditors and supervisory authorities look for under GDPR:

• A documented risk assessment that considered encryption as a control
• Evidence that encryption is applied to personal data at rest on endpoints and in storage
• Key management practices documented and enforced
• Incident response procedures that account for encrypted vs. unencrypted data

Germany's BSI (Federal Office for Information Security) applies a stricter national interpretation. Their technical guidelines reference specific approved cryptographic algorithms and key lengths, going further than the base GDPR text. If you operate in Germany, BSI TR-02102 is worth reading alongside Article 32.

How Does SOC 2 Handle Encryption at Rest?

SOC 2 does not prescribe encryption algorithms or require full-disk encryption by name. The relevant Trust Services Criteria are CC6.1 (logical access controls) and CC6.7 (system operations, including media handling). Auditors assess whether controls are in place and operating effectively. Evidence of encryption at rest, documented policy, and configuration screenshots satisfy the criteria. Absence of encryption requires a compensating control or a documented exception.

SOC 2 encryption at rest sits under the Common Criteria. CC6.1 requires that logical access to assets is managed through registered and authorized users, and CC6.7 covers the protection of information stored on portable media. In practice, most SOC 2 auditors expect to see full-disk encryption enabled on laptops as a baseline control, even though the criteria do not state this explicitly.

The AICPA's Trust Services Criteria document (the authoritative source for SOC 2) frames these requirements in terms of "points of focus," which are guidance rather than requirements. Auditors have discretion in how they evaluate compliance, and their interpretation is informed by prevailing industry practice.

What SOC 2 auditors typically request as evidence:

• MDM or endpoint management reports showing encryption status across the fleet
• Screenshots of FileVault or BitLocker configuration
• Policy documents stating encryption requirements for company-owned devices
• Evidence of enforcement (e.g., devices without encryption blocked from network access)

The "operating effectiveness" test is where many companies fail. Having a policy that requires encryption is not enough. You need evidence that the control is consistently applied. A fleet of 200 laptops with 180 showing encryption enabled and 20 with no status is a finding, not a pass.

BYOD adds another layer of complexity. If personal devices access company systems, your SOC 2 scope may require you to address encryption on those devices too, which is exactly why the security comparison between BYOD and company-issued devices matters when scoping your encryption policy.

What Does ISO 27001:2022 Require for ISO 27001 Encryption Controls?

ISO 27001:2022 Annex A control A.8.24 (Use of cryptography) requires organizations to define and implement rules for the effective use of cryptography, including key management. This replaces the 2013 version's A.10 Cryptography section. ISO 27001 encryption controls do not mandate a specific algorithm. They require a documented cryptography policy that is proportionate to the classification of information assets (A.5.9) and addresses data retention and disposal (A.8.10).

The 2022 revision consolidated and updated cryptography controls significantly. A.8.24 requires your cryptography policy to cover:

• The types of cryptographic protection required for different data classifications
• Key generation, distribution, storage, archiving, retirement, and destruction
• Roles and responsibilities for cryptographic key management

ISO 27001 encryption controls are assessed against your own documented policy. If your policy says laptops containing classified data must use AES-128 or higher, and your fleet delivers that, you meet the control. If your policy says AES-256 and half your fleet is on AES-128, you have a nonconformity, even though both are NIST-approved.

Control A.8.10 covers information deletion. This connects directly to device lifecycle: when devices are decommissioned, cryptographic erasure (wiping the encryption key) is a recognized method of data sanitization. The certified data erasure standards guide covers how crypto-erase maps to NIST and ISO requirements in practice.

ISO 27001 certification requires a third-party audit by an accredited registrar. Auditors will review your Statement of Applicability to confirm A.8.24 is included, and then test whether your documented controls are implemented and effective. Evidence requirements are similar to SOC 2: policy documents, configuration evidence, key management procedures.

How Do Encryption Requirements Vary by Region?

Encryption requirements vary significantly by jurisdiction, and no single global standard satisfies all of them. Endpoint encryption by region requires matching the correct framework to the correct data type and sector. The table below summarizes the primary frameworks and their enforcement mechanisms.

HIPAA classifies encryption as "addressable," not "required." Under HIPAA §164.312(a)(2)(iv), addressable means you must implement the control OR document why it is not reasonable and appropriate, and implement an equivalent alternative. In practice, the HHS Office for Civil Rights has consistently treated absence of encryption as a significant factor in breach investigations. Non-implementation is very hard to defend if a breach occurs.

PCI-DSS 4.0 Requirement 3.5 requires that stored primary account numbers (PANs) are protected using strong cryptography. Requirement 4 covers encryption in transit. These are explicit, not illustrative.

NIS2 (in force October 2024) applies to essential and important entities across 18 sectors including energy, transport, health, and digital infrastructure. It is not a universal encryption mandate. Member state implementations vary, and some national transpositions are stricter than the base directive.

Canada and Australia do not mandate encryption explicitly, but both countries' privacy regulators have made clear in enforcement decisions that encryption is expected for sensitive personal data. The absence of encryption following a breach will be treated as failure to implement reasonable safeguards.

What Should You Actually Do? The Practical Answer for Encryption at Rest Requirements

Build your encryption policy around three decisions: what data classification triggers encryption, which tools you will use, and how you will prove the control is operating. Choose tools with validated cryptographic modules. Document your key management process. Generate evidence continuously, not just at audit time.

On tool selection: BitLocker with TPM 2.0 on Windows is FIPS 140-2 validated in certain configurations and is widely accepted by auditors across GDPR, SOC 2, and ISO 27001 engagements. FileVault on macOS is FIPS 140-2 or FIPS 140-3 validated in certain configurations depending on hardware and OS version. Both use AES-128 or AES-256 depending on configuration. Both are acceptable. The choice between them is a policy decision, not a compliance one. NIST SP 800-57 Part 1 confirms that both key lengths are appropriate for protecting sensitive data.

The actual algorithm matters less than consistent deployment. A fleet with AES-128 on every device and MDM evidence to prove it will pass more audits than a fleet that targets AES-256 but has 15% of devices with unknown encryption status.

For key management, document where keys are stored, who has access, and what happens when a device is lost or an employee leaves. This connects directly to device retrieval: an unrecovered device with no documented key management process is a much bigger compliance risk than a recovered device with proper crypto-erase.

When devices are decommissioned, cryptographic erasure is a valid sanitization method under NIST SP 800-88. Destroying the encryption key renders the data unrecoverable without needing physical destruction. This matters for device resale, redeployment, and cost recovery. See the certified data erasure standards breakdown for how this maps to NIST 800-88 and ISO 27001 A.8.10.

Platforms like Rayda that enforce encryption at provisioning as a default step in the device deployment workflow (BitLocker or FileVault enabled and logged before the device ships) remove the dependency on individual employees enabling encryption correctly after they receive the device. That single control point is what makes fleet-wide encryption evidence auditable across a distributed workforce.

For teams managing BYOD alongside company-issued devices, encryption policy enforcement differs significantly between the two models. The BYOD versus company-issued security comparison is a useful reference for scoping your policy correctly before you try to meet encryption at rest requirements across a mixed fleet.

What Are the Most Common Misconceptions About Compliance Encryption?

Several specific false claims appear repeatedly in commercial content on encryption at rest requirements. Here are the most common ones, with corrections.

"GDPR requires AES-256."
GDPR does not specify any algorithm or key length. Article 32 lists encryption as an example measure, not a mandate. The algorithm choice is yours, provided it is appropriate to the risk. Both AES-128 and AES-256 are NIST-approved and considered secure.

"SOC 2 mandates full-disk encryption."
SOC 2 Trust Services Criteria CC6.1 and CC6.7 address logical access and system operations. They do not mention full-disk encryption by name. Auditors expect to see it because prevailing industry practice treats it as a baseline control, not because the criteria require it.

"ISO 27001 uses A.10 for cryptography."
The 2013 version used A.10. ISO 27001:2022 renumbered and restructured controls. Cryptography is now A.8.24. Any content still citing A.10 Cryptography is referencing an outdated standard.

"HIPAA requires encryption."
HIPAA §164.312(a)(2)(iv) classifies encryption as "addressable." This means organizations must implement encryption or document why it is not reasonable and implement an equivalent alternative. HHS enforcement decisions consistently treat unencrypted devices as contributing factors in breach penalties. In practice, non-implementation of encryption for electronic protected health information stored on endpoints is very difficult to defend.

"AES-256 is more compliant than AES-128."
No major compliance framework distinguishes between the two. Both are approved in NIST SP 800-57. The fixation on AES-256 in vendor marketing reflects positioning, not regulatory requirement. Choose based on your risk assessment and performance requirements.

"Encrypting data in transit covers your encryption at rest requirements."
Transit encryption (TLS) and encryption at rest are separate controls addressing different threat vectors. Transit encryption protects data moving across a network. Encryption at rest protects data stored on a disk, database, or backup. Auditors treat these as distinct requirements. You need both.

FAQ

Does GDPR require encryption at rest?

GDPR Article 32 does not mandate encryption at rest. It lists encryption as an example of an appropriate technical measure. The practical pressure comes from Article 34: if encrypted data is breached and keys are not compromised, you may avoid the obligation to notify affected individuals. That safe harbor provision makes encryption a strong operational choice even where it is not technically required.

What algorithm does SOC 2 require for encryption at rest?

SOC 2 does not specify an algorithm. The Trust Services Criteria CC6.1 and CC6.7 require evidence of logical access controls and media protection. Auditors assess whether your chosen controls are appropriate and consistently applied. AES-128 or AES-256 with full-disk encryption enabled and documented in MDM are both accepted in practice. The evidence of consistent deployment matters more than the algorithm choice.

Is encryption at rest required under ISO 27001:2022?

ISO 27001:2022 Annex A control A.8.24 requires a documented cryptography policy and key management process proportionate to your data classification scheme. It does not mandate a specific algorithm or key length. Your policy must define which data categories require encryption, and your controls must deliver that. Auditors will test both the policy and the evidence of implementation.

Is HIPAA encryption addressable or required?

HIPAA §164.312(a)(2)(iv) classifies encryption as "addressable." This means organizations must implement encryption or document why it is not reasonable and implement an equivalent alternative. HHS enforcement decisions consistently treat unencrypted devices as contributing factors in breach penalties. In practice, non-implementation of encryption for electronic protected health information stored on endpoints is very difficult to defend.

Does encrypting a device eliminate GDPR breach notification obligations?

Not automatically, but GDPR Article 34 provides a safe harbor. If the breached data was encrypted and the encryption keys were not compromised, the controller may be able to demonstrate that the breach is unlikely to result in high risk to individuals, removing the obligation to notify them directly. The supervisory authority notification under Article 33 may still apply. This determination requires a case-by-case risk assessment.

Do I need different encryption standards for different countries?

The underlying cryptographic standards (AES, NIST-approved algorithms) are broadly consistent. What varies by region is the regulatory framework triggering the requirement, the enforcement mechanism, and the documentation expected. Germany's BSI publishes approved algorithm lists that go beyond base GDPR text. UK-GDPR references NCSC guidance. US requirements fragment by sector and state. Build your encryption policy to satisfy the strictest applicable framework and document why it satisfies the others.

What counts as evidence of encryption at rest for an audit?

For most frameworks, acceptable evidence includes: MDM or endpoint management console reports showing encryption status across all enrolled devices, configuration screenshots of BitLocker or FileVault, a written policy stating encryption requirements, key management procedures, and records showing what happens when a device is reported lost or an employee is offboarded. Point-in-time screenshots are less convincing than continuous monitoring reports that show consistent enforcement over the audit period.

If your team manages devices across multiple countries and encryption compliance is part of your audit scope, Rayda enforces encryption at provisioning as a default and handles retrieval and crypto-erase across 170+ countries. Book a demo to see how it fits your setup.