Two vocabularies, two owners
Most of the confusion we watch play out in a kickoff meeting comes from one unstated assumption: that FedRAMP Low / Moderate / High and DoD IL2 / IL4 / IL5 / IL6 are two sets of rungs on the same ladder, so a team can climb from FedRAMP High and keep going into IL5. They are not one ladder. They are two programs with different owners, different legal authorities, and different questions to answer — and the DoD program consumes the FedRAMP one as evidence rather than continuing it.
FedRAMP is statutory. The FedRAMP Authorization Act — Title LIX, Subtitle C of the FY2023 National Defense Authorization Act, Public Law 117-263 — placed the program inside GSA and codified it at 44 U.S.C. §§ 3607–3616. The implementing guidance is OMB Memorandum M-24-15, issued 25 July 2024, which rescinded the Federal CIO's December 8, 2011 cloud memo and rewrote the program's scope and governance. Section III sets the scope: cloud computing products and services — IaaS, PaaS, SaaS — that "create, collect, process, store, or maintain Federal information on behalf of a Federal agency," and only those systems that process unclassified information and are not national security systems as defined in 44 U.S.C. § 3552.
Impact levels are a Department of Defense construct. They are defined in the DoD Cloud Computing Security Requirements Guide (CC SRG), published by DISA on the DoD Cyber Exchange, which sets out Information Impact Levels 2, 4, 5 and 6 — Level 1 was merged into Level 2 and Level 3 into Level 4 — and which describes its own relationship to the civil program plainly: "This SRG uses the FedRAMP Moderate baseline at all information impact levels and considers the High Baseline at some." The FedRAMP baseline is an input to the DoD label. FedRAMP itself does not award impact levels, so there is no such thing as a "FedRAMP IL5." A companion piece on this site walks through what each impact level actually changes for an AI workload; this one is about the join between the two systems.
Side by side
| FedRAMP | DoD impact levels | |
|---|---|---|
| Who owns it | GSA, with a FedRAMP Board created by the 2022 Act. | DISA, on behalf of the Department of Defense. |
| Authority | 44 U.S.C. §§ 3607–3616; OMB M-24-15. | DoD Cloud Computing SRG; DFARS 239.7602-1. |
| The labels | FIPS 199 impact — Low, Moderate, High. | IL2, IL4, IL5, IL6. There is no IL1 or IL3. |
| What it produces | A FedRAMP authorization for a cloud service offering, reusable across agencies. | A DoD Provisional Authorization (PA) for that offering, at specific impact levels. |
| Who signs | An agency authorizing official. | The DISA authorizing official, after a Joint Validation Team review. |
| Where the list lives | The FedRAMP Marketplace. | DoD Cloud Authorization Services (DCAS) and the DISA Storefront. |
| National security systems | Out of scope by M-24-15 §III. | In scope — IL5 and IL6 exist for exactly that class of information. |
Sources: OMB M-24-15 §§III–IV; 44 U.S.C. §§ 3607–3616; DoD Cloud Computing SRG (DISA); DFARS 239.7602-1; DISA Cloud Assessment Division, DoD Cloud Authorization Process, June 2024.
What a FedRAMP authorization actually buys you
It buys reuse, and reuse is worth a great deal. DISA's own process briefing is explicit: "The DoD authorization process promotes reuse of security authorization packages from FedRAMP and Federal agency authorizations. This allows the CSO to go through the authorization process once, and after achieving authorization, the security package can be reused." The same briefing lays out two paths to a DoD PA — uplift or leverage an existing FedRAMP agency ATO, or go through a 3PAO assessment plus DISA validation against the general readiness requirements in the CC SRG. The first path exists precisely because the FedRAMP body of evidence carries over.
What it does not buy is the right to sell cloud services to DoD. Read the acquisition rule directly. DFARS 239.7602-1(b)(1) says the contracting officer shall only award a contract to acquire cloud computing services from a provider "that has been granted provisional authorization by Defense Information Systems Agency, at the level appropriate to the requirement." The two exceptions at (b)(2) are narrow: a waiver from the DoD Chief Information Officer, or a private, on-premises version provided from U.S. Government facilities — and even then the provider must obtain the authorization before operational use. The clause names DISA specifically. A FedRAMP authorization on its own does not satisfy it.
The reuse rule inside FedRAMP is often mistaken for a rule that reaches this far. M-24-15 §IV.A establishes a presumption of adequacy: if a cloud product or service holds a FedRAMP authorization at a given FIPS 199 impact level, "the Act requires that agencies must presume the security assessment documented in the authorization package is adequate for their use," unless an agency shows a demonstrable need for more. That governs how agencies treat the FedRAMP package. It does not dissolve a separate acquisition requirement written into the DFARS, and it does not extend into the national security systems that FedRAMP's own scope statement sets aside.
The PA is not the ATO
This is the distinction that costs schedules. DISA's June 2024 briefing puts the two side by side, and the split is clean.
Provisional Authorization. Focuses on cloud service offering risk and continuous monitoring. Granted by the DISA authorizing official. Granted to a cloud service provider, for a specific offering, sponsored by a DoD mission owner.
Authorization to Operate. Focuses on mission risk. Granted by a DoD Component's authorizing official. Granted to a DoD mission owner, for the assessed and authorized boundary of the system they are running. In DISA's words, "IAW the CC SRG, DoD MO must leverage a CSO's DoD PA" — the PA is a precondition for the mission owner's decision, not a substitute for it.
The mission owner's authorizing official is told to maximize reuse of the existing body of evidence: review the 3PAO's security assessment report, the POA&Ms, the continuous monitoring data, DISA's authorization recommendation and the PA memo — then decide whether any additional testing is required for their boundary and their data. Everything you deploy on top of the platform is on the far side of that line.
Where teams get surprised
- You cannot self-start a DoD PA — a DoD mission owner sponsors the assessment, and the sponsor supplies two or more analysts to the Joint Validation Team that reviews the package.
- Two marketplaces, two answers — the FedRAMP Marketplace lists FedRAMP authorizations; DCAS and the DISA Storefront list the offerings that carry DoD PAs. Checking one and assuming the other is a common miss.
- The higher up the stack, the more is yours — DISA's own responsibility diagram shows the mission owner's share growing from IaaS to PaaS to SaaS. A SaaS purchase does not move the security work off your plate.
- "Authorized" does two jobs — it describes the platform and it describes your system, and vendors are not always careful about which one they mean.
- Continuous monitoring is a live obligation — a PA is issued with an expiration date, and holding it requires the 30-, 90- and 180-day vulnerability resolution windows plus annual assessments.
- Connection is its own step — the CC SRG requires mission owners to register the system, the offering and the connection method in DISA's SNAP database cloud module and follow the DISN connection process.
FedRAMP's scope stops where national security systems begin
M-24-15 §III limits FedRAMP to unclassified systems that are not national security systems as defined in 44 U.S.C. § 3552. IL5 and IL6 are the DoD levels built for unclassified national security system data and for classified information respectively. So the place where teams most want a FedRAMP authorization to carry them is the exact place FedRAMP's own scope statement declines to go. That is a boundary drawn on purpose, not a gap someone forgot to close.
If your software is not a cloud service, none of this is your accreditation
This is the case we see most often and the one most often mis-framed. A model that ships as an artifact into a customer's existing accredited environment — installed headless, no outbound network, no hosted API on the critical path — is not a cloud service offering. It does not receive a FedRAMP authorization. It does not receive a DoD Provisional Authorization. It is a component inside somebody else's boundary, assessed inside their package, against their control set, by their assessor.
That changes what the compliance work is. The artifacts that matter become a dependency manifest that installs from a mirror rather than a public index; deterministic, fully offline evaluation that can be re-run inside the enclave; logs and traces the customer's existing tooling can read; and control-implementation narrative their system security plan can absorb without rewriting. No license callback, no telemetry, no model download at runtime — each of those is one ordinary line in a container build and each one is a defect on the far side of the boundary. Two adjacent pieces go deeper on this: headless deployment into a customer-controlled sandbox and what actually runs with no network.
It also changes who you need to be talking to. The useful question in the first meeting is not "what impact level are you?" but "which authorization package does this component land in, and which authorizing official owns it?" If nobody on the call can answer that, the schedule everyone is working to is a guess.
The documents move faster than the summaries
The pieces do not move together, which makes stale citations a live hazard. On the DoD side, the full CC SRG text posted on the DoD Cyber Exchange is Version 1 Release 3, dated 6 March 2017, and is written against NIST SP 800-53 Revision 4 — while the guidance wrapped around it has kept moving, with DISA's Cloud Connection Process Guide now at Version 3, December 2025. On the civil side, FedRAMP 20x has moved out of pilot — fedramp.gov describes Phase 3 as active and states that new Rev5 certifications stop being accepted on 11 June 2027. A citation that was correct two years ago may be pointing at a document that has since been reissued underneath it.
The practical discipline is simple. Pull the current release from the DoD Cyber Exchange and read the section, not a summary of the section. Check fedramp.gov's own status pages rather than a vendor recap. Any article on this subject, including this one, is a snapshot with a date on it, and the date matters.
Where our scope ends
Stating the boundary is more useful than claiming breadth, so here is ours.
We are not a cloud service provider, and we hold no FedRAMP authorization or DoD PA
We build mission-owner systems and components that run inside environments other organizations have had assessed. When a design "targets IL5," that means it is built to deploy into an offering that carries an IL5 provisional authorization and to satisfy the mission-owner-side requirements. It does not mean Precision Federal carries an authorization. That distinction is cheap to state and expensive to blur.
We do not issue, sponsor or accelerate authorizations — and we will not quote you a date for one
A provisional authorization is a DISA decision and an ATO is a component authorizing official's decision. We can build to the control set, produce the evidence, and write the sections of the system security plan that describe what we built. Anyone promising a guaranteed accreditation date is promising something they do not control.
We will not write "FedRAMP High equals IL5" — in a proposal, a capability brief, or an email
Impact levels are defined in the DoD's own requirements guide and issued by DISA, and the two programs answer different questions under different authorities. Compressing them into an equivalence reads as fluent shorthand to a general audience and as a tell to an assessor. If a shorthand would not survive being read aloud in a validation meeting, it does not go in our documents.
We will not present a platform's authorization as evidence about our code
Inheriting controls from an authorized offering is legitimate, and we document inheritance as inheritance — which controls are provider-side, which are shared, which are ours. Letting a platform's authorization stand in for a statement about the component we wrote is not legitimate, and it fails on first contact with someone who reads the package carefully.
Where to check all of this yourself
Every claim above is traceable. These are the primary documents, not summaries of them.
- OMB M-24-15, Modernizing the Federal Risk and Authorization Management Program, 25 July 2024 — scope at §III, presumption of adequacy at §IV.A. fedramp.gov
- FedRAMP Authorization Act, Pub. L. 117-263 Title LIX Subtitle C, codified at 44 U.S.C. §§ 3607–3616. uscode.house.gov
- DoD Cloud Computing SRG — impact level definitions at §3.2, DoD use of the FedRAMP baselines at §5.1.1, SNAP registration at §5.10.1.6. Full text, Version 1 Release 3, 6 March 2017: dl.dod.cyber.mil. Current document set: public.cyber.mil/dccs
- DoD Cloud Connection Process Guide, Version 3, December 2025 — SNAP registration, the CATC and CPTC approvals, and the BCAP connection path. dl.dod.cyber.mil (PDF)
- DFARS 239.7602-1 — the provisional-authorization requirement and its exceptions. acquisition.gov
- DISA Cloud Assessment Division, DoD Cloud Authorization Process, June 2024 — the PA/ATO split, the two paths, sponsorship and reuse. dl.dod.cyber.mil (PDF)
- FedRAMP 20x — phases, certification classes and the Rev5 transition dates. fedramp.gov/20x
Working the same problem from another angle: which of FISMA and FedRAMP applies when, choosing between FedRAMP High and Moderate, and the ATO path for an AI component.
Frequently asked questions
No. They come from different programs under different authorities. FedRAMP baselines are FIPS 199 impact levels administered by GSA; impact levels are defined in the DoD Cloud Computing SRG and issued by DISA. FedRAMP does not award impact levels, so there is no such thing as a "FedRAMP IL5." A FedRAMP authorization is evidence a DoD assessment can reuse, not a DoD authorization.
Not by itself. DFARS 239.7602-1(b)(1) directs contracting officers to award cloud computing services only to a provider granted a provisional authorization by DISA at the level appropriate to the requirement. The exceptions are a DoD CIO waiver or a private on-premises version provided from U.S. Government facilities, and in that second case authorization is still required before operational use.
The DISA authorizing official issues the provisional authorization to a cloud service provider for a specific offering, after a Joint Validation Team review and with a DoD mission owner sponsoring. A DoD Component's authorizing official issues the ATO to the mission owner for their own system boundary. The first is about offering risk; the second is about mission risk.
No. OMB M-24-15 §III limits FedRAMP's scope to systems that process unclassified information and are not national security systems as defined in 44 U.S.C. § 3552. DoD handles unclassified national security system data at IL5 and classified information at IL6 under its own requirements guide.
Not as a cloud service offering — FedRAMP scopes to cloud products and services offered to agencies. Software delivered as an artifact into a customer's already-accredited environment is assessed as a component of that customer's system, inside their authorization package. The work shifts from pursuing your own authorization to producing evidence their assessor can absorb: mirrored dependencies, offline evaluation, readable logs, and control-implementation narrative.