Key management

To meet the ISO/IEC 27017 key management requirement, you must define and run a documented cryptographic key management policy that covers the full key lifecycle in cloud environments, including how keys are generated, stored, accessed, rotated, revoked, and destroyed, and how responsibilities differ for provider-managed keys versus customer-managed keys. Your fastest path is to map every production encryption use case to an owner, a key type, a storage location, and lifecycle procedures, then collect evidence that the procedures operate in practice. ¹

Key takeaways:

• Your policy must cover end-to-end key lifecycle, not just “encryption enabled.” ¹
• You must explicitly document the split of duties between cloud provider key handling and customer-managed keys. ¹
• Auditors look for operational proof: inventories, access controls, rotation/revocation records, and destruction evidence aligned to your policy. ¹

“Key management requirement” usually fails in practice for one reason: teams treat it as a design-time encryption decision instead of a run-time operational discipline. ISO/IEC 27017:2015 Clause 10.1.2 expects a policy that governs how cryptographic keys are used, protected, and retired across their entire lifecycle, including cloud-managed key storage and customer-managed encryption keys. ¹

For a Compliance Officer, CCO, or GRC lead, operationalizing this requirement means translating “policy” into concrete controls your engineering and cloud operations teams can execute without ambiguity: who can create keys, where keys live, how access is granted and logged, what triggers rotation, how revocation happens during an incident, and how you prove keys were destroyed at end of life. You also need to make the shared responsibility model explicit so you can answer the most common audit question: “Which keys are you relying on the cloud provider to protect, and which keys do you control directly?” ¹

Regulatory text

ISO/IEC 27017:2015 Clause 10.1.2: “A policy on the use, protection and lifetime of cryptographic keys shall be developed and implemented through their whole lifecycle, including cloud-managed key storage and customer-managed encryption keys.” ¹

Operator meaning (what you must do):

• Develop a key management policy that states rules for key use, protection, and lifetime across the full lifecycle (creation through destruction). ¹
• Implement the policy in real systems and processes, including for cloud-managed key storage (provider controls) and customer-managed encryption keys (customer controls). ¹

Plain-English interpretation

You need one authoritative set of rules for keys and proof that those rules are followed. “Keys” includes keys used for data-at-rest encryption, database encryption, object storage encryption, volume encryption, secrets that function as cryptographic material, and keys protecting backups, logs, and key-wrapping hierarchies. The policy must also state which parts of the lifecycle are handled by your cloud provider and which parts are handled by you when you choose customer-managed keys. ¹

Who it applies to

Entity types:

• Cloud Service Providers (CSPs): You must define how you protect and manage keys for the services you operate, including keys you hold on behalf of customers and any platform keys used to protect customer data. ¹
• Cloud Service Customers: You must define how your organization manages keys used in cloud workloads, including when you accept provider-managed keys and when you bring customer-managed keys (for example, via cloud KMS/HSM options). ¹

Operational contexts that trigger scope:

• Production workloads that encrypt data, tokens, or backups using keys stored/controlled in cloud services. ¹
• Multi-tenant cloud services where segregation, access control, and key isolation must be demonstrable. ¹
• Third parties that touch keys or key material (managed service providers, incident response firms, platform vendors), because lifecycle responsibilities and access pathways must be governed by your policy. ¹

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

1) Build a complete “key inventory” tied to encryption use cases

Create a register that maps every cryptographic use case to:

• System/service name and environment (prod/non-prod)
• Data classification and purpose (at-rest, in-transit termination, signing, backup encryption)
• Key type (master key, data encryption key, signing key, key-encryption key)
• Key storage/control plane (provider-managed, cloud KMS, HSM, external key manager)
• Owner (team and accountable role)
• Lifecycle rules (creation, rotation trigger, revocation method, destruction method) ¹

Practical tip: if you cannot answer “where is the key, who can touch it, and how do we kill it,” your inventory is not audit-ready.

2) Write the policy as executable rules, not principles

Minimum content your key management policy should include:

• Permitted cryptographic services (what platforms are approved for key generation and storage, and when exceptions are allowed). ¹
• Key ownership model (who owns the key lifecycle; who approves access). ¹
• Provider-managed vs customer-managed keys responsibilities, including what you rely on the cloud provider to do and what you must do yourself. ¹
• Lifecycle procedures: generation, storage, distribution, rotation, revocation, destruction. ¹
• Access control requirements: least privilege, separation of duties for key admins vs workload admins, break-glass process, and logging requirements for key actions. ¹
• Incident and termination handling: what happens to keys during suspected compromise, customer offboarding, and system decommissioning. ¹

3) Implement lifecycle controls in the platform

Operationalize the policy with technical and process controls:

• Key generation: require generation inside approved key management systems; prohibit ad hoc key material in code repos or tickets. ¹
• Key storage and protection: confirm keys remain in managed stores with strong access controls and audit logs; document how cloud-managed key storage is configured. ¹
• Distribution/use: define how applications request keys, how permissions are granted, and what prevents unauthorized export. ¹
• Rotation: implement rotation mechanisms consistent with your policy triggers (time-based, event-based, or both). Keep it consistent across systems or document deviations. ¹
• Revocation/suspension: define a tested procedure to disable keys rapidly during compromise, employee termination, or third-party access removal. ¹
• Destruction: define what “destruction” means in your platforms (for example, scheduled deletion with retention safeguards) and how you verify it occurred. ¹

4) Make third-party boundaries explicit

If a third party operates your cloud environment, runs your KMS/HSM, or administers production workloads:

• Put the key lifecycle responsibilities into contracts, SLAs, and access terms.
• Require evidence: access logs for key actions, change records for key policy changes, and incident reporting obligations related to keys. ¹

