KMS, cryptographic erasure, and ecommerce data

A customer asks bfstore to remove their account.

The customer profile is deleted from MySQL.

The job reports:

customer_deleted = true

The application has removed one row.

The customer may still exist in:

• order records
• shipping events
• payment-provider references
• Kafka topics
• search indexes
• application logs and traces
• support exports
• database snapshots
• cross-account backups
• disaster-recovery copies
• a CSV downloaded during an incident

Deleting the live row is not the same as eliminating every recoverable representation of the data.

Encryption adds another possible control. If the remaining copies are ciphertext and every key path required to decrypt them is permanently removed, the ciphertext may remain physically present while the protected plaintext becomes infeasible to recover.

That is the idea behind cryptographic erase.

NIST SP 800-88 Revision 2 describes cryptographic erase as a purge technique based on sanitising the keys that encrypt data, or keys that prevent access to those encryption keys. It also places strict conditions on the claim: sensitive data must not previously have been stored in plaintext on the affected storage, all relevant key copies must be sanitised, and backed-up, escrowed or unwrapped keys must be handled separately.¹

That is much stricter than:

We deleted the KMS alias.

or:

We turned encryption on.

Cryptographic erasure is not a button. It is an evidence-backed claim that no usable route from the remaining ciphertext to its plaintext still exists.

AWS KMS can control an important part of that route. The architecture must still know where the data, derived copies and relevant keys live.

Throughout this article, bfstore is a hypothetical AWS-hosted ecommerce platform used to make the design choices concrete. The intended audience is application, platform and security engineers designing access, recovery and deletion boundaries. This is not legal advice or a complete KMS operations manual.

AWS service behaviour in this article was checked against official documentation on 31 July 2026. Service state transitions and permission requirements should be confirmed again when a production runbook is used.

The decision in one table

The recurring question is not simply:

Is this encrypted?

It is:

Which data must be accessible,
recoverable and destroyed together?

Define the erasure claim before choosing the mechanism

“No usable route remains” needs a scope.

For bfstore, the technical claim should cover:

• the identified ciphertext;
• every retained plaintext or derived representation;
• KMS keys and application data keys controlled by bfstore;
• wrapped-key copies in databases, events, exports and backups;
• grants, replicas and external key stores that can restore access;
• plaintext keys still held in application or service memory.

It does not prove that plaintext was never copied or exfiltrated before the erasure operation. It does not protect against a future failure of the cryptographic algorithm. It does not automatically establish compliance with every legal or contractual deletion requirement.

The evidence should therefore separate three claims:

TECHNICAL CLAIM

The identified ciphertext cannot be
decrypted through any retained key path.


DATA-LIFECYCLE CLAIM

Live, replicated, exported and backup
representations were handled under
the approved retention policy.


COMPLIANCE CLAIM

The organisation reviewed whether
that process satisfies the applicable
legal and contractual obligations.

Keeping those claims separate makes each one more credible.

Encryption at rest is only one stage of the lifecycle

AWS services provide broad encryption-at-rest support. For example, Amazon S3 encrypts new objects by default, RDS encryption covers database storage, logs, automated backups and snapshots, and DynamoDB encrypts table data, indexes, streams and backups.²³⁴

That protection matters. Someone who obtains encrypted storage should not automatically obtain readable data.

But encrypted does not answer:

• Who may request decryption?
• Which workloads share the key?
• Which backup has another key?
• What happens during recovery?
• Which records become unreadable if the key is deleted?
• Does the same plaintext exist elsewhere?
• Is the data being retained longer than necessary?

The UK Information Commissioner’s Office says organisations should establish retention periods, erase or anonymise data that is no longer needed, and address backup data rather than treating deletion from the live system as the whole process.⁵

A useful sequence is:

DATA CLASSIFICATION
        │
        ▼
RETENTION RULE
        │
        ▼
ENCRYPTION BOUNDARY
        │
        ▼
RECOVERY DESIGN
        │
        ▼
ERASURE DESIGN

Encryption should be designed with the final stage already visible.

KMS usually protects the keys that encrypt the data

Large application payloads are generally protected through envelope encryption.

PLAINTEXT DATA
      │
      ▼
DATA KEY
      │
      ▼
CIPHERTEXT DATA


DATA KEY
      │
      ▼
KMS KEY
      │
      ▼
ENCRYPTED DATA KEY

AWS KMS can generate a plaintext data key for immediate use and an encrypted copy that can be stored with the encrypted data.⁶ The application or AWS service then stores:

ciphertext

+

