Cryptographic Keys complete

Control over encryption keys, key management systems, and cryptographic operations

L0 Unaware

No encryption policy exists. Default provider-managed encryption may be active but is neither understood nor governed. Key custody, rotation, and lifecycle management are entirely unconsidered.

Criteria

KEYS-L0-C1 No formal encryption policy or standard has been defined for data at rest or in transit.

Evidence guidance

Request the organisation's encryption policy or information security policy. Absence of any documented encryption requirements satisfies this criterion.
KEYS-L0-C2 Encryption keys are entirely provider-managed with no organisational awareness of key custody arrangements.

Evidence guidance

Interview IT leadership regarding who holds encryption keys and where key material resides. Lack of knowledge or 'the cloud provider handles it' responses confirm this criterion.
KEYS-L0-C3 No key rotation schedule or key lifecycle management process is in place.

Evidence guidance

Request documentation of key rotation policies or automated rotation configurations. Complete absence satisfies this criterion.

Indicators

No encryption policy document exists in the organisation's policy framework.
IT staff cannot identify where encryption keys are stored or who controls them.
Default provider encryption is active but not formally acknowledged or governed.

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-32	high	Article 32 requires appropriate technical measures including encryption. Absence of any encryption governance fails to demonstrate appropriateness.
`NDSG`	art-8	high	Data security obligations under nDSG Art. 8 require technical measures proportionate to risk. No encryption awareness represents a significant gap.
`NIS2`	art-21	high	NIS2 Art. 21 mandates policies on cryptography. Complete absence of encryption governance is non-compliant.

Upgrade path

Establish a basic encryption policy. Inventory all systems and identify which provider-managed encryption is active. Document current key custody arrangements, even if they are entirely provider-controlled.

Risk if stagnant

Data breaches may go undetected due to lack of encryption awareness. Regulatory non-compliance with GDPR Art. 32 and NIS2 Art. 21 exposes the organisation to enforcement action. Foreign government access to unmanaged keys under the CLOUD Act cannot be assessed or mitigated.

Typical characteristics

No encryption policy or standard is documented.
The organisation cannot articulate who holds key material or under which jurisdiction keys reside.
Key rotation does not occur, or occurs solely at provider discretion without organisational awareness.
There is no distinction between encryption of data at rest, in transit, or in use.
CLOUD Act exposure through US-headquartered providers is neither assessed nor mitigated.

Typical evidence

Absence of encryption-related policies in the information security management system.
Interview responses indicating encryption is "handled by the cloud provider" with no further detail.
No key management entries in asset inventories or configuration management databases.

Why this is dangerous

Organisations at Level 0 face significant regulatory exposure. GDPR Art. 32 requires encryption as a technical safeguard, and the inability to demonstrate deliberate encryption governance undermines compliance posture. In the event of a breach, the inability to confirm encryption status (GDPR Art. 34) may trigger mandatory notification to data subjects. Under NIS2, the absence of cryptography policies constitutes a direct compliance gap for entities in scope.

L1 Dependent

Provider-managed encryption is acknowledged and documented. The organisation relies entirely on the cloud provider for key generation, storage, and rotation. Key material remains under provider custody with no customer-controlled options exercised.

Criteria

KEYS-L1-C1 A basic encryption policy exists that mandates encryption at rest and in transit for production systems.

Evidence guidance

Review the organisation's encryption policy or relevant section of the information security policy. Confirm it requires encryption for data at rest and in transit.
KEYS-L1-C2 Provider-managed encryption services are explicitly identified and documented (e.g., AWS SSE-S3, Azure SSE with Microsoft-managed keys, Google default encryption).

Evidence guidance

Request an inventory of encryption services in use. Verify that specific provider encryption mechanisms are named and mapped to workloads.
KEYS-L1-C3 The organisation acknowledges that key material is held by the provider and has documented this as a known dependency.

Evidence guidance

Review risk registers or dependency documentation for explicit acknowledgement that the cloud provider controls key material.

Indicators

Encryption policy exists and is approved by management.
Provider-managed encryption is active on all production data stores.
Key custody is documented as a provider dependency in the risk register.
No customer-managed key options have been evaluated or exercised.

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-32	medium	Basic encryption measures are in place, partially satisfying Art. 32. However, lack of customer control over keys limits the ability to demonstrate full appropriateness.
`NDSG`	art-8	medium	Encryption is active but key custody remains with a potentially foreign-jurisdiction provider, creating residual risk under Swiss data protection expectations.
`CLOUD-ACT`	18-usc-2703	high	Provider-held keys mean a CLOUD Act request could compel decryption without customer knowledge or consent. This is a significant sovereignty concern.
`DORA`	art-9	medium	ICT risk management under DORA Art. 9 requires identification of dependencies. Provider-managed keys represent a critical dependency that must be governed.

