Cryptographic Key Management for ISO 27001, NIS2 and DORA

At 08:17 on a Monday morning, the CISO of a European SaaS company gets a message from the engineering lead: “We rotated the database encryption key over the weekend, but one integration stopped decrypting records. We rolled back using an old key from the vault.”

Ten minutes later, the DPO asks whether the affected records include EU personal data. Finance asks whether this could become a reportable operational incident for a regulated customer. Procurement asks whether the cloud provider or the company owns the customer-managed key. The CEO asks the only question that matters in the boardroom: “Can we prove we managed this properly?”

That is the moment when “we use encryption” stops being a comforting phrase and becomes an evidence problem.

In 2026, cryptographic key management sits at the intersection of ISO/IEC 27001:2022 controls, NIS2 cyber hygiene, DORA ICT risk management, GDPR Article 32 security-of-processing evidence, cloud shared responsibility and post-quantum crypto-agility planning. The real issue is not whether encryption exists. The real issue is whether the organization can show, with records, that keys are generated securely, assigned to owners, stored in approved KMS or HSM environments, rotated on schedule, recovered safely, revoked when compromised and mapped to business risk.

Clarysec sees the same pattern repeatedly in readiness work. Encryption is implemented system by system, but key governance is fragmented. Certificates live in spreadsheets. Cloud KMS permissions are inherited from old projects. Developers know which secrets matter, but the ISMS does not. Auditors receive screenshots instead of lifecycle evidence. NIS2 and DORA teams talk about resilience, privacy teams talk about GDPR encryption and pseudonymisation, and nobody owns the cryptographic control plane end to end.

A mature answer is not more cryptography in isolation. It is governed cryptographic key management connected to risk treatment, cloud architecture, supplier oversight, access control, logging, incident response and regulatory evidence.

Why key management is now a governance issue

NIS2 makes cryptography and encryption policies part of minimum cybersecurity risk-management measures for essential and important entities. Article 21 requires appropriate and proportionate technical, operational and organisational measures, including risk analysis, incident handling, continuity, supply chain security, secure development, cyber hygiene, access control, asset management, and cryptography and encryption policies. It also requires management bodies to approve and oversee cybersecurity risk-management measures.

For SaaS, cloud, managed service and cybersecurity providers, applicability can be broader than many teams assume. NIS2 covers sectors such as digital infrastructure, cloud computing service providers, data centre providers, DNS providers, trust service providers, managed service providers, managed security service providers, online marketplaces, search engines and social networking platforms where size or criticality thresholds are met.

DORA raises the bar for financial entities. From 17 January 2025, DORA requires a documented ICT risk management framework, board accountability, ICT business continuity and response and recovery plans, digital operational resilience testing, ICT third-party risk management and incident reporting. For financial entities identified under NIS2 national rules, DORA operates as the sector-specific Union legal act for equivalent NIS2 obligations. A fintech should not run separate crypto governance for NIS2, DORA and ISO. It needs one defensible control model.

GDPR adds the privacy evidence dimension. GDPR Article 32 is where encryption is commonly evaluated as a security-of-processing safeguard, but “the data is encrypted” is not a complete answer. Regulators and auditors ask who controls the keys, how access is restricted, how compromise is detected, how recovery works, and whether the design matches the risk to individuals.

ISO/IEC 27001:2022 gives organizations the management system to tie these obligations together. Clauses 4.1 to 4.4 require context, interested-party requirements, ISMS scope and interacting processes. Clauses 5.1 to 5.3 require leadership, policy, resources and assigned responsibilities. Clauses 6.1.1 to 6.1.3 require risk assessment, risk treatment, control selection, a Statement of Applicability and risk-owner approval. Clauses 8.1 to 8.3 require controlled operation, risk reassessment when changes occur, implementation of treatment plans and retention of documented results.

For cryptographic key management, the ISMS must answer five questions:

1. Which information assets, data flows and services require cryptographic protection?
2. Which keys, certificates, secrets and crypto services protect them?
3. Who owns, administers, approves and monitors those cryptographic assets?
4. How are generation, storage, use, rotation, escrow, recovery, revocation and destruction controlled?
5. What evidence proves that the controls operated as designed?

The ISO 27001 control spine for cryptographic key management

Clarysec treats cryptographic key management as a control chain, not a single control. In Zenith Controls: The Cross-Compliance Guide Zenith Controls, the topic maps primarily to ISO/IEC 27002:2022 control 8.24, Use of cryptography, with important supporting relationships to 5.17, Authentication information, and 5.23, Information security for use of cloud services.

That relationship matters. A key management failure is rarely just “bad encryption.” It is often an authentication problem, a cloud governance problem, a supplier problem, a logging gap or a change-management failure.

The Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint makes this operational in the Risk Management phase, Step 14, Risk Treatment Policies and Regulatory Cross-References. Its cryptography policy sample says the organization should define where cryptography is needed, approve algorithms and protocols, define key management, cover use cases such as full disk encryption and secure communications, and connect the policy to GDPR Article 32.

“Encryption keys must be stored securely (e.g. in a key vault/HSM) and access limited to authorized personnel.”
Attribution: Zenith Blueprint, Risk Management phase, Step 14, Risk Treatment Policies and Regulatory Cross-References Zenith Blueprint

In the Controls in Action phase, Step 20, the Zenith Blueprint goes deeper. Cryptography is not about “turning encryption on.” It is about embedding cryptography into design, policy and lifecycle management. That includes data at rest, data in transit, authentication of identities and transactions, approved algorithms, key vaults, HSMs, scheduled rotation, revocation and validation through penetration testing and code review.

What auditors expect when they ask for key evidence

Most audit findings start with a simple request: “Show me your encryption policy and key management records.”

Weak answers include:

• “The cloud provider encrypts everything by default.”
• “We use TLS.”
• “Secrets are in the vault.”
• “The engineering team handles rotation.”
• “The key is managed by the application.”

Those statements may be technically true, but they are not complete evidence. An ISO auditor will connect key management back to risk assessment, the Statement of Applicability, policy requirements, operational control and retained documentation. A NIST CSF assessor will ask whether cryptographic assets are identified, protected, monitored and recovered. A DORA auditor will look for board-approved ICT risk governance, third-party dependencies, incident management and resilience testing. A GDPR reviewer will ask whether encryption and key separation reduce risk to individuals and whether the controller can demonstrate accountability.

Clarysec’s Enterprise Cryptographic Controls Policy Cryptographic Controls Policy directly addresses the evidence gap:

“A centralized Key Management Register must be maintained to record all cryptographic keys, their lifecycle status, assigned custodians, and usage contexts.”
Attribution: Enterprise Policy, Cryptographic Controls Policy, Governance Requirements, clause 5.2 Cryptographic Controls Policy

That sentence changes the audit conversation. Instead of chasing tribal knowledge, the organization can show a register that links keys to assets, owners, data classifications, systems, cloud accounts, rotation dates, usage contexts and evidence.

For SMEs, Clarysec’s Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME scales the same expectation:

“The IT Support Provider must maintain an up-to-date inventory of cryptographic tools and certificates in use”
Attribution: SME Policy, Cryptographic Controls Policy-sme, Governance Requirements, clause 5.1.2 Cryptographic Controls Policy-sme - SME

A regulated financial institution may need HSM ceremonies, split knowledge, dual control, formal custodian appointments and quarterly access reviews. A small SaaS provider may start with a maintained inventory, approved algorithms, documented KMS ownership and rotation evidence. Both need governance that is proportionate to risk.

The key lifecycle your ISMS should control

A practical key management program follows the lifecycle. Each stage needs an owner, approved method, technical control, change record and audit evidence.

The Enterprise Cryptographic Controls Policy reinforces secure generation:

“Key Generation: Performed using secure hardware or software modules (e.g., HSMs, FIPS 140-2-validated systems).”
Attribution: Enterprise Policy, Cryptographic Controls Policy, Policy Implementation Requirements, clause 6.3.1 Cryptographic Controls Policy

It also specifies rotation:

“Key Rotation: Required at defined intervals or immediately upon compromise or role change.”
Attribution: Enterprise Policy, Cryptographic Controls Policy, Policy Implementation Requirements, clause 6.3.4 Cryptographic Controls Policy

For SMEs, the same principle appears in simpler operating language:

“Key rotation must occur in accordance with expiry schedules or upon suspected compromise”
Attribution: SME Policy, Cryptographic Controls Policy-sme, Policy Implementation Requirements, clause 6.3.4 Cryptographic Controls Policy-sme - SME

These clauses matter for NIS2 and DORA because stale or poorly governed keys are not only confidentiality weaknesses. They can become incident response blockers, supplier dependency issues, disaster recovery failures and customer notification problems.

Cloud KMS, HSM and BYOK: the shared responsibility trap

Cloud encryption is one of the most common sources of false assurance. A cloud provider may encrypt storage by default, but that does not automatically mean your organization has governed the key.

The Zenith Blueprint, Controls in Action phase, Step 23, explains ISO/IEC 27002:2022 control 5.23 by focusing on cloud governance, visibility and shared responsibility. It emphasizes that the provider may secure infrastructure, but the customer remains accountable for data, configurations, access policies and incident response readiness.

