{"description":"Runs the seven NIST SP 800-37r2 RMF phases — Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor — against a single information system to reach and then sustain an authorization-to-operate (ATO) decision. The cycle is anchored on an Audit item created per authorization (\"RMF ATO Cycle — <system> <year>\", audit_type=it_audit, scope=the authorization boundary, period_start/period_end=the AO decision calendar); the information system itself is enriched as an existing Process item (process_type=security_process). Studio has no System/Asset type, so the RMF-specific facts (FIPS 199 categorization, selected baseline, ATO decision, authorization-termination date) live in the phase documents and on the Audit anchor rather than in dedicated fields. In scope: the defined authorization boundary and its inherited, hybrid, and system-specific controls (existing Control items). Out of scope: enterprise-wide common-control-provider programs and standalone penetration testing, which run as their own engagements and are consumed here only as assessment evidence. Named deliverables: the FIPS 199 categorization memo, the System Security Plan (SSP), the Security Assessment Report (SAR), the Plan of Action & Milestones (POA&M), and the signed ATO letter — assembled into one authorization package for the authorizing official. No upstream workflow feeds this cycle; it originates at Prepare. Downstream it hands off to itself: the Monitor phase's reauthorization triggers re-instantiate this template against the same system, and the Monitor phase's closing export is the authorization record the next cycle's Prepare consumes.","edges":[{"id":"e-categorize-impact-level-implement-controls","source":"categorize-impact-level","target":"implement-controls"},{"id":"e-implement-controls-assess-controls","source":"implement-controls","target":"assess-controls"},{"id":"e-assess-controls-classify-disposition","source":"assess-controls","target":"classify-disposition"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clear","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"clean"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"escalate"},{"id":"e-create-action-plan-approve-or-revise-package","source":"create-action-plan","target":"approve-or-revise-package"},{"id":"e-escalate-or-accept-risk-approve-or-revise-package","source":"escalate-or-accept-risk","target":"approve-or-revise-package"},{"id":"e-approve-or-revise-package-monitor-system","label":"Approved","source":"approve-or-revise-package","target":"monitor-system","whenValue":"approved"},{"id":"e-approve-or-revise-package-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-resolve-approval-conditions-monitor-system","source":"resolve-approval-conditions","target":"monitor-system"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AUDIT-26","UC-RISK-18","UC-GOV-16","UC-GOV-18","UC-AUDIT-21"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-rmf-system-authorization-ato","contentDigest":"sha256:fb1370c15e42a8a84603dd92914c3f91d5edd898296476d2cafb967d88ebb215","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:fb1370c15e42a8a84603dd92914c3f91d5edd898296476d2cafb967d88ebb215","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-rmf-system-authorization-ato"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"controls-rmf-system-authorization-ato","source":"coworkcanvas-gallery","standards":["nist-800-53"],"teams":["it","compliance-legal"]},"name":"NIST RMF System Authorization (ATO) Cycle","nodes":[{"data":{"description":"Concur on the authorization boundary, roles and calendar and approve FIPS 199 high-water categorization from complete information types.","instructions":"**Objective** — Concur on the authorization boundary, roles and calendar and approve FIPS 199 high-water categorization from complete information types.\n\n**Inputs**\n- The information system's existing inventory record — the system's Process item (process_type=security_process, process_owner=system owner). Interconnection/data-flow diagrams and the hosting model (on-prem, cloud/FedRAMP, hybrid) arrive as uploads on this step.\n- Mission/business impact context and the organization's risk-management strategy — enterprise Risk items in the register for the context; the strategy and AO risk-tolerance statements ride as uploaded documents (Studio has no Policy home for them here).\n- The common-control catalog from any control-provider program the system will inherit from — existing Control items in the control library (framework=nist-800-53, control_owner=the providing organization).\n- The SP 800-37 role roster (AO, AO designated representative, system owner, ISSO/ISSM, control assessor) — carried on the Audit anchor (lead_auditor=assessor) and the Process item (process_owner=system owner); the remaining roles ride in the workplan upload.\n- The Audit anchor, the system's Process item, and the signed authorization boundary from the PREPARE step.\n- The catalog of information types the system processes, stores, or transmits — arrives as an information-type inventory worksheet uploaded on this step (no native field holds it).\n- SP 800-60 Vol. II provisional impact mappings and any organization-specific overrides.\n\n**Procedure**\n_This checkpoint absorbs “PREPARE authorization record”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. PREPARE authorization record: Stand up the RMF authorization record so every downstream phase runs against an agreed scope. The system already exists in the inventory — this step does not create it; it opens the authorization by creating the Audit anchor, enriching the system's Process item, fixing the authorization boundary, naming the accountable roles, publishing the authorizing-official (AO) decision calendar, and locking the executable workplan (RMF PREPARE, SP 800-37r2 tasks P-9 through P-18).\n2. Create the Audit anchor for this authorization and enrich the system's Process item (create the Process item only if the inventory holds no record): name, owner, environment, data types at a glance, and lifecycle status. The Audit anchor and Process item together anchor every later artifact.\n3. Draw the authorization boundary: enumerate hardware/software/service components, external interconnections, and the controls the system inherits (common), shares (hybrid), or owns (system-specific). Document explicitly what is inside versus outside the boundary; a component left ambiguous voids later inheritance claims. Obtain system-owner and AO concurrence on the boundary.\n4. Assign and record roles: AO, AO designated representative, system owner, ISSO, ISSM, security control assessor, and each common-control provider. Every RMF task needs a named accountable owner.\n5. Establish the AO decision calendar: milestone dates for Categorize, Select, Implement, Assess, and Authorize; AO briefing slots; the ATO target date; and any external deadline (e.g., FISMA reporting or a contract go-live).\n6. Lock the executable workplan: final scope, control owners, due dates, evidence requirements, and review expectations. Freeze it so scope changes become explicit change requests rather than silent drift.\n7. CATEGORIZE impact level: Determine the system's security categorization — the high-water-mark impact level across confidentiality, integrity, and availability — using FIPS 199 and the SP 800-60 information-type mappings, so the correct control baseline can be selected (RMF CATEGORIZE, tasks C-1 through C-3).\n8. Identify every information type in the boundary using the SP 800-60 taxonomy (e.g., financial management, PII, system configuration). Missing an information type understates the categorization.\n9. Assign provisional confidentiality/integrity/availability impact (Low/Moderate/High) to each information type from the SP 800-60 mapping.\n10. Adjust each provisional value for system context (aggregation effects, mission criticality, legal/regulatory drivers), documenting each deviation from the provisional value with rationale.\n11. Apply the high-water mark: the overall categorization for each C/I/A objective is the highest impact across all information types; the system category is the highest of the three (Low, Moderate, or High).\n12. Obtain system-owner and AO agreement on the categorization and record the rationale.\n\n**Record in AssureSwarm**\n- Create the Audit anchor item — audit_type=it_audit, scope=the authorization boundary, period_start/period_end=the decision-calendar window, lead_auditor=the security control assessor.\n- Enrich the system's Process item (create it if the inventory has no record) — process_type=security_process, process_owner=the system owner; capture the boundary summary and environment in its description (Studio has no System/Asset type, so these have no dedicated field).\n- Attach the authorization-boundary diagram and the locked workplan document to this step (uploads — the full role roster, AO/ISSO/ISSM designations, and decision calendar have no native fields and ride in these documents).\n- Attach the FIPS 199 categorization memo (DOCX/PDF: C, I, A, and overall high-water level with rationale) to this step.\n- Record the categorization in the memo and note the overall level in the system Process item's description — Studio has no System/Asset field to hold the C/I/A values.\n\n**Exit criteria**\n- Authorization boundary signed off by system owner and AO; roles assigned; decision calendar published; workplan locked with owners, dates, and evidence requirements.\n- Overall categorization determined by high-water mark, deviations justified, and the categorization approved by the AO and recorded.","label":"CATEGORIZE impact level","performedBy":{"note":"Agent registers the system record, boundary artifacts, and locked workplan; system owner and AO concur on the boundary.","primitives":["coach-item-create","coach-item-update","coach-document-upload"]}},"id":"categorize-impact-level"},{"data":{"description":"Approve tailored baseline responsibility and implement it with specific SSP statements and inheritance evidence.","instructions":"**Objective** — Approve tailored baseline responsibility and implement it with specific SSP statements and inheritance evidence.\n\n**Inputs**\n- The approved categorization from the CATEGORIZE step.\n- SP 800-53B Low/Moderate/High baselines and any applicable overlays.\n- The common-control catalog and the continuous-monitoring strategy drafted in PREPARE.\n- The tailored baseline and SSP from the SELECT step.\n- System architecture, configuration standards, and hardening baselines (e.g., CIS/STIG).\n- Inheritance details from each common-control provider.\n\n**Procedure**\n_This checkpoint absorbs “SELECT and tailor baseline”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. SELECT and tailor baseline: Select the SP 800-53B control baseline matching the categorization, tailor it to the system, allocate common/hybrid/system-specific responsibility, and capture it all in the System Security Plan (SSP) (RMF SELECT, tasks S-1 through S-6).\n2. Pick the starting baseline (Low, Moderate, or High) straight from the overall categorization.\n3. Apply overlays that fit the system (privacy overlay when PII is present, a cloud/FedRAMP overlay for cloud hosting, classified overlays as applicable), reconciling any conflicting parameter values.\n4. Tailor the baseline: document each scoping decision, compensating control, and organization-defined parameter value with an explicit rationale. Removing a baseline control without a documented, AO-acceptable rationale is a finding waiting to happen.\n5. Allocate responsibility for every control: inherited (common-control provider), hybrid (shared), or system-specific. Record the provider for each inherited/hybrid control.\n6. Define the continuous-monitoring frequency and method per control (or control family) so the MONITOR phase has a concrete strategy.\n7. Write the tailored control set and allocation into the SSP.\n8. IMPLEMENT controls: Implement every selected control and record how it is implemented in the SSP, so the assessor has an accurate description to test against (RMF IMPLEMENT, tasks I-1 and I-2).\n9. Implement each control as specified in the SSP, coordinating with control owners for technical, operational, and management controls.\n10. Write the implementation statement for each control part-by-part: what is configured, where, by whom, and how it satisfies the control. Vague statements (\"the system enforces access control\") fail assessment — cite the mechanism and configuration.\n11. Capture inheritance explicitly: for each inherited/hybrid control, reference the provider's implementation and the system-side responsibilities that remain.\n12. Stand up the evidence artifacts the assessor will need (configuration exports, screenshots, policy references) and note where each lives.\n13. QA the implementation statements for completeness against the tailored control set — every selected control must have a statement before assessment can start.\n\n**Record in AssureSwarm**\n- Attach the System Security Plan (SSP) document (DOCX) to this step; record the selected baseline in the SSP and note it in the Process item's description (Studio has no native baseline field).\n- Record control responsibility as Item relationships — link each inherited/hybrid Control item to the system's Process item; the provider is named in each Control's control_owner.\n- Re-attach the updated SSP (with per-control implementation statements) to this step; there is no per-control implementation-status field, so status lives in the SSP.\n- Attach the configuration/hardening evidence (exports, CIS/STIG proof) to this step.\n\n**Exit criteria**\n- Tailored baseline with documented scoping/parameters and responsibility allocation captured in an SSP approved by the system owner.\n- Every selected control has a specific implementation statement in the SSP, inheritance is documented, and evidence locations are recorded.","label":"IMPLEMENT controls","performedBy":{"primitives":["coach-item-update","coach-document-upload","coach-items-link"]}},"id":"implement-controls"},{"data":{"description":"Independently assess control effectiveness against SP 800-53A and produce the Security Assessment Report (SAR)","instructions":"**Objective** — Independently assess whether the implemented controls are effective, following SP 800-53A assessment procedures, and produce the Security Assessment Report (SAR) with a determination for every control (RMF ASSESS, tasks A-1 through A-6).\n\n**Inputs**\n- The SSP with implementation statements from the IMPLEMENT step.\n- SP 800-53A assessment procedures and the Security Assessment Plan (SAP).\n- The evidence artifacts referenced in the SSP.\n- Independent security testing results (penetration test) and any prior security control assessment for inherited controls, consumed here as supporting evidence — uploaded on this step; any pre-existing pentest findings are existing Issue items (source=penetration_test) linked to the affected Controls. These engagements run outside this workflow.\n\n**Procedure**\n1. Develop or confirm the SAP: assessment methods per control (examine, interview, test), depth and coverage, and the sample of controls/instances to be tested. Assessor independence from the implementation team is required for the result to be defensible.\n2. Execute the assessment procedures control-by-control, gathering and referencing evidence for each determination.\n3. Determine each control as \"satisfied\" or \"other-than-satisfied\" per SP 800-53A determination statements; partial satisfaction is other-than-satisfied.\n4. For each other-than-satisfied control, document the finding, its risk (likelihood/impact), and a recommended remediation.\n5. Assemble the SAR: assessment scope, method, per-control results, findings, and overall risk posture.\n\n**Record in AssureSwarm**\n- Attach the Security Assessment Report (SAR) document to this step.\n- Record each per-control determination as a row in the SP 800-53A assessment-results matrix attached to this step — assessed Control, cycle year, independent assessor, satisfied/other-than-satisfied result, evidence references, and rationale — and link each row/result package to its Control. Do not represent this non-ICFR assessment as a SOX testing cycle.\n- Create one Issue item per other-than-satisfied control (issue_type=finding or deficiency, source=compliance_review, severity=the finding's risk rating, root_cause), linked to the affected Control item and to the Audit anchor.\n\n**Exit criteria** — SAR complete with a satisfied / other-than-satisfied determination for every assessed control, and every finding carries a risk rating.\n\n> **⚡ Audit Artist accelerator:** `/sox-testing` plans and executes the control tests and `/sox-test` reperforms deterministic checks so each determination is reproducible in a Procedure tab.","label":"ASSESS controls","performedBy":{"primitives":["coach-item-create","coach-document-upload","sox-testing","sox-test"]}},"id":"assess-controls"},{"data":{"decisionField":"disposition_path","description":"Classify the assessment outcome so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"No reportable gap","value":"clean"},{"label":"Remediation required","value":"remediate"},{"label":"Escalate significant issue","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Using the SAR, classify the assessment outcome so the workflow keeps only the relevant closure path. Owned by the system owner and ISSO, with AO visibility.\n\n**Decision criteria**\n- `clean` (No reportable gap): all controls satisfied, or only administrative observations remain, and residual risk sits within the AO's stated tolerance. Route straight to package assembly.\n- `remediate` (Remediation required): one or more other-than-satisfied controls with feasible near-term fixes. A Plan of Action & Milestones (POA&M) is required before the package is complete.\n- `escalate` (Escalate significant issue): high residual risk, a systemic weakness, or risk exceeding the AO's tolerance — requiring a formal risk-acceptance or denial deliberation before proceeding.\n\n**Record in AssureSwarm** — Submit the `disposition_path` SELECT field, and in the step result cite the SAR findings and residual-risk basis for the chosen branch.\n\n**Exit criteria** — The form is submitted and the two unused branches are prunable because branch edge values match the selected value.","kind":"decision","label":"Classify disposition"},"id":"classify-disposition"},{"data":{"description":"Build the POA&M for other-than-satisfied controls","instructions":"**Objective** — Build the Plan of Action & Milestones (POA&M) for every other-than-satisfied control so residual risk is tracked to closure with named owners and dates. The POA&M is not a new item type — it enriches the finding Issues created in ASSESS.\n\n**Inputs**\n- The finding Issue items and their risk ratings (severity) from the ASSESS step.\n- Control owner assignments from the SSP.\n\n**Procedure**\n1. For each finding, confirm the root cause and the affected control, not just the symptom.\n2. Assign an accountable owner and a scheduled completion milestone; break multi-step remediations into interim milestones with dates.\n3. Capture interim mitigations/compensating controls that reduce risk while remediation is in flight.\n4. Define the validation evidence that will close the item (retest, configuration proof) and the reporting cadence to the AO.\n5. State the residual risk that remains until closure so the AO can weigh it in the authorization decision.\n\n**Record in AssureSwarm**\n- Enrich each finding Issue (from ASSESS) into its POA&M entry — set issue_owner, target_remediation_date, and remediation_plan (milestones, interim mitigation, and the closure/validation evidence). Each Issue is already linked to its Control and the Audit anchor.\n- There is no residual-risk field on the Issue; carry the residual-risk statement in remediation_plan (or, for a formally accepted residual risk, on a linked Risk item with treatment=accept).\n\n**Exit criteria** — Every other-than-satisfied finding has an owned POA&M entry with milestones, interim mitigation, and closure evidence defined.","label":"Create action plan","performedBy":{"primitives":["coach-item-create","coach-item-update","coach-items-link"]}},"id":"create-action-plan"},{"data":{"description":"Prepare the escalation or risk-acceptance decision memo for significant issues","instructions":"**Objective** — Prepare the escalation and risk-acceptance decision memo for significant issues, giving the AO a defensible basis to accept, mitigate, or deny.\n\n**Inputs**\n- The SAR findings classified as significant in the disposition decision.\n- The AO's stated risk tolerance and any organizational risk-acceptance policy.\n\n**Procedure**\n1. Quantify the issue: likelihood, impact, affected mission/business functions, and the residual risk after any interim mitigation.\n2. Lay out the options with trade-offs: remediate before authorization, authorize with conditions and a POA&M, formally accept the risk, or deny authorization.\n3. Draft the AO decision memo recommending an option, with the conditions attached to a conditional path.\n4. Define follow-up ownership and the review date for any accepted risk so acceptance does not become permanent by default.\n\n**Record in AssureSwarm**\n- Attach the escalation / risk-acceptance decision memo (DOCX/PDF) to this step.\n- If the recommendation is to accept, create or update a Risk item as the risk-acceptance record — treatment=accept, residual_rating, risk_owner=the AO — and set the follow-up review date noted in the memo.\n- Record the linkage as Item relationships — link the accepted Risk item to the affected finding Issues and Control items.\n\n**Exit criteria** — Decision memo prepared with quantified impact, options, a recommendation, conditions, and follow-up ownership, ready for the AO.","label":"Escalate or accept risk","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Judge aggregate residual risk from the complete SSP/SAR/POA&M package and formally approve or return it with conditions.","formData":{"fields":[{"key":"approval_path","label":"Approve or revise package","options":[{"label":"Approved","value":"approved"},{"label":"Revision required","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge aggregate residual risk from the complete SSP/SAR/POA&M package and formally approve or return it with conditions.\n\n**Inputs**\n- The SSP (SELECT/IMPLEMENT), the SAR (ASSESS), and, depending on the disposition branch, the POA&M (action plan) and/or the risk-acceptance/escalation memo.\n- The AO's authorization-package checklist, if one exists.\n- The assembled authorization package from the package-preparation step.\n- The AO's risk tolerance and organizational risk-management strategy.\n\n**Procedure**\n_This checkpoint absorbs “Prepare final package”, “AUTHORIZE system”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Prepare final package: Assemble the complete authorization package the AO needs to render a risk-based decision — the SSP, SAR, POA&M, risk assessment, and an executive summary — verified against the AO's acceptance checklist.\n2. Compile the core artifacts into one package: SSP, SAR, POA&M, and the risk assessment.\n3. Write an executive summary: system purpose, categorization, overall risk posture, open POA&M items with residual risk, and the recommended authorization outcome.\n4. Include the risk-determination inputs the AO needs — aggregate residual risk and any conditions proposed on the escalation path.\n5. Verify completeness against the AO checklist; a package missing an artifact will bounce at review and burn a decision-calendar slot.\n6. AUTHORIZE system: The authorizing official reviews the package, makes a risk determination, and drafts the authorization decision — ATO, ATO with conditions, or denial (RMF AUTHORIZE, tasks R-1 through R-5).\n7. Review the aggregate residual risk across all controls and open POA&M items — not control-by-control, but the system's overall risk to organizational operations, assets, and individuals.\n8. Make the risk determination: is the residual risk acceptable given mission need and the AO's tolerance?\n9. Select the decision type: full ATO, ATO with conditions (POA&M-bound), interim/time-bound authorization, or denial of authorization.\n10. Draft the authorization decision document: decision, rationale, conditions, and the authorization termination date (or ongoing-authorization terms).\n11. Approve or revise package: Capture the authorizing official's formal action on the authorization package: approve (grant the authorization) or return it for revision. Owned by the AO.\n\n**Decision criteria**\n- `approved`: residual risk is acceptable, the evidence in the SAR is sufficient, and any POA&M adequately governs open items — the AO grants the ATO (with conditions if drafted).\n- `revise`: the package has gaps — insufficient evidence, an inadequate POA&M, unresolved risk analysis, or missing artifacts — and must be reworked before authorization.\n\n**Record in AssureSwarm**\n- Attach the assembled authorization package (PDF/ZIP) to this step.\n- The constituents stay attached at their producing steps (SSP at SELECT/IMPLEMENT, SAR at ASSESS, memo at escalate); link the traceable records — the SAR's per-control SP 800-53A assessment-matrix rows (with their Control references) and the POA&M finding Issues — to the Audit anchor so the package traces back to the record.\n- Attach the draft authorization decision document (DOCX) to this step.\n- At this draft stage the proposed decision has no native field; keep the risk determination and proposed decision type in the draft document — they are finalized onto the Audit anchor at the record-decision step.\nSubmit the `approval_path` SELECT field, and in the step result record the AO's basis and any conditions attached to an approval.\n\n**Exit criteria**\n- Authorization package assembled, executive summary written, and completeness confirmed against the AO checklist.\n- AO risk determination made and the authorization decision drafted with decision type, conditions, and term, ready for the formal approval gate.\n- The form is submitted and the unused branch is prunable because the branch edge value matches the selected value.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the SSP, SAR, POA&M, and executive summary into a single reviewable authorization package.","kind":"decision","label":"Approve or revise package","performedBy":{"primitives":["coach-render-package","coach-document-upload","coach-items-link","coach-item-update"]}},"id":"approve-or-revise-package"},{"data":{"description":"Address the AO's revision comments and conditions before recording the decision","instructions":"**Objective** — Address each of the AO's revision comments and conditions so the authorization package can be re-presented and the decision recorded.\n\n**Inputs**\n- The AO's revision comments and conditions from the approval decision.\n- The authorization package and its constituent artifacts (SSP, SAR, POA&M).\n\n**Procedure**\n1. Log each AO comment/condition as a discrete item so none is dropped.\n2. Resolve each one: add missing evidence, revise the risk analysis, strengthen or re-scope POA&M entries, or update the SSP/SAR as required.\n3. Record what changed for each comment — a reviewer must be able to trace every condition to its resolution.\n4. Update the authorization package with the revised artifacts and confirm it now meets the AO's acceptance checklist.\n\n**Record in AssureSwarm**\n- Update the affected artifacts (SSP/SAR documents, the POA&M finding Issues) and re-attach the revised authorization package to this step.\n- Attach a change-log document mapping each AO condition to its resolution.\n\n**Exit criteria** — Every AO comment/condition is resolved and traceable, and the revised package is ready for the decision to be recorded.","label":"Resolve approval conditions","performedBy":{"primitives":["coach-item-update","coach-document-upload"]}},"id":"resolve-approval-conditions"},{"data":{"description":"Establish active ISCM, POA&M validation and reauthorization triggers under the signed AO decision, preserving and communicating its conditions.","instructions":"**Objective** — Establish active ISCM, POA&M validation and reauthorization triggers under the signed AO decision, preserving and communicating its conditions.\n\n**Inputs**\n- The AO's approval from the approval gate, or the resolved package from the revision path.\n- The drafted authorization decision document from the AUTHORIZE step.\n- The recorded authorization decision with its termination date, and the full authorization package (SSP, SAR, POA&M, signed ATO letter).\n- The per-control continuous-monitoring strategy defined in the SELECT step.\n- The open POA&M items from the action-plan step.\n\n**Procedure**\n_This checkpoint absorbs “Record authorization decision and conditions”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Record authorization decision and conditions: Record the final, signed authorization decision so it is an auditable system-of-record entry: the decision type, its conditions, the AO approval, and the authorization termination (reauthorization) date.\n2. Capture the authorization decision: decision type (ATO, ATO with conditions, interim, or denial), the AO of record, and the decision date.\n3. Record the formal approval: approver identity, signature reference, and the conditions the authorization is bound to (this folds in the final approval-decision recording).\n4. Set the authorization termination date and any ongoing-authorization terms so the expiration is unambiguous.\n5. Attach the signed authorization (ATO) letter and link it to the Audit anchor and the system's Process item.\n6. MONITOR system: Stand up ongoing information security continuous monitoring (ISCM), set the reauthorization triggers so the authorization stays current between formal decisions (RMF MONITOR, tasks M-1 through M-7), and close the cycle by preserving the complete authorization record while monitoring runs on.\n7. Implement ISCM per the monitoring strategy: control-effectiveness monitoring at the defined frequencies, configuration/change management, and vulnerability tracking.\n8. Track POA&M items to closure and validate remediations with the evidence defined when each item was created.\n9. Establish the ongoing security-status reporting cadence to the AO (dashboards and periodic reports).\n10. Set the reauthorization triggers: the authorization termination date, significant-change triggers (major architecture, boundary, or data-type changes), and risk-threshold triggers (a new critical finding or an accepted-risk review date). Schedule the reviews on the decision calendar so a lapse cannot pass unnoticed. When a trigger fires it re-instantiates this same ATO template against the same system Process item — a self-handoff back to PREPARE, not a new workflow.\n11. Archive the authorization package, signed decision, SAR, and POA&M as the system's authorization record of reference.\n12. Update the system inventory with the current ATO status, decision date, and authorization termination date so downstream reporting (e.g., FISMA) reads a single source of truth.\n13. Communicate the authorization decision and any conditions to stakeholders — system owner, AO office, and control owners.\n14. Confirm the monitoring handoff is real before the cycle closes: ISCM is live and the reauthorization triggers are scheduled, so closing does not orphan ongoing oversight.\n\n**Record in AssureSwarm**\n- Record the decision on the Audit anchor — opinion=the ATO decision (unqualified≈full ATO, qualified≈ATO-with-conditions, adverse≈denial), rating, report_date=the decision date.\n- Attach the signed ATO letter (PDF) to this step; there is no native field for the conditions or the authorization-termination date, so keep them in the Audit description and the letter.\n- Attach the ISCM plan document to this step and stand up the monitoring Dashboard (control/Issue security-status reporting for the AO).\n- Track POA&M closure on the open finding Issues (actual_remediation_date, verified_date). Reauthorization-trigger dates and the reporting cadence have no native field — keep them in the ISCM plan document, and the termination date stays on the Audit anchor.\n- Export the authorization record (coach-workflow-export) as the handoff package the next cycle's PREPARE consumes, and archive this workflow instance as the durable audit trail; link the exported record to the Audit anchor and the system's Process item.\n- Set the Audit anchor status to completed and note the ATO status/expiration on the system Process item's description (no native field); send the decision notification to stakeholders.\n\n**Exit criteria**\n- Signed authorization decision recorded on the Audit anchor with approver, conditions, and a termination/reauthorization date preserved in the description and the letter.\n- ISCM active with a reporting cadence to the AO, POA&M tracking live, and reauthorization triggers scheduled; authorization record archived and linked; inventory updated with ATO status/expiration; stakeholders notified — the cycle closes with continuous monitoring confirmed active.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-scan` watches control-effectiveness and POA&M status, `/coach-workflow-export` packages the full authorization record for archive, and `/coach-notify` alerts the AO when a reauthorization trigger fires and distributes the decision to stakeholders.","label":"MONITOR system","performedBy":{"primitives":["coach-item-update","coach-document-upload","coach-workflow-scan","coach-notify","coach-workflow-export"]}},"id":"monitor-system"}],"sourceTemplateId":"workflow-library:controls-rmf-system-authorization-ato"}