{"description":"Enterprise Risk Treatment Operations Cycle as a decision-aware workflow: it runs the documented risk methodology each cycle - identification and analysis of risks and opportunities, evaluation and prioritization against risk criteria, treatment selection and tracking for risks exceeding tolerance with residual re-evaluation, and risk-register and portfolio reporting to management and the board - triggering dynamic reassessment when internal or external change shifts the risk profile. This cycle has no anchor item of its own: the enterprise risk register it maintains IS the Risk item population, and the workflow instance is the cycle record and durable audit trail. In scope: entity-level and process-level risk across the enterprise, explicitly including cybersecurity, privacy, and financial-reporting risk alongside operational and strategic risk and opportunity. Out of scope: detailed control design and testing, which downstream control workflows own - a mitigate or share/transfer plan that creates or strengthens a control hands that work off to those workflows, which anchor on the affected Control items. This cycle has no upstream workflow feeding it; its starting inputs are the documented methodology, the consistent likelihood/impact scoring scales, the board-approved risk criteria and appetite/tolerance statements, and the risk-acceptance delegation matrix - all carried as Policy items - plus the existing control, insurance and transfer information (Control items and step documents) and the prior cycle's Risk register. Named deliverables: the maintained enterprise risk register (the Risk items), the prioritized risk heat-map dashboard, and the management and board portfolio report package.","edges":[{"id":"e-evaluate-and-prioritize-risks-select-and-implement-risk-treatment","label":"Treatment required","source":"evaluate-and-prioritize-risks","target":"select-and-implement-risk-treatment","whenValue":"exceeds_tolerance"},{"id":"e-evaluate-and-prioritize-risks-monitor-for-change-triggered-reassessment","label":"No treatment needed","source":"evaluate-and-prioritize-risks","target":"monitor-for-change-triggered-reassessment","whenValue":"within_tolerance"},{"id":"e-select-and-implement-risk-treatment-reevaluate-residual-risk","source":"select-and-implement-risk-treatment","target":"reevaluate-residual-risk"},{"id":"e-reevaluate-residual-risk-monitor-for-change-triggered-reassessment","label":"Residual within tolerance","source":"reevaluate-residual-risk","target":"monitor-for-change-triggered-reassessment","whenValue":"within_tolerance"},{"id":"e-reevaluate-residual-risk-escalate-and-strengthen-treatment","label":"Escalate","source":"reevaluate-residual-risk","target":"escalate-and-strengthen-treatment","whenValue":"escalation_required"},{"id":"e-escalate-and-strengthen-treatment-monitor-for-change-triggered-reassessment","source":"escalate-and-strengthen-treatment","target":"monitor-for-change-triggered-reassessment"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-RISK-06","UC-RISK-07","UC-RISK-08","UC-RISK-09","UC-RISK-10","UC-RISK-11"],"department":"operations","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-enterprise-risk-assessment-treatment-cycle","contentDigest":"sha256:bbc320670d4d8c85ce55c4b291867eb62b89ddc4c7b8c7aacd8355d71a632125","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:bbc320670d4d8c85ce55c4b291867eb62b89ddc4c7b8c7aacd8355d71a632125","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-enterprise-risk-assessment-treatment-cycle"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-enterprise-risk-assessment-treatment-cycle","source":"coworkcanvas-gallery","standards":["iso-31000","coso-erm","nist-csf-2","nist-800-53"],"teams":["operations","risk-management"]},"name":"Enterprise Risk Treatment Operations Cycle","nodes":[{"data":{"decisionField":"criteria_outcome","description":"ERM lead with process and entity risk owners: Resolve missed risks/opportunities and ownership, calibrate comparable likelihood/impact evidence and decide whether any risk exceeds approved tolerance.","formData":{"fields":[{"key":"criteria_outcome","label":"Risk-criteria evaluation outcome","options":[{"label":"One or more risks exceed tolerance - treatment required","value":"exceeds_tolerance"},{"label":"All risks within tolerance - no treatment required","value":"within_tolerance"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Build and calibrate the owner-confirmed enterprise risk and opportunity population and decide whether formal treatment is required.\n\n**Decision criteria**\nInputs for preparation: - The documented risk assessment methodology and severity-rating method, the board-approved risk criteria, and the appetite/tolerance statements — each held as a Policy item (policy_type: procedure for the methodology, charter/standard for the appetite and criteria statements; framework: iso-31000, coso-erm), with the governed document attached. The consistent likelihood/impact scoring scales are partly encoded in the Risk schema itself (Risk.likelihood, Risk.impact selects); their narrative definitions live in the methodology Policy item. No upstream workflow feeds this cycle; if this is the initial cycle and none exist, record that fact.\n- The prior cycle's Risk register — the existing Risk items with their prior-cycle likelihood/impact/inherent_rating/residual_rating/treatment/risk_owner values (carryover risks to be enriched, not re-created) — plus the prior portfolio report (document on the prior cycle instance) and open treatment-plan Issue items (source: management_identified, linked to their Risk).\n- Source data for identification: loss-event and incident logs (Issue items — issue_type/severity/identified_date), audit and control-testing findings (Issue items linked to Audit items, plus Control-hosted SOX testing workflows — the workflow Test-step conclusion), the organizational structure (Process items — process_type, process_owner), and external strategic/operating plans, threat-intelligence and macroeconomic feeds (outside AssureSwarm; extracts uploaded as step documents). Business units and systems have no native item type — carried as external references (gap: no Entity/Asset type).\n- Scope reminder: the population must span both entity-level (strategy, reputation, market, macroeconomic) and process-level (operational, financial-reporting, cybersecurity, privacy, third-party, compliance) risk.\n- The confirmed risk-and-opportunity population from the population review in this checkpoint (each Risk item with its category and level).\n- The consistent likelihood and impact scales and the severity-rating method from the methodology Policy item (the Risk.likelihood/Risk.impact selects encode the scale points).\n- Analysis evidence: historical loss and incident data (Issue items), current control-environment information (Control items linked to the Risk), Control-hosted SOX testing workflow results and Audit findings, and forward-looking indicators uploaded as step documents (threat intelligence, macro forecasts, strategic-plan assumptions).\n\n*Autonomous preparation incorporates Identify risks and opportunities; Analyze likelihood and impact; ERM lead with process and entity risk owners reviews the combined evidence.*\n1. Query the source data above to compile a candidate list of risks at the entity level and the process level; pull prior-cycle carryover Risk items so open items are enriched rather than re-identified as new.\n2. Systematically identify strategic opportunities — positive risks where a favorable outcome is plausible (new markets, technology, partnership upside) — alongside downside threats, so the population is not skewed to threats only. Aim for at least one opportunity per major strategic objective before concluding none exists.\n3. Create a new Risk item for each newly surfaced entry (and enrich each carryover Risk item), recording its description, category, entity-or-process level, proposed owner, and identification source.\n4. Have every participating process and entity risk owner review their draft population and record their own native result: they name the risks and opportunities the draft misses, the entries that duplicate one another, and whether they accept ownership. Owners see exposures no source system records — do not answer for them.\n5. Merge duplicates that describe the same underlying exposure and consolidate the owners' returned input back into the register, resolving any risk two owners both claim or both disown.\n6. For each Risk item, analyze likelihood and potential impact using the best available historical loss and incident data, current control-environment information, and forward-looking indicators, applying the consistent likelihood and impact scales from the methodology.\n7. Record the analysis result, the sources relied on, and the key assumptions for every score, so the rationale is traceable rather than a bare number.\n8. Compute a severity rating for each entry from its likelihood and impact scores using the same method across the whole population, so ratings are comparable across business units and risk owners rather than owner-specific.\n9. Link supporting evidence — loss-data extracts, control-testing results, threat-intelligence summaries — to each scored entry.\n\n- `exceeds_tolerance` — one or more risks' analyzed position sits above the board-approved tolerance threshold and therefore requires a formal treatment response this cycle. Pick this whenever any single entry breaches tolerance, even if most of the population is within appetite.\n- `within_tolerance` — the entire analyzed population sits inside appetite and tolerance; no formal treatment is warranted and only register maintenance and portfolio reporting remain.\n- To support the call, prioritize the exceeds-tolerance entries by severity, proximity to appetite, and organizational context (concentration, strategic importance, regulatory exposure) to sequence treatment resource, and build a heat-map of the full population showing severity, tolerance position, and priority ranking.\n\n**Record in AssureSwarm**\n- Create a new Risk item per newly surfaced risk or opportunity, and enrich each carryover Risk item (coach-item-create): set description, category (SELECT — strategic | operational | cyber_security | financial_reporting | privacy | third_party | compliance_regulatory | …), taxonomies, domains, and risk_owner; record the identification source and the entity-vs-process level in description (Risk has no source or level field — honest fallback). Strategic opportunities are also Risk items (category: strategic, the upside noted in description — Risk has no threat-vs-opportunity field, so it is stated in prose).\n- Query the prior-cycle Risk population, the loss/incident Issue items, the Audit findings and Control-hosted SOX testing workflow results, and the Process items via coach-query-data.\n- Each process and entity risk owner’s native result captures the area reviewed, whether the draft population is complete, the missing risks and strategic opportunities, the entries to merge, and their acceptance of ownership — the assessor's own consolidation goes in the step result.\n- Update each Risk item with its analysis result (coach-item-update): Risk.likelihood (low | medium | high | very_high), Risk.impact (low | medium | high | critical), and the computed Risk.inherent_rating (low | medium | high | critical); record the sources relied on and the key assumptions in Risk.description (no dedicated source/assumption field — honest fallback).\n- Link each scored Risk to the loss/incident Issue items, the Audit items, and the Controls whose directly hosted SOX workflow results were relied on; the workflow's direct Control host preserves the result association (coach-items-link).\n- Pull analysis evidence (loss/incident Issue items, Control records, Control-hosted SOX testing workflow results, and Audit records, uploaded threat/macro extracts) via coach-query-data.\n- Submit the `criteria_outcome` SELECT field (exceeds_tolerance | within_tolerance).\n- Record the evaluation rationale and evidence references in the step result, and the decision owner or approver in the step's approver record.\n- Build the prioritized risk heat-map dashboard over the Risk population (coach-dashboard-create) — severity, tolerance position, and priority ranking; pull the risk-criteria and appetite thresholds from their Policy items and the analyzed Risk items via coach-query-data.\n\nRecord in the native step result or attached source documents: Entity or process area you are reviewing the draft population for (area_reviewed); Is the draft risk population complete for your area? (population_completeness); Risks in your area that the draft population misses, each as cause, event, consequence (state None if none) (additional_risks); Strategic opportunities (upside outcomes) in your area that should be assessed (state None if none) (strategic_opportunities); Draft entries that describe the same underlying exposure and should be merged (duplicates_to_merge); Do you accept ownership of the risks listed against you? (ownership_confirmation); Reassignments proposed, or context an assessor would not otherwise know (reassignment_or_context). Use native approvals for sign-off.\n\n**Exit criteria**\nResolve missed risks/opportunities and ownership, calibrate comparable likelihood/impact evidence and decide whether any risk exceeds approved tolerance.\nEvery named risk owner has recorded their review and their additions, merges, and ownership answers are consolidated into the register; strategic opportunities are genuinely represented (not just threats); duplicates are merged; every entry has a proposed owner and an identification source recorded.\nA calibration session with risk owners and the ERM lead spot-checks a cross-section of scores for consistency, confirms severity ratings are comparable across the risk universe (not inflated or deflated by individual owners), and confirms sources and assumptions are recorded for every entry.\nThe `criteria_outcome` form is submitted with rationale and owner recorded; the heat-map reflects the full population and its tolerance positions; the branch not selected is prunable.","kind":"decision","label":"Evaluate and prioritize against risk criteria","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-item-update","coach-form-fill","coach-dashboard-create"]}},"id":"evaluate-and-prioritize-risks"},{"data":{"description":"Agent recommends a response for every exceeds-tolerance risk, formulates treatment plans with owners and timelines, and tracks implementation; human treatment owners approve each response and plan","instructions":"**Objective** — For every risk exceeding tolerance, land an approved treatment response and, where applicable, a resourced plan with owner and timeline, and track implementation to the point residual risk can be re-scored.\n\n**Inputs**\n- The exceeds-tolerance Risk items and their priority ranking from the evaluation decision.\n- Existing control information (Control items linked to the Risk — control_type, key_control, control_owner), and insurance/contractual-transfer instruments backing a transfer (no native Contract type — carried as step documents; gap).\n- The organization's strategic risk-response direction and the treatment-owner community.\n\n**Procedure**\n1. For each exceeds-tolerance risk, recommend a response — accept, avoid, mitigate, or share/transfer — consistent with the strategic risk-response direction and the priority ranking, checking for existing controls, insurance, or contractual transfer mechanisms already in place.\n2. For mitigate and share/transfer responses, formulate a treatment plan with named owner, specific actions, resourcing, and a target completion timeline; for accept and avoid responses, draft the documented rationale and the accountable owner's sign-off statement in place of a plan.\n3. Create a tracked item for every response and plan, link each to its source risk, and route plans to their named owners for approval.\n4. Track every approved plan's implementation against its timeline, chasing owners ahead of due dates and flagging slippage.\n\n**Record in AssureSwarm**\n- Set the selected response on each exceeds-tolerance Risk item (coach-item-update): Risk.treatment (mitigate | accept | transfer | avoid).\n- For mitigate and share/transfer responses, create one Issue item per plan (coach-item-create): source: management_identified, remediation_plan (actions and resourcing), issue_owner (the named plan owner), target_remediation_date (the completion timeline); link Issue ↔ its source Risk item (coach-items-link).\n- For accept and avoid dispositions, attach the documented rationale and accountable-owner sign-off statement as a step document (coach-document-upload), with Risk.treatment set to accept or avoid on the Risk item.\n- Monitor each approved plan's progress against its timeline (coach-workflow-scan).\n\n**Exit criteria** — Treatment owners approve their assigned response and plan (or return it for rework); actions and timelines are realistic and resourced; the ERM lead confirms every exceeds-tolerance risk has an approved response before residual risk is re-evaluated.","label":"Select and implement risk treatment","performedBy":{"primitives":["coach-item-create","coach-item-update","coach-items-link","coach-document-upload","coach-workflow-scan"]}},"id":"select-and-implement-risk-treatment"},{"data":{"decisionField":"residual_status","description":"Agent re-scores every treated risk against tolerance and drafts the stakeholder status communication; human ERM lead decides whether residual exposure now clears tolerance or must escalate","formData":{"fields":[{"key":"residual_status","label":"Residual-risk status","options":[{"label":"Residual risk within tolerance","value":"within_tolerance"},{"label":"Escalation or strengthened treatment required","value":"escalation_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Determine whether treated risks now clear tolerance or must escalate. The ERM lead re-scores residual exposure against the same criteria used in analysis and selects the branch.\n\n**Decision criteria**\n- `within_tolerance` — every treated risk's residual likelihood and impact, reflecting completed mitigation actions, executed transfers, or the accepted/avoided disposition, now sits at or below the tolerance threshold.\n- `escalation_required` — one or more risks remain above tolerance after treatment and need senior or board risk acceptance or a strengthened plan. Pick this whenever any single treated risk's residual position still breaches tolerance.\n- Re-score residual likelihood and impact using the same scales and risk criteria used in analysis; compile the list of risks whose residual position still exceeds tolerance to justify the call.\n\n**Record in AssureSwarm**\n- Submit the `residual_status` SELECT field (within_tolerance | escalation_required).\n- Record the rationale and evidence references in the step result, and the decision owner or approver in the step's approver record.\n- Update each treated Risk item's Risk.residual_rating (low | medium | high | critical) to its re-scored residual position (coach-item-update).\n- Draft the response-decision and treatment-status stakeholder communication as a step document (memo) on this step (coach-document-upload); pull residual evidence (treated Risk items and their treatment Issue items) via coach-query-data.\n\n**Exit criteria** — The `residual_status` form is submitted with rationale and owner recorded; each treated risk's residual score is updated in the register; the branch not selected is prunable.","kind":"decision","label":"Re-evaluate residual risk","performedBy":{"primitives":["coach-query-data","coach-item-update","coach-document-upload","coach-form-create"]}},"id":"reevaluate-residual-risk"},{"data":{"description":"Agent packages the still-exceeding risks with their treatment history for senior or board risk acceptance and drafts strengthened actions; human senior risk owner formally accepts or redirects treatment","instructions":"**Objective** — For risks still exceeding tolerance after treatment, secure a formal senior or board risk-acceptance decision or route strengthened treatment back into execution, with the outcome recorded and time-bound.\n\n**Inputs**\n- The still-exceeding Risk items and their residual_rating from the residual re-evaluation.\n- Each risk's treatment history: the original response, the treatment-plan Issue item, actions taken, and why the result fell short.\n- The organization's risk-acceptance delegation authority matrix — a Policy item (policy_type: standard) — mapping which authority level may accept which residual severity.\n\n**Procedure**\n1. For every risk whose residual position still exceeds tolerance, assemble the treatment history — the original response, the plan, actions taken, and the reason the result fell short.\n2. Where a stronger response is available, draft the revised or supplementary treatment actions, owner, and timeline for resubmission.\n3. Where no further cost-effective treatment exists, draft a formal risk-acceptance package naming the senior executive or board committee whose authority level matches the residual severity, consistent with the risk-acceptance delegation.\n4. Link the escalation package to the original risk and treatment records and route it to the named senior approver.\n\n**Record in AssureSwarm**\n- Where a stronger response is available, update the plan's Issue item (coach-item-update): revised remediation_plan, issue_owner, and target_remediation_date, routed back into execution.\n- Where the senior authority formally accepts the residual exposure, record the acceptance as a policy_exception Issue (coach-item-create): issue_type: policy_exception, exception_approver (the senior executive or board committee), exception_expiry_date (the time-bound re-review date), with the residual severity and authority-level rationale in description; set Risk.treatment: accept on the accepted Risk item (coach-item-update); link the exception Issue ↔ the source Risk item and its treatment Issue (coach-items-link).\n- Attach the escalation and risk-acceptance package as a step document (coach-document-upload).\n\n**Exit criteria** — The senior risk owner or board delegate either formally accepts the residual exposure at their authority level (recorded and time-bound for re-review) or directs strengthened treatment back into execution; the decision and its owner are recorded before register close-out.","label":"Escalate and strengthen treatment","performedBy":{"primitives":["coach-item-create","coach-item-update","coach-document-upload","coach-items-link"]}},"id":"escalate-and-strengthen-treatment"},{"data":{"description":"ERM lead and designated management approver: Judge whether current changes invalidate the completed assessment, direct dynamic reassessment and approve the reconciled register and board report for distribution and retention.","instructions":"**Objective** — Reconcile the risk register and portfolio, evaluate change-triggered reassessment and approve the current report and archived cycle record.\n\n**Inputs**\n- The full risk population and its dispositions from every path that reaches here: within-tolerance entries routed straight from the evaluation decision, treated risks whose residual position cleared tolerance, and escalated or formally accepted risks from the escalation checkpoint.\n- Each entry's current analysis results, owner, and treatment plan or documented disposition.\n- The prior-cycle register and portfolio report, for movement comparison.\n- The maintained risk register and portfolio report prepared in this checkpoint (the recorded scores, tolerance positions, and treatment plans this cycle produced), against which change materiality is judged.\n- Change sources: HR and leadership records, system inventory, program and M&A activity, and external regulatory, threat-intelligence, macroeconomic, and industry-incident feeds.\n- The full working record: the methodology and risk-criteria references, the identification and analysis workpapers with sources and assumptions, the evaluation and prioritization rationale, every treatment plan or documented disposition with approvals, and any escalation and risk-acceptance records.\n\n**Procedure**\n*Autonomous preparation incorporates Maintain risk register and report the portfolio view; ERM lead and designated management approver reviews the combined evidence.*\n1. Update the risk register so every risk and opportunity carries its current analysis results, owner, treatment plan or documented disposition, and status — whether it skipped treatment as within tolerance, completed treatment, or was formally accepted at escalation — timestamped to this cycle.\n2. Aggregate the register into a portfolio-level view showing risk distribution by severity, category, and entity-versus-process level, movement since the prior cycle, and treatment-plan completion rates.\n3. Compile the management and board report package from the register extract and portfolio dashboard, including the cycle's key decisions, escalations, and any risk-criteria or appetite observations surfaced during the cycle.\n4. Verify every entry required by this cycle — identified, analyzed, evaluated, and, where applicable, treated — is present in the extract with no silent drops between checkpoints.\n5. Scan for internal changes since the cycle opened — new business models or products, leadership changes, new or retired systems, M&A activity, restructuring — against HR, system-inventory, and program-management sources.\n6. Scan for external changes — new or amended regulations, emerging threat patterns, macroeconomic shifts, industry incidents — that could significantly affect the organization's risk profile or system of internal control.\n7. For any change identified, assess whether it invalidates a risk score, tolerance position, or treatment plan already recorded this cycle, and apply the specific register updates needed to keep the assessment current.\n8. Log every change-triggered assessment and its resulting update, or the confirmation that no material change was detected, so the next cycle inherits an accurate trigger history; the ERM lead decides whether any detected change is material enough to require an out-of-cycle dynamic reassessment.\n9. Before approval, distribution or archive, reconcile the portfolio dashboard and report to every change-driven update so the approved report and register use the same current scores and dispositions. Assemble the complete cycle record — the methodology and risk-criteria references, the identification and analysis workpapers with sources and assumptions, the evaluation and prioritization rationale, every treatment plan or documented disposition with approvals, any escalation and risk-acceptance records, the updated register, the portfolio report, and the change-monitoring log.\n10. Archive the package to the designated evidence repository with the applicable retention period, and export the full workflow record so the package is self-contained.\n11. Record the management approval evidencing this cycle satisfied the methodology and the at-least-annual, change-triggered cadence, and note the scheduled trigger for the next quarterly register and treatment refresh.\n12. Communicate closure and the archive location to risk owners, the ERM lead, and the board reporting line.\n\n**Record in AssureSwarm**\n- Update each Risk item to its final cycle state (coach-item-update): current residual_rating, treatment, risk_owner, and status, timestamped to this cycle; pull the full Risk population via coach-query-data.\n- Build the portfolio-level dashboard over the Risk population (coach-dashboard-create) — distribution by severity, category, and entity-vs-process level, movement since the prior cycle, and treatment-plan completion rates.\n- Export the management and board report package — the XLSX register extract plus the portfolio narrative — as a step document (coach-item-export).\n- Pull change-source data via coach-query-data; apply any change-driven updates to the affected Risk items (coach-item-update) — revised likelihood, impact, or residual_rating where a change invalidates a score; log the scan outcome, or a no-material-change confirmation, as the scan record on this step (coach-workflow-scan).\n- Export the full workflow instance record (coach-workflow-export) — the run itself is this cycle's durable audit trail — and link all cycle artifacts (register extract, portfolio report, treatment Issue items, escalation/policy_exception records, change-scan log) into the archive package (coach-document-link).\n- Record the management approval and the next-cycle refresh trigger on this step.\n\n**Exit criteria**\nJudge whether current changes invalidate the completed assessment, direct dynamic reassessment and approve the reconciled register and board report for distribution and retention.\nThe ERM lead confirms the register is current and complete, the portfolio view accurately reflects this cycle's population and movement, and approves the final report for management and the board after the change review and reconciliation in this checkpoint.\nThe ERM lead has decided whether any detected change requires an out-of-cycle dynamic reassessment (or formally confirmed none is needed) and every required update is applied to the register before archiving; the archived record is self-contained and durable — methodology, identification, analysis, evaluation, treatment, residual re-evaluation, register, portfolio report, and change log all present; management approval and the next refresh trigger are recorded; closure is communicated and the cycle is closed.","label":"Monitor for change-triggered reassessment","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-export-package","coach-item-update","coach-item-create","coach-workflow-scan","coach-workflow-export","coach-document-upload"]}},"id":"monitor-for-change-triggered-reassessment"}],"sourceTemplateId":"workflow-library:grc-enterprise-risk-assessment-treatment-cycle"}