Worked example · one control, end to end
Tested in every ISO 27001 and SOC 2 audit, and a common failure in teams that ship quickly. What follows is a working version in a real pipeline, how it gets tested, and the five places it tends to break. Free to read, no signup.
Nobody sets out to let one person write and release code unchecked. It happens because the company grew faster than the permissions did.
The last one is the most expensive. A policy describing a process nobody follows gives the auditor a documented standard to test against, so the exception is raised against your own wording.
The separation has to live in platform configuration rather than in a document. If the only thing preventing a self-release is that nobody would do it, there is nothing for an auditor to test.
Commit, approve, deploy to production, manage access, and modify the pipeline. These are five different things, and the grid in section C says which pairs one person may never hold. Start here: most environments have never separated deploy from commit at all.
Branch protection on the release branch, a required reviewer who cannot be the author, and administrators included in the rule rather than exempt from it. The common failure is an admin bypass that nobody remembers enabling.
Production deployment runs under an identity that developers cannot assume directly, behind an environment protection rule with its own reviewer. Human access to production is broken out from the ability to release code into it.
Whoever can edit the workflow file can remove the gate. The pipeline definition needs the same protection as the code it releases: review required, and change history retained.
Break-glass access is legitimate and auditors expect it. What they do not accept is an emergency route with no trigger condition, no logging and no review afterwards. Define who can invoke it, what it grants, how long it lasts, and who reviews every use inside a set number of days.
A control that makes shipping painful gets bypassed within a month, and then you have both an ineffective control and a documented process you are breaching. The separation should cost a reviewer a few minutes, not a release train a day.
Any single person holding two capabilities marked as a conflict breaches segregation of duties. This is the table the test is run against, so it is worth checking your own access before anybody else does.
| Commit | Approve | Deploy | Manage access | Edit pipeline | |
|---|---|---|---|---|---|
| Develop / commit | · | Conflict | Conflict | Conflict | Conflict |
| Review / approve | Conflict | · | Monitor | Conflict | Conflict |
| Deploy to production | Conflict | Monitor | · | Conflict | Conflict |
| Manage access | Conflict | Conflict | Conflict | · | Conflict |
| Edit the pipeline | Conflict | Conflict | Conflict | Conflict | · |
Conflict — never one person. Monitor — tolerable only where the approval is genuinely independent, and worth watching for self-approval.
Three moves, none of which involve reading your policy. That is why documentation on its own does not carry an audit.
An export of who can commit, who can approve, who can deploy and who can administer access, plus every production release in the audit period. Taken from the systems, not from a spreadsheet you maintain.
Pass — the export is complete and reconciles to the period. Exception — the list is manually maintained and cannot be tied back to the platform.
Every user mapped to their capabilities, and every conflicting combination flagged. A competent auditor will not rely on your own analysis here — they will redo it from the raw access data.
Pass — no individual holds a conflicting pair. Exception — a user can create and release a change without independent approval.
Not that the gate exists, but that it cannot be walked around: approval required, self-approval impossible, administrators inside the rule, deployment restricted to a separate identity. Where the separation lives in custom code rather than platform configuration, this becomes a code review.
Pass — the gate holds under test and cannot be self-approved. Exception — the gate is optional, bypassable by an admin, or self-approvable.
Where a conflict is found, it is not automatically a failure. The next question is whether an independent detective review catches it afterwards, and how quickly. That argument only works if the review is evidenced — which brings us to the next part.
Evidence gathered in good faith is often accurate and still unusable. Four questions decide whether it stands.
This is the part that quietly consumes engineering time: pulling exports out of four systems, re-taking captures that failed one of the four questions, and answering the follow-ups. On a turnkey programme that work sits with me.
Four of these five are configuration, and can be closed in an afternoon once somebody knows where to look. The fifth — break-glass — needs a process designed around it, and that takes a conversation rather than a setting.
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.