Key management

ISO/IEC 27018 Clause 10.1.2 requires you to document and implement a cryptographic key management policy that governs how keys are used, protected, and managed across their full lifecycle to protect PII in public cloud environments (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). Operationally, you need enforceable standards, clear ownership, lifecycle procedures, and auditable evidence that keys protecting PII are generated, stored, rotated, and destroyed under controlled conditions.

Key takeaways:

• Write a lifecycle key management policy scoped to PII in public cloud, then prove it is implemented in systems and processes.
• Establish control over key custody, access, rotation, backup/escrow (if used), and destruction, with logging and review.
• Retain audit-ready artifacts: policy/standards, key inventory, access logs, rotation records, exceptions, and incident runbooks.

“Key management” is rarely a single control; it is a set of operational decisions that determine whether encryption is actually protective or just a checkbox. ISO/IEC 27018:2019 Clause 10.1.2 focuses on the policy layer and the lifecycle layer: you must define how cryptographic keys are used, protected, and managed from creation through retirement, specifically to protect PII processed in public cloud environments where you act as a PII processor (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this requirement is to translate “policy” into enforceable rules that engineers must follow (key ownership, where keys can live, how access is approved, rotation triggers, destruction steps), then collect evidence that the rules are in effect. Auditors will test whether your written policy matches actual configuration and operations, especially for keys that encrypt PII at rest, in backups, and in sensitive application workflows.

This page gives requirement-level implementation guidance you can execute quickly: who the requirement applies to, what to build, how to run it day-to-day, and what evidence to keep.

Regulatory text

ISO/IEC 27018:2019 Clause 10.1.2 (Key management) states: “A policy on the use, protection and lifetime of cryptographic keys shall be developed and implemented through their whole lifecycle for the protection of PII in public cloud environments.” (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Operator interpretation (what you must do):

• Develop a key management policy that explicitly covers keys used to protect PII in public cloud.
• Implement that policy in real operations: tools, configurations, access approvals, monitoring, and change management.
• Cover the whole lifecycle: key creation, storage, access, use, rotation, backup/escrow (if any), compromise handling, retirement, and destruction (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

Plain-English requirement interpretation

If your systems process PII in a public cloud, you need written, approved rules for how encryption keys are handled end-to-end, and you must be able to show that engineers and operators actually follow those rules. Your “keys” include KMS-managed keys, HSM-backed keys, customer-managed keys (CMK/BYOK/HYOK patterns), application-level keys, database TDE keys, and any wrapping keys used to protect data encryption keys.

A common audit failure: a well-written policy that does not match reality (for example, the policy requires rotation, but the KMS configuration or operational runbook does not rotate keys or cannot show rotation history).

Who it applies to

Entity types

• Public cloud Cloud Service Providers acting as PII processors (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

Operational context

• PII stored in cloud databases, object storage, data warehouses, logs, backups, and SaaS application data stores.
• PII in transit across internal services (service-to-service encryption) where key material and certificate/private key handling affects confidentiality.
• Multi-tenant environments where key isolation and access boundaries matter.

What you actually need to do (step-by-step)

1) Define scope: “Keys that protect PII”

Create a scoped definition that is enforceable:

• Which datasets are PII (by classification) and where they live.
• Which encryption mechanisms are approved for PII (platform encryption, application encryption, field-level encryption).
• Which key types are in scope (KMS keys, HSM keys, TLS private keys where they protect PII flows, signing keys if they protect integrity of PII records).

Output: documented scope statement and a key inventory baseline for PII-related systems.

2) Establish ownership and governance

Assign named accountability:

• Key Management Owner (often Security Engineering) responsible for the policy and standards.
• System Owners responsible for implementing policy in their services.
• Approvers for privileged access (Security/Compliance plus service owner, depending on your model).

Decide how exceptions work:

• What constitutes an exception.
• Who can approve it.
• What compensating controls are required.
• How exceptions expire and get reviewed.

Output: RACI (or equivalent accountability mapping) and an exception workflow tied to change management.

3) Write the key management policy (lifecycle-based)

Your policy should read like test criteria. Include:

A. Key generation and acquisition

• Approved sources (KMS/HSM, approved libraries).
• Requirements for uniqueness, separation of duties, and preventing ad hoc key creation in code repositories.

B. Key storage and protection

• Where keys may be stored (managed KMS/HSM, secret manager with strict controls, or other approved locations).
• Requirements for encryption of keys at rest and in transit inside your control plane.
• Prohibition of storing plaintext keys in source control, tickets, chat, documentation, or CI logs.

C. Access control and key custody

• Role-based access to key administration vs key usage.
• Administrative operations (disable, schedule deletion, policy edits) restricted to a smaller set than “encrypt/decrypt” usage.
• Requirements for approvals, break-glass access, and logging.

D. Key usage rules

• Allowed cryptographic operations by key type (encrypt/decrypt vs sign/verify).
• Environment separation (prod vs non-prod keys).
• Tenant/customer separation expectations where applicable.

E. Rotation, renewal, and re-keying

• Define rotation triggers (scheduled, on personnel changes in privileged roles, on suspected compromise, on algorithm changes).
• Define what “rotation” means in each architecture (new key version, envelope rewrapping, data re-encryption, certificate renewal).

F. Backup/escrow (only if you do it)

• Whether keys are escrowed, under what approvals, and how access is controlled.
• How you prevent escrow from becoming a bypass of normal access control.

G. Compromise response

• What constitutes suspected key compromise.
• Immediate containment steps (disable key, revoke grants, rotate, re-encrypt if needed).
• Notification and incident handling hooks.

H. Key retirement and destruction

• Conditions for retirement.
• Deletion process, timing controls, verification steps, and records to retain.

Output: an approved policy and associated standards/runbooks mapped to the lifecycle language in the clause (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

4) Implement the policy in cloud controls and engineering workflows

Policy without enforcement fails. Implementation typically requires:

• Centralized key management via your chosen cloud KMS/HSM where possible.
• Infrastructure-as-code guardrails: prevent creation of noncompliant keys, block public access patterns, require logging, and enforce approved key policies.
• Secrets handling controls: scanning and prevention for keys in repos and CI artifacts.
• Access review routines: periodic review of who can administer keys and who can use them (separate from generic cloud admin access reviews).
• Logging and alerting: key policy changes, disable/delete actions, unusual decrypt spikes, and use from unexpected principals.

Output: config evidence (screenshots/exports), IaC policy rules, and operational runbooks.

5) Build an evidence machine (auditors test what you can prove)

