Cryptography Procedure

1. Purpose

This procedure explains how to apply the Cryptography Policy. It sets out how a team decides whether and how to use cryptography for a given system or data flow, how products and algorithms are chosen and approved, who does what, and how cryptographic keys are created, stored, changed, recovered and destroyed so that encrypted information stays protected and also remains recoverable by the Organisation.

2. Scope

• In scope: encryption of data at rest, in transit and in backups; digital signatures; certificates and public key infrastructure; hashing of passwords and integrity values; secrets used by applications; and any cryptographic function embedded in products or developed in-house.
• In scope: all systems, devices, cloud services and suppliers that handle Organisation or customer information, and all staff who request, operate or use cryptography.
• Out of scope: the details of the key custody roles and ceremonies, which are covered in the Key Management Process, and the choice of network design, covered in the Network Security Procedure.

3. Terms and Definitions

4. Roles and Responsibilities for Encryption

5. Cryptographic Controls

The Organisation uses only widely reviewed, standards-based algorithms and protocols. Proprietary or home-made schemes are not allowed. The table sets the default minimum; the Head of IT Security updates it at least [annually] and when a weakness is published.

5.1 Principles

• Encrypt by default for Confidential and Restricted data wherever it is stored or travels; encryption for other levels follows the risk assessment.
• Use well-tested libraries and platform services; do not combine primitives in new ways without review by the Head of IT Security.
• Keys are separated from the data they protect, and from the administrators of that data where practicable.
• Every key and certificate has an owner, purpose, cryptoperiod and recovery plan before it enters use.
• Cryptography must be agile: systems must allow algorithms and keys to be changed without redesign.
• Use of cryptography must respect applicable law in each jurisdiction where the Organisation operates, including import, export and use restrictions; legal is consulted before cross-border deployment.

6. Determination of Encryption Requirements

A requirement assessment is done for every new system, major change, new supplier and new data flow involving Confidential or Restricted information. It is recorded on the cryptographic requirement assessment form (Annexure A) and kept with the design record.

1. Describe the data and flowsThe system owner lists the data, its classification, where it is stored, and every path it travels, including backups, logs and third parties. Input: data flow diagram and classification register.
2. Identify driversRecord legal, contractual and customer requirements and the findings of the latest risk assessment. For personal data, include the safeguards expected in the Data Protection and Privacy Procedure.
3. Select the controlsUsing the table below, choose the encryption layer for each data location and flow. Where a layer is skipped, record the compensating control.
4. Review and approveThe Head of IT Security reviews within [5 working days]. The information owner signs acceptance of any residual risk.
5. Implement and verifyIT operations configure the controls; a second person checks the configuration and evidence is attached to the change record.
6. Re-assessRepeat when the data, hosting, supplier or threat picture changes, and at least [annually] for Class 1 systems.

7. Product Selection

Products and services that provide cryptography must be chosen from the approved list kept by IT security. A new product is added only after the following checks.

1. Define needsState the use, data classification, performance, integration, and recovery needs.
2. EvaluateCheck that the product uses approved algorithms and protocols, is actively maintained, has had independent review or validation, and allows key export or escrow under Organisation control. Consider supplier viability and exit terms.
3. Assess securityReview the supplier's security evidence and test the product in a lab, including failure modes such as expired certificates and lost keys.
4. ApproveThe Head of IT Security approves for a stated purpose and period of [3 years]; the decision goes into the approved product list.
5. ReviewRe-evaluate at renewal or when a vulnerability or end-of-support notice is received.

8. Key Management

Every key follows a lifecycle from generation to destruction. The table gives default cryptoperiods; shorter periods apply where the risk assessment demands. The Key Management Process describes custody ceremonies in detail.

8.1 Key generation and distribution

• Generate keys in the protected environment of the target store, using an approved random generator; do not generate keys on personal devices.
• Never email, chat or write down keys in clear text. Distribute through the secret store, a key wrapping method, or split components delivered by separate channels.
• For master keys use a ceremony with at least [two] key custodians, witnessed and recorded in the key ceremony record (Annexure C).
• Register each key in the key register (Annexure B) at generation with owner, purpose, location, algorithm, creation and expiry dates.

8.2 Storage and change

