Policy on the use of cryptographic controls

A “policy on the use of cryptographic controls” sounds like paperwork until you map it to what auditors and enterprise customers actually ask: where is PII encrypted, with what cryptographic approach, who controls the keys, and what happens when encryption cannot be applied. ISO/IEC 27018:2019 Clause 10.1.1 turns those questions into a requirement: set a defined policy, implement it in your cloud service operations, and provide clear information to customers about the circumstances in which you use cryptography to protect PII.

For a CCO, GRC lead, or security compliance owner, the fastest path to operationalizing this requirement is to treat it as a product-and-operations contract: engineering must implement encryption patterns consistently; security must own standards, approvals, and exceptions; legal/compliance must ensure customer-facing disclosure is accurate and not overbroad; support and sales engineering must be able to explain real-world behavior (including edge cases like logs, backups, and exports).

This page gives requirement-level guidance you can execute quickly: a practical interpretation, who it applies to, an implementation checklist, evidence to retain, typical audit hangups, common mistakes, and a phased execution plan.

Regulatory text

Requirement (verbatim): “A policy on the use of cryptographic controls for protection of information shall be developed and implemented. The public cloud PII processor shall provide information to the cloud service customer regarding the circumstances in which it uses cryptography to protect PII.” ¹

What the operator must do

You must produce a documented cryptography policy and prove it is actually used to run the service (implemented through standards, system configurations, reviews, and exception handling). You must also provide customer-facing information that explains when cryptography protects PII (for example, in transit, at rest, in backups) and under what conditions (for example, which service tiers, which customer configurations, which regions, which features).

---

Plain-English interpretation

If you process customer PII in a public cloud service, you need to:

1. Standardize your encryption decisions. Define which data types must be encrypted, where encryption is required, what “approved cryptography” means in your environment, and who can approve deviations.
2. Make it real in production. Convert policy into engineering requirements (defaults, guardrails, CI/CD checks, platform controls) and operational processes (key rotation, access controls to keys, incident response considerations).
3. Tell customers the truth in a usable format. Provide a clear description of how encryption is applied to PII and the scenarios where it may differ (customer-managed keys vs provider-managed keys, optional features, customer misconfiguration, exports, or integrations).

A strong implementation reads like a contract between security, engineering, and customer-facing teams: “This is what we do by default; this is what you can configure; this is what we do not encrypt; and this is who owns the keys.”

---

Who it applies to (entity and operational context)

In-scope entities

• Public cloud PII processors providing cloud services that process PII on behalf of customers ¹

In-scope operational contexts (practical view)

• Production services that store, transmit, or transform customer PII
• Data pipelines (ingest, ETL/ELT, streaming)
• Observability systems that may capture PII (logs, traces, error reports)
• Backups, snapshots, archives, DR environments
• Admin and support access paths
• Third parties used in delivery (subprocessors) where PII could be encrypted (or not) before transfer

---

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

Step 1: Define the cryptography policy scope and ownership

• Name an owner (security or GRC) accountable for policy maintenance and exception governance.
• Define scope: what constitutes “information” for policy purposes, and what constitutes “PII” within your service and telemetry.
• Establish how policy becomes enforceable: referenced by engineering standards, secure SDLC requirements, platform guardrails, and customer documentation.

Operator tip: If your cryptography policy is not referenced by engineering requirements or architecture review checklists, auditors will treat it as “paper compliance.”

Step 2: Specify baseline cryptographic requirements by data state

Create explicit requirements for:

• Data in transit: encryption for service endpoints, internal service-to-service traffic where feasible, and administrative access.
• Data at rest: encryption for databases, object storage, file systems, and managed services storing PII.
• Backups and replicas: encryption expectations for snapshots, archives, and DR copies.
• Data exports and integrations: whether exported files are encrypted by default, and what the customer must do.

Write the policy so it can be tested. Avoid vague language like “encrypted as appropriate.” Your policy should translate into configuration checks and architecture patterns.

Step 3: Decide and document key management responsibilities (the audit hotspot)

Your policy should state:

• Whether you offer provider-managed keys, customer-managed keys, or both.
• Who can access or administer keys and under what approvals.
• How keys are created, stored, rotated, disabled, and retired.
• How key access is logged and reviewed.

Then map this to the customer-facing disclosure: customers need to understand whether they can bring their own key, what that changes, and what it does not change.

Step 4: Establish an exception process that is fast, documented, and enforceable

Auditors will accept exceptions if they are controlled. Build a lightweight workflow:

• Exception request with scope, rationale, compensating controls, and end date.
• Approval by security (and product owner when customer impact exists).
• Centralized exception register.
• Periodic review and closure.

Step 5: Implement controls and prove implementation

Implementation evidence typically comes from:

• Cloud configuration baselines (encryption settings enabled by default)
• Infrastructure-as-code modules enforcing encryption flags
• Secure SDLC controls that require encryption decisions in design reviews
• Automated checks (policy-as-code) that block or alert on unencrypted PII stores

Make sure “implemented” includes operational processes: key rotation tasks, access review for key administrators, and incident runbooks that consider key compromise scenarios.

Step 6: Produce customer-facing disclosure (“circumstances” disclosure)

ISO 27018 explicitly requires telling customers the circumstances in which cryptography is used for PII ¹. Publish a clear statement in one or more of:

• Security whitepaper / trust page
• Data processing addendum (technical exhibit)
• Customer admin guide (encryption section)
• Service description / shared responsibility model

Minimum content to include:

• Where encryption applies (in transit, at rest, backups) for PII
• Preconditions and limitations (feature flags, service tiers, regional constraints, customer configuration requirements)
• Key ownership model and customer options (if any)
• How customers can verify or configure encryption settings (where applicable)

