Last updated: August 12, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
Fintech engineering teams keep velocity through an audit by making evidence a byproduct of the pipeline, tiering changes by risk instead of reviewing everything equally, and documenting a break-glass path before they need it. Three patterns. I have shipped under all three, auditors have signed off on all three, and none of them require slowing down.
Eleven days.
That is how long a one-line configuration change once sat in a queue at a lender I was advising. The change adjusted a cache TTL on a pricing service. The engineer who wrote it could have explained it in a single sentence, and eventually did, to a change advisory board that met on Thursdays, had fourteen standing members, and had not read the diff.
The board approved it. The board approved everything. Meanwhile every emergency change that quarter went out in under four hours with a fraction of the scrutiny, and the engineers noticed, because engineers always notice. The process was not protecting production. It was performing protection.
Most of my career has been inside regulated software, lending especially, and I keep meeting VPs who accept this as the entry fee. It is not. The regulation almost never demands the process that is strangling you. Your last audit response does. I have written about where fintech engineering actually differs from generic SaaS, and the honest answer is: in fewer places than your change process implies.
Three patterns fix most of it. Not frameworks. Patterns, the kind you can start on Monday. Each one comes from an org I either ran or got called into after the wheels came off. A few of our auditors ended up liking the result better than the thing it replaced.
The Tradeoff Is Mostly Invented
An audit requires you to prove that changes to production were authorized, tested, and reviewed by someone other than the author. It does not require a weekly meeting, a change freeze, or a ticket in a second system. Everything beyond provable authorization, testing, and separation of duties is process your org added on its own.
Usually in a panic. Usually after a finding.
Google’s DORA research team tested the assumption directly. In the 2019 Accelerate State of DevOps report, organizations that routed changes through an external approval body were 2.6 times more likely to land in the low-performing bucket, and the researchers found no evidence that the extra approvals reduced change failure rates. None. The board slows you down and catches nothing your pipeline would not have caught.
What the board costs you compounds quietly, quarter over quarter, in features not shipped and rate changes met a week late, and the research puts a number on the compounding. McKinsey’s Developer Velocity research found top-quartile companies grew revenue four to five times faster than bottom-quartile peers. In a fintech, where the product is software and the margin is speed to a rate change, that gap is the whole game.
So the real question is not speed versus compliance. It is whether your controls produce evidence or produce meetings. That is a design choice. Three patterns, three sections, no framework diagram.
Let the Pipeline Write the Audit File
The worst two weeks of my year, for several years running, arrived when SOC 2 fieldwork started. Three engineers would stop building and start screenshotting. Jira tickets, pull requests, deploy logs, four hundred screenshots pasted into a shared drive with filenames like evidence_final_v3. Screenshots. Grown adults, screenshotting.
The fix was embarrassingly simple. We stopped assembling evidence and started shipping it. Every merge to a protected branch carries its own audit trail, produced by the tools we were already paying for:
- The ticket link. Jira, Linear, whatever you run. Traceability is the point, not the tool.
- A reviewer who is not the author. GitHub branch protection enforces this with a checkbox, and that one setting satisfies most of what SOC 2’s CC8.1 criterion is actually asking for when it wants changes authorized and approved.
- CI results pinned to the exact commit that shipped. Not the branch. The commit.
- A deploy log answering who, what, and when.
- For infrastructure, the archived Terraform plan output, because infra changes are changes and auditors have learned to ask.
Then we gave the auditor read-only access to the systems themselves. Auditors do not actually want screenshots. They want to see under the hood and trust what they find. Our next Type II took one engineer four days start to finish, and most of that time went to walking the auditor through where to click in systems she already had credentials for.
Evidence stopped being a project. It became exhaust.
Give Changes Lanes, Not a Gate
Back to the Thursday board. We killed it, but not by decree, because auditors reasonably want to know what replaced it. What replaced it was lanes. Every change is classified at the moment it is opened, and the classification decides how much ceremony it gets.
| Lane | What rides it | Approval | Evidence produced |
|---|---|---|---|
| Standard | Dependency bumps, copy changes, config within preset guardrails | None at merge time. The lane itself is re-approved quarterly. | Diff, automated test run, deploy log |
| Normal | Feature work, schema migrations, most bug fixes | One peer reviewer, author cannot self-merge | PR review thread, CI results, ticket link |
| High-risk | Money movement, PII handling, credit decisioning, auth | Senior reviewer plus compliance sign-off, staged rollout | Review thread, test evidence, rollout plan, rollback rehearsal |
At the lender, 82 percent of changes qualified for the standard lane in the first quarter. The cache TTL change that once waited eleven days now ships the same afternoon. And the high-risk lane got slower, on purpose, because the six percent of changes that touch money or credit decisions deserve every bit of the scrutiny the CAB used to spread evenly across everything.
The auditors did not fight us. The opposite. For the first time, the scrutiny map matched the risk map, and an auditor can defend that to their own reviewer. What they cannot defend is a board that waved through four hundred changes a year without reading one.
One warning. The lane definitions have to live in writing, with examples, and someone has to own the boundary. The moment “config change” quietly starts including changes to decisioning thresholds, you have rebuilt the old system with better branding. This is the same discipline problem I described in the case for operational discipline. Write it down, review it quarterly, done.
Build the Break-Glass Path Before the 2 a.m. Page
A rate-lock service fell over at 2 a.m. once, mid-quarter, volume day. An engineer had the fix identified in forty minutes, pushed it straight to production, and saved the pipeline a very bad morning. The fix was correct. I would approve it again today.
The next audit wrote it up as an unauthorized production change. Which, on paper, it was. Nothing in our process distinguished a competent emergency fix from someone quietly pushing whatever they wanted, and an auditor cannot tell the difference from the artifacts alone. The finding was fair. That part stung.
So now every org I run has a break-glass path defined before anyone needs it, and it has exactly four parts. A standing list of people authorized to invoke it. An automatic tag on any deploy that skips the normal lane, applied by the pipeline, not by memory. A post-hoc review within 48 hours where a second engineer signs off on what shipped. And a counter someone actually watches, because break-glass deploys creeping past a few percent of the total means you do not have an emergency problem. You have a planning problem wearing a costume.
Auditors love a documented emergency path. It is one of the specific things a SOC 2 assessor checks under change management, and handing them a clean break-glass log turns your scariest deploys into your best-looking evidence. The 2 a.m. fix stops being a finding. It becomes proof the system works when it matters.
None of This Survives the Wrong Hires
A caveat before the questions, and a bias worth naming. I write in partnership with KORE1, and KORE1 places engineers for a living, so weight what follows accordingly.
These patterns are cheap to run and miserable to bootstrap with a team that has never shipped under audit. Engineers who have lived a SOC 2 cycle write the ticket link without being asked. Engineers who have not will treat the whole thing as bureaucracy until the first finding lands on them, which is roughly what I said in the compliance lessons mortgage tech leaders learn the hard way. When I need that experience fast I lean on recruiters who screen for it, and KORE1’s engineering staffing team averages 17 days to fill technical roles, with a 92 percent twelve-month retention rate. On a contract basis, that can mean a platform engineer who has built the evidence pipeline twice before your next fieldwork window opens.
Before You Blame the Auditors
Questions I get from fintech VPs after I walk through these patterns, usually in the parking lot.
Our auditors specifically asked for CAB minutes. Now what?
They asked for evidence of authorization, and minutes are just the format they have seen most often. Bring them a sample evidence package from your pipeline instead, one change, end to end, and ask whether it satisfies the control objective. In my experience the answer is yes within the hour. Assessors accept equivalent evidence all the time. They rarely volunteer that fact.
Can continuous deployment actually survive a SOX audit?
Public fintechs prove it every quarter. The control SOX cares about is that no single person can push an unreviewed change into a system that feeds financial reporting, and an enforced branch protection rule demonstrates that better than a monthly release meeting ever did. Deployment frequency is not the control. Traceability is.
Does peer review really count as segregation of duties?
In every audit I have sat through, yes, with one condition. The separation has to be enforced by the system, not by policy. If the author can technically approve their own PR and you are relying on people choosing not to, expect the finding. Turn on the setting. It takes a minute.
We have five platform engineers. Which pattern first?
The evidence pipeline, and nothing else for a quarter. It funds the other two. Lanes without automated evidence just move the arguing, and a break-glass path without deploy tagging is a promise, not a control. Small teams get the most out of this, honestly, because they were the ones losing whole weeks to screenshots.
Our last audit already wrote us up for change management. Too late to switch approaches?
A finding is the best moment to switch. You have to submit a remediation plan anyway, so submit this one. I have watched an assessor accept “replace CAB with risk-tiered lanes plus pipeline evidence” as remediation, and the follow-up review went faster than any I had run under the old process. Show them the data and they will usually take it.
Fast Is a Control, Too
This one took me years to actually believe. Small, frequent, well-evidenced changes are not the risky version of shipping. Big quarterly batches are. Every one of DORA’s stability findings points the same direction, and every painful incident review I have ever sat in involved a large change, not a small one.
So stop treating velocity as the thing you spend to buy compliance. Built right, they are the same system. Ship fast. Keep the receipts.
If your audit response has your engineers screenshotting Jira at midnight, or your CFO is asking why releases slowed down again, talk to the KORE1 team about what the right engineers change. And if you want a second set of eyes on your change process specifically, connect with me on LinkedIn. I answer DMs.
