ATO Sprints: Accelerating Authority to Operate

In the federal government, the Authority to Operate (ATO) is the ultimate permission slip. It is the formal declaration by an Authorizing Official (AO) that an IT system, software application, or cloud environment has met the rigorous security requirements of the Risk Management Framework (RMF) and is permitted to operate on a government network.

Historically, achieving an ATO has been a notoriously slow, bureaucratic process. It is not uncommon for a traditional ATO effort to take 12 to 18 months. By the time the software is finally authorized, the mission requirements have often changed, or the underlying technology has become obsolete. This delay is unacceptable in modern warfare and federal operations, where speed and agility are critical mission imperatives.

The DoD's own studies have found that the average time to achieve an ATO for a new system is over 400 days. In that same period, a commercial technology company can release dozens of software updates, respond to new threats, and iterate on user feedback. The federal government's inability to deploy technology at the speed of relevance is a recognized national security risk.

To solve this bottleneck, progressive defense contractors and federal agencies have adopted the concept of the "ATO Sprint." An ATO Sprint is a highly focused, accelerated methodology designed to compress the RMF timeline from months to weeks, without sacrificing security or regulatory compliance.

This guide explains the mechanics of an ATO Sprint. It details how contractors can leverage DevSecOps, aggressive control inheritance, automated documentation, and early assessor engagement to deliver rapid mission assurance to their federal customers.

An ATO Sprint is not about skipping steps in the Risk Management Framework (NIST SP 800-37). It is about executing those steps with extreme efficiency and eliminating the waste that plagues traditional RMF efforts.

The traditional RMF process fails because it is treated as a sequential waterfall: build the system, then document the security, then assess the security, then fix the flaws, then resubmit the documentation. Each handoff between teams introduces weeks of delay. Security is treated as someone else's problem until the very end.

The ATO Sprint philosophy shifts security to the "left." It integrates compliance directly into the engineering lifecycle. Security controls are built, documented, and tested continuously as the system is developed. By the time the formal assessment begins, the system is already compliant, the SSP is already written, and the assessor has already reviewed the architecture.

Key Principles of an ATO Sprint

Dedicated, Cross-Functional Teams: A traditional ATO effort often involves throwing documents over the wall between developers, security engineers (ISSEs), and compliance personnel (ISSMs). An ATO Sprint requires a dedicated "Tiger Team." Developers, ISSEs, ISSMs, and ideally a representative from the Assessment team work together daily in agile sprints. Communication is continuous, not episodic.

"Shift Left" Security: Security is not an afterthought. Vulnerability scanning, static code analysis, and configuration checks are automated and run every time a developer commits code. Flaws are fixed immediately, not logged on a massive POA&M at the end of the project. This "fail fast, fix fast" approach eliminates the avalanche of findings that derails traditional assessments.

Continuous Documentation: The System Security Plan (SSP) is not written at the end of the project. It is drafted iteratively. As an engineer configures a control, the compliance specialist documents the implementation details in the SSP in real time. By the time the system is built, the SSP is already 80% complete.

Early Assessor Engagement: Do not surprise the Security Control Assessor (SCA) at the end of the process. In an ATO Sprint, the SCA is engaged early—ideally during the architecture design phase. They review the architecture, agree on the control tailoring, and understand the inheritance model before the formal assessment begins. This eliminates late-stage architectural redesigns that are the single most expensive cause of ATO delays.

Executing a successful ATO Sprint requires specific technical and procedural strategies.

1. Aggressive Control Inheritance

The fastest way to satisfy a NIST 800-53 security control is to prove that someone else is already doing it. This is known as control inheritance.

Modern federal systems are rarely built from scratch on bare metal. They are built in the cloud (e.g., AWS GovCloud, Azure Government) or deployed into existing enterprise data centers. These hosting environments already have an ATO.

If you deploy an application into AWS GovCloud, you inherit the physical security controls (Family PE), environmental controls, and underlying hypervisor security. If you use a PaaS offering, you inherit even more, such as operating system patching and database management controls. If the agency has an enterprise Identity, Credential, and Access Management (ICAM) solution, integrate with it and inherit the complex Identification and Authentication (IA) controls.

In an ATO Sprint, the team maps out every possible inheritable control on Day 1. If a system requires 300 controls, and you can inherit 150 of them from the cloud provider and the enterprise, you have instantly cut the assessment workload in half.

2. Leverage Reciprocity

Reciprocity is the principle that one government agency should accept the security assessment of another agency, rather than forcing the contractor to start from scratch.

