Who can see what, and who decided

Access gets discussed as though there were one failure, a leak, and one dial, tightness. There are three failures and they trade against each other.

• A leak is somebody holding data they have no business seeing. It is the only one that reliably gets reported.
• An over-block is somebody unable to do the job they were hired for. Nothing on the platform can see it.
• A standing privilege is a grant nobody currently needs, sitting there waiting for a compromised login to make it interesting.

Requests denied is not one of them, and it is the metric most often put on a slide. A high denial rate can mean the design is holding, or it can mean five teams are queueing for something they should already have. The number cannot tell you which, so it cannot be improved deliberately.

• Role - the thing permissions are attached to. People hold roles; roles hold permissions. Permissions attached straight to a person are the exception that has to be justified.
• Least privilege - each role holds what its job needs and nothing more. Easy to say, and the reason it is hard is that "its job" was never written down. Session 3.
• Masking - a column returns a transformed value rather than the real one, so the row is still usable and the value is not readable. It is what lets a job proceed honestly instead of being blocked. Session 4.
• Row filter - a rule that limits which rows a role sees at all, usually by region or ownership. Columns and rows are separate dimensions, and a design covering only columns will pass review and still leak.
• Access review - the recurring exercise that finds standing privileges and takes them back. It is the only routine that reduces that counter, and it decays the moment it becomes a spreadsheet.
• Exception role - a named role allowed to see a masked column in clear, with a written reason. A class of data with no exception role is a much stronger statement than a class with a vague one.

What it is. A role can read a value that its job has no use for. Not a breach, not an incident, just capability sitting there. At Saltbox the clearest one is a contractor in APAC able to read EU customers' revenue, which nobody ever intended and nobody ever revoked.

Who notices. An auditor, a customer complaint, or a journalist. All three arrive after the fact, which is why the count feels abstract until the day it does not.

The cheap fix and what it wrecks. Deny everything and leaks are zero by tomorrow. Over-blocks then become the largest number in your estate and, because nothing measures them, you will not see them. You will see the consequences instead: a shared spreadsheet, a shared login, a data request queue nobody can clear.

What it is. A person whose job requires a value and who cannot get it. Saltbox's support agents need name, email, phone and the support notes column for the two regions they cover. Take those away and there are exactly eight of these, one per column per region.

Who notices. The person, their manager, and the customer waiting on the ticket. Nobody in the platform team, and nobody in the access review, because a review reads grants and grants only record what was given.

The cheap fix and what it wrecks. Grant everything and over-blocks are zero by lunchtime. Leaks go straight back to where they started, along with every standing privilege you had cleared, and the policies you wrote stay defined and deployed while ceasing to constrain anybody.

What it is. A column a role can read in clear that the written design does not mark clear for that role. That is the definition an access review uses, and it deliberately does not care whether anybody has actually read the column. Capability is the exposure; use is just evidence.

Who notices. The access review, and then whoever compromises an account. A standing privilege is the difference between one stolen login being an inconvenience and being an incident.

The cheap fix and what it wrecks. A one-off spreadsheet sweep takes the number to zero on the day of the sweep. It does not wreck another counter so much as wreck itself: by the following month the exceptions are back, because the process that creates them was untouched. This is the counter that needs a routine rather than an effort.

Saltbox's opening state is the one almost every growing company has: a single shared analyst role that everybody in data holds, because it is the only role anybody trusts to work. Scored against the written design over 150 concrete access requests, that state produces 109 leaks, 0 over-blocks and 30 standing privileges.

The two single-number reports are both accurate and they recommend opposite actions. An over-blocks-only report on the most over-granted state in the ladder calls it perfect, and it is right: nobody is blocked. That is what a one-counter scoreboard buys you.

The Saltbox figures come from evaluating every combination of five jobs, ten columns and three regions, which is 150 requests. Of those, 41 legitimately need a value in clear, 3 need it masked, and 106 have no business being answered at all.

• Counts beat percentages in a room. "109 leaks" starts an argument about which ones. "27 percent non-compliant" starts an argument about the denominator, and the denominator is where a scoreboard goes to die.
• The ground truth has to be written first. Every counter here is a comparison against a design that says, per job, which columns are needed in clear and which regions the job covers. Without that table there is no leak, only a disagreement.
• Every request counts the same, which is wrong on purpose. A leaked plan name scores exactly like a leaked national ID. Weighting by sensitivity is the first improvement to make, and it reorders the middle of the ladder without rescuing either of the two popular over-corrections.

Every route on that diagram has one thing in common: none of them appear in the warehouse. The counter you are watching is measuring the one place the data is no longer going.

Read the sequence carefully, because the audit made things worse in three separate ways. The data left a system with masking for one with none. It went from a per-person grant to a folder membership nobody reviews. And the person now doing the refresh needs broader access than the support team ever had, because a weekly export has to read everything anybody might ask for.

Ask five leaders who decides access and you get five different answers, all sincere. The honest answer in most companies is: whoever is fastest to ask. A request lands in a channel, somebody with the ability to help helps, and that grant is now permanent policy created by a person who was not deciding policy.

• The platform engineer holds the ability, so they get asked. They have no way to know whether the job needs the column, so they default to yes on a busy day and no on a nervous one.
• The requester's manager knows the job, and typically cannot see what the grant actually opens up. Approving "read access to the customers table" is approving all ten columns including the national ID.
• Security or the DPO knows the sensitivity, and is usually consulted after the pattern is set, at which point their only available move is a blanket restriction.
• Nobody holds the combination, which is the actual finding. The decision needs the job, the sensitivity and the mechanism in one head or one document.

Approving is answering a request somebody else framed. Designing is deciding, ahead of any request, which jobs need which columns in which regions, so that most requests never need a human at all. A queue of approvals is what a missing design looks like from the inside.

The tell is in the wording. An approval that names a person and a table has decided nothing that can be reviewed later, because there is no statement to check the grant against next year.

The second version is longer, and it is also reusable: it is a decision about the job, so the next data scientist inherits it instead of starting a new thread. That is the moment access stops being a queue.

Standing privileges behave differently from the other two counters, and the difference is worth understanding before you are asked to sign anything.

• They accumulate without any decision. Nobody grants a standing privilege on purpose. It is what a legitimate grant becomes once the project ends, the person moves team, or the incident it was issued for is forgotten.
• They survive people. A role keeps its permissions when its membership changes, so a grant issued for one analyst in 2024 is inherited by everybody who joins that role afterwards.
• Nobody dares remove them. The reason a role list never shrinks is that no single person knows what breaks. That is a documentation problem being treated as a risk decision.
• They are what turns one stolen login into an incident. The blast radius of a compromised account is exactly the set of permissions it holds, needed or not, so this counter is the one that determines how bad a bad day is.

Which is why the counter belongs on a monthly report next to the other two, with a date attached to each grant. Any grant older than the incident that caused it is a standing privilege with a nicer name.