Template draft. Replace everything in [square brackets] with your own decision,
delete what does not describe what you really do, and approve it through your own document control. It is not legal
advice and does not make an organisation compliant or certified.
1. Purpose
This policy makes sure that confidentiality, integrity, authenticity and non-repudiation of information are protected by cryptography that is strong enough, correctly implemented and managed through the whole life of every key. It also makes sure that cryptography used by the Organisation meets legal, regulatory and contractual obligations.
2. Scope
The policy covers every use of cryptography in systems operated by or for the Organisation: data at rest, data in transit, data in use where confidential computing is deployed, digital signatures, authentication secrets, code signing, certificates, tokens and backups. It applies to employees, contractors and suppliers who design, build, operate or buy such systems.
- In scope: disks and databases, files, mobile devices, email, web and API traffic, remote access, wireless, backup media, secrets used by applications, hardware security modules and cloud key services.
- Out of scope: cryptography embedded in a third-party product that the Organisation cannot configure, where the supplier has given written assurance; such cases are recorded as a supplier risk.
3. Terms and Definitions
| Term | Meaning |
|---|
| Symmetric encryption | One secret key both encrypts and decrypts. Used for bulk data protection. |
| Asymmetric encryption | A key pair is used: a public key shared widely and a private key kept secret. Used for key exchange and signatures. |
| Hash function | A one-way function that produces a fixed-length digest. Used for integrity checks and, with salting and stretching, for password storage. |
| Key lifecycle | Generation, distribution, storage, use, rotation, revocation, archive, recovery and destruction of a key. |
| Hardware security module (HSM) | A tamper-resistant device or managed service that generates and holds keys and performs cryptographic operations without exposing the key. |
| Certificate authority (CA) | An entity that issues and signs digital certificates that bind a public key to an identity. |
| Crypto-period | The time during which a key may be used for protecting data before it must be replaced. |
4. Roles and Responsibilities
| Role | Responsibilities |
|---|
| Head of IT Security (document owner) | Owns this policy and the approved algorithm standard, approves exceptions, reviews cryptographic risks and monitors external guidance on weak algorithms. |
| Key custodian | Generates, stores, rotates, revokes and destroys keys under dual control, and keeps the key inventory current. |
| System owner | Ensures the system uses approved cryptography for the data it holds and requests keys and certificates through the defined process. |
| Application and infrastructure engineers | Implement cryptography using approved libraries and services, never custom algorithms, and keep secrets out of source code. |
| Information security manager | Reviews designs, scans for weak protocols and expired certificates, and reports findings. |
| Legal and compliance lead | Advises on legal limits on use, import or export of cryptography and on lawful access obligations. |
| Activity | Responsible | Accountable | Consulted | Informed |
|---|
| Maintain the approved algorithm and key length standard | Head of IT Security | Head of IT Security | Key custodian, engineers | System owners |
| Generate and rotate keys | Key custodian | Head of IT Security | System owner | Information security manager |
| Request and renew certificates | System owner | System owner | Key custodian | Service desk |
| Review cryptographic design of new systems | Information security manager | Head of IT Security | Engineers, system owner | Project manager |
| Respond to a suspected key compromise | Key custodian | Head of IT Security | Incident response lead, system owner | Management |
| Scan for weak protocols and expiring certificates | Information security manager | Head of IT Security | System owners | Key custodian |
5. Cryptography Policy Statements
5.1 When cryptography is required
| Information or channel | Minimum protection |
|---|
| Confidential or restricted data at rest on servers, databases and cloud storage | Encryption with approved algorithms; keys managed in a key management service or HSM, not stored beside the data |
| Laptops, mobile devices and removable media | Full-disk or full-device encryption enforced by the endpoint management tool; no exceptions for devices that leave the premises |
| Data in transit over public or untrusted networks, and between internal tiers handling confidential data | TLS version [1.2] or higher, or an approved VPN; certificates from a trusted authority |
| Email carrying restricted data outside the Organisation | Transport encryption as a minimum; message-level encryption or secure file sharing for restricted data |
| Backups and archives | Encrypted as set out in the Backup and Restoration Policy; key held separately |
| Passwords and authentication secrets | Stored only as salted, slow hashes; never reversibly encrypted unless a documented technical need exists |
| Code, firmware and software releases | Digitally signed with keys held in a protected signing service |
Note. Classification drives the choice. The Information Classification and Handling Policy defines which classes need encryption; where the two differ the stricter requirement applies.
5.2 Approved algorithms and strengths
Only algorithms in the approved standard maintained by the Head of IT Security may be used. The defaults below are reviewed at least once each year against current industry guidance.
| Purpose | Approved default | Not allowed |
|---|
| Symmetric encryption | AES with key length [256 bits] (not lower than [128 bits]) | DES, 3DES, RC4, and any custom or home-built cipher |
| Asymmetric encryption and signatures | RSA with at least [3072 bits], or elliptic-curve algorithms at the equivalent strength | RSA below [2048 bits], DSA |
| Hashing for integrity | SHA-256 or stronger | MD5, SHA-1 for any new purpose |
| Password storage | Memory-hard or adaptive hashing with unique salt, tuned to take about [250 ms] per check | Unsalted or fast hashes |
| Transport | TLS [1.2] with strong cipher suites, TLS [1.3] preferred | SSL, TLS 1.0 and 1.1, export-grade and null ciphers |
| Random numbers | Operating system or HSM cryptographic generator | Time-seeded or language default generators |
5.3 Design and implementation
- Cryptography must be implemented with well-reviewed, maintained libraries or platform services. Developers must not design their own algorithms or protocols.
- Keys, passwords and tokens must never be embedded in source code, images, scripts or documents. Applications must fetch secrets at run time from a secrets manager or key service.
- Systems must negotiate the strongest mutually supported option and must refuse downgrade to weak options for internal services.
- New systems and material changes must have their cryptographic choices reviewed in the design stage, as part of the Systems Acquisition, Development and Maintenance Policy.
- Where encryption prevents inspection by security tools, the traffic that is decrypted for inspection, the people allowed to see it and the retention of that data must be documented and approved by the information security manager.
5.4 Certificates
- Public certificates must be requested only from authorities approved by the Head of IT Security. Internal certificate authorities must keep root keys offline and use short-lived issuing certificates.
- Every certificate must be listed in the certificate inventory with owner, expiry date and location. Expiry alerts must be sent at [60], [30] and [7] days; expiry of a certificate on a production service is an incident.
- Certificates must be revoked within [24 hours] when the private key is suspected to be compromised, or the service is withdrawn.
5.5 Legal, regulatory and contractual limits
Some countries restrict the import, export or use of cryptographic products. The legal and compliance lead must confirm before cryptographic products are taken to, or services provisioned in, another country. Where applicable law in each jurisdiction where the Organisation operates (such as the EU General Data Protection Regulation) or a contract expects encryption of personal data, the controls in this policy are the minimum. Obligations under the Digital Personal Data Protection Act, 2023 and its Rules concerning reasonable security safeguards are met in part by this policy [confirm the current requirement].
6. Key Management
6.1 Key lifecycle rules
| Stage | Requirement |
|---|
| Generation | In an HSM or approved key service, with the cryptographic generator, by an authorised key custodian; never on personal devices |
| Distribution | Over protected channels or by wrapping with another key; no keys by plain email or chat |
| Storage | In an HSM or key service; if software storage is unavoidable, encrypted under a master key, with access limited to the service that needs it |
| Use | Each key for one purpose only; encryption keys and signing keys are never shared; separate keys per environment |
| Rotation | At the end of the crypto-period, or immediately on compromise or when a key custodian with access leaves |
| Revocation and destruction | Withdrawn keys are made unusable, and destruction is logged; copies on backup media are covered by the retention rules |
| Recovery and escrow | Recovery keys exist for data that must remain readable; they are split between at least [two] custodians and tested [yearly] |
| Key type | Default crypto-period |
|---|
| Data encryption keys (databases, volumes) | [12 months] |
| Key encryption keys and master keys | [24 months] |
| TLS certificates, public | [12 months] or the maximum permitted by industry rules |
| Code signing and document signing keys | [24 months] |
| API keys and service credentials | [90 days] or short-lived tokens |
| Backup encryption keys | [12 months], with older keys retained to read old backups |
6.2 Control of key custodians
- Root and master key operations need two authorised people present [dual control and split knowledge]. Their actions are recorded in the key ceremony log.
- Key custodians are named, trained and approved by the Head of IT Security. Access is reviewed [every six months] and removed on role change or leaving.
- The key inventory records key identifier, purpose, algorithm, owner, location, creation date, crypto-period end, status and the systems that depend on it. It is reconciled against the key service every [quarter].
6.3 Compromise and loss
Suspected exposure or loss of a key is a security incident under the Information Security Incident Management Policy. The key custodian must disable the key, the system owner must re-key and re-encrypt the data affected, and the incident response lead must decide on notification. The target to replace a compromised Tier 1 key is [24 hours] from confirmation.
7. Compliance and Monitoring
| Check | Performed by | Frequency |
|---|
| Scan for weak protocols, ciphers and expiring certificates | Information security manager | [Monthly] |
| Review of the key and certificate inventory against the key service | Key custodian | [Quarterly] |
| Review of approved algorithm standard against external guidance | Head of IT Security | [Yearly] |
| Sampling of encrypted devices and databases against asset register | Information security manager | [Quarterly] |
| Internal audit of key management | Internal audit | [Yearly] |
8. Procedure Reference
Step-by-step practice is in the Cryptography Procedure and the Key Management Process. This policy sets the rules; those documents set the how.
9. Records and Evidence
- Key and certificate inventory, kept for the life of each key plus [3 years].
- Key ceremony logs and custodian approvals, kept for [5 years].
- Algorithm and protocol scan results and remediation tickets, kept for [2 years].
- Exception records for weak or unsupported cryptography, with the compensating controls and end date, kept for [3 years] after closure.
Annexure A: Key inventory register
| Key ID | Purpose | Algorithm and length | Owner | Storage location | Created | Crypto-period end | Status |
|---|
| | | | | | | |
| | | | | | | |
10. Exception
Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.
11. Enforcement
Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.
12. Review
This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.
ISO/IEC 27001:2022 references
| Reference | Title |
|---|
| A.8.24 | Use of cryptography |
| A.5.14 | Information transfer |
| A.5.12 | Classification of information |
| A.5.31 | Legal, statutory, regulatory and contractual requirements |
| A.8.21 | Security of network services |
| 6.1.2 | Information security risk assessment |