Most systems don't get their own accredited environment. They get deployed into an existing IT environment — a platform that an IT operations organization already maintains, monitors, and is responsible for.
The vendor builds the system. The program office accepts delivery. And the IT O&M organization is left absorbing the integration and ongoing operational costs.
Nobody scoped that cost. Nobody asked the IT team what they'd need. And the first time the IT team sees the system's actual requirements — hardened images to maintain, containerized database services to operate, patching cadence to keep up, monitoring to configure, storage to provision — is after delivery, when the system is already committed.
This is the most common pattern in DoW software deployment, and it is where the most predictable friction occurs. Not because the technology is hard, but because the people who absorb the cost of operating the system weren't consulted about what it would take.
How the vendor handoff to an accredited environment works
A program office identifies a need. A vendor builds a product. The product gets hardened and authorized for deployment. Everyone celebrates.
Then the system arrives at the IT environment. The IT operations team — the people who keep the accredited platform running — discover:
New container images they have to maintain. The system runs on 3–5 hardened container images with specific base image dependencies. Those images need to be rebuilt when upstream CVEs are patched. The patching cadence is now the IT team's responsibility, and they didn't plan for it.
A containerized database they didn't ask for. The system includes a containerized PostgreSQL or MSSQL instance because the platform doesn't offer a managed database service. That container needs persistent storage, backup automation, migration handling on upgrades, and monitoring. The IT team now operates a database they didn't choose.
Service mesh configuration that affects their platform. The system's VirtualService, DestinationRule, and NetworkPolicy configurations interact with the existing mesh. A misconfiguration doesn't just break the new system — it can affect other tenants on the platform.
Monitoring and alerting gaps. The system has health endpoints, but nobody configured the platform's monitoring stack (Prometheus, Grafana, alert rules) to watch them. The IT team doesn't know what "healthy" looks like for this system because they weren't involved in defining it.
Storage consumption they didn't budget for. Persistent volumes for the database, file storage, and logs consume cluster storage. The IT team's capacity planning didn't include this system.
None of these are surprises. They are the entirely predictable consequences of deploying a system into an environment operated by a team that wasn't consulted about the integration requirements.
Why it doesn't get scoped
Three reasons, all structural:
The vendor's scope ends at delivery. The vendor's contract covers building, hardening, and delivering the system. The contract does not cover the IT team's integration effort — that's someone else's problem. The vendor may not even know what the IT environment looks like on the inside.
The program office thinks in capabilities, not operations. The program office cares that the system works, not how it's operated after deployment. Their test is "does it do the thing?" — not "what does the IT team need to absorb to keep it doing the thing?"
The IT team isn't at the table. The IT operations organization often learns about a new system when the deployment request arrives. They weren't consulted during requirements, weren't consulted during architecture, and weren't consulted during authorization. The first conversation about integration cost happens after the commitment is made.
Who pays when the ATO integration cost is invisible
When the IT integration cost isn't scoped upfront, one of three things happens:
The deployment stalls. The IT team pushes back because they don't have bandwidth or budget for the integration work. The system sits in a queue. The program office and the vendor both believe the system is "ready" — it is, from their perspective. But from the IT team's perspective, there's unplanned work that nobody is paying for. Meanwhile, the cleared IT operations staff absorbing this work bill at GSA Schedule rates of $145–$200/hr — and on the commercial market, $200–$325/hr. Every week of stalled deployment costs real money against someone's budget.
The IT team absorbs it silently. The team takes on the extra workload without additional resources. Service quality across the platform degrades over time. When the next system arrives, there's even less capacity.
The relationship between the vendor and the program office fractures. The program office asks the vendor why the system isn't operational. The vendor says they delivered it. The program office says the IT team says it's not ready. Nobody scoped the gap between "delivered" and "operational."
What a fit study does about this
Millabs' Enclave Fit Study deploys the vendor's product against a hardened baseline and reports what breaks. Part of that report — and the part that program offices and IT teams find most valuable — is the integration cost scope:
What the IT environment will need to do. Not in abstract terms, but in specific work items: which images to maintain, what patching cadence to follow, what storage to provision, what monitoring to configure, what backup automation to operate.
How long it takes. Each integration work item has an effort estimate. The IT team can evaluate whether they have capacity and budget before the system arrives.
What it costs. The cost is stated in dollar terms the program office can act on — using GSA Schedule labor rates (~$175/hr midpoint for cleared DevSecOps) as a baseline, with the understanding that commercial cleared rates run 15–85% higher. The IT team doesn't have to absorb unfunded work — the number is visible before delivery.
The vendor, the program office, and the IT organization all see the real number before handoff. The vendor walks into the program office with specific answers to questions the program office may not have known to ask: how the system gets integrated, what the IT O&M organization needs to plan for, and what the realistic ongoing cost looks like.
The goal is to empower the vendor to advise the program, not wait for the program to figure it out.
For program offices reading this
If you're acquiring a commercial software product for deployment into your IT environment, ask two questions before the contract is signed:
-
Has the product been deployed against the actual hardened baseline? Not modeled, not assessed on paper — actually deployed. If not, the integration cost is a guess.
-
Has the IT operations team been consulted on what they'll need to absorb? If not, you're committing to a system whose operational cost is unknown to the people who will pay it.
A fit study answers both questions in one to three weeks, before the commitment is made.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. Formerly Division Chief, Space Warfighting Analysis Center (USSF/NRO) and Cybersecurity Chief, AFLCMC — roles that included receiving systems into accredited environments and seeing the integration cost firsthand.
If you're deploying a system into an accredited IT environment and nobody has scoped the integration cost, contact Millabs.