encrypted data key

When the data is read:

1. the encrypted data key is sent to KMS;
2. KMS authorises the operation;
3. KMS returns the plaintext data key;
4. the data key decrypts the application data;
5. the plaintext key should be removed from memory as soon as possible.

KMS does not retain an inventory of every data key, row, object, export or backup protected through that process. It also does not store the application ciphertext.⁷

KMS CAN RECORD

the KMS key
the cryptographic request
the caller
the policy and encryption context


KMS DOES NOT INVENTORY

every database row
every S3 object version
every backup
every exported encrypted data key
every plaintext copy

Deleting a KMS key can make the data keys wrapped by it unusable. It cannot prove that another data-key copy or plaintext representation does not exist.

Key topology becomes deletion topology

Suppose every production resource uses:

alias/bfstore-prod

It protects:

• customer and order databases;
• application logs;
• Kafka storage;
• snapshots;
• backup vaults;
• sensitive exports.

The policy inventory is small. The destruction boundary is enormous.

DELETE ONE KEY
      │
      ├── customer records unreadable
      ├── orders unreadable
      ├── logs unreadable
      ├── backups unreadable
      └── operational recovery lost

The key cannot selectively erase one customer. It also cannot retire one service without affecting unrelated workloads.

At the other extreme, one KMS key per row would create a large key inventory, difficult policies, recovery complexity and avoidable cost.

The useful boundary usually lies between those extremes.

A KMS key should protect data that shares an access policy, recovery policy and destruction lifecycle.

For bfstore, a first layout might be:

alias/bfstore-prod-customer-data
alias/bfstore-prod-order-data
alias/bfstore-prod-payment-tokens
alias/bfstore-prod-application-logs
alias/bfstore-prod-sensitive-exports
alias/bfstore-prod-backups

This is not a rule that every resource needs a unique key. It is a warning against placing unrelated destruction and recovery requirements under one cryptographic roof.

Ecommerce data does not have one lifecycle

The data model should let these lifecycles diverge.

An order may need to survive account closure, but it may not need to keep the customer’s email and full shipping address for the same period. Public catalogue data may still be encrypted, but key deletion is unlikely to be its main end-of-life mechanism.

Record-level crypto-shredding needs a dedicated envelope

Deleting a database-level KMS key affects the encrypted resource, not one customer.

CUSTOMER DATABASE
        │
        ▼
alias/bfstore-prod-customer-data

For narrower control, bfstore can selectively apply application-level envelope encryption to high-risk fields or records.

customer_id: customer-8042

encrypted_profile:
  ciphertext: AQICAH...
  encrypted_data_key: AQIDAH...
  algorithm: AES-256-GCM
  schema_version: 2

The sensitive profile is encrypted with a data-encryption key. The wrapped copy of that data key is stored with the ciphertext.

At customer deletion, bfstore may remove every recoverable copy of:

• the wrapped data key;
• plaintext projections and indexes;
• duplicate envelopes in events or exports;
• cached plaintext keys;
• the ciphertext itself, where the retention policy requires deletion.

For shared KMS keys, this narrower pattern is often called record-level crypto-shredding. NIST’s guidance supports sanitising wrapped versions of data-encryption keys as a way to prevent decryption, but the assurance conditions still apply: every wrapped or unwrapped copy must be addressed.¹

Deleting one wrapped-key row from the live database is not enough when the same envelope survives in a snapshot, Kafka event, support export or replicated store.

Also keep two actions distinct:

DATA DELETION

remove the ciphertext or plaintext record


CRYPTOGRAPHIC ERASURE

eliminate every usable decryption-key path

A robust customer-erasure workflow may use both. They are not the same operation.

Application envelope encryption should be selective. Good candidates include saved addresses, high-risk profile attributes, sensitive support attachments and confidential exports. Encrypting every ordinary column independently without an access or deletion reason creates complexity rather than useful control.

Payment data: minimise before encrypting

Encryption is not permission to collect every payment field.

PCI DSS requires retention to be limited to legal, regulatory and business needs. Card verification codes or values cannot be retained after authorisation, even if encrypted. Encryption of stored cardholder data also does not, by itself, remove the environment from PCI DSS scope.⁸⁹¹⁰

A preferred application record looks like:

payment:
  provider: example-processor
  provider_customer_id: cus_7f42
  provider_payment_method_id: pm_91a8
  payment_intent_id: pi_4431
  card_brand: visa
  card_last_four: "4242"
  status: authorised

Not:

