Authority to Operate for a First System: The Documents and the Realistic Timeline

Start With a Real Number

Federal agencies that attempt an ATO without a complete documentation package before the security assessment phase lose an average of 8 to 14 weeks to rework cycles, according to recurring findings in Inspector General reports across civilian agencies. For a first-time system owner, that delay often pushes a planned go-live past a fiscal year boundary, which triggers budget and contract complications that are entirely avoidable.

This post walks through the core document set required for a FISMA-aligned ATO, the sequence in which those documents are produced, and a realistic week-by-week timeline for a moderate-impact (FIPS 199 Moderate) system going through the process for the first time.

What an ATO Actually Is

An Authority to Operate is a formal written decision by an Authorizing Official (AO) that a system's residual risk is acceptable for operation. It is not a certification, a compliance badge, or a one-time audit. The AO signs a memo or letter that references a specific set of evidence. If that evidence is incomplete, outdated, or contradicted by assessment findings, the AO has no basis to sign. The process that produces the evidence is the Risk Management Framework (RMF), defined in NIST SP 800-37 Rev. 2.

For a first system, the most common failure mode is not a technical security gap. It is missing, inconsistent, or unsigned documents that force the assessor to pause and request remediation before the assessment can conclude.

The Core Document Set

The following list covers what a Moderate-impact system typically requires. Agency-specific templates may add fields, but these are the baseline artifacts the assessor and AO will review.

System Categorization and Planning

• System Security Plan (SSP): The central artifact. Describes the system boundary, data types, user roles, interconnections, and the implementation status of every applicable NIST SP 800-53 control. For a Moderate system this commonly runs 150 to 300 pages including attachments. Incomplete control descriptions are the single most common cause of assessment delays.
• FIPS 199 Categorization Worksheet: Documents the confidentiality, integrity, and availability impact levels for each information type. Must be signed by the system owner and reviewed by the Information System Security Officer (ISSO).
• Privacy Impact Assessment (PIA): Required if the system processes Personally Identifiable Information. Reviewed by the agency Privacy Officer before the assessment begins.
• System of Records Notice (SORN): Required if the system maintains a Privacy Act system of records. Published in the Federal Register, which adds a mandatory 30 to 40 day public comment window that many first-time teams forget to schedule.

Risk and Control Documentation

• Control Implementation Summary (CIS) or Control Traceability Matrix: Maps each 800-53 control to the specific configuration, policy, or technical mechanism that satisfies it. Some agencies fold this into the SSP; others require it as a standalone spreadsheet.
• Hardware and Software Inventory: A current list of all components within the authorization boundary, including version numbers. Assessors will cross-reference this against vulnerability scan results.
• Network and Data Flow Diagrams: Must accurately reflect the production environment. Diagrams that do not match the actual architecture are a fast path to a finding that halts the assessment.
• Interconnection Security Agreements (ISAs) and Memoranda of Understanding (MOUs): Required for every external system connection. Each ISA must be signed by both parties before the assessment closes.

Operational Security Documents

• Incident Response Plan: Must be tested (tabletop at minimum) and include agency-specific contact information. A generic template that has never been exercised will generate a finding.
• Contingency Plan and Contingency Plan Test Results: The plan must be tested. A test report with actual results, not just a plan document, is required.
• Configuration Management Plan: Describes how changes to the system are controlled, reviewed, and documented.
• Rules of Behavior (RoB): Signed by all users with system access. Unsigned RoBs are a persistent finding in first-time assessments.
• Plan of Action and Milestones (POA&M): Documents known weaknesses, their risk ratings, and scheduled remediation dates. A clean POA&M at assessment start is unrealistic; a well-managed one with accurate dates is not.

Assessment-Phase Artifacts

• Security Assessment Plan (SAP): Written by the assessor (a Third Party Assessment Organization or agency assessment team), reviewed and approved by the system owner before testing begins.
• Security Assessment Report (SAR): The assessor's findings. The system owner responds to each finding in writing. This response package, along with an updated POA&M, goes to the AO.
• ATO Memo or Authorization Decision Document: Signed by the AO. Specifies the authorization boundary, the authorization date, and the expiration date (typically three years for a continuous monitoring program).

A Realistic Timeline for a First Moderate-Impact System

The timeline below assumes a team that is organized and responsive. It does not assume perfection. It does assume that the system is built and that the ISSO has been assigned before week one.

1. Weeks 1 to 4: Categorization and boundary definition. Complete the FIPS 199 worksheet. Define the authorization boundary in writing. Identify all interconnections and begin ISA negotiations. Start the PIA if PII is in scope. Assign the SSP template and begin populating system description sections.
2. Weeks 5 to 10: SSP drafting. This is the longest single phase for most first-time teams. Each control must be described with enough specificity that an assessor can verify it. Plan for two internal review cycles. If a SORN is required, submit the draft to the Privacy Officer now so the Federal Register publication timeline does not block the assessment.
3. Weeks 11 to 13: Operational document completion. Finalize the Incident Response Plan, Contingency Plan, and Configuration Management Plan. Conduct and document the contingency plan test. Collect signed Rules of Behavior from all users.
4. Weeks 14 to 15: Internal readiness review. Conduct vulnerability scans and a configuration compliance scan. Resolve critical and high findings before submitting to the assessor. Build the initial POA&M for accepted risks.
5. Weeks 16 to 18: Assessor engagement and SAP approval. The assessor reviews the SSP and supporting documents, writes the SAP, and schedules testing. Expect one to two weeks of back-and-forth on SAP scope.
6. Weeks 19 to 23: Security assessment. The assessor conducts interviews, reviews documentation, and runs independent scans. Expect preliminary findings mid-assessment. Begin drafting responses immediately rather than waiting for the final SAR.
7. Weeks 24 to 26: SAR response and AO package assembly. The system owner submits written responses to findings, updates the POA&M, and assembles the authorization package for the AO. The AO review period varies by agency, typically one to three weeks.
8. Weeks 27 to 30: AO decision. The AO may request additional information, accept risk with conditions, or sign the ATO memo. A first-time system with a well-prepared package commonly receives a decision within this window. An incomplete package resets the clock.

Total elapsed time: 28 to 32 weeks for a well-prepared team. Teams that begin SSP drafting after the system is already in production, or that discover missing ISAs during the assessment, routinely run 40 to 52 weeks.

The Practical Takeaway

Start the SSP the same week you start building the system, not after it is built. Identify your ISA counterparts early because their signature timelines are outside your control. Schedule the contingency plan test before you engage the assessor, not after. And treat the POA&M as a living management tool, not a document you create once and file. Those four habits eliminate the majority of first-ATO delays before they start.

For teams navigating their first federal authorization, our cybersecurity and compliance services cover RMF documentation support, ISSO advisory, and assessment readiness reviews. If you want a quick read on where your package stands before engaging an assessor, reach out through our contact page for a no-obligation conversation.