In regulated industries there is a received wisdom that you can move quickly or you can be well controlled, and that the regulator has already made the choice on your behalf. It is a comfortable framing because it excuses a great deal of slowness, and it is wrong.
The actual choice is not between speed and control. It is between controls embedded in the path to production and controls applied as a manual gate at the end. Only one of those scales, and it is not the one most organizations are running.
Why the end-stage gate fails
Start with the economics. A design flaw discovered at the security review two weeks before go-live is expensive to fix. The code is written, the date is committed, the business has been told, and the people who would fix it are already assigned to the next thing.
So what actually happens is one of two things. Either the date slips and the security function absorbs the blame for a delay it did not cause, or the risk is formally accepted with a remediation ticket that will be deprioritized in the next planning cycle and every one after it.
Run that loop a few times and something predictable follows. Teams begin scoping work so that it does not trigger review. It is just a configuration change. It is only an internal tool. It is a minor enhancement to an existing system. None of this is malicious; it is a rational response to a gate that imposes cost late and unpredictably. The result is an organization that is not safer, and is now materially worse at knowing what it is running.
Controls as code
The alternative is to move the control to where the work happens, which means most of it stops being a review at all.
Preapproved architectural patterns do a surprising amount of the work. A pattern reviewed thoroughly once and then reused fifty times consumes expert attention once. Teams get a fast path in exchange for staying inside a known-good design, which most are happy to take.
Policy as code enforces the guardrails at plan time, so infrastructure that violates a control never reaches an environment. The team gets the feedback in minutes from a pipeline, in the context of the change they are making, rather than in a meeting three weeks later from someone reconstructing what they intended.
Dependency and secret scanning at merge catches the most common classes of problem before they are anywhere near production, when fixing them costs almost nothing.
And identity handled through short-lived, automatically issued credentials removes the standing privilege that quietly accumulates for years and shows up in every breach report worth reading.
None of this is novel. What is genuinely uncommon is treating it as the primary control set rather than as supplementary tooling that sits underneath an unchanged manual gate.
Evidence you generate, not assemble
Ask most organizations how long their last audit took and the honest answer includes several weeks of people gathering screenshots, exporting tickets, and reconstructing what happened months ago.
That effort is almost entirely an instrumentation failure. If a control is implemented in the pipeline, the evidence that it operated is a byproduct of running it. Every deployment produces an artifact recording which gates passed, on which commit, approved by whom. Access reviews come out of the identity system rather than a spreadsheet. Change records are generated by the change, not typed in afterward by someone reconstructing it.
The important part is that this is designed at the same time as the control. Adding evidence generation costs very little when the control is being built and is genuinely painful to retrofit onto controls that have been operating informally for three years.
The organizations that find audits routine are not the ones with fewer controls. They are the ones whose controls emit evidence as a side effect of working.
Where humans still belong
None of this argues that security review disappears. It argues about where scarce expert attention is spent.
Human review earns its cost on genuinely novel architecture, on anything that changes authentication, authorization, or cryptography, on new data flows crossing a trust boundary, on third-party integrations that introduce a new dependency, and on the systems where the consequence of being wrong is severe enough that no amount of automation should stand alone.
Spending a senior architect's afternoon on the ninth instance of a pattern that has already been approved eight times is not diligence. It is a queue, and the cost of that queue is measured in the reviews that did not happen on the changes that actually warranted one.
The uncomfortable part
This model asks the security function to give up the gate, which is worth naming plainly because it is a real loss. The gate is the one moment of guaranteed leverage — the point at which the function can say no and be heard.
What replaces it is broader but less dramatic: influence over the patterns everyone builds on, and continuous visibility instead of a point-in-time verdict. In our experience it is a good trade, and it produces materially better outcomes than a gate that people have learned to design around.
But it is a genuine change in how the function operates, how it is staffed, and how it measures itself. It does not happen because somebody wrote it into a strategy document. It happens when the security team is given engineering capacity and made accountable for delivery speed alongside risk — at which point the incentives finally point the same direction as the intent.