{"description":"Risk & Resilience Framework Governance as a decision-aware workflow. The instance runs on the \"Enterprise Risk Management Framework\" Process item (process_type: business_process, process_owner = the framework owner, frequency: annual) - created on the first cycle at \"Design core ERM framework\" and enriched every cycle thereafter, never duplicated; that Process item is the governance register entry, and each governance cycle runs as a workflow instance attached to it, so the at-least-annual cadence is provable from one item's instance history. Working from the organization's context and the ISO 31000 / COSO ERM / DORA reference models - no upstream workflow package feeds it, because this workflow establishes the governance layer - it establishes or refreshes the enterprise risk management framework, extends it for ICT operational resilience and regulated technologies, secures management-body approval and budget, drives implementation across the organization, and runs the at-least-annual review, filling the governance layer the risk-cycle workflows run inside but never establish. The named deliverable is the approved risk & resilience framework package (core ERM design + ICT operational-resilience (DORA) extension + any regulated-technology lifecycle extension), archived at close as durable governance evidence. In scope: the enterprise risk framework, its always-in-scope ICT operational-resilience (DORA) extension, and any regulated-technology (e.g. high-risk AI) extensions to be evaluated. Out of scope: executing the individual risk-cycle workflows (identify / assess / treat / monitor) that run inside this framework - this workflow governs them but does not perform them, and consumes no upstream workflow package. Downstream, the archived framework enables those risk-cycle workflows, which reference it as their governing baseline (the relationship is real but not modeled as a node).","edges":[{"id":"e-design-core-erm-framework-extend-ict-operational-resilience-framework","source":"design-core-erm-framework","target":"extend-ict-operational-resilience-framework"},{"id":"e-design-core-erm-framework-scope-regulated-technology-extensions","source":"design-core-erm-framework","target":"scope-regulated-technology-extensions"},{"id":"e-scope-regulated-technology-extensions-add-ai-lifecycle-risk-processes","label":"Regulated tech in scope","source":"scope-regulated-technology-extensions","target":"add-ai-lifecycle-risk-processes","whenValue":"ai_in_scope"},{"id":"e-scope-regulated-technology-extensions-secure-management-body-approval","label":"No extension","source":"scope-regulated-technology-extensions","target":"secure-management-body-approval","whenValue":"none"},{"id":"e-add-ai-lifecycle-risk-processes-secure-management-body-approval","source":"add-ai-lifecycle-risk-processes","target":"secure-management-body-approval"},{"id":"e-extend-ict-operational-resilience-framework-secure-management-body-approval","source":"extend-ict-operational-resilience-framework","target":"secure-management-body-approval"},{"id":"e-secure-management-body-approval-drive-implementation-rollout","label":"Approved","source":"secure-management-body-approval","target":"drive-implementation-rollout","whenValue":"approved"},{"id":"e-secure-management-body-approval-resolve-approval-conditions","label":"Revise","source":"secure-management-body-approval","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-resolve-approval-conditions-drive-implementation-rollout","source":"resolve-approval-conditions","target":"drive-implementation-rollout"},{"id":"e-drive-implementation-rollout-run-annual-framework-review","source":"drive-implementation-rollout","target":"run-annual-framework-review"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-RISK-01","UC-BCDR-02","UC-GOV-17","UC-RISK-03"],"department":"risk-management","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-risk-resilience-framework-governance","contentDigest":"sha256:2eaeb9c8bb2b20a89e69ff15a7f08852a99129d1bad280b4e70a722a18fef665","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:2eaeb9c8bb2b20a89e69ff15a7f08852a99129d1bad280b4e70a722a18fef665","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-risk-resilience-framework-governance"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-risk-resilience-framework-governance","source":"coworkcanvas-gallery","standards":["iso-31000","coso-erm","dora"],"teams":["risk-management","executive"]},"name":"Risk & Resilience Framework Governance","nodes":[{"data":{"description":"Agent drafts or refreshes the enterprise risk framework design - context, accountabilities, resources, processes, and risk tolerance; human framework owner reviews the design against the organization's context","instructions":"**Objective** — Produce (or refresh) the core enterprise risk-management framework design - context, accountabilities, resources, processes, and risk tolerance - tailored to this organization and ready to be extended for ICT resilience and regulated technologies.\n\n**Inputs**\n- The governance trigger for this cycle and its date/source: an initial establishment, a scheduled at-least-annual review, a new or amended regulation such as DORA, a material change in strategy / structure / critical ICT services, or a significant risk or incident. On a repeat cycle it is recorded into the anchor Process item's description.\n- Any existing framework baseline: on repeat cycles, the prior cycle's archived workflow instance on the anchor Process item and the governance-package document attached to its \"Run at-least-annual framework review\" step (prior ERM framework document, management-body approvals, implementation plan, evidence). On the first cycle there is no baseline - note its absence in the design document.\n- The organization's external and internal context (strategic objectives, regulatory landscape, industry, structure, culture, stakeholder expectations) - external knowledge synthesized into the design document; the live risk context is readable from existing Risk items (category / taxonomies / domains) via query.\n- ISO 31000 and COSO ERM as reference models (external standards; their internal reflection is existing Control items whose framework includes iso-31000 / coso-erm). The named framework owner (= Process.process_owner on the anchor), executive sponsor, and accountable management body.\n- No upstream workflow feeds this cycle - this workflow establishes the governance layer that the individual risk-cycle workflows (identify / assess / treat / monitor) run inside.\n\n**Procedure**\n1. Analyze the organization's external and internal context so the framework is tailored rather than generic - map strategic objectives, the regulatory landscape, industry, structure, culture, and stakeholder expectations, drawing on ISO 31000 and COSO ERM as reference models.\n2. Draft or refresh the accountabilities layer: governance and culture expectations, roles and responsibilities across the three lines of defense, and explicit management-body and senior-leadership ownership and visible sponsorship of risk.\n3. Specify the resources and the mandated risk-management processes - risk identification, assessment, response, monitoring, and reporting - and define how risk management integrates with strategy, objective-setting, and performance.\n4. Calibrate the enterprise risk tolerance and appetite statements and their thresholds to the organization's context and objectives, stating each threshold in measurable terms.\n5. Draft the phased implementation plan and schedule for embedding the framework across the organization.\n6. Sanity-check the design against ISO 31000 and COSO ERM so no mandated element (leadership sponsorship, accountabilities, processes, tolerance) is missing before hand-off to the resilience and regulated-technology extensions.\n\n**Record in AssureSwarm** — Upload the framework design document to this step as the step document (DOCX/PDF; document upload). On the first cycle, create the anchor Process item \"Enterprise Risk Management Framework\" (Process — process_type: business_process, process_owner: the framework owner, frequency: annual); on every later cycle, enrich that existing Process item rather than creating a second one. Record the trigger, executive sponsor, accountable management body, and the target approval and implementation dates in Process.description - there are no dedicated sponsor/body/date fields, so they live in the description and in the framework design document.\n\n**Exit criteria** — The framework owner confirms the design is genuinely customized to the organization's context and that accountabilities, resources, processes, and the risk-tolerance statements are complete, internally consistent, and ready to be extended for ICT operational resilience.","label":"Design core ERM framework","performedBy":{"primitives":["coach-document-upload","coach-item-create"]}},"id":"design-core-erm-framework"},{"data":{"description":"Agent extends the framework with the documented ICT risk-management framework, digital operational-resilience strategy, ICT-risk roles, budget, and annual-review cadence; human resilience owner and management-body delegate confirm DORA coverage","instructions":"**Objective** — Extend the core framework with a documented ICT risk-management framework and digital operational-resilience strategy so critical ICT services are governed to DORA's standard.\n\n**Inputs**\n- The core ERM framework design and enterprise risk-tolerance statements from \"Design core ERM framework\" (the framework design document on that step, anchored to the Process item) - the ICT risk tolerance links to them.\n- The inventory of the organization's critical or important ICT services (existing Process items, process_type: it_general_control or operational) and their third-party ICT dependencies - the cloud / SaaS providers behind those services - as existing Vendor items (category: cloud_infrastructure or saas_software, tier, data_classification, business_owner, risk_owner).\n- DORA's ICT risk-management requirements as the reference standard.\n\n**Procedure**\n1. Document an ICT risk-management framework that covers, for each critical ICT service, all six capabilities: identification, protection, detection, response, recovery, and learning and evolving.\n2. Define the digital operational-resilience strategy and the ICT risk tolerance, explicitly linking the ICT tolerance to the enterprise risk tolerance set in the core design so the two are consistent.\n3. Document how ICT risk is identified, contained, and recovered across critical services and third-party dependencies.\n4. Assign clear ICT-risk roles: the accountable executive (e.g. CISO or head of operational resilience), the management-body oversight, and the first-line service owners; specify the supporting budget and resources the framework requires.\n5. Establish the review cadence - the management body reviews the ICT framework at least annually and after major changes or incidents - and record that the management body approves the framework and remains accountable for its effectiveness.\n\n**Record in AssureSwarm** — Upload the ICT operational-resilience (DORA) extension as the step document (document upload). Link the anchor Process item to the critical-ICT-service Process items it governs (Process ↔ Process item relationship; items link). Critical ICT services are represented as Process items (process_type: it_general_control or operational); their third-party ICT dependencies (cloud / SaaS providers) are Vendor items (Vendor — category: cloud_infrastructure or saas_software, tier, data_classification, business_owner, risk_owner, monitoring_status), created where missing and linked to the anchor and their governed ICT-service Process items (item create, items link).\n\n**Exit criteria** — The resilience owner and a management-body delegate confirm the ICT framework covers all six resilience capabilities for the critical services, that the strategy, tolerance, roles, budget, and at-least-annual review cadence are defined, and that management-body accountability is explicit and DORA-aligned.","label":"Extend ICT operational-resilience framework","performedBy":{"primitives":["coach-document-upload","coach-item-create","coach-items-link"]}},"id":"extend-ict-operational-resilience-framework"},{"data":{"decisionField":"tech_extension_scope","description":"Agent evaluates whether regulated technologies such as high-risk AI systems are in scope and drafts the applicability assessment; human decides whether lifecycle-specific risk processes must be added","formData":{"fields":[{"key":"tech_extension_scope","label":"Regulated-technology extension scope","options":[{"label":"Regulated technology such as high-risk AI is in scope","value":"ai_in_scope"},{"label":"No regulated-technology extension required","value":"none"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether the framework must be extended with lifecycle-specific risk processes for a regulated technology such as high-risk AI, or whether the core ERM and ICT-resilience processes already suffice. The regulated-technology governance owner owns this decision.\n\n**Decision criteria**\nTo reach a defensible pick, the agent first prepares the evidence: (1) inventory the organization's regulated or high-risk technologies - high-risk AI systems and other technologies carrying regime-specific lifecycle obligations - and map each to the risk regimes that apply, such as ISO 42001 or emerging AI regulation; (2) assess, for each in-scope technology, whether it needs lifecycle-specific risk processes beyond the core ERM and ICT-resilience processes already defined; (3) draft the applicability assessment with evidence and owner concurrence supporting the chosen disposition. Then select:\n- `ai_in_scope` (Regulated technology such as high-risk AI is in scope): the organization operates a regulated or high-risk technology carrying regime-specific lifecycle obligations (e.g. high-risk AI under ISO 42001 or emerging AI regulation) that the core ERM and ICT-resilience processes do not already govern - lifecycle-specific processes must be added.\n- `none` (No regulated-technology extension required): no such technology is in use, or the existing core and ICT frameworks already satisfy every applicable regime - no additional extension is needed this cycle.\n\n**Record in AssureSwarm** — There is no native technology / AI-system item type, so query the regulated-technology inventory best-effort from existing Process and Control items (query data) and attach the applicability-assessment evidence as a document link on this step. Submit the step form: `tech_extension_scope` SELECT with the chosen option, the decision rationale and evidence references in the step result, and the decision owner in the step's approver record.\n\n**Exit criteria** — The `tech_extension_scope` form is submitted with rationale and a named owner, and the branch not selected is prunable.","kind":"decision","label":"Scope regulated-technology extensions","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"scope-regulated-technology-extensions"},{"data":{"description":"Agent drafts the required lifecycle-specific risk processes for the in-scope regulated technology and integrates them into the framework; human governance owner confirms completeness","instructions":"**Objective** — Draft the required lifecycle-specific risk processes for the in-scope regulated technology and integrate them into the framework so the technology is governed consistently with the rest of the enterprise, not in isolation.\n\n**Inputs**\n- The applicability assessment and the selected `ai_in_scope` disposition from \"Scope regulated-technology extensions\".\n- The core ERM processes and risk-tolerance thresholds (the integration target) and the applicable regime (e.g. ISO 42001 or AI regulation) for the technology.\n\n**Procedure**\n1. Draft the required lifecycle-specific risk processes for the in-scope technology - for high-risk AI systems, cover the design, data governance, development, validation, deployment, post-market monitoring, and incident-response stages of the lifecycle.\n2. Define the accountabilities, controls, and evidence requirements for each lifecycle stage and assign owners across the three lines of defense.\n3. Integrate the lifecycle processes into the enterprise risk-management processes and the risk-tolerance thresholds so they are governed consistently with the rest of the framework rather than run separately.\n4. Update the framework document and the implementation plan to include the extension and its rollout steps.\n\n**Record in AssureSwarm** — Upload the regulated-technology lifecycle-extension as the step document (document upload). Create one Control item per lifecycle stage (Control — framework: iso-42001 and/or eu-ai-act, domains: ai_governance, control_owner: the stage owner across the three lines of defense) and link each to the anchor Process item (item create, items link).\n\n**Exit criteria** — The regulated-technology governance owner confirms the lifecycle risk processes are complete, mapped to the applicable regime, integrated with the enterprise framework, and ready to be packaged for management-body approval.","label":"Add regulated-technology lifecycle risk processes","performedBy":{"primitives":["coach-document-upload","coach-item-create","coach-items-link"]}},"id":"add-ai-lifecycle-risk-processes"},{"data":{"decisionField":"approval_decision","description":"Agent assembles the consolidated framework package and board brief; the management body decides on approval, sponsorship, and budget; human records the approval decision","formData":{"fields":[{"key":"approval_decision","label":"Management-body approval decision","options":[{"label":"Approved with sponsorship and budget","value":"approved"},{"label":"Revision required before approval","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — The management body decides whether to approve the consolidated framework and commit sponsorship and budget, or send it back for revision. The approving body or its delegate owns the decision.\n\n**Decision criteria**\nTo prepare the decision, the agent: (1) assembles the consolidated framework package - the core ERM design, the ICT operational-resilience extension, any regulated-technology lifecycle extension, the accountabilities map, the risk-tolerance statements, the resourcing and budget request, and the phased implementation plan; (2) cross-checks the package against an ISO 31000, COSO ERM, and DORA requirement checklist so no mandated element - leadership sponsorship, accountabilities, processes, tolerance, ICT resilience capabilities, budget, or review cadence - is missing; (3) drafts the management-body approval brief presenting the framework, the sponsorship and budget requested, the key risk-tolerance decisions, and the implementation timeline; (4) routes the brief to the management body and captures the deliberation record. Then record the outcome:\n- `approved` (Approved with sponsorship and budget): the management body approves the framework and commits the requested sponsorship and budget; no mandated element is missing and the tolerance, resourcing, and plan are acceptable.\n- `revise` (Revision required before approval): the framework, tolerance, resourcing, or plan must change first, or a checklist gap remains before approval can be given.\n\n**Record in AssureSwarm** — Upload the consolidated framework package and the management-body approval brief as documents on this step, and attach the deliberation record (document upload). Submit the step form: `approval_decision` SELECT with the outcome, the rationale, any conditions, and evidence references in the step result (conditions live here), and the approving body or delegate in the step's approver record.\n\n**Exit criteria** — The `approval_decision` form is submitted with rationale and a named owner, and the branch not selected is prunable.","kind":"decision","label":"Secure management-body approval","performedBy":{"primitives":["coach-document-upload","coach-items-link"]}},"id":"secure-management-body-approval"},{"data":{"description":"Agent applies the management body's conditions and revisions and re-secures sponsor sign-off; human sponsor confirms the conditions are resolved","instructions":"**Objective** — Apply the management body's conditions and revisions and re-secure sponsor sign-off so the revised framework can proceed to implementation.\n\n**Inputs**\n- The `revise` decision from \"Secure management-body approval\" with its recorded conditions, comments, and rationale.\n- The consolidated framework package and the ISO 31000 / COSO ERM / DORA requirement checklist used at approval.\n\n**Procedure**\n1. Translate the management body's comments and conditions into specific revisions to the framework design, accountabilities, risk tolerance, ICT-resilience extension, budget, or implementation plan.\n2. Apply the revisions to the framework documentation and record a change log showing what changed and why against the prior version.\n3. Re-run the requirement checklist to confirm the revisions did not reopen a gap and that every condition is addressed.\n4. Re-circulate the revised package to the executive sponsor and, where required, back to the management body for confirmation.\n\n**Record in AssureSwarm** — Upload the revised framework package and a change log as documents on this step (document upload); the change log records each management-body condition and how it was resolved against the prior version, and captures the executive-sponsor sign-off. This is not a decision node and has no step form, so the condition-by-condition sign-off is recorded in the change-log document rather than a form.\n\n**Exit criteria** — The executive sponsor confirms every condition and comment has been resolved, the change log is complete, and the revised framework is approved to proceed to implementation.","label":"Resolve approval conditions","performedBy":{"primitives":["coach-document-upload","coach-form-fill"]}},"id":"resolve-approval-conditions"},{"data":{"description":"Agent launches the implementation plan across the organization and tracks adoption milestones; human implementation owner confirms rollout is on plan","instructions":"**Objective** — Launch the approved framework across the organization on its planned schedule and track adoption against milestones until it is embedded.\n\n**Inputs**\n- The approved (or condition-resolved) framework package and implementation plan from \"Secure management-body approval\" or \"Resolve approval conditions\".\n- The approved budget and the named owners across the first, second, and third lines of defense.\n\n**Procedure**\n1. Launch the approved implementation plan on its planned schedule - communicate the framework and the risk-tolerance statements across the organization, and embed the accountabilities and risk-management processes into the first, second, and third lines of defense.\n2. Stand up the ICT operational-resilience capabilities and any regulated-technology lifecycle processes, allocating the approved budget and confirming the named owners have accepted their roles.\n3. Track adoption against the plan milestones - policies published, training delivered, processes operating, and tooling in place - and log implementation progress and evidence in the governance register.\n4. Surface implementation blockers and slipping milestones with proposed owners and dates.\n\n**Record in AssureSwarm** — There is no native Milestone/Task item type, so record implementation milestones with their owners and due dates in the implementation-plan section of the framework document on this step, and build an adoption / rollout tracking dashboard over the governance records to track them (dashboard create).\n\n**Exit criteria** — The implementation owner confirms the framework is being implemented across the organization on the planned schedule, that adoption milestones are tracked with evidence, and that blockers are owned and on a credible path to closure.","label":"Drive implementation rollout","performedBy":{"primitives":["coach-item-create","coach-dashboard-create"]}},"id":"drive-implementation-rollout"},{"data":{"description":"Agent compiles the framework-effectiveness review pack, archives the approved framework, implementation plans, and review evidence, and schedules the next review; human management-body delegate confirms the review meets the at-least-annual cadence and closes the cycle","instructions":"**Objective** — Run the at-least-annual review of the enterprise and ICT frameworks, assess their continuing effectiveness against current context, schedule the next review, and close the governance cycle on that review: the management-body delegate's confirmation recorded here is the closure.\n\n**Inputs**\n- The implemented framework and adoption evidence from \"Drive implementation rollout\".\n- Operating evidence accumulated since the last review: risk-tolerance breaches, incident and resilience-test outcomes, control performance, audit and assurance findings, and regulatory or context changes.\n- The complete cycle record for archiving: the approved framework documentation, the ICT operational-resilience extension, any regulated-technology extension, the management-body approval and conditions, and the implementation plan and progress.\n- The retention location and the applicable retention period.\n\n**Procedure**\n_Items 1-4 run the review; items 5-8 close the cycle (folded from the former \"Close and archive\" step) - the review conclusion confirmed here is the closure, with no separate confirmation._\n1. Compile evidence on how the enterprise and ICT frameworks are operating - risk-tolerance breaches, incident and resilience-test outcomes, control performance, audit and assurance findings, and regulatory or context changes since the last review.\n2. Assess the framework's continuing effectiveness and suitability against the organization's current context and objectives, and identify design gaps, tolerance recalibrations, or accountability changes needed.\n3. Prepare the review conclusions and any change recommendations for the management body, which remains accountable for the framework's effectiveness, and record the review as evidence that the cadence was met.\n4. Schedule the next at-least-annual review and any interim reviews triggered by major change or incident.\n5. Assemble the complete governance record for this cycle from the surviving artifacts above.\n6. Archive the approved framework documentation and implementation plans to the retention location with version, approval date, and the applicable retention period, and link them to the governance register.\n7. Update linked records - the risk-cycle workflows that run inside this framework, the policy library, and the control inventory - so downstream work references the current approved version.\n8. Communicate the approved framework, its effective date, and the next review date to stakeholders.\n\n**Record in AssureSwarm**\n- Scan the prior workflow instances and query the risk-cycle records (Risk / Issue / Control-hosted SOX testing workflows) for operating evidence (workflow scan, query data).\n- Create one Issue item for the review conclusion (Issue - issue_type: observation, source: self_assessment, recommendation: the change recommendations, issue_owner: the management-body delegate, identified_date: the review date, with the next review date noted in description) and link it to the anchor Process item (item create, items link).\n- Export the governance package to the retention location as a workflow-export document (PDF/ZIP; workflow export) and link it into the governance register (document link) - the archived workflow instance on the anchor Process item is itself the durable audit trail.\n- Link the anchor Process item (the governance register entry) both to the Control items that form the control inventory and to the relevant Policy items that form the policy library (Process ↔ Control and Process ↔ Policy item relationships; items link). This archived framework is what the downstream risk-cycle workflows (identify / assess / treat / monitor) reference as their governing baseline.\n\n**Exit criteria** — A management-body delegate confirms the review satisfies the at-least-annual cadence required for both the enterprise and ICT frameworks, that effectiveness has been assessed against current context, and that recommendations and the next review date are recorded; the archived record is self-contained and durable enough to serve as evidence to auditors and regulators without oral explanation - approved framework, accountabilities, tolerance, ICT-resilience extension, approvals, implementation plans, and review - and the governance cycle is formally closed.","label":"Run at-least-annual framework review","performedBy":{"primitives":["coach-workflow-scan","coach-query-data","coach-item-create","coach-items-link","coach-workflow-export","coach-document-upload"]}},"id":"run-annual-framework-review"}],"sourceTemplateId":"workflow-library:grc-risk-resilience-framework-governance"}