payment:
  pan: "4242424242424242"
  expiry: "12/30"
  card_verification_value: "123"

The safer sequence is:

DO NOT COLLECT UNNECESSARY DATA
            │
            ▼
USE PROVIDER TOKENISATION
            │
            ▼
ENCRYPT RETAINED REFERENCES

Provider tokens and transaction identifiers still need protection. They may permit refunds, account actions or valuable operations in the wrong application context.

Encryption context binds purpose, not identity

AWS KMS supports an encryption context for symmetric cryptographic operations. It is non-secret additional authenticated data that is cryptographically bound to the ciphertext. The same exact, case-sensitive context must be supplied for decryption. Context values may also be used in policy conditions and appear in plaintext in CloudTrail.¹¹

Suitable:

{
  "service": "customer",
  "record-type": "shipping-address",
  "environment": "production"
}

Unsuitable:

{
  "customer-email": "mariam@example.com",
  "shipping-address": "42 Example Road"
}

A policy fragment might require the expected service and environment:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/bfstore-customer-runtime"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:service": "customer",
      "kms:EncryptionContext:environment": "production"
    }
  }
}

This is an illustrative key-policy fragment, not a complete production policy. A full design may also need account and service constraints, grant controls, organisation policies and protection against confused-deputy paths.

Encryption context improves integrity, audit evidence and purpose restriction. It does not create a new destruction boundary. One KMS key may still wrap many data keys carrying different contexts.

Key policy is part of the data boundary

Every KMS key has one key policy, and AWS describes key policies as the primary mechanism for controlling access. IAM policies, grants and VPC endpoint policies may also participate.¹²

Separate key administration from ordinary data use:

KEY ADMINISTRATOR

may:
    update key policy
    manage rotation
    disable key
    schedule deletion

does not automatically need:
    decrypt customer data


APPLICATION ROLE

may:
    generate data keys
    decrypt approved envelopes

must not:
    change key policy
    disable the key
    schedule deletion

A backup service may need another constrained path. The exact permissions depend on the service integration.

The ability to decide whether data may ever be decrypted again is more powerful than permission to decrypt it today. kms:ScheduleKeyDeletion should be rare, reviewed and monitored.

What does not establish erasure

Deleting an alias

Aliases are mutable names for keys. Removing an alias does not delete the underlying KMS key or its material.

Inventory and evidence should use the stable key ARN and key ID where exact identity matters.

Rotation

KMS rotation changes the key material used for new encryption operations. KMS retains the older material required to decrypt existing ciphertext.¹³

BEFORE ROTATION

ciphertext A → material version 1


AFTER ROTATION

ciphertext A → still decryptable with version 1
ciphertext B → encrypted with version 2

Rotation does not re-encrypt existing application data, rotate stored data keys or erase old ciphertext.

Temporary disablement

Disabling a customer managed key makes KMS cryptographic operations fail, but it is reversible. It is useful for incident containment and dependency testing.

The impact on workloads may be delayed. Services or applications that already hold plaintext data keys can continue until they need KMS again.¹⁴

Disablement is therefore a rehearsal, not destruction.

Scheduling deletion without waiting

AWS KMS requires a deletion waiting period of 7 to 30 days, with 30 days as the default. During PendingDeletion, the key cannot perform cryptographic operations, but deletion can still be cancelled. Once the waiting period completes, the KMS key, key material and metadata are irreversibly deleted.⁷

A rehearsal must run long enough to exercise actual key reuse, service caches and normal recovery paths.

Recovery deliberately complicates erasure

A backup exists so that data survives loss of the primary copy. Cryptographic erasure exists so that data cannot survive loss of its required key. Those goals can conflict.

If production and backup use the same key:

PRIMARY ── key A
BACKUP  ── key A

Deleting key A may remove both the workload and its recovery path.

If the backup copy uses an independent key:

PRIMARY             ── production key
CROSS-ACCOUNT COPY  ── backup-account key

Deleting the production key does not erase the backup. That improves recovery isolation, but final erasure must also address the recovery point, destination key, retention schedule and any locked vault policy.

AWS Backup generally encrypts cross-account and cross-Region copies using the target vault’s KMS key, with resource-specific caveats.¹⁵

This is not a flaw. It is the expected result of separating recovery credentials from production credentials.

PRODUCTION KEY COMPROMISED

preserve independent recovery


DATASET RETENTION EXPIRES

remove live data and every retained copy


CUSTOMER ERASURE REQUEST

handle that customer's fields under
the approved retention basis

One KMS-key deletion cannot safely represent all three events.

