In This Article
Key Takeaways
- An authorization package is a set of per-control claims plus evidence that each claim is true and operating. Architecture decides how expensive both halves are.
- The authorization boundary is determined by the Authorizing Official (NIST SP 800-37 Rev. 2, Task P-11), with the system owner supporting. Everything inside it has to be proven at the system's impact level.
- Inheritance is the largest single cost lever. SP 800-37 Rev. 2 states that system owners are not required to assess or document inherited common controls — that belongs to the common control provider.
- Log format is an accreditation decision made in week two. OMB M-21-31 specifies required event fields, RFC 3339 timestamps, near-real-time automated forwarding to a SIEM, and retention measured in years.
Why it stalls
The pattern is familiar enough to be boring. The software works. The demo went well. A program office wants it. Then someone says "we're in ATO," and eight months later that sentence is still the whole status report — and nobody can name the blocker, because the blocker is not one thing.
The stall is rarely insecurity. It is that accreditation asks a question the build never answered: for every control that applies, what exactly did you implement, and what evidence shows it is operating right now? A system designed without that question can still answer it — slowly, by hand, with senior engineers writing prose instead of code while an assessor books interviews to see things that could have been a query.
This guide is the engineering side of that problem. For the definitions — who signs, why no vendor can sell you one — see our companion piece on what an ATO actually is.
The artifacts, and what they actually are
Under NIST SP 800-37 Rev. 2 (December 2018), the package the Authorizing Official receives is the security and privacy plans, the assessment reports, the plan of action and milestones, and an executive summary — the SSP, the SAR, and the POA&M in everyday speech.
The most useful reframing an engineering team can make: the SSP is not documentation of your system. It is a list of assertions about it, one per applicable control. The controls come from NIST SP 800-53 Rev. 5, still maintained by NIST — release 5.2.0 landed in August 2025. The methods for checking those assertions come from SP 800-53A Rev. 5 (January 2022), which supplies "a methodology and set of procedures for conducting assessments of security and privacy controls."
Two consequences follow. First, a narrative written by someone who did not build the control will not survive an interview — the assessor can go ask the person who did. Write it with that engineer in the room, or write it twice.
Second, and more expensive: every assertion whose only proof is "an engineer will show you on a screen share" converts a five-second check into a scheduled meeting. Across a few hundred control items, that is not a system but a calendar. Evidence the system emits on its own — a config diff, a query result, a signed pipeline log — costs nothing the second time it is asked for.
One mundane failure is worth naming early: 800-53 controls carry organization-defined parameters — the "[Assignment: organization-defined frequency]" blanks. A blank cannot be assessed. Each must resolve to a value the system actually enforces, and reconciling those late is a slow slog.
The boundary is not yours to draw
Task P-11 of SP 800-37 Rev. 2 is one sentence — "Determine the authorization boundary of the system" — and lists Primary Responsibility: Authorizing Official, with the system owner, CIO, and enterprise architect supporting. Engineering teams routinely assume the boundary is theirs to define. It is not — you influence it by how you design, but you do not set it.
The publication's framing: authorization boundaries "establish the scope of protection for information systems ... what the organization agrees to protect under its management control or within the scope of its responsibilities." It adds that "the system is included in a single authorization boundary to ensure accountability," and that clear delineation matters most where lower-impact systems connect to higher-impact ones, or where external providers operate a system.
Translated into architecture:
- Everything inside the boundary must be proven at the boundary's impact level. Convenience services accumulate quietly — a build runner, a metrics dashboard, a scratch database left from a migration. Each is free in development, expensive at assessment.
- Everything outside it that you talk to becomes an interconnection you document and defend. SP 800-37 notes formal agreements with external providers, contracts included, may delineate the boundary.
- The cheapest architecture has the fewest components inside and the fewest, most conventional things crossing. Every unusual egress path is a conversation, and conversations are the unit of delay here.
Inheritance is the biggest lever you have
SP 800-37 Rev. 2 designates controls as system-specific, hybrid, or common (inherited). Common controls "are controls that can be inherited by one or more information systems," supplied by designated common control providers. Then comes the sentence worth more than any tooling decision here:
"System owners are not required to assess common controls that are inherited by their systems or document common control implementation details; that is the responsibility of the common control providers."
Every control you can legitimately inherit is one you do not implement, narrate, evidence, or defend in an interview. Inheritance is not a paperwork trick — it is the single largest determinant of how much accreditation work your architecture creates.
The trap is the hybrid case. SP 800-37: "A requirement may not be fully met by a common control. In such cases, the control is considered a hybrid control," with the organization specifying which parts are inherited and "which parts are to be provided at the system level." A hybrid control is inheritance with a seam, and the seam is yours. Teams mark a control inherited, learn at assessment that only part of it was, and take a finding.
One illustrative case plays out constantly. Integrate with the agency's identity provider and much of the identification-and-authentication family is inherited or hybrid. Stand up your own user store to hit a sprint deadline and the system owns account management, credential policy, multi-factor enforcement, and session handling — plus the evidence for all of it, permanently. A two-day decision with a multi-year tail.
One mechanical detail: common controls "are authorized by designated authorizing officials before the controls are made available for inheritance," so a claim must name the provider and its authorization status. An SSP line reading "inherited" and nothing else is a blank wearing a claim's clothes. In DoD, the impact level decides which foundations you may build on at all.
Evidence is an engineering output
The best evidence is produced by the system continuously, without anyone remembering to collect it. Federal logging requirements are unusually specific.
OMB Memorandum M-21-31, issued August 27, 2021 and signed by then Acting Director Shalanda D. Young, establishes a four-tier event logging maturity model — EL0 (Not Effective), EL1 (Basic), EL2 (Intermediate), EL3 (Advanced) — then gets down to fields. Appendix A's minimum log data includes an accurate timestamp, status code, device identifier, session or transaction ID, source and destination IPs, key-value formatting "where possible," and "a unique event identifier ... defined per event type."
Timestamps are specified down to the format: ISO 8601 and RFC 3339 with milliseconds and a time zone designator, referenced to a GPS master clock or NIST's authenticated time service, with public NTP pools a "last resort." Logs go to centralized SIEM "in near real-time and on an automated basis," and Appendix C sets retention by category — 12 months active plus 18 months cold storage for network and infrastructure logs.
Two footnotes belong in a design review. Software "developed by agencies or by contractors on behalf of agencies must log unique event identifiers for each event" — that reaches application code, not just infrastructure. And if software "does not produce data in this format, Federal agencies will transform records to conform to these standards before the data is ingested into the SIEM."
Read that as a warning, not a reprieve. A non-conforming log schema does not fail loudly; it becomes someone else's transformation job and surfaces at assessment as a finding against your system. Session IDs, correlation identifiers, and structured output are schema decisions made in the first fortnight; retrofitting them across a running service mesh in month ten is a rewrite, and the POA&M item stays open throughout. Much of this overlaps ordinary production telemetry — see what to monitor in an LLM system — so building the two separately means paying twice.
The shape of the timeline
An ATO timeline is not a burn-down. It is three phases with different physics, and estimating it as one line is why that eight-month status report exists.
A long, quiet front end. Boundary, categorization under FIPS 199, baseline selection and tailoring, inheritance mapping. It produces no demo, is chronically underfunded, and is the cheapest place to spend effort — every downstream cost is priced off decisions made here.
Implementation. The part teams estimate well, and usually the only part the plan covers.
A queue. Independent assessment is scheduled, not summoned, and the assessor should have nothing riding on the answer — which is exactly why asking nicely does not compress them. The AO's review belongs to someone whose priorities are not yours.
Authorize is step six of seven, not the finish. The AO sets an authorization termination date — unless, SP 800-37 says, the system runs under an ongoing authorization, where "the authorization frequency is specified in lieu of an authorization termination date."
That is the door to continuous authorization. A DoD CIO memorandum on continuous ATO names three competencies an authorizing official should see, as reported by ExecutiveGov: "adoption of an approved DevSecOps reference design"; the ability to carry out active cyber defense, so that threats can be answered in real time; and "ongoing visibility of cyber activities within the system boundary and continuous monitoring of risk management framework controls." cATOs carry no expiration date but can be revoked — no shortcut around evidence, just a one-time push traded for a permanent standard.
Civilian cloud is moving the same way. FedRAMP 20x, in Phase 3 through FY26 Q3–Q4, is built on Key Security Indicators — described on the program's own site as demonstrating "security posture in near real time, replacing static yearly manual assessments." For scale, FedRAMP's site listed 28 services certified under 20x against 521 certified overall in late July 2026. Plan for the conventional path; keep the automated one open by emitting machine-readable artifacts, which is what NIST's OSCAL is for.
Seven early decisions that help or hurt
Each is made in the first weeks, usually for reasons unrelated to accreditation. Each moves months.
- Identity. Agency identity provider versus your own user store — whether a whole control family is inherited or owned.
- Hosting foundation. An already-authorized agency environment versus infrastructure you assemble — whether physical, environmental, and much infrastructure work is somebody else's evidence or yours.
- Log schema. Covered above — the cheapest fifteen minutes in the project.
- Configuration. Version-controlled declarative config versus servers built by hand — whether configuration-management evidence is a diff an assessor can read or an interview someone sits through.
- Secrets. A managed secrets service versus credentials in config files. Several controls turn on this, and the version with screenshots as evidence ages badly.
- Patch path. Can you ship an upstream security fix without a redeploy that itself needs fresh approval? If not, the architecture is a POA&M generator, and every published CVE adds a row.
- Change cadence versus authorization model. Task M-1 of SP 800-37 requires monitoring the system "for changes that impact the security and privacy posture," with updated plans, POA&Ms, and assessment reports as outputs. Deploying weekly under a point-in-time authorization builds friction into your own release process — the mismatch cATO exists to solve.
What goes wrong
Beyond the failures already named — template narratives, untraceable inheritance claims — four more recur.
- Evidence that exists only as a screenshot in a slide deck. Continuous monitoring will ask again, and its author will have changed teams.
- Parameters left blank — or set to a value the system does not enforce. The second is worse.
- A POA&M with nothing on it. Open items with owners and dates read as candor; a clean sheet on a live system reads as an incomplete search, and reviewers can tell them apart.
- Treating accreditation as a phase after the build rather than a property the build has or lacks. Root cause of most of the above, and cheap to fix only before the architecture sets.
None of this makes a system secure by itself. It makes it legible — the precondition for someone senior signing their name to accepting its risk. The systems that move fast are the ones where every claim in the SSP has a query behind it.
If you want help with this
When the package is the blocker, not the code
Most teams reading this have working software and an authorization that is not moving. The gap is not usually a missing security feature — it is several hundred control claims that nobody has written against the system as actually built, an inheritance story that has never been mapped to named providers, and evidence that exists only in people's heads. That work does not fit between feature sprints, and the engineers who could do it are the same ones shipping the product.
Precision Federal — a federal software and AI firm, and this site's sister organization — builds exactly that layer. The practice covers NIST RMF execution across all seven steps; 800-53 Rev. 5 control implementation with an automation-first bias, because controls backed by technical enforcement and log-generated evidence are far easier to defend in assessment than controls backed by a policy PDF; SSP authoring with control-by-control narratives drafted alongside the engineers who built each control, every organization-defined parameter traced to a specific value, and every inherited control mapped to its source and that source's authorization status; OSCAL-formatted packages for FedRAMP 20x and agency modernization programs; POA&M operation with a named owner per finding, weekly remediation tracking, target dates that do not slip without explicit re-baselining, and open-count, median-age and past-due metrics reported to the AO monthly; and cATO enablement — control evidence wired into CI/CD pipelines, continuous monitoring feeding the agency SIEM, and control-health dashboards an AO can actually read. Overlay work included: privacy and the PT family, CUI under 800-171 and 800-172, HVA, and DoD IL4/IL5/IL6 layering.
What an engagement looks like. A scoped assessment first, a build second. The assessment establishes the boundary as the AO understands it, the categorization, the inheritance map, and a control-by-control gap list against the applicable baseline. That comes before any schedule discussion, because a timeline quoted before someone has read the architecture and the existing package is a guess. Implementation and package authoring follow from what that assessment finds.
What the firm will not do
- Issue an ATO, or say a system "comes with" one. Only a government Authorizing Official can authorize a system. Any vendor claiming otherwise is describing something that does not exist.
- Act as the independent assessor for a system we built. The assessment report should come from a party with nothing riding on the answer. We will help you scope and prepare for it; we will not grade our own work.
- Cosmetically shorten a POA&M. Its entire value to an Authorizing Official is that it is candid. A tidied one is worth less than an honest one, and reviewers can tell.
- Claim impact levels or accreditations we have not worked at. If we have not operated at a given level, we say so in writing rather than let a capability sheet imply it.
- Write a package at arm's length. If the ask is control narratives produced without access to the engineers who built the system, that is the copy-paste failure described above with a purchase order attached. Other firms will take that work. We would rather decline it than deliver a package that falls apart in the first interview.
- Purely commercial compliance with no federal dimension. If what you need is SOC 2 or ISO work for a commercial product, the practice is not built around it and specialists will serve you better.
Sources: NIST SP 800-37 Rev. 2 — Risk Management Framework for Information Systems and Organizations (Task P-11 authorization boundary, Task P-5 common controls, hybrid controls, Task M-1 system and environment changes, ongoing authorization); NIST SP 800-53 Rev. 5 — Security and Privacy Controls; NIST SP 800-53A Rev. 5 — Assessing Security and Privacy Controls; FIPS 199 — Standards for Security Categorization; OMB M-21-31 — event logging maturity model, minimum logging data, retention (Appendices A and C); FedRAMP 20x — phases and Key Security Indicators; FedRAMP — certified service counts, retrieved July 2026; NIST OSCAL; ExecutiveGov — DoD CIO memo on continuous authorization to operate. Analysis and framing by Precision AI Academy.
Common questions
What documents make up an ATO package? Per NIST SP 800-37 Rev. 2: the security and privacy plans (the System Security Plan), the security and privacy assessment reports, the plan of action and milestones, and an executive summary for the authorizing official. The SSP states a claim for every applicable control; the assessment report is an independent check on those claims; the POA&M lists what is not true yet, with an owner and a date.
Who decides the authorization boundary? The Authorizing Official. Task P-11 of SP 800-37 Rev. 2 assigns primary responsibility for determining the boundary to the AO, with the system owner, CIO, enterprise architect and others in supporting roles. Engineering teams influence the boundary through how they design the system; they do not set it unilaterally.
What is control inheritance and why does it matter? SP 800-37 Rev. 2 designates controls as system-specific, hybrid, or common (inherited). Common controls are provided once by a common control provider and inherited by many systems, and the publication states that system owners are not required to assess inherited common controls or document their implementation details — that is the provider's responsibility. Every control legitimately inherited is one you do not implement, evidence, or defend.
What logging does a federal system have to produce? OMB M-21-31 sets a four-tier maturity model (EL0–EL3) and specifies minimum log content: accurate timestamps, status codes, device identifiers, session or transaction IDs, source and destination IPs, and a unique event identifier per event type. Timestamps follow an ISO 8601 and RFC 3339 format with milliseconds and a time zone designator. Logs are forwarded to centralized SIEM in near real time on an automated basis, and Appendix C sets retention by category — 12 months active plus 18 months cold storage for the network and infrastructure categories. The requirements do not apply to national security systems.