Every federal program I have worked on eventually produces the same meeting. Delivery says security is the bottleneck. Security says delivery keeps skipping the gate. Somebody proposes a service level agreement: one to two business days for a security checkpoint. Everyone nods. The SLA goes into the charter, and within a quarter it is being missed routinely and quietly.
The mistake is treating that number as a staffing question. It is not. A one to two day checkpoint is a statement about where the control sits in the workflow, and if the control is a review meeting, no amount of headcount will make the number hold.
What the SLA is actually measuring
A checkpoint has three costs, and only one of them is analysis:
- Queue time. How long the request sits before anyone opens it.
- Gather time. How long it takes to assemble the evidence needed to make a decision.
- Decision time. How long the actual judgment takes.
Teams size their security function against decision time, which is usually minutes. Then they get destroyed by gather time. An engineer opens the ticket, discovers the requester has not attached the resource definition, asks for it, waits a day, gets a screenshot instead of a plan file, asks again. The two day clock was consumed entirely by finding out what changed.
That is not a security problem. That is an input format problem.
Move the checkpoint left of the request
If the change is expressed as code, gather time collapses to zero. The diff is the evidence. A Terraform plan tells you the security group is opening 0.0.0.0/0 on 22 without anyone writing a paragraph about it. A Kubernetes manifest tells you the pod is requesting privileged mode. An IAM policy document tells you somebody reached for a wildcard because the specific action list was tedious.
So the working version of the SLA is not "security responds within two days." It is:
Changes inside the authorization boundary arrive as machine-readable artifacts. Policy runs against the artifact automatically on every proposal. A human reviews only what policy could not resolve.
Once that holds, most requests never reach a person, the ones that do arrive with the analysis already attached, and the two day number stops being aspirational.
The part people skip
Automating the check is the easy half. The half that decides whether this survives an assessment is the record it leaves behind.
A pipeline gate that blocks a bad change and writes nothing durable has protected the system and produced no evidence. Come assessment time you will be reconstructing decisions from Slack threads, which is exactly the position the automation was supposed to save you from. Every automated decision should emit a record that answers the same four questions an auditor asks about anything else:
- Who or what proposed the change.
- What specifically changed, at the resource level.
- Which control the check maps to.
- What the outcome was, and who overrode it if anyone did.
Ship those into the same log platform you already run detections on. You get continuous monitoring that is genuinely continuous, a Security Impact Analysis you can produce on demand rather than assemble under duress, and an override trail that is far more interesting to a security team than most of the alerts sitting in the queue. An engineer bypassing a control at 11pm on a Friday is a signal. Most organizations cannot see it because the bypass was a verbal approval.
The uncomfortable version
Security that cannot keep pace with provisioning is security that gets routed around. Not maliciously. People have delivery dates, and a control that reliably costs a week will be avoided by reasonable people acting in good faith. When you find shadow infrastructure, the useful question is rarely who stood it up. It is what the sanctioned path cost them, and whether that cost was one you chose on purpose.
The checkpoint is not the tax you pay for delivering. Built correctly, it is the thing that lets you deliver at all inside a boundary that somebody has to sign for.