Where the leader track lands
Six sessions, and the through-line has been that access control is a design problem measured with three numbers rather than a tightening exercise measured with one. Tonight the design becomes an organisation: four separated jobs, an escalation path that exists before it is needed, a 90-day plan ordered by evidence rather than by what looks urgent, and a monthly report that a board can read. The worked example throughout is saltbox.customers at Saltbox, a consumer lending startup, with five jobs, ten columns and three regions.
★ What you walk out with tonight. The four jobs written against real names for one domain, with the one pairing that has to stay apart. An escalation path for genuinely urgent requests, drafted before the next incident rather than during it. A 90-day plan whose order is set by the measured effect of each step. And a three-number monthly report, one of which can only be collected by asking people.
LiveOne person holding every job is the default, and it is the failure3 min▶
In most teams under a hundred people, the same engineer decides what a column is for, grants it, builds the policy that constrains it and signs the access review that checks it. Nobody chose that. It accreted, because each of those four things arrived as a small favour on top of an existing job.
Two things break at once. The first is throughput: that person becomes the queue, and a queue is what produces the shared login and the standing grant. The second is evidence: a review carried out by the person who made the grants cannot find a wrong grant, because finding one means reporting on themselves. Neither failure looks like a security failure from the inside. One looks like a busy colleague and the other looks like a clean report.
Saltbox's platform lead approved access requests in a chat thread and also produced the quarterly review, exported from the same chat thread. Every quarter came back clean. The first external audit found nineteen grants with no request behind them at all, because a request that was never written down cannot be missing from a review of what was written down.
Self-studyWhat an operating model has to contain to be one4 min▶
- Named people, not named teams. "Platform owns approvals" is not an operating model; it is an intention. A model names a person and a deputy for each job in each domain, and it is out of date the day one of them leaves, which is the point.
- A decision rule per job. What does the approver check against? If the answer is judgement, the model will produce different answers on different days and nobody can review it.
- A path for the exception. Every access model is judged on the urgent Friday request, because that is the one that produces the permanent grant. Write it before it happens.
- A cadence. Monthly numbers, quarterly review, annual recertification of the roles themselves. A control with no date attached is an aspiration.
- An exception register. A short list of grants that break the design on purpose, each with an owner, a reason and an end date. What is not on it is not an exception, it is a finding.
Separate the four jobs, or one person becomes both the bottleneck and the audit finding
12 min liveFour distinct things happen to an access request, and they need different skills, different information and, for one pair, different people. Naming them separately is most of the work, because once they are named it becomes obvious how many of them one person is currently holding.
LiveThe four jobs, and what each one is actually deciding5 min▶
Each job answers a different question, and each needs information the others do not have. That is the real argument for splitting them: it is not ceremony, it is that the person who knows why a column exists is almost never the person who knows what a row policy costs at query time.
- The data owner decides what a column is for. Usually a business leader rather than an engineer. They answer "which jobs have a legitimate reason to see
national_id, and in what form". At Saltbox the answer for that column is nobody, in any form, and an owner is the only person who can say that with authority. - The approver grants against the design. They answer one question: does this request match what the owner already decided? If it does, approve. If it does not, it is not an approval decision at all, it is a request to change the design, and it goes back to the owner. An approver exercising judgement is an approver with no design behind them.
- The platform engineer implements the policy. They answer "what is the smallest change that produces this outcome, and what does it break". They also own the honest answer that some designs are not implementable as written and need a view rather than a grant.
- The reviewer checks the result. Not the intent, the result. They compare what is actually granted today against the written design, and they report the gap. Their output is a number and a list, not a reassurance.
The smallest viable split. Four jobs does not mean four full-time people. It means four names, where the approver and the reviewer are different humans and the data owner is not on the platform team. In a team of eight that is achievable. In a team of three, the reviewer comes from outside the team, and that is the whole requirement.
LiveWhy the approver and the reviewer cannot be one person3 min▶
A review is a comparison between two things: what was granted and what should have been granted. When the same person produced both sides, the comparison is guaranteed to succeed, and a check that cannot fail is not a check.
This is not an accusation of dishonesty and it is worth saying that out loud when you introduce the split, because people hear it as one. The mechanism is ordinary and human. You do not find an error you have already looked at and considered correct, and you especially do not find the grant you made at eleven at night during an incident, because you remember the reason and the reason was good.
A Saltbox analytics lead approved a temporary grant during a payments outage, then wrote it into the review as "approved, incident 4412, temporary". Three quarters later the same line appeared in the same review, still marked temporary, still approved by the person writing the review. A finance reviewer with no memory of the incident spotted it in ten minutes, because to them the word temporary next to a nine-month-old date is the only interesting thing on the page.
LiveThe escalation path, and why writing it early is the whole trick4 min▶
Some requests are genuinely urgent. A payments incident at seven on a Friday is not somebody being impatient, and a model that has no answer for it will get the answer that is always available: somebody grants the top role, because that definitely works and nobody has to think.
A written escalation path replaces that with something almost as fast and far narrower. Four elements are enough, and all four have to be decided in advance, because the point is that nobody is designing anything at seven on a Friday.
- Who can invoke it. A named on-call approver and a named deputy. Not a team alias, because an alias at seven on a Friday is nobody.
- What it grants. A pre-built break-glass role, scoped in advance to the tables an incident actually touches. Building it during the incident is how it ends up being the top role.
- How it ends. An expiry, in hours, set at the moment of the grant and not dependent on anybody remembering. A grant that has to be revoked by a human is a standing privilege with a good intention attached.
- Where it is recorded. One line, automatically, into the same place the monthly numbers come from. An escalation nobody counted is indistinguishable from a grant nobody made.
The second answer is faster to say and produces a grant that outlives everybody in the conversation. The first takes ten seconds longer and is only available if somebody wrote the path down on a quiet afternoon.
LiveThe three numbers to report monthly4 min▶
Access is usually reported as one number, and the number is usually leaks, which is exactly why over-blocks are invisible in almost every access review ever written. Three numbers go in the monthly report, together, on the same page, because each has a cheap fix that ruins another.
| Number | What it counts | Where it comes from |
|---|---|---|
| Leaks found | Cases where somebody could read data the design does not grant them | Generated: grants and policies compared against the written design |
| Over-blocks reported | Cases where somebody cannot do the job they were hired for | Asked: a standing question to support, operations and analytics |
| Standing privileges outstanding | Grants nobody currently needs, still in place | Generated: columns a role can read in clear that the design does not mark clear |
The middle row is the one that gets dropped, and it is the one that cannot be recovered later. Over-blocks cannot be queried. There is no table of things people wanted and could not get, because a blocked person does not file a ticket, they find a colleague with wider access. The only detector is a question asked on a schedule: what can you not see, what do you do instead, and where does that copy live. Three questions, three teams, once a month.
Report the three side by side with last month's values and nothing else. A leaks number falling while over-blocks climb is not progress, and it is only visible when both are on the same page. The moment they live in different reports owned by different people, the trade stops being visible and the organisation optimises the one that has a graph.
Self-studyMaking the split real when nobody has spare capacity4 min▶
The objection to separating the four jobs is always the same and it is usually honest: there is no headcount. Four moves make the split affordable without any.
- Borrow the reviewer. The reviewer does not need warehouse skills, only the design and the current grants in readable form. A finance analyst, a risk colleague or a peer lead from another domain can do it in two hours a quarter, and their unfamiliarity is a feature.
- Make the approver's job smaller, not bigger. An approver working against a written design is doing a matching exercise, not an investigation. Most requests become a thirty-second yes. The ones that are not are supposed to be slow.
- Automate the reviewer's inputs. If producing the current-state grants takes a day, the review happens annually. If it is a generated file, the review happens monthly and the reviewer spends their two hours on judgement.
- Rotate the owner conversation, not the ownership. Data owners do not need a weekly meeting. They need to be asked once, in writing, per column class, and then again only when something changes.
One structural warning: do not solve the capacity problem by making the approver a rota that includes the platform engineer. That reconstructs the failure with extra steps and a false record of independence, which is worse than the honest single-person version because now the report looks credible.
A 90-day tightening plan that does not stall the business
6 min liveNinety days is long enough to move all three numbers and short enough that the plan survives the quarter it was written in. The content below is ordinary. The order is not, because the step that moves the numbers most is the one that looks least like security work and therefore gets scheduled last almost everywhere.
| Phase | What lands | What it is expected to move |
|---|---|---|
| Days 1-30 Write it down |
A written access design for the top five tables. The top role reduced to two named humans. A grants dump in version control, diffable rather than screenshotted. A baseline of the three numbers. | Nothing yet, deliberately. This phase produces the measuring stick, and a baseline taken after the first fix is not a baseline. |
| Days 31-60 Split and enforce |
The shared role split along the five real jobs. A row policy on the region or tenant column. Masking on the highly sensitive class. An expiry on every grant made during an incident. | The heavy phase. The role split alone moves leaks from 70 to 22 and standing privileges from 17 to 1; the row policy takes the remaining leaks down to 3. |
| Days 61-90 Prove and revoke |
Pseudonymised views for modelling work. The access review as a generated diff rather than a spreadsheet. The exception register, each entry with an owner and an end date. The first deliberate revocations. | The last leak closes: pseudonymising the modelling view reaches 0 leaks, 0 over-blocks and 0 standing privileges across the full request set. |
LiveSequence the role split before the policies4 min▶
The instinct is to start with masking, because masking is legible. You can show a screenshot of an obscured national ID to a nervous executive and the conversation calms down. It is also the step with the worst return, and the bench that scores the finished policy set against 150 requests says so with numbers.
- Masking alone plateaus. Masking
national_idfor everybody takes leaks from 109 to 94. Adding masking on email and phone with a support exception takes them to 70. Two policies, real work, and two thirds of the leaks are still there. - The role split is the step. Splitting the shared role five ways moves leaks from 70 to 22 and standing privileges from 17 to 1, in one move. Nothing else on the ladder touches standing privileges at all.
- Policies then finish the job cleanly. The row policy on region takes 22 leaks to 3, and pseudonymising the modelling view takes the last 3 to zero. Applied to a shared role first, the same policies would have had to be written around a role that does five jobs at once.
The reason is structural rather than tool-specific. A policy expresses a rule about who sees what, and it can only be as precise as the identity it is written against. When five jobs share one role, every policy has to be written for the union of what those five jobs need, which is by definition the widest of them. Splitting the role is what makes precision expressible at all, and it is scheduled last almost everywhere because it reads as administration.
How to sell the order upward. "We are reorganising roles" is a hard sentence in a security conversation. "The measured step that removes two thirds of the remaining exposure and almost all of the dormant access is a role change, and masking without it plateaus at 70" is a different sentence, and it is the same work.
LiveWhat not to promise3 min▶
The pressure at the end of a tightening programme is to declare something absolute, because absolutes are easy to hear and easy to repeat in a board pack. Every absolute available here is a hostage.
- Never promise zero access incidents. You do not control the compromised laptop, the misconfigured integration or the leaver whose contractor account belonged to a vendor. Promising zero converts the next ordinary event into a broken commitment and, worse, gives the team a reason to not report the small ones.
- Do not promise a date for full coverage. Five tables in 90 days is a real promise. Every table by the end of the year is a promise about work you have not scoped, made to people who will remember it.
- Do not promise that nobody will be inconvenienced. Tightening produces over-blocks. Saying so in advance, and committing to counting and fixing them, is what stops the first one becoming an argument about whether the programme should continue.
What to promise instead is three things, all of which you control: a written design that says who should see what, a measurement of the gap between that design and reality, and a cadence on which the gap is reported and closed. That is a commitment you can keep during a bad quarter, which is the only test that matters.
LiveThe two failure modes, named in advance4 min▶
Two over-corrections show up in almost every programme, one from the audit side and one from the delivery side. Naming both at the start, with their measured cost, is what stops each from arriving later as somebody's clever idea.
Over-correction one: strip every PII column. Applied on top of the full design, this holds leaks at 0 and produces 8 over-blocks, all of them the support agent, across name, email, phone and support_notes in each of the two regions they cover. The warehouse then reports a perfect number while the support team answers tickets from a spreadsheet somebody refreshes weekly.
Over-correction two: grant the top role. Applied on top of the full design, this restores all 109 leaks and all 30 standing privileges, with every policy still defined and still deployed. Nothing was deleted and nothing was misconfigured. A role that sits above the policy layer is a role the policy layer does not reach, which makes this the most expensive single statement available to anybody in the organisation.
The second one is worth rehearsing with the team, because it is the one that arrives dressed as helpfulness during an incident. Everyone in the room agrees it was reasonable at the time. The measurement does not care, and neither will the audit.
Self-studyThe exception register, and keeping it short4 min▶
Some grants break the design on purpose and always will. A regulator needs a direct extract. A migration needs a service account with more reach than any human. Pretending otherwise produces a design nobody can follow, which is worse than a design with visible holes in it.
| Field | Why it is on the register |
|---|---|
| What is granted | Named columns and rows, not "elevated access". A vague entry cannot be reviewed or revoked with confidence |
| Why | One sentence a non-specialist can evaluate in a year, when nobody remembers the context |
| Owner | A person, not a team. The owner is who gets asked at review time, and who loses the exception if they cannot justify it |
| End date | Every entry has one. An exception with no end date is the design, and it should be argued for as a design change instead |
| Compensating control | What is done instead: extra logging, a smaller window, a second approver. An exception with nothing in this column is just a gap |
Watch the length. A register of five entries is a control. A register of forty is a second access model, running in parallel, with no reviewer. When it grows past about ten, the honest read is that the design is wrong rather than that the organisation is unusually exceptional, and the fix is to change the design.
Draft the operating model for one domain
★ 20 min · everyone writesOne domain, not the whole estate. Pick the one with the most sensitive table in it, because that is where the model gets tested first. Everything below fits on one page and the point is that it exists, not that it is elegant.
Name the four jobs against real people. Data owner, approver, platform engineer, reviewer, with a deputy for each. Write actual names. If the same name appears in the approver and reviewer rows, you have found the finding, and the fix is usually to borrow a reviewer from a neighbouring team rather than to hire one.
Write the approver's decision rule in one sentence. It should be a matching rule against the written design, not a judgement. If you cannot write it as a matching rule, the design is not finished, and that is the more useful discovery.
Write the urgent-request escalation path. Who can invoke it, what role it grants, how many hours until it expires, and where the line gets recorded. Four bullets. Then read it aloud and check that every element is decided in advance, because anything left open will be decided badly at seven on a Friday.
Draft the 90-day plan with real dates. Three phases, four or five items each, in the order on this page: write it down, then split and enforce, then prove and revoke. Put a date on each phase boundary and a named owner on each item. Resist the pull to move masking earlier because it demonstrates well.
Write the monthly report format. Three numbers, this month and last month, on one page. Add one line naming where each number came from, so that the over-block number is visibly the one collected by asking. A report that does not say how a number was produced is a report nobody can challenge, which sounds good and is not.
Decide the three over-block questions and who gets asked. What can you not see, what do you do instead, and where does that copy live. Name the two or three teams and the person who asks them. Put it on the same schedule as the report, because an unscheduled question is a question that happens once.
Write the sentence you will say when somebody asks for the top role on a Friday. Out loud, to the person next to you. It should name what they get instead, when it expires and where it appears. If it takes more than fifteen seconds to say, it will lose to the alternative, and the alternative is 109 leaks and 30 standing privileges with every policy still deployed.
Put the page where the work happens. An operating model in a slide deck is a description of an organisation. In the repository next to the access design and the policy definitions, it is the thing a new joiner reads in their first week and a reviewer opens during a review. Same words, entirely different half-life.
Before the first monthly report
45 min- Circulate the four-job page to the people named on it. The objection you get back is the real constraint, and it is almost always the reviewer row.
- Take the baseline of the three numbers before anything is changed. A baseline captured after the first fix quietly deletes the evidence that the programme worked.
- Ask the three over-block questions of one support or operations team this week. Write the answers down verbatim, including where the copies live, because that sentence is the one that moves an executive.
- Count the humans currently holding the top role, and the date each one got it. Any grant older than the incident that caused it is a standing privilege with a nicer name.
- Book the review cadence in the calendar for the next four quarters, with the reviewer's name on the invitation. A cadence that depends on somebody remembering is not a cadence.
- Start the exception register with the exceptions you already have. There are some. Finding them now is cheaper than a reviewer finding them in month four.
Three questions
Why must the approver and the reviewer be different people?
The mechanism is ordinary rather than dishonest: you do not find an error you already looked at and considered correct, and you especially do not find the grant you made during an incident when you still remember the good reason for it.
Of the three monthly numbers, which one cannot be produced by querying the platform, and why?
Leaks and standing privileges are both generated by comparing grants and policies against the written design. Over-blocks exist only in the heads of the people who have them, which is why they are missing from almost every access review.
Why does the 90-day plan schedule the role split before the masking and row policies?
A policy can only be as precise as the identity it is written against. While five jobs share one role, every policy has to be written for the widest of them, and nothing else on the ladder touches standing privileges at all.