“Cloud providers secure the infrastructure, but you are still accountable for your data, your configurations, your access policies, and your incident response readiness.”
Attribution: Zenith Blueprint, Controls in Action phase, Step 23, Organizational controls 5.19-5.37 Zenith Blueprint

This is where cloud key responsibility becomes a board-level risk. A SaaS company may use provider-managed encryption for low-risk logs, customer-managed keys for customer databases, BYOK for regulated tenants and HSM-backed root keys for signing or tokenization. Each choice has compliance implications.

Clarysec’s Enterprise Cloud Usage Policy Cloud Usage Policy provides a clear control direction:

“Customer-managed keys (CMKs) or Bring Your Own Key (BYOK) shall be used where supported by the cloud provider.”
Attribution: Enterprise Policy, Cloud Usage Policy, Policy Implementation Requirements, clause 6.4.2 Cloud Usage Policy

This does not mean every cloud service must use BYOK. It means the organization should decide deliberately, based on risk, customer commitments, contractual requirements and recoverability.

DORA Article 28 and Article 30 make this especially relevant for financial entities. They require ICT third-party risk management, registers of ICT contractual arrangements, due diligence, audit and inspection rights, incident assistance, data protection and access, recovery and return provisions. If a cloud provider or SaaS supplier manages encryption keys for a critical or important function, that relationship must be visible in the ICT third-party register and contractual controls.

NIS2 also requires supply chain security, including supplier-specific vulnerabilities, cybersecurity practices and secure development procedures. If a critical supplier holds your keys, operates your KMS, provides your HSM, manages your certificate lifecycle or hosts encrypted backups, the supplier is part of your cryptographic control environment.

Algorithm approval and crypto-agility in 2026

A 2026 key management policy should not only list “AES-256” and “TLS 1.2 or later.” It should establish an approval and review process that supports crypto-agility. Crypto-agility means the organization can identify where algorithms, protocols, certificates and key lengths are used, assess exposure to weakness or deprecation, and migrate without panic.

Clarysec’s SME policy states:

“Only industry best-practice algorithms and protocols approved by the IT Support Provider may be used (e.g., AES-256, RSA 2048, TLS 1.2 or later)”
Attribution: SME Policy, Cryptographic Controls Policy-sme, Policy Implementation Requirements, clause 6.2.1 Cryptographic Controls Policy-sme - SME

It also requires documentation:

“All encryption methods (e.g., AES-256, TLS 1.2+) and key management processes must be documented”
Attribution: SME Policy, Cryptographic Controls Policy-sme, Governance Requirements, clause 5.3.1 Cryptographic Controls Policy-sme - SME

The audit-ready version is an approved cryptographic standard with:

• Allowed algorithms and protocols for data at rest, data in transit, signatures, password hashing, tokenization and backups.
• Disallowed algorithms, protocols and libraries.
• Minimum key lengths and certificate validity periods.
• Approved KMS, HSM, certificate authority and secrets management platforms.
• Secure random number generation requirements.
• Developer guidance for cryptographic libraries.
• Exception process for legacy systems.
• Review triggers for vulnerabilities, regulatory changes, supplier changes and post-quantum transition planning.

Post-quantum planning does not require every organization to replace all cryptography immediately. It does require inventory. Without a cryptographic inventory, you cannot know which systems use long-lived public-key encryption, which certificates protect critical services, where signing keys live or which vendors must support migration. The Key Management Register is not bureaucracy. It is the foundation of crypto-agility.

A 90-minute key management evidence sprint

Clarysec often uses a short evidence sprint with leadership, security, cloud and compliance teams. The goal is to turn scattered key knowledge into audit evidence quickly.

Step 1: Select one critical service

Choose a system that matters to NIS2, DORA or GDPR. Examples include customer identity, payment processing, transaction monitoring, production customer database, encrypted backup platform or customer-facing API.

Step 2: Open the Key Management Register

Use the Cryptographic Controls Policy requirement for a centralized register as the structure. If you do not have one yet, create a simple register with these fields:

Step 3: Trace access and dual control

For high-impact cryptographic operations, apply dual control and least privilege. The Enterprise Cryptographic Controls Policy states:

“Dual control and least privilege principles must be applied to sensitive cryptographic operations (e.g., root key imports, HSM administration).”
Attribution: Enterprise Policy, Cryptographic Controls Policy, Policy Implementation Requirements, clause 6.6.2 Cryptographic Controls Policy

Ask:

• Who can disable or delete the key?
• Who can change the key policy?
• Who can decrypt data directly?
• Are break-glass roles monitored and time-bound?
• Is MFA enforced for privileged key operations?
• Are privileged actions logged and reviewed?

