{"description":"Second-line ERM oversight cycle. Each run is anchored to a cycle Audit item created for the period (audit_type: operational, scope = the assessment boundary, period_start/period_end = the cycle window, report_date = the approval date); the workflow instance attaches to it as the durable audit trail, and the enterprise Risk items are the register it assesses and updates in place. Establish the assessment context (scope, criteria, appetite, scoring calibration), identify risks, score inherent and residual severity, select responses, publish the portfolio view, and route the package through disposition and governance approval. In scope: enterprise-level risk identification, assessment, response selection, and portfolio reporting for the current cycle. Out of scope: defining the board-approved risk appetite statement itself and preparing the board reporting deck, which are handled by downstream workflows. Consumes the prior-cycle risk-register handoff package (the existing Risk items plus the linked register document) from the Enterprise Risk Register Lifecycle workflow, and hands its named deliverables — the residual portfolio view (dashboard), the risk-movement narrative, and the approved assessment package — to the Risk Appetite Definition & Board Reporting and Quarterly Board & Audit-Committee GRC Reporting workflows.","edges":[{"id":"e-compute-residual-risk-prioritize-and-select-response","source":"compute-residual-risk","target":"prioritize-and-select-response"},{"id":"e-prioritize-and-select-response-classify-disposition","source":"prioritize-and-select-response","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Remediate","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clean","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"clean"},{"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-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-approve-or-revise-package-record-approval-decision","label":"Approved","source":"approve-or-revise-package","target":"record-approval-decision","whenValue":"approved"},{"id":"e-resolve-approval-conditions-record-approval-decision","source":"resolve-approval-conditions","target":"record-approval-decision"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-RISK-03","UC-RISK-06","UC-RISK-07","UC-RISK-08","UC-RISK-09","UC-RISK-10","UC-RISK-04"],"department":"risk-management","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-enterprise-risk-assessment-cycle","contentDigest":"sha256:c0b55c9a7fc920d14f3d9ae8b3d77d431a7fa57d1bdb0cd025c63ae86e94f2e9","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:c0b55c9a7fc920d14f3d9ae8b3d77d431a7fa57d1bdb0cd025c63ae86e94f2e9","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-enterprise-risk-assessment-cycle"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-enterprise-risk-assessment-cycle","source":"coworkcanvas-gallery","standards":["coso-erm","iso-31000"],"teams":["risk-management"]},"name":"Enterprise Risk Assessment & Portfolio Oversight Cycle","nodes":[{"data":{"description":"Second-line GRC assessment lead and assessors, with separate peer review of critical/outlier scores: Judge the complete risk population and evidence-based inherent/residual ratings against the fixed criteria and approved appetite, retaining the required second-reviewer notes for criticals and large movers.","instructions":"**Objective** — Establish and freeze the assessment basis before analysis, identify risks, and judge calibrated inherent and residual scores supported by control evidence and peer checks.\n\n**Inputs**\n- The prior-cycle risk register — the existing **Risk items** (with their `inherent_rating`/`residual_rating`/`treatment`/`risk_owner`) plus the register handoff document linked to this step, consumed from the Enterprise Risk Register Lifecycle workflow.\n- Strategic objectives and the current business/operating context (org changes, new products, M&A, regulatory shifts) — the in-scope **Process items** stand in for entities/processes; objectives have no native type, so they ride in the context memo uploaded at this step.\n- The organization's ERM policy / framework reference (COSO ERM, ISO 31000) — the **Policy item** for the ERM framework (`policy_type: policy`/`standard`, `framework: coso-erm|iso-31000`); any prior-cycle scope memo is uploaded here.\n- Materiality and governance reporting thresholds — uploaded at this step (no native field holds them).\n- The current board-approved risk appetite statement — the **Policy item** for the appetite statement/charter (`policy_type: charter`, `approved_by` = the board, `framework: coso-erm`); the category-level tolerance thresholds it carries are recorded in this step's attached document (no native field holds thresholds).\n- KRI/KPI limits and escalation triggers in force — uploaded as evidence at this step (no KRI type).\n- Strategic objectives and operating context — the same **Process items** and scope memo used to frame scope.\n- Any appetite changes fed back from the prior cycle's Risk Appetite Definition & Board Reporting run (a prior-cycle feedback loop, not a live dependency on the workflow this cycle feeds).\n- The organization's risk taxonomy / category tree — the **Risk.category** and **Risk.taxonomies** select options ARE the taxonomy risks are tagged to (strategic, financial, operational, cyber, compliance, third-party, …).\n- The prior-cycle scoring rubric and heat-map bands.\n- The likelihood/impact scales from the criteria stage (or the shared criteria source).\n- The control-effectiveness rating convention (how design and operating effectiveness map to a residual discount).\n- The scope and criteria package (from the scope stage).\n- The appetite thresholds (from the appetite stage).\n- The taxonomy and scoring calibration (from the calibration stage).\n- Available assessors, workshop schedule, and the governance reporting calendar.\n- The locked workplan (owners, scope, evidence requirements) fixed during baseline preparation in this checkpoint.\n- The prior-cycle risk register — the carried-forward **Risk items** (and their prior ratings) linked to the cycle, from the Enterprise Risk Register Lifecycle handoff.\n- KRI/KPI data and loss/incident history (no native type — uploaded as CSV/XLSX at this step), audit and assurance findings (existing **Issue items**, `source`/`severity`), emerging-risk scans, and interview or workshop inputs.\n- The risk inventory (from identification in the residual-assessment checkpoint).\n- The likelihood/impact scales and rating function (from the criteria and calibration stages).\n- Supporting evidence per the workplan (loss data, external benchmarks, KRI trends).\n- Inherent scores (from inherent scoring in this checkpoint).\n- The control-strength / inherent-to-residual model (from the calibration stage).\n- Control coverage and effectiveness evidence: control design, latest operating-effectiveness test results, and assurance ratings mapped to each risk.\n\n**Procedure**\n*Autonomous preparation incorporates Frame scope and criteria; Confirm appetite and objectives; Confirm assessment taxonomy and scoring calibration; Lock executable workplan; Identify risks; Score inherent severity; Second-line GRC assessment lead and assessors, with separate peer review of critical/outlier scores reviews the combined evidence.*\n1. Set the assessment boundary: list the entities, business units, processes, and objective categories (strategic, operational, reporting, compliance) in scope, and explicitly name what is out of scope with a one-line reason for each exclusion.\n2. Anchor to objectives: for each in-scope objective, state the value at stake so a risk's relevance is testable rather than asserted.\n3. Define assessment criteria: the likelihood scale (e.g., a 5-point Rare/Unlikely/Possible/Likely/Almost-Certain scale with % or frequency anchors) and the impact scale across dimensions (financial, operational, reputational, regulatory) with quantified band boundaries.\n4. Set the time horizon (e.g., a 12-month forward view) and any velocity or vulnerability factors the cycle will capture.\n5. Reconcile with the framework: confirm the criteria trace to the ERM policy and to prior-cycle criteria; document any change and its rationale so period-over-period movement stays comparable.\n6. Retrieve the in-force appetite statement and confirm its approval date and version; do not proceed on a draft or lapsed statement — flag it and use the last approved version.\n7. Translate qualitative appetite (e.g., \"low tolerance for compliance breaches\") into the quantified thresholds this cycle will apply, mapped onto the impact-scale bands from the criteria stage.\n8. Confirm per-category tolerance boundaries and the KRI trigger levels that mark amber/red status.\n9. Note objectives whose appetite is ambiguous or contested and record them as open items for governance — do not invent a threshold.\n10. Confirm accountable owners for each appetite category so later over-appetite findings have a named escalation route.\n11. Confirm the taxonomy: the category/subcategory tree risks will be tagged to, so aggregation and portfolio roll-up are consistent.\n12. Define the rating function: how a likelihood level and an impact level combine into an overall rating (matrix cell to Low/Medium/High/Critical), including any asymmetric weighting.\n13. Set the heat-map bands and color thresholds so the published portfolio view is deterministic rather than eyeballed.\n14. Calibrate the control-strength model: how control design and operating-effectiveness ratings translate into the reduction from inherent to residual (e.g., strong controls drop two bands, moderate one, weak none), and set the floor below which controls cannot reduce a risk.\n15. Run a calibration check: re-score two or three prior-cycle risks with the new rubric and confirm results are explainable and comparable; document any rubric change.\n16. Consolidate the three setup outputs into one assessment baseline and confirm they are mutually consistent (the criteria scales referenced by the scoring rubric actually match the framed criteria).\n17. Assign owners: for each in-scope area, name the risk owner and the assessor responsible for identification and scoring.\n18. Set due dates working back from the governance reporting date, with checkpoints for identification complete, scoring complete, and package ready.\n19. Specify evidence requirements: what supports each score (KRI data, loss events, control-test results, assurance reports) so scores are defensible rather than opinion.\n20. Define the review path and lock the baseline: record the version, freeze scope and criteria, and note that any later change requires re-baselining with a documented rationale.\n21. Carry forward prior-cycle risks in scope; mark each as unchanged, modified, or retired with a reason — never silently drop a prior risk.\n22. Run structured identification across sources: objective-driven (what threatens each objective), event-driven (loss/incident history, near-misses), and horizon scanning (regulatory, technology, market, third-party).\n23. Write each risk as a testable cause-event-consequence statement tied to a specific objective — not a vague theme like \"cyber\" but \"unpatched external system exploited leads to data exfiltration leads to regulatory penalty and outage.\"\n24. Deduplicate and disambiguate: merge duplicates, split compound risks, and tag each to the taxonomy from the calibration stage.\n25. Assign a preliminary owner to each risk and flag any risk lacking a clear owner for resolution before scoring.\n26. Confirm coverage: check every in-scope objective and entity has at least been considered, and record any deliberate \"no material risk identified\" conclusions.\n27. For each risk, score inherent likelihood on the defined scale, anchoring to frequency/probability evidence rather than gut feel, and cite the evidence used.\n28. Score inherent impact across each impact dimension (financial, operational, reputational, regulatory) and take the driving dimension as the impact rating, recording which dimension drove it.\n29. Apply the rating function to derive the inherent rating (matrix cell to Low/Medium/High/Critical); do not hand-adjust the cell — fix the inputs if the result looks wrong.\n30. Document key assumptions and any scenario basis (reasonable worst case vs expected) consistently across risks so scores are comparable.\n31. Peer-check outliers: any Critical, or any risk whose inherent score jumped materially from the prior cycle, gets a second-reviewer note before it stands.\n32. Map controls to each risk: identify the key controls that mitigate it and confirm the mapping is current (no orphan or lapsed controls credited).\n33. Rate the aggregate control strength for the risk from design and operating-effectiveness evidence using the calibrated convention; where controls are untested or failing, do not credit them.\n34. Apply the calibrated discount to derive residual likelihood/impact and the residual rating, respecting the floor (some risks cannot be controlled below a residual minimum).\n35. Compare residual to appetite: flag each risk as within, approaching, or over appetite using the thresholds from the appetite stage.\n36. Record the control gap for any over-appetite risk (missing, weak, or untested controls) so the response step has a concrete starting point.\n37. Sanity-check: residual must never exceed inherent; residual equal to inherent is valid only where no effective control exists — document that case.\n\n**Record in AssureSwarm**\n- Create the cycle **Audit item** (`audit_type: operational`, `scope` = the in-scope/out-of-scope boundary, `period_start`/`period_end` = the cycle window, `lead_auditor` = the GRC assessment lead) — the anchor this cycle enriches throughout; never create a duplicate cycle record downstream.\n- Link the in-scope **Process items** to the Audit item and capture the objective linkage in the scope memo on this step (no Objective type — honest fallback).\n- Attach the criteria definition document (likelihood + impact scales) to this step — the scales have no native field.\n- Link the consumed prior-cycle **Risk items** (the register handoff) to the cycle Audit item, and reference the ERM **Policy item** where tracked.\n- Attach the appetite-thresholds document to this step (per-category boundaries + KRI triggers) — Risk has no `appetite_status` or threshold field, so these live in the document and the portfolio view, not on an item.\n- Reference the appetite **Policy item** version (its `approved_by`, `version`, and `effective_date`) as the confirmed basis for the cycle.\n- Record open or ambiguous appetite items with their owners in the same step document.\n- Attach the scoring rubric and heat-map band document to this step — the rating function, bands, and inherent-to-residual control-strength model have no native field.\n- Note on the cycle **Audit item** `scope`/`description` that risks are tagged to the **Risk.category** and **Risk.taxonomies** options as the fixed taxonomy for the cycle.\n- Attach the workplan document (owners, due dates, evidence requirements) to this step — there is no workplan item type, so the document on the step is the record.\n- Assign the identification and scoring steps to the named owners.\n- Record the locked baseline version in the workplan document and on the cycle **Audit item** `scope`/`description` (no baseline-lock field — the frozen document is the record).\n- Create a **Risk item** per newly identified risk (`description` = the cause-event-consequence statement, `category` + `taxonomies` = taxonomy tags, `risk_owner` = the preliminary owner).\n- Link each Risk to its in-scope **Process item** (objectives collapse to Process — no Objective type) and to the cycle **Audit item**; for carry-forwards, keep the existing Risk item and record its unchanged/modified/retired disposition rather than creating a duplicate.\n- On each **Risk item**, set `likelihood`, `impact`, and `inherent_rating`; record the driving impact dimension in the Risk `description` (no dedicated field).\n- Attach the scoring evidence to this step (or link it) so each score is defensible.\n- On each **Risk item**, set `residual_rating` (the residual likelihood/impact reasoning is captured in `description`); appetite status (within/approaching/over) has no native field — carry it in the portfolio view and the package.\n- Link the credited **Control items** (and their **SOX** test results / **Issue** effectiveness evidence) to each Risk; record the control gap for any over-appetite risk in the Risk `description`.\n\n**Exit criteria**\nJudge the complete risk population and evidence-based inherent/residual ratings against the fixed criteria and approved appetite, retaining the required second-reviewer notes for criticals and large movers.\nScope boundary and out-of-scope rationale documented; likelihood and impact scales defined with quantified anchors; criteria reconciled to the ERM framework and prior cycle; scope item and criteria document saved.\nQuantified per-category appetite thresholds recorded and mapped to the impact scale; appetite statement confirmed as an approved version; ambiguous items logged with owners.\nTaxonomy confirmed; rating function and heat-map bands documented and deterministic; inherent-to-residual control-strength model calibrated; calibration check on prior-cycle risks documented.\nEvery in-scope area has a named owner and due date; evidence requirements specified per score; baseline version recorded and frozen; the three setup outputs confirmed mutually consistent.\nEvery in-scope objective and entity covered or explicitly cleared; each risk stated as cause-event-consequence with an owner and taxonomy tag; carry-forward dispositions recorded; duplicates resolved.\nEvery risk has inherent likelihood, impact (with driving dimension), and a derived rating; evidence cited; Criticals and large movers peer-checked; scoring basis consistent across the portfolio.\nEvery risk has a residual rating and an appetite status; only current, effective controls credited; residual is at or below inherent everywhere; control gaps captured for over-appetite risks.","label":"Compute residual risk","performedBy":{"agent":"grc-artist","primitives":["coach-item-create","coach-document-upload","coach-items-link","coach-item-update","coach-query-data","coach-workflow-assign"]}},"id":"compute-residual-risk"},{"data":{"description":"Rank the portfolio and select an owned response for each risk that needs one","instructions":"**Objective** — Rank the portfolio by residual exposure and appetite breach, then select and assign a risk response (accept / mitigate / transfer / avoid) for each risk that needs one, so the cycle produces decisions rather than just ratings.\n\n**Inputs**\n- Residual ratings and appetite status (from the residual assessment).\n- Control gaps recorded for over-appetite risks.\n- Cost/benefit and capacity context for potential responses.\n\n**Procedure**\n1. Rank risks by residual rating and appetite breach; within a band, order by velocity/proximity so the most urgent surface first.\n2. For each over-appetite or high/critical risk, select a response strategy: Accept (within appetite, or cost of action exceeds benefit — requires documented acceptance), Mitigate (strengthen or add controls), Transfer (insurance or contractual), or Avoid (exit the activity).\n3. For Mitigate, name the specific control improvement, its owner, and the expected residual after the action (target rating), so effectiveness is measurable next cycle.\n4. For Accept, require the acceptance to sit at the authority level appetite demands (higher exposure needs a higher approver) — flag any acceptance that exceeds the current owner's authority for escalation.\n5. Confirm each response is proportionate to the residual exposure and does not create a new material risk; note interdependencies where one response affects another risk.\n\n**Record in AssureSwarm**\n- On each **Risk item**, set `treatment` (`mitigate` | `accept` | `transfer` | `avoid`) and `risk_owner` (the response owner); the target residual has no native field — record it in the Risk `description` and the package.\n- For Mitigate responses, create (or stub) the **Issue** action item (`issue_type: deficiency`) linked to its Risk and the credited Control; the full plan is completed at Create action plan.\n\n**Exit criteria** — Portfolio ranked; every over-appetite and high/critical risk has a selected, owned response with a target residual; acceptances sit at the required authority level or are flagged for escalation.","label":"Prioritize and select response","performedBy":{"agent":"grc-artist","primitives":["coach-item-update","coach-items-link","coach-item-create"]}},"id":"prioritize-and-select-response"},{"data":{"decisionField":"disposition_path","description":"GRC lead with accountable risk owners: Judge portfolio appetite breaches, control gaps and systemic exposure to route clean, remediation or higher-authority 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** — Publish the reconciled residual portfolio and classify the cycle’s required remediation or escalation.\n\n**Decision criteria**\nInputs for preparation: - The scored, prioritized risk items (residual ratings, appetite status, responses).\n- The heat-map bands and taxonomy from the calibration stage.\n- The reporting audience and format expected by governance.\n\n*Autonomous preparation incorporates Publish portfolio view; GRC lead with accountable risk owners reviews the combined evidence.*\n1. Build the heat map from residual ratings using the calibrated bands — every risk plots to a cell deterministically, with no manual repositioning.\n2. Compile the top-risk list (Critical/High and all over-appetite risks) with residual rating, appetite status, owner, and selected response.\n3. Summarize appetite breaches by category and the aggregate portfolio posture (count by band, trend versus prior cycle).\n4. Roll up by taxonomy and by entity/business unit so governance can see concentration.\n5. Validate the view against the underlying records: totals reconcile to the risk items, and no risk is missing or double-counted.\n\n- **No reportable gap (`clean`)** — residual risks are within appetite or already carry adequate owned responses; no over-appetite risk lacks a response; no significant control failure surfaced. Route straight to package preparation.\n- **Remediation required (`remediate`)** — one or more risks are over appetite with a control gap, or a response needs new or strengthened controls that require a tracked action plan, but the exposure does not on its own warrant executive or board escalation.\n- **Escalate significant issue (`escalate`)** — a risk breaches appetite at a level requiring risk-acceptance authority above the current owner, a Critical residual has no viable response, or a systemic/board-reportable exposure exists. Route to the escalation and acceptance path.\n\n**Record in AssureSwarm**\n- Create the portfolio **dashboard** (residual heat map built from **Risk.residual_rating** × **Risk.category**/`taxonomies`, top-risk roll-up, appetite-breach summary, and entity/taxonomy roll-ups).\n- Link the dashboard to the cycle **Audit item**.\nSubmit the `disposition_path` SELECT. In the rationale note, cite the specific risks, residual ratings, and appetite breaches driving the classification, and name the decision owner (risk owner, GRC lead, executive sponsor, or board delegate).\n\n**Exit criteria**\nJudge portfolio appetite breaches, control gaps and systemic exposure to route clean, remediation or higher-authority escalation.\nHeat map, top-risk list, appetite-breach summary, and roll-ups published and reconciled to the underlying risk items; portfolio dashboard linked to the cycle.\n\n> **⚡ Audit Artist accelerator:** `/coach-dashboard-create` builds the residual heat map and top-risk roll-ups directly from the scored risk items.\n`disposition_path` submitted with a rationale that names the driving risks and the decision owner; unused branches are prunable.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"grc-artist","primitives":["coach-dashboard-create","coach-query-data"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Build an owned, dated remediation plan for each risk requiring stronger controls so the gap between residual and target exposure has a concrete, trackable path to closure.\n\n**Inputs**\n- The risks flagged remediate with their control gaps and target residuals (from response selection and the disposition decision).\n- Owner availability and any interim mitigation options.\n\n**Procedure**\n1. For each gap, state the root cause — why residual exceeds appetite (missing control, design weakness, or operating failure).\n2. Define the corrective action, its accountable owner, and a realistic due date tied to the exposure's urgency.\n3. Specify interim mitigation for the period until the action lands, so exposure is managed in the meantime.\n4. Define the validation evidence that will prove the action worked (the test or metric confirming residual reached target) and the reporting cadence.\n5. Confirm the plan actually moves residual to the target rating; if it cannot, escalate rather than accept a plan that leaves the risk over appetite.\n\n**Record in AssureSwarm**\n- Create an **Issue item** per gap (`issue_type: deficiency`, `source: self_assessment`, `root_cause`, `remediation_plan` = the corrective action + interim mitigation + validation evidence + cadence, `issue_owner`, `target_remediation_date`).\n- Link each Issue to its **Risk** and to the credited **Control**.\n\n**Exit criteria** — Every remediate risk has an owned, dated action with root cause, interim mitigation, and validation evidence; each plan credibly reaches the target residual or is escalated.","label":"Create action plan","performedBy":{"agent":"grc-artist","primitives":["coach-item-create","coach-items-link"]}},"id":"create-action-plan"},{"data":{"description":"Escalate to the right authority or document a formal risk acceptance","instructions":"**Objective** — Bring each escalated risk to the authority that can accept it or direct action, with a decision memo that lets that authority decide on the facts.\n\n**Inputs**\n- The risks flagged escalate with residual ratings, appetite breaches, and control gaps (from the disposition decision).\n- The appetite/authority matrix (which level may accept which exposure).\n\n**Procedure**\n1. Quantify the exposure: residual rating, potential impact range, likelihood basis, and the appetite threshold it breaches.\n2. Identify the correct authority per the acceptance-authority matrix (risk owner, GRC lead, executive sponsor, board delegate) — do not let a lower level accept an exposure reserved for a higher one.\n3. Draft the decision memo: the risk, the options (mitigate/transfer/avoid/accept), the recommendation, the cost/benefit, and the conditions attached to any acceptance.\n4. Capture the decision: for a formal risk acceptance, record the accepting authority, rationale, conditions, expiry/review date, and monitoring trigger; for a directive to act, require an owned action plan with the same root-cause, interim-mitigation, target-residual and validation requirements as the remediation path before the package is approved.\n5. Define follow-up ownership and the monitoring that will re-surface the risk if conditions change.\n\n**Record in AssureSwarm**\n- Attach the risk-acceptance **decision memo** (DOCX/PDF) to this step.\n- For a formal risk acceptance, set `treatment: accept` on the accepted **Risk item** and create a linked **Issue** with `issue_type: policy_exception`, `exception_approver` = the accepting authority, and `exception_expiry_date` = the review/expiry date (the register of live acceptances is those Issues filtered by `exception_expiry_date`).\n- Conditions and the monitoring trigger have no native field — they ride in the decision memo; set the follow-up owner as the Risk `risk_owner`.\n\n**Exit criteria** — Each escalated risk has a decision memo and a recorded decision at the correct authority level, with conditions, expiry/review date, monitoring trigger, and follow-up owner.","label":"Escalate or accept risk","performedBy":{"agent":"grc-artist","primitives":["coach-render-package","coach-item-update","coach-item-create","coach-items-link","coach-notify"]}},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Governance approver appropriate to the portfolio exposure: Challenge rating movements, authority, evidence and response adequacy and approve or return the reconciled assessment package.","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** — Explain portfolio movements, assemble and reconcile the complete assessment and obtain governance approval or precise revision conditions.\n\n**Decision criteria**\nInputs for preparation: - The published portfolio view and current residual ratings.\n- The prior-cycle portfolio and ratings (from the carried-forward register).\n- Carry-forward dispositions and response decisions from this cycle.\n- The portfolio view and the risk-movement narrative.\n- Action plans (remediate path) and/or decision memos and acceptances (escalate path), or confirmation of a clean disposition.\n- All scoring evidence and control-effectiveness references.\n\n*Autonomous preparation incorporates Publish risk movement narrative; Prepare final package; Governance approver appropriate to the portfolio exposure reviews the combined evidence.*\n1. Compute movement: for each risk, classify as new, increased, decreased, unchanged, or retired versus the prior cycle, using the residual rating change.\n2. Explain the drivers behind each material move — a changed threat environment, a control failure or improvement, a re-calibration, or a realized event — and never report a movement without a cause.\n3. Highlight the top new and top escalated risks and the appetite-breach changes since the last cycle.\n4. Summarize the aggregate trend (is the portfolio getting riskier?) and call out any concentration or emerging theme.\n5. Keep the narrative reconciled to the portfolio view: every movement claim traces to the underlying rating change, and any move driven by re-calibration rather than real risk change is flagged so it is not misread.\n6. Assemble the package contents: scope/criteria, appetite thresholds, the risk inventory with inherent/residual scores and evidence, the portfolio view, responses, action plans, acceptances, and the movement narrative.\n7. Reconcile across artifacts: ratings in the package match the risk items and the portfolio view; every over-appetite risk has either a response, an action plan, or a recorded acceptance — no orphan gaps.\n8. List unresolved constraints and open items (ambiguous appetite items, pending owners, untested controls) so the approver sees what is not yet closed.\n9. State the proposed conclusion for the cycle and the specific approval being requested.\n10. Quality-check completeness and traceability: every conclusion traces to criteria, appetite, evidence, and an accountable owner.\n\n- **Approved (`approved`)** — the package is complete and reconciled, every over-appetite risk has an adequate response/plan/acceptance at the right authority, evidence supports the conclusions, and open items are acceptable or assigned. The cycle result stands.\n- **Revision required (`revise`)** — material evidence is missing, a conclusion is unsupported, an acceptance sits below its required authority, an action plan does not credibly reach target, or the package is internally inconsistent. Route to condition resolution before it can be approved.\n\n**Record in AssureSwarm**\n- Attach the **risk-movement narrative** (DOCX/PDF) to this step.\n- Link it to the portfolio dashboard and the cycle **Audit item**.\n- Assemble the **assessment package** (PDF/XLSX) and attach it to this step; link its component records (**Risk items**, **Issue** action items, the portfolio dashboard, the movement narrative) to the cycle **Audit item**.\n- Record the proposed conclusion in the package and on the cycle **Audit item** (`rating`/`opinion` where applicable); the requested approval is captured by the decision in this checkpoint.\nSubmit the `approval_path` SELECT. In the rationale note, record the reviewer, the specific conditions or gaps (for revise) or the scope of approval and any conditions (for approved), and the decision date.\n\n**Exit criteria**\nChallenge rating movements, authority, evidence and response adequacy and approve or return the reconciled assessment package.\nEvery material movement classified with a documented driver; new/escalated risks and appetite-breach changes highlighted; narrative reconciled to the portfolio view; re-calibration effects separated from real risk change.\nPackage assembled and internally reconciled; no over-appetite risk without a response, plan, or acceptance; open items listed; proposed conclusion and requested approval stated; conclusions traceable end to end.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the portfolio, scores, responses, and narrative into a single reviewable package.\n`approval_path` submitted with reviewer, rationale, and date; the unused branch is prunable.","kind":"decision","label":"Approve or revise package","performedBy":{"agent":"grc-artist","primitives":["coach-render-package","coach-query-data","coach-items-link"]}},"id":"approve-or-revise-package"},{"data":{"description":"Resolve reviewer comments or approval conditions","instructions":"**Objective** — Clear the reviewer's conditions on the returned package so it can be re-submitted for a clean approval, with a documented record of what changed.\n\n**Inputs**\n- The revise decision and the specific conditions or comments (from Approve or revise package).\n- The final package and its underlying records.\n\n**Procedure**\n1. Log each condition as a discrete item with an owner so none is lost.\n2. Address each: gather the missing evidence, revise the unsupported conclusion, re-score if a rating was challenged, escalate an under-authorized acceptance, or strengthen an action plan.\n3. Update the affected records and the package so it is internally consistent again after the changes.\n4. Document what changed and why, tied to each reviewer condition, so the re-review is fast and auditable.\n5. Confirm every condition is resolved; if a condition cannot be met, escalate it back with rationale rather than silently closing it.\n\n**Record in AssureSwarm**\n- Update the affected **Risk** and **Issue** items and the package document.\n- Attach a change-log document to this step linking each reviewer condition to its resolution.\n\n**Exit criteria** — Every reviewer condition resolved or escalated with rationale; affected records and package updated and reconciled; change log recorded and ready for re-review.","label":"Resolve approval conditions","performedBy":{"agent":"grc-artist","primitives":["coach-item-update","coach-render-package"]}},"id":"resolve-approval-conditions"},{"data":{"description":"Authorized governance approver; ERM lead records and delivers the approved result: Confirm the final approved version and any conditions after corrections, then freeze and deliver the authorized package with owned monitoring and expiry reviews.","instructions":"**Objective** — Record the authoritative package approval, freeze its version and deliver the portfolio to both governance reporting consumers with the cycle’s archive and follow-up schedule.\n\n**Inputs**\n- The approved package (direct approval, or after conditions were resolved).\n- The approver's identity and any conditions attached to the approval.\n- The approved, frozen assessment package (from Record approval decision).\n- The scope, assumptions, and open items the downstream workflows must know.\n- The full set of cycle records (risks, scores, evidence, decisions, approvals).\n\n**Procedure**\n*Autonomous preparation incorporates Handoff to related workflow; Authorized governance approver; ERM lead records and delivers the approved result reviews the combined evidence.*\n1. Capture the approver's name/role, the approval date, and the exact version of the package approved.\n2. Record any conditions attached to the approval and the owner and due date for each.\n3. Confirm the approver holds authority appropriate to the portfolio's exposure (a board delegate for board-reportable risks).\n4. Freeze the approved package version as the record of the cycle so later changes are tracked as new versions.\n5. Set the follow-up ownership and the monitoring cadence for conditions and accepted risks.\n6. Identify the downstream consumers: Risk Appetite Definition & Board Reporting (which may adjust appetite based on this portfolio) and Quarterly Board & Audit-Committee GRC Reporting (which reports it to governance).\n7. Package the handoff: the approved portfolio view, top risks and appetite breaches, the movement narrative, open items, and the assumptions the downstream should not re-litigate.\n8. State explicitly what each downstream workflow should NOT repeat (e.g., re-scoring) versus what it owns (appetite change, board deck), so work is not duplicated.\n9. Create or link the downstream workflow instances and attach the package to them.\n10. Notify the downstream owners that the package is ready, with the key dates they must hit.\n11. Archive the final approved package and lock its version as the immutable record of the cycle.\n12. Update the enterprise risk register with the cycle's residual ratings, responses, acceptances, and owners so it is the current source of truth going into the next cycle.\n13. Schedule the monitoring and follow-up: KRI tracking, action-plan check-ins, and risk-acceptance expiry reviews, each with an owner and date.\n14. Set the next-cycle trigger (calendar date or event) and carry forward open items so nothing is dropped between cycles.\n15. Communicate the closed decision to stakeholders and confirm the audit trail (who did what, when, on what evidence) is complete and retrievable — the recorded handoff and archive on this step close the cycle.\n\n**Record in AssureSwarm**\n- On the cycle **Audit item**, set `report_date` = the approval date and `rating`/`opinion` = the approved conclusion; the approver's name, approved version, and conditions ride in the frozen package document (Audit has no approver field).\n- Assign the condition follow-ups to their owners with due dates (step assignment).\n- Link the approved **assessment package** to the downstream workflow instances — Risk Appetite Definition & Board Reporting AND Quarterly Board & Audit-Committee GRC Reporting — notify the downstream owners, and record the handoff on the cycle **Audit item**.\n- Close the cycle **Audit item** (`report_date` set, status closed) with the archived, version-locked package; export the workflow instance as the cycle audit trail.\n- The enterprise **Risk items** ARE the register — their final `residual_rating`/`treatment`/`risk_owner` stand as the current source of truth going into the next cycle; schedule monitoring, action-plan check-ins, and risk-acceptance expiry reviews (driven off the `exception_expiry_date` on the acceptance **Issues**), and set the next-cycle trigger.\n\n**Exit criteria**\nConfirm the final approved version and any conditions after corrections, then freeze and deliver the authorized package with owned monitoring and expiry reviews.\nApprover, date, approved version, and conditions recorded; authority confirmed appropriate; approved package frozen; condition follow-ups owned and dated.\nApproved package linked to both downstream workflows with assumptions and no-repeat scope noted and downstream owners notified; cycle closed with an archived, version-locked package; register updated to current residuals; monitoring, follow-ups, and acceptance-expiry reviews scheduled with owners; next-cycle trigger set; audit trail complete and retrievable.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` alerts the downstream workflow owners that the approved portfolio package is ready and sends the closure communication to stakeholders.","label":"Record approval decision","performedBy":{"agent":"grc-artist","primitives":["coach-item-update","coach-workflow-assign","coach-workflow-attach","coach-document-upload","coach-notify","coach-workflow-export"]}},"id":"record-approval-decision"}],"sourceTemplateId":"workflow-library:grc-enterprise-risk-assessment-cycle"}