Treat key management like a control family with recurring evidence:

• Sampled proof that specific PII systems use approved keys.
• Proof that key access is limited and reviewed.
• Proof that lifecycle events (rotation, destruction) happened as required.
• Proof that incidents/exceptions were handled via defined process.

Where Daydream fits naturally: many teams struggle to keep key inventories, rotation records, and exception approvals tied together. Daydream can act as the system of record for key management controls by linking policy, ownership, PII system scope, evidence requests, and recurring review tasks so audits don’t turn into a spreadsheet chase.

Required evidence and artifacts to retain

Keep artifacts in a form that stands alone during an audit:

• Key management policy approved and version-controlled (maps to use, protection, lifetime, lifecycle).
• Key inventory for keys protecting PII, including system/application, environment, key owner, key type, and where managed.
• Access control records: role definitions, grants, approvals, and access reviews for key admins and key users.
• Audit logs for key lifecycle actions (create, policy change, disable, delete, rotate).
• Rotation/renewal records: change tickets, KMS key version history exports, certificate issuance logs where relevant.
• Exception register: approvals, compensating controls, expiry, closure evidence.
• Incident runbooks and incident records for key compromise or suspected exposure.
• Decommission/destruction records: proof keys were retired and deleted according to policy.

Common exam/audit questions and hangups

Expect auditors to ask:

• “Show me the keys that encrypt PII for system X and who can administer them.”
• “How do you know keys aren’t embedded in code or shared in tickets?”
• “Show rotation evidence for a sample of PII systems.”
• “What happens if a key is suspected compromised? Walk through the runbook.”
• “Do you separate duties between key administrators and application operators?”
• “How do you handle customer-managed keys and customer requests around access?”