• Store keys in hardware security modules, managed key services or dedicated encrypted vaults, separate from the data they protect.
• Access to key stores is by named role, approved in the access request tool, protected with multi-factor authentication and logged. Review membership [quarterly].
• Change keys at the end of their cryptoperiod and immediately on suspected compromise, on departure of a custodian with access, or when an algorithm is withdrawn.
• Re-encrypt data under a new key within [30 days] of rotation unless envelope encryption means only the wrapping key changes.
• Track certificate expiry; renew at least [30 days] before it ends and alert at [60 days].

8.3 Archival and recovery

• Keep retired keys in an archive, restricted to decryption, for as long as data encrypted under them must be readable, plus [1 year].
• Back up keys and recovery material to a separate, protected location under dual control. A test restore of a key and the data it protects is performed [annually].
• Recovery of a key requires approval from the system owner and the Head of IT Security, a ticket, and two custodians. Record the reason, who took part and the time.
• Where a customer or law requires access to encrypted data, the information owner and legal approve release and the decryption is performed by authorised staff only.

8.4 Revocation and destruction

1. TriggerA key is revoked on compromise, suspected exposure, loss of custody, algorithm withdrawal, end of use or end of contract.
2. RevokeRevoke the certificate with the issuer, remove the key from active use, and publish the revocation where applicable. Target: [4 hours] for a compromise.
3. ReplaceIssue replacement keys, re-encrypt or re-sign affected data, and update dependent systems.
4. DestroyWhen the archive period ends, destroy every copy using secure deletion or hardware zeroisation, witnessed by two custodians. Destruction of a key is irreversible, so confirm no data still depends on it.
5. RecordUpdate the key register and file the destruction record. Evidence: signed record and system output.

9. Data Encryption Methodology

9.1 Data at rest

• Laptops and desktops: full-disk encryption with recovery keys held centrally by IT.
• Servers and virtual machines: volume encryption using keys from the key service; databases with transparent encryption plus field-level encryption for Restricted attributes such as identifiers and authentication data.
• Cloud storage: provider encryption with customer-managed keys for Confidential and Restricted data.
• Backups: encrypted before they leave the source or at the backup platform, with keys stored separately from the media.
• Mobile devices: device encryption enforced through the mobile device management tool.

9.2 Data in transit

• External connections use the approved transport protocol and certificates from a trusted issuer; certificate validation must never be turned off in code.
• Remote access, administration and file transfer between systems use encrypted protocols only.
• Where customer-facing platforms exchange Confidential data with partners, use mutual authentication or signed and encrypted payloads.
• Email gateways enforce transport encryption wherever the receiving side supports it, and block or quarantine messages that match data loss rules.

9.3 Applications and development

• Developers call approved libraries and the central secret store; keys, passwords and tokens are never stored in source code, configuration files in repositories or build logs.
• Secret scanning runs on every commit; a detected secret is treated as compromised and rotated within [24 hours].
• Tokens and sessions use signed and time-limited values. Passwords are hashed with the approved function and a unique salt.

9.4 Testing and monitoring

• Scan externally exposed services [monthly] for weak protocols, ciphers and certificates; fix findings by the severity rules in the Patch Management Procedure.
• Alert on key store access outside a change, failed decryption spikes and certificate expiry, using the Logging and Monitoring Procedure.
• Review the approved algorithm list [annually] against current guidance and plan migrations at least [12 months] before an algorithm is withdrawn.

10. Certificate Lifecycle and Key Compromise

10.1 Certificate lifecycle

1. RequestThe system owner raises a request naming the host names, purpose, key type and validity. Only certificates from approved issuers are used; self-signed certificates are limited to test environments.
2. IssueIT operations generates the key pair on the target system or key store and sends only the signing request to the issuer. Private keys are never emailed.
3. InstallInstall, restrict access to the private key, test chain validation, and add the certificate to the inventory with its expiry date.
4. MonitorExpiry is watched by an automated check. Alerts go to the owner at [60, 30 and 14 days] before expiry.
5. Renew or retireRenew at least [30 days] before expiry; remove certificates for decommissioned services and revoke them.

10.2 Response to key compromise

11. Measures

12. Records and Evidence

Annexure A: Cryptographic requirement assessment

Annexure B: Key register

Annexure C: Key ceremony and destruction record

13. 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.

14. 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.

15. 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

Related documents

• Cryptography Policy
• Key Management Process
• Information Classification and Handling Procedure
• Network Security Procedure
• Mobile Device Management Procedure
• Backup Management and Retention Procedure
• Cloud Computing Security Policy and Procedure