FedRAMP ATO Readiness Checklist for Federal AI Systems

The three-minute summary

FedRAMP is the Federal Risk and Authorization Management Program. It standardizes how federal agencies assess, authorize, and continuously monitor cloud services. If your system processes federal data and runs in a cloud environment, FedRAMP (or its agency-specific derivative ATO) is the path to operate. The process has four stages: decide the impact level, define the boundary, implement and document the controls, and sustain them through continuous monitoring. This page is the structured checklist for all four stages.

Stage 1 — Determine impact level

The impact level is the single most important decision in a FedRAMP engagement. It determines the control baseline, the documentation burden, and the cost of the assessment. Get it wrong and you either over-engineer (expensive) or under-engineer (inadmissible).

FedRAMP Low

Applies when a confidentiality, integrity, or availability failure would have limited adverse effect on agency operations, assets, or individuals. Examples: public-facing informational systems, collaboration tools that do not process PII or CUI. Control baseline is the smallest of the three.

FedRAMP Moderate

Applies when a failure would have serious adverse effect. This is the most common impact level for federal AI systems processing Controlled Unclassified Information, agency operational data, or PII. If you are not sure where your system belongs, Moderate is the usual answer. Roughly 325 controls in the baseline.

FedRAMP High

Applies when a failure would have severe or catastrophic effect. Typical for systems handling law enforcement, emergency services, financial systems, or highly sensitive personal data. Roughly 421 controls in the baseline. Substantially more expensive to authorize and operate.

Impact level determination checklist

1. Enumerate every data type the system will process.
2. Classify each data type against NIST SP 800-60 guidance.
3. Assign a confidentiality, integrity, and availability rating to each data type.
4. Take the high-water mark across all data types — that is your impact level.
5. Document the determination in writing with rationale and agency concurrence.

Stage 2 — Define the authorization boundary

The boundary is the fence around the system. Everything inside is in scope for the ATO; everything outside must be treated as external with documented interfaces. A sloppy boundary is the leading cause of ATO failure.

Boundary definition checklist

1. Enumerate every compute resource — VM, container, function, managed service — that participates in the system.
2. Enumerate every data store — database, object store, cache, queue — holding in-scope data.
3. Enumerate every network segment — VPC, subnet, peering, transit — through which in-scope data flows.
4. Enumerate every external interface — APIs, SFTP, email relays, third-party SaaS — and document what crosses the line.
5. Enumerate every human role — administrator, developer, analyst, auditor — with any access to in-scope components.
6. Document all of the above in a single boundary diagram and a written narrative.

Example: Terraform boundary snippet

module "atob_boundary" {
  source  = "./modules/boundary"
  name    = "federal-ai-moderate"

  allowed_regions       = ["us-gov-west-1", "us-gov-east-1"]
  in_scope_vpc_ids      = [aws_vpc.atob.id]
  allowed_data_stores   = [
    aws_rds_cluster.primary.arn,
    aws_s3_bucket.audit.arn,
    aws_s3_bucket.models.arn,
  ]
  external_endpoints    = []  // intentionally empty; all traffic stays in-scope
  required_tags         = {
    Boundary   = "in-scope"
    Impact     = "Moderate"
    DataClass  = "CUI"
  }
}

Every resource in the module is tagged for automated discovery and control evidence.

Stage 3 — NIST 800-53 control implementation

NIST 800-53 is the control catalog underpinning FedRAMP. The controls are organized into 20 families. For a FedRAMP Moderate system, roughly 325 controls apply. Implementation is the longest part of the process — and the one most often underestimated.

Control families

Control inheritance

A huge fraction of controls are inherited from the underlying FedRAMP-authorized cloud platform. Physical, environmental, facility, and many platform-level controls do not need to be re-implemented — they need to be mapped. Typical inheritance allocations for a system built on AWS GovCloud or Azure Government:

• Fully inherited from platform: 80-120 controls (PE family, portions of MA, SC, SI).
• Shared responsibility: 150-180 controls (the platform provides capability, you configure and operate).
• Fully customer responsibility: 60-100 controls (application-level, data-level, organizational policy).

The FedRAMP-authorized cloud provider publishes a Customer Responsibility Matrix documenting which control is which. Read it before assuming any inheritance.

Example: audit log event format

{
  "timestamp": "2026-04-16T14:22:11.184Z",
  "event_id": "audit-8f4c91d2",
  "principal": {
    "user_id": "u_4821",
    "auth_method": "piv+mfa",
    "session_id": "s_9c21"
  },
  "action": "records.read",
  "resource": "dataset://cui/health-survey-2025",
  "outcome": "allowed",
  "source_ip": "10.42.7.113",
  "request_id": "req_61aa",
  "metadata": {
    "justification": "analytic_query",
    "boundary": "federal-ai-moderate"
  }
}