Customer-facing language standard: Avoid absolutes you cannot test. Replace “all data is encrypted everywhere” with precise statements tied to systems and configurations.

Step 7: Align third parties (subprocessors) to your cryptography policy

If PII flows to third parties, ensure contracts and due diligence confirm:

• Encryption expectations for transfers
• Storage encryption expectations
• Key management responsibilities (especially for managed services)
• Breach notification and incident handling related to cryptographic failures

A practical approach is to add a cryptography section to your third-party security questionnaire and to require architecture diagrams for high-risk subprocessors.

---

Required evidence and artifacts to retain

Maintain an audit-ready packet that answers: “Show me the policy, show me it’s implemented, show me what you tell customers.”

Core artifacts

• Cryptography policy (approved, versioned, reviewed)
• Supporting standards (encryption standard, key management standard, secure transport standard)
• Data classification guidance showing how PII triggers encryption requirements
• Architecture patterns / reference designs for encrypting PII in approved storage and transit paths
• Key management procedures (rotation, access approvals, break-glass)
• Exception register with approvals and remediation plans
• Customer-facing disclosure(s) and change log

Implementation evidence examples

• Screenshots/exports of encryption settings enabled in cloud consoles for core services storing PII
• IaC repositories showing encryption defaults
• Design review templates showing cryptography questions and approvals
• Logs or access review outputs for key administrator roles
• Training or enablement materials for support/Sales Engineering on explaining encryption “circumstances”

---

Common exam/audit questions and hangups

1. “Show me where the policy is enforced.” Auditors want linkage from policy to technical controls and review gates.
2. “Who controls the keys?” If this is unclear, expect findings. Be explicit about shared responsibility and customer options.
3. “Does encryption cover backups, logs, and replicas?” These are frequent gaps. Have a defensible answer and documented exceptions.
4. “What do you tell customers?” Customer-facing disclosure must be specific and consistent with reality.
5. “How do you handle exceptions?” A spreadsheet with no approvals or review cadence reads as unmanaged risk.

---

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy says “encrypt PII,” but nobody defined what counts as PII in telemetry.
  Fix: Maintain a PII data inventory and explicitly address logs, analytics events, and support dumps.

• Mistake: Customer disclosure is marketing language.
  Fix: Write disclosures like an engineer would. Name data states, control boundaries, and customer responsibilities.

• Mistake: Key management is outsourced to a single admin group with weak governance.
  Fix: Define privileged access controls for key administrators, require approvals, and retain access review evidence.

• Mistake: Exceptions are permanent.
  Fix: Require expiration and a remediation plan for any exception tied to PII storage or transport.

• Mistake: Encryption is enabled but not monitored.
  Fix: Add detective controls that alert on creation of unencrypted storage where PII could land.

---

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement risk as indirect: customers, auditors, and regulators often view weak cryptographic governance as a multiplier during incident response and privacy investigations. Your operational risk concentrates around (1) unclear key ownership, (2) unencrypted secondary stores like backups or logs, and (3) customer communications that overpromise.

---

Practical 30/60/90-day execution plan

First 30 days (foundation and truth-finding)

• Identify systems that store/process PII, including logs and backups.
• Draft the cryptography policy and key management responsibilities section.
• Inventory current encryption posture by data state, note gaps and undocumented practices.
• Collect existing customer-facing statements and flag inaccuracies.

Next 60 days (implementation and governance)

• Publish policy and supporting standards, roll into architecture/security review checklists.
• Implement encryption defaults in IaC modules and platform baselines for in-scope services.
• Stand up the exception workflow and register.
• Draft customer-facing disclosure with security + legal + product review.

By 90 days (prove it, package it, scale it)

• Produce the audit evidence packet (policy, standards, configs, exceptions, disclosure).
• Run an internal audit-style walkthrough: pick one PII dataset and trace it through transit, storage, backups, logs, and third parties.
• Train support and Sales Engineering on the approved encryption narrative and how to handle edge-case questions.
• Consider tooling to manage evidence collection and third-party cryptography attestations; Daydream can help centralize policy-to-evidence mapping and keep customer disclosures aligned with control reality.

Frequently Asked Questions

Do we need to encrypt all PII at rest and in transit to meet the requirement?

ISO/IEC 27018:2019 Clause 10.1.1 requires a policy to be developed and implemented and requires customer disclosure about when cryptography is used for PII ¹. Your policy should make your encryption expectations explicit and define how you govern any exceptions.

What does “circumstances in which it uses cryptography” mean in customer-facing terms?

It means you should clearly describe where encryption applies (for example, in transit, at rest, backups) and what conditions affect coverage (service tiers, regions, optional features, customer configuration). Keep it consistent with actual architecture and operational practices ¹.

Can we meet the requirement if customers manage their own encryption keys?

Yes, if your policy clearly defines the shared responsibility model and you disclose to customers how customer-managed keys change the cryptographic protections and operational processes. Auditors will still expect you to document and implement controls around key access paths you control ¹.

Where should we publish the customer disclosure?

Put it where customers can reliably find it during due diligence: a security whitepaper, technical appendix in your DPA, and/or an admin guide encryption section. The key is that it is accessible, accurate, and maintained as the service changes ¹.

How do we handle cases where encryption is technically difficult (legacy systems, certain logging tools)?

Document an exception with compensating controls and a remediation plan, then disclose any material limitations in customer-facing language if they affect how PII is protected. Treat “hard to encrypt” as a tracked risk, not an unwritten reality.

What evidence will an auditor ask for beyond the policy document?

Expect requests for proof of implementation: configuration baselines, IaC settings, design review records, key management procedures, exception approvals, and the customer-facing disclosure describing cryptographic circumstances ¹.

Footnotes

1. 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