Hangups that slow audits:

• No reliable key inventory tied to PII systems.
• Access reviews cover cloud admins generally, but not key-level permissions.
• Rotation is claimed in policy but cannot be demonstrated for sampled systems.

Frequent implementation mistakes (and how to avoid them)

1. Policy describes ideals, not operating reality.
   Fix: draft policy from existing architecture, then tighten controls with a change plan; document exceptions explicitly.

2. No separation between key admin and key usage roles.
   Fix: create distinct roles and approval paths; require stronger controls for policy edits and deletion actions.

3. Keys proliferate across teams with inconsistent naming and ownership.
   Fix: enforce tags/labels and ownership at creation via IaC checks; block untagged keys.

4. Rotation defined but not testable.
   Fix: define rotation evidence per platform (KMS version history, certificate issuance logs, change tickets) and make it a recurring control activity.

5. Destruction is ambiguous.
   Fix: define “retire” vs “destroy,” specify who approves destruction, and retain deletion evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so focus on the operational risk: weak key management can negate encryption, expand blast radius during incidents, and make you unable to prove that PII remained protected. In ISO/IEC 27018 audits, key management gaps often cascade into findings across access control, logging, incident response, and data protection claims, because keys sit at the control boundary for confidentiality of PII (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

Practical 30/60/90-day execution plan

Timelines below are a practical sequence, not a claim about required duration.

First 30 days (stabilize and scope)

• Identify in-scope PII systems in public cloud and list the encryption mechanisms used.
• Build an initial key inventory for PII protection keys and assign owners.
• Draft the key management policy outline mapped to lifecycle stages (create, store, access, rotate, retire, destroy).
• Confirm logging is enabled for key management actions and accessible to audit/IR teams.

Days 31–60 (formalize and implement guardrails)

• Finalize and approve the key management policy and supporting standards/runbooks.
• Implement role separation for key admin vs key use, plus an approval workflow for high-risk actions.
• Add IaC and CI guardrails: enforce required tags/ownership, block insecure key storage patterns, require logging.
• Stand up an exception register with expirations and review cadence.

Days 61–90 (operationalize and prove)

• Run a first evidence cycle: pick a sample of PII systems and collect key mapping, access lists, and rotation records.
• Conduct an access review focused specifically on key permissions and close gaps.
• Tabletop the key compromise runbook and capture action items.
• Implement recurring control checks in Daydream (or your GRC system): inventory refresh tasks, access review tasks, evidence requests, and exception renewals.

Frequently Asked Questions

Does ISO/IEC 27018 require us to use a specific tool like a cloud KMS or HSM?

Clause 10.1.2 requires a policy and lifecycle implementation, not a named technology (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). In practice, you need a managed approach that can enforce access control, logging, rotation, and destruction in a way you can audit.

What counts as “cryptographic keys” for this requirement?

Treat any key material that protects PII confidentiality or access as in scope, including KMS/HSM keys and application-level encryption keys. If a key’s misuse could expose PII, it belongs in your lifecycle policy and inventory (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

We encrypt data at rest by default in the cloud. Do we still need a key management policy?

Yes. The clause is explicit about developing and implementing a policy for key use, protection, and lifetime across the lifecycle (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). Default encryption does not replace governance over access, rotation, and retirement for the keys behind that encryption.

How do we handle customer-managed keys (BYOK/CMK) in a PII processor model?

Document shared responsibilities: who creates keys, who controls admin permissions, and what evidence you can provide without accessing customer key material. Your policy should cover how your services integrate with customer keys, what logs you retain, and how you respond if a customer rotates or revokes a key (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

What evidence do auditors usually ask for first?

They usually start with the approved policy, then test a small sample of PII systems to see if the keys, access controls, logging, and rotation match the policy (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). If you have a clean key inventory tied to PII systems, the audit moves faster.

We rotate keys, but we don’t re-encrypt old data every time. Is that a problem?

The standard requires lifecycle coverage and implementation, not a single prescribed rotation mechanism (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). Define what rotation means in your architecture, document the security rationale, and retain evidence that the defined process happens consistently.