{"description":"Intake one newly identified risk into the enterprise register. The instance creates a new Risk item at the first step and attaches to that Risk item for the whole run — every rating, control link, and disposition enriches that single record. It consumes the initial risk identification (no upstream workflow) plus existing Control items, Policy items, and evidence carried on Issue, Audit, and Control-hosted SOX testing workflows, and produces the named deliverable: a review-ready risk intake package attached to the Risk item. On completion it hands that package to the Enterprise Risk Register Lifecycle workflow for ongoing monitoring. In scope: intake and initial assessment of one new risk. Out of scope: portfolio-level aggregation, periodic re-assessment, and risk-treatment project execution, which the Enterprise Risk Register Lifecycle workflow owns.","edges":[{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-close-and-archive","label":"Clear","source":"classify-disposition","target":"close-and-archive","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-close-and-archive","source":"create-action-plan","target":"close-and-archive"},{"id":"e-escalate-or-accept-risk-close-and-archive","source":"escalate-or-accept-risk","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-RISK-07","UC-RISK-08","UC-RISK-10"],"department":"risk-management","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-risk-register-intake","contentDigest":"sha256:75e01ddd883d1cf48630fce5879880b334cfdd9af7e2aec3111be8842be42114","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:75e01ddd883d1cf48630fce5879880b334cfdd9af7e2aec3111be8842be42114","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-risk-register-intake"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-risk-register-intake","source":"coworkcanvas-gallery","standards":["coso-erm","iso-31000"],"teams":["risk-management"]},"name":"Risk Register Intake","nodes":[{"data":{"decisionField":"disposition_path","description":"Named risk owner with GRC lead: Approve the cited inherent/residual proposals and real control credit, accept ongoing ownership/cadence and classify the complete one-risk package against appetite before register ratings take effect.","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** — Create one authoritative risk record, prepare source-backed inherent and residual assessments with real control mappings, and obtain the risk owner’s approval, ongoing ownership and appetite disposition.\n\n**Decision criteria**\nInputs for preparation: - The initial risk identification: proposed risk title, a plain-language description of the exposure, the accountable risk owner, and the related business process(es). These are the workflow's initiation inputs, recorded in the initiating request and native result; this node is the entry point, so it needs no prior in-workflow output.\n- The related business processes named in the identification are existing **Process items** to be linked to the new Risk.\n- The enterprise risk taxonomy: the `Risk.category` SELECT values (cyber_security, operational, financial_reporting, compliance_regulatory, third_party, privacy, ai_governance, strategic, reputational, esg, people_hr, business_continuity), with `Risk.taxonomies` / `Risk.domains` MULTISELECTs for secondary classification.\n- Where a regulatory-change feed exists, recent regulatory changes that may be candidate risk drivers, uploaded as evidence at this step (they have no native home in AssureSwarm).\n- The captured Risk item (description, category, owner) produced by the capture step.\n- Supporting evidence to justify the rating: **Issue items** (issue_type/source distinguish findings, exceptions, incidents), **Audit items**, plus any regulatory changes, loss events, or external news uploaded at this step.\n- The organization's likelihood and impact rating-scale definitions (what a 1 versus a 5 means on each axis) — no native type; referenced from the governing risk-rating policy document uploaded at this step.\n- The captured Risk item. Prepare control mapping independently of the inherent score once the risk has been captured.\n- The existing control library: **Control items**.\n- The policy set: **Policy items** (policies/standards that set the expectations controls enforce).\n- The approved inherent likelihood and impact scores (from inherent scoring).\n- The linked mitigating Controls (and Policies) and their per-link rationale (from control mapping). Residual derivation requires both the inherent score and the control mapping.\n- The control effectiveness evidence for the linked controls, where available: **Control-hosted SOX testing workflows** linked to each Control (the Test-step conclusion = operating_effectively | exceptions_noted | not_operating_effectively | not_tested) and **Issue items** recorded against those controls.\n- The risk appetite thresholds that define acceptable residual severity — no native type; referenced from the governing risk-appetite policy document.\n- The approved residual rating and tier (from residual scoring) — cadence is tiered by residual severity.\n- The named risk owner from the captured entry.\n- The organizational review-cadence policy (if any) and the current date to stamp as last-reviewed.\n- The approved residual rating and tier (`Risk.residual_rating`) from residual scoring, and the flagged control gaps from control mapping.\n- The risk appetite thresholds and escalation matrix — no native type; referenced from the governing risk-appetite policy document at this step. Appetite is the yardstick every branch below is measured against (\"within appetite\" vs \"above appetite\").\n\n*Autonomous preparation incorporates Capture the risk; Score inherent risk; Map mitigating controls; Compute residual risk; Assign owner and review cadence; Named risk owner with GRC lead reviews the combined evidence.*\n1. Create the Risk item in the register and record each supplied attribute against it.\n2. Classify the risk into exactly one value of `Risk.category`. Map a plain-language category to its schema value (e.g. financial → financial_reporting, compliance → compliance_regulatory, technology → cyber_security). If the exposure spans two categories, pick the dominant driver, capture the secondary in `Risk.taxonomies`, and note it in the description — never leave the category blank or invent a value outside the SELECT list.\n3. Write the description so a reviewer can understand the exposure without outside context: name the threat, the asset or objective at risk, and the plausible loss event. Worked example: \"Vendor concentration — 70% of settlement volume routes through a single unrated payment processor; an outage would halt customer payouts\" is specific; \"operational risk in payments\" is not.\n4. Confirm the accountable owner is a named individual — a role title alone is insufficient, a person must be answerable. If only a role is known, flag the owner as open rather than guessing.\n5. Do not invent attributes the requester did not supply. Leave unknowns explicitly open (flagged) rather than filling a plausible-looking value.\n6. Where a regulatory-change feed is available, review recent changes and, if one is the driver of this risk, cite it as the source of the entry.\n7. Assign an inherent likelihood score from 1 to 5 using the scale anchors (e.g. 1 = rare, occurs less than once in five years; 5 = near-certain, expected within the year). State which anchor you matched and why.\n8. Assign an inherent impact score from 1 to 5 against the impact scale, using the highest applicable dimension among financial, operational, reputational, and regulatory magnitude.\n9. For every proposed score, cite at least one concrete piece of evidence (an issue, audit finding, regulatory change, incident, or news event) recorded as a source reference beside the score. Never propose or change a rating without at least one such citation — an uncited score is not admissible.\n10. Do not write the rating straight into the register. Record it as a proposed change with its evidence, present it as a clear before-and-after difference, and route it to the risk owner to review and approve before it takes effect.\n11. If the owner revises a score, the revised score must itself carry a fresh evidence citation — capture the owner's rationale for the change.\n12. Search the existing control library for controls that plausibly reduce this risk's likelihood or impact. Read the risk description against each candidate control's objective — do not match on keyword alone.\n13. For each candidate, write a short rationale explaining the mechanism: does the control reduce the probability of the event, or limit the loss if it occurs? A control with no articulable mechanism is not a mitigant — drop it.\n14. Where a Policy item sets the expectation the control enforces, link the Policy too and note the policy-to-control relationship.\n15. Only link Control and Policy items that genuinely exist and genuinely relate. Never fabricate a control to make a risk look covered — an unmitigated risk must show as unmitigated so residual scoring stays honest.\n16. Flag any obvious control gap (a risk driver with no linked mitigating control) so the disposition step can treat it as a candidate action.\n17. Start from the approved inherent likelihood and impact. For each mapped control, judge whether it primarily reduces likelihood, impact, or both, and by how much — grounded in the control's effectiveness evidence, not optimism.\n18. Derive residual likelihood (1-5) and residual impact (1-5). Residual must never exceed inherent on either axis; a control cannot make a risk worse. Where a control is designed but not operating effectively, give it little or no residual credit and say so.\n19. If no effective control mitigates a driver, residual equals inherent on that axis — do not discount for controls that are absent or ineffective.\n20. Compute the residual severity (e.g. likelihood times impact, or the org's mapping to low, medium, high, or critical) and state the resulting tier.\n21. Record the residual rating as a proposed change with reasoning that ties each reduction to a specific control, and route it to the risk owner for approval before it is written.\n22. Confirm the accountable owner is a named person who accepts ongoing responsibility for monitoring the risk. If ownership is contested or vacant, flag it — an unowned risk cannot be closed.\n23. Set the review cadence in days. Tier it to the residual severity where the policy allows: higher residual tiers get a shorter cadence (e.g. critical goes to 30-90 days, high to 90 days, medium to 180 days, low to 365 days). Default to 180 days when no policy or tier rule specifies otherwise.\n24. Stamp the last-reviewed date (today) so staleness can later be computed as a last-reviewed date older than the cadence window.\n25. Record who will receive the review reminder when the entry ages past its cadence.\n\n- Choose **complete** (\"Complete\") when residual risk sits within appetite, mitigating controls are linked and effective, and no open gap or action is required — the entry is ready to package as-is.\n- Choose **gaps** (\"Gaps require action\") when a control gap, an ineffective control, or a residual above appetite requires a remediation action plan with an owner and due date before the risk can be considered managed.\n- Choose **monitor** (\"Monitor without immediate action\") when residual exceeds appetite but no immediate remediation is warranted or feasible — the risk must be escalated to the risk owner, GRC lead, executive sponsor, or board delegate for a formal acceptance or watch decision.\n\n**Record in AssureSwarm**\n- Create the Risk item (`coach-item-create`) and populate `Risk.description`, `Risk.category`, `Risk.taxonomies`, `Risk.domains`, and `Risk.risk_owner` from the supplied initiation evidence and native result.\n- Link the Risk to each in-scope Process item (Risk ↔ Process, `coach-items-link`).\n- Flag any unknown attribute as an open field rather than leaving a fabricated value.\n- Query supporting evidence from Issue and Audit items (`coach-query-data`).\n- Update the tier selects on the Risk item — `Risk.likelihood` (low | medium | high | very_high) and `Risk.impact` (low | medium | high | critical) — and set `Risk.inherent_rating` (low | medium | high | critical) as the combined inherent tier; map the 1-5 scores onto these tiers.\n- Keep the numeric 1-5 scores, the evidence citation behind each, and the owner-approval trail in the native result as a proposed change, with source documents and the owner’s native approval record (Risk has no 1-5 field; retain numeric detail in the result).\n- Query the Control and Policy items (`coach-query-data`) and create the relationships on the Risk item — Risk ↔ Control item(s) and Risk ↔ Policy item(s) (`coach-items-link`).\n- Record each per-link mitigation rationale and every control-gap flag in the native result with linked source evidence.\n- Pull control-effectiveness evidence from Control-hosted SOX testing workflow results and linked Issue items (`coach-query-data`).\n- Set `Risk.residual_rating` (low | medium | high | critical) to the residual tier — it must never exceed `Risk.inherent_rating`.\n- Keep the residual likelihood/impact 1-5 scores and the per-axis control-credit reasoning in the native result as a proposed change with the owner’s native approval record (Risk has no 1-5 field; retain numeric detail in the result).\n- Confirm and, if changed, update `Risk.risk_owner` (`coach-item-update`).\n- Record the review cadence in days and the last-reviewed date in the native result and final intake package — Risk has no review_cadence_days or last_reviewed_date field, so this governance data lives in the result and handoff package (the honest fallback the downstream Lifecycle workflow reads for its staleness check).\n- Submit the `disposition_path` SELECT field with the chosen branch value (complete, gaps, or monitor).\n- Record the decision rationale and evidence references in the step result, and the decision owner or approver in the step's approver record. The rationale must cite the residual tier and the appetite comparison that drove the choice.\n\n**Exit criteria**\nApprove the cited inherent/residual proposals and real control credit, accept ongoing ownership/cadence and classify the complete one-risk package against appetite before register ratings take effect.\nThe Risk item exists with a title, a single valid `Risk.category`, a specific description, a named `Risk.risk_owner`, and its related Process items linked; every unknown is explicitly flagged open rather than guessed.\n`Risk.likelihood`, `Risk.impact`, and `Risk.inherent_rating` are set to their tier values with the underlying 1-5 scores in the native result, each carries at least one evidence citation, and the risk owner has approved the rating rather than it being written unilaterally.\nEvery proposed link names a real Control or Policy item and carries a stated mitigation rationale in the native result; identified control gaps are flagged; the mitigating set is ready for residual scoring.\n`Risk.residual_rating` is set to a tier that does not exceed `Risk.inherent_rating`, the underlying 1-5 residual scores are in the native result, each reduction is tied to a specific effective control, and the owner has approved.\n`Risk.risk_owner` is a confirmed named person, a numeric review cadence (tiered to residual or defaulted to 180 days) is set in the native result, and the last-reviewed date is stamped so the entry can be surfaced for review once it ages past the cadence.\nThe `disposition_path` form is submitted with a rationale tied to residual-versus-appetite evidence and a named decision owner; the two unselected branches are prunable because each branch edge value matches the selected form value.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"grc-artist","note":"Create risk entry and capture attributes Score inherent risk with cited evidence Link mitigating controls with rationale Compute residual risk from mapped controls Assign owner and review cadence","primitives":["coach-item-create","coach-form-fill","coach-items-link","coach-query-data","coach-item-update"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Produce an owned, dated remediation action plan that closes the control gap or brings residual risk back within appetite.\n\n**Inputs**\n- The classify-disposition outcome (gaps) and its rationale identifying the specific gap or above-appetite driver.\n- The flagged control gaps from the control-mapping step and the residual rating.\n- The remediation owner and any interim mitigation options.\n\n**Procedure**\n1. State the root cause of the gap: is the control missing, poorly designed, or not operating? Name the specific driver, not a symptom.\n2. Define the remediation action(s), each with a single accountable owner and a due date. A vague \"improve monitoring\" is not an action — \"implement daily reconciliation of the settlement file to the bank statement, owner J. Doe, due 2026-08-15\" is.\n3. Specify interim mitigation to hold the risk while remediation is in flight (e.g. a manual compensating check), and the validation evidence that will prove the action worked.\n4. Set the reporting cadence for tracking the action to closure and the escalation path if it slips.\n\n**Record in AssureSwarm**\n- Create one **Issue item** per remediation action (`coach-item-create`) — the Issue type is built for remediation tracking — setting `Issue.issue_type` (deficiency, or finding/observation as appropriate), `Issue.source: management_identified`, `Issue.root_cause`, `Issue.remediation_plan` (with the interim mitigation and validation evidence captured in this RICHTEXT), `Issue.issue_owner`, and `Issue.target_remediation_date`.\n- Link each Issue to the Risk (Issue ↔ Risk, `coach-items-link`) and set `Risk.treatment: mitigate` (`coach-item-update`).\n- Capture the reporting cadence in the native result and action-plan evidence — it has no native Issue field.\n\n**Exit criteria** — Each remediation Issue has a root cause, a single named `Issue.issue_owner`, a `Issue.target_remediation_date`, interim mitigation and validation evidence in `Issue.remediation_plan`, and a reporting cadence; each Issue is linked to the Risk and `Risk.treatment` is set to mitigate.","label":"Create action plan","performedBy":{"agent":"grc-artist","note":"Create owned action plan for gaps","primitives":["coach-item-create","coach-form-fill","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** — Prepare the escalation and acceptance memo that puts an above-appetite risk in front of the accountable authority (risk owner, GRC lead, executive sponsor, or board delegate) and captures their formal acceptance or watch decision.\n\n**Inputs**\n- The classify-disposition outcome (monitor) and its rationale.\n- The residual rating and tier and the appetite threshold it exceeds.\n- The escalation authority appropriate to the residual tier per the escalation matrix.\n\n**Procedure**\n1. Identify the correct escalation authority for the residual tier: the higher the tier above appetite, the higher the authority (owner, then GRC lead, then executive sponsor, then board delegate).\n2. Draft the decision memo: quantify the exposure (potential impact and likelihood), state why immediate remediation is not being pursued, and present the options — accept, monitor, or defer remediation.\n3. Capture the conditions of any acceptance: the acceptance duration, the trigger events or KRI thresholds that would reopen the decision, and who must re-approve at expiry.\n4. Define the follow-up ownership and the monitoring cadence for the accepted or watched risk.\n\n**Record in AssureSwarm**\n- When acceptance is granted, record it as a risk acceptance: create a **policy_exception Issue** (`coach-item-create`) with `Issue.issue_type: policy_exception`, `Issue.exception_approver` (the accepting authority), and `Issue.exception_expiry_date` (the acceptance expiry / re-approval date — the filterable expiry index), linked to the Risk (Issue ↔ Risk, `coach-items-link`), and set `Risk.treatment: accept` on the accepted Risk (`coach-item-update`).\n- Capture the decision memo, quantified impact, acceptance conditions, and follow-up owner in the native result and attached decision memo, with granted sign-off in native approvals, and notify the escalation authority (`coach-notify`).\n\n**Exit criteria** — The memo names the correct authority, quantifies the exposure, records the acceptance conditions and expiry trigger, and assigns follow-up ownership; a granted acceptance exists as a policy_exception Issue linked to the Risk with `Risk.treatment: accept`.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` — routes the escalation memo to the named risk owner, GRC lead, executive sponsor, or board delegate and logs the notification.","label":"Escalate or accept risk","performedBy":{"agent":"grc-artist","note":"Escalate or document risk acceptance","primitives":["coach-notify","coach-form-fill","coach-item-create","coach-items-link","coach-item-update"]}},"id":"escalate-or-accept-risk"},{"data":{"description":"Automatically compile the authorized intake evidence, deliver its cadence and open obligations to the lifecycle instance, verify receipt and archive the active register entry with monitoring scheduled.","instructions":"**Objective** — Compile and transmit the authorized risk-intake package to the lifecycle workflow, verify the handoff and retain the immutable rating/approval record and monitoring cadence.\n\n**Inputs**\n- The disposition outcome and whichever branch output fired: the action plan (gaps), the escalation and acceptance memo (monitor), or a clean \"complete\" classification.\n- The confirmed owner and review cadence (from the owner and cadence stage) — the package includes both the selected disposition and the owner/cadence record.\n- The full risk record: attributes, inherent and residual ratings with citations, and control and policy linkages.\n- The final intake package (from package assembly).\n- The Enterprise Risk Register Lifecycle workflow, the downstream consumer — this intake produces the handoff package that workflow consumes.\n- The handoff confirmation that the lifecycle workflow has received the package.\n- The final package and all linked records: risk item, ratings, controls, and the action plan or acceptance memo.\n\n**Procedure**\n*The agent incorporates Prepare final package; Handoff to related workflow after the preceding authorized decisions, without an additional approval.*\n1. Compile the risk entry with its inherent and residual ratings, each with the evidence citations behind them.\n2. Attach the mitigating control and policy linkages and their rationales, plus any flagged gaps.\n3. Include the disposition outcome and its rationale, and the branch artifact — the action plan, the escalation and acceptance memo, or the clean-close note.\n4. Include the confirmed owner, review cadence, and last-reviewed date.\n5. List unresolved constraints and open items, and state the proposed conclusion so the reviewer can approve the package in one pass.\n6. Create or locate the downstream Enterprise Risk Register Lifecycle workflow instance for this risk and attach the final package to it.\n7. Pass the handoff explicitly: the approved residual rating, the review cadence and last-reviewed date, the owner, and any open action plan or acceptance conditions the lifecycle must track.\n8. Note the assumptions baked into the intake (evidence as-of dates, control effectiveness conclusions relied upon) so the lifecycle knows what to revalidate over time.\n9. State clearly what the downstream workflow should not repeat (the initial intake scoring) versus what it must carry forward (monitoring against the cadence, tracking the action plan to closure).\n10. Archive the final package as the immutable record of the intake decision, preserving the evidence citations and approvals so the rating history is reconstructable.\n11. Update the linked records: mark the risk entry active in the register, confirm the owner and review cadence are set, and ensure any action plan is open and tracked.\n12. Confirm monitoring and follow-up are scheduled — the entry will surface for review when it ages past its cadence, and any action plan has its reporting cadence running.\n13. Communicate the final disposition to the risk owner and stakeholders, closing the intake.\n\n**Record in AssureSwarm**\n- Render the review-ready risk intake package as a PDF/DOCX step document (`coach-render-package`) linked to the Risk item, capturing the risk ID, owner, inherent and residual assessment, control coverage, appetite position, action plan or acceptance memo, and disposition rationale.\n- Attach the package to the downstream workflow (`coach-workflow-attach`) and link the handoff document to the risk item (`coach-document-link`), noting assumptions and the do-not-repeat scope.\n- Set the Risk item status to active/OPEN in the register (`coach-item-update`) and link the archived intake package to the Risk record (`coach-document-link`).\n- The completed workflow instance — attached to this Risk item — is the durable, immutable audit trail of the intake decision, preserving the ratings, evidence citations, and approvals.\n\n**Exit criteria**\nAutomatically compile the authorized intake evidence, deliver its cadence and open obligations to the lifecycle instance, verify receipt and archive the active register entry with monitoring scheduled.\nA single risk intake package document exists containing the risk record, both ratings with citations, control mappings, owner and cadence, the disposition outcome with its branch artifact, and the proposed conclusion — traceable and ready for handoff.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — assembles the risk record, ratings, control mappings, and disposition into one review-ready package document.\nThe final package is attached to the Enterprise Risk Register Lifecycle workflow, the carry-forward items (residual, cadence, owner, open actions) are passed, and the intake-versus-lifecycle scope boundary is documented.\nThe workflow instance is archived as the intake audit trail with its citations intact, the Risk entry is active in the register with owner and cadence set, monitoring and follow-up are scheduled, and the final disposition is communicated.","label":"Close and archive","performedBy":{"agent":"grc-artist","note":"Assemble final evidence and decision package Hand package to Enterprise Risk Register Lifecycle Close intake and preserve audit trail","primitives":["coach-render-package","coach-workflow-attach","coach-document-upload","coach-item-update"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:grc-risk-register-intake"}