Statement of Applicability — Use of Cryptography
Template. Replace every […] placeholder. Delete rows that do not apply — but record why in §7 rather than deleting silently; an auditor reads omissions as gaps.
| Field |
Value |
| Document ID |
[e.g. ISMS-SOA-08.24] |
| Version |
[0.1 — draft] |
| Classification |
[Internal] |
| Document owner |
[IS Manager] |
| Approved by |
[name / role] on [date] |
| Scope entities |
[Ahola Group entities in scope] |
| Review cycle |
[Annually, and on material change to the cryptographic estate] |
| Next review |
[date] |
1. Purpose
This document states which cryptographic controls are applicable to [organisation], how they are implemented, who owns them, and what evidence demonstrates that they operate. It is the controlling statement for ISO/IEC 27001:2022 Annex A 8.24 Use of cryptography and supports the obligations listed in §3.
2. Scope
| Dimension |
In scope |
Out of scope (and why) |
| Information systems |
[e.g. all production and corporate systems] |
[…] |
| Environments |
[production / staging / development] |
[…] |
| Locations & platforms |
[e.g. on-prem hypervisors, cloud IaaS, SaaS, endpoints] |
[…] |
| Data classifications |
[e.g. Confidential and above; personal data of any class] |
[…] |
| Third parties |
[processors handling in-scope data] |
[…] |
3. Regulatory and standard drivers
| Driver |
Requirement (summary) |
Where addressed |
| ISO/IEC 27001:2022 A.8.24 |
Rules for effective use of cryptography, including key management |
This document |
| ISO/IEC 27001:2022 A.5.31 |
Legal, statutory and contractual requirements, incl. any national restrictions on cryptography |
§3 note, §11 |
| GDPR Art. 32(1)(a) |
Encryption of personal data as an appropriate technical measure |
§7 rows for personal-data systems |
| GDPR Art. 34(3)(a) |
Encryption may remove the obligation to notify data subjects of a breach |
§7, §12 |
| NIS2 Art. 21(2)(h) |
Policies and procedures on the use of cryptography and, where appropriate, encryption |
This document |
[Customer / contractual] |
[e.g. specific TLS or key-length obligations in customer contracts] |
[…] |
[Other] |
[…] |
[…] |
Note on legal restrictions: [state whether any jurisdiction in which the organisation operates restricts the import, export, or use of cryptography, or mandates lawful-access provisions. If none apply, say so explicitly.]
4. Roles and responsibilities
| Role |
Responsibility for cryptography |
[IS Manager] |
Owns this document; approves algorithm standards and exceptions |
[IT Manager] |
Implements and operates controls; maintains the cryptographic inventory |
[DPO / Compliance Manager] |
Confirms adequacy for personal-data processing; reviews DPIA linkage |
[Key custodian(s)] |
[generation, escrow, recovery of master/root keys — name at least two for separation of duties] |
[System owners] |
Apply the standard within their systems; raise exceptions |
[Internal audit / external auditor] |
Tests control effectiveness against the evidence in §12 |
5. Approved algorithms and minimum parameters
| Purpose |
Approved algorithm(s) |
Minimum key / parameter |
Notes |
| Symmetric encryption |
[e.g. AES-GCM, ChaCha20-Poly1305] |
[256-bit] |
[AEAD modes required] |
| Asymmetric encryption / key exchange |
[e.g. ECDH P-256/P-384, X25519, RSA-OAEP] |
[RSA ≥ 3072; EC ≥ 256] |
[…] |
| Digital signatures |
[e.g. ECDSA P-256, Ed25519, RSA-PSS] |
[…] |
[…] |
| Hashing |
[e.g. SHA-256, SHA-384, SHA-3] |
[≥ 256-bit output] |
[…] |
| Password / credential storage |
[e.g. Argon2id, scrypt, bcrypt] |
[state work factors] |
[…] |
| Transport |
[TLS 1.3; TLS 1.2 with AEAD ciphers only] |
[…] |
[cipher suite allowlist: reference or attach] |
| VPN / tunnelling |
[e.g. WireGuard, IKEv2/IPsec] |
[…] |
[…] |
| Random number generation |
[OS CSPRNG / HSM] |
— |
[no application-level custom RNG] |
| Full-disk encryption |
[…] |
[…] |
[recovery key escrow location] |
Authoritative reference used: [e.g. BSI TR-02102, NIST SP 800-131A Rev.3, SOG-IS agreed mechanisms, Traficom/NCSC-FI guidance] — cite one so algorithm choices are defensible rather than opinion.
6. Prohibited and deprecated
| Prohibited / deprecated |
Status |
Remediation deadline |
Owner |
| SSL 2.0/3.0, TLS 1.0/1.1 |
[Prohibited] |
[…] |
[…] |
| MD5, SHA-1 (signatures) |
[Prohibited] |
[…] |
[…] |
| DES, 3DES, RC4, Blowfish |
[Prohibited] |
[…] |
[…] |
| RSA < 2048-bit |
[Prohibited] |
[…] |
[…] |
| ECB mode, unauthenticated CBC |
[Prohibited] |
[…] |
[…] |
Self-signed certificates on [internal services] |
[Deprecated / exception required] |
[…] |
[…] |
[Legacy system X using …] |
[Exception — see §11] |
[…] |
[…] |
7. Applicability statement
The core table. For each use case: is cryptography applied, by what mechanism, who holds the key, and what proves it.
| # |
Use case |
Applicable? |
Mechanism / technology |
Key holder & storage |
Justification or exclusion rationale |
Evidence ref. |
| 7.1 |
Endpoint disk encryption |
[Yes] |
[…] |
[…] |
[Loss/theft of mobile devices; GDPR Art. 32] |
[…] |
| 7.2 |
Server / VM volume encryption |
[…] |
[…] |
[…] |
[…] |
[…] |
| 7.3 |
Backup encryption (on-site) |
[…] |
[client-side vs. at-rest — state which] |
[…] |
[…] |
[…] |
| 7.4 |
Backup encryption (off-site / object storage) |
[…] |
[…] |
[…] |
[key must not be recoverable only from the encrypted set] |
[…] |
| 7.5 |
Database encryption at rest |
[…] |
[…] |
[…] |
[…] |
[…] |
| 7.6 |
Field / column-level encryption of personal data |
[…] |
[…] |
[…] |
[…] |
[…] |
| 7.7 |
Removable media |
[…] |
[…] |
[…] |
[or: prohibited by policy — reference it] |
[…] |
| 7.8 |
Public-facing services in transit |
[…] |
[TLS version + HSTS] |
[…] |
[…] |
[…] |
| 7.9 |
Internal / east-west traffic |
[…] |
[…] |
[…] |
[…] |
[…] |
| 7.10 |
Site-to-site and remote access |
[…] |
[…] |
[…] |
[…] |
[…] |
| 7.11 |
Administrative access (SSH / RDP / management planes) |
[…] |
[key types, MFA binding] |
[…] |
[…] |
[…] |
| 7.12 |
Email in transit |
[…] |
[MTA-STS, DANE, opportunistic TLS] |
— |
[…] |
[…] |
| 7.13 |
Email / file end-to-end encryption |
[…] |
[…] |
[…] |
[…] |
[…] |
| 7.14 |
Managed file transfer / EDI with partners |
[…] |
[…] |
[…] |
[per-partner requirements] |
[…] |
| 7.15 |
Secrets, credentials and API keys |
[…] |
[secret manager; envelope encryption] |
[…] |
[…] |
[…] |
| 7.16 |
Password / authenticator storage |
[…] |
[…] |
— |
[…] |
[…] |
| 7.17 |
Code, artifact and container image signing |
[…] |
[…] |
[…] |
[supply-chain integrity] |
[…] |
| 7.18 |
Log and audit-trail integrity |
[…] |
[…] |
[…] |
[…] |
[…] |
| 7.19 |
Pseudonymisation / tokenisation of personal data |
[…] |
[…] |
[…] |
[GDPR Art. 25, Art. 32] |
[…] |
| 7.20 |
SaaS / third-party held data |
[…] |
[provider-managed vs. customer-managed keys] |
[…] |
[record in DPA / vendor register] |
[…] |
| 7.21 |
[…] |
[…] |
[…] |
[…] |
[…] |
[…] |
8. Key management lifecycle
| Stage |
Procedure |
Owner |
Frequency / trigger |
Evidence |
| Generation |
[where, by what, entropy source; dual control for root keys] |
[…] |
[…] |
[…] |
| Distribution |
[…] |
[…] |
[…] |
[…] |
| Storage & protection |
[HSM / KMS / secret manager; never in code or config repos] |
[…] |
— |
[…] |
| Access control |
[who can read, who can only use; separation of duties] |
[…] |
— |
[…] |
| Rotation |
[per key class — state intervals] |
[…] |
[…] |
[…] |
| Escrow / recovery |
[custodians, split knowledge, where the recovery material physically lives] |
[…] |
[test annually] |
[…] |
| Compromise response |
[revoke, re-key, re-encrypt; link to incident process] |
[…] |
[on suspicion] |
[…] |
| Retirement & destruction |
[crypto-erase, verified destruction, retention of keys needed for archived data] |
[…] |
[…] |
[…] |
Key inventory: maintained at [location], listing key ID, purpose, algorithm, owner, creation date, rotation due, system(s) served.
9. Certificate management
| Item |
Detail |
| Public CA(s) used |
[…] |
| Internal CA |
[yes/no; root protection] |
| Issuance method |
[e.g. ACME with DNS-01 validation] |
| Storage / distribution |
[…] |
| Maximum validity |
[…] |
| Expiry monitoring & alerting |
[tool, threshold, who is paged] |
| Certificate inventory |
[location] |
| Revocation procedure |
[…] |
10. Crypto-agility and post-quantum readiness
| Question |
Answer |
| Can algorithms be changed without redesigning the system? |
[per system class] |
| Is there an inventory of where each algorithm is used? |
[…] |
| Data with confidentiality lifetime beyond ~2035 (harvest-now-decrypt-later exposure) |
[identify it] |
| PQC migration position |
[e.g. monitoring; hybrid X25519-MLKEM768 adopted where vendor-supported] |
| Owner and review date |
[…] |
11. Exceptions
| ID |
System / control deviated from |
Reason |
Compensating control |
Risk accepted by |
Expiry / review |
[EX-01] |
[…] |
[…] |
[…] |
[…] |
[…] |
Exceptions require [approver role] approval, a compensating control, and an expiry date. No open-ended exceptions.
12. Monitoring, evidence and verification
| Verification activity |
Method |
Frequency |
Owner |
Evidence location |
| TLS configuration scan of external services |
[…] |
[…] |
[…] |
[…] |
| Disk-encryption compliance across the estate |
[…] |
[…] |
[…] |
[…] |
| Backup restore test including key recovery |
[…] |
[…] |
[…] |
[…] |
| Certificate expiry and inventory reconciliation |
[…] |
[…] |
[…] |
[…] |
| Key rotation adherence |
[…] |
[…] |
[…] |
[…] |
| Prohibited-algorithm detection |
[…] |
[…] |
[…] |
[…] |
| Third-party crypto attestation review |
[…] |
[…] |
[…] |
[…] |
| Document |
Reference |
| Information Security Policy |
[…] |
| Access Control Policy |
[…] |
| Backup and Recovery Policy |
[…] |
| Secure Development Policy |
[…] |
| Supplier Security / DPA register |
[…] |
| Incident Response Plan |
[…] |
| Risk register entries |
[IDs] |
14. Version history
| Version |
Date |
Author |
Change |
[0.1] |
[…] |
[…] |
Initial draft |