The question that started this series arrives in almost exactly these words: when you deploy software to JWICS, is that a JWICS deployment or a TS/SCI deployment?
By now the answer is visible. Neither — because neither of those names refers to an approval. One names a transport service; the other names a classification level joined to a control system. What gets authorized is a system inside a boundary, and the approval to do it is not one signature. It is several, from different authorities, in a dependency order that determines your schedule.
This post is the part that goes in the plan. It starts with the path DoD documents most completely — hosting in DoD cloud, through Secret — and then shows what changes at Top Secret and SCI.
The two authorizations people collapse into one
If your software runs in a cloud service — which for most commercial products it does — there are two separate authorizations in play, and they belong to two different parties. The DoD cloud authorization process sets them side by side:
| Provisional Authorization (PA) | Authorization to Operate (ATO) |
|---|---|
| Focuses on the cloud service offering's risk and continuous monitoring | Focuses on mission risk |
| Granted by the DISA AO | Granted by a DoD Component's AO |
| Granted to a cloud service provider for their offering, sponsored by a mission owner | Granted to a mission owner for the assessed and authorized boundary |
You are the mission owner. The PA is not yours — it belongs to the platform you run on, as the previous post covered. What you get is an ATO for your own boundary, and your AO's job is to accept the risk already identified in that PA in the context of your system, interconnections and data.
Which means your authorization is partly a review of somebody else's paperwork. Your AO reads the provider's assessment report, the residual risk, the continuous monitoring data and DISA's recommendation, and then decides about you. If the platform's evidence is weak, that lands on your timeline.
Inheritance is a mechanism, not a promise
Everyone selling into this space says "you inherit the platform's controls." True, and it has mechanics that decide whether it actually happens.
Inheritance runs through eMASS. The provider maintains a security package for their offering, and that package is what supplies inheritance into a mission owner's own package. So the controls you inherit are the ones the provider has documented and made inheritable — not the ones they have merely implemented.
And there is a detail in the official guidance worth quoting to anyone who assumes this is automatic: "uploading an artifact to eMASS does not make it available for inheriting, it must be attached to a control." An artifact sitting in the package that nobody attached to a control inherits to nothing. You can be running on a genuinely well-secured platform and still be writing control narratives for protections you did not build, because the evidence was never wired up.
How much you inherit also depends on the service model, and the split is steep. On infrastructure as a service most of the responsibility is yours. On platform as a service, less. On software as a service, most of it sits with the provider. Choosing IaaS because it is familiar is choosing the largest control burden available.
And you are entitled to a written account of that split rather than having to negotiate for one. Since the July 2025 revision, section 5.1.4 of the Cloud Service Provider SRG requires that the provider "will provide the Mission Owner (MO) with a responsibility matrix and configuration guide(s) that delineate the security controls the MO can modify or for which the MO is responsible." Get it before you estimate. You can also request the body of evidence from DISA's cloud team, so there is no reason to work from assurances.
Then there is the connection, which is a different approval entirely
Being authorized to operate does not permit you to connect to anything. Connection is a separate determination, made by a separate office, and this is where vendors who budgeted for "an ATO" discover that it was one of four approvals, not the whole set.
For a system connecting to a DISN transport service, the DISN Connection Process Guide governs it. The DISN Connection Approval Office issues an Approval to Connect, and the dependency is explicit: the ATC is contingent on possession of a valid ATO, and the connection approval office confirms the AO has signed before issuing one.
The clock matters as much as the order. An ATC's expiration date "is usually the same as the Authorization Termination Date included in the customer's" authorization decision document. Your connection expires when your authorization expires. They are not two independently renewable things, and a lapsed ATO does not merely pause an assessment — it strands a live connection.
For cloud, the chain is longer still. Every mission owner registers their instantiation of the offering in the SNAP database. The connection approval office issues a Cloud Approval to Connect, and separately a Cloud Permission to Connect for the specific project. Only once both are in hand does DISA's Secure Cloud Computing Architecture office activate the connection through a Boundary Cloud Access Point — and at IL4 and IL5 that connection must be obtained, sustained and funded between the provider's enclave and DISA's access points.
So how many approvals is a classified deployment?
For a system hosted in DoD cloud, at minimum:
- A Provisional Authorization for the platform, from the DISA AO — not yours, but you depend on it, and it can expire or be revoked.
- An ATO for your system, from your component's AO, built partly on the platform's evidence.
- Connection approval from the DISA Connection Approval Office — one or two documents depending on path.
- Connection activation by the SCCA office, with funded transport to a boundary access point.
Four authorities. You control none of them, and three of the four are gated on the one before. That is why a plan built around a single milestone called ATO slips without anyone being able to name the cause.
But notice what that list runs on. A provisional authorization carries an impact level, and as the previous post showed, impact levels stop at Secret. So this chain is the shape of a classified cloud deployment through Secret. It is not, by itself, the answer to the JWICS question.
Top Secret and SCI move under the intelligence community's own regime. ICD 703 requires that "all SCI must be processed, stored, and communicated in accordance with ICD 503, Information Technology Systems Security Risk Management Certification and Accreditation." That title is a small monument to this series. ICD 503 dropped "Certification and Accreditation" from its name in 2015, and in October 2024 the current directive superseded that version under a new title, Intelligence Community Information Environment Risk Management. ICD 703 still points at a directive by a name it has since lost twice.
The current ICD 503 also runs on a Risk Management Framework, and it answers the same three questions in its own terms. Who authorizes: an Authorizing Official designated by the head of the IC element. What carries over: elements shall, "to the maximum extent practical," accept another element's security assessment, but "should test configuration differences introduced by the system, service, or the item in a new environment" — and the IC's Chief Information Security Officer maintains central repositories of inheritable controls. Who approves the connection: interconnection follows IC CIO standards and may require an interconnection security agreement.
One sentence in it deserves more attention than it gets: "Reciprocal acceptance of security and privacy assessments and authorization decisions does not confer data reciprocity." An authorization that travels is not permission to share the data.
So ask the same questions, but do not assume the answers carry over from the Secret path. Anyone who describes a TS/SCI deployment as the Secret path with a higher number on it has made the exact mistake this series is about.
The compartmentation question from earlier in this series sits across all of this, because it decides who may be read in to do the work at all — including your own engineers. And none of these approvals is the thing that determines the size of the job. That is inheritance, and inheritance is decided by where you land.
What to ask, in this order
- Which boundary am I entering, and does it hold a current authorization? If the answer is "we will stand one up," the schedule you were given is wrong.
- What does the hosting platform hold, and when does it expire? Named offering, named authorization, named date.
- Where is the provider's responsibility matrix? The SRG requires them to supply one. Ask for it, and for the evidence behind it, not for an assurance.
- Who is my AO? Not which organization — which office, and what is in its queue.
- Which connection approvals apply, and is transport funded? Ask whether your arrival re-opens a determination that was settled before you got there.
- What access do my people need, and who grants it? Clearance is not access.
None of these is expensive to ask. All are expensive to discover after a date has been committed.
The reframe
"Is this a JWICS deployment or a TS/SCI deployment" has no answer because both options describe attributes of the environment rather than the thing being authorized. The question that does have an answer, and that makes an estimate possible, is:
Which boundary, hosted on what, inheriting which controls, authorized by whom, connected under whose approval, staffed by people with what access?
Six clauses instead of one label. Every one of them is knowable before you commit, and the distance between working software and fielded software is mostly made of the ones nobody asked about.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He has served as ISSM and ISSE for legacy weapon systems at the Air Force Lifecycle Management Center and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO). Millabs has deployed commercial software to IL-4 and TOP SECRET environments operational on JWICS.
If you have been told to get your product into a classified environment and cannot yet name the boundary, the inheritance, or the AO, an enclave fit study answers those questions before you commit to a schedule. Contact Millabs to scope one.