How do we decide where we need encryption and how we manage keys and certificates under ISO 27001?

Start

We must set rules for encryption and for managing keys

The control asks you to define and apply rules for using cryptography, including managing keys. Encryption that is on but badly managed fails in a few ways: certificates that expire unnoticed, keys stored beside the data they protect and outdated protocols left enabled. These are the Library's named mistakes.

• Then: Does a law or a contract require specific encryption, or limit it?

Decision

Does a law or a contract require specific encryption, or limit it?

Some laws, sector rules and customer contracts name what must be encrypted, and a few countries restrict the import or use of strong cryptography. The standard asks that the rules follow the law. If you have not checked, answer yes and ask legal or compliance.

• Yes, or not known: Record each requirement and its source, and take the stricter
• No: List where encryption is required, from your classification

Step

Record each requirement and its source, and take the stricter

Add the duty to the register of legal and contractual requirements, with the clause or article it comes from. Where two duties differ, apply the stricter. Counsel confirms which apply; this is not legal advice.

• Then: List where encryption is required, from your classification

Step

List where encryption is required, from your classification

Work from the levels in your classification scheme: laptops and phones, data in transit, sensitive data at rest and backups. The handling matrix is a good place to say which level needs what. Write the rule per place, not as one sentence for everything.

• Then: Do platforms encrypt by default: disks, cloud storage, connections?

Decision

Do platforms encrypt by default: disks, cloud storage, connections?

Many platforms encrypt at rest and in transit unless turned off. A default is a control only if you have checked it is on for your tenant. If you have not checked, answer no.

• Yes: Record that the default is the control and where you checked it
• No, or not known: Turn it on, or record the gap and who accepts the risk

Step

Turn it on, or record the gap and who accepts the risk

Enable encryption where the system supports it. Where it cannot be enabled, record the gap as an exception with a compensating control and an expiry, approved by the person with authority to accept the risk.

• Then: Allow only current algorithms and protocols, from a published source

Step

Record that the default is the control and where you checked it

Name the setting and the date you checked it, for each platform. A statement that the provider encrypts is not evidence of your settings. Check again when the provider changes the service.

• Then: Allow only current algorithms and protocols, from a published source

Step

Allow only current algorithms and protocols, from a published source

Pick a published baseline rather than inventing one. NIST SP 800-131A on algorithm transitions and the NCSC's and BSI's guidance are examples. The pack does not name one, so say in the standard which source you follow and who watches it for change.

• Then: Are outdated protocols or weak settings still enabled anywhere?

Decision

Are outdated protocols or weak settings still enabled anywhere?

Old versions of TLS, weak ciphers and expired algorithms are on the Library's list of mistakes. Scans of your exposed services will show them. If you have not scanned, answer yes.

• Yes, or not known: Disable them, or log an exception with a date
• No: Is every key, certificate and secret listed with owner and expiry?

Step

Disable them, or log an exception with a date

Turn the weak setting off. If a legacy system needs it, record the exception, name a compensating control such as network limits and set the date it must go. The patching pack's end-of-life register is a useful model.

• Then: Is every key, certificate and secret listed with owner and expiry?

Decision

Is every key, certificate and secret listed with owner and expiry?

The Library's evidence is a certificate and key inventory with expiry dates. Without one, certificates expire unnoticed and nobody knows who may use a key. If you hold keys in several tools and have no single list, answer no.

• Yes: Are keys kept apart from the data they protect?
• No, or not known: Build the inventory: owner, location and expiry for each

Step

Build the inventory: owner, location and expiry for each

Include TLS certificates, signing keys, API keys, database and disk keys, backup keys and the keys cloud services hold for you. Start from the places that issue them. Pull expiry dates from the systems rather than typing them.

• Then: Are keys kept apart from the data they protect?

Decision

Are keys kept apart from the data they protect?

Keys stored beside the data they protect is a named mistake: whoever takes the data takes the key. A vault, a managed key service or a hardware module keeps them apart. If a key sits in the same account, file share or repository as its data, answer no.

• Yes: Set renewal, rotation, retirement and what to do if a key is exposed
• No, or not known: Move keys to a vault or managed key service with its own access list

Step

Move keys to a vault or managed key service with its own access list

Give the key store its own administrators and its own logs. Limit who can use and who can export a key, and review that list when people leave or change role. Remove keys from code, tickets and chat.

• Then: Set renewal, rotation, retirement and what to do if a key is exposed

Step

Set renewal, rotation, retirement and what to do if a key is exposed

Set a renewal date or automatic renewal for each certificate, an alert well before expiry and a rotation interval by risk. Write the steps to revoke and replace a key that may be exposed, and who decides. Rehearse them once. Say how keys are created, and how a retired key is destroyed so that it cannot be used again.

• Then: If a key is lost, can the data still be recovered?

Decision

If a key is lost, can the data still be recovered?

Encryption that nobody can undo is data loss waiting to happen. Backups encrypted with a key held only in the backup console are the classic case. If you have not tested recovery without the usual key holder, answer no.

• Yes: Check settings on a sample of systems and walk through the inventory
• No, or not known: Keep a recovery copy outside the estate, reachable by two named people

Step

Keep a recovery copy outside the estate, reachable by two named people

Store a sealed copy or a split key outside the estate it protects, where at least two named people can reach it when the usual holder is away or the main systems are down. Whether you also require two people to use it is your own risk decision. Have someone who is not the usual administrator recover a key from the register, and record the date. The backup case has its own question.

• Then: Check settings on a sample of systems and walk through the inventory

Step

Check settings on a sample of systems and walk through the inventory

Pick a few systems, including a cloud one, and confirm the encryption setting and protocol versions match the standard. Pick a few certificates and confirm owner, expiry and renewal. The auditor's sample is the same.

• Then: Did the sample find a system or certificate that breaks the rules?

Decision

Did the sample find a system or certificate that breaks the rules?

Any breach shows the rules are not yet applied. If you did not sample, answer yes.

• Yes, or not known: Fix them, update the inventory, then sample again
• No: Encryption rules set, keys managed and sampled

Step

Fix them, update the inventory, then sample again

Correct the setting, add what was missing to the inventory and take a fresh sample. Repeat until a sample passes.

• Then: Check settings on a sample of systems and walk through the inventory (back to an earlier step)

Outcome

Encryption rules set, keys managed and sampled

Keep the standard, the inventory with expiry dates and the sample result. Do not say all data is encrypted unless the sample covered each place the standard names, and do not describe a provider's encryption as your own control without checking your settings.