Document ID: ISMS-POL-007 | Version: 1.0 | Date: March 2026 | Classification: Internal | Owner: Information Security Manager
Purpose and Scope
This policy defines the requirements for the use of cryptographic controls to protect the confidentiality, integrity, and authenticity of information across [Organisation Name], in accordance with ISO/IEC 27001:2022 Annex A control 8.24.
It applies to all systems, applications, and services that store, process, or transmit information classified as Internal or above, including cloud-hosted services, internal applications, developer tools, and communication systems. All employees, contractors, and suppliers who implement or manage cryptographic systems on behalf of the organisation must comply with this policy.
1. Approved Cryptographic Algorithms
The following algorithms and configurations are approved for use. New implementations must use these standards; existing systems using deprecated algorithms must be migrated within the timelines specified in the exceptions process.
| Use Case | Approved Algorithm | Minimum Key / Parameter | Notes |
|---|---|---|---|
| Symmetric encryption — data at rest | AES-GCM | 256-bit key | Preferred for all data at rest on disk, in database, and on backup media; GCM mode provides both confidentiality and integrity |
| Symmetric encryption — general | AES-CBC or AES-CTR | 256-bit key | CBC requires proper random IV for each encryption; CTR requires unique nonce; GCM preferred |
| Asymmetric encryption / key exchange | ECDH with ECDSA | NIST P-256 or P-384 | Preferred over RSA for new implementations; smaller key size with equivalent or stronger security |
| Asymmetric encryption / key exchange | RSA-OAEP | 4096-bit minimum | PKCS#1 v1.5 padding prohibited; use OAEP with SHA-256 only |
| Hashing — integrity verification | SHA-256 / SHA-384 / SHA-512 | N/A | SHA-3 variants also acceptable; SHA-1 prohibited for all new uses |
| Password hashing / key derivation | Argon2id | Memory: 64 MB minimum; iterations: 3 minimum; parallelism: 4 | bcrypt (cost factor 12+) and scrypt acceptable alternatives; PBKDF2 with SHA-256 and 600,000+ iterations acceptable for FIPS environments |
| Transport encryption | TLS 1.3 | N/A | TLS 1.3 preferred for all new implementations; TLS 1.2 with approved cipher suites permitted; TLS 1.1 and below prohibited |
| TLS cipher suites (TLS 1.2) | ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES128-GCM-SHA256 | N/A | Only AEAD cipher suites permitted; RC4, 3DES, and NULL cipher suites prohibited |
| SSH | Ed25519 | N/A | ECDSA with P-256 acceptable; RSA 4096-bit acceptable; RSA below 2048-bit prohibited; DSA prohibited |
| Code signing | ECDSA with P-256 or RSA-PSS | P-256 / 4096-bit | All production release artefacts (binaries, container images, scripts) must be signed before deployment |
| Email encryption (external) | S/MIME or OpenPGP (PGP) | RSA 4096-bit / AES-256 | Required for external transmission of Confidential or Restricted documents; optional for Internal |
| File / disk encryption | BitLocker (Windows) with AES-256 | 256-bit | FileVault 2 (macOS) acceptable; VeraCrypt for cross-platform portable media |
| Certificate signing | SHA-256 with RSA or ECDSA | RSA 4096-bit / P-256 | SHA-1 signed certificates not trusted; MD5 signed certificates not trusted |
2. Prohibited Algorithms and Configurations
The following algorithms, protocols, and configurations are explicitly prohibited. They must not be used in any new system. Existing systems using prohibited algorithms must have a documented remediation plan approved by the CISO.
| Prohibited Item | Category | Reason for Prohibition |
|---|---|---|
| MD5 | Hash function | Practical collision attacks demonstrated since 2004; completely broken for any security purpose including password hashing, certificate signing, and HMAC |
| SHA-1 | Hash function | Collision attacks demonstrated (SHAttered attack, 2017); deprecated by NIST; prohibited in TLS certificates since 2017; prohibited for all security uses |
| DES | Symmetric cipher | 56-bit key — exhaustive key search feasible; broken in 22 hours in 1999 EFF Deep Crack attack |
| 3DES / Triple-DES | Symmetric cipher | Deprecated by NIST in 2017; Sweet32 birthday attack; maximum 64-bit block size creates practical vulnerability |
| RC4 | Stream cipher | Multiple practical biases and attacks; prohibited in TLS by RFC 7465 (2015); forbidden in WPA2 |
| SSL 2.0 / SSL 3.0 | Protocol | Completely broken; POODLE attack (2014) on SSL 3.0; DROWN attack leverages SSL 2.0 presence |
| TLS 1.0 | Protocol | BEAST attack; padding oracle vulnerabilities; deprecated by RFC 8996 (2021) |
| TLS 1.1 | Protocol | No AEAD cipher suites; deprecated by RFC 8996 (2021) |
| RSA with PKCS#1 v1.5 padding | Padding scheme | Bleichenbacher oracle attack; robot attack; padding oracle vulnerability |
| Elliptic curve P-192 (secp192r1) | Elliptic curve | Key size provides insufficient security margin (less than 96-bit equivalent); not recommended by NIST post-2030 |
| Dual_EC_DRBG | PRNG | Potential NSA backdoor (NIST withdrew recommendation 2014); abandoned by all major implementors |
| DSA (any key size) | Signature | Vulnerable to nonce reuse leading to private key recovery; superseded by ECDSA and EdDSA |
| Export-grade ciphers (EXPORT, eNULL, aNULL) | Cipher suite | Deliberately weakened; FREAK and Logjam attacks; all prohibited in modern TLS |
3. Key Management Lifecycle
3.1 Key Generation
- All cryptographic keys must be generated using a cryptographically secure pseudorandom number generator (CSPRNG) — not a general-purpose random number generator.
- Keys must be generated in a secure, controlled environment: on a dedicated HSM, within an approved cloud KMS (AWS KMS, Azure Key Vault), or on a hardened system with an approved software CSPRNG.
- Keys must never be generated on shared, untrusted, or development systems.
- The generation of Restricted-classification keys must be witnessed and logged.
3.2 Key Storage
- Private keys must never be stored in:
- Source code or version control systems (even private repositories)
- Plaintext configuration files
- Shared file systems without encryption
- Environment variables in CI/CD logs
- Approved storage locations:
- AWS Key Management Service (KMS) for cloud-hosted key material
- Azure Key Vault for Azure-hosted services
- Hardware Security Module (HSM) for on-premises critical keys
- Approved secrets management tool (e.g., HashiCorp Vault, AWS Secrets Manager) for application secrets
- Encrypted backups of key material must be maintained and tested annually.
3.3 Key Distribution
- Private keys must never be transmitted across any network, even encrypted.
- Public keys must be distributed via authenticated channels (e.g., certificate authority signed certificates, authenticated key servers).
- Where PKI is used, certificates must be issued by a trusted Certificate Authority; self-signed certificates are prohibited in production.
- Symmetric keys must be exchanged via asymmetric cryptography (e.g., RSA-OAEP or ECDH key agreement) — never transmitted in plaintext.
3.4 Key Usage
- Each key must be used for a single, defined purpose: an encryption key must not also be used as a signing key.
- Keys must not be reused across different services, environments (development vs production), or clients.
- Service accounts and applications must each have unique keys; shared keys across services are prohibited.
3.5 Key Rotation
| Key Type | Rotation Frequency | Trigger for Immediate Rotation |
|---|---|---|
| Data encryption keys (symmetric — data at rest) | Every 12 months | Suspected compromise; personnel change with key access |
| TLS/SSL certificates | Before expiry (alert at 30 days remaining; auto-renew at 14 days) | Certificate compromise; CA compromise |
| SSH host and user keys | Every 12 months | Compromise; staff offboarding |
| API keys / service account keys | Every 12 months | Compromise; accidental exposure in logs or code |
| Cryptographic master keys (HSM or KMS CMK) | Every 24 months | Compromise; regulatory requirement |
| Code signing keys | Every 24 months | Compromise; CA compromise |
All rotations must be logged in the Key Register with the old key reference, rotation date, and new key reference.
3.6 Key Revocation
- Keys must be revoked immediately upon confirmed or suspected compromise, or when the key holder departs the organisation.
- For PKI: revoke via Certificate Revocation List (CRL) or OCSP stapling; ensure relying parties are using current revocation information.
- For application keys (API keys, SSH keys): revoke via the relevant management console; confirm revocation in system logs.
- All revocations must be documented in the Key Register: key ID, reason for revocation, date, and revoked by.
3.7 Key Destruction
- Keys that are no longer needed must be securely destroyed.
- Software keys: cryptographic erasure (overwrite key material with zeros; delete all copies including backups).
- HSM keys: perform HSM zeroisation per vendor documentation.
- Cloud KMS keys: delete key material from KMS and confirm deletion; note that some KMS services enforce a deletion delay (e.g., AWS KMS 7-30 day waiting period).
- All destructions must be logged in the Key Register: key ID, destruction method, date, and witness (for Restricted keys).
4. Certificate Management
| Item | Requirement |
|---|---|
| Certificate inventory | All TLS/SSL certificates must be recorded in the Certificate Inventory with domain, expiry date, responsible owner, and CA |
| Expiry alerting | Automated alerts must be configured at 60 days, 30 days, and 14 days before expiry; alerts sent to IT Manager and ISM |
| Auto-renewal | Use ACME protocol (Let’s Encrypt or internal CA) for auto-renewal where supported; test auto-renewal 30 days before expiry |
| Wildcard certificates | Permitted where managing many subdomains of the same domain; private key must be stored in KMS; scope must be documented |
| Self-signed certificates | Prohibited in production environments; permitted in development and test environments with explicit CISO approval; must not be deployed to client-facing systems under any circumstances |
| Certificate Authority | Internal PKI or commercial CA (DigiCert, Sectigo, Let’s Encrypt) only; do not use unknown or untrusted CAs |
| Certificate transparency | All public certificates must be logged in Certificate Transparency logs; monitor CT logs for unauthorised certificates issued for organisation domains |
5. Exceptions
Any deviation from this policy (e.g., a legacy integration requiring TLS 1.1, an inherited system using RSA 2048-bit keys) requires:
- Written request to the ISM documenting: the affected system, the deviation, the technical reason, and the proposed compensating controls.
- Written approval from the CISO with a defined remediation timeline (maximum 12 months per exception).
- Recording in the Exceptions Register with quarterly review.
- Communication to the relevant System Owner.
No exception may be renewed more than twice for the same system and algorithm — permanent exceptions are not permitted.
6. Review History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | March 2026 | [ISM Name] | Initial issue |