Why your audit team and your DevOps team are both right
After thirty-five years inside this fight, I’ve come to think it isn’t really a fight at all.
If you have ever sat in a meeting where the head of internal audit and the head of engineering were trying very hard to be polite to each other, you know the look. The auditor is patient. The engineer is patient. Neither one of them is happy. The auditor asks why a particular change went into production without all fifteen of the required approvals. The engineer explains, again, that ten of those fifteen people are approving precisely the same thing, that the team ships forty times a day, and that the only person who actually carries accountability when something breaks is the engineer who built it. The auditor nods. The engineer nods. Nobody’s mind moves.
I have watched this conversation play out, in some form, for thirty-five years. In London, in Hong Kong, in Singapore, in Zurich. In trading firms, brokerages, wealth managers, and global banks. The names change. The body language is identical.
Here is the thing I want to say to both of them, and to anyone reading this who has been in that meeting: you are both right.
The engineer is right
Modern software is not built the way it was built when most of our compliance frameworks were written. SOX Section 404 was passed in 2002. The IT General Controls model was scaffolded in the years after. They were both designed for an industry that planned, built, tested, approved, and deployed software in linear, deliberate phases. That world existed. I worked in it. We released a few times a year and we counted ourselves lucky.
That world is gone. Modern teams release dozens of times a day. They automate the tests. They automate the deployments. They iterate on the basis of customer behavior rather than annual planning cycles. This is not a fashion. It is how every consequential piece of software is now built, including in regulated industries. The teams who insist otherwise are losing.
So when an engineer tells you that fifteen signatures per change does not scale — and that ten of those fifteen are approving precisely the same thing — they are not being lazy. They are telling you the truth about the medium they work in. They are also telling you something more uncomfortable: that the only person carrying actual accountability when the change breaks is the engineer who built it. To them, the duplicated approvals start to look like a cover-your-ass exercise for everyone except the person who is actually on the hook. A control that worked when you shipped quarterly does not work when you ship hourly. The control has to change.
The auditor is right
But — and this is the part engineers do not always want to hear — the auditor is not wrong either.
Audit professionals have a different mental model. They think about what happens when something goes wrong, who is accountable, and whether anyone can prove it. They have watched institutions take on too much velocity, decide that controls were “slowing innovation,” and then, two years later, watched the regulator walk in. They have seen failed migrations, mis-shipped releases, and the slow grim process of reconstructing what happened from log files that nobody designed for that purpose.
The TSB Bank migration in 2018 is the canonical example. The Financial Conduct Authority and the Prudential Regulation Authority eventually fined TSB £48.65 million. The fine cited, among other things, the inability to verify that the deployed infrastructure matched the original design. That is not a paperwork failing. That is a real-world consequence of a control gap that nobody had taken seriously enough.
So when an auditor pushes back on a velocity-first delivery model, they are not being obstructive. They are pointing at a category of risk that, if it materializes, will cost the firm tens or hundreds of millions of pounds. Their job is to make sure that doesn’t happen. That is a serious job.
What I had wrong
I will tell you candidly where this lesson hit me hardest, because it took me years to learn it. For most of my career I assumed that what audit needed was more engineering rigor. If we shipped cleaner code, with better tests, and a more disciplined delivery process, the audit team would be impressed and step back. They were not. They were polite. They were never impressed.
It took me longer than I would like to admit to understand why. I had been thinking like an engineer about a problem that needed thinking like a controls person. The two are not the same skill. An engineer asks how to make a system work correctly. A controls professional asks how to prove the system worked correctly, to a skeptical observer, after the fact. Those are different questions. They have different answers.
The insight behind C3P is not that engineering rigor is the answer. It is that engineering rigor, applied to the controls problem on its own terms, is the answer. Understand what the audit team actually needs — verifiable provenance, role separation, tamper-evident history — and bring engineering discipline to producing those things automatically as part of the delivery pipeline. Stop trying to impress audit with how clean the engineering is. Start solving the problem the audit team actually has.
Don’t fight audit. Build genuine solutions to the controls they are paid to enforce.
The illusion
The illusion is that you have to choose. Velocity or control. Speed or assurance. Engineers or auditors.
You don’t.
The reason this conflict has festered for two decades is that nobody built a framework that gave both groups what they actually needed. Engineers needed automation, feedback loops, and the freedom to ship without ceremony. Auditors needed traceability, integrity, and continuous evidence. Both can be delivered by the same system — but only if the system is designed for it from the start.
A traditional compliance framework treats evidence as something assembled after the work is done. Spreadsheets, screenshots, sign-off forms. By the time the auditor needs it, the engineering team has moved on six sprints. The reconstruction is expensive, demoralizing, and unreliable.
A different design treats evidence as a natural by-product of the work. Every change records its own provenance as it happens. Every review is logged because the pipeline cannot proceed without it. Every deployment carries a verifiable chain back to the business decision that authorized it. There is no “audit prep.” There is just the audit, and the answer, and the next release going out the door.
This is the design principle behind the framework I have spent the last several years building, called C3P — Continuous Compliance Control Protocol. I will write more about C3P specifically in the next post in this series. For now, the point I want to leave you with is more general:
The reframe
Compliance is not a tax on engineering. It is the proof that engineering did what it was meant to do.
If you build the system so that proof is generated automatically, both your auditor and your engineer get what they need. The auditor gets continuous, queryable evidence rather than retrospective paperwork. The engineer gets the freedom to move quickly, knowing the controls are travelling alongside them rather than waiting at the end of a quarter.
The conflict in the meeting room was never really between auditors and engineers. It was between two outdated models — one of how compliance evidence is gathered, and one of how software is delivered — that the industry never bothered to reconcile.
You don’t need to pick a winner. You need a different design.
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. The Crisis Monitor reference implementation is available at github.com/PGALLC/crisis_monitor.