NIS2 Art.21.2h: Cryptography and Encryption Policies
What This Control Requires
The measures referred to in paragraph 1 shall include at least the following: (h) policies and procedures regarding the use of cryptography and, where appropriate, encryption.
In Plain Language
Encryption done properly protects your data even when other defences fail. Done badly - or inconsistently - it creates a false sense of security. NIS2 expects a deliberate, managed approach to cryptography rather than ad-hoc implementations scattered across the organisation. Your cryptography policy should cover data encryption at rest and in transit, key management through its full lifecycle, digital signatures and certificates, algorithm selection, and any regulatory requirements around encryption. It needs to be specific enough to actually guide implementation decisions. The directive says "where appropriate" - recognising that not all data needs the same level of protection. Use a risk-based approach to decide what needs encrypting, at what strength, and how you manage the keys. That said, some things are non-negotiable: data in transit over public networks and sensitive data at rest should always be encrypted.
How to Implement
Draft a cryptography and encryption policy covering approved algorithms and minimum key lengths, encryption requirements for data at rest and in transit, key management procedures, certificate management, and who owns what. Audit your current cryptographic landscape. Identify where encryption is already in use, which algorithms and key lengths are in play, and where the gaps are. This gives you a clear starting point. For data in transit, enforce TLS 1.2 as a minimum for all external communications, with TLS 1.3 preferred where supported. Encrypt internal communications between systems handling sensitive data too. Disable SSL, TLS 1.0, and TLS 1.1 completely. For data at rest, encrypt all sensitive data including databases, file systems, backups, and portable media. Use full-disk encryption on endpoints and server volumes. Apply field-level encryption for PII and other sensitive database columns. Build a key management programme covering the full lifecycle: generation using cryptographically secure random number generators, secure distribution, storage in HSMs or key vaults, rotation on defined schedules, revocation when compromised, and secure destruction. For critical keys, use hardware security modules or cloud-based key management services. Set up certificate management with a complete inventory, automated renewals where possible, and expiry monitoring. Define clear procedures for handling incidents like private key compromise. Keep an eye on the quantum computing horizon. For data that needs long-term protection, start planning your post-quantum cryptography migration strategy now.
Evidence Your Auditor Will Request
- Cryptography and encryption policy approved by management
- Inventory of cryptographic implementations across the organisation
- Key management procedures and evidence of implementation
- TLS configuration reports showing approved protocol versions and cipher suites
- Certificate inventory and management records
Common Mistakes
- Outdated cryptographic algorithms or protocol versions still in use (SSL, TLS 1.0, SHA-1)
- No formal key management process; keys stored insecurely or never rotated
- Encryption applied inconsistently, with gaps in data at rest or internal communications
- Self-signed certificates used in production without proper management
- No monitoring for certificate expiration leading to service outages
Related Controls Across Frameworks
Frequently Asked Questions
What encryption algorithms are considered acceptable under NIS2?
Is end-to-end encryption required?
Track NIS2 compliance in one place
AuditFront helps you manage every NIS2 control, collect evidence, and stay audit-ready.
Start Free Assessment