How Federal Delivery Actually Works

Previously, at Meridian — and the contract that changes everything

Two minutes of context, then the map. Meridian Utilities (our fictional regional utility, ~1,400 staff) has spent three trainings modernizing its estate, securing it with Zero Trust, and building a delivery platform — those are the Cloud Modernization, Zero Trust, and DevSecOps Foundations trainings, and nothing here requires them. What matters is what just landed on the platform team’s desk: Meridian won a state-federal interconnect contract. Its grid-analytics software will exchange operational data with a federal energy-coordination system — one that also serves a military installation in Meridian’s service territory. For the first time, Meridian’s software must be delivered into a federal environment.

That sentence carries more obligations than any team expects. The receiving federal system has an authorization to protect. Meridian’s delivery becomes part of that system’s risk story: its code needs an authorization package trail, its evidence must be verifiable by strangers, its updates must cross boundaries that do not trust the sender, and because the contract’s scope includes serving a military installation, the clause stack Meridian’s lawyers find inside it carries obligations they have never met — which clauses apply is a fact of the contract text, never of geography, and Lesson 4.4 is where they get read.

One honest disclosure before we start, because this training’s fiction has to flex where reality bends. Federal delivery is inherently a multi-seat world — the same professional is a vendor delivering into one system, an evaluator inheriting another, and a contractor under clauses for a third. So this training will explicitly change your seat: you’ll spend most of it in the vendor seat (delivering Meridian’s software into the federal system), move to the evaluator seat in Lesson 4.1 (assessing a cloud vendor the way ISSOs actually consume FedRAMP), and sit in the contractor seat for Lesson 4.4 (the clauses that flow down from that military installation). The seat changes are announced when they happen. They’re not continuity errors — they’re the job.

The process: RMF in one pass

Everything federal flows through the Risk Management Framework (NIST SP 800-37, Revision 2 — still the process of record). Seven steps — a preparatory step Revision 2 added, then the six-step operational loop:

PREPARE     get the org and system ready to run this    (Rev 2's headline addition)
            loop at all - roles named, risk strategy set
CATEGORIZE  what would go wrong if this system failed?  (FIPS 199 - the federal
            impact-rating standard: low / moderate / high)
SELECT      which controls apply?                        (the 800-53B baseline for
            that rating, then TAILORED - added or removed with a written reason)
IMPLEMENT   build them - and WRITE DOWN how              (implementation statements)
ASSESS      does a stranger agree they work?             (independent assessor, 800-53A)
AUTHORIZE   a named official accepts the residual risk   (the ATO decision)
MONITOR     keep proving it                              (continuous monitoring / conmon)

Four roles decide everything, and their incentives explain most federal behavior you’ll ever observe:

The one idea to carry through all twenty lessons

Here’s the anchor pattern, and it changes how you read everything downstream: certification is not risk acceptance. An assessment, a certificate, a compliance checkmark — none of these is the authorization. The Authorization to Operate — the ATO, the decision this whole world revolves around — is one named human (the AO) deciding that the remaining risk — the stuff that’s documented as not-fully-satisfied, sitting in a Plan of Action and Milestones — is acceptable for this mission. A system can be authorized with known gaps (they usually are). A system can hold every certificate and be denied. The package exists to make that one decision honest. And because the AO’s queue is the clock on Meridian’s contract revenue, the package is the only lever Meridian controls over how long that clock runs — which is why this training treats it as an engineering artifact and not paperwork. When Lesson 4.4 shows you a certification program suspended while the underlying obligations march on, this is the idea that makes it make sense.

The package the AO reads centers on four load-bearing documents (formally, 800-37’s authorization package is the system plans, the SAR, the POA&M, and an executive summary — the SAP joins the working set in FedRAMP-style programs, and the quartet below is what delivery teams handle day to day):

SSP    System Security Plan       - what the system is, and HOW each control is implemented
SAP    Security Assessment Plan   - how the assessor will test that story
SAR    Security Assessment Report - what the assessor actually found
POA&M  Plan of Action & Milestones - the honest list of gaps, each with an owner and a date

What you already have, translated

Meridian is not replacing its commercial delivery lifecycle; it is making existing work legible to a federal decision. Most vendors arrive holding commercial assurance artifacts, and each has a federal counterpart worth knowing on day one:

YOU HAVE                          THE FEDERAL COUNTERPART
SOC 2 Type II report              the SAR's closest cousin: an independent
                                  opinion on controls operating over time -
                                  evidence for the package, never a substitute
ISO 27001 certificate             a certification (the standards body, not the
(the standard, not the            Information System Owner above) - which this
ISO in the roles table)           lesson just taught is NOT risk acceptance;
                                  the AO still decides
shared-responsibility model       INHERITANCE (Lesson 1.3): the platform answers
(cloud provider vs you)           for its controls; you answer for your delta
CUECs (complementary user-        the CUSTOMER RESPONSIBILITY MATRIX (Lessons
entity controls in your SOC 2)    2.2, 3.3): what remains the consumer's to do

Nothing on the left is wasted; all of it becomes evidence and structure on the right. What it cannot become is the authorization itself — that is the anchor pattern, applied to your own paperwork.

Prompt first: your delivery map

The vendor seat’s opening move — run this against your own product (or Meridian’s grid-analytics stack as described above):

Our software will be delivered into a federal system that holds an
authorization under NIST RMF. Build me a delivery-obligations map:
1) which RMF artifacts our delivery touches (SSP sections, assessment
   evidence, POA&M entries) and what the receiving system's ISSO will
   ask us for, in the order they will ask;
2) the roles on the OTHER side - ISO, ISSO, assessor, AO - and which
   of our artifacts each one actually reads;
3) every claim in our current docs that says 'secure' or 'compliant'
   without naming WHO accepted WHAT risk - flag each as a rewrite.
Format as a table I can walk into a kickoff meeting with.

That third item is the anchor pattern applied on day one: language that implies certification-equals-safety gets rewritten before a federal counterpart reads it.

The honest timelines

No government-wide time-to-ATO statistic exists — anyone quoting one precisely is selling something. The defensible ranges: a traditional ATO takes six months to three years of calendar time, most of it waiting on assessment and package review, not engineering. Delivery onto an inheritance platform (Module 4 explains these) collapses that to weeks, because most of the package is already authorized and your software only answers for its own delta. And continuous authorization — the field’s stated direction, examined honestly in Module 6 — aims to make the question “is it still acceptable?” answer itself every day instead of every three years. Those three speeds are Lesson 1.3. The reason the slow lane is slow — and it’s arithmetic, not culture — is Lesson 1.3’s punchline.

Practice status — among mature regulated delivery programs, commercial and federal

(a few rows carry a more specific status - principle, canon, suspended - where one of the five would mislead)

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

Federal delivery runs through RMF: prepare, then categorize, select, implement, assess, authorize, monitor — with four roles whose incentives explain the system, and a package (SSP, SAP, SAR, POA&M) built to make one decision honest: a named AO accepting residual risk. Certification is never that acceptance. You’ll occupy three seats in this world — vendor, evaluator, contractor — and this training announces each change. Next: the control catalog itself, which turns out to be versioned software.

LEADERSHIP DECISION   approve delivery into a federal system as a program with
                      an AO on a clock - not a checkbox; fund the package as
                      engineering
PRACTITIONER ACTION   build the delivery-obligations map; rewrite every
                      'compliant/secure' claim to name who accepted what risk
SUCCESS MEASURE       days, not weeks, from ISSO kickoff to the first evidence
                      request answered; zero assessment findings for language
                      that equates a certificate with authorization