Preliminary ATO Documentation - An Engineer's Field Manual for ATO Readiness

Preliminary ATO Documentation Generation

This documentation translates the technical reality into artifacts that an Authorizing Official can evaluate: what the system is, how it works, and how risk is managed.

Prerequisite: Produce the technical evidence

The most important evidence required is the actual container images containing your software under review, which should be traceable back to source code, CI/CD pipelines, SBOMs, and scans. Supporting technical evidence includes the items we discussed in previous sections, such as the following:

Supply chain and vulnerability evidence (Syft Software Bills of Materials, Trivy vulnerability reports). These show that all dependencies are known, tracked, and assessed.
Configuration and compliance scanning (OpenSCAP compliance reports, NeuVector security reports, Kyverno policy reports, and Kiali network traffic reports). These demonstrate enforcement of runtime and configuration expectations, particularly in Kubernetes environments.
Secrets scanning (Trivy, Trufflehog). These primarily support Application Security & Development (ASD) STIG requirements.
Static analysis (SAST) of your own source code. CVE/dependency scanners only find known vulnerabilities in third-party components; they never find flaws in your custom code. A real multi-language pipeline runs a suite of analyzers (selected by language) and normalizes their output to SARIF.
Malware and adversarial testing (ClamAV scan results, manual penetration testing reports). These provide assurance against classes of threats that static analysis cannot detect. For zero-result AV scans, include a bounding statement (signature count and database refresh) so that a 0 reads as "scanned against a current signature set" and not "scan failed or empty."

It can be tempting to just assume that dumping these raw documents in your authorization package is sufficient. It’s often not. Exported evidence reports like this can be incredibly long and detailed. Give summaries to point out what matters and why – strengths, weaknesses, and how they should be interpreted.

If an ATO package allows the AO to understand what risks exist, why they exist, and how you intend to manage them, you are doing it correctly.

Tip: Judiciously leverage AI for drafting ATO documents

Large language models (LLMs) can accelerate your path to ATO in two key ways:

First, AI can help you understand the technical reality. AI can directly analyze your actual codebase and infrastructure to help identify compliance gaps and control mappings. The key is giving AI your actual technical artifacts rather than abstract descriptions. Specific approaches include:

