Three control surfaces, in order of desperation
This mechanism has three main subjects. They are not three topics. They are three places you can intervene, and you use the next one only when the previous one is insufficient or cannot be trusted.
Surface 1 — Identity and access: control the channel
A request arrives. Something decides yes or no before the bytes move. This is a per-request, logical check, and it is fully reversible: revoke the grant and the door closes again. It assumes you control every path to the data, which is exactly the assumption that fails most often.
In one sentence: access control is a decision made at a chokepoint, and it is only as true as the chokepoint is narrow.
Surface 2 — Protection: control the bytes
Encryption, masking, tokenization: make the data unreadable to anyone who holds it but lacks a secret. You use this when you cannot guarantee the channel, because the storage layer, the operator, the backup tape or the cloud provider is outside your trust boundary. It does not remove the problem. It turns "protect a petabyte" into "protect a 32-byte key". That is a much better problem, but a different one. It is also reversible: hold the key, get the data back.
In one sentence: encryption does not reduce the secret; it shrinks it and moves the whole problem into key custody.
Surface 3 — Privacy: control the inference
This is the case where access control is perfect, encryption is perfect, and you still leak. The person asking is authorized, and the data itself carries identity in its structure. Aggregates (sums, counts, averages) leak. Quasi-identifiers combine. A join with an outside data set re-identifies rows you thought were anonymous. The only remedy is to destroy information: generalize it, add noise, or never collect it. And destroyed information does not come back.
In one sentence: privacy is the only control that works by deliberately reducing the information content of the data, which is why it is the only irreversible one.
How they compose
They compose in one direction only. A privacy failure cannot be patched with an access rule, because the disclosure already happened through an authorized path. An encryption failure can sometimes be contained by access control. Read the order as:
The order is also a threat model: deny the channel if you own it; obscure the bytes if you do not; destroy the signal if the requester is legitimate.
Two rules this mechanism keeps using
The narrowest-waist rule. A control binds at the narrowest point the data passes through. Anything enforced above that point is documentation. Example: a table-level permission is enforced by the query engine, but the underlying data files can be read by anyone who has storage credentials. Then the real boundary is the storage permission, and the table permission is only advice. This explains why "use views for security" is contested, why credential vending (Enforcement points) exists, and why where you place the enforcement point matters more than how clever your policy language is.
Disclosure is monotone. You can always add a restriction later. You can never subtract a disclosure. Every other area recovers from mistakes by replay, rollback or recomputation from the original inputs. That safety net does not exist here. A leaked record stays leaked. This is the only subject whose errors are outside the reach of the recovery tools the rest of a data stack is built on.
Name the adversary first
Every mechanism here works against one adversary and is worthless against the next. So a mechanism cannot be evaluated until the adversary is named. Five adversaries behave differently enough to separate:
| Adversary | What stops them |
|---|---|
| External attacker | authentication and the network perimeter |
| Malicious insider | only least privilege, egress control and detection |
| Careless insider | good defaults and limits on blast radius (how much damage one mistake can do), not policy |
| Platform operator (the cloud provider's or vendor's staff) | only client-held keys or confidential computing |
| Authorized analyst | only privacy mechanisms, never access control |
Apply the diagnostic ("a control without a named adversary is unevaluable") systematically: which of these five does this control stop, and which does it not touch? Full-disk encryption stops exactly one (someone who steals a disk). Row-level security stops two. Nothing stops all five, and any design that claims to has skipped the exercise.