Upgrade path

Evaluate BYOK (Bring Your Own Key) or customer-managed key options available from current providers. Negotiate contractual terms for key handling in the DPA. Conduct a CLOUD Act risk assessment for key material held by US-headquartered providers.

Risk if stagnant

Provider-held keys leave the organisation unable to prevent provider-side decryption or foreign government compelled access. CLOUD Act exposure remains unmitigated. Inability to independently rotate or revoke keys creates operational risk during security incidents.

Typical characteristics

A formal encryption policy mandates encryption for data at rest and in transit.
Provider-default encryption mechanisms are identified and mapped to workloads.
Key generation, storage, rotation, and destruction are entirely provider-managed.
The provider retains technical capability to access key material.
Key custody is documented as a known dependency but no mitigation is in place.

Typical evidence

Approved encryption policy with scope covering production systems.
Configuration evidence showing provider-managed encryption enabled (e.g., AWS SSE-S3 bucket policies, Azure Storage Account encryption settings).
Risk register entry acknowledging provider key custody as a dependency.
No BYOK or customer-managed key configurations present.

Why this is dangerous

The primary risk at Level 1 is the CLOUD Act exposure. When a US-headquartered provider holds key material, law enforcement requests under the CLOUD Act can compel the provider to produce decrypted data without customer notification. This applies regardless of where the data or keys physically reside. Organisations processing sensitive personal data or operating in regulated sectors (financial services under DORA, essential services under NIS2) should prioritise advancing beyond this level.

L2 Contractual

BYOK options are contractually available and the DPA addresses key handling obligations. However, the provider retains technical access to key material through platform architecture. Contractual controls exist but technical sovereignty over keys is not yet achieved.

Criteria

KEYS-L2-C1 The Data Processing Agreement explicitly addresses key management responsibilities, key custody, and conditions under which the provider may access key material.

Evidence guidance

Review the DPA for clauses covering encryption key management, key access conditions, and key custody responsibilities. Confirm these are specific rather than generic security references.
KEYS-L2-C2 BYOK or customer-managed key options have been contractually secured with the provider, even if not yet fully implemented.

Evidence guidance

Review service agreements or order forms for BYOK/CMK entitlements. Confirm the organisation has the contractual right to manage its own keys.
KEYS-L2-C3 A key management procedure documents key lifecycle stages including generation, distribution, rotation, revocation, and destruction.

Evidence guidance

Request the key management procedure. Verify it covers the full key lifecycle and assigns responsibilities for each stage.
KEYS-L2-C4 The provider's technical access to key material has been assessed and documented as a residual risk.

Evidence guidance

Review risk assessments or technical architecture documentation acknowledging that BYOK in cloud KMS does not fully eliminate provider access to key material in memory during cryptographic operations.

Indicators

DPA contains specific key management clauses beyond generic encryption references.
BYOK or customer-managed key entitlements are documented in service agreements.
Key management procedure covers full lifecycle and is reviewed at least annually.
Residual risk of provider key access is documented and accepted at appropriate management level.

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-32, art-34	medium	Contractual key management provisions strengthen the Art. 32 posture. However, technical provider access means encryption may not constitute a measure rendering data unintelligible per Art. 34(3)(a).
`NDSG`	art-8	medium	Contractual safeguards improve compliance posture but do not fully address Swiss expectations for data security when key material remains technically accessible to foreign providers.
`NIS2`	art-21	low	Documented cryptography policies and procedures with contractual controls largely satisfy NIS2 Art. 21 requirements for cryptography governance.
`DORA`	art-9	medium	Key management procedures support DORA Art. 9 ICT risk management, but residual provider access to keys may not satisfy financial sector expectations for critical data protection.

Upgrade path

Implement customer-managed keys across all critical workloads. Deploy HSM-backed key storage to ensure key material never exists in plaintext outside the HSM boundary. Establish key rotation automation under customer control. Evaluate jurisdictional placement of key material to ensure EU/Swiss residency.

Risk if stagnant

Contractual controls without technical enforcement provide limited protection against compelled access scenarios (CLOUD Act, national security orders). Provider platform compromises could expose key material. Regulatory expectations are evolving toward technical rather than purely contractual safeguards, particularly for financial services (DORA) and critical infrastructure (NIS2).

Typical characteristics

