How Do I Write a System Description for an ATO?

You are staring at a blank page, and your ATO cannot move forward without a system description. ATO stands for Authorization to Operate. This is the section every other part of your package depends on. Write it like a tour guide, not a sales pitch. NIST places it in the Categorize step of the RMF (Risk Management Framework), under task C-1, System Description (NIST SP 800-37 Rev 2). Here is how to write it, one part at a time.

Start with the name and type

NIST SP 800-18 Rev 2 lists System Name and Identifier as the first plan element. Give the system one unique name and keep it through the whole life cycle. NIST asks you to keep the name steady across inventories and reports, so do not rename it later. Next comes System Type: what kind of system this is. Say if it is cloud based, on premises, public facing, or for internal staff only. Also note whether it is a development, test, or production system.

Describe what the system does

The System Overview explains the mission the system supports. List the business functions, the data types it handles, and the technologies it uses. Name the user groups and who owns the data. This section answers one question: why does this system exist.

Draw the boundary

The Authorization Boundary Description draws the line around what is in and what is out. Name every subsystem, service, and data store inside it. Then add the System Component Inventory: the full list of those parts. Include network diagrams that show how the parts connect. Arrows should show which way the data flows. A blurry boundary is the fastest way to stall an authorization.

Add the categorization and the data flows

State the System Categorization: low, moderate, or high for confidentiality, integrity, and availability. FIPS 199 (Federal Information Processing Standard 199) sets the scale for these ratings. The overall rating takes the highest of the three. Summarize information exchanges with systems outside the boundary. Say what data moves, where it goes, and how it is protected in transit.

Name the people

Role Identification lists the system owner, the authorizing official, and other key roles. An authorizing official decides whether the system may operate. Get real names and titles, not just job descriptions.

List the laws and keep it alive

Also list the laws, regulations, and policies that apply to the system. For federal systems, this includes FISMA (Federal Information Security Management Act). PL-2 in SP 800-53 Rev 5 requires the security plan to be reviewed and updated when the system changes. A system description is not a one time document. Update the boundary, inventory, and diagrams whenever the system changes.

Avoid the common mistakes

Common mistakes: copying a boundary from another system. Skipping the diagrams because the system is small. Describing controls before describing the system they protect. Using marketing language instead of plain facts.

Next step

The description becomes the opening of the SSP (System Security Plan). PL-2 requires the plan to cover the boundary, the environment, and the connections to other systems. PolicyCortex reads live Azure configuration with 33 collectors and builds SSP output from the evidence it collects. It re-verifies controls after remediation, so the package stays current. Start with what your system actually looks like: https://policycortex.com.

Sources

• NIST SP 800-37 Rev 2 (Risk Management Framework): https://csrc.nist.gov/pubs/sp/800/37/r2/final
• NIST SP 800-18 Rev 2 (System Plan Guide): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-18r2.pdf
• NIST SP 800-53 Rev 5 (Security and Privacy Controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• FIPS 199 (Security Categorization): https://csrc.nist.gov/pubs/fips/199/final