{"description":"Define enterprise risk appetite statements, tolerances, and KRIs, secure executive and board approval, monitor actuals against tolerances, and report the appetite position to the board. Runs as a standalone recurring instance per appetite cycle (typically annual): appetite spans the whole Risk register rather than a single item, so the register, tolerance and KRI matrix, monitoring workbook, and reporting pack attach to the workflow instance's steps as the versioned documents of record, with the existing Risk items as the linked reference data and KRI breaches recorded as Issue items (issue_type: exception, linked to their Risk). In scope: appetite-statement definition, tolerance and KRI design, executive validation, board approval, ongoing monitoring, and ERM board reporting. Out of scope: the enterprise-wide risk identification and scoring that produces the risk universe, and the assembly of the full quarterly board deck. Consumes the risk-assessment handoff package from the Enterprise Risk Assessment & Portfolio Oversight Cycle (the risk universe as Risk items plus inherent and residual ratings) rather than re-deriving it, and hands the board-approved appetite package to the Quarterly Board & Audit-Committee GRC Reporting workflow.","edges":[{"id":"e-validate-with-executives-obtain-board-approval","source":"validate-with-executives","target":"obtain-board-approval"},{"id":"e-obtain-board-approval-classify-disposition","source":"obtain-board-approval","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clear","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"complete"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"monitor"},{"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-handoff-to-related-workflow","label":"Approved","source":"approve-or-revise-package","target":"handoff-to-related-workflow","whenValue":"approved"},{"id":"e-resolve-approval-conditions-handoff-to-related-workflow","source":"resolve-approval-conditions","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-17","UC-RISK-03","UC-GOV-05","UC-RISK-13","UC-GOV-21"],"department":"executive","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-risk-appetite-board-reporting","contentDigest":"sha256:723ab74c727b8838bd39308f2744973e46edacb63b7c2394677b5adc452c10ed","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:723ab74c727b8838bd39308f2744973e46edacb63b7c2394677b5adc452c10ed","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-risk-appetite-board-reporting"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-risk-appetite-board-reporting","source":"coworkcanvas-gallery","standards":["coso-erm"],"teams":["executive","risk-management"]},"name":"Risk Appetite Definition & Board Reporting","nodes":[{"data":{"description":"Risk-category executives and CRO: Endorse strategy-aligned appetite and operable tolerances, stress-test calibrated warning thresholds and accept category accountability before board consideration.","instructions":"**Objective** — Draft the strategy-linked appetite statements and historically calibrated tolerances/KRIs, then secure executive endorsement of the complete package.\n\n**Inputs**\n- The risk-assessment handoff package from the Enterprise Risk Assessment & Portfolio Oversight Cycle: the risk universe lives as the existing Risk items (`Risk.category`, `Risk.inherent_rating`, `Risk.residual_rating`, `Risk.risk_owner`) and the packaged summary of top risks arrives as the upstream workflow's handoff document, linked at this step. Consume this package as an input; do NOT re-run the enterprise risk assessment here.\n- The board-approved strategy and objectives (uploaded at this step — no native type for strategy), the existing risk-appetite / ERM framework policy (a Policy item in the policy library — `policy_type: policy`, `framework: coso-erm`, `policy_owner`), and the prior-period appetite register (the XLSX attached to the prior cycle's archived instance).\n- The risk-category taxonomy — the `Risk.category` select options are the taxonomy (strategic, financial, operational, compliance, cyber, third-party, reputational, …) and `Risk.risk_owner` names the accountable owner per risk — plus the CRO or GRC lead and the committee that will approve. The category-owner assignment list itself is a document uploaded at this step.\n- The draft appetite-statement register document from \"Align appetite to strategy\".\n- Historical KRI and KPI series (uploaded as a CSV/XLSX at this step — no native KRI type), loss and incident history (the existing Issue items — `Issue.severity`, `Issue.identified_date`, `Issue.source`), and current control-coverage data (the existing Control items — `Control.key_control`, `Control.frequency`, `Control.control_owner` — and their Control↔Risk relationships).\n- Regulatory or board-imposed limits (capital, liquidity, concentration) and relevant industry benchmarks, uploaded as a document at this step.\n- The appetite-statement register and the tolerance and KRI matrix from the appetite and KRI drafting stages.\n- The list of accountable executives per risk category and the executive or risk-committee meeting slot.\n\n**Procedure**\n*Autonomous preparation incorporates Align appetite to strategy; Draft tolerances and KRIs; Risk-category executives and CRO reviews the combined evidence.*\n1. Lock the engagement plan first: confirm which risk categories are in scope this cycle, the accountable owner per category, due dates, evidence requirements, and the executive and board review calendar. Record any category deliberately excluded this cycle together with the owner who concurred.\n2. Map each strategic objective to the risk categories that threaten it, using the upstream risk universe. Every residual-high or top risk must map to at least one appetite statement so nothing material is left unstated.\n3. Draft one qualitative appetite statement per category using a directional stance (averse, minimal, cautious, open, or hungry) plus a one-sentence rationale tied to strategy. Worked example: \"Cyber: averse; we will not accept changes that could cause a reportable data breach or a customer-facing outage beyond four hours.\"\n4. Make each statement measurable-in-principle so the next step can attach tolerances and KRIs, ensure it names an owner, and confirm it is consistent with capital, liquidity, and regulatory constraints.\n5. Check internal consistency: flag any two statements that conflict (for example \"hungry for growth\" against \"averse to new-market exposure\") and add an explicit reconciliation note.\n6. Flag every statement that materially changes the prior-period stance, because those need extra executive and board attention.\n7. For each appetite statement define one or more tolerances, a numeric boundary that, if breached, means appetite is exceeded (worked example: \"single-counterparty exposure at most 10% of eligible capital\").\n8. Keep appetite (aggregate willingness) distinct from tolerance (a specific limit at business-unit or risk level); tolerances must ladder up to and never exceed the stated appetite.\n9. Select one to three KRIs per category that are leading (they predict a breach) rather than purely lagging; prefer indicators with a reliable data owner and monthly-or-better refresh.\n10. Set green, amber, and red thresholds per KRI, calibrating amber as an early-warning trigger before the red tolerance breach. Use the historical distribution (for example amber at the 80th percentile of the last eight quarters) and document the calibration basis.\n11. For each KRI record the data source, the data owner, the refresh frequency, and the escalation path on amber and on red.\n12. Validate coverage: every red threshold maps to a tolerance and every tolerance maps to an appetite statement, so there are no orphan metrics and no unmeasured statements.\n13. Prepare a concise executive walkthrough covering each statement, its tolerances and KRIs, what changed versus the prior period, and the resource and behavioural implications.\n14. Facilitate review with each risk-category owner and the executive or risk committee; confirm each owner accepts accountability for their statement and can operate within the stated tolerance.\n15. Stress-test the calibration: ask whether the amber and red thresholds would have flagged known past incidents, and adjust thresholds that prove too loose or too tight.\n16. Resolve conflicts between growth ambition and risk limits explicitly, and record the reconciliation rather than leaving it implicit.\n17. Log every change request with an owner and a disposition (accepted, rejected, or deferred), then update the register and the matrix accordingly.\n18. Obtain documented executive sign-off, or a defined list of open items each with an owner and due date, confirming the package is ready for board consideration.\n\n**Record in AssureSwarm**\n- Attach the draft appetite-statement register as a step document (XLSX) — one row per risk category holding the statement, stance, rationale, owner, linked strategic objective, and the upstream Risk items it traces to. There is no native appetite-statement item type among the eight Studio types, so the register lives as this versioned document (re-attached at each downstream step as the version of record), not as items.\n- Reference the risk universe by linking the register rows to the existing Risk items (`Risk.category`, `Risk.inherent_rating`, `Risk.residual_rating`, `Risk.risk_owner`); do not recreate them.\n- Attach the locked engagement plan as a step document, noting the in-scope categories, per-category owners, due dates, and any deliberately excluded category with the concurring owner.\n- Attach the tolerance and KRI matrix as a step document (XLSX): statement, tolerance, KRI, green/amber/red thresholds, data owner, and escalation path. There is no native KRI/metric item type, so the matrix lives as this document rather than as items.\n- Within the matrix, key each KRI row back to its parent appetite-statement row in the register so every threshold traces to a statement (document-internal linkage, since neither the KRI nor the statement is a Studio item).\n- Attach the executive review minutes, the sign-off, and the change-request log (each request with its disposition) as step documents.\n- Revise the appetite-statement register and the tolerance and KRI matrix with the agreed changes and re-attach them as the executive-endorsed version of record — these are documents, not items, so the \"management-endorsed\" status is carried by this version rather than by an item field.\n\n**Exit criteria**\nEndorse strategy-aligned appetite and operable tolerances, stress-test calibrated warning thresholds and accept category accountability before board consideration.\nEvery in-scope category has a drafted, owned appetite statement traceable to a strategic objective and to upstream risks; the engagement plan is locked with owners and due dates; changes versus the prior period are flagged.\nEvery appetite statement carries at least one tolerance and at least one KRI with calibrated thresholds, a data owner, and an escalation path; the calibration basis is documented; no orphan metrics remain.\nExecutive sign-off is recorded (or all open items are owned with due dates); the register and matrix reflect the agreed changes; the package is flagged ready for the board.","label":"Validate with executives"},"id":"validate-with-executives"},{"data":{"description":"Present the endorsed appetite framework to the board and obtain a formal approval resolution","instructions":"**Objective** — Present the executive-endorsed risk-appetite framework to the board or risk committee and obtain a formal approval resolution that sets the authorized appetite of record.\n\n**Inputs**\n- The management-endorsed appetite register and tolerance and KRI matrix.\n- The board or risk-committee charter defining approval authority, the prior board-approved appetite for comparison, and the scheduled board meeting.\n\n**Procedure**\n1. Assemble the board approval paper: the appetite statements, the key tolerances, the material changes versus prior year, and the rationale linking appetite to strategy.\n2. Distinguish decisions the board must actively make (for example an increase in appetite or a new category) from items presented for noting.\n3. Present, capture the board discussion, and record any board-directed amendments precisely enough to action them.\n4. Obtain a formal resolution (approved, approved with conditions, or deferred) together with the effective date.\n5. If the resolution is approved with conditions, log each condition, its owner, and its due date.\n6. Only an approved resolution establishes the new authoritative appetite and supersedes the prior version. A deferred resolution keeps the prior approved baseline in force and this approval checkpoint open; satisfy any blocking conditions before using the new thresholds.\n\n**Record in AssureSwarm**\n- Attach the board approval paper and the board minute or resolution (approver, effective date, and any conditions captured in the resolution document) as step documents.\n- Re-attach the appetite-statement register and matrix as the board-approved version of record — this becomes the authoritative baseline; there is no appetite item to carry an approval-status field, so the board-approved version supersedes the prior one.\n\n**Exit criteria** — A board resolution is recorded with an effective date; any conditions are logged and owned; the approved appetite register is versioned as the authoritative baseline.","label":"Obtain board approval"},"id":"obtain-board-approval"},{"data":{"decisionField":"disposition_path","description":"CRO or GRC lead: Judge current actuals, velocity, stale data and uncovered incidents, then classify the evidence-backed appetite position for clear, corrective or acceptance action.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Complete","value":"complete"},{"label":"Gaps require action","value":"gaps"},{"label":"Monitor without immediate action","value":"monitor"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Monitor actuals against the board-approved thresholds, escalate breaches and compile the exceptions-focused report for the CRO’s disposition.\n\n**Decision criteria**\nInputs for preparation: - The board-approved tolerance and KRI matrix (the version-of-record document with thresholds, data owners, and escalation paths).\n- The live data feeds or source systems for each KRI (external systems outside AssureSwarm — current-period extracts are uploaded as a CSV/XLSX at this step as evidence), plus the incident and issue logs (the existing Issue items).\n- The current appetite-position record and KRI RAG statuses from monitoring (the monitoring workbook document).\n- The breach and issue list with remediation status (the breach Issue items from monitoring), the board reporting template and cadence, and the prior pack for trend continuity.\n\n*Autonomous preparation incorporates Monitor actuals vs tolerances; CRO or GRC lead reviews the combined evidence.*\n1. Collect current-period actuals for every KRI from its named data source and confirm data completeness and timeliness, flagging any stale metric.\n2. Compare each actual to its green, amber, and red thresholds; classify the status per KRI and roll it up to a per-category and enterprise appetite position (within appetite, approaching, or exceeding).\n3. For every amber or red status trigger the defined escalation path and open or link an issue with an owner and remediation timing.\n4. Analyze trend and velocity, not just the point value; a metric moving quickly toward red matters even while it is still green.\n5. Reconcile against incident and loss data: any material incident with no corresponding KRI movement signals a KRI-coverage gap to note.\n6. Record the breaches, escalations, and the current appetite position with links to the underlying evidence.\n7. Build the appetite dashboard view: per-category RAG status, actual against tolerance, and trend arrows versus prior periods.\n8. Write a concise narrative for every amber and red: what breached, why, the impact, the action, the owner, and the expected return-to-green date.\n9. Summarize the enterprise appetite position and any cross-cutting theme (for example concentrated cyber or third-party pressure).\n10. Surface the decisions and escalations the board must act on (accept a breach, recalibrate a tolerance, fund remediation) distinctly from noting items.\n11. Ensure every number ties back to the monitoring evidence and is reproducible; avoid any unsupported assertion.\n12. Apply the house reporting format and reading level and keep it board-digestible — exceptions and decisions rather than raw data dumps.\n13. Read the assembled pack and classify the cycle against the criteria below, citing the specific KRI, breach, and appetite-position evidence that drives the call.\n\n- `complete` (Complete): the appetite position is within tolerance across categories, there are no red breaches requiring action, and KRIs are current. Proceed straight to preparing the final package.\n- `gaps` (Gaps require action): one or more red breaches or unresolved tolerance exceedances need an owned, time-bound remediation plan before closure.\n- `monitor` (Monitor without immediate action): an amber or emerging pressure, or a breach the organization may knowingly accept, needs a formal escalate-or-accept decision rather than a remediation project.\n\n**Record in AssureSwarm**\n- Attach the monitoring workbook as a step document (XLSX): each KRI's current actual against its green/amber/red thresholds, the per-KRI RAG status, and the rolled-up per-category and enterprise appetite position. There is no native KRI item or dashboard, so the workbook carries the actuals and the appetite position.\n- For every amber or red breach, create an Issue (`issue_type: exception`, `source: management_identified`, `severity` per the RAG level, `identified_date`, `description` naming the KRI and the exceedance) and relate it to the breached category's Risk item (`Issue ↔ Risk`).\n- Trigger the defined escalation path for each breach and link its evidence extract to the breach Issue.\n- Attach the rendered ERM board reporting pack as a step document (PDF/PPTX) and link it to the breach Issue items and the monitoring workbook; state the report period and reporting status in the pack itself — the pack is a document, not an item with period/status fields.\n- Submit the `disposition_path` SELECT. In the step result cite the specific KRI, breach, and appetite-position evidence driving the choice; name the decision owner in the step's approver record.\n\n**Exit criteria**\nJudge current actuals, velocity, stale data and uncovered incidents, then classify the evidence-backed appetite position for clear, corrective or acceptance action.\nAll KRIs are refreshed with current actuals and RAG status; every amber and red breach is escalated and issue-linked; the enterprise appetite position is recorded with evidence.\n\n\nThe pack is assembled with per-category RAG, exception narratives, the enterprise position, and a clear decision list, every figure traceable to monitoring evidence; the form is submitted and the two unchosen branches are prunable because the branch edge whenValues match the selected value.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles and renders the board reporting pack from the monitoring items and open issues.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-workflow-scan","coach-query-data","coach-render-package"]}},"id":"classify-disposition"},{"data":{"description":"Produce owned, time-bound remediation plans for each red breach or tolerance exceedance","instructions":"**Objective** — Produce an owned, time-bound remediation plan for each red breach or tolerance exceedance so the appetite position can return within tolerance.\n\n**Inputs**\n- The breach and exceedance list and the appetite-position record from monitoring and the reporting pack.\n- The disposition decision (gaps) and its rationale, plus the issue records already opened for the breaches.\n\n**Procedure**\n1. For each gap document the root cause (a control failure, a miscalibrated threshold, or a genuine increase in risk) rather than the symptom.\n2. Define the corrective action, the accountable owner, the due date, and an interim mitigation that holds the risk while the fix is built.\n3. Specify the validation evidence that will prove the action closed the gap and name the KRI it should move.\n4. Set the reporting cadence and the trigger that would re-escalate the gap if it worsens or slips.\n5. Separate breaches that need remediation from those the board may knowingly accept, routing acceptances to the escalate-or-accept path rather than a plan.\n6. Link each action to its breach issue and to its parent appetite statement.\n\n**Record in AssureSwarm**\n- Enrich each existing breach Issue (created at \"Monitor actuals vs tolerances\") rather than creating a new item: set `Issue.root_cause`, `Issue.remediation_plan`, `Issue.issue_owner`, and `Issue.target_remediation_date`; record the interim mitigation and reporting cadence in `Issue.remediation_plan` and the validation evidence in `Issue.recommendation`.\n- Confirm each breach Issue is related to the breached category's Risk item (`Issue ↔ Risk`) so the action plan traces to its parent risk.\n\n**Exit criteria** — Every gap has an owned, dated action with an interim mitigation and defined validation evidence, all linked to their breach issues.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Bring an emerging or accepted breach to the right authority for a documented escalate-or-accept decision","instructions":"**Objective** — Bring an emerging or knowingly-accepted breach to the appropriate authority for a documented escalate-or-accept-risk decision, with conditions, an expiry, and follow-up ownership.\n\n**Inputs**\n- The appetite-position record and the specific breach or emerging pressure from monitoring.\n- The disposition decision (monitor) rationale and the escalation-authority matrix (risk owner, GRC lead, executive sponsor, or board delegate).\n\n**Procedure**\n1. Quantify the exposure: the likelihood, the impact range, and how far the actual sits beyond tolerance (or its velocity toward it).\n2. Determine the correct authority for the severity per the appetite governance and escalation matrix.\n3. Prepare a decision memo stating the risk, the options (reduce, accept, or transfer), the recommendation, and the conditions attached to any acceptance.\n4. Obtain the escalate-or-accept decision; if accepted, record the acceptance rationale, the boundary or expiry of the acceptance, and the monitoring trigger that reopens it.\n5. Assign follow-up ownership and a review date, ensuring the acceptance is time-bounded rather than permanent.\n6. Link the decision to the affected appetite statement and to the monitoring evidence.\n\n**Record in AssureSwarm**\n- Attach the escalate-or-accept decision memo as a step document (the risk, the options, the recommendation, and the conditions on any acceptance).\n- If the breach is knowingly accepted, record it natively as a risk acceptance: set the breach Issue to `issue_type: policy_exception` with `exception_approver` (the deciding authority) and `exception_expiry_date` (the time-bound boundary of the acceptance — the filterable expiry index), and set `treatment: accept` on the affected Risk item, relating the two (`Issue ↔ Risk`). The monitoring trigger that reopens the acceptance is noted in the memo.\n- If the decision is instead to reduce or transfer, route the breach to an action plan and leave `Risk.treatment` unchanged.\n\n**Exit criteria** — A documented escalate-or-accept decision by the correct authority exists with conditions, an expiry, and a follow-up owner, all linked to the evidence.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Accountable final package approver: Approve the evidence-linked complete cycle conclusion and conditions or require a corrected 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** — Assemble the internally consistent appetite-cycle package and obtain its accountable approve-or-revise decision.\n\n**Decision criteria**\nInputs for preparation: - The approved appetite register and tolerance and KRI matrix, and the board reporting pack.\n- The disposition decision and rationale, plus the action-plan items (if the disposition was gaps) and/or the escalate-or-accept memo (if the disposition was monitor), and any open constraints.\n\n*Autonomous preparation incorporates Prepare final package; Accountable final package approver reviews the combined evidence.*\n1. Assemble the package: appetite statements with tolerances and KRIs, the current appetite position, the board reporting pack, the disposition, and the resulting action plans or risk acceptances.\n2. Reconcile the disposition path with its artifacts: a gaps disposition must carry action plans, a monitor disposition must carry an accept-or-escalate memo, and a complete disposition must show a clean within-tolerance position.\n3. Summarize the unresolved constraints, open conditions, and assumptions the approver must weigh.\n4. State the proposed conclusion or recommendation put forward for approval.\n5. Verify every claim links to evidence and every prior decision (board approval, escalations, acceptances) is captured.\n6. Run a completeness check against the engagement plan's evidence requirements.\n\n- `approved` (Approved): the package is complete, evidence-backed, consistent with its disposition path, and any conditions are acceptable. Proceed to record the approval decision.\n- `revise` (Revision required): there is missing evidence, an unresolved condition, an inconsistent disposition, or a conclusion the approver cannot support. Route to resolve the approval conditions before the decision is recorded.\n\n**Record in AssureSwarm**\n- Attach the compiled final appetite package as a step document, with links to all constituent artifacts (the board-approved register and matrix, the monitoring workbook and reporting pack, the disposition form, and the action-plan Issues or the escalate-or-accept memo).\n- Note the package status (ready-for-approval) and the open constraints in the package itself — the package is a document, not an item with a status field.\nSubmit the `approval_path` SELECT. In the step result cite the specific gaps or conditions, or the basis for approval; name the approver in the step's approver record.\n\n**Exit criteria**\nApprove the evidence-linked complete cycle conclusion and conditions or require a corrected package.\nA single decision-ready package is assembled, internally consistent with the disposition path, evidence-linked, with a proposed conclusion and open constraints stated.\nThe form is submitted and the unchosen branch is prunable because the branch edge whenValues match the selected value.","kind":"decision","label":"Approve or revise package"},"id":"approve-or-revise-package"},{"data":{"description":"Address every reviewer comment and approval condition and update the package","instructions":"**Objective** — Address every reviewer comment and approval condition raised by the approve-or-revise decision and update the package so the final approval can be recorded.\n\n**Inputs**\n- The approve-or-revise decision (revise) and the specific gaps or conditions it cited.\n- The final package and its constituent artifacts.\n\n**Procedure**\n1. Convert each reviewer comment and condition into a discrete, owned to-do.\n2. Resolve each one: supply the missing evidence, revise the conclusion, update the action plan or risk acceptance, or recalibrate a threshold as directed.\n3. Document what changed and why, keeping a change log against the prior package version.\n4. Re-run the completeness and internal-consistency checks from the package assembly stage.\n5. Obtain the approver’s actual approval of the corrected version after each condition is addressed; retain any residual disagreement and keep the checkpoint open until approval is granted.\n\n**Record in AssureSwarm**\n- Update the final package and its constituent documents and attach the change log resolving each cited condition as a step document.\n- Note the package status (resubmitted-for-approval) in the updated package — documents, not item fields.\n\n**Exit criteria** — Every cited condition is resolved and logged; the updated package passes the completeness and consistency checks; the corrected package is approved and ready for that actual decision to be recorded.","label":"Resolve approval conditions"},"id":"resolve-approval-conditions"},{"data":{"description":"Quarterly Board Reporting receiving owner: Accept the approved appetite position and carried breaches for reporting; record the existing approval, archive the accepted input and schedule monitoring.","instructions":"**Objective** — Record the exact approved appetite package and transfer its position, thresholds and open conditions to board reporting, then archive and schedule continuing monitoring.\n\n**Inputs**\n- Either the directly-approved package or the condition-resolved package with its change log.\n- The approver's identity and authority.\n- The locked approved package, the record of the approval decision, and all constituent artifacts and evidence (register and tolerance/KRI matrix, monitoring workbook, reporting pack, action plans or acceptances).\n- The intake expectations of the Quarterly Board & Audit-Committee GRC Reporting workflow.\n\n**Procedure**\n*Autonomous preparation incorporates Record approval decision; Quarterly Board Reporting receiving owner reviews the combined evidence.*\n1. Record the approver name and role, the approval date, and the exact version approved.\n2. Capture any residual conditions together with their owners and due dates.\n3. Note the follow-up ownership for ongoing monitoring and for the next review cycle.\n4. Confirm the recorded decision reconciles with the board resolution and with any escalations or risk acceptances.\n5. Lock the approved package version as the governance record.\n6. Create or link the Quarterly Board & Audit-Committee GRC Reporting workflow instance for the period.\n7. Pass the approved appetite statements, the current appetite position, the breaches and actions, and the board-approved thresholds as its input package.\n8. Note the assumptions and state what the downstream workflow should not repeat; it consumes this appetite position rather than redefining appetite.\n9. Identify any open items the downstream workflow must track, such as unresolved breaches or conditional approvals.\n10. Confirm downstream receipt and linkage with the receiving owner.\n11. Archive the final approved package and all evidence in the retention-controlled location per policy.\n12. Update linked records — the appetite-register version, the risk-universe references, and the issue and action links — to point to the approved baseline.\n13. Schedule the ongoing KRI monitoring cadence and the next appetite review, typically annual or on a material strategy or risk-change trigger.\n14. Communicate the board-approved appetite and any conditions to the accountable owners and stakeholders, and verify the audit trail is complete: every decision, approval, and change traceable end to end.\n\n**Record in AssureSwarm**\n- Attach the final, locked approved appetite package as a step document, and record the approver, role, approval date, exact version approved, and any residual conditions in the closing note on this step (the approval selection itself was captured on the \"Approve or revise package\" form).\n- Note the follow-up owners and the next-review date so the final handoff can schedule them.\n- Link this workflow's locked appetite package to the Quarterly Board & Audit-Committee GRC Reporting workflow instance (the handoff package its first step consumes).\n- Attach a handoff note as a step document listing the contents (approved statements, current appetite position, breaches and actions, board-approved thresholds), the assumptions, and the non-duplication scope.\n- Close and archive the workflow instance as the audit trail of record, recording the retention location, the next-review date, and the ongoing KRI monitoring cadence in the closure note.\n- Log the closure communication (the `/coach-notify` output) on this step, and confirm the linked records — the appetite register version, the referenced Risk items, and the breach Issues — point to the approved baseline.\n\n**Exit criteria**\nAccept the approved appetite position and carried breaches for reporting; record the existing approval, archive the accepted input and schedule monitoring.\nThe approval decision is recorded with approver, date, version, and conditions; the approved package is locked; follow-up ownership and the next review are captured.\nThe approved package is linked to the Quarterly Board & Audit-Committee GRC Reporting workflow with a handoff note, open items flagged and receipt confirmed; the package is archived with a complete audit trail; linked records point to the approved baseline; the next review and the KRI monitoring cadence are scheduled and the closure is communicated.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` sends the board-approved appetite, conditions, and handoff notice to the accountable owners, stakeholders, and the downstream reporting owner.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-notify"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:grc-risk-appetite-board-reporting"}