If your software application has already achieved an ATO with the Air Force, and you are now deploying it for the Navy, you should not have to execute a full 12-month RMF process. The ATO Sprint team packages the existing Air Force Authorization Package (SSP, SAR, POA&M) and submits it to the Navy AO. The Navy AO reviews the package, assesses any delta in the risk environment, and issues a reciprocal ATO.

While reciprocity is heavily encouraged by DoD policy (DoDI 8510.01 explicitly requires it), it requires proactive management by the contractor to convince the receiving AO that the previous assessment was rigorous and applicable to the new environment.

3. Automated Compliance and "Compliance as Code"

Writing a 500-page System Security Plan in Microsoft Word is the antithesis of an ATO Sprint. Word documents are static, difficult to update, and impossible to query programmatically.

Progressive teams use Governance, Risk, and Compliance (GRC) tools (like eMASS, Xacta, or RegScale) and "Compliance as Code" methodologies.

Open Security Controls Assessment Language (OSCAL): OSCAL is a standardized, machine-readable format for documenting security controls. By using OSCAL, teams can automate the generation of SSPs and other RMF artifacts directly from the system configuration data. When a control is implemented, the OSCAL record is updated automatically. When the SSP needs to be generated, it is produced in minutes, not weeks.

Automated STIG Application: Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) are mandatory configuration baselines. Instead of manually applying hundreds of STIG settings to a server (a process that can take days), teams use automated configuration management tools (like Ansible, Chef, or Puppet) to apply the STIGs instantly and consistently across the entire environment. The same tools can continuously verify that the STIGs remain applied, preventing configuration drift.

4. The Continuous ATO (cATO) Pathway

The ultimate evolution of the ATO Sprint is the Continuous ATO (cATO). A cATO is not an authorization for a specific, static software version; it is an authorization of the software factory itself.

If a contractor can prove to the AO that their DevSecOps pipeline is highly secure—that every piece of code is automatically scanned for vulnerabilities (SAST, DAST, SCA), automatically tested for compliance, and automatically deployed into a secure container environment—the AO can grant a cATO.

Under a cATO, the contractor can deploy new features and updates to the production environment daily or weekly, without needing to go back through the RMF process for every release. The focus shifts from assessing the software to continuously monitoring the pipeline that produces the software. The DoD's Platform One initiative and the Air Force's Kessel Run program are leading examples of the cATO model in practice.

The Assessment phase (Step 4 of RMF) is where many ATO timelines derail. The SCA arrives, finds discrepancies between the SSP and the actual system, and issues a massive list of findings that require weeks of remediation and re-testing.

Conduct Rigorous Pre-Assessments: The contractor's internal team must conduct a "mock audit" before the official SCA arrives. Use the same automated scanning tools (e.g., ACAS, Nessus) that the government will use. Fix the critical vulnerabilities before the official assessment begins. Arriving at the formal assessment with zero critical findings is the hallmark of a mature ATO Sprint team.

Provide "Assessment-Ready" Evidence: Do not make the assessor hunt for evidence. When the assessment begins, hand the SCA a mapped evidence repository where every NIST control is linked to specific, timestamped evidence (e.g., a screenshot of the firewall rule, an export of the Active Directory group policy, the vulnerability scan results). This dramatically reduces the time the assessor spends on evidence collection and allows them to focus on analysis.

The "Fix-in-Place" Window: Negotiate a "fix-in-place" window with the SCA before the assessment begins. If the assessor finds a minor configuration error during the audit (e.g., a single server with an incorrect STIG setting), the engineering team should be allowed to fix it immediately, rather than logging it as a formal finding that requires a POA&M and a subsequent re-assessment. This requires a pre-existing relationship and trust with the SCA, which is why early engagement is so critical.

A mature ATO Sprint program tracks specific metrics to continuously improve its performance.

| Metric | Description | Target | | :--- | :--- | :--- | | Time to ATO | Calendar days from project kickoff to ATO issuance | < 90 days | | Control Inheritance Rate | Percentage of controls inherited vs. implemented | > 40% | | Pre-Assessment Finding Rate | Critical/High findings per 100 controls before formal assessment | < 2 | | SSP Completion at Assessment Start | Percentage of SSP complete when formal assessment begins | > 95% | | POA&M Age | Average age of open POA&M items | < 60 days |

The traditional ATO process is a relic of a slower era of IT procurement. In the modern defense landscape, the ability to rapidly authorize and deploy secure technology is a critical mission enabler.

