Scenarios

One table, with a row filter on a partition key (region), so pruning still works: a 40 TB scan falls to about 2 TB.

Remove direct storage credentials and have the catalog vend 15-minute credentials scoped to the query. Do not rely on a view alone.

An authorized analyst who wants other regions' data, so also consider inference by subtraction, and exports.

Availability now depends on the credential vendor, and the optimizer loses some freedom in planning.

The token was a long-lived bearer secret, not bound to any audience.

Workload identity attested by the scheduler, 15-minute tokens restricted to their intended audience, one principal per pipeline, and the requesting person recorded in the job's metadata.

A token can still be replayed within its lifetime. The number of live tokens is issue rate × lifetime, so short lifetimes put the token issuer on the hot path.

9 regions × 6 departments × 5 data classes × 2 purposes is 540 combinations: a sign of role explosion.

Keep about 25 coarse roles, and move fine-grained access to attributes, with policy written as code.

"Who can read X?" becomes a query that has to evaluate the policy.

Grants that expire, and quarterly re-attestation, because controls drift towards permissive.

Encryption destroys statistics and pruning on that column: reading 2 TB instead of 40 GB, 50 times more.

Envelope encryption with a data key per file, and a key-service policy controlling who may unwrap. Avoid filtering on the encrypted column: join on a surrogate key instead.

Deterministic or order-preserving encryption, which leak value frequencies or ordering.

For every row of the threat table: whether a platform operator or a stolen backup is what this protects against.

A data key per patient, and crypto-shredding: deleting one key turns every copy of that patient's data into noise, in constant time.

• 2.1 million keys to manage.
• Lost compression across blocks, since each patient's data is encrypted separately.
• The key store must be extremely durable: losing it destroys data, yet backing up keys makes shredding unprovable.
• Uncertain legal standing: treat it as strong pseudonymization, and confirm with the privacy officer.

Fails: the space of phone numbers is small enough to enumerate.

A token from a vault cannot be reversed without the vault, and lookups can be rate-limited, but it is still a stable pseudonym, and so personal data.

Gives a safe copy for non-production use, but the masking job must keep up with schema changes.

Tokenization or static masking; if you use tokens, document the demo data as personal data.

It does not compose across releases (combining two extracts can re-identify people), groups are often homogeneous in diagnosis, and it collapses in high dimensions.

Serve them through a query interface with differential privacy and an ε ledger per dataset per quarter: for example 1.0 in total at 0.1 per query gives 10 queries, then deny. Large counts cost almost nothing in accuracy.

Noise on counts near 5 is about 40%, so run those in a supervised environment on real data, under a data-use agreement, releasing only reviewed outputs.

Clamp sums, and protect at the level of users, not events. Analysts lose small slices. There is no principled way to set ε, and correlated records, such as families, weaken the guarantee.

Build the list from the lineage graph: raw and derived tables, aggregates, caches, replicas, snapshots, backups (deleted when restored), exported files (found only by asking, since lineage does not see them), reverse-ETL targets, logs and models.

With delete vectors or file rewrites plus compaction, or by crypto-shredding where keys are per person.

Aggregates published before and after the deletion leak the difference; models need retraining, since removing one person's influence from a trained model is unsolved; backups rely on a procedure. Coverage is only as good as lineage coverage.

Whether that data should have been collected at all.

Multi-party computation or private set intersection keeps each side's inputs private, but the output can identify people: an intersection of size one, or a partner probing with a one-person list.

Differential privacy on the output, minimum aggregation thresholds, limits on the shape of queries, and rate limits on similar queries.

Multi-party computation costs orders of magnitude more compute and many rounds of messages, so offer a fixed function. Noise hurts exactly the small, targeted counts the partner wants.

Multi-party computation plus differential privacy, with a contract as a backstop.

Access control cannot help: the read was authorized.

Derive accounts from HR records, with expiry (for example 90 days without re-attestation); require two-person approval for exports above a size, say 10,000 rows; block removable media; put a perimeter around the data plane; and detect unusual export volumes.

Write the audit log to a store the team cannot edit, hash-chained, and set a time-to-detect target, say under 24 hours, tested monthly.

Friction on exports pushes people towards workarounds, so measure it: friction displaces risk rather than removing it.

The result cache was keyed on the query text alone.

Include the user's roles and the policy version in the cache key. Treat everything shared between tenants as a possible channel: timing, error messages that reveal whether something exists, shared statistics. Add a test that deliberately attempts the forbidden read.

Weigh the ladder of isolation (shared process, separate cluster, separate account) by cost against utilization, and state the decision cache's lifetime, say 5 minutes, as the revocation SLA.

"We are encrypted and use role-based access."

External attacker, malicious insider, careless insider, platform operator, authorized analyst: which controls stop each and which do not, the time to detect, and the position you chose.

Backups against erasure and legal holds, third-party code in pipelines, copies held by partners, models that cannot forget, and phishing. Give friction an owner.

Security is a rate, how fast you detect and revoke, not a state.

• At the edge only: simple, one certificate, but plaintext inside, so the internal network is the trust boundary, a compliance risk.
• End to end with mutual TLS: encrypted everywhere, with a cryptographic identity for each service. The cost is issuing, rotating and revoking certificates for 80 workloads, and CPU at every service.
• Re-encrypt at the load balancer: routing plus encryption, at the cost of a decrypt-and-encrypt cycle at that hop and no zero-copy there.

End-to-end mutual TLS with short-lived certificates issued automatically (SPIFFE/SPIRE or a service mesh), long-lived pooled connections so handshakes are rare, and an alert on time to certificate expiry, since expiry, not compromise, is the likely outage. If brokers serve large stored volumes, evaluate kernel TLS or offload to the network card.