Use of cryptography

What the control asks

The organization is to define and apply rules for using cryptography effectively, key management included. Purpose: apply cryptography correctly and to good effect so information stays confidential, genuine or unaltered in line with business and security requirements and the legal, regulatory and contractual rules on cryptography. Guidance: consider a topic-specific cryptography policy setting general principles, needed to gain the benefits and avoid misuse; the protection level and classification of information, which determine the type, strength and quality of algorithms; encryption of information on mobile endpoints and storage media and in transit to them; the approach to key management, including generating and protecting keys and recovering encrypted information when keys are lost, compromised or damaged; roles for implementing the rules and for key management including generation; approved or mandatory standards, algorithms, cipher strengths, solutions and usage practices; and the effect of encryption on controls that inspect content, such as malware detection or content filtering. Take into account national regulations and restrictions on cryptography in different countries and cross-border flows of encrypted information (5.31), and make agreements with external cryptographic service providers such as certification authorities cover liability, service reliability and response times (5.22). Keys need secure handling across their whole life, from creation, storage, archiving, retrieval and distribution to retirement and destruction, based on agreed standards and procedures for: generating keys for different systems and applications; issuing and obtaining public key certificates; distributing keys to intended parties and activating them on receipt; storing keys and granting authorized access; changing or updating keys, with rules on when and how; handling compromised keys; revoking or deactivating keys, for instance on compromise or when a user leaves, archiving them in that case; recovering lost or corrupted keys; making backup or archive copies of keys; destruction of keys; logging and auditing key management; setting activation and deactivation dates so keys are used only within their permitted period; and handling legal demands for access to keys, such as producing decrypted evidence in court. All keys need protection from modification and loss, and secret and private keys also from unauthorized use and disclosure; equipment that generates, stores or archives keys is physically protected, and the authenticity of public keys often matters too. Other information: public key authenticity is usually handled through certificate authorities and certificates, or manually for small numbers of keys; cryptography supports confidentiality (encryption), integrity and authenticity (digital signatures, message authentication codes, file integrity checks), non-repudiation and authentication of users and entities; ISO/IEC 11770 covers key management.

Purpose in the standard’s terms, in our words: Makes cryptography work correctly to keep information confidential, genuine or unaltered as business, security and legal needs require.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Protect; Secure configuration; Protection.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• The topic-specific cryptography policy with approved algorithms, key lengths, protocols and usage by information classification
• Key management procedures covering generation, distribution, storage, rotation, revocation, recovery, backup, destruction and activation periods
• Key inventory or HSM and key management service records with logs of key management activity
• Evidence of encryption on endpoints, removable media and data in transit, aligned with the policy
• Contracts or SLAs with certification authorities and other cryptographic service providers covering liability, reliability and response times
• Assessment of cryptography laws for each relevant jurisdiction and of the impact of encryption on content inspection controls

Where audits commonly find gaps

• Deprecated algorithms or short keys remain in use because no approved list is enforced
• Keys have no defined lifetime and are never rotated
• Private keys are stored alongside the data they protect or in source code
• Expired or compromised certificates are not revoked promptly

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. Its earlier numbering (10.1.1, 10.1.2) is kept in the register so an older audit file can still be traced.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 8.18 Use of privileged utility programs
• 8.19 Installation of software on operational systems
• 8.4 Access to source code

Read the five attributes All 93 controls