Segregation of Duties in Azure DevOps: Proving Who Approved What
Segregation of duties means the person who makes a change isn’t the person who approves it. If your team uses pull requests, you’re already complying the problem is that the evidence is scattered across your ticketing system, git history and pull requests, so proving it for a sampled change takes hours of manual assembly.
It’s a core control in ISO 27001, SOC 2 and ISAE 3402, and in my experience it produces more audit findings in integration work than any other single requirement.
What the auditor is actually testing
They pick a handful of changes usually at random, often from months ago and trace each one:
- Was it requested? A ticket, a change request, a work item.
- Was it authorised before work started?
- Was it tested?
- Was it approved before production, by someone other than the author?
- Did it actually reach production through that approved path?
This is the walkthrough. It’s typically a scheduled session where the audit team sits with your people and follows each sampled change through the systems. And it is slow, because the evidence lives in three different places.
Why it’s painful even when you’re compliant
Here’s the frustrating part: most teams are doing this correctly. Changes go through pull requests. Reviewers approve them. Tickets get raised.
But when the auditor asks about a specific change from March, someone has to open the ticketing system to find the request, open Azure DevOps to find the pull request, cross-reference the commit, and confirm the approver wasn’t the author. Multiply by a sample of ten changes and you’ve lost a day for a control you were already passing.
The failure isn’t the control. It’s the traceability between systems.
Closing the chain
The chain of custody an auditor wants looks like this:
request → authorisation → change → review/approval → deployment
Each link already exists in a tool you use. The ticket ID lives in your ITSM, TopDesk, Jira, Azure Boards, ServiceNow. The author and commit live in git. The approver and reviewed change live in the pull request. The deployment lives in your pipeline history.
What’s missing is the thread connecting them.
That thread is usually already present, and overlooked: most teams reference the ticket ID in the commit message or pull request title. If something reads that reference and turns it into a link, the whole chain becomes traversable from one place.
What this looks like in practice
This is exactly what TrueStateRegistry now does. Every integration’s page carries its change history, and each row shows:
Date · Author · Approved by · PR · Ticket · Change · Source
The approver’s name and pull request number come from Azure DevOps automatically. The ticket reference is parsed from the commit message or pull request and rendered as a link straight into your own ITSM, TopDesk, Jira, Azure Boards, whatever your team uses. Configure the URL pattern once; it works with any tool.
So when the auditor picks a change from March, you open that integration’s page and the whole chain is there: who asked, who built it, who approved it, and a link to the original ticket.
An honest boundary: this gives you the traceable chain and takes you straight to the ticket. It doesn’t replace your ITSM, and it doesn’t prove the ticket contained a proper business authorisation the auditor still opens it and reads it. What you stop doing is hunting.
Making it a by-product, not a project
The principle underneath all of this: audit evidence should be generated by how your team already works, not assembled afterwards by the people being audited. Evidence produced as a by-product is more credible precisely because nobody curated it.
Pull requests already record approvals. Commits already record authors. Tickets already record requests. Wire them together and the segregation-of-duties evidence produces itself, continuously and stays available for changes from eight months ago, not just this sprint.
For the broader set of controls this sits within, see IT general controls for Azure integration. For the full list of what auditors request, see what auditors actually ask for.
Does your team reference ticket IDs in commits or PRs today? That one habit turns out to be worth a lot at audit time. Book a demo if you’d like to see the chain assembled.