GASP AICF

Search controls and profiles

Search by control ID, name, domain or profile

DAT-021 Customer-Managed Encryption Keys

Tier 3+ProviderManaged Service Providerdeployment model

Description

A customer can supply, hold and withdraw the encryption key that protects its own tenant data, through a published key ownership statement that names which keys the provider holds, which the customer holds and what the service does to the customer's data when a customer key is withdrawn or the provider's permission to use it is removed. Withdrawal renders the affected tenant data unreadable to the service within the period the statement gives. The service records the withdrawal and the resulting loss of access. The behaviour on withdrawal is tested against a tenant configured with a customer key and the result is recorded.

Rationale

A customer-held key gives the customer a revocation path that does not depend on the provider acting, which is the reason enterprise buyers and regulated sectors ask for it. It is only worth having if the revocation actually severs access, so the control turns on the tested behaviour rather than on the key being nominally customer-owned. DAT-005 holds the lifecycle of provider-held keys; DAT-003 holds encryption at rest itself. Issued in S4 from the NC-G proposal in docs/review-coverage-security.md section 2.1.

Applicability (9 profiles)

SaaS AI Providerstablerequireddeployment duty

Customer-held keys are a commitment of a hosted service.

Enterprise AI Deployerstableconditionaldeployment duty

Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped

Where the deployer runs the AI system on infrastructure it controls, key ownership and the behaviour on withdrawal are its own. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider and the deployer obtains the key ownership statement and the withdrawal test result under VND-004.

GPAI Model Providerstableconditionaldeployment duty

Condition: deployment_model in cloud-saas, cloud-single-tenant

Customer-held keys are a commitment of a hosted service. Conditional since 1.1: the profile lists every deployment model and this row is a commitment of a hosted service, so a provider that publishes weights or runs on infrastructure the customer controls has no hosted service to carry it (ADR-046 amendment, 2026-09-16).

High-Risk Provider (EU)stablerequireddeployment duty

Customer-held keys are a commitment of a hosted service.

Public Body Deployer (EU)stableconditionaldeployment duty

Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped

Where the deployer runs the AI system on infrastructure it controls, key ownership and the behaviour on withdrawal are its own. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider and the deployer obtains the key ownership statement and the withdrawal test result under VND-004.

Data Act Cloud Provider (EU)stablerequiredrole duty

Customer-held keys stop being only a commercial commitment under this instrument. Art. 28(1)(b) requires the technical measures preventing international governmental access to be described publicly. A tested key withdrawal that renders tenant data unreadable to the service is the strongest thing a provider has to put in that description.

DORA ICT Provider (EU)stablerequireddeployment duty

Customer-held keys are a commitment of a hosted service.

HIPAA Business Associate (US)stablerequireddeployment duty

Customer-held keys are a commitment of a hosted service.

NIS2 Cloud Provider (EU)stablerequireddeployment duty

Customer-held keys are a commitment of a hosted service.

Framework Mappings (5)

CEK-08Service Customer Key Management Capabilityfull
CEK-08Service Customer Key Management Capabilityfull
EU-DA-Art.32.1Measures Preventing Unlawful Third-Country Accessinformative
HIPAA-164.312.a.2.ivEncryption and Decryptioninformative
SC-12Cryptographic Key Establishment and Managementinformative

Evidence (3)

configurationtechnicalautomated

Key management service configuration for a tenant using a customer-supplied key, showing the key material owner, the grant that lets the service use the key and the tenant resources encrypted under it.

Example: Key management service key policy and grant export for tenant ACME-PROD, dated 2026-08-14, showing the customer key ARN, the grant issued to the service role and the storage volumes and database instances encrypted under that key

Test: Export the key configuration for a tenant using a customer-supplied key. Verify: (1) the key material is held under the customer's control and not in the provider's own key hierarchy, (2) the service holds a grant or delegation that the customer can remove without provider action, (3) every store holding that tenant's data is encrypted under the customer key rather than a provider default key, (4) the resources listed match the scope the key ownership statement claims.

observationobservationmanual

Live withdrawal test in which a customer key is disabled or its grant removed and the effect on the service's access to that tenant's data is observed.

Example: Witnessed key withdrawal test on the customer-key test tenant, 2026-07-02, recording the time the grant was removed, the first failed read and the state the tenant was left in

Test: Withdraw the key or remove the grant on a test tenant. Verify: (1) reads and writes to that tenant's data fail within the period the key ownership statement gives, (2) no cached or secondary copy of the tenant's data remains readable to the service after that period, (3) the withdrawal and the loss of access are recorded, (4) other tenants are unaffected.

policydocumentmanual

Published key ownership statement setting out which keys the provider holds, which the customer holds, how a customer supplies or withdraws a key and the effect of withdrawal.

Example: Key ownership and customer key handling statement v2.1, dated 2026-05-30, published in the trust centre and referenced from the data processing agreement

Test: Read the published key ownership statement. Verify: (1) it names each key in the encryption path and says who holds it, (2) it states how a customer supplies, rotates and withdraws its key, (3) it states the period within which withdrawal takes effect and what happens to the tenant's data after it, (4) its version and approval date are current against the key configuration in use.

Questions (3)

boolean

Can a customer supply and hold the encryption key that protects its own tenant data?

Answer yes only where the key material sits under the customer's control and the customer can withdraw the service's use of it without the provider acting. A provider-held key that is dedicated to one tenant is not a customer-managed key; that is DAT-005.

multi

Which of the following does the key ownership statement give to customers?

Which keys the provider holds and which the customer holdsHow a customer supplies, rotates and withdraws its keyWhat happens to the tenant data when a customer key is withdrawnThe period within which withdrawal takes effectNone of the above

A customer reads the statement before deciding whether to use its own key, so each element is tested against the live key configuration rather than against the sales material. Publishing it in a trust centre or annexing it to the data processing agreement both count.

select

How is the effect of withdrawing a customer key verified?

Tested at defined intervals on a tenant configured with a customer key, with the result recordedTested once when the capability was built, with the result recordedDescribed in documentation but not testedNeither tested nor described

Options run from strongest to weakest. The test that matters is whether the service loses access within the period the statement gives, including access through caches and read replicas. A capability that has never been exercised is an assertion, not a control.