5) Establish governance and review

Run a repeatable oversight cadence:

• Review the key inventory for new services and decommissioned systems.
• Review privileged access to key management systems.
• Test break-glass and revocation steps through tabletop or controlled exercises, then retain outcomes as evidence. ¹

If you want this to move quickly without missing evidence, Daydream can track key management obligations as requirement-level controls, route tasks to cloud and security owners, and store the artifacts auditors ask for in one place, tied back to ISO/IEC 27017 Clause 10.1.2. ¹

Required evidence and artifacts to retain

Auditors will expect artifacts that show both design (policy) and operation (records):

• Approved Key Management Policy with version history and owner.
• Key inventory/register mapping systems to keys, storage, owners, and lifecycle rules.
• Access control evidence: role definitions, approvals, and current access listings for KMS/HSM and key admin functions.
• Audit logs (or exports/screenshots) showing key creation, rotation, disablement, deletion events, and who performed them.
• Change management records for key policy changes, KMS configuration changes, and encryption configuration changes.
• Incident runbooks for key compromise and revocation; post-incident notes when invoked.
• Offboarding/decommission checklists showing key destruction or retirement aligned to lifecycle requirements. ¹

Common exam/audit questions and hangups

Expect these, and pre-answer them in your artifacts:

• “Show me your key management policy and where it covers the full lifecycle.” ¹
• “Which systems use provider-managed keys vs customer-managed keys, and why?” ¹
• “Who can administer keys, and how do you prevent one person from having end-to-end control?” ¹
• “Show evidence of key rotation/revocation/destruction for a sample system.” ¹
• “How do you manage keys for backups, replicas, and logs?” ¹

Typical hangup: a team can show encryption is enabled but cannot show the lifecycle procedures or who is accountable for them.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails ISO/IEC 27017 Clause 10.1.2	Fix
Policy exists but doesn’t cover lifecycle end-to-end	The requirement explicitly calls for “whole lifecycle” coverage. 1	Add explicit sections for generation, storage, distribution, rotation, revocation, destruction, and responsibilities.
No clarity on provider-managed vs customer-managed keys	The text calls out both models; ambiguity creates control gaps. 1	Add a responsibility matrix per platform/service and map it in the key inventory.
Keys “owned by engineering” with no accountable approver	Auditors need governance, not informal norms.	Assign accountable owners and approvers; document access grant paths and break-glass approvals.
Rotation/revocation exists in theory but isn’t evidenced	Audits test operation; absence of records reads as non-operation.	Preserve logs, tickets, or change records for real events; run controlled tests and retain results.
Missing scope: backups, replicas, integrations, third-party tooling	Keys often exist outside the “main app” boundary.	Expand inventory to cover backup encryption, log encryption, and third-party access paths.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for this requirement, so treat enforcement discussion as risk-based. Weak key management increases the chance that a compromise becomes a full data exposure event: attackers who obtain keys (or key admin access) can decrypt protected data, forge signatures, or maintain persistence by creating new keys. ISO/IEC 27017’s focus on lifecycle and cloud responsibility boundaries targets these operational failure modes. ¹

A practical 30/60/90-day execution plan

You asked for speed, but the source set does not support numeric timeline claims. Use this phased plan and adjust to your delivery cadence; keep each phase outcome-driven and evidence-backed.

Immediate phase (stabilize and define)

• Name an executive owner and an operational owner for key management.
• Draft or update the key management policy to cover the full lifecycle and the provider-managed vs customer-managed split. ¹
• Stand up a key inventory template and start with highest-risk production systems first (customer data stores, backups, signing keys). ¹

Near-term phase (implement controls and collect proof)

• Configure or validate access controls for key admin roles; remove broad permissions.
• Implement and document rotation and revocation procedures per system class.
• Turn on and retain logs for key lifecycle actions; confirm you can export them for audits. ¹

Ongoing phase (operate and govern)

• Integrate key inventory updates into change management so new services cannot go live without key lifecycle mapping.
• Run periodic reviews of key admin access and exceptions.
• Test key revocation and recovery procedures, then file the results as evidence. ¹

Frequently Asked Questions

Do we need customer-managed keys to satisfy ISO/IEC 27017 Clause 10.1.2?

No. The requirement is to have and implement a lifecycle policy that covers both cloud-managed key storage and customer-managed encryption keys where they exist. If you only use provider-managed keys, document that decision and the provider/customer responsibility split. ¹

What’s the minimum “key inventory” detail an auditor will accept?

You need enough detail to prove lifecycle governance: where the key lives, what it protects, who can administer it, and how rotation/revocation/destruction occurs. If you cannot trace a key from creation to retirement for a sampled system, expect a finding. ¹

How do we prove key destruction in cloud KMS systems?

Keep policy language that defines destruction for your platform (for example, scheduled deletion) and retain audit logs or administrative records showing the deletion action for sampled keys. Pair it with a decommission checklist that ties the action to the system retirement event. ¹

Does “key management” include TLS certificates and signing keys?

If they are cryptographic keys used to protect confidentiality or integrity of your services, treat them as in scope and manage them through the same lifecycle policy structure. Document how they are generated, stored, rotated, revoked, and destroyed. ¹

We use a third party managed service provider. Who “owns” key management?

You still need a policy that assigns responsibilities across the lifecycle and captures what the third party does versus what you do. Contractual terms and access records become part of your audit evidence set. ¹

What’s the fastest way to get audit-ready evidence without slowing engineering?

Standardize templates (inventory, access approvals, decommission checklist) and collect logs centrally for key lifecycle actions. Tools like Daydream help by tying each artifact to the requirement and keeping an always-current evidence packet for audits. ¹

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services