What an authority to operate means
An authority to operate (ATO) is the formal decision that lets a federal information system go into production. NIST SP 800-37 Revision 2, quoting OMB Circular A-130, defines it as the official management decision by a senior federal official to authorize operation of a system and to explicitly accept the risk to agency operations, assets, individuals, other organizations and the nation.
Two words in that definition matter most to vendors: decision and risk. An ATO is not a certificate a contractor earns. It is a judgment made by the authorizing official, based on evidence, that the remaining risk is acceptable. Your job as a vendor or subcontractor is to make that evidence complete, accurate and easy to trust.
SP 800-37 lists other possible outcomes besides an ATO: a common control authorization, an authorization to use, and a denial of authorization. The authorizing official can also attach terms and conditions and set an authorization termination date.
The seven steps of the Risk Management Framework
NIST organizes the work into seven steps. Each one produces something the next step depends on, and vendors contribute to most of them.
- Prepare: the organization and system owner set roles, a risk strategy, and the authorization boundary. Vendors help define what is inside the boundary and what is inherited from elsewhere.
- Categorize: the system and its information are categorized by impact, using FIPS 199 levels of low, moderate or high for confidentiality, integrity and availability.
- Select: controls from NIST SP 800-53 are selected, usually starting from a baseline, then tailored.
- Implement: the controls are put in place and documented. This is where most engineering effort lands.
- Assess: an assessor tests whether controls are in place, working as intended, and producing the desired result.
- Authorize: the authorizing official reviews the package and decides whether the risk is acceptable.
- Monitor: controls and risks are watched on an ongoing basis after the decision.
Who does what in an authorization
SP 800-37 assigns tasks to named roles, and knowing them tells you who to ask for what. The authorizing official makes the risk decision. The system owner is responsible for the system, and assembles the authorization package and submits it to the authorizing official. The system security officer maintains the security posture of the system day to day. A control assessor, with the degree of independence the authorizing official decides on, tests the controls and reports the results.
Vendors and subcontractors sit under the system owner. In practice, your main working relationship is with the security officer, who will review your control statements, ask for evidence, and track your findings. Meet that person early. Ask which baseline applies, which templates the agency uses, and how they want evidence delivered. Ten minutes of alignment at the start can save weeks of rework at the end.
Inherited and common controls
Not every control has to be implemented by your system. SP 800-37 describes common controls that a provider implements once and many systems inherit, such as physical security in a data center or an agency-wide training program. When a system runs on an authorized cloud platform, many infrastructure controls are inherited from the provider. For cloud services used by federal agencies, the FedRAMP program is the usual route for that provider authorization.
Inheritance only counts if it is documented. Get the provider responsibility matrix, mark each control as inherited, shared or system-specific, and describe your share of every shared control. Shared controls, such as access management or logging, are where gaps hide.
What goes into the authorization package
The authorizing official decides from the authorization package. Per SP 800-37, at a minimum it includes an executive summary, the system security plan, the privacy plan, the security and privacy control assessments, and any relevant plans of action and milestones.
The system security plan (SSP) is the center of gravity. It gives an overview of the security requirements for the system and describes the controls in place or planned to meet them. For a software team, that means a clear statement of how each relevant control is actually implemented in the code, the infrastructure and the team process.
The plan of action and milestones (POA&M) describes the actions planned to correct deficiencies found during assessment and continuous monitoring. A POA&M is not a confession. It is a schedule. Assessors expect findings, and a POA&M with realistic dates and owners shows the risk is being managed.
How a vendor or subcontractor prepares for an ATO
Subcontractors rarely write the whole package, but they often own the most technical parts of it. The work goes faster when the evidence is produced during development instead of reconstructed at the end.
- Keep an accurate architecture diagram and data flow diagram, including every external connection, port and protocol.
- Write control implementation statements for the controls your code satisfies, such as authentication, session handling, audit logging and input validation, in plain language with specifics.
- Maintain a software and dependency inventory, and patch on a defined schedule.
- Use configuration as code so the deployed configuration matches the documented one.
- Run vulnerability scans and code analysis in the pipeline, and route findings into tickets with owners.
- Record changes through pull requests and change tickets so an assessor can trace any production change to an approval.
Continuous monitoring after the authority to operate
The ATO is not the finish line. The Monitor step keeps watch over control effectiveness and changes to the system and its environment. NIST SP 800-137 describes information security continuous monitoring as maintaining ongoing awareness of assets, threats, vulnerabilities and control effectiveness to support risk decisions.
SP 800-37 notes that an organization may remove the authorization termination date and move to ongoing authorization when its continuous monitoring program gives the authorizing official the information needed to keep making risk decisions. For a development team, that raises the bar on routine hygiene: scans run on schedule, POA&M items close on time, and significant changes are flagged for security review before they ship.
Mistakes that slow an ATO down
Most delays we see in authorization work come from avoidable gaps rather than hard technical problems.
- An unclear authorization boundary, so nobody agrees which components are in scope.
- Control statements copied from a template that do not describe the real system.
- Inherited controls claimed without confirming what the hosting provider or agency actually covers.
- Documentation written in the last month, after the engineers who knew the details have moved on.
- Findings fixed but not recorded, so the POA&M shows open items that are already closed.
How Foundry Peak works on ATO-bound systems
We support a federal law-enforcement system as a subcontractor inside a prime contractor team. We do not hold certifications or grant authorizations, but we build to NIST SP 800-53 Revision 5 controls and write our part of the evidence in the same sprint as the code. If you are a prime or an agency program office preparing for an authorization, we can take on engineering work and the documentation that goes with it.
Sources
- NIST SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations
- NIST SP 800-37 Rev. 2 full text (PDF)
- NIST CSRC, About the RMF
- NIST SP 800-53 Rev. 5, Security and Privacy Controls
- NIST SP 800-137, Information Security Continuous Monitoring
- FIPS 199, Standards for Security Categorization