Authority to Operate (ATO): FIPS 199, Controls, and FedRAMP

The Authority to Operate process and requirements come from one law and one framework: the Federal Information Security Modernization Act requires every federal information system to be authorized before it connects to a government network, and the NIST Risk Management Framework in Special Publication 800-37 sets out how you get there.¹² In practice, that means categorizing your system’s risk under FIPS 199, selecting and implementing controls from NIST SP 800-53, documenting everything in an authorization package, passing an independent security assessment, and convincing a senior official to accept the residual risk. Then you keep monitoring the system for as long as it runs. Budget for the long version of the calendar. The federal average from initial categorization to a signed authorization letter is about 210 days, and Department of Defense systems routinely take 18 to 24 months.

Who Is Responsible for What

Three roles carry the process, and their accountabilities are enforced when things go wrong.

The Authorizing Official is a senior leader with budgetary and operational authority who makes the final accept-or-deny decision. When this person signs the authorization letter, they personally accept the risk the system introduces to the federal network.³

The System Owner is responsible for the system’s full lifecycle: procurement, development, operation, maintenance, and retirement. The system owner assembles the authorization package, keeps security fixes on schedule, and ensures the confidentiality, integrity, and availability of the data the system handles.³

The Information System Security Officer handles day-to-day security work: researching, implementing, and testing the organization’s security posture. The ISSO typically liaises with the agency’s security team, assesses the impact of proposed system changes, and often manages contracts for penetration testing.³

When a breach happens, a patch cycle slips, or a documented control turns out to exist only on paper, investigators trace responsibility back to these named roles. Losing track of the accountabilities is one of the fastest ways to lose both an authorization and the contract it supports.

Step One: Categorize the System Under FIPS 199

Every other requirement downstream depends on this first decision. Federal Information Processing Standard 199 requires you to assign an impact level to the system based on the potential harm from a loss of confidentiality, integrity, or availability.⁴

Low impact: a breach would cause limited harm to agency operations, assets, or individuals.
Moderate impact: a breach would cause serious harm, such as significant financial loss or disruption to mission-critical functions.
High impact: a breach would cause severe or catastrophic harm, potentially threatening lives, national security, or triggering financial ruin.

Rate each of the three security objectives independently, then apply the high-water mark: the highest individual rating becomes the system’s overall category. A system that rates low for confidentiality and availability but moderate for integrity is categorized moderate overall.

The category you land on directly determines which controls from NIST SP 800-53 you must implement. Higher categories mean more controls, stricter implementation, and a more demanding assessment. Miscategorize in either direction and you pay for it: too low and sensitive data is underprotected; too high and you spend months implementing controls the system does not actually need.

Step Two: Select and Implement Controls

NIST SP 800-53 Revision 5 is the working catalog. It organizes security and privacy controls into 20 families covering access control, incident response, system integrity, supply chain risk, and everything in between.⁵ Your FIPS 199 category maps to a baseline set of controls, which you then tailor to fit the system.

You are not required to build every control from scratch. If your system runs on a cloud platform or shared infrastructure that already carries its own authorization, you can inherit controls that platform already satisfies. NIST SP 800-37 calls these common controls, and the provider maintaining them is responsible for their assessment and monitoring, not you.² A system hosted in an authorized cloud environment typically inherits physical security, environmental protections, and portions of access control from the provider. Where coverage is only partial, the control becomes hybrid: the provider handles their share and you document and implement the rest at the system level.

Common control providers must make their security plans, assessment reports, and remediation documents available to system owners who inherit their controls, and your authorizing official uses those artifacts alongside your own package. Maximizing inherited controls reduces documentation, shortens the assessment, and lowers cost.

Supply chain considerations sit inside this step. NIST SP 800-161 requires authorizing officials to weigh supply chain risks before granting an ATO, which means documenting where your hardware and software come from, assessing supplier trustworthiness, and identifying what happens if a component is compromised or becomes unavailable.⁶ The results feed into an ICT Supply Chain Risk Management Plan, either as a standalone document or integrated into the System Security Plan.

Step Three: Build the Authorization Package

The authorization package is the body of evidence submitted to the authorizing official. It has three core documents.

