NIS2 makes cryptography board-level risk because the directive links written policy, operational evidence, and management accountability. If the organisation cannot prove that encryption, key management, and related procedures are implemented and maintained, it faces regulatory findings, substantial fines, and in some jurisdictions personal liability for management. That shifts cryptography from best practice to a legal obligation with executive oversight.
Why cryptography becomes an executive accountability issue under NIS2
NIS2 changes the question from whether encryption is “implemented” to whether leadership can demonstrate that cryptographic safeguards are governed, maintained, and reviewed as part of the organisation’s security posture. That matters because the directive treats security measures as management obligations, not just technical choices made by engineers. For the official legal basis, see the NIS2 Directive - official EU legal text.
In practice, boards are no longer insulated from the consequences of weak encryption governance. If key handling, certificate lifecycle, algorithm choices, backup protection, or exception handling are undocumented or inconsistent, the organisation can fail an audit even if some encryption is deployed. The risk is therefore not only confidentiality loss but also inability to show control effectiveness, which is what turns a technical issue into a governance problem.
In practice, many organisations discover that cryptography was never truly board-visible only after a regulator or auditor asks for evidence the technical team cannot easily produce.
What counts as proof that cryptography is actually governed
Operationally, NIS2 pushes organisations to treat cryptography as a managed control set with ownership, evidence, and review cycles. That means leadership should be able to point to policy, standards, decision records, and operational artefacts that show encryption is not ad hoc. The question is not whether strong algorithms exist somewhere in the environment, but whether their use is justified, current, monitored, and tied to business-critical assets.
A useful way to think about it is:
- Policy defines when encryption is required and who approves exceptions.
- Standards define approved algorithms, key lengths, and protocol baselines.
- Operations prove key rotation, certificate renewal, storage, and revocation are working.
- Oversight shows the board or senior management receives assurance on gaps, exceptions, and remediation.
This is also where cryptography intersects with resilience. If keys are lost, mishandled, expired, or inaccessible during recovery, encrypted data may become unavailable even when the original security objective was protection. For broader context on control-oriented governance, the NIST Cybersecurity Framework 2.0 is useful because it frames security as an organisational outcome rather than a single technical feature.
The guidance breaks down when an organisation can describe encryption in architecture terms but cannot produce evidence that the control is owned, tested, and continuously maintained.
Where the board-level risk is highest, and where organisations overstate maturity
Tighter cryptographic governance often increases operational overhead, requiring organisations to balance assurance against certificate, key, and exception-management complexity.
The highest-risk areas are usually not the encryption primitives themselves, but the lifecycle around them: key generation, storage, access, rotation, revocation, backup recovery, and change control. A board should care because failures in those areas create both direct exposure and regulatory defensibility problems. A control that cannot be evidenced under scrutiny is functionally weaker than a control that is fully documented but slightly less ambitious.
There is also a common mismatch between vendor claims and organisational reality. Many teams assume that because TLS is enabled, disks are encrypted, or a cloud provider offers managed key services, the obligation is met. That is not necessarily true. NIS2 is about accountability across the control environment, so delegated services still require decisions, oversight, and assurance. In security programmes with multiple subsidiaries, inherited controls, or shared services, the challenge is often proving consistent governance rather than deploying another tool. For related operational assurance and control benchmarking, PCI DSS v4.0 is a useful comparator because it also treats cryptographic protection as something that must be maintained and evidenced, not merely stated.
Where this breaks down most often is in organisations that equate “cryptography present” with “cryptography governed”, because that assumption ignores evidence quality, exception handling, and management accountability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while NIS2 and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | Article 20 — Management Body Accountability | Makes senior management accountable for cyber risk oversight and security measures. |
| Article 21 — Cybersecurity Risk-Management Measures | Requires appropriate technical and organisational measures, including protective controls. | |
| Article 23 — Reporting Obligations | Makes control failures and significant incidents part of formal regulatory accountability. | |
| Recommendation — Assign board oversight for cryptography governance and require evidence of control effectiveness. Document cryptography policies, key management, and exception handling as managed security measures. Link cryptographic control failures to reporting workflows and escalation criteria. | ||
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Supports governance of security controls as part of organisational risk decisions. |
| Recommendation — Embed cryptography oversight into enterprise risk decisions and assurance reporting. | ||
| CIS Controls v8 | 3 — Data Protection | Addresses encryption and related protection for sensitive information. |
| 5 — Account Management | Key and certificate administration depends on controlled privileged access. | |
| Recommendation — Apply encryption and handling standards to sensitive data and verify they stay enforced. Restrict access to cryptographic administration and review privileged accounts regularly. | ||
| ISO/IEC 42001:2023 | A.5 — Policies for AI Systems | Only weakly relevant if cryptography supports AI governance; omitted if not central. |
Practitioner Guidance
What to prioritise: Put ownership around the evidence chain, not just the control itself. Boards should ask who can prove, on demand, that encryption policy, key management, certificate handling, and exception approvals are current and reviewed.
What to verify: Check whether the organisation can produce a complete trail for the most sensitive systems: policy, standards, implementation status, renewal records, incident handling, and unresolved exceptions. If any of those are missing, the control is not yet board-grade even if the technology is deployed.
Decision rule: If cryptography protects regulated, high-value, or recovery-critical data, treat failures in governance as business risk, not just engineering debt. If it is only a point design choice with no assurance evidence requirement, the issue is narrower and should be handled as operational control hygiene.
What practitioners underestimate: The hardest part is often not selecting encryption methods, but demonstrating that keys, certificates, and recovery dependencies remain trustworthy over time. That is the point where technical control becomes executive accountability.
Practitioner takeaway: Under NIS2, cryptography is board-level because the organisation must be able to defend the control as governed, evidenced, and continuously maintained, not merely enabled.
Related resources from NHI Mgmt Group
- Who should own the translation of technical risk into board-level language?
- When does identity security become a business risk rather than a technical issue?
- Why do AI systems make NHI risk harder to control?
- When does indirect prompt injection become a business risk rather than a technical curiosity?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