The DPA includes specific clauses on key management, custody, and access conditions.
BYOK or customer-managed key options are contractually available.
A formal key management procedure covers generation, rotation, revocation, and destruction.
The organisation understands that cloud BYOK typically means the provider wraps customer keys within their KMS, retaining technical access during cryptographic operations.
Residual risk of provider access to key material is formally documented and accepted.

Typical evidence

DPA with key management annexes or clauses specifying custody and access conditions.
Service agreement addenda enabling BYOK/CMK capabilities.
Key management procedure aligned to industry standards (e.g., NIST SP 800-57).
Risk assessment documenting the technical limitations of cloud BYOK (provider access to key material in memory).
Partial implementation of customer-managed keys on high-sensitivity workloads.

Why this matters

The critical limitation at Level 2 is the gap between contractual and technical control. Cloud KMS BYOK implementations (AWS KMS CMK, Azure Key Vault BYOK, Google Cloud KMS) typically import customer key material into the provider's HSM infrastructure, where the provider's platform retains access during cryptographic operations. While contractual clauses restrict how the provider may use this access, they do not prevent compelled access under legal instruments such as the CLOUD Act or national security letters. Organisations handling particularly sensitive data (health, financial, classified) should advance to Level 3 to close this gap.

L3 Controlled

Customer-managed keys are implemented with HSM-backed storage. Key material resides in EU/Swiss jurisdiction under customer control. The provider cannot access plaintext key material. Key rotation, revocation, and lifecycle management are fully under customer governance.

Criteria

KEYS-L3-C1 Customer-managed keys (BYOK or HYOK) are implemented for all critical workloads, with key material stored in HSM-backed infrastructure that prevents provider access to plaintext keys.

Evidence guidance

Review key management architecture documentation. Verify HSM-backed key storage (e.g., AWS CloudHSM, Azure Dedicated HSM, or third-party HSM) is used rather than standard cloud KMS. Confirm the provider cannot extract plaintext key material.
KEYS-L3-C2 Encryption key material resides exclusively within EU or Swiss jurisdiction, with no replication to non-EU/non-Swiss locations.

Evidence guidance

Request HSM deployment location documentation. Verify that HSM instances and key material are deployed in EU/Swiss data centre regions with no cross-border replication.
KEYS-L3-C3 Key rotation is automated under customer control, not delegated to the provider.

Evidence guidance

Review automated key rotation configurations. Confirm that rotation is triggered by customer-managed automation, not by the provider's default rotation mechanisms.
KEYS-L3-C4 Key rotation schedules are defined per data classification level.

Evidence guidance

Review key rotation schedules and confirm rotation frequency varies according to data classification policy (e.g., more frequent rotation for higher-sensitivity data).
KEYS-L3-C5 Envelope encryption is implemented, separating data encryption keys (DEKs) from key encryption keys (KEKs) with the KEK under customer-controlled HSM protection.

Evidence guidance

Review encryption architecture documentation for envelope encryption design. Verify KEKs are stored in customer-controlled HSMs and DEKs are wrapped/unwrapped using customer-controlled operations.

Indicators

HSM-backed key storage is deployed and operational for all critical workloads.
Key material jurisdictional residency is verified and monitored (EU/Swiss locations only).
Automated key rotation executes on customer-defined schedules without provider intervention.
Envelope encryption architecture separates DEKs and KEKs with KEKs in customer-controlled HSMs.

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-32, art-34	low	HSM-backed customer-managed keys with jurisdictional controls constitute a strong technical measure under Art. 32. Encryption with customer-only key access may satisfy Art. 34(3)(a) rendering data unintelligible.
`NDSG`	art-8	low	Swiss-jurisdiction key storage with customer-only access aligns well with nDSG data security expectations and Swiss sovereignty principles.
`NIS2`	art-21	low	Comprehensive cryptographic controls with HSM backing and defined lifecycle management exceed NIS2 Art. 21 cryptography requirements.
`DORA`	art-9	low	Customer-controlled HSM key management with envelope encryption and automated rotation satisfies DORA Art. 9 ICT risk management expectations for financial entities.
`CLOUD-ACT`	18-usc-2703	low	Customer-controlled HSMs with no provider access to plaintext key material significantly reduce CLOUD Act exposure. The provider cannot produce decrypted data even if compelled.

Upgrade path

Evaluate self-hosted HSM infrastructure to eliminate any remaining cloud provider dependency for key management. Assess on-premises key ceremony capabilities for root key generation. Implement confidential computing or secure enclave integration to protect keys during cryptographic operations.

Risk if stagnant