System Security Plan

The System Security Plan describes what the system does, how it is structured, and which controls protect it. It includes the FIPS 199 categorization, system architecture, authorization boundary definitions, data flow diagrams, interconnections with other systems, and a detailed description of how each applicable NIST SP 800-53 control is implemented.⁷ Every control has to map to a specific organizational practice, not just a statement that the control exists. Most agencies publish standardized templates, and using them is the easiest way to avoid being sent back to the start.

The plan also needs an exhaustive inventory of hardware and software running inside the system boundary. Reviewers cross-check inventories against known vulnerability databases. Anything running that you did not document is a finding waiting to happen.

Security Assessment Report

The Security Assessment Report captures the results of independent testing to verify that the controls described in the System Security Plan actually work in practice. A qualified assessor tests the controls and documents what passes, what fails, and what residual risk remains. For FedRAMP work, that assessor is a Third Party Assessment Organization (3PAO) accredited by the American Association for Laboratory Accreditation.⁸ Independence is a hard requirement: the assessor cannot be anyone who helped build or configure your security controls.

Professional assessments typically cost between $30,000 and $200,000 depending on system complexity and impact level, with full FedRAMP assessments landing at the higher end. This is where most organizations discover the gap between what documentation claims and what the system actually does.

Plan of Action and Milestones

The assessment almost always reveals gaps. You document each weakness in a Plan of Action and Milestones, along with the fix, the responsible party, the resources required, and the target completion date.⁹ The POA&M is a living document reviewed at every monitoring cycle. Authorizing officials read it closely, and the number and severity of open items, combined with how credible the remediation timeline looks, heavily influence whether you get approved, get an interim authorization, or get denied.

Step Four: The Authorization Decision

Once the package is complete, the system owner submits it to the authorizing official. The official evaluates the assessment findings, the remediation plan, and the overall risk picture, then decides whether the system is safe to operate. Document every communication in this period; the audit trail matters.

Timelines are where expectations tend to break. Many guides quote a 30-to-90-day review window, which may describe the final review stage at some agencies but does not describe the process from end to end. From initial categorization through a signed letter, the federal average is around 210 days, and DoD systems frequently run 18 to 24 months. The bottlenecks are as much cultural as technical: agencies often treat the process as a rigid checklist rather than a risk-based framework, and decision-makers sometimes stall rather than issuing a clear approval or denial. Build the longer estimate into any contract schedule.

The official issues one of three outcomes:

Full Authorization to Operate. The system can run for the period the official specifies. There is no universal three-year term; the official sets the termination date based on the system’s risk profile and agency policy.
Interim Authorization to Operate. Granted when certain risks remain but are manageable for a limited period, typically up to six months with one possible six-month extension. Generally reserved for systems still in development or testing, not operational production systems.
Denial of Authorization to Operate. The system poses unacceptable risk and cannot connect to the network. For contractors, denial can trigger contract termination.

After the Signature: Continuous Monitoring

The signed letter is not the finish line. Every authorized system must be continuously monitored so security controls stay effective as threats evolve and the system changes. NIST SP 800-137 sets the framework, and its core principle is that monitoring frequency is driven by risk rather than a fixed calendar.¹⁰ High-impact systems and controls with documented weaknesses need more frequent assessment. Controls that change often, such as software configurations that receive monthly patches, should be scanned at least as often as those changes occur.

Some events trigger a mandatory review outside the regular cadence: major architectural upgrades, changes to physical hosting, new interconnections with other systems, or the discovery of a significant vulnerability. Any of these can require a fresh authorization decision rather than an updated monitoring report.

Mature organizations can transition from a fixed-term authorization to ongoing authorization. Two conditions must be met: the initial authorization must have come through a complete, zero-based review, and the continuous monitoring program must be robust enough to give the authorizing official the information they need for ongoing risk decisions. When those conditions are satisfied, the official issues a new decision that eliminates the termination date and replaces it with a monitoring frequency. The system stays authorized indefinitely as long as monitoring continues to demonstrate acceptable risk.

Cloud Services and FedRAMP

