{"description":"Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.","edges":[{"id":"e-build-assessment-plan-classify-disposition","source":"build-assessment-plan","target":"classify-disposition"},{"id":"e-classify-disposition-issue-sar","label":"No reportable gap","source":"classify-disposition","target":"issue-sar","whenValue":"clean"},{"id":"e-classify-disposition-create-action-plan","label":"Remediation required","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-re-validate-remediation","source":"create-action-plan","target":"re-validate-remediation"},{"id":"e-re-validate-remediation-issue-sar","source":"re-validate-remediation","target":"issue-sar"},{"id":"e-escalate-or-accept-risk-issue-sar","source":"escalate-or-accept-risk","target":"issue-sar"},{"id":"e-issue-sar-handoff-to-related-workflow","source":"issue-sar","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{"UC-AUDIT-17":"operates","UC-AUDIT-21":"operates","UC-GOV-22":"operates","UC-RISK-14":"operates"},"controls":["UC-AUDIT-21","UC-GOV-22","UC-RISK-14","UC-AUDIT-17","UC-ACCESS-05","UC-ACCESS-10","UC-ACCESS-11","UC-ACCESS-12","UC-ACCESS-13","UC-ACCESS-14","UC-ACCESS-16","UC-ACCESS-19","UC-ASSET-01","UC-ASSET-04","UC-BCDR-04","UC-BCDR-11","UC-BCDR-13","UC-CONFIG-01","UC-CONFIG-03","UC-CONFIG-05","UC-CONFIG-06","UC-CONFIG-07","UC-CONFIG-08","UC-CONFIG-09","UC-CONFIG-10","UC-CRYPTO-01","UC-CRYPTO-04","UC-DATA-11","UC-GOV-09","UC-GOV-19","UC-GOV-25","UC-GOV-29","UC-GOV-30","UC-GOV-31","UC-GOV-32","UC-GOV-34","UC-GOV-35","UC-GOV-36","UC-HR-01","UC-HR-02","UC-HR-04","UC-IR-02","UC-LOG-01","UC-LOG-02","UC-LOG-03","UC-LOG-05","UC-LOG-07","UC-LOG-08","UC-LOG-10","UC-LOG-11","UC-NET-01","UC-NET-02","UC-NET-03","UC-NET-04","UC-NET-05","UC-NET-06","UC-NET-07","UC-NET-08","UC-NET-09","UC-NET-10","UC-NET-11","UC-NET-12","UC-NET-13","UC-NET-14","UC-PHYS-01","UC-PHYS-02","UC-PHYS-03","UC-PHYS-04","UC-PHYS-05","UC-PHYS-06","UC-PHYS-07","UC-PHYS-08","UC-PHYS-09","UC-PHYS-10","UC-PHYS-11","UC-SDLC-11","UC-TPRM-07","UC-TPRM-09","UC-VULN-04","UC-VULN-05","UC-VULN-06","UC-VULN-07","UC-VULN-08","UC-VULN-09","UC-VULN-11","UC-ACCESS-06","UC-ACCESS-18"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-security-assessment-poam-remediation","contentDigest":"sha256:513af45d886c143c166f32c84f2080655a9a78f1376bd2613ac47d412d1bb6c8","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:513af45d886c143c166f32c84f2080655a9a78f1376bd2613ac47d412d1bb6c8","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-security-assessment-poam-remediation"},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"controls-security-assessment-poam-remediation","source":"coworkcanvas-gallery","standards":["nist-800-53"],"teams":["it","compliance-legal"]},"name":"Security Control Assessment & POA&M Remediation","nodes":[{"data":{"description":"Develop and lock the Security Assessment Plan (SAP): scope, control set, methods, objects, and logistics","instructions":"**Objective** — Produce a Security Assessment Plan (SAP) that fixes the control set, assessment methods, assessment objects, and logistics so the assessment is defensible, reperformable, and sized to the system's impact level.\n\n**Inputs**\n- The authorization boundary and FIPS 199 impact level (low / moderate / high): recorded on the anchor Audit — Audit.scope (boundary text) and Audit.description (impact level); the formal categorization memo is uploaded (PBC) to this step. There is no System item type or impact-level field — see the note below.\n- The tailored NIST 800-53 control baseline: existing Control items (framework contains nist-800-53) with family and control_owner; the in-scope set is linked to the engagement via an Audit ↔ Control relationship. Overlay / common-hybrid inheritance tailoring has no Control field — carry it in the SAP methods matrix uploaded to this step.\n- The approved System Security Plan (SSP): uploaded (PBC) to this step from the upstream SSP-development effort — there is no native System/document type.\n- The assessment objective and driver (initial / annual reassessment / targeted): recorded in Audit.scope/description; Audit.audit_type (it_audit or compliance) distinguishes the engagement flavour.\n- Prior SAR and open POA&M items: the prior SAR is the document archived on the prior assessment's workflow instance (or re-uploaded here); open POA&Ms are existing Issue items (issue_type: deficiency / finding) linked to the affected Controls.\n- Reusable examine evidence (config exports, prior penetration-test results, continuous-monitoring findings): uploaded to this step; prior pentest findings may also exist as Issue items (source: penetration_test).\n- The named control owners and system owner for scheduling and interviews: Control.control_owner per control and the assessor lead in Audit.lead_auditor; the system owner has no dedicated field — name it in Audit.description.\n\n**Procedure**\n1. Enumerate the control set in scope: pull the tailored baseline and split into system-specific, common (inherited), and hybrid controls. Mark inherited controls as assessed-by-reference and exclude common controls owned elsewhere — record the provider so coverage is traceable.\n2. For each in-scope control, select 800-53A methods — Examine (documents/artifacts), Interview (personnel), Test (mechanisms/behavior) — and set the attribute depth (basic / focused / comprehensive) from the impact level: moderate and high systems warrant focused-to-comprehensive on access, audit, config, and contingency families.\n3. Identify the assessment objects for each method (specific policies, config files, personnel roles, mechanisms) and map each determination statement (the 800-53A ASSESSMENT OBJECTIVE decomposition) to the object and method that will satisfy it.\n4. Build the logistics: sampling approach for populous controls (e.g., account reviews, change tickets), evidence-request list with owners and due dates, interview schedule, and the test window.\n5. Lock the SAP: confirm final scope, owners, due dates, evidence requirements, and reviewer/approver expectations with the system owner, and freeze the version that execution will run against. Any later scope change is a versioned amendment, not an edit.\n\n**Record in AssureSwarm**\n- Attach the Security Assessment Plan (SAP) to this step as a document — the methods-by-control matrix and evidence-request list (XLSX) plus the SAP narrative (DOCX); note the locked SAP version/date on the step. There is no SAP item type.\n- Update the anchor Audit: Audit.scope (authorization boundary), Audit.description (impact level, driver, and the named system owner), Audit.period_start / Audit.period_end (assessment window), Audit.audit_type (it_audit or compliance), Audit.lead_auditor.\n- Link the in-scope Control items to the engagement via an Audit ↔ Control relationship so coverage is traceable; record inherited/common-control provider attribution in the SAP matrix (no Control inheritance field).\n\n**Exit criteria** — SAP attached and version-locked; every in-scope control has assigned methods, objects, and an owner; inherited/common controls are marked assessed-by-reference with a named provider; evidence-request list issued with due dates.","label":"Build assessment plan"},"id":"build-assessment-plan"},{"data":{"decisionField":"disposition_path","description":"Review statement-level S/OTS determinations and classify the complete assessment into clean, remediation or significant escalation.","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** — Review statement-level S/OTS determinations and classify the complete assessment into clean, remediation or significant escalation.\n\n**Inputs**\n- The locked SAP and its methods-by-control matrix from the assessment-plan step.\n- Collected evidence responsive to the evidence-request list: policies, procedures, configuration exports, screenshots, logs, and prior test evidence (pentest, continuous monitoring) reused as examine artifacts.\n- Interview notes from control owners and operators.\n- The determination-statement decomposition for each control (the 800-53A objective broken into determination statements).\n\n**Procedure**\n_This checkpoint absorbs “Execute determination statements”. 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. Execute determination statements: Execute the SAP against every in-scope control and produce a defensible per-control determination — satisfied or other-than-satisfied — with the evidence and finding that supports it, then record each result in AssureSwarm.\n2. For each control, execute the assigned methods in order: Examine the artifacts, Interview the operators to confirm the control operates as documented, and Test the mechanism where the SAP calls for it. Record the object examined and the date for each.\n3. Evaluate each determination statement independently as Satisfied (S) or Other Than Satisfied (OTS). A control is Satisfied only when every one of its determination statements is Satisfied; a single OTS statement makes the control OTS.\n4. For every OTS statement, write the finding: the exact condition observed, the determination statement it fails, the affected assessment objects, and the risk exposure in plain terms. Do not yet assign remediation — that is the disposition and action-plan steps.\n5. Sample-based controls (account recerts, change management, backups): apply the SAP sampling approach, note the population size and sample size, and treat any exception in the sample as evidence toward OTS for the relevant statement.\n6. Distinguish severity signals for the downstream disposition decision: isolated/low-impact weaknesses vs. systemic or high-impact failures (e.g., a broken access-provisioning control on a high system). Capture that signal in the finding so classify-disposition can be made on evidence.\n7. Cross-check determinations against the control objective: the assessment logic must tie back to what the control is meant to achieve, and no OTS finding may be left without an identified affected object.\n8. Classify disposition: Resolve the overall disposition of the assessment from the recorded determinations so the workflow follows only the relevant closure path. Owned by the assessor lead in concurrence with the system owner.\n\n**Decision criteria**\n- **No reportable gap (`clean`)** — every in-scope control is Satisfied, or the only OTS items are already-remediated-and-revalidated with no residual weakness. Nothing needs a POA&M; proceed straight to issuing the SAR.\n- **Remediation required (`remediate`)** — one or more OTS controls represent tractable weaknesses that need an owned corrective-action plan and POA&M tracking, but do not by themselves warrant escalation. This is the default when OTS findings exist.\n- **Escalate significant issue (`escalate`)** — an OTS finding rises to a significant or high-risk deficiency: a systemic control failure, a high-impact-system safeguard broken with no compensating control, or a weakness the system owner cannot accept within tolerance. Route to escalation / risk-acceptance for a management decision before the package proceeds.\n\n**Record in AssureSwarm**\n- Record every control's determination in the determination register attached to this step (XLSX): control ID, methods applied, object examined, S/OTS result, and evidence reference. There is no per-control assessment-result item type, so Satisfied determinations live only in this register (SOX sox-test is ICFR-per-fiscal-year, not a home for 800-53A determinations).\n- For each OTS control, create an Issue (coach-item-create): issue_type: finding, source: compliance_review, severity from the recorded signal, description = the condition observed and the determination statement it fails plus the affected objects, identified_date; link Issue ↔ the failing Control and Issue ↔ the anchor Audit.\n- Attach the assembled evidence to this step (document upload).\n- Record the Satisfied / Other-Than-Satisfied roll-up (controls assessed, S, OTS) on the step.\nSubmit the `disposition_path` SELECT with the chosen value. In the step result, cite the specific determination records and findings driving the classification (control IDs, severity signal) and name the decision owner/approver. When both remediable and escalation-worthy findings exist, pick `escalate` and list the remediable items so the action plan still captures them downstream.\n\n**Exit criteria**\n- Every in-scope control carries an S or OTS determination traceable to evidence and method; each OTS control has a written finding with affected objects and a severity signal; determination records and evidence are attached; the Satisfied/OTS roll-up is recorded.\n- `disposition_path` is submitted with a cited rationale and named owner; the unpicked branches are prunable because each outgoing edge value matches the selected form value.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"canvas-artist","note":"drafts per-control satisfaction/other-than-satisfied determinations for assessor review and seeds the determination records","primitives":["coach-item-create"]}},"id":"classify-disposition"},{"data":{"description":"Open POA&M items for every gap and collect each accountable owner's milestone commitment and validation evidence through the step form","formData":{"fields":[{"key":"root_cause_agreement","label":"Agreement with the assessed root cause","options":[{"label":"Agreed as assessed","value":"agreed"},{"label":"Alternative root cause — described below","value":"alternative_root_cause"}],"required":false,"type":"select"},{"key":"milestone_plan","label":"Dated remediation milestones (what will be done, by when, by whom)","required":false,"type":"textarea"},{"key":"committed_completion_date","label":"Committed completion date for the corrective action","required":false,"type":"date"},{"key":"interim_mitigation","label":"Interim mitigation or compensating control in force until completion","required":false,"type":"textarea"},{"key":"validation_evidence_committed","label":"Evidence the owner will produce to prove the fix worked","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Convert every OTS finding into a tracked POA&M item with an owned corrective-action plan — root cause, owner, milestones, and validation evidence — so remediation is accountable and auditable.\n\n**Inputs**\n- The OTS determination records and findings from the assessment-execution step (control ID, affected objects, severity signal).\n- Any existing open POA&M items for this system, to avoid duplicates and to update rather than re-open.\n- The system's risk tolerance and remediation-timeline policy (e.g., high findings ≤ 30 days, moderate ≤ 90, low ≤ 180) if one exists.\n\n**Missing-input gate** — Before any form request below, inspect the existing source records, reports and correspondence. Reuse every established fact and record its source. Send a form only when a listed fact remains genuinely unresolved and the named respondent is outside the complete roster of people executing or approving any checkpoint in this workflow. If the respondent is on that roster, record their contribution in native results and approvals. Ask only the unresolved fields; leave known, unasked or inapplicable fields optional and blank. Skip the form entirely when no missing facts remain. Attach evidence documents and record sign-off through native approval. References below to form answers or completion also accept the existing authoritative record or native participant contribution.\n\n**Procedure**\n1. For each OTS finding, open (or update) a POA&M item: assign a POA&M ID, link it to the failing control and determination record, and copy the weakness description and affected objects.\n2. Determine root cause — design gap vs. operating failure vs. missing evidence — because it drives the fix type (implement a control, fix an operation, or document/collect evidence).\n3. Send this step's form to the accountable system or control owner for each POA&M item so the milestone commitment, dates, interim mitigation, and validation evidence come from the party who will do the work; the assessor does not commit dates on the owner's behalf. An `alternative_root_cause` answer is reconciled with the determination record before the item is finalized.\n4. Assign a single accountable owner and a scheduled completion date consistent with the finding's risk (apply the timeline policy above; record the basis if the returned commitment deviates from it).\n5. Define interim mitigation / compensating controls where the fix will take time, and state the residual risk that mitigation leaves.\n6. Specify the validation evidence up front: exactly what artifact or test will prove the fix worked, so re-validation is unambiguous. Set the reporting cadence for status updates.\n7. Reconcile the POA&M set against the OTS roll-up: every OTS finding must map to exactly one open POA&M item — no orphan gaps, no duplicate items.\n\n**Record in AssureSwarm**\n- Enrich each OTS finding's Issue into its POA&M item (coach-item-update): set root_cause, remediation_plan (the corrective action, interim mitigation, the specified validation evidence, and the reporting cadence), issue_owner, and target_remediation_date (risk-based per the timeline policy). The Issue created at execution IS the POA&M item — do not open a duplicate.\n- Where an OTS gap has no Issue yet, create one (coach-item-create) with issue_type: finding (or deficiency), source: compliance_review, and the same fields, linked Issue ↔ failing Control and Issue ↔ anchor Audit.\n- Step form — the form on this step, answered by the accountable system or control owner who will remediate the finding, uses the assigned POA&M reference and owner identity and captures root-cause agreement, the dated milestone plan and committed completion date, interim mitigation, the validation evidence they will produce, with ownership acceptance recorded through native approval; issue_owner, target_remediation_date, and remediation_plan are set from those answers.\n- Extract the POA&M register (XLSX — open items with owners and due dates) to this step for distribution.\n\n**Exit criteria** — Every OTS finding has exactly one open POA&M item with a named owner with recorded acceptance, a risk-based due date, defined interim mitigation, and specified validation evidence; the POA&M set reconciles to the OTS roll-up with no orphans or duplicates.\n\n**Form recipient** — The accountable control remediation owner outside the assessment team supplies only root-cause agreement or alternative; dated milestones and completion date; interim mitigation; validation evidence commitment only when this gate permits the assigned form. The workflow executor records their own analysis in the step result.","label":"Create action plan","performedBy":{"primitives":["coach-item-create","coach-item-update"]}},"id":"create-action-plan"},{"data":{"description":"Re-test remediated POA&M items and update determinations to closed or residual","instructions":"**Objective** — Independently re-test each POA&M item that the owner reports remediated and update its determination to Satisfied (closed) or keep it Other Than Satisfied with a documented residual, so the SAR reflects true post-remediation status.\n\n**Inputs**\n- Open POA&M items marked ready-for-validation by their owners, with the corrective action taken.\n- The validation-evidence specification recorded on each POA&M item at creation.\n- Fresh evidence of the fix: updated configs, new access reviews, re-run test output, or updated procedures.\n\n**Procedure**\n1. For each ready POA&M item, re-apply the same 800-53A method that produced the original OTS — do not accept a self-attestation where the original finding required a Test. Re-examine or re-test against the validation evidence specified at creation.\n2. Confirm the fix addresses the root cause, not just the observed symptom: a re-provisioned account does not close a broken provisioning control unless the process control itself is fixed.\n3. If the evidence proves the determination statement now passes, flip the control/statement to Satisfied and close the POA&M item with the validation evidence attached and the closure date.\n4. If the fix is partial, keep the item open with an updated milestone, or accept a documented residual risk only with the disposition owner's concurrence — record which.\n5. Re-run the roll-up: recompute Satisfied vs. still-OTS after validation so the SAR and final package carry post-remediation numbers, not the original assessment numbers.\n\n**Record in AssureSwarm**\n- Update each validated POA&M Issue: on a pass, set Issue.actual_remediation_date and Issue.verified_date and move its status to closed; on a partial fix, keep it open with an updated target_remediation_date and note the residual in remediation_plan.\n- Attach the fresh validation evidence to this step (document upload); update the determination register attached here with the S/OTS flip.\n- Record the post-remediation Satisfied / OTS roll-up on the step.\n\n**Exit criteria** — Every ready POA&M item is re-tested with the original method and marked closed-with-evidence or open-with-updated-milestone/documented-residual; determination records reflect post-remediation status; the updated roll-up is recorded.","label":"Re-validate remediation"},"id":"re-validate-remediation"},{"data":{"description":"Escalate a significant deficiency for a management risk-acceptance or risk-treatment decision","instructions":"**Objective** — Bring a significant or high-risk deficiency to the accountable authority (control owner, assessor lead, system owner, or authorizing official) and secure a documented decision to treat, transfer, or formally accept the risk before the package proceeds.\n\n**Inputs**\n- The OTS determination record(s) and findings flagged significant by the disposition decision, with severity signal and affected objects.\n- The system's risk-tolerance statement and any related enterprise-risk register entries.\n- Cost/effort and timeline estimates for the candidate remediation options.\n\n**Procedure**\n1. Draft a decision memo: state the deficiency, the failing control and determination statement, the affected assets/objects, and the exposure in impact terms (confidentiality/integrity/availability and business consequence).\n2. Quantify the risk: likelihood and impact given any compensating controls already in place, and the residual risk under each option (remediate now, remediate with interim mitigation, or accept).\n3. Present the treatment options with cost, effort, and timeline so the authority can choose on a like-for-like basis.\n4. Route to the correct authority by severity: assessor lead / system owner for most significant findings; the authorizing official when the decision affects the authorization or requires formal risk acceptance.\n5. Capture the decision: the option chosen, any conditions or time limits, the accepting authority, the date, and the follow-up owner. A risk acceptance must have an expiry/review date, not be open-ended.\n\n**Record in AssureSwarm**\n- Attach the signed decision memo (DOCX/PDF) to this step, stating the outcome (treat / interim-mitigate / accept), accepting authority, conditions, and expiry/review date.\n- For an accepted risk, set treatment: accept on the Risk item (residual_rating, risk_owner) and link Risk ↔ the failing Control; then record the acceptance as an Issue — issue_type: policy_exception, exception_approver = the accepting authority, exception_expiry_date = the review/expiry date — and link Issue ↔ the Risk and Issue ↔ the failing Control. The policy_exception Issue is the home for the accepting authority and the expiry/review date; do not squat them in Risk.description.\n- For a treatment decision, ensure the failing finding's POA&M Issue exists (create via the action-plan path if not) and carries the chosen milestone in target_remediation_date; capture the decision on the Issue's management_response / remediation_plan.\n\n**Exit criteria** — A signed decision memo exists with a named accepting authority, chosen treatment, conditions, and an expiry/review date; every escalated finding has either an open POA&M item or a time-bounded accepted-risk record; nothing significant is left undecided.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"description":"Issue the reconciled post-remediation SAR and freeze a complete assessment package with explicit residuals, constraints and reuse boundaries.","instructions":"**Objective** — Issue the reconciled post-remediation SAR and freeze a complete assessment package with explicit residuals, constraints and reuse boundaries.\n\n**Inputs**\n- The full set of determination records at their post-validation status (from execution and re-validation).\n- The open/closed POA&M items and any accepted-risk records from the action-plan and escalation paths.\n- The locked SAP (to state scope and methods) and the disposition decision rationale.\n- The issued SAR and its linked determination records.\n- The open/closed POA&M items and any accepted-risk records.\n- The locked SAP, the assembled evidence, and the disposition and escalation decision memos.\n\n**Procedure**\n_This checkpoint absorbs “Prepare final package”. 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. Issue SAR: Issue the Security Assessment Report (SAR): the assessor's formal statement of each control's post-remediation determination, the findings, the open POA&M items, and the assessor's overall conclusion on the system's security posture.\n2. Assemble the control-by-control results table: control ID, methods applied, final S/OTS determination, and evidence reference. Use post-remediation status so closed items show Satisfied and residuals show OTS-with-POA&M.\n3. Write the findings section: one entry per residual OTS control with condition, root cause, affected objects, risk, and the linked open POA&M ID and due date.\n4. Summarize the POA&M schedule: count of open items by severity and their committed completion dates, plus any accepted-risk decisions with expiry dates.\n5. Write the assessor conclusion: an overall statement of residual risk and whether the control implementation supports the intended operation, keyed to the impact level. This is the assessor's professional judgment, not an authorization decision.\n6. Version and date the SAR, and confirm it reconciles to the recorded roll-up (Satisfied + residual-OTS counts must tie to the determination records).\n7. Prepare final package: Compile the complete, self-consistent assessment package — SAR, POA&M, evidence index, and decision record — so it is ready to hand to the authorization process with nothing left to reconstruct.\n8. Build the package manifest: SAP (scope/methods), SAR (results/conclusion), POA&M register (open items with owners/dates), evidence index (each determination's supporting artifacts), and the decision record (disposition + any risk acceptances).\n9. Run the consistency check across artifacts: SAR counts tie to determination records; every residual OTS in the SAR has a matching open POA&M; every accepted risk has a memo and expiry; no evidence reference is broken.\n10. Capture unresolved constraints and assumptions explicitly (inherited-control reliance, evidence not yet available, interim mitigations in force) so the downstream authorization does not rediscover them.\n11. State the proposed conclusion and what the downstream authorization process should NOT repeat (already-validated controls, closed POA&M items).\n12. Freeze the package version and confirm access for the receiving parties.\n\n**Record in AssureSwarm**\n- Attach the Security Assessment Report (DOCX/PDF, versioned) to this step; there is no SAR item type — the report is a step document with its version/date and the S/residual-OTS/open-POA&M/accepted-risk counts noted on the step.\n- Update the anchor Audit: Audit.rating (the assessor's overall conclusion — satisfactory / needs_improvement / unsatisfactory), Audit.report_date (SAR date), Audit.opinion: na (a control assessment is not an audit opinion).\n- The SAR references the engagement's Issue (POA&M) items and the determination register already linked to the anchor Audit; confirm the Satisfied + residual-OTS counts reconcile to those records.\n- Assemble and attach the frozen authorization package (ZIP/PDF with its manifest) to this step; note the package version/date on the step. There is no package item type.\n- The manifest indexes the anchor Audit and its linked Control, Issue (POA&M), and Risk (accepted-risk) items — confirm each reference resolves.\n- Record the open-POA&M count, unresolved-constraint count, and proposed conclusion in the manifest on this step.\n\n**Exit criteria**\n- SAR issued, versioned, and attached; the results table covers every in-scope control at post-remediation status; each residual OTS ties to an open POA&M or accepted-risk record; the assessor conclusion is stated; SAR counts reconcile to the determination roll-up.\n- Package assembled and version-frozen with a complete manifest; cross-artifact consistency check passes with no orphan findings or broken references; unresolved constraints and reuse notes documented; proposed conclusion stated.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — assembles the control-results table, findings, and POA&M schedule into the formatted SAR document for assessor sign-off. `/coach-render-package` — compiles the SAP, SAR, POA&M, evidence index, and decisions into a single versioned authorization package.","label":"Issue SAR","performedBy":{"primitives":["coach-render-package"]}},"id":"issue-sar"},{"data":{"description":"Hand the assessment package to the NIST RMF System Authorization (ATO) Cycle, then close the assessment on the acknowledged receipt: archive the record, schedule POA&M and accepted-risk follow-ups, and notify stakeholders","instructions":"**Objective** — Transfer the frozen assessment package to the NIST RMF System Authorization (ATO) Cycle so the authorizing official can make an authorization decision without re-deriving assessment results, and close the assessment on the downstream owner's acknowledged receipt.\n\n**Inputs**\n- The version-frozen final package (SAP, SAR, POA&M, evidence index, decision record) from the issue-sar step.\n- The list of unresolved constraints, assumptions, and reuse notes recorded on the package.\n- The receiving contact/queue for the NIST RMF System Authorization (ATO) Cycle.\n- Open POA&M items with committed completion dates and any accepted-risk records with review/expiry dates.\n- The stakeholder distribution list (system owner, control owners, assessor lead, authorizing official).\n\n**Procedure**\n_Items 1–5 transfer the package; items 6–9 close the workflow (folded from the former \"Close and archive\" step) — the acknowledged handoff recorded here is the closure, with no separate confirmation._\n1. Create or locate the downstream NIST RMF System Authorization (ATO) Cycle instance and link it to this workflow so the lineage is traceable both directions.\n2. Pass the frozen package by reference (link the package record and its artifacts) rather than copying, so the ATO process reads the authoritative version.\n3. Write the handoff note: the proposed conclusion, the open POA&M schedule the authorizing official must weigh, accepted risks with expiry dates, and explicit assumptions.\n4. State what the downstream process should NOT repeat — already-validated controls and closed POA&M items — to prevent duplicated assessment effort.\n5. Confirm receipt: verify the downstream owner has access and has acknowledged the handoff.\n6. Verify closure preconditions: SAR issued, package handed off and acknowledged, and every OTS finding resolved to a closed item, an open POA&M with an owner/date, or a time-bounded accepted risk. Do not close over an unowned gap.\n7. Archive the complete record read-only: SAP, SAR, POA&M register, evidence index, and decision memos, with retention set per policy so the trail is reproducible on later review.\n8. Schedule the follow-ups: POA&M milestone check-ins on their committed cadence, accepted-risk reviews at their expiry dates, and the next reassessment window per the monitoring policy.\n9. Communicate the outcome — send the final decision summary and open-item schedule to stakeholders — and mark the workflow closed with the archive location and follow-up schedule recorded.\n\n**Record in AssureSwarm**\n- Link the downstream NIST RMF System Authorization (ATO) Cycle instance to the anchor Audit item so the lineage is traceable both directions, and reference the frozen package attached at issue-sar.\n- Record the handoff date, receiving owner, and acknowledgment on this workflow instance, then set the instance to closed with the archive reference, retention date, and follow-up schedule as the run's audit trail.\n- Attach or link the archived package (document link) and record the stakeholder notification on the step. POA&M milestone follow-ups already live on each open Issue's target_remediation_date, and accepted-risk reviews on the Risk memo's expiry date.\n\n**Exit criteria** — Downstream ATO workflow linked and given access to the frozen package; handoff note with open-POA&M schedule, accepted risks, and reuse boundaries delivered and receipt acknowledged by the downstream owner; closure preconditions verified; complete record archived read-only with a retention date; POA&M check-ins, accepted-risk reviews, and next reassessment scheduled; stakeholders notified; workflow marked closed.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` — sends the handoff note, final decision summary, and open-POA&M schedule to the downstream owner and the stakeholder distribution list on close.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-notify"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:controls-security-assessment-poam-remediation"}