Code analysis with Claude Code or Cursor: Point AI at your actual source code, Dockerfiles, Kubernetes manifests, and configuration files. Ask it to identify potential STIG violations, trace data flows, map authentication/authorization implementations to AC controls, or explain how your current logging setup does (or doesn't) satisfy SI-04 requirements. For example: "Analyze my Kubernetes network policies in the /k8s directory and tell me which SC (System and Communications Protection) controls they satisfy."
Control mapping from implementation: Give AI your actual architecture (Helm charts, Terraform configs, network diagrams) and ask it to map your technical implementation to NIST 800-53 controls. For example: "Based on this Istio AuthorizationPolicy YAML, which access control requirements from AC-3 and AC-6 does this satisfy, and what's still missing?"

Once your system's technical reality is understood and you have credible evidence, AI can accelerate the creation of ATO documents. This includes drafting control narratives for your SSP based on your actual architecture, generating initial POA&M entries from real scan results, or structuring technical descriptions from your deployment manifests. However, human verification of such drafts is still important.

It is vital to understand that AI is not a substitute for robust evidence collection. You still need to generate SBOMs, run vulnerability scans, create architecture diagrams, define authorization boundaries, and document operational procedures. AI can help you understand how these pieces fit together and what they mean for compliance, but it cannot fabricate the artifacts.

Used correctly, AI shortens the path from “we understand our system” to “we have a readable SSP.” Used prematurely, it produces confident-sounding fiction that assessors will dismantle quickly. Without proper evidence, AI-generated content will be vague at best and factually incorrect at worst. This is why upstream work like build hygiene, dependency traceability, and evidence generation matters so acutely in ATO efforts.

[GEN-1] Authorization Boundary

The authorization boundary is a precise list of every component you are asking the AO to trust. List every virtual machine, container, and database included in the boundary, and describe the mechanisms (e.g., Firewalls, Ingress Controllers, Service Mesh) that isolate your system from external environments. A trust boundary diagram can be helpful in showing both what you are intended to trust and other parts of the larger system that may have different trust characteristics that are important for an AO to understand.

[GEN-2, 3] Detailed Software Architecture, Data Flows and Encryption

This provides the "why" and "where" of your system.

A technical description of how data enters, moves through, and leaves the system. Identify every API endpoint, UI portal, or database connection where data enters or leaves. Map the internal route data takes. An example data path could be from a user’s browser to an Ingress gateway, through a sidecar proxy, and into an encrypted database. Highlight exactly where data is encrypted in transit (e.g., mTLS) and at rest (e.g., encrypted PVCs).

Documenting ports, protocols, and services is also a key part of the SSP documentation. This information can likely be incorporated in a table in the SSP and possibly in the architecture diagram as well. A useful form is a table keyed to components, listing default (configurable) ports, distinguishing internal mesh traffic from external dependencies, and explicitly scoping out platform-managed communications.

Architectural assessment can be one of the quickest ways for an AO to start assessing your software. If you are able to provide visual architecture diagrams that can help an AO more efficiently assess the security posture of software system and serve as a map that anchors more detailed documentation in your authorization package.

[GEN-4] Control Implementation Narratives

This is in many ways the "meat" of the SSP in terms of documenting specific ATO requirements. This provides a control-by-control account of where your system stands relative to each control previously selected. There may often be many controls, so placing this documentation in separate spreadsheets from the main SSP document is likely appropriate. However, prioritize documenting controls that are most relevant before investing a ton of upfront time exhaustively documenting every control - your AO assessors may be able to provide more concrete direction later down the line.

Avoid vague policy statements. A "good" narrative is a technical specification of your security architecture:

Bad (Vague): “The system implements access control to ensure only authorized users can see data. We use RBAC.”
Good (Traceable): “Access enforcement is managed via Keycloak integrated into the application. The system denies all requests by default. Authorization is enforced through Istio AuthorizationPolicies at the Big Bang service mesh layer, which validates the JWT ‘roles’ claim against the required application feature role (e.g., AdministratorTool_v2). Technical evidence is provided in the NeuVector Security Reports. Big Bang provides the FIPS-validated ingress controller for TLS termination, and the application delegates all session authenticity to the platform and provides the required app-layer metadata for centralized logging.”

Many technical controls must be implemented in ways specified by Security Technical Implementation Guides (STIGs). A key part of the documentation is mapping controls to specific STIG rules using Control Correlation Identifiers (CCIs) provided with specific STIG rules. Here’s an example:

ASD STIG Rule	Control Correlation Identifier (CCI)	Requirement	Technical Evidence
SRG-APP-000456	CCI-002607	Check for vulnerabilities before production.	Trivy Image Scan: Reported 0 Critical/High findings in build #402.
SRG-APP-000516	CCI-000366	No embedded credentials.	Trivy Secret Scan: 0 findings for keys or certs in image layers.

[GEN-5] System Security Plan (SSP)

There is no tool that tells you whether you are ATO-ready. At its core, the Risk Management Framework (RMF) requires English narratives explaining why controls are satisfied, supported by concrete technical evidence. The SSP does this, and that's why it is the single most important document in your package; authorization hinges on whether the SSP is coherent, comprehensive, and honest.

Think of the SSP as the authoritative blueprint — the hub of the package. Every evidence folder, every control catalog, and every supporting document should trace back to a security story told in the SSP. When you assemble the package, the index itself should send the reader to the SSP first and let everything else hang off it. You likely want to start this early as you document many of the above items, and then you'll want to keep it up-to-date as you add in other types of documentation.

A real SSP can be compact and predictably sectioned. It does not necessarily need to inline every control narrative — that would make it enormous and unmaintainable. Instead it points to the control catalogs (see [GEN-4]) and stays a navigator. A workable section order:

System Categorization (information types and C/I/A)
System Description (software architecture, authorization boundary, interconnections, CI/CD)
Ports, Protocols, and Services
Cryptography
Security Controls (a pointer to the control catalogs)
SRGs / STIGs
Continuous Monitoring Plan
Plan of Actions & Milestones (POA&M)

[GEN-6] SRG/STIG Compliance Documentation

We described above the specific SRG/STIG requirements you'll likely need to meet, as well as where OpenSCAP can automate producing some useful evidence. This should form a matrix referenced in the SSP, typically a spreadsheet/CSV with a README.

You'll need to identify applicable SRGs/STIGs. https://www.stigviewer.com/ can be helpful for browsing these. Not every SRG/STIG or item will be applicable to your software. Focus first on those that are applicable and whether you currently meet those requirements or not. After that, you can provide more comprehensive coverage documentation for all rules in applicable SRGs/STIGs as needed.

[GEN-7] Continuous Monitoring Plan Documentation

Continuous monitoring is a key part of risk management for software approvals and Continuous Authority to Operate (cATO). As noted in articles like the following, continuous monitoring is a key part of a cATO approach:

You'll want to provide at least some brief documentation as part of the System Security Plan outlining how continuous monitoring of your software can work, largely leveraging existing DevSecOps platform infrastructure and also noting any specifics for your software that may be useful.

Keep this distinct from your snapshot-in-time evidence. The build-time and runtime scan reports in your package are dated, manually collected artifacts that are true as of submission. The Continuous Monitoring Plan is the separate story of how the package stays true and how security can be continuously monitored once deployed — it enumerates the running platform capabilities (registry scanning, runtime container monitoring, admission reporting, centralized logging) that keep producing evidence after submission. An AO needs both: "true at submission" and "how it stays true."

[GEN-8] Plan of Actions & Milestones (POA&M)

The POA&M is a formal acknowledgement of your cybersecurity technical debt. It is a “living” backlog that shows the AO you understand your system's flaws. (See this article for more details on POA&Ms.) Each item in the POA&M should be structured like the following:

Nature of Finding: Explicitly state the source of the weakness, such as a Trivy vulnerability scan or an OpenSCAP report.
Risk and Severity: Categorize findings by impact (e.g., CAT I, II, or III).
Interim Mitigations: Describe the "compensating controls" protecting the system now while the fix is being built. (e.g., "While a CVE exists in the web server, we have implemented a Kyverno policy to block all egress traffic from that pod.")
Realistic Remediation Timeline: Define clear milestones, such as "Re-base on hardened image" and "Regression test in staging".

When documenting weaknesses in a POA&M, keep in mind that many vulnerabilities are reported generically, often assuming a worst-case scenario. Vulnerabilities need to be analyzed and reported on considering actual exposure, exploitability, risk, and mitigation approaches in the operational and deployment context of your software.

[GEN-9] Privacy Documentation

The Privacy Impact Assessment (PIA) documents how the system collects, uses, stores, shares, and protects personally identifiable information (PII) and other privacy-sensitive data. While the SSP addresses security controls and technical risk, the PIA focuses on privacy risk, legal authority for data collection, data minimization, retention, sharing, and lifecycle handling of PII, along with safeguards against misuse or overexposure.

For a Big Bang deployment, the PIA should explicitly address whether PII appears in application logs or observability data, whether platform telemetry or monitoring components collect user identifiers, how third-party integrations handle personal data, and how backups, snapshots, deletion, and retention controls protect PII across the platform.

If the system does not process PII, the PIA should explicitly state this and document the analysis supporting that determination.

[GEN-10] Threat model

A threat model is a key way you can surface key security risks to your software and describe how they are handled and maps to a STIG rule. This can be a good, concise way to communicate threat and security practices at an architectural level to help speed up assessment.

The STRIDE framework is a good starting point, applied at each trust boundary crossing in your software architecture. STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege; see Microsoft's STRIDE model documentation for details.

[GEN-11] User Account and Identity Documentation

Reviewers will want a clear account of who can act on the system and how that is enforced, so document the account model as its own artifact rather than scattering it across control narratives. Enumerate the account types (interactive users, service accounts, break-glass/administrative accounts), the roles and the privileges each role carries, and the lifecycle events (provisioning, modification, disabling, removal). Most importantly, describe how authentication and authorization actually integrate with the platform identity provider — where identities come from, how the application consumes validated claims (for example, a JWT roles claim checked at the mesh layer), and what the application delegates to the platform versus enforces itself.

[GEN-12] Application Configuration Guide

An application configuration guide is important, mapping to ASD STIG V-222663. This shows that an operator can stand the system up in the same secure configuration the SSP describes. You should base this on realistically how someone could stand up your system, ideally with as much automation (Helm charts) as possible. Specific manual steps and security-relevant considerations should also be specifically identified.

[GEN-13] Compile the initial ATO package

Once all required controls have been implemented, inherited, or otherwise formally acknowledged, the ATO work culminates in a single, coherent ATO package. This is not merely a collection of reports; it is the body of evidence an Authorizing Official relies upon to make a personal risk decision. The package should read as a navigable path, not a file dump — reviewers consistently reward a clean, indexed body of evidence over raw report dumps, and a raw dump with no summaries actively hurts you.

Lead with a top-level index that orders the folders by flow (foundational documents → control/compliance mappings → build-time evidence → runtime evidence), gives a "start here" pointer per folder, and states an explicit reading sequence (SSP → diagrams → threat model → drill into evidence). In a well-built package, the index is a control narrative.

A reusable folder skeleton:

SystemSecurityPlan/
Diagrams/
ThreatModel/
<Product>Documentation/ — operations/deployment, configuration baseline, data protection, privacy, per-application logging, web/API surface, user accounts
SecurityControls/ — self-implemented catalog + inherited catalog (the two CSVs)
SRGs_STIGs/ — matrix CSV + README
PlanOfActionsAndMilestones/ — CSV + README
Build-time evidence — SBOMs/, VulnerabilityReports/, OpenScapResults/, ClamAvResults/, StaticAnalysisReports/, AutomatedTestReports/
Runtime evidence — ClusterMonitoringReports/ (with policy and runtime-security subfolders)

Due to size, container images themselves must often be delivered separately.

While DoW is heavily leaning into continuous evidence delivery from live systems, initial ATO review is currently still based on a snapshot-in-time package that tells a complete, internally consistent story.

An ATO package should be clearly organized to support an AO doing their best job at efficiently assessing your system. Use techniques like a table of contents and summaries to guide them through your package, rather than just dumping a bunch of reports on them.

Remember that there can be multiple authorization pathways, and you can structure your authorization packages to support both limited and full-scope authorizations and improve them over time as needed.

​Preliminary ATO Documentation Generation