By adopting the ATO Sprint methodology—integrating security into the DevSecOps pipeline, aggressively inheriting controls, automating compliance documentation, engaging assessors early, and pursuing the cATO model—defense contractors can dramatically reduce the time-to-value for their federal customers.

An ATO Sprint proves that speed and security are not mutually exclusive. When engineered correctly, they are complementary. The contractor who can deliver a secure, authorized system in 60 days instead of 18 months is not just more efficient; they are delivering a fundamentally different level of mission value.

[1] DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf [2] NIST Special Publication 800-37 Revision 2, Risk Management Framework. https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final

The DoD's most advanced ATO Sprint programs are built on the concept of "software factories"—centralized, DoD-managed DevSecOps platforms that provide pre-authorized, hardened infrastructure for development teams.

Platform One: Platform One is the Air Force's enterprise DevSecOps platform. It provides development teams with a pre-authorized, hardened set of tools and services—including container registries, CI/CD pipelines, code scanning tools, and artifact repositories—all running within a DoD IL2/IL4 boundary. When a development team builds their application on Platform One, they inherit the Platform One ATO for the underlying infrastructure. This dramatically reduces the scope of the application-level ATO.

Ironbank: Ironbank is Platform One's hardened container registry. It provides pre-scanned, pre-hardened container images for hundreds of common software components (e.g., Nginx, PostgreSQL, Redis). By using Ironbank images instead of pulling images directly from public registries like Docker Hub, development teams eliminate an entire category of supply chain risk and inherit the security scanning that Platform One has already performed.

Kessel Run: The Air Force's Kessel Run program is the most advanced example of the cATO model in practice. Kessel Run operates a highly secure, DoD-accredited software factory that can deploy new software updates to production systems daily. The AO has authorized the pipeline, not a specific software version. This allows Kessel Run to deliver new capabilities to warfighters at commercial speed, without the traditional ATO bottleneck.

For defense contractors supporting DoD software development programs, familiarity with Platform One, Ironbank, and the cATO model is increasingly a requirement, not a differentiator.

One of the most impactful things an ATO Sprint team can do to accelerate the formal assessment is to prepare a comprehensive, well-organized evidence package before the assessor arrives.

The evidence package is a mapped repository that links every control in the tailored baseline to specific, timestamped evidence of its implementation. It is the difference between an assessor spending three weeks hunting for evidence and an assessor spending three days reviewing it.

Evidence Types: Different controls require different types of evidence. Common evidence types include:

• Screenshots: Timestamped screenshots of system configurations (e.g., a screenshot of the Active Directory password policy settings, a screenshot of the firewall rule base).
• Configuration Exports: Machine-readable exports of system configurations (e.g., a Group Policy Object export, a firewall configuration backup, a STIG XCCDF results file from STIG Viewer).
• Scan Results: ACAS/Nessus scan reports, STIG compliance scan results, and web application scan reports.
• Policy Documents: Approved, signed policy documents (e.g., the Acceptable Use Policy, the Incident Response Plan, the Configuration Management Plan).
• Training Records: Evidence that all users have completed required security awareness training.
• Audit Logs: Sample audit log exports demonstrating that logging is configured and functioning.

Evidence Organization: Organize the evidence package by NIST control family and control number. For each control, include a brief narrative describing the implementation and then attach the supporting evidence. Use a consistent naming convention for evidence files (e.g., `AC-2_Account_Management_GPO_Export_2024-01-15.pdf`).

A well-prepared evidence package communicates professionalism and competence to the assessor. It signals that the team has done the work, not just written about it.

The traditional ATO process is a relic of a slower era of IT procurement. In the modern defense landscape, the ability to rapidly authorize and deploy secure technology is a critical mission enabler.

By adopting the ATO Sprint methodology—integrating security into the DevSecOps pipeline, aggressively inheriting controls, automating compliance documentation, engaging assessors early, leveraging platforms like Platform One, preparing comprehensive evidence packages, and pursuing the cATO model—defense contractors can dramatically reduce the time-to-value for their federal customers.

An ATO Sprint proves that speed and security are not mutually exclusive. When engineered correctly, they are complementary. The contractor who can deliver a secure, authorized system in 60 days instead of 18 months is not just more efficient; they are delivering a fundamentally different level of mission value.

[1] DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf [2] NIST Special Publication 800-37 Revision 2, Risk Management Framework. https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final [3] Platform One. https://p1.dso.mil/