Worked example · one control, end to end
Permanent administrative access is the most common finding in this kind of work, and the first thing an enterprise customer asks about in a security questionnaire. What follows is a working version that does not slow your engineers down, how it gets tested, and the five places it tends to break. Free to read, no signup.
Standing privilege is not a security failure so much as an operational habit. It gets granted because somebody needed it at 2am, and then nothing happens to take it back.
The support case is the one worth being honest about. Telling an engineer they can no longer read production data does not work unless something replaces it. A control that removes capability without replacing it gets reversed within a month, and then the exception is worse than before.
The aim is not to take privilege away. It is to make privilege temporary, requested, logged and reviewed — so that having it is an event rather than a property of a person.
Day to day accounts hold no administrative rights at all. Elevation happens through a separate role or account that a person assumes when they need it, so ordinary work never runs with privilege attached to it.
Access is granted for a window, not indefinitely, and it expires on its own without anybody remembering to remove it. This is the single change that closes most of the findings: expiry does the work that periodic reviews are supposed to do and usually do not.
Every elevation carries a justification — a ticket, an incident number, a change record. The reason is what turns a log line into evidence, and it is the difference between "somebody had admin on Tuesday" and "this was authorised for this purpose".
Routine elevation can be self-service with logging. Rights that could destroy data or disable logging need a second person, and that person cannot be the requester. Set the boundary deliberately rather than treating all privilege as one tier.
If engineers read production data to answer customer questions, give them a supported path: a read-only view with the sensitive fields masked, or a tool that answers the common questions without direct access. Then the removal holds.
Who holds privileged rights, in which system, granted when and expiring when. Produced from the systems themselves, not typed into a spreadsheet — a maintained list is the first thing an auditor stops trusting.
Treating every elevated right identically is what makes these controls painful. Sorting them into tiers is what makes the control survive contact with an engineering team.
| Tier | Examples | Standing access | How it is granted |
|---|---|---|---|
| Routine elevated | Restart a service, read non-sensitive logs, re-run a job | No | Self-service, time bound, logged with a reason |
| Data access | Query production data, export records, read customer content | No | Approved request, masked where possible, short window |
| Destructive or control-affecting | Delete data, change access rights, alter logging or the pipeline | No | Second-person approval, narrow window, reviewed after use |
| Break glass | Full administrative access during a live incident | No | Defined trigger, alerts on use, reviewed within days |
| Automation | Deployment and integration accounts | Yes, scoped | Least privilege, credentials rotated, no interactive login |
Automation is the only row where standing access is normally acceptable, and it is also the row most often abused: a deployment account with unrestricted rights is standing privilege that any engineer able to edit the pipeline can borrow. Scope it as tightly as a human account, and make sure nobody can log into it directly.
Four moves. The first one is where most companies come apart, and it happens before anybody looks at the control itself.
Every system in scope, every account with elevated rights, human and non-human, exported from the systems themselves. Non-human accounts are part of the population and are the ones companies forget to include.
Pass — the list is generated, complete and reconciles across systems. Exception — the list is maintained by hand, or a system in scope cannot produce one.
For each account, does the right exist permanently, or is it assumed for a window? Where standing rights remain, is the reason documented and is the account still needed by somebody still employed?
Pass — elevation is time bound and expires without intervention. Exception — permanent administrative rights held by individuals, including founders.
Take individual grants from the period and trace each one: who requested it, on what stated basis, who approved it, when it expired, and what was done with it. This is where a control that exists on paper separates from one that operates.
Pass — each sampled grant has a reason, an approver where required, and an expiry that took effect. Exception — grants with no recorded reason, or that outlived their stated window.
Leavers from the period checked against every privileged system, not only the identity provider. Movers matter as much: people who changed role and accumulated the rights of both.
Pass — privileged rights removed promptly and provably on departure or change of role. Exception — a leaver retaining access in any system in scope.
A leaver with live privileged access is the finding least likely to be argued down. It is binary, it is easy to evidence, and it is the one an enterprise customer will ask about directly rather than through the auditor.
Evidence gathered in good faith is often accurate and still unusable. Four questions decide whether it stands.
Privileged access is harder to evidence than most controls because the population lives in five places and the history is easy to lose. Log retention is worth checking early: if your elevation records only go back thirty days, a twelve month audit period cannot be evidenced at all, and that is a problem no amount of remediation fixes retrospectively.
Three of these five are configuration and process changes that can be made in days. The founder exception is the one that needs a decision rather than a setting, and it is usually the person commissioning the work who has to make it.
The depth above is the depth a whole programme gets. On a turnkey engagement I design the controls around how your company already works, put them in place, gather the evidence, and handle the auditor.
Tell me the situation in a couple of lines: the environment, the deadline, and who is asking for the certificate. Thirty minutes, no charge. If it is not something I should be doing, I will say so.