From storage to deletion,
manage where data goes.

Separate business records from personal data.

For retail, keep proxy IDs, orders, products, and delivery status in business systems. Store names, addresses, and phone numbers in the vault. Authorized delivery workflows retrieve only what they need.

Order system: order ID / proxy ID / products / delivery status
Vault: encrypted name, address, and phone mapped to a proxy ID
Delivery: retrieve required fields only during the permitted period

Separate storage reduces direct address exposure if the order database is stolen. Order histories and proxy IDs can still identify people when combined with other information. Proxy IDs do not guarantee anonymity.

At collection

Define purpose and retention. Do not collect unnecessary fields or record request bodies in errors and access logs.

During storage

Separate ciphertext from decryption permissions. Include replicas, caches, and analytics copies in data management.

At use

Authorize fields and purpose. Return only necessary data and track new copies created by transfers to partners.

Search indexes, partner deletion notices and irreversible key erasure in this section are integration design examples. The current address API does not offer search, automatic partner deletion notices or immediate physical erasure of backups. See the integration guide for actual APIs and scope. Getting started

How can encrypted data be searched?

Random nonces produce different ciphertext for the same email address, preventing ordinary exact-match searches. Prefer proxy IDs or order IDs. If matching personal data is necessary, design a separate search index.

Exact-match example: keyed HMAC.

Normalize email addresses using defined rules and compute an HMAC with tenant- and field-specific search keys. Repeat for lookups, then verify source data after authorization. The index value is for matching, not decryptable ciphertext.

Plain hashes allow guessing candidate emails or phone numbers. HMAC also permits guessing if its key is stolen. Repeated values and frequency remain visible. Limit bulk queries to search APIs.

Substring, prefix, and range searches can expose additional information and increase processing costs. Evaluate functionality, leakage, and performance together. Search key rotation also requires rebuilding indexes.

Search indexes, partner deletion notices and irreversible key erasure in this section are integration design examples. The current address API does not offer search, automatic partner deletion notices or immediate physical erasure of backups. See the integration guide for actual APIs and scope. Getting started

What does deletion actually mean?

Removing data from a screen is not enough. Block retrieval, then address source records, indexes, caches, replicas, and partners. Record backup retention and restoration behavior.

1. Stop use: reject new retrieval and revoke tokens and grants.
2. Delete active data: remove source records, indexes, and replicas; invalidate caches.
3. Notify partners: request deletion and track completed and outstanding actions.
4. Handle backups: document what remains until expiry and retain deletion records to prevent reuse after restoration.

Making data unreadable by destroying keys.

Cryptographic erasure makes the required keys irrecoverable. This requires dedicated keys and removal of backups, wrapped keys, caches, and recoverable service copies. Destroying a shared key also affects other users.

Reversible key disabling is not irreversible erasure. It does not remove plaintext already retrieved or copies encrypted with other keys. Track access blocking, active-data deletion, and backup expiry separately.

Recover safely without bringing deleted data back.

Restoring yesterday's backup can bring back addresses deleted today. Restore in isolation, reapply deletion records and current revocations, then validate before reopening access. Deletion records cannot exist only in that same old backup.

RPO: acceptable data-loss window

A 15-minute target means up to 15 minutes of recent updates may be lost. Confirm actual replication, backups, and test results.

RTO: time to restore service

A two-hour target includes keys, permissions, deletion replay, and validation, not just database restoration. These numbers are examples, not service guarantees.

Recovery checks

Verify that valid data decrypts, deleted data cannot be retrieved, old tokens are rejected, and key failures stop processing without exposing information.

Audit evidence

Record actor, target reference, time, outcome, and key version. Avoid copying personal data or raw tokens into logs.

Evidence for evaluating the design.

Review data-location maps, decryption permissions, search leakage, deletion status, and recovery test results to assess protection across storage, use, and disposal.