{"description":"Enterprise Risk Register Lifecycle as a decision-aware workflow. This is a standalone recurring instance (quarterly or annual) that runs against the existing Risk item population — the enterprise risk register itself — enriching those Risk items in place rather than recreating a register: per-risk results are written onto the individual Risk items, and cycle-level deliverables attach to the workflow instance's steps. In scope: maintaining the register across the confirmed entities, business units, and risk-taxonomy categories for this cycle — intake and deduplication of new risks, Three-Lines ownership, control and assurance mapping, KRIs, periodic review and escalation, and retirement. Out of scope: any entity, unit, or category not named in this cycle's confirmed scope. It consumes the candidate-risk handoff package from the upstream Risk Register Intake workflow and hands its maintained register, residual positions, and escalations to two downstream workflows — Enterprise Risk Assessment & Portfolio Oversight Cycle (the maintained register, the concentration and correlation flags, and the residual positions) and Risk Appetite Definition & Board Reporting (the above-appetite entries, the escalations, and the acceptances) — rather than duplicating repeated work.","edges":[{"id":"e-assign-three-lines-owners-review-and-escalate","source":"assign-three-lines-owners","target":"review-and-escalate"},{"id":"e-review-and-escalate-classify-disposition","source":"review-and-escalate","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-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","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-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-escalate-or-accept-risk-handoff-to-related-workflow","source":"escalate-or-accept-risk","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{"UC-GOV-38":"operates"},"controls":["UC-RISK-10","UC-RISK-09","UC-RISK-13","UC-RISK-05","UC-GOV-38"],"department":"risk-management","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-enterprise-risk-register-lifecycle","contentDigest":"sha256:c93ca4af1ef0fb0829dc57626fed632b72751eed20f08bb8b59f66e7fa0ac457","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:c93ca4af1ef0fb0829dc57626fed632b72751eed20f08bb8b59f66e7fa0ac457","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-enterprise-risk-register-lifecycle"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-enterprise-risk-register-lifecycle","source":"coworkcanvas-gallery","standards":["coso-erm","iso-31000"],"teams":["risk-management"]},"name":"Enterprise Risk Register Lifecycle","nodes":[{"data":{"controls":["UC-GOV-38"],"description":"Named first-line risk owners and governance role holders, coordinated by second line: Resolve deduplication and activity-level ownership, obtain each role’s acceptance and approval, and prevent gaps, self-assurance or outsourced-accountability loss.","instructions":"**Objective** — Fix the register scope, structure and deduplicate candidate risks, then authorize distinct Three Lines, external and board responsibilities for each entry.\n\n**Inputs**\n- Consumes the candidate-risk handoff package from the upstream **Risk Register Intake** workflow — a document on that workflow's handoff step, linked (not re-derived) here — carrying the candidate risks and their source references.\n- The existing enterprise risk register — the **Risk items** already in the tenant (`description`, `category`, `taxonomies`, `likelihood`, `impact`, `inherent_rating`, `residual_rating`, `treatment`, `risk_owner`) — the subject this cycle maintains in place.\n- The confirmed in-scope population — entities, business units, and risk-taxonomy categories; the taxonomy categories are the `Risk.category` / `Risk.taxonomies` select options, while entities and business units have no native type and are carried as scope text in the locked workplan.\n- The Three-Lines owner registers (first, second, and third line); only `Risk.risk_owner` (first line) has a native field — second- and third-line come in as an owner-register extract attached to this step.\n- The criteria basis — the likelihood and impact scales (embodied in the `Risk.likelihood` / `Risk.impact` / `Risk.inherent_rating` / `Risk.residual_rating` select fields) and the appetite and tolerance thresholds (no native field — recorded in the locked workplan document) — plus the reporting or assurance reliance for this cycle.\n- The in-scope candidate risks from the locked workplan and their source references (issues, incidents, audit findings, horizon scans).\n- The risk taxonomy, the likelihood and impact scales, and the appetite thresholds for this cycle.\n- The existing register, to write into a consistent schema and to compare new entries against for duplicates.\n- Related records: issues, incidents, audit findings, controls, obligations, and strategic objectives.\n- The deduplicated register and the organization hierarchy.\n- The Three Lines Model roles: first line (management that owns and manages the risk), second line (risk and compliance oversight), third line (internal audit assurance).\n- The system and process owner registers, for aligning ownership to where the risk actually lives.\n- The annual review calendar and evidence of any significant organizational or responsibility change since the prior review.\n\n**Procedure**\n*Autonomous preparation incorporates Lock executable workplan; Intake and deduplicate risks; Named first-line risk owners and governance role holders, coordinated by second line reviews the combined evidence.*\n1. Confirm the final in-scope population — risks, entities, controls, KRIs — and that nothing in scope was left unowned.\n2. Assign owners and due dates per activity: intake, deduplication, ownership confirmation, control mapping, KRI definition, and review. Set the review cadence per entry (the default 180-day staleness threshold that the owner-review checkpoint enforces, tightened for high or above-appetite risks).\n3. State evidence requirements: what each rating change must cite, where assessment support lives, and the sign-off expected at escalation and closure.\n4. Set review expectations: who reviews ratings, who approves escalations, and the risk-committee or board reporting points this cycle feeds.\n5. Lock the plan and record it as the baseline, so later changes are tracked as dated deltas rather than silent edits.\n6. Write each risk as a cause-event-consequence statement, not a topic label: \"Because [cause], [uncertain event] may occur, leading to [consequence].\" \"Cyber risk\" is a category, not a register entry.\n7. Classify to the taxonomy (strategic, operational, financial, compliance/legal, technology/cyber, third-party, people, ESG/reputational) and assign a unique risk ID.\n8. Assess inherent risk — before controls — on the standard scales: likelihood (for example 1-5 from rare to almost certain, anchored to frequency or probability) and impact (financial, operational, regulatory, reputational, safety). Record the driver behind each score, not just the number.\n9. Capture the source and date so the entry's provenance is auditable, and flag any risk that is velocity-sensitive (fast onset) or tied to a strategic objective for later prioritization.\n10. Establish inherent evidence first; authorize ownership later in this checkpoint and leave residual/control conclusions to the owner-review checkpoint.\n11. Detect duplicates across the portfolio: the same underlying risk stated by two business units, near-identical cause-event-consequence pairs, or a broad risk alongside its narrower instance. Search on cause and consequence, not just title wording.\n12. Resolve each match deliberately: merge true duplicates (preserving both source references), or model a parent-child relationship where one risk is a specific manifestation of another. Never silently delete — record which entry survived and why.\n13. Link each surviving risk to its related records: originating issues and incidents, mapped controls (detailed during owner review), affected strategic objectives, and any regulatory obligation it bears on.\n14. Flag concentration and correlation: risks that share a common cause or that aggregate into a larger exposure — this is the input the portfolio-oversight workflow relies on.\n15. Assign a first-line risk owner to each entry: the accountable manager who owns the process or objective the risk bears on and has authority to act on treatment. Ownership sits with a named person, not a committee or a function.\n16. Assign second-line oversight (the risk and compliance function) responsible for challenge, aggregation, and monitoring — distinct from the first-line owner.\n17. Confirm third-line independence: internal audit provides assurance and must not own or manage the risk it audits. No one assures their own risk.\n18. Resolve conflicts and gaps: a risk spanning several units gets a single accountable owner plus named contributors; an orphan risk with no natural owner escalates to the risk committee rather than defaulting to the GRC team.\n19. Confirm each named owner accepts the assignment — an unacknowledged owner is not an owner.\n20. Assign external-assurance and board responsibilities by ERM activity alongside the first-, second-, and third-line roles; distinguish assurance, oversight, approval, and governance responsibilities.\n21. Record each named owner's acknowledgements and activity-level approvals; escalate a missing acknowledgement or approval before the assignment is effective.\n22. Review the activity map for ownership gaps, duplication, and self-assurance; resolve or escalate each collision before the risk proceeds.\n23. Confirm that outsourcing a risk, control, or assurance activity does not transfer accountability from the named first-line owner or the board.\n24. Review every assignment at least annually and upon significant organizational or responsibility change; record the change trigger, assignment delta, and governance review and approval before the revised assignment becomes effective.\n\n**Record in AssureSwarm**\n- Build the workflow steps with owners and due dates, and assign them.\n- Attach the locked workplan (scope, owners, dates, evidence requirements, review points) to the step (document upload).\n- Create a **Risk item** per new in-scope risk — the item is the unique register entry; set `Risk.description` (the cause-event-consequence statement), `Risk.category`, `Risk.taxonomies`, `Risk.likelihood`, `Risk.impact`, and `Risk.inherent_rating`. The score drivers and the source reference have no dedicated field — record them in `Risk.description`.\n- Item relationships — link each surviving Risk to its originating **Issue items** (issues and audit findings), and set a parent Risk ↔ child Risk link where one risk is a specific manifestation of another. Incidents, strategic objectives, and obligations have no native type — reference them in the entry description and the step notes, not as links.\n- Update `Risk.description` / `Risk.category` on merged and parent-child entries so the surviving statement is correct; record the dedup decisions (merged, parented, kept distinct) with rationale on the step, along with the concentration and correlation flags for portfolio oversight.\n- Item field update — set `Risk.risk_owner` (the named first-line owner) on each Risk item. Second-line oversight and third-line assurance references have no native Risk field — record them on this step as an owner-assignment log against each risk ID.\n- Assign the owning workflow steps and notify each owner of their accountability.\n- Record the external and board roles, each acknowledgement and approval, the gap/duplication/self-assurance review, and the accountability retained when work is outsourced in the owner-assignment log.\n- Retain the review date, change trigger, assignment delta, governance review and approval, approver, and effective date in the owner-assignment log.\n\n**Exit criteria**\nResolve deduplication and activity-level ownership, obtain each role’s acceptance and approval, and prevent gaps, self-assurance or outsourced-accountability loss.\nFinal scope, owners, due dates, evidence requirements, and review expectations confirmed and locked; review cadence set per entry; the baseline recorded so downstream changes are tracked as deltas.\nEvery in-scope risk exists as a structured register entry with a unique ID, a taxonomy category, a cause-event-consequence description, and an inherent assessment whose score drivers are recorded; no unresolved duplicate remains; merges and parent-child links are recorded with rationale; each risk is linked to its related records; concentration and correlation flags are captured for portfolio oversight.\nEvery entry has a named, acknowledged first-line owner, second-line oversight, and a third-line assurance reference; independence is preserved (no self-assurance); orphan and cross-cutting risks are escalated or resolved to a single accountable owner; external and board responsibilities are recorded, and outsourcing does not transfer accountability. The review occurred at least annually and upon any significant organizational or responsibility change, with the change trigger, assignment delta, governance review and approval retained before assignments became effective.","label":"Assign Three Lines owners","performedBy":{"primitives":["coach-workflow-build","coach-workflow-assign","coach-document-upload","coach-item-create","coach-form-fill","coach-query-data","coach-items-link","coach-item-update","coach-notify"]},"roleIntegrity":{"decisionOwner":"Named first-line risk owner","ermPhase":"cross_cutting","independenceRequired":false,"lineRole":"second","serviceMode":"administrative"}},"id":"assign-three-lines-owners"},{"data":{"description":"Accountable first-line risk owners with risk-function challenge: Judge control effectiveness, residual/KRI evidence and current activity and personally approve, re-score or reject each cited rating delta.","instructions":"**Objective** — Prepare control, assurance and KRI evidence and obtain each risk owner’s decision on the current register and proposed rating changes.\n\n**Inputs**\n- The deduplicated register entries with their inherent assessments.\n- The control inventory or library and control-effectiveness evidence (test results, SOX and ITGC status, second-line reviews).\n- Assurance sources: internal audit coverage, external audit, regulatory exams, and second-line monitoring.\n- The appetite thresholds from the criteria basis.\n- The residual-rated register with appetite positions.\n- Available metrics and data sources (operational, financial, control, external) that could serve as leading indicators.\n- The appetite and tolerance thresholds, to anchor KRI limits.\n- The current register with every entry's last-reviewed date and its review cadence.\n- Activity since each entry's last review: new issues, audit findings, regulatory changes, incidents, and relevant external or news events.\n- The likelihood and impact scales and the appetite thresholds, so refreshed scores stay on the same criteria.\n\n**Procedure**\n*Autonomous preparation incorporates Map controls and assurance; Define KRIs and cadence; Accountable first-line risk owners with risk-function challenge reviews the combined evidence.*\n1. Link each risk to the controls that mitigate it — preventive and detective — and identify risks with no mapped control (a bare inherent exposure) and controls mapped to no risk (candidate redundancy).\n2. Judge control adequacy against the risk: design (would the control, operating as intended, address the cause or the consequence?) and operating effectiveness (does evidence show it works?). Do not credit an untested or failing control in the residual calculation.\n3. Derive residual likelihood and impact from inherent minus demonstrated control effect — residual should move only as far as the evidence supports. A \"residual well within appetite\" resting on untested controls is false comfort; flag it.\n4. Map assurance: which line or party last tested each key control and when, so coverage gaps (a key control on a top risk with no recent assurance) are visible.\n5. Compare residual to appetite and flag entries above appetite or tolerance for the disposition step.\n6. Select which risks need KRIs — prioritize top residual risks, entries near or above appetite, and velocity-sensitive risks. Not every risk needs a KRI; a KRI on a trivial risk is noise.\n7. Choose leading indicators, not lagging counts where possible: a KRI should move before the risk materializes (for example a trend in failed logins ahead of a breach, or the aging of past-due obligations ahead of a compliance failure). Tie each KRI to the risk's cause or consequence.\n8. Set thresholds calibrated to appetite: green, amber, and red bands where red aligns to the tolerance limit and amber gives lead time to act. State the measurement, the source, the formula, and the owner responsible for reporting it.\n9. Set the monitoring cadence per KRI (daily, weekly, monthly, quarterly) to the indicator's volatility, and set each register entry's review cadence — the default 180-day staleness threshold the owner-review checkpoint enforces, tightened for high or above-appetite risks.\n10. Define the breach response: who is notified and what happens when a KRI hits amber or red, so a breach triggers action, not just a color change.\n11. Surface stale entries: flag every entry whose last-reviewed date is older than its review cadence (default 180 days), and group the stale set by risk owner. Optionally draft a review prompt for each owner summarizing their stale entries.\n12. For each entry being refreshed, pull the related activity since its last review and use it to propose an updated description and updated likelihood and impact scores.\n13. Present each update as a clear before-and-after difference — old versus proposed description and scores — so the owner reviews a delta, not a rewrite.\n14. Require evidence for every rating change: each proposed change must cite at least one concrete piece of evidence (an issue, an audit finding, a regulatory change, an incident, or a news event). Never change a rating without a citation.\n15. Do not write refreshed ratings straight into the register. Have each first-line risk owner review the proposed change in the native result and respond in their own words, with acceptance or rejection in native approvals — approve, re-score, or reject, with the change in their area and the evidence behind their assessment. Only owner-approved changes take effect.\n16. Chase non-responses rather than defaulting them: an entry whose owner does not answer stays stale and is escalated with the disposition, never silently re-dated.\n\n**Record in AssureSwarm**\n- Item relationships — link each Risk ↔ its mitigating **Control items** (preventive and detective), and map assurance by linking Risk ↔ the **Audit items** that cover it and Risk ↔ each Control whose directly hosted **SOX testing workflow** supplies the Test-step effectiveness evidence. Flag any Risk with no linked Control (bare inherent exposure) and any Control linked to no Risk (candidate redundancy).\n- Item field update — set `Risk.residual_rating` (and adjust `Risk.likelihood` / `Risk.impact` where the residual position shifts them) from demonstrated control effect, not assumed. The control-effectiveness basis and the appetite position (within or above appetite) have no native Risk field — record them on the step and carry the above-appetite flags into the disposition rationale.\n- Step document — record the KRI definitions in a **KRI definition register** attached to this step (XLSX/CSV): per KRI the measurement, source, formula, green/amber/red thresholds, cadence, breach-response routing, owner, and the risk ID it serves. There is no native KRI item type, so this document (not an item) is the KRI record.\n- Dashboard — build or refresh the **KRI monitoring dashboard** and link it to the workflow.\n- Each register entry's review cadence has no native Risk field — record it (the default 180-day threshold, tightened for high or above-appetite risks) in the same KRI/review-cadence document on this step; the review stage reads its staleness check from that log.\n- Record the list of stale entries grouped by owner on this step — Risk has no last-reviewed or review-cadence field, so the 180-day staleness check runs off the step-recorded review log, not a queryable field.\n- The accountable first-line risk owner’s native result and approval capture their per-risk review: whether the exposure is still live, their response to the proposed likelihood/impact change, their own scores and the rationale and evidence behind them, whether treatment or controls need to change, and the date they completed the review.\n- Record each proposed rating change as a before-and-after delta with its evidence citation(s) and its approval status (pending or owner-approved), routed to the owner rather than written directly into the register.\n- Only once approved, land each change as an Item field update on its Risk — `Risk.likelihood`, `Risk.impact`, `Risk.residual_rating`, and/or `Risk.description` — and stamp the new last-reviewed date in the step review log.\n\nRecord in the native step result or attached source documents: Risk ID under review (risk_id_reviewed); Is this risk still a live exposure for your area? (still_relevant); Your response to the proposed likelihood/impact change (rating_response); Likelihood you assess (1-5) (owner_likelihood); Impact you assess (1-5) (owner_impact); What changed in your area since the last review, and the evidence behind your assessment (owner_rationale); Does the current treatment or control set need to change? (treatment_change_needed); Date you completed this review (owner_review_date). Use native approvals for sign-off.\n\n**Exit criteria**\nJudge control effectiveness, residual/KRI evidence and current activity and personally approve, re-score or reject each cited rating delta.\nEvery risk is mapped to its controls (or flagged as unmitigated) and to its assurance coverage; residual assessment is evidence-based, not assumed; entries above appetite are flagged; assurance gaps on key controls are visible.\nPriority risks have leading KRIs with appetite-calibrated thresholds, named sources, owners, and cadence; each entry has a review cadence set; breach-response routing is defined; the KRI dashboard reflects current status.\nStale entries are surfaced to their owners; every refreshed rating is cited, presented as a before-and-after difference, and approved by the risk owner through native approval before taking effect; no proposed rating change is pending without at least one evidence citation; unanswered reviews are escalated rather than re-dated.\n\n\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` routes each owner's grouped stale-entry review prompt and proposed rating changes for approval, with a logged trail of who was asked and when.","label":"Review and escalate","performedBy":{"agent":"grc-artist","note":"Refresh ratings and flag stale entries","primitives":["coach-items-link","coach-item-update","coach-query-data","coach-item-create","coach-dashboard-create","coach-form-fill","coach-notify"]}},"id":"review-and-escalate"},{"data":{"decisionField":"disposition_path","description":"Classify the result of Enterprise Risk Register Lifecycle so the agent keeps only the relevant closure path","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** — Classify the maintained register's disposition so the cycle takes exactly one closure path: clean to the final package, gaps into an owned action plan, or monitor into a formal escalation or acceptance. The risk-function owner decides with the accountable risk owners.\n\n**Decision criteria**\n\nJudge the refreshed, owner-approved register against appetite and control coverage, and state counts in the rationale (how many entries fall to each path, in which categories, and how many are above appetite) so the selected branch sizes its work:\n\n- **Complete (`complete`)** — the register is current and within appetite: residual risks sit within tolerance, key controls are effective with assurance coverage, KRIs are green, and no entry needs a treatment action or an above-appetite decision. Route straight to the final package.\n- **Gaps require action (`gaps`)** — one or more risks need treatment: residual above appetite with a viable mitigation, an unmitigated risk (no effective control), an assurance gap on a key control, or a red KRI breach with a fixable cause. These need an owned action plan with root cause and dates. Route to create the action plan.\n- **Monitor without immediate action (`monitor`)** — a risk is above appetite or otherwise notable but no cost-justified treatment exists this period, so it is knowingly carried: it needs a formal risk acceptance or an escalation to the authority that can accept it, plus monitoring — not a remediation plan. Route to escalate or accept the risk.\n\n**Record in AssureSwarm**\n- Submit the decision form: `disposition_path` (the branch), the step result with the counts and the appetite basis, and the step's approver record.\n\n**Exit criteria** — Form submitted; the rationale reconciles entry counts to the chosen path and names above-appetite entries; the unused branches are prunable because branch edge values match the selected form value.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-query-data"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Turn each gap into an owned, dated action plan with root cause, interim mitigation, and validation evidence, so above-appetite and unmitigated risks have a credible path back within tolerance rather than an open flag.\n\n**Inputs**\n- The gap entries from the disposition decision, with their residual ratings and appetite positions.\n- The mapped controls and the assurance gaps for each risk.\n- The first-line owners and the treatment options (mitigate, transfer, avoid) available.\n\n**Procedure**\n1. Establish root cause for each gap — why residual sits above appetite, or why the control is absent or ineffective. Treating a symptom (a failed test) without the cause (a design gap) rebuilds the same gap next cycle.\n2. Choose the treatment strategy: mitigate (a new or strengthened control), transfer (insurance, contract), or avoid (exit the activity). Acceptance is not an action-plan outcome — that path is the monitor and escalation branch.\n3. Name a single accountable owner and a due date for each action; where the risk is live now, record an interim mitigation that holds until the fix lands.\n4. Define validation evidence up front: what will prove the action closed the gap and moved residual within appetite (a passing control test, a KRI returning to green) — decided before work starts, not chosen after.\n5. Set a reporting cadence so progress is visible to the risk committee, and link each action to its risk entry.\n\n**Record in AssureSwarm**\n- Item create — one **Issue item** per gap: set `Issue.issue_type` (`deficiency` for an above-appetite or unmitigated risk, `finding` where it came from assurance), `Issue.source: management_identified`, `Issue.root_cause`, `Issue.remediation_plan` (the treatment strategy, the interim mitigation, and the pre-defined validation evidence), `Issue.issue_owner`, and `Issue.target_remediation_date`.\n- Item field update — set `Risk.treatment` (`mitigate` / `transfer` / `avoid`) on the gap's Risk.\n- Item relationship — link each Issue ↔ its Risk.\n- Record the reporting cadence on the step.\n\n**Exit criteria** — Every gap has an owned, dated action plan with root cause, treatment strategy, an interim mitigation where needed, and pre-defined validation evidence; each plan links to its risk entry; the reporting cadence is set.","label":"Create action plan","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-item-update"]}},"id":"create-action-plan"},{"data":{"description":"Escalate to risk owner, GRC lead, executive sponsor, or board delegate or document risk acceptance","instructions":"**Objective** — For each monitor-path risk, prepare a decision memo that either escalates the above-appetite exposure to the authority that can accept it or documents a formal, time-bound risk acceptance with conditions and follow-up ownership, so carried risk is a governed choice and not a silent one.\n\n**Inputs**\n- The monitor-branch entries with residual ratings and appetite positions.\n- The appetite statement and the escalation authority matrix (who can accept risk at which level — risk owner, GRC lead, executive sponsor, board delegate).\n- The rationale for carrying rather than treating (no cost-justified mitigation this period) and any compensating controls.\n\n**Procedure**\n1. Quantify the exposure being carried: residual likelihood and impact, the amount over appetite, and the plausible loss and velocity — an acceptance without a quantified exposure is a blank cheque.\n2. Match the decision to authority: the higher the residual over appetite, the higher the acceptance authority. A risk materially above appetite is not accepted by its own first-line owner — it escalates to the executive sponsor or board delegate per the matrix.\n3. Draft the decision memo: the risk, why treatment is deferred, the compensating controls, the exposure quantification, and the recommendation (escalate for decision, or accept).\n4. For acceptances, capture conditions and an expiry: what must stay true, the KRIs that would void the acceptance, and a re-decision date. A perpetual acceptance is permanent unmanaged risk — every acceptance is time-bound.\n5. Define follow-up ownership: who monitors the accepted or escalated risk and who re-opens it at expiry or on a breach.\n\n**Record in AssureSwarm**\n- Item create — for each documented risk acceptance, create a **`policy_exception` Issue** (`Issue.issue_type: policy_exception`) that is the governed acceptance record: set `Issue.exception_approver` (the accepting authority per the matrix) and `Issue.exception_expiry_date` (the time-bound re-decision date — the filterable expiry index), with the quantified exposure, the conditions, and the compensating controls captured in `Issue.description`. Link the Issue ↔ its Risk.\n- Item field update — set `Risk.treatment: accept` on each accepted Risk.\n- Step document — attach the **decision memo** per monitor-path risk (DOCX/PDF, document upload); an escalation routed for decision but not yet accepted is the memo plus the notification, with no acceptance Issue until it is granted.\n- Notify the escalation authority and record the follow-up owner on the step.\n\n**Exit criteria** — Each monitor-path risk has a decision memo with quantified exposure; acceptances are approved at the authority matching the over-appetite level, time-bound, and conditioned; escalations are routed to the right authority; follow-up ownership and re-decision dates are set.","label":"Escalate or accept risk","performedBy":{"primitives":["coach-document-upload","coach-item-update","coach-notify","coach-item-create","coach-items-link"]}},"id":"escalate-or-accept-risk"},{"data":{"description":"Enterprise Risk Assessment and Risk Appetite Reporting receiving owners, with risk-function owner: Accept the maintained register and above-appetite packages with their distinct downstream scope, take ownership of carried constraints and obtain the risk-function owner’s formal handoff sign-off.","instructions":"**Objective** — Compile and hand off the owner-approved register and decided actions/acceptances, then retain the immutable cycle evidence and follow-up schedule.\n\n**Inputs**\n- The refreshed, owner-approved register with inherent and residual ratings and appetite positions.\n- The control-assurance mapping, the KRIs and their status, the action plans (gaps branch), and the risk-acceptance or escalation memos (monitor branch).\n- The linked outputs of any related workflow and the unresolved constraints logged along the way.\n- The final package: the maintained register, above-appetite entries, action plans, acceptances and escalations, KRIs, and open constraints, plus the governance decision it supports.\n- The named downstream workflows and their owners.\n- The assumptions and limitations logged during the cycle.\n- The records-retention schedule for risk and ERM governance records.\n- Open threads: action plans in flight, risk acceptances with expiry dates, KRIs to keep monitoring, and scope changes for the next cycle; the review cadence and the next scheduled cycle date.\n\n**Procedure**\n*Autonomous preparation incorporates Prepare final package; Enterprise Risk Assessment and Risk Appetite Reporting receiving owners, with risk-function owner reviews the combined evidence.*\n1. Compile the package in the order a reviewer reads it: portfolio summary (counts by category, above-appetite entries, movement since the last cycle), then entry-level detail with ratings and their evidence citations, then action plans and acceptances, then KRIs and open constraints.\n2. Test it against re-performance: could a reviewer holding only this package reconstruct each rating and its basis? Any \"see the register\" external reference fails — pull the artifact in.\n3. Spot-check every figure against source — the register, the trackers, the KRI dashboard — before publishing; a summary count that does not tie to the register undermines the whole package.\n4. State the proposed conclusion and the governance decision it supports (for example register accepted, escalations tabled for the risk committee), plus what remains open with named owners.\n5. Note explicitly what the downstream workflows should consume and not re-derive, so the handoff is clean.\n6. Create or link the downstream workflows and attach the final package to each: Enterprise Risk Assessment & Portfolio Oversight Cycle consumes the maintained register, the concentration and correlation flags, and the residual positions; Risk Appetite Definition & Board Reporting consumes the above-appetite entries, the escalations, and the acceptances for board-level reporting.\n7. State the handoff contract per downstream: what is authoritative here (ratings, ownership, control mapping) and therefore should not be re-derived, versus what the downstream workflow extends (portfolio aggregation, appetite calibration, board narrative).\n8. Pass assumptions and limitations forward explicitly — provisional categories, deferred units, acceptances nearing expiry — so downstream work inherits them rather than rediscovering them.\n9. Confirm the receiving owner acknowledges the handoff so the package does not land unowned. Before treating the cycle as closable, check it is: the register is refreshed and owner-approved, escalations and acceptances are decided, and action plans are owned and dated. An undecided escalation is not closable.\n10. Export the final workflow record and archive it with the package in the designated governance repository under retention and immutability controls; record the archive location and reference, and verify retrievability by opening the archived copy. Any post-archive correction is a new dated addendum, never an edit to the sealed record.\n11. Update the control execution log for UC-RISK-05, UC-RISK-09, UC-RISK-10, and UC-RISK-13 with the cycle period, completion date, and result — this is what demonstrates on-cadence register maintenance when the control is sampled.\n12. Create carry-forward items, each with an owner and due date: action plans continuing past close, risk acceptances due for re-decision at expiry, KRIs to monitor, and scope changes for the next cycle. An acceptance that renews silently is how temporary risk becomes permanent.\n13. Communicate the outcome to stakeholders and confirm the next cycle is scheduled at the policy cadence; the risk-function owner's handoff sign-off on this step is the formal closure declaration.\n\n**Record in AssureSwarm**\n- Assemble the package and link each evidence artifact to its producing step (document link).\n- Attach the compiled package and the portfolio summary to the step (document upload).\n- Record each receiving owner’s actual acceptance in native approvals, with scope and limitations in the native result. Retain the source owner’s closure sign-off where the procedure requires it.\n- Link the downstream workflows and attach or link the final package to each (workflow attach, document link).\n- Record the handoff contract, the assumptions passed forward, and the acknowledging owner on the step.\n- Workflow instance — export the run as the audit trail; attach the closure record with the archive location and reference (document upload).\n- Item create — carry-forward **Issue items** (`Issue.issue_owner` + `Issue.target_remediation_date`) for continuing action plans, acceptance re-decisions due at their `exception_expiry_date`, KRIs to keep monitoring, and next-cycle scope changes; a continuing action-plan Issue simply stays open rather than being recreated.\n- Record the control execution log update for UC-RISK-05, UC-RISK-09, UC-RISK-10, and UC-RISK-13 (cycle period, completion date, result) and the next cycle date on the step; where those UC controls are loaded as Control items, link them to the instance.\n\n**Exit criteria**\nAccept the maintained register and above-appetite packages with their distinct downstream scope, take ownership of carried constraints and obtain the risk-function owner’s formal handoff sign-off.\nPackage assembled in reviewer order and passes the re-performance test with no external references; every summary figure traces to source; the proposed conclusion and open items are stated with owners; ready for the governance decision and handoff.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the linked register entries, ratings, evidence, action plans, and KRIs into the ordered, self-contained package with source cross-references.\nBoth downstream workflows are linked and hold the final package; the handoff contract names what not to re-derive; assumptions and limitations are passed forward; the receiving owner has acknowledged. The final record is archived, verified retrievable and immutable, with its reference recorded; the control execution log is updated; every open thread exists as a carry-forward item with an owner and due date; the next cycle is scheduled; and the risk-function owner's sign-off on this step closes the cycle.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-render-package","coach-document-upload","coach-workflow-attach","coach-workflow-export","coach-item-create"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:grc-enterprise-risk-register-lifecycle"}