Control area

Encryption and keys: who owns it on each service model

Whether data is encrypted at rest and in transit, and who generates, holds, rotates and can revoke the keys. Provider-held keys are the default on most platform and software services.

The split by service model

Service model	Owner	Why, and the clause
Infrastructure as a service	yours	On infrastructure you choose whether volumes and objects are encrypted and who holds the keys; the provider supplies the key service, not the decision. ISO/IEC 27017 10.1.2
Platform as a service	shared	The platform encrypts by default with keys it holds; choosing customer-managed keys, their rotation and who may use them is yours. ISO/IEC 27017 10.1.2
Software as a service	the provider's	The provider encrypts the application's data with keys it manages; a key you hold exists only where the service offers one and you turn it on. ISO/IEC 27017 10.1.2
Serverless functions and event services	shared	The platform encrypts by default with keys it holds; choosing customer-managed keys, their rotation and who may use them is yours. ISO/IEC 27017 10.1.2
Hosted AI models and AI platforms	shared	The platform encrypts by default with keys it holds; choosing customer-managed keys, their rotation and who may use them is yours. ISO/IEC 27017 10.1.2

Services that move the line

Key management service: yours The key service holds keys you create; who may use them, their rotation and their deletion are yours. The provider protects the hardware they sit in.

The clauses each framework attaches

8 quoted

Framework	Clause
Cloud Controls Matrix v4.0.1	CCM-CEK-03 Data Encryption · CCM-CEK-08 CSC Key Management Capability
ISO/IEC 27017:2015	ISO/IEC 27017 10.1.2 Key management
ISO/IEC 27001:2022 Annex A	ISO/IEC 27001 8.24 Use of cryptography
CMMC 2.0	CMMC SC.L2-3.13.10 Key Management · CMMC SC.L2-3.13.16 Data at Rest
FedRAMP Moderate	FedRAMP SC-12 Cryptographic Key Establishment and Management
C5 cloud criteria catalogue	C5-CRY-04 Secure key management

CCM-CEK-03 Data Encryption

Apply cryptographic protection to stored data and to data moving across networks, using libraries that hold certification against an approved standard.

What an assessor asks to see:

Configuration evidence showing encryption enabled at rest and in transit per system
The certification of the cryptographic libraries or modules in use, such as a validation certificate
Inventory of data stores and transport paths with their encryption status
Exceptions where encryption is not applied and the risk acceptance behind them

Where it usually falls short:

Encryption at rest claimed from a provider default without verification per data store
Uncertified or self-built cryptographic implementations in use
Internal traffic left unencrypted because it is considered a trusted network

Source: Cloud Controls Matrix v4.0.1

CCM-CEK-08 CSC Key Management Capability

Give cloud customers the means to manage the encryption keys that protect their own data.

What an assessor asks to see:

Documentation of the customer key management capability offered
Technical evidence the capability works, such as a customer-managed key configuration
Guidance published to customers on how to use it
Records of customers who have taken it up

Where it usually falls short:

Capability described in marketing material but not available in the product
Customer keys held in a way the provider can still unilaterally use
No documentation, so customers cannot exercise the capability

Source: Cloud Controls Matrix v4.0.1

ISO/IEC 27017 10.1.2 Key management

Cryptographic keys used by the service should be explained to the customer: the provider should give information about the keys the service uses and the key management options available, including whether the customer may manage its own keys and how keys are protected and destroyed. The customer should decide who manages the keys for its cloud-hosted information and should keep management of keys it controls under its own key management policy.

What an assessor asks to see:

Key management arrangement per cloud service stating who holds keys
Provider documentation of key protection, rotation and destruction
Customer key management records for customer-managed keys

Where it usually falls short:

Keys held by the provider with no statement of who can access them
Customer-managed keys lost, making cloud-hosted data unrecoverable

Source: ISO/IEC 27017:2015

ISO/IEC 27001 8.24 Use of cryptography

Define and implement rules for effective use of cryptography and key management.

What an assessor asks to see:

Encryption policy
Key management procedures
Algorithm inventory
Key usage records

Where it usually falls short:

Missing documented key lifecycle
Use of outdated or weak algorithms
Inadequate segregation of duties for key handling
Lack of regular key rotation evidence

Source: ISO/IEC 27001:2022 Annex A

CMMC SC.L2-3.13.10 Key Management Level 2

Establish and manage the cryptographic keys used by cryptography employed in organizational systems, across their life cycle.

What an assessor asks to see:

Key management procedure covering generation, distribution, storage, rotation and destruction
Key inventory and custodian assignments
Evidence of key rotation and secure storage

Where it usually falls short:

Keys generated and then never rotated or inventoried
Private keys stored alongside the data they protect
Key custodianship undefined so departures leave keys orphaned

Source: CMMC 2.0

CMMC SC.L2-3.13.16 Data at Rest Level 2

Protect the confidentiality of CUI while it is at rest in storage.

What an assessor asks to see:

Inventory of locations where CUI is stored at rest
Encryption or equivalent protection configuration at those locations
Evidence of protection coverage including databases, file shares and endpoints

Where it usually falls short:

Endpoint encryption in place while servers and shares are unprotected
Storage locations for CUI never fully inventoried
Cloud storage protection assumed from the provider without verification

Source: CMMC 2.0

FedRAMP SC-12 Cryptographic Key Establishment and Management

Establish and manage cryptographic keys per FedRAMP requirements (FIPS-validated, key escrow/recovery as appropriate).

What an assessor asks to see:

Control implementation statement for SC-12 citing the system mission and inheritance from common controls
Boundary protection architecture with firewall and proxy rule documentation
Cryptographic standards specifying approved algorithms and key lengths
Key management procedures including rotation and escrow
TLS configuration scan results across in scope endpoints

Where it usually falls short:

Firewall rule base contains stale allow any entries
Internal traffic between services unencrypted within trusted zones
Legacy TLS versions remain enabled on external services

Source: FedRAMP Moderate

C5-CRY-04 Secure key management

Operate key management spanning generation, certificate issuance, activation, storage isolated from application and middleware layers, authorised retrieval, rekeying, compromise handling, withdrawal and deletion, with separate rules stated where pre-shared keys are used.

What an assessor asks to see:

Key lifecycle procedure running from generation through to destruction
Key register recording owner, purpose, cryptoperiod and next rotation date
Proof that the key store operates separately from application and middleware tiers
Key compromise response instruction and any compromise event that invoked it

Where it usually falls short:

Keys generated on general purpose systems with no assured source of entropy
Rotation intervals defined on paper while expired keys stay in productive use
Pre-shared secrets circulated by mail or chat with no dedicated handling provisions

Source: C5 cloud criteria catalogue