Your technology impressed the program office. That is a real milestone. But before your software touches a government network, it usually needs something just as important as funding: an Authorization to Operate, or ATO.
For many SBIR awardees, the ATO is the point where the work shifts from promising prototype to deployable product. If you understand what it is early, and what it takes to get there, you can avoid months of preventable delay later.
What is an ATO?
The short version
An Authorization to Operate is the formal decision by a government Authorizing Official that a system is approved to process, store, or transmit federal information in a government environment. In practical terms, it is the security approval your software needs before it can go live.
The process is governed by the Risk Management Framework, or RMF, established by NIST Special Publication 800-37. Under RMF, you document the system, implement the required security controls, test those controls, and present the resulting security package for review.
What the reviewer actually looks at
That package typically includes core artifacts such as the System Security Plan, the Security Assessment Report, and the Plan of Action and Milestones. Together, those documents show how the system is built, what controls are in place, what risk remains, and whether that risk is acceptable to the government customer.
For companies moving from Phase II into deployment or Phase III work, the ATO is often the bridge between “the government funded this” and “the government can actually use this.”
Why do you need one?
If your SBIR solution will connect to a government network, process or store Controlled Unclassified Information, run inside a government cloud or on-premise environment, or integrate with existing federal or DoD systems, an ATO is usually not optional.
This is where many small businesses get caught off guard. The technology may be ready, the customer may be interested, and the contract opportunity may be real, but none of that changes the fact that deployment can stop cold if the system is not authorized.
- Network connection: If the product touches a government system, security authorization becomes part of deployment.
- Sensitive data: If the system processes, stores, or transmits CUI or classified information, the compliance bar rises quickly.
- Hosted environments: Government cloud and on-premise environments come with security expectations that must be documented and assessed.
- Integration risk: Even if your product is not the system of record, connecting it to existing mission systems can still trigger authorization requirements.
The worst time to discover you need an ATO is after the customer has already said yes. By then, every documentation gap and every missing control becomes schedule risk.
Beyond compliance, an ATO signals credibility. It shows the government customer that you understand the security expectations of operating in a federal environment and that you are capable of meeting them.
The six steps of the RMF process
The RMF breaks authorization into six structured steps. For a first-time SBIR company, understanding these stages early helps with staffing, budgeting, and product planning.
- 1. Categorize: Define the system based on the type of information it handles and the potential impact if confidentiality, integrity, or availability were compromised. This step is guided by FIPS 199 and NIST SP 800-60.
- 2. Select Controls: Choose the required security controls based on system categorization and mission context. Depending on the environment, that usually means NIST SP 800-53 or, for certain CUI cases, 800-171-aligned expectations.
- 3. Implement Controls: Build the controls into the actual system architecture. Access management, encryption, audit logging, configuration management, and vulnerability handling all move from concept to implementation here.
- 4. Assess Controls: A Security Control Assessor or equivalent review team evaluates whether the controls are implemented correctly and operating as intended. The result is typically documented in a Security Assessment Report.
- 5. Authorize: The Authorizing Official reviews the complete package and decides whether to grant an ATO, issue a conditional approval, or deny authorization until issues are addressed.
- 6. Monitor: Authorization is not permanent. You still need continuous monitoring, vulnerability management, incident reporting, documentation updates, and recurring POA&M tracking to keep the system in good standing.
What does it actually cost, in time and money?
The honest answer
The timeline and cost depend heavily on the system, its architecture, the impact level, and how prepared you are when the process starts. A relatively well-prepared low-impact system may move much faster than a complex platform with major documentation and remediation gaps.
For small businesses, the most important point is not the exact number. It is understanding what drives the number.
What usually drives cost
- How complete your system documentation already is
- Your impact level and control baseline
- Whether you can fit inside an existing authorization boundary
- The experience level of the cybersecurity team supporting you
- How much remediation is needed before assessment begins
What consistently increases cost is waiting too long. If the first serious ATO conversation happens only after contract award pressure is already on the table, the team usually ends up paying for speed, rework, or both.
Tips for SBIR companies starting the ATO process
If this is your first time dealing with authorization, there are a few moves that pay off almost immediately.
Start the conversation early
Talk to the program office before you think you have to. Ask whether there is an existing authorization boundary, whether the customer prefers a specific assessor, and whether agency-specific requirements will shape your package. Those answers change your plan in meaningful ways.
Get your documentation in order
Your System Security Plan is the foundation of the entire package. Start documenting system boundaries, architecture, data flows, inherited services, and security practices now rather than trying to reconstruct them under deadline.
Build security in, do not retrofit it
Late-stage architecture fixes are one of the fastest ways to drive up ATO cost. Logging, encryption, access control, segmentation, and secure configuration management are much cheaper when they are designed into the product from the beginning.
Keep one record, not four documents
Manual spreadsheets work for a while, then they become brittle, and the way they break is specific. The SSP, the SAR and the POA&M are three views of the same system under NIST SP 800-37 Rev 2. Kept as three separate documents plus a pile of scan results, they drift apart, and the person who finds the drift is your assessor.
The move that pays off is holding the underlying facts once, your architecture, your control implementations, your evidence, your findings, and producing the documents from them. Scanning and STIG tooling still matter; what changes is that their output lands against the control it bears on instead of in a folder somebody correlates later. For a small team without a full-time ISSO, that structural choice matters more than any individual tool feature.
What happens after you get it
The ATO is not the finish line, and for SBIR companies this is the part that most often comes as a surprise. An authorization is granted against a system as it existed on a particular day, with evidence that was current on that day. Your product will keep changing, because that's what a Phase II or Phase III product does.
So two things start on the day you're authorized. Continuous monitoring: scans on a cadence, evidence that ages out and needs refreshing, inventory that drifts as components are added. And change: every architecture change creates a reassessment scope. The question your AO will eventually ask is not "did anything change?" but "what did that change affect, and what did you do about it?"
Programs that can answer that question narrowly, this component moved, these controls are in scope, here are the reassessments, keep their authorization current at reasonable cost. Programs that can't answer it end up choosing between reassessing everything and reassessing nothing. That's why designing for authorization from day one is worth more than it sounds: the same discipline that gets you the ATO in the first place is what lets you keep it without rebuilding the package every release.
Don't know where to start on your ATO? Ask Alethia Software.
Alethia Software works with SBIR Phase II and III winners that need to navigate the ATO process without building a large, expensive compliance operation from scratch.
Whether you are still developing the product and want to design for authorization from day one, or you are ready to start assembling your RMF package now, we support the practical work that gets a system moving: SSP development, STIG compliance, POA&M management, and broader RMF package support sized for small businesses.
That work runs on CertiField, our operational RMF platform for DoD system authorization. It connects system architecture, security evidence, controls, assessments, findings and POA&Ms in one authorization record and generates SSPs, SARs, POA&Ms, OSCAL and authorization packages from that record, which means the package you hand your AO is a render of current state rather than a reconstruction of it, and it stays that way after the authorization is granted.
The goal is straightforward. Help companies avoid the scramble, reduce rework, and move from award to deployable capability with a security posture the customer can trust.
Need help getting ready for an ATO?
We help SBIR companies build security in early, hold their authorization facts in one record, manage STIG findings, and prepare for deployment in federal environments, then keep the authorization current as the product changes.
Visit Alethia Software Talk to Our TeamAbout the author: Christie Frieg is the President and Founder of Alethia Software, an SBA 8(a) WOSB based in Colorado Springs, Colorado. Alethia Software develops CertiField, its operational RMF platform for DoD system authorization.