Dependency on cloud-hosted HSM infrastructure (even customer-dedicated) means the underlying HSM platform is still managed by the cloud provider. Firmware updates, physical security, and operational continuity remain provider-controlled. For organisations requiring absolute cryptographic sovereignty, this residual dependency may be unacceptable.

Typical characteristics

Customer-managed keys (BYOK/HYOK) are deployed across all critical workloads.
HSM-backed key storage ensures key material never exists in plaintext outside the HSM security boundary.
Key material resides exclusively in EU/Swiss jurisdiction with verified residency.
Automated key rotation operates on customer-defined schedules, differentiated by data classification.
Envelope encryption separates data encryption keys from key encryption keys.
The provider is technically unable to decrypt customer data without customer cooperation.

Typical evidence

Architecture diagrams showing HSM-backed key management (e.g., AWS CloudHSM clusters, Azure Dedicated HSM, Thales Luna Network HSM in cloud).
HSM deployment certificates confirming EU/Swiss data centre locations.
Automated key rotation logs showing customer-triggered rotations on defined schedules.
Envelope encryption design documentation with clear DEK/KEK separation.
Penetration test or architecture review confirming provider cannot access plaintext key material.
Key ceremony records for root key generation.

Remaining risks

While Level 3 provides strong cryptographic sovereignty, residual risks remain. The underlying HSM platform (hardware, firmware, operational management) is still controlled by the cloud provider in cloud-hosted HSM deployments. Physical security of the HSM hardware, firmware integrity, and side-channel protections depend on the provider's operational practices. For organisations subject to the most stringent sovereignty requirements (defence, intelligence, critical national infrastructure), these residual dependencies may necessitate advancing to Level 4.

When Level 3 is warranted

Level 3 is appropriate for organisations that process sensitive personal data, financial data under DORA, or data subject to sector-specific regulations where provider access to plaintext key material is unacceptable. It is also warranted when a CLOUD Act risk assessment identifies provider-held keys as a significant exposure, or when clients or regulators require evidence of technical key control beyond contractual assurances.

When Level 3 is excessive

Organisations handling general-purpose business data, where contractual safeguards at Level 2 are proportionate to the risk profile, may not need HSM-backed key management. Small and medium organisations without the operational capacity to manage HSM infrastructure, key rotation automation, and envelope encryption should weigh the operational burden against the incremental sovereignty gained.

CLOUD Act mitigation

At Level 3, CLOUD Act risk is substantially mitigated. Even if a US-headquartered provider receives a lawful data production request, the provider cannot produce decrypted data because it lacks access to the plaintext key material. The requesting authority would need to compel the customer directly through mutual legal assistance treaties (MLATs) or equivalent instruments, which are subject to jurisdictional safeguards.

L4 Autonomous

Full cryptographic sovereignty is achieved through self-hosted HSM infrastructure and on-premises key management. Zero provider access to key material at any stage. The organisation controls the complete key lifecycle from root key generation through destruction, with no external dependencies.

Criteria

KEYS-L4-C1 Self-hosted HSM infrastructure is deployed on-premises or in a customer-controlled data centre, with no dependency on cloud provider HSM services.

Evidence guidance

Inspect on-premises HSM deployment (e.g., Thales Luna, Utimaco SecurityServer, Entrust nShield). Verify HSMs are physically located in customer-controlled facilities with no cloud provider involvement in HSM operations.
KEYS-L4-C2 Key ceremonies for root key generation are conducted on-premises with documented procedures, multiple key custodians, and tamper-evident controls.

Evidence guidance

Review key ceremony documentation including procedures, witness logs, custodian assignments, and tamper-evident bag records. Verify ceremonies are conducted in physically secured, customer-controlled environments.
KEYS-L4-C3 Zero provider access to key material is architecturally enforced across the full lifecycle: generation, storage, use, rotation, and destruction.

Evidence guidance

Review architecture documentation confirming key material never transits provider infrastructure in plaintext. Verify that cryptographic operations occur within customer-controlled boundaries (on-premises HSM, secure enclave, or confidential computing environment).
KEYS-L4-C4 An independent key management system operates entirely within customer infrastructure, providing centralised governance over all cryptographic keys across hybrid and multi-cloud environments.

Evidence guidance

Inspect the key management system deployment (e.g., HashiCorp Vault Enterprise on-premises, Thales CipherTrust Manager, Fortanix DSM). Confirm it operates on customer-owned infrastructure and manages keys across all environments without provider dependencies.

Indicators