Service behaviour is not uniform

The architectural principle is stable: a restore requires usable data and a usable key. The exact failure states are service-specific.

A backup encrypted under a deleted key is not an escape hatch. Recovery needs a key path too.

Multi-Region and imported keys widen the boundary

Related KMS multi-Region keys share key material and can decrypt one another’s ciphertext across Regions. Deleting one relative does not establish erasure while another remains usable. AWS KMS keeps a primary key in PendingReplicaDeletion until all replicas have been deleted, after which the ordinary deletion waiting period begins.¹⁸

Inventory:

• the primary;
• every replica;
• Region-specific policies and grants;
• disaster-recovery resources;
• replicated and backup data.

Imported key material adds an external copy by design. AWS recommends retaining the material outside AWS so it can be reimported if the KMS copy expires or is deleted.¹⁹

KMS COPY

deleted


EXTERNAL HSM COPY

still exists

That is temporary withdrawal, not permanent erasure. The erasure process must include external HSM backups, escrow and runbooks capable of reimporting the material.

Deleting imported material from a KMS key can be reversed by reimporting the same material. Deleting the KMS key after its waiting period is different and irreversible.²⁰⁷

Plaintext keys and values can outlive a KMS request

Envelope encryption puts plaintext data keys outside KMS while data is being encrypted or decrypted. They may exist in:

• application memory;
• service caches;
• cryptographic-library state;
• hardware registers;
• crash dumps;
• diagnostic captures.

NIST specifically requires assurance that unwrapped key copies in volatile memory or encryption engines are eliminated as part of a cryptographic-erase operation.¹

Application code should:

• use reviewed encryption libraries;
• minimise plaintext-key lifetime;
• never log key material;
• avoid support workflows that collect unrestricted memory dumps;
• clear mutable buffers where the language and library make that meaningful;
• restart or drain workloads when a high-assurance erasure requires cached keys to disappear.

Go does not offer a universal guarantee that overwriting one variable removes every compiler-created or runtime copy. That is another reason not to build custom cryptographic protocols in business code.

KMS does not know every dependency

Before deleting a KMS key, AWS recommends determining its past usage. KMS does not maintain a list of all ciphertexts protected by the key, and local use of a previously generated data key is not visible as a new KMS operation.⁷²¹

Evidence must combine:

• CloudTrail;
• infrastructure-as-code state;
• AWS Config or resource inventory;
• RDS, S3, DynamoDB and AWS Backup metadata;
• application envelope registries;
• grants and cross-account access;
• disaster-recovery inventories;
• retention and deletion records.

A key record could contain:

key:
  alias: alias/bfstore-prod-customer-data
  arn: arn:aws:kms:eu-west-2:111122223333:key/example
  region: eu-west-2
  type: symmetric
  regionality: single-region
  material_origin: AWS_KMS

ownership:
  data_owner: customer-service
  key_administrator: security-platform
  backup_owner: bfstore-backup

data:
  classification: customer-personal-data

resources:
  primary:
    - rds-customer-prod
    - customer-export-bucket
  backups:
    - customer-rds-snapshot-policy
    - bfstore-backup-account-copy

deletion:
  waiting_period_days: 30
  disable_rehearsal_required: true
  restore_test_required: true
  approvers:
    - data-owner
    - security
    - backup-owner

No key should reach deletion with its purpose described as:

probably old

Key deletion needs a two-person-shaped process

A safe production process might be:

1. The data owner confirms that the retention basis has ended.
2. The resource owner inventories every dependent resource and application envelope.
3. The backup owner confirms every recovery point and destination key.
4. Security reviews policy, grant and usage evidence.
5. The key is disabled.
6. Workloads are observed through a meaningful rehearsal period.
7. Restore tests confirm which recovery paths remain.
8. A separate privileged role schedules deletion.
9. Attempted use during the waiting period produces alarms.
10. Unexpected dependencies trigger cancellation.
11. Final deletion evidence is retained.

RETENTION APPROVAL
        │
        ▼
DEPENDENCY INVENTORY
        │
        ▼
DISABLE AND OBSERVE
        │
        ▼
RESTORE TEST
        │
        ▼
SCHEDULE DELETION
        │
        ▼
ALARMED WAITING PERIOD
        │
        ├── unexpected use → cancel
        └── no dependency  → continue
        │
        ▼
FINAL DELETION
        │
        ▼
ERASURE EVIDENCE

AWS records CloudTrail events when deletion is scheduled and when the key is deleted. Policy can also constrain the requested waiting period using kms:ScheduleKeyDeletionPendingWindowInDays.⁷²²

