Are you sure you know how to write software?
The second control point-of-focus: ensuring code is of sufficient quality. Let me give you a perspective, and something you can do tomorrow morning to improve your pipeline. Continued from Part 1: You built WHAT?!.
Every change that gets merged should be of acceptable quality. That is the control point-of-focus.
It is the question most engineers find most insulting. You spent years learning to write software. You read the books, you’ve shipped production systems, you mentor juniors. Are you sure you know how to write software? — of course you are. Move on.
Put the controls hat on for a moment and the question is not about your competence. It is about whether your team — collectively, day to day — has a standard, applies it consistently, and can show that.
The delivery team’s view
A well-run engineering team has a code style guide, or at least a tacit one. PRs require approval before they merge. Static analysis runs in CI. Tests have to pass. Senior engineers review junior work. Pair programming and rubber-ducking are normal. The team takes pride in what good code looks like, and code that does not meet the bar gets pushed back. The team is doing this because they care, and because their next sprint depends on what last sprint left in the codebase.
This is what good engineering teams do, and it is real work.
The auditor’s view
The auditor does not have an opinion on what good code looks like. The auditor is auditing whether, for any given change in production, you can show that:
- A defined quality standard exists.
- It was applied to this change.
- Where the standard was not met, an authorized exception is recorded.
If you can show those three things, the auditor doesn’t care whether your style guide says tabs or spaces. If you cannot, the auditor starts asking why — and that conversation tends to surface patterns the team did not know they had.
What each side is expecting
Same focus, two languages.
| The delivery team is expecting… | The auditor is expecting… |
|---|---|
| Code is reviewed before merging | A traceable approval on every merged PR, by someone other than the author |
| The team has a sense of what good looks like | A written standard, visible to anyone who joins the team |
| Static analysis and tests run in CI | The CI configuration treats failures as gates, not warnings |
| Exceptions get a senior engineer’s nod | Exceptions are documented, with the authority for the exception named |
| Junior code is mentored | The standard is applied evenly — seniors and juniors held to the same bar, or the difference is policy not vibe |
The delivery team’s expectations are about engineering judgement. The auditor’s expectations are about evidence that judgement was applied. 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.
Is the standard written down? If “we all know what good looks like” is the answer, the standard does not survive a single departure. A written guide — even one page, even auto-generated from a public style guide — is what the auditor can read.
Is the standard applied to everyone? Senior engineers occasionally bypass review on the grounds that they “wrote the system.” Hotfixes go in without review. Each pattern undermines the control. The auditor will look for these gaps, and finding even one will make them keep looking.
Are reviews substantive? A two-second approval is not the same as a review. The auditor doesn’t audit the content of your reviews — but they may notice that an entire week’s worth of merges were approved within ninety seconds of being raised.
When CI fails, what happens? If the team’s habit is to re-run until it passes, you have a flaky-CI problem masquerading as a quality control. If the team’s habit is to override, you have an undocumented-exception problem.
Are exceptions visible? Code that’s allowed to skip review (for emergencies, for example) should leave a trail. A pattern of “emergency” exceptions that are not actually emergencies will fail a control review quietly.
None of these are exotic questions. Each one is a place where a control gap can hide.
What an auditor actually wants to see
Three specific evidence asks:
- A documented code standard, with an owner. One page is enough. The standard can be inherited (a public style guide, a framework’s defaults) or bespoke; what matters is that it is named and accessible.
- A traceable PR approval for every merged change, by someone other than the author, with branch protection enforcing it. The history must be immutable — no rewriting approvals after the fact.
- CI gate configuration that fails the build on the checks that matter — tests, security scans, mandatory lint rules — plus an audit log of any overrides, with the override authority named.
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 or link to your team’s code standard. If you do not have one, adopt a public style guide (the language’s official one, your framework’s defaults) and add a one-page team supplement for the few things you do differently. Get your engineering manager and a senior IC to endorse it.
- Configure branch protection on your main branch so PRs require at least one approving review, by someone other than the author, and all CI checks must pass. GitHub, GitLab, and Azure DevOps all support this as a one-click setting.
- Audit your CI gates. The checks that are warnings rather than blockers — move the ones that actually matter to “blocker” status. Most teams find they had everything configured as warnings by default. Switching them to blockers is a config change, not new tooling.
Half a day’s work. None of it requires a new tool.
The reframe
The auditor isn’t asking whether you write good code. They are asking whether your team has a standard, applies it, and can show it. Your standard is yours to define. The auditor just needs to see the line.
The next post asks the question you ask of every piece of running software, eventually: What is your software doing?
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.