On-premises HSM infrastructure is operational with documented physical security controls.
Key ceremony records demonstrate multi-custodian root key generation in customer-controlled facilities.
Architecture review confirms zero provider access to key material at any lifecycle stage.
Centralised key management system operates on customer infrastructure spanning all environments.

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-32, art-34	minimal	Self-hosted cryptographic infrastructure provides the highest level of technical measures under Art. 32. Customer-exclusive key access definitively satisfies Art. 34(3)(a) unintelligibility requirements.
`NDSG`	art-8	minimal	Full cryptographic sovereignty with Swiss-jurisdiction key infrastructure fully satisfies nDSG Art. 8 technical safeguard requirements.
`NIS2`	art-21	minimal	Self-hosted cryptographic infrastructure with comprehensive lifecycle management exceeds all NIS2 Art. 21 cryptography requirements.
`DORA`	art-9	minimal	Elimination of third-party dependencies for key management fully satisfies DORA Art. 9 expectations and removes ICT concentration risk for cryptographic operations.
`CLOUD-ACT`	18-usc-2703	minimal	No provider holds or can access key material. CLOUD Act requests to providers cannot yield decrypted data. Cryptographic sovereignty is fully achieved.

Risk if stagnant

Maintaining Level 4 requires ongoing investment in HSM infrastructure, skilled cryptographic personnel, and operational procedures. Failure to maintain HSM hardware (firmware updates, certificate renewals, capacity planning) can degrade security posture. The organisation must also track cryptographic algorithm evolution to prepare for post-quantum migration.

Typical characteristics

Self-hosted HSM infrastructure operates in customer-controlled data centres or on-premises facilities.
Root key ceremonies are conducted on-premises with multi-custodian controls and tamper-evident procedures.
Key material is generated, stored, used, rotated, and destroyed entirely within customer-controlled boundaries.
A centralised key management platform governs keys across hybrid and multi-cloud deployments.
No cloud provider, managed service provider, or third party has technical access to plaintext key material.
Post-quantum cryptographic readiness is assessed and migration planning is underway.

Typical evidence

On-premises HSM deployment documentation with physical security audit reports.
Key ceremony records with witness logs, custodian sign-off, and tamper-evident bag serial numbers.
Architecture documentation demonstrating end-to-end key material isolation from provider infrastructure.
Centralised key management platform (e.g., HashiCorp Vault Enterprise, Thales CipherTrust Manager, Fortanix DSM) deployed on customer-owned infrastructure.
Independent audit report confirming zero provider access to key material.
Cryptographic algorithm inventory and post-quantum migration roadmap.

Operational considerations

Achieving Level 4 requires significant operational maturity. The organisation must maintain:

HSM operations: Hardware lifecycle management including firmware updates, certificate renewals, capacity monitoring, and disaster recovery for HSM clusters.
Key custodian programme: Trained personnel for key ceremonies with documented succession planning and segregation of duties.
Cryptographic expertise: In-house or retained expertise for cryptographic architecture decisions, algorithm selection, and incident response.
Compliance monitoring: Continuous verification that no key material leaks into provider-accessible infrastructure through configuration drift or architectural changes.

When Level 4 is warranted

Level 4 is the target state for organisations in defence, intelligence, or critical national infrastructure where no residual provider dependency for key management is acceptable. It is also warranted when the threat model includes the cloud provider itself as a potential adversary or as a party that could be compelled to act against the organisation's interests.

When Level 4 is excessive

For most commercial organisations, Level 3 provides strong cryptographic sovereignty with significantly lower operational overhead. Level 4 requires sustained investment in HSM operations, key custodian programmes, cryptographic expertise, and post-quantum migration planning. Organisations should pursue Level 4 only when driven by a specific threat model and regulatory requirement, not as a default aspiration.

CLOUD Act and foreign access mitigation

At Level 4, the organisation is effectively immune to CLOUD Act compelled access through providers. Since no provider holds or can access key material, a CLOUD Act request directed at a provider cannot yield decrypted data. Any government seeking access to the encrypted data must engage directly with the organisation through the applicable legal framework (Swiss IMAC, EU MLAT processes), which are subject to full jurisdictional safeguards and judicial oversight.

Post-quantum preparedness

Organisations at Level 4 should actively monitor NIST post-quantum cryptography standards and begin assessing the impact of quantum computing on their cryptographic estate. Key management infrastructure should be evaluated for crypto-agility - the ability to migrate to post-quantum algorithms without architectural redesign. This includes inventorying all cryptographic algorithms in use, identifying harvest-now-decrypt-later risks for long-lived data, and planning HSM firmware upgrades to support post-quantum algorithms.