Policy on the use of cryptographic controls

ISO/IEC 27017 Clause 10.1.1 requires you to develop and implement a written policy that governs how your organization uses cryptographic controls in cloud environments, specifically covering encryption for data in transit and at rest. To operationalize it, define approved encryption standards, when encryption is mandatory, how keys are managed, and how exceptions are approved and monitored. ¹

Key takeaways:

• A “crypto policy” must be implemented, not just published, with enforceable rules for cloud encryption and key management. ¹
• Your policy must explicitly address encryption in transit, encryption at rest, key management, and algorithm selection for cloud workloads. ¹
• Auditors will look for evidence that systems follow the policy, that exceptions are controlled, and that responsibilities are clear across cloud provider/customer boundaries. ¹

A policy on the use of cryptographic controls is one of those requirements that sounds like “write a document,” but audits fail because the document is disconnected from real cloud operations. ISO/IEC 27017:2015 Clause 10.1.1 expects a policy that drives consistent encryption decisions for cloud data flows and storage, and that ties those decisions to key management and approved cryptography choices. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize this requirement is to treat the policy as a binding control standard: it must be specific enough that engineers can implement it and specific enough that audit can test it. That means defining scope (which cloud services, which data types), minimum requirements (in transit and at rest), key ownership and lifecycle, and a controlled exception path.

This page gives you a requirement-level blueprint you can hand to security engineering, platform teams, and application owners, then test against evidence within your control.

Regulatory text

ISO/IEC 27017:2015 Clause 10.1.1 states: “A policy on the use of cryptographic controls for protection of information shall be developed and implemented,” and it must address “encryption of data in transit and at rest within cloud environments.” ¹

What the operator must do

You must (1) create a cryptographic controls policy and (2) make it real in your cloud environment through enforceable requirements and governance. The policy needs to cover, at minimum:

• Encryption in transit
• Encryption at rest
• Key management
• Cryptographic algorithm selection
  ¹

Plain-English interpretation (what auditors mean by “policy” here)

A passing implementation looks like this: you can point to a written policy and show that cloud services are configured and operated in line with it. A failing implementation looks like this: a high-level statement (“we encrypt sensitive data”) with no scope, no approved methods, no defined ownership for keys, and no evidence that encryption settings are consistently enforced.

This requirement is about consistency and control across cloud workloads. The “policy” is the rulebook; the “implemented” part is the combination of technical settings, processes, and oversight that make the rulebook true.

Who it applies to (entity and operational context)

ISO/IEC 27017 is written for cloud security, and this clause applies to:

• Cloud service providers (CSPs): You need a crypto policy that governs how your platform protects customer information in your cloud service. ¹
• Cloud service customers: You need a crypto policy that governs how you configure and operate cloud services you consume, including how you protect your data in those services. ¹

Operationally, this applies wherever you have cloud data paths or cloud storage, including common scenarios such as:

• Application traffic between users, APIs, microservices, and third-party integrations
• Object storage, databases, queues, disks, backups, and snapshots
• Managed services where the provider controls some encryption layers and you control others

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

1) Define scope and policy authority

• Scope: Identify which cloud environments and services are in scope (production, staging, developer sandboxes; IaaS/PaaS/SaaS).
• Policy authority: State who owns the policy (often CISO or Security) and who approves exceptions (often Security + Risk/Compliance).
• Binding nature: Make it explicit that the policy sets mandatory requirements for cloud implementations.
  Tie this back to the clause requirement to develop and implement a crypto controls policy. ¹

2) Set minimum requirements for encryption in transit

Your policy should answer, in enforceable language:

• Which protocols/ciphers are allowed for service-to-service and user-to-service communications
• Where encryption termination is permitted (e.g., load balancer, API gateway) and where it is prohibited
• Expectations for certificate management (issuance, rotation triggers, revocation handling)
• Requirements for third-party connections (e.g., require encrypted channels for integrations)

Auditors test this by sampling system configurations (load balancers, ingress controllers, service meshes, API gateways) and verifying encrypted connections match policy requirements. ¹

3) Set minimum requirements for encryption at rest

Your policy should explicitly state:

• Which data stores must be encrypted at rest in cloud environments
• How “at rest” is interpreted (databases, object stores, file systems, disks, backups, logs, and exports)
• The expected control point (cloud-native encryption controls, application-level encryption, or both)
• How to treat derived data and replicas (read replicas, caches, snapshots)

Testing usually includes checking encryption settings on storage services, databases, and backup configurations, then confirming the evidence matches the policy. ¹

4) Define key management rules (the part most policies under-specify)

Your policy must describe key management at a level an operator can follow:

• Key ownership: Who owns keys for each environment (customer-managed vs provider-managed responsibilities in shared responsibility models)
• Key lifecycle: Creation, storage, access controls, rotation expectations, disablement, destruction
• Access and segregation: Who can request access to keys, who can approve it, and how access is logged
• Key storage: Where keys live (e.g., KMS/HSM expectations) and prohibited storage locations (e.g., source code repositories)
• Incident handling: When key compromise is suspected, what actions are required (revocation, re-encryption, customer notification routes where applicable)

The core audit question: can you prove that key access is controlled, logged, and aligned to your written rules? ¹

5) Specify approved cryptography and how changes happen

ISO/IEC 27017 expects algorithm selection to be governed. Your policy should:

