You built WHAT?!
Let me give you a perspective, and something you can do tomorrow morning to improve your pipeline.
Every change that hits production should be done for a valid business reason. That is the control point-of-focus.
On the surface it sounds uncontroversial. Of course every change has a reason — the team is professional, the product owner is engaged, the work is tracked. The delivery team would tell you they have this covered.
Put the controls hat on for a moment and the same statement starts to ask sharper questions.
The delivery team’s view
A well-run engineering team has a sprint board. Tickets are written by the product owner, refined in backlog grooming, estimated by the developers, agreed in sprint planning, built over two weeks, shipped at the end. Every change ties back to a ticket. Every ticket has a sponsor. The team has stand-ups, sprint reviews, retrospectives. They know what they are building and they know why.
This is modern software delivery. It is what good teams do.
The auditor’s view
The auditor is not auditing the sprint process. The auditor is auditing whether, for any given change in production, the team can produce evidence that:
- The change traces back to a business reason that pre-dated the work.
- That reason was authored by someone authorized to author it.
- The reason has not been edited after the fact to retroactively match the work that was actually done.
If you can show those three things, the auditor goes home happy. If you cannot, the auditor starts asking why — and that conversation tends to go badly for the engineering team.
Here is a real exchange I have been part of, lightly paraphrased:
Delivery lead: We write acceptance criteria on tickets in a specified format.
Auditor: That’s excellent. Is every code change attributed to a ticket?
Delivery lead: Yes — we create tickets and pull requests for every change we make. We’re extremely diligent engineers and we’re proud of our discipline.
Auditor: Excellent. But every Jira ticket I checked today doesn’t have an acceptance criteria.
Delivery lead: Ah — we only write them for feature requests.
Auditor: 5% of your tickets have an acceptance criteria.
Delivery lead: Well, yes — most things are small changes that don’t warrant it. It’s an agile environment.
Auditor: OK, so how do I know which ticket is associated with each change?
Delivery lead: Well, erm — those tickets would have been closed about the time the release was done.
Control gaps surface quickly, and they compound. The delivery team did not know they had any of them. They often come away from the exchange angry — feeling the auditor does not understand how good a job they’re doing, and is not focused on what’s actually important.
What each side is expecting
Same focus, two languages.
| The delivery team is expecting… | The auditor is expecting… |
|---|---|
| Sprint planning agreed to do the work | A documented authority for who arbitrates work, with the moment of agreement recorded immutably |
| Tickets are linked to the work | A traceable, machine-checkable link from commit to ticket (direct, or indirect via a release) |
| The change shipped when it was done | “Done” was defined in measurable terms, and the result was recorded |
| The product owner is happy | The success criteria were validated and the validation was recorded |
The delivery team’s expectations are about running the process. The auditor’s expectations are about evidence that the process was run. Same work. Different posture.
What the controls hat opens up
It sounds easy. Put your controls hat on for a minute and it isn’t.
Under what authority was this work agreed? This is not a question about who wrote the ticket. Engineers regularly write tickets for refactors and infrastructure work, business owners write feature tickets, and that’s fine. The right question is where final arbitration on “yes, do this work” happened, and whether it was recorded. The arbiter might be the product owner. It might be a sprint-planning session with named participants. It might be a documented team policy that delegates routine technical work below a threshold. The auditor does not insist on a particular role — they insist on a documented authority and a recorded moment of decision.
Teams that get hung up on roles (“who is allowed to write a requirement?”) make life unnecessarily hard. Capture every change as a ticket — business writes business ones, engineering writes technical ones — and document where final arbitration sits.
Is the history immutable? Or can someone edit the ticket after the work is done to make the requirement match the build, rather than the other way around? “We delivered what we said we would deliver” does not hold up if “what we said we would deliver” has been rewritten three times. And it does not hold up at all if the tickets were closed and discarded once the release went out.
Does this change need additional sign-off? Some changes cross a risk threshold and need escalation beyond the team. The auditor will want to see the policy that defines the threshold — and evidence that it was applied to this change.
How often does the team actually deliver the success criteria they promised? The team says “this change is done when users can complete checkout in three clicks.” Was it? Did anyone check? Did anyone record the result?
None of these are exotic questions. All of them are real. Each one is a place where a control gap can hide.
What an auditor actually wants to see
Three specific evidence asks:
- A documented authority for who arbitrates work — sprint planning, product-owner sign-off for feature work, a team policy for routine technical work — and a recorded moment of agreement for each arbitration. One page is enough.
- A traceable link from every change in source control back to the ticket that authorized it. The link can be direct (a Jira ID in the commit message) or indirect (a PR that closes the ticket, then a release that tags the PR). A CI check enforcing the link is enough. The link must survive even if the ticket is later edited.
- An immutable history of the requirement — what it said when work started, what it said when work ended, and a record of every change in between. Most issue trackers (Jira, Linear, GitHub Issues) already produce this. The auditor just needs you to point at it.
That is the whole list. Nothing custom. Nothing expensive. Three evidence trails, almost all of which most teams already produce as a side-effect of doing the work. Or could produce, if you configure the tools you already use!
What you can do tomorrow
If your team is not doing this, three steps:
- Write a one-page policy: where work gets arbitrated (sprint planning? product-owner sign-off? a documented delegation for routine technical work?), and how each arbitration moment is recorded. Put it in your team handbook. Get it endorsed by your product owner and your engineering manager.
- Use protected branches that only accept PRs. Have each PR close its associated ticket. Tag releases as the set of PRs that went out in them. Most engineering teams already do this for their own sanity — and the same pattern is precisely the traceability an auditor wants. Additionally have a CI check that enforces the ticket link in the commit or PR if one is not there already.
- Open the audit log on your issue tracker/repository management software and check it. If it shows the history of changes, you have an immutable requirements log already — you just have to know where it lives. If it does not, find out what setting needs to change.
Half a day’s work. None of it requires a new tool.
The reframe
The auditor isn’t asking you to slow down. They’re asking you to make visible what good engineering teams already do implicitly. You built WHAT?! is not an accusation. It’s a request for receipts.
The next post asks the same question of the code itself: Are you sure you know how to write software?
Read on substack
Paul Gresham is the creator of C3P (Continuous Compliance Control Protocol) and founder of Paul Gresham Advisory LLC. He has spent thirty-five years building and governing software in regulated industries, with senior technology leadership roles at global financial institutions. He writes about continuous compliance, software engineering controls, and AI governance.