Every field above maps to specific AU-family controls. Logs are immutable, centrally stored, retained per FedRAMP requirements, and reviewed on a documented cadence.

Stage 4 — Authoring the System Security Plan

The SSP is the definitive document of what the system is, where its boundary runs, and how every required control is implemented. FedRAMP publishes a standard SSP template. Use it. Do not invent your own format.

SSP authoring checklist

1. System identification complete: name, owner, agency sponsor, impact level.
2. System description narrative written — what the system does, who uses it, what data it processes.
3. Boundary diagram, data flow diagram, and architecture diagram embedded.
4. Information types and categorization documented.
5. Interconnections documented for every external interface.
6. Every control has a narrative response describing the implementation — not boilerplate.
7. Every shared or hybrid control identifies the customer responsibility clearly.
8. Every inherited control cites the authoritative source (platform ATO package).
9. Evidence references listed for each control.
10. Document reviewed by someone other than the author before submission.

Stage 5 — POA&M (Plan of Action and Milestones)

No system achieves an ATO with zero findings. The POA&M is the formal tracking document for every known weakness, its remediation plan, and its status. It is a living document for the entire life of the ATO.

POA&M discipline

• Every finding from the independent assessment is entered immediately.
• Each entry has: finding ID, control reference, description, risk rating, remediation plan, owner, original ship date, current status.
• High-risk findings are closed before the ATO is issued.
• Moderate and low findings can remain open with a documented plan and acceptable risk acknowledgment.
• POA&M is reviewed monthly as part of continuous monitoring.
• No finding is silently closed — every closure has evidence attached.

Stage 6 — Continuous monitoring

An ATO is not a one-time certification. It is a commitment to ongoing operational discipline. Continuous monitoring is the set of recurring activities that keep the authorization valid.

Monthly obligations

• Vulnerability scans on all in-scope components, with results delivered to the agency.
• POA&M updates reflecting closed findings and new findings.
• Account management reviews for privileged access.
• Configuration drift reports from baseline comparisons.

Quarterly obligations

• Privileged-access recertification with documented signoff.
• Incident response tabletop exercise or equivalent practice event.
• Log review sample across the AU family to verify completeness.

Annual obligations

• Full independent assessment of a sampled control subset.
• Contingency plan test — restore from backups, verify RTO and RPO.
• Security awareness training completion for every in-scope user.
• Updated SSP reflecting any architectural changes.

Common failure modes

• Boundary drift. The system grows new interfaces nobody updates the SSP for. Prevent with tag-based discovery and boundary enforcement in CI.
• Inherited-control complacency. Teams assume the platform covers more than it does. Read the Customer Responsibility Matrix per control.
• Audit log gaps. A control says logs exist; the log stream has a silent outage nobody notices. Monitor the monitor.
• POA&M rot. Findings linger for months without status updates. Treat POA&M hygiene as a production discipline, not paperwork.
• Weak change control. Engineering ships changes that modify the security posture without going through the configuration management workflow. Automate the gate.
• Underestimated documentation load. Teams budget 20% of effort for documentation; reality is 40-50% for the first ATO.

Realistic timeline

FAQ

What is FedRAMP?

FedRAMP is the Federal Risk and Authorization Management Program. It standardizes the security assessment, authorization, and continuous monitoring of cloud services used by federal agencies, so that one thorough review can be reused by many agencies instead of every agency repeating the same assessment independently.

How long does a FedRAMP ATO take?

Six to twelve months if the team is prepared and the underlying platform is already FedRAMP authorized. Eighteen to twenty-four months cold start, with most of the delay in SSP authoring, control implementation, and assessment findings remediation.

Can I inherit controls from my cloud provider?

Yes, if the underlying cloud is FedRAMP-authorized. You inherit physical, environmental, and many platform-level controls. You remain responsible for customer-configurable controls, application-level controls, data-level controls, and your own organizational policies.

Is FedRAMP the same as a DoD ATO or agency ATO?

Not exactly. FedRAMP is a civilian-agency baseline that many defense and intelligence organizations reuse as a starting point. DoD adds DISA's Cloud Computing Security Requirements Guide and impact levels 2 through 6 on top. Always confirm which framework your target agency actually uses.

Does a Phase I SBIR system need an ATO?

Usually not during Phase I, which is largely a feasibility study. Phase II prototypes often need at least an interim authorization. Phase III commercial deployment into production agency environments almost always requires a full ATO.

What is a 3PAO?

A Third Party Assessment Organization. An independent firm accredited by FedRAMP to perform the security assessment that produces the Security Assessment Report used in the authorization decision. The 3PAO cannot also be the implementer.