The waiting period is the last recovery window before an irreversible action.

Customer erasure starts with a data map, not a KMS command

CUSTOMER ID
    │
    ├── customer service
    ├── order service
    ├── payment references
    ├── shipping service
    ├── notification service
    ├── Kafka and search
    ├── logs and traces
    ├── analytics
    └── backups

Each representation then receives one of four decisions.

Delete now

Examples:

• live customer profile;
• saved addresses;
• marketing preferences;
• inactive sessions;
• unnecessary search projections.

Transform

An order may initially contain:

order:
  order_id: order-8042
  customer_id: customer-421
  customer_email: mariam@example.com
  shipping_name: Mariam Example
  shipping_address: 42 Example Road
  items:
    - product_id: product-11
      quantity: 2
  total_pence: 8900

A later retained form might become:

order:
  order_id: order-8042
  customer_reference: deleted-customer
  items:
    - product_id: product-11
      quantity: 2
  total_pence: 8900
  fulfilment_region: GB
  personal_data_removed_at: 2026-06-22

Whether this is anonymous or merely pseudonymous depends on the remaining data and bfstore’s ability to reconnect it with other records. The architecture should not label data anonymous without assessing re-identification.

Retain under an approved basis

Examples may include tax records, chargeback evidence, fraud investigation or legal claims. This is a legal and business decision, not one KMS can make.

Put beyond ordinary use until backup expiry

The live system no longer exposes the data. Backup procedures prevent it from being used for another purpose and allow it to expire under an established schedule. The ICO describes this “beyond use” approach for backup data that cannot be overwritten immediately, while stressing that the organisation must be clear about the process.²³

Where a dedicated field or record envelope exists, bfstore can also destroy every wrapped data-key copy and remove the corresponding plaintext projections. That does not normally require deleting the shared service KMS key.

Restores must replay erasure decisions

Suppose a customer is erased on 22 June.

A backup from 15 June still contains the profile.

In August, an incident restores that backup.

15 JUNE BACKUP
      │
      ▼
22 JUNE CUSTOMER ERASED
      │
      ▼
10 AUGUST RESTORE
      │
      ▼
CUSTOMER DATA REAPPEARS

The restore process needs an erasure ledger, or an equivalent durable reconciliation mechanism, containing deletion and retention changes made after the recovery point.

Before customer traffic resumes:

1. restore the backup;
2. replay ordinary database events;
3. replay the erasure ledger;
4. rebuild search, cache and analytics projections;
5. verify that removed data has not returned;
6. record the reconciliation evidence.

RESTORE BACKUP
      │
      ▼
REPLAY APPLICATION CHANGES
      │
      ▼
REPLAY ERASURE LEDGER
      │
      ▼
REBUILD PROJECTIONS
      │
      ▼
VERIFY
      │
      ▼
RETURN TO SERVICE

A restore that resurrects data the business committed to removing is technically successful and operationally wrong.

Backup tests should therefore verify privacy and retention behaviour, not only whether MySQL starts.

Proposed bfstore approach

For bfstore, I would use the following model:

• Use AWS-service encryption for production storage, logs, event infrastructure and backups.
• Use customer managed KMS keys where bfstore needs control over policy, audit, disablement or deletion.
• Separate keys by environment, service or data owner, classification and recovery boundary.
• Keep payment-account data outside bfstore through hosted collection and provider tokenisation.
• Apply application envelope encryption selectively to data with a clear access or erasure requirement.
• Keep encryption context non-sensitive and purpose-oriented.
• Give production backups independent keys where recovery isolation requires it, while documenting their separate erasure lifecycle.
• Treat key deletion as a production change requiring inventory, rehearsal, restore testing, multiple approvals and retained evidence.
• Make erasure-ledger replay a mandatory restore gate.

The final mental model is:

DATA MINIMISATION
        │
        ▼
RETENTION DECISION
        │
        ▼
ACCESS AND ENCRYPTION BOUNDARY
        │
        ▼
RECOVERY COPIES AND KEYS
        │
        ▼
END-OF-LIFE ACTION
        │
        ├── delete
        ├── transform
        ├── retain under an approved basis
        └── cryptographically erase
        │
        ▼
VERIFIABLE EVIDENCE

A KMS key is not a padlock attached to one database row.

It is an authority, recovery and blast-radius boundary with cryptography inside it.

The key hierarchy should reflect not only who may read data, but which data must live, recover and die together.

The ciphertext may remain.

The route home should not.

References