Cloud service providers selling to federal agencies face an additional layer through the Federal Risk and Authorization Management Program. One boundary matters here: a FedRAMP authorization is not itself an Authority to Operate. It means the provider’s security package has been reviewed and is available for agencies to evaluate, but each agency still has to issue its own ATO before using the service.¹¹ The value is reuse: agencies can lean on the FedRAMP package rather than running a full independent assessment from scratch, which cuts the time and cost of each subsequent agency authorization.

FedRAMP uses the same FIPS 199 impact levels with tailored baselines at each tier. Low-impact baselines cover offerings where a breach would cause limited harm and that hold no personal information beyond basic login credentials. High-impact baselines protect the government’s most sensitive unclassified data, including law enforcement, financial, and health systems.¹²

The FedRAMP Marketplace lists cloud offerings in three stages: FedRAMP Ready, where a 3PAO has attested the provider is prepared for assessment; In Process, where a provider is actively working toward authorization with an agency; and Authorized, where the full security package is available for agency reuse.¹³ Private cloud offerings are excluded from the Marketplace because they do not support the program’s “do once, use many” reuse model.

The Cost of Getting It Wrong

The stakes of non-compliance go well past losing a single contract. The Department of Justice launched the Civil Cyber-Fraud Initiative in October 2021 to use the False Claims Act against government contractors and grant recipients who misrepresent their cybersecurity compliance. The initiative targets situations where a contractor’s representations do not match implementation: claiming NIST controls are met when they are not, submitting a System Security Plan describing safeguards never put in place, or certifying compliance to win a contract while cutting corners.

The False Claims Act lets the government recover damages and penalties, and it includes a whistleblower provision. Employees who report compliance fraud can file claims on the government’s behalf and typically receive between 15 and 30 percent of the recovery.¹⁴ These are live risks. In a recent enforcement action, Raytheon and its affiliates agreed to pay $8.4 million to resolve allegations that they failed to comply with cybersecurity requirements in Department of Defense contracts.¹⁵

Beyond False Claims Act exposure, contractors who repeatedly fail to perform or who show a lack of business integrity face debarment under Federal Acquisition Regulation Subpart 9.4. Debarment bars a company from receiving new federal contracts for a set period. The government treats it as a protective measure, not a punishment: it applies when a contractor’s track record raises serious questions about the ability to perform responsibly.¹⁶ Willful failure to perform, a pattern of unsatisfactory performance, or conduct reflecting a lack of business honesty can all trigger proceedings. For a company whose revenue depends on federal work, debarment is existential. The people managing your ATO are, in a real sense, managing whether your company continues to exist as a federal contractor.

1
Computer Security Resource Center. Federal Information Security Modernization Act (FISMA) Background
2
National Institute of Standards and Technology. Risk Management Framework for Information Systems and Organizations NIST SP 800-37 Revision 2
3
Digital.gov. An Introduction to ATOs
4
National Institute of Standards and Technology. FIPS 199 – Standards for Security Categorization of Federal Information and Information Systems
5
National Institute of Standards and Technology. Security and Privacy Controls for Information Systems and Organizations NIST SP 800-53 Revision 5
6
National Institute of Standards and Technology. Supply Chain Risk Management Practices for Federal Information Systems and Organizations NIST SP 800-161
7
FedRAMP. System Security Plan (SSP)
8
FedRAMP Help Center. What Is a Third Party Assessment Organization (3PAO)
9
National Institute of Standards and Technology. Plan of Action and Milestones
10
National Institute of Standards and Technology. Information Security Continuous Monitoring for Federal Information Systems and Organizations NIST SP 800-137
11
FedRAMP. FedRAMP Authorization Designations
12
FedRAMP. Understanding Baselines and Impact Levels in FedRAMP
13
FedRAMP Help Center. How Does a Cloud Service Provider Get Listed on FedRAMP Marketplace
14
United States Department of Justice. False Claims Act Settlements and Judgments Exceed $6.8B in Fiscal Year 2025
15
United States Department of Justice. Raytheon Companies and Nightwing Group to Pay $8.4M to Resolve False Claims Act Allegations
16
Acquisition.gov. FAR Subpart 9.4 – Debarment, Suspension, and Ineligibility