Outside the three surfaces

Which risks does no access, protection or privacy control reach: destruction, untrusted code, shared copies, people and friction?

Five risks sit outside the three control surfaces. Each is a real gap, and each is where a platform that looks complete on paper is still exposed.

1. Availability is the third security property. This mechanism focused on confidentiality and integrity because that is where the interesting mechanisms are. But destruction is a security outcome too: ransomware, a destructive insider, a deletion issued with valid credentials. Access control does not help, because the action was authorized. The only defence is a copy that the authorized principal cannot reach: immutable snapshots, versioned retention, and an account boundary between production and backup. This collides head-on with the deletion mechanics of the privacy article. The property that lets a backup survive an attacker is the same property that lets it survive an erasure request. This is a real, unresolved conflict between two requirements, and most organizations satisfy one and only claim the other. (A related point: legal hold, a duty to keep data for a lawsuit, and erasure are directly contradictory duties that land on the same table. The resolution is procedural, not technical.)

2. The pipeline runs arbitrary code with the pipeline's credentials. User-defined functions (UDFs), notebook libraries, connector plugins, dbt macros and transitive dependencies (the libraries your libraries use) all run inside the trust boundary and hold the service account's authority. This is the confused-deputy problem again, but the deputy is not a service you wrote. It is a package that someone else published. Every control here assumes that the code holding the credential is the code you meant to run, and nothing checks that. The mechanisms come from software supply-chain security: pinned dependencies, provenance attestation (signed proof of how a package was built) and sandboxed execution of user code. They are weak in data platforms in particular, because the whole point of a notebook or a UDF is to run code that nobody reviewed.

3. Data that leaves the organization has no technical waist at all. Vendor feeds, partner shares, regulatory submissions, the extract someone sends every quarter. Once data is out, the only enforcement is a contract. This is the narrowest-waist rule at its extreme: the narrowest waist is a legal document and the audit is a questionnaire. It is worth stating plainly because the risk is large and the mechanism is not technical. Your real security posture includes everyone you have shared with, at their level and not yours.

4. The usual first step into a system is a person, not a system. Phishing and social engineering defeat authentication by getting the legitimate holder to use it. No mechanism here addresses that. The whole response is to limit what a compromised legitimate session can reach, which is the blast-radius argument for short TTLs, narrow scopes and egress control, now with its real reason attached.

5. A control that costs more than its workaround selects for the workaround. Access requests that take a week produce shared credentials. A masked table that is unusable produces a CSV on a laptop. This is the twin of "controls decay toward permissive", and it may be more damaging. The first law says controls decay. This one says controls are routed around while still looking intact on the dashboard. The effective control is min(designed, tolerable), so friction is a security parameter, not just a user-experience one.

One smaller point: security posture is not a state but a rate. The question is how fast you detect and revoke, not whether you are configured correctly today.