• List approved cryptographic algorithms and modes (or reference an internal crypto standard that does)
• Define who can approve deviations and under what conditions
• Define a review process for cryptographic choices in new systems and major changes

If your organization already has a secure engineering standard, align it: the crypto policy can be the governance anchor, while engineering standards hold the implementation detail. ¹

6) Operationalize: turn the policy into guardrails

A policy “implemented” in cloud environments usually requires:

• Cloud configuration baselines (required encryption settings for storage, managed databases, load balancers)
• CI/CD checks (reject infrastructure-as-code changes that violate encryption requirements)
• Monitoring and alerting for drift (unencrypted storage created, public endpoints without encryption controls)
• Exception process that is time-bounded, risk-accepted, and tracked to remediation

If you use Daydream to manage control implementation, map the policy requirements to testable controls, assign owners, and collect evidence in one place so audit requests don’t turn into a scavenger hunt.

Required evidence and artifacts to retain

Keep artifacts that prove both “developed” and “implemented”:

Policy and governance

• Approved cryptographic controls policy (versioned, approved, with effective date) ¹
• Roles and responsibilities matrix for encryption and key management across teams and third parties ¹
• Exception register with approvals, rationale, compensating controls, and closure evidence ¹

Implementation evidence (cloud)

• Configuration evidence showing encryption in transit (e.g., gateway/load balancer settings, service mesh policies)
• Configuration evidence showing encryption at rest (storage, database, backups, snapshots)
• Key management configuration and logs (KMS/HSM configuration, access logs, IAM policies tied to key use)
• Change management evidence showing encryption controls are part of design reviews or deployment gates

Common exam/audit questions and hangups

Auditors and certification bodies commonly get stuck on:

• “Show me the policy, and show me it’s followed.” Expect sampling across multiple cloud services. ¹
• Shared responsibility confusion. For CSP customers, auditors ask which encryption layers you control versus what the cloud provider controls. ¹
• Key ownership ambiguity. If you claim customer-managed keys, they will ask how you prevent provider operators from accessing plaintext and who can change key policies.
• Exceptions without closure. An exception path that never expires reads as “policy optional.”

Frequent implementation mistakes (and how to avoid them)

1. Writing a policy that only says “encrypt data.”
   Fix: add scope, minimum requirements for transit/rest, and key management responsibilities tied to cloud services. ¹

2. Treating encryption at rest as a single toggle.
   Fix: enumerate storage types (databases, object stores, backups, logs) and define how each is verified.

3. No defined cryptography standard or algorithm selection process.
   Fix: maintain an approved list (or referenced standard) and a change/exception workflow. ¹

4. Key management left to “the platform team.”
   Fix: document key ownership, access controls, logging expectations, and incident actions, then test access pathways.

Enforcement context and risk implications

No public enforcement cases were provided for this specific clause in the provided source catalog. Practically, weak cryptographic governance increases breach impact and can turn a cloud misconfiguration into an exposure with clear preventability arguments during post-incident reviews. Treat this as a control that reduces blast radius and supports defensibility.

A practical 30/60/90-day execution plan

Numeric timelines are useful for planning, but this guidance is presented as phases so you can match it to your internal cadence without implying a mandated duration.

Immediate phase (policy drafted and approved path established)

• Draft the cryptographic controls policy with required sections: transit, rest, key management, algorithm selection. ¹
• Identify in-scope cloud environments and owners.
• Stand up an exception workflow and register (even if basic), with required fields and approvers.

Near-term phase (implementation mapped to cloud reality)

• Translate policy into cloud build standards (reference configurations for storage, database, network entry points).
• Implement at least one enforcement mechanism (IaC checks, config policies, or deployment gates) tied to encryption requirements.
• Collect “first audit pack” evidence: policy, approvals, sample configs, and key access controls.

Ongoing phase (prove it stays implemented)

• Add continuous checks for drift and a process to remediate violations.
• Operationalize periodic review of the crypto policy and approved algorithms list based on technology changes and risk.
• Expand evidence collection to cover new services and third parties as they onboard.

Frequently Asked Questions

Do we need separate policies for cloud and on-prem cryptography?

ISO/IEC 27017 focuses on cloud environments, so your policy must clearly address cloud encryption in transit and at rest. You can meet the requirement with one enterprise crypto policy if it explicitly covers cloud responsibilities and control points. ¹

What’s the minimum content auditors expect to see in the crypto policy?

At minimum: encryption for data in transit, encryption at rest in cloud environments, key management rules, and cryptographic algorithm selection governance. If any of these are missing, the policy won’t meet the clause intent. ¹

If our cloud provider encrypts storage by default, are we done for “encryption at rest”?

Not automatically. Your policy must still define what “required” means for your data and how you verify encryption is enabled for the services you use, including backups and snapshots. ¹

How should we handle exceptions for legacy apps that can’t support required encryption?

Document a controlled exception with risk acceptance, compensating controls, and a tracked remediation plan. Auditors will focus on whether exceptions are governed and revisited rather than becoming permanent policy bypasses. ¹

What evidence is strongest for “implemented,” beyond the policy document?

Configuration evidence from cloud services showing encryption settings, plus key management controls (access policies and logs). Pair that with change management or CI/CD controls that prevent noncompliant deployments. ¹

Who should own key management in a cloud customer organization?

The policy should assign ownership explicitly, commonly to a security or platform function with defined approvals and logging requirements. ISO/IEC 27017 cares that key management is governed and implemented, not which org chart box owns it. ¹

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