Step 4: Pull five evidence records

Collect five records that prove the control works:

1. Key creation or import log.
2. Current KMS or HSM access policy.
3. Last key rotation change ticket.
4. SIEM query showing key usage or administrative actions.
5. Recovery or restore test evidence.

Step 5: Map to risk and regulation

Add a short risk statement: “Unauthorized use or loss of this key could expose EU personal data, disrupt customer service and impair recovery of critical systems.” Then map it to the relevant obligations.

In 90 minutes, the team can usually identify whether key governance is real or assumed.

Incident reporting: when key compromise starts the clock

A suspected key compromise is not automatically a reportable breach, but it can start the regulatory clock.

Under NIS2, essential and important entities must notify significant incidents affecting service provision without undue delay. The staged model includes an early warning within 24 hours of awareness, an incident notification within 72 hours, status updates where requested, and a final report no later than one month after the incident notification.

Under DORA, financial entities must detect, manage and notify ICT-related incidents, record incidents and significant cyber threats, classify incidents by severity and affected service criticality, communicate with stakeholders, report major incidents to senior management and competent authorities, conduct root-cause analysis and remediate. Outsourcing reporting may be possible, but responsibility remains with the financial entity.

Under GDPR, the question becomes whether a personal data breach occurred, meaning accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. Strong encryption with uncompromised keys can materially change breach risk analysis. Weak key management can undermine that argument.

Key compromise playbooks should define:

• How suspected key exposure is detected.
• Who declares a cryptographic incident.
• How affected data, services, customers and jurisdictions are identified.
• How keys are revoked or rotated.
• How dependent systems are restored.
• How evidence integrity is preserved.
• How legal, regulatory and customer notification decisions are made.

The Key Management Register becomes essential during this process. Without it, responders waste time identifying what a key protected. With it, they can scope impact quickly.

The audit lens: one control set, many evidence consumers

Different auditors approach cryptographic key management from different backgrounds, but they converge on the same evidence.

A strong audit package for cryptographic key management usually contains:

• Approved Cryptographic Controls Policy.
• Approved Cloud Usage Policy where cloud encryption is relevant.
• Cryptographic standard and algorithm list.
• Key Management Register.
• Certificate and secrets inventory.
• KMS, HSM and vault architecture.
• IAM and privileged access review evidence.
• Rotation and revocation records.
• Backup, escrow and recovery test evidence.
• Logging and monitoring rules for key activity.
• Supplier and cloud shared responsibility mapping.
• Incident playbook for suspected key compromise.
• Exceptions and risk acceptances.
• Management review and audit remediation records.

This package turns a control assertion into proof.

Common findings in key management audits

The most common findings are avoidable:

1. No single inventory of keys, certificates and cryptographic tools.
2. Cloud provider default encryption treated as full key governance.
3. No owner or custodian assigned to production keys.
4. Rotation exists for certificates, but not for application keys or database CMKs.
5. Secrets and keys mixed in the same vault without classification.
6. Developers can create keys outside approved patterns.
7. No evidence that KMS administrators are reviewed.
8. Recovery procedures exist but have never been tested.
9. Key compromise is not included in incident response playbooks.
10. Legacy algorithms remain in internal services because nobody owns remediation.
11. BYOK commitments are made in customer contracts but not reflected in operations.
12. Supplier-managed encryption is not included in vendor risk reviews.

Each finding maps back to governance. That is why cryptography cannot be treated as a purely engineering project. It must connect to ISMS scope, risk treatment, policy, suppliers, cloud, access, logging, incidents and continuity.

Make key governance audit-ready before the next incident

If your organization is preparing for NIS2, DORA, GDPR Article 32 evidence, ISO/IEC 27001:2022 certification or post-quantum crypto-agility, start with one question: can you produce a complete Key Management Register today?

If not, Clarysec can help you build the control system around it.

Use the Zenith Blueprint Zenith Blueprint to structure the work through Risk Management phase Step 14 and Controls in Action phase Step 20. Use Zenith Controls Zenith Controls to map ISO/IEC 27002:2022 controls 8.24, 5.17 and 5.23 across NIS2, DORA, GDPR, NIST and audit expectations. Use Clarysec’s Cryptographic Controls Policy Cryptographic Controls Policy, Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME and Cloud Usage Policy Cloud Usage Policy to turn requirements into operating rules.

The practical next step is simple: pick one critical service, inventory its keys, prove ownership, validate access, pull rotation evidence and test recovery. If that takes more than a day, your cryptographic governance needs attention before the regulator, auditor or incident response team asks the same question under pressure.