{"description":"This review runs on an Audit engagement item created for the review cycle (audit_type: it_audit; scope: the identity assurance boundary) — the workflow instance attaches to that Audit, and the five in-scope UC-ACCESS Control items (UC-ACCESS-07/08/09/11/12) link to it. It is self-originating: no upstream workflow feeds it — it starts from the review trigger, the governing controls, and the collected evidence. Review the IAL, AAL, and FAL assurance requirements against the current identity proofing, authentication, and federation controls for the in-scope systems, then remediate, document, and hand off open gaps. It produces the target-level register, the current-state control inventory, the scored gap register, the per-control assurance determination memo, and the compiled assurance review package; each open gap is recorded as an Issue (POA&M) item linked to its UC-ACCESS Control and the anchor Audit. In scope: NIST SP 800-63 identity assurance levels for the systems named in the locked workplan. Out of scope: broader access provisioning, joiner-mover-leaver lifecycle, and privileged-access certification. Hands off the assurance determination and any open POA&M items to the Security Control Assessment and POA&M Remediation workflow.","edges":[{"id":"e-determine-target-assurance-levels-classify-disposition","source":"determine-target-assurance-levels","target":"classify-disposition"},{"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-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"clean"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-escalate-or-accept-risk-handoff-to-related-workflow","source":"escalate-or-accept-risk","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ACCESS-07","UC-ACCESS-08","UC-ACCESS-09","UC-ACCESS-11","UC-ACCESS-12"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-identity-assurance-review","contentDigest":"sha256:356c43deb1a22a13525cc411a881fc72d7a28eff0443a514ded9c6c5444bd201","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:356c43deb1a22a13525cc411a881fc72d7a28eff0443a514ded9c6c5444bd201","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-identity-assurance-review"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"controls-identity-assurance-review","source":"coworkcanvas-gallery","standards":["nist-800-53"],"teams":["it"]},"name":"Identity Assurance Review","nodes":[{"data":{"description":"Agree the identity boundary and evidence plan, then determine risk-based IAL, AAL and FAL targets and justified deviations.","instructions":"**Objective** — Agree the identity boundary and evidence plan, then determine risk-based IAL, AAL and FAL targets and justified deviations.\n\n**Inputs**\n- Assessment objective and trigger: why the review runs now (periodic monitoring cycle, audit finding, new or migrated system, authentication incident, IdP change).\n- System boundary: the applications, relying parties, identity providers, and credential services in scope, each with user population (public, partner, workforce, privileged), data sensitivity, and impact categorization (low, moderate, high, or the org equivalent).\n- Control baseline: the NIST SP 800-53 IA family (IA-1 through IA-12) and the unified controls this review covers (UC-ACCESS-07, UC-ACCESS-08, UC-ACCESS-09, UC-ACCESS-11, UC-ACCESS-12) — each already a Control item (`control_id`, `framework`: nist-800-53, `family`: IA, `domains`: access_control_identity).\n- Evidence sources: identity-proofing procedures, IdP and IAM configuration exports, MFA and authenticator policy, session and reauthentication settings, federation trust config (SAML or OIDC metadata), and the prior review determination plus open POA&M items.\n- Control owners (on `Control.control_owner` per UC-ACCESS Control item), evidence custodians, the system owner, and the authorizing official (custodians/owner/AO named in the workplan document — no native people/role type). The prior review determination is the previous cycle's workflow instance (archived package on its prior Audit item); the open POA&M items are existing Issue items linked to these Controls. This review has no upstream workflow feeding it; it starts directly from these inputs.\n- The locked workplan scope table (system, population, data sensitivity, impact categorization).\n- NIST SP 800-63-3 xAL selection guidance and the organization's digital identity risk assessment (DIRA) method, if one exists.\n- Regulatory or contractual assurance obligations (agency mandate, PCI DSS, HIPAA, partner federation agreements) that floor the target.\n\n**Procedure**\n_This checkpoint absorbs “Lock executable workplan”. 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. Lock executable workplan: Restate the trigger and objective in one sentence and record whether this is a full-scope review or a targeted one (for example, only AAL after an MFA policy change).\n2. Enumerate in-scope systems in a table: system name, role (relying party, identity provider, credential service), user population, data sensitivity, and impact categorization.\n3. State what is explicitly out of scope and why (for example, provisioning lifecycle and joiner-mover-leaver handled elsewhere, privileged-access certification reviewed separately) so scope does not creep during fieldwork.\n4. For each in-scope system, name the accountable control owner and evidence custodian and set an evidence-due date.\n5. Assemble the per-system evidence request: proofing procedure, authenticator and MFA policy plus enforcement config, session and reauthentication settings, federation trust config and assertion protections, and the prior review determination with open POA&M items.\n6. Define the review checkpoints and who signs each off: target-level determination, gap register, disposition, and final package.\n7. Confirm the mapping from findings to the unified controls (UC-ACCESS-07, UC-ACCESS-08, UC-ACCESS-09, UC-ACCESS-11, UC-ACCESS-12) so every result ties back to the control library.\n8. Determine target assurance levels: For each system, rate impact across the NIST SP 800-63-3 categories — inconvenience or distress; financial loss; organizational harm; harm to programs or the public interest; unauthorized information release; personal safety; and civil or criminal violations — as Low, Moderate, or High.\n9. Map proofing impact to target IAL: no need to link to a real-world identity means IAL1; remote or in-person proofing of a claimed identity at moderate impact means IAL2; high impact requiring in-person or supervised remote proofing with biometrics means IAL3.\n10. Map authentication impact to target AAL: single-factor acceptable means AAL1; multi-factor with approved, replay-resistant authenticators means AAL2 (the baseline for anything nontrivial); hardware-based, verifier-impersonation-resistant, phishing-resistant means AAL3.\n11. For federated systems, map assertion protection to target FAL: a bearer assertion signed by the IdP means FAL1; an assertion also encrypted to the relying party means FAL2; a holder-of-key assertion bound to an authenticator means FAL3.\n12. Record any documented deviation where a compensating control lets a lower level stand, and cite the risk-acceptance basis.\n13. Produce the target-level register: one row per system with target IAL, AAL, and FAL and the impact-rating rationale behind each.\n\n**Record in AssureSwarm**\n- Open the anchor Audit item for this review cycle and set `Audit.audit_type`: it_audit, `Audit.description` (objective and trigger), `Audit.scope` (the identity assurance boundary), `Audit.lead_auditor`, and `Audit.period_start`/`Audit.period_end`.\n- Attach the workplan document to this step: scope table, out-of-scope statement, owners, evidence list, and due dates. The in-scope systems live in this scope table — no System/Asset item type exists, so they have no item of their own.\n- Link the five UC-ACCESS Control items (UC-ACCESS-07, UC-ACCESS-08, UC-ACCESS-09, UC-ACCESS-11, UC-ACCESS-12) to the anchor Audit; each already carries `Control.control_owner`, `Control.framework`: nist-800-53, and `Control.domains`: access_control_identity.\n- Attach the target-level register (XLSX) and the DIRA worksheet to this step — these are the register's home.\n- The per-system target IAL, AAL, and FAL live only in that register document: no System/Asset item type exists, so there are no system items to set target fields on.\n\n**Exit criteria**\n- Scope table finalized with owners and impact categorization; out-of-scope stated; evidence request issued with due dates; checkpoints and sign-offs named; controls linked.\n- Every in-scope system has a target IAL, AAL, and FAL with documented impact ratings; deviations cite a risk basis; the register is attached.","label":"Determine target assurance levels"},"id":"determine-target-assurance-levels"},{"data":{"decisionField":"disposition_path","description":"Judge tested identity enforcement, report reliability, target gaps and per-control determinations to select clean, remediation or significant-risk 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** — Judge tested identity enforcement, report reliability, target gaps and per-control determinations to select clean, remediation or significant-risk escalation.\n\n**Inputs**\n- The locked workplan scope table and the issued evidence request.\n- Collected evidence: identity-proofing procedures, IdP and IAM configuration exports, MFA and authenticator policy plus enforcement config, session and reauthentication settings, and federation trust config (SAML or OIDC metadata, assertion signing and encryption).\n- The target-level register (from Determine target assurance levels).\n- The current-state control inventory (from Assess current identity controls). This step needs both reviewed outputs before it can start.\n- The scored gap register (from Gap-analyze assurance).\n- The target-level and current-state registers and their evidence exhibits.\n\n**Procedure**\n_This checkpoint absorbs “Assess current identity controls”, “Gap-analyze assurance”, “Document assurance decision”. 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. Assess current identity controls: Proofing (IAL): document how identities are verified before a credential is issued — evidence collected, validation source, remote versus in-person, biometric use — and cite the evidence artifact for each system.\n2. Authentication (AAL): record the authenticator types in use (passwords, OTP, push, FIDO2 or WebAuthn, PKI), whether MFA is enforced and for which populations, replay and phishing resistance, and reauthentication and session-timeout settings.\n3. Federation (FAL): for each federated system, record the assertion protocol, whether assertions are signed and whether they are encrypted, audience restriction, assertion lifetime, and holder-of-key versus bearer.\n4. Test enforcement rather than reading policy alone: sample accounts and config to confirm MFA is genuinely required — no legacy-authentication bypass, no conditional-access exclusions left open — and capture the test evidence.\n5. Note information-produced-by-the-entity dependencies: if MFA-coverage figures come from an IdP report, confirm that report's completeness and accuracy before relying on it.\n6. Produce the current-state control inventory: one row per system per assurance dimension, showing the implemented control and its evidence reference.\n7. Gap-analyze assurance: Join the two registers by system and assurance dimension so every row shows target versus implemented for IAL, AAL, and FAL.\n8. Score each cell: Meets (implemented at or above target), Gap (implemented below target), or Over-provisioned (implemented above target — note for efficiency, not a finding).\n9. For each Gap, state the shortfall precisely, for example \"AAL2 required but only single-factor enforced for the partner population\" or \"FAL2 required but assertions are signed and not encrypted to the relying party\".\n10. Rate each gap's risk from the system's impact categorization and the size of the shortfall — for example, AAL1 against an AAL3 target on a high-impact system is a High-risk gap.\n11. Identify compensating controls that reduce residual risk and note whether each fully or partially closes the gap.\n12. Assign a preliminary POA&M identifier and a candidate owner to each open gap.\n13. Produce the gap register with columns: system, dimension, target, implemented, status, shortfall, risk rating, compensating control, POA&M ID, and owner.\n14. Document assurance decision: For each control (UC-ACCESS-07, UC-ACCESS-08, UC-ACCESS-09, UC-ACCESS-11, UC-ACCESS-12) and system, write a determination statement: control objective, method used (inquiry, observation, inspection, or reperformance), the evidence inspected, and the result (Satisfied or Other Than Satisfied).\n15. Ensure the determination logic ties to the control objective — do not restate the test steps; state whether the objective is achieved and why.\n16. Summarize residual risk across the boundary: which populations and systems fall short of target and the aggregate exposure.\n17. List every open gap with its POA&M identifier, owner, and retest requirement, so no gap is left without accountable remediation.\n18. Draft a recommended overall conclusion (meets target assurance, meets with remediation, or does not meet) to feed the disposition decision — do not finalize it here.\n\n**Decision criteria**\n- **clean (No reportable gap):** every control's determination is Satisfied — implemented assurance meets or exceeds the target IAL, AAL, and FAL for all in-scope systems — and any over-provisioning carries no risk. No open POA&M items of consequence remain.\n- **remediate (Remediation required):** one or more gaps exist that are correctable through an owned action plan within normal timelines (for example, enabling AAL2 MFA for a population, or encrypting federation assertions to reach FAL2) and that do not on their own warrant authorizing-official escalation.\n- **escalate (Escalate significant issue):** a gap represents significant residual risk to a high-impact system (for example, AAL1 where AAL3 is required, or unverified identities at IAL1 for high-impact access), a systemic failure, or a condition the authorizing official must accept or act on before the system continues operating.\n\n**Record in AssureSwarm**\n- Attach the current-state inventory (XLSX) to this step, and upload the evidence exhibits (config exports, MFA/authenticator policy, session settings, federation metadata) as PBC/external uploads on this step.\n- The per-system current-state findings live in the inventory document — with no System/Asset item type, there are no system items to attach evidence to or to set current-state fields on.\n- Attach the gap register (XLSX) to this step.\n- Create one Issue (POA&M) item per open gap — `issue_type`: deficiency, `source`: compliance_review, `description`: the precise shortfall statement, `severity`: the gap's risk rating, `root_cause`, `issue_owner`, `identified_date`; carry the POA&M identifier as a title prefix (for example \"POAM-2026-014: …\") since Issue has no POA&M-ID field.\n- Link each Issue to the affected UC-ACCESS Control item (Issue ↔ Control) and to the anchor Audit (Issue ↔ Audit); with no System type, the affected system is named in the register and the shortfall statement, not a linked item.\n- Attach the assurance determination memo (DOCX/PDF) to this step — the per-control, per-system Satisfied / Other Than Satisfied determinations live in this memo, because Control has no determination or test-result field.\n- Keep each Issue (POA&M) item's links to its UC-ACCESS Control and the anchor Audit current. The recommended overall conclusion is drafted here for the decision and rolls up to `Audit.rating` (satisfactory | needs_improvement | unsatisfactory) at close — do not finalize it now.\n- Submit this step's decision form: `disposition_path` (clean, remediate, or escalate).\n- Record the step result (decision rationale and evidence references) and the step's approver record (the decision owner or approver).\n\n**Exit criteria**\n- Proofing, authentication, and federation controls documented per system with cited evidence; MFA enforcement tested rather than only policy-read; report dependencies noted; inventory attached.\n- Every target-versus-implemented pair scored; each gap has a precise shortfall statement, a risk rating, and a candidate owner; compensating controls noted; gap register attached and POA&M items created.\n- Each control and system has a determination statement tied to its objective with cited evidence; residual risk is summarized; every gap carries a POA&M ID, owner, and retest requirement; a recommended conclusion is drafted for the decision.\n- The `disposition_path` form is submitted with rationale and owner; the two unused branches are prunable because the selected value matches exactly one outgoing branch.\n\n> **⚡ Audit Artist accelerator:** `/coach-query-data` pulls the IdP and IAM configuration and MFA-coverage extracts into this step so enforcement can be tested against the live population, not just the written policy.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-query-data"]}},"id":"classify-disposition"},{"data":{"description":"Build the owned action plan that closes each assurance gap and defines how each fix will be validated","instructions":"**Objective** — On the remediation path, build the owned action plan that closes each identified assurance gap and defines how each fix will be validated before the control is considered restored.\n\n**Inputs**\n- The gap register and the assurance determination memo (open gaps, POA&M IDs, risk ratings).\n- Control-owner input on feasible target designs and timelines.\n\n**Procedure**\n1. For each open gap, state the root cause — policy absent, configuration drift, a population excluded from enforcement, an unsupported authenticator, or missing assertion protection — not merely the symptom.\n2. Define the target remediation design that reaches the required level: enforce phishing-resistant MFA (FIDO2 or WebAuthn) to reach AAL2 or AAL3; strengthen identity proofing to reach IAL2; enable assertion encryption and audience restriction to reach FAL2.\n3. Assign an accountable owner, a due date, and an interim mitigation or compensating control to hold residual risk until the fix lands — for example, restricting the affected population or requiring step-up authentication.\n4. Record the reporting cadence and the POA&M linkage so status is trackable to closure.\n5. Define the validation and retest plan for each remediation: the exact evidence that will prove the target level is met (a configuration export showing enforcement, a re-tested MFA-coverage extract, a signed and encrypted assertion sample), the reperformance method, and the acceptance threshold.\n6. Where a change has already been implemented during the review, reperform the test now and record whether the target level is met: if met, mark the gap ready-to-close pending final review; if not, keep it open with the residual noted.\n7. Assemble the action plan with columns: gap, root cause, target design, owner, due date, interim mitigation, validation method, and current status.\n\n**Record in AssureSwarm**\n- Attach the action plan (XLSX/DOCX) and any completed retest evidence to this step.\n- Update each Issue (POA&M) item with the fix: `remediation_plan` (target design and validation method), `management_response`, `issue_owner`, and `target_remediation_date`; for gaps retested and closed during the review, set `actual_remediation_date` and `verified_date`. The Issue ↔ Control and Issue ↔ Audit links already exist; the affected system stays named in the plan (no System item).\n\n**Exit criteria** — Every open gap has a root-caused action plan with owner, due date, interim mitigation, and a defined validation method; any already-implemented fixes are retested with evidence and their status updated; POA&M items are current.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Prepare the decision memo that routes a significant issue for remediation or formal risk acceptance","instructions":"**Objective** — On the escalation path, prepare the decision memo that brings the significant identity-assurance issue to the control owner, assessor lead, system owner, or authorizing official for a remediate-or-accept-risk decision.\n\n**Inputs**\n- The gap register and the assurance determination memo (the significant gap or gaps, risk ratings, and affected high-impact systems).\n- The organization's risk-acceptance and authorization policy: who may accept residual risk and on what terms.\n\n**Procedure**\n1. State the significant issue precisely: the control, the system, target versus implemented level, the population affected, and why it exceeds normal remediation (impact categorization combined with shortfall size).\n2. Quantify the residual risk and the exposure window: what a mis-proofed user or an attacker could do, and how long the exposure persists without action.\n3. Present the options: expedited remediation with its cost and timeline, compensating controls, or formal risk acceptance with conditions and an expiry.\n4. Route to the correct authority per policy — issues affecting a high-impact system or its authorization go to the system owner or authorizing official; others go to the control owner or assessor lead.\n5. Capture the decision: if risk is accepted, record the accepting official, the conditions, the monitoring trigger, and the expiry or re-review date; if remediation is chosen, hand the specifics to the action plan.\n6. Ensure any accepted risk is logged as an open POA&M item with an owner and a follow-up date — accepted is not closed.\n\n**Record in AssureSwarm**\n- Attach the escalation and risk-acceptance decision memo (DOCX/PDF) to this step.\n- On formal risk acceptance, record it on the affected Issue (POA&M) item: `exception_approver` (the accepting official), `exception_expiry_date` (the expiry / re-review date), and `management_response` (the decision and its conditions); the Issue stays open — accepted is not closed. Where a register Risk exists for the accepted exposure, set `Risk.treatment`: accept and `Risk.residual_rating` on the linked Risk (Issue ↔ Risk). The Issue ↔ Control link already exists.\n\n**Exit criteria** — The significant issue is documented with quantified residual risk; a routed decision is recorded (remediate, or accept with conditions and expiry); accepted risk carries an owner and a follow-up date; nothing significant is left undecided.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"description":"Accept ownership of the evidence-referenced assurance determination and open POA&M items, with a clear validity window and scope that prevents duplicated assessment.","instructions":"**Objective** — Accept ownership of the evidence-referenced assurance determination and open POA&M items, with a clear validity window and scope that prevents duplicated assessment.\n\n**Inputs**\n- The assurance determination memo and the gap register.\n- Whichever closure artifact applies: the action plan (remediate path), the escalation and risk-acceptance memo (escalate path), or the clean determination (no reportable gap).\n- All evidence exhibits and the target-level and current-state registers.\n- The compiled final package (from Prepare final package) and all evidence exhibits.\n- The identifier or instance of the downstream Security Control Assessment and POA&M Remediation workflow; create it if it does not yet exist for this system boundary.\n- The organization's records-retention schedule and the monitoring cadence for identity controls.\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. Prepare final package: Assemble the package contents: objective and scope, target-level register, current-state inventory, gap register, assurance determination, disposition and rationale, and the applicable closure artifact.\n2. Confirm every determination cites its evidence and every open gap has a POA&M ID, owner, and retest requirement — no orphan findings.\n3. Reconcile the disposition: the package conclusion must match the submitted `disposition_path` value and the state of the POA&M items.\n4. List unresolved constraints and assumptions explicitly (evidence not yet received, deferred retests) so the downstream workflow does not have to re-derive them.\n5. State what the downstream Security Control Assessment and POA&M Remediation workflow should consume and should not repeat — namely the assurance determination and the open POA&M items — so work is not duplicated.\n6. Produce a proposed final conclusion for the record.\n7. Handoff to related workflow: Create or locate the downstream Security Control Assessment and POA&M Remediation workflow instance for this system boundary.\n8. Attach or link the final package and the open POA&M items to the downstream workflow.\n9. Write the handoff note: what the downstream workflow should act on (open POA&M remediation, retests, authorization impact) and what it must not repeat (the assurance-level determination and the evidence already gathered here).\n10. Record any assumptions and the assurance determination's validity window, so the downstream owner knows when a re-review becomes due.\n11. Confirm receipt and ownership on the downstream side — a named owner acknowledges the handoff.\n12. Verify the package is complete and that the disposition, determinations, and POA&M items are consistent before locking the record.\n13. Archive the final package and all evidence exhibits to the retention location per the records schedule, and set records to read-only where the platform supports it.\n14. Update the linked control records (UC-ACCESS-07, UC-ACCESS-08, UC-ACCESS-09, UC-ACCESS-11, UC-ACCESS-12) with the final determination and the review date; with no System/Asset item type, the per-system results stay in the archived package, not on system items.\n15. Schedule the next review or continuous-monitoring trigger — for example, a re-review on an authentication policy change, an IdP migration, or the assurance determination's expiry — and set follow-up dates on any open POA&M items.\n16. Communicate the final decision to the control owners, the system owner, and the authorizing official, confirming the downstream workflow is engaged for any open remediation.\n\n**Record in AssureSwarm**\n- Attach the compiled final package (PDF/ZIP) to this step — it is the durable home for the per-control determinations and per-system results (no Control-determination or System field).\n- Confirm each Issue (POA&M) item and its Issue ↔ Control and Issue ↔ Audit links are current and reconcile to the package.\n- Link this review's final package to the downstream Security Control Assessment and POA&M Remediation workflow instance, then mark this workflow instance complete and attach or confirm the archived package — the workflow instance on the anchor Audit is the durable audit trail.\n- There is no native handoff field: record the downstream workflow reference, the handoff owner, and the act-on vs do-not-repeat scope note in the handoff note attached to this step. The open Issue (POA&M) items carry across via their existing Issue ↔ Control links.\n- Record the outcome on the anchor Audit: `Audit.rating` (final determination), `Audit.report_date`, and `Audit.fieldwork_start`/`Audit.fieldwork_end`. Control has no last-review/next-review field, so the next monitoring cycle is the next workflow instance; confirm follow-up dates on each open `Issue.target_remediation_date` (or `Issue.exception_expiry_date` for accepted items).\n\n**Exit criteria**\n- Package assembled with all registers, the determination, the disposition, and the applicable closure artifact; every finding traces to evidence and a POA&M item; the conclusion reconciles to the disposition; open constraints and the downstream handoff scope are stated.\n- Downstream workflow instance created or located and linked, holding the final package and open POA&M items, with the act-on versus do-not-repeat scope stated and downstream ownership acknowledged; the package is archived per retention with records locked; the control records carry the determination and dates (per-system results live in the archived package); the next review or monitoring trigger is scheduled; the final decision is communicated and open POA&M items carry follow-up dates.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the registers, determination, disposition, and closure artifact into a single reviewable package attached to this step. `/coach-notify` sends the final decision to the control owner, system owner, and authorizing official and confirms downstream engagement.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-render-package","coach-notify"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:controls-identity-assurance-review"}