{"description":"Policy Exception & Risk Acceptance as a decision-aware workflow. It carries a waiver from request and justification through risk assessment, compensating controls, time-bound approval, registration with expiry, and re-review so no exception outlives its rationale. The exception IS an Issue item (issue_type: policy_exception) — the workflow runs on it, and the exception register is simply the set of those Issues, queryable by their filterable exception_expiry_date. The affected policy is a Policy item the Issue links to; a granted acceptance also sets treatment: accept on the linked Risk item. In scope: time-bound exceptions/waivers to an existing policy that are risk-accepted for a bounded window. Out of scope: permanent policy-change proposals, which route to the Policy Lifecycle Management workflow (the Policy item's revision process) rather than this waiver workflow. No upstream or downstream workflow feeds or consumes this one; the exception request is the initial input, and recurring-exception patterns are compiled as feedback onto the affected Policy items at close.","edges":[{"id":"e-assess-and-package-route-for-approval","source":"assess-and-package","target":"route-for-approval"},{"id":"e-route-for-approval-register-and-implement","label":"Approved","source":"route-for-approval","target":"register-and-implement","whenValue":"approved_time_bound"},{"id":"e-route-for-approval-close-and-archive","label":"Rejected","source":"route-for-approval","target":"close-and-archive","whenValue":"rejected"},{"id":"e-route-for-approval-committee-review","label":"Escalated","source":"route-for-approval","target":"committee-review","whenValue":"escalated"},{"id":"e-committee-review-register-and-implement","source":"committee-review","target":"register-and-implement"},{"id":"e-register-and-implement-monitor-to-expiry","source":"register-and-implement","target":"monitor-to-expiry"},{"id":"e-monitor-to-expiry-close-and-archive","source":"monitor-to-expiry","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ASSET-10","UC-RISK-09","UC-RISK-08","UC-AUDIT-17"],"department":"risk-management","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-policy-exception-risk-acceptance","contentDigest":"sha256:4cf2f22767e9a99b893684ffb6e0d1fa7238fa4bcafda89190b6a2052a31b0ef","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:4cf2f22767e9a99b893684ffb6e0d1fa7238fa4bcafda89190b6a2052a31b0ef","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-policy-exception-risk-acceptance"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-policy-exception-risk-acceptance","source":"coworkcanvas-gallery","standards":["coso-erm","iso-27001"],"teams":["risk-management","compliance-legal"]},"name":"Policy Exception & Risk Acceptance","nodes":[{"data":{"description":"The requestor and sponsor submit the exception on this step's form; the agent de-duplicates it, drafts the rated risk assessment against appetite and the compensating-control plan, and the risk owner endorses the packet and the approval authority it requires","formData":{"fields":[{"key":"policy_clause","label":"Policy and specific clause you cannot meet","required":true,"type":"text"},{"key":"why_not_met","label":"Why the requirement cannot be met as written","required":true,"type":"textarea"},{"key":"alternative_considered","label":"Compliant alternative you considered, and why it was rejected","required":true,"type":"textarea"},{"key":"cost_and_timeline_of_compliance","label":"Cost and timeline of achieving full compliance","required":true,"type":"textarea"},{"key":"scope_in_and_out","label":"Assets, systems, or processes the exception covers - and what it explicitly does not cover","required":true,"type":"textarea"},{"key":"requested_end_date","label":"Date the exception should end","required":true,"type":"date"},{"key":"remediation_milestone","label":"Remediation milestone that end date is tied to","required":true,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Produce a risk-owner-endorsed approval packet for a single policy exception: business justification, a rated risk assessment positioned against appetite, a compensating-control plan, and the residual rating that determines which approval authority the request needs.\n\n**Inputs**\n- The exception request, submitted by the requestor on this step's form (the workflow's initial input): the affected Policy item and the specific clause that cannot be met, named requestor and business unit, accountable sponsor, in-scope assets/processes with explicit out-of-scope items, and the requested duration. A request that is really a permanent policy-change proposal is out of scope — return it to the policy owner (the Policy item's policy_owner) rather than assessing it here.\n- The risk register — Risk items touching the same assets/requirement — the org's standard likelihood/impact scale, and documented appetite/tolerance thresholds.\n- The control inventory — Control items as candidate compensating controls — and the governance approval/authority matrix.\n- Prior exception history for the same clause: query Issue items with issue_type policy_exception linked to the same Policy (active duplicates, prior rejections).\n\n**Procedure**\n1. Validate intake completeness and de-duplicate: confirm the requestor has supplied each missing business fact and resolve the sponsor from the exception ownership record, then query the exception register and prior history for the same policy clause. Flag duplicates of an active exception or a re-submission of a previously rejected request. Confirm exactly one accountable requestor and one sponsor, and that the requested duration is a genuine time bound, not an open-ended waiver.\n2. Test the submitted business justification rather than restating it: why the requirement cannot be met as written, the cost and timeline of full compliance, the compliant alternative that was considered and why it was rejected, and the remediation milestone the requested duration is tied to. Send the form back where any of these is assertion rather than argument.\n3. Draft the risk assessment consistent with COSO ERM risk-response practice and ISO 27001 risk-acceptance expectations: identify what the waived requirement protects against, rate likelihood and impact over the requested window on the standard scale, and state the inherent position before mitigation.\n4. Position against appetite: link the affected risk-register entries, compare the exposure to documented appetite/tolerance, and flag any breach explicitly (a breach forces escalation at the approval decision).\n5. Build the compensating-control plan: enumerate candidate controls (heightened monitoring, restricted access, segmentation, added review gates, reduced data scope), each with a proposed owner, operating frequency, the evidence it produces, and a required-by date; then re-estimate residual risk with those controls in place.\n6. Assemble the packet and identify the approver the authority matrix requires for that residual level: request, justification, risk assessment with appetite position, compensating-control plan, residual rating, and required approver.\n7. Route the assembled packet to the risk owner for endorsement.\n\n**Record in AssureSwarm**\n- Create/update the exception's Issue item — issue_type: policy_exception, identified_date (request date), issue_owner (the accountable sponsor), severity (from the residual rating) — with the policy clause, bounded scope, duration, duplicate-check result, ratings, and required approver in its description (item create/update).\n- The form on this step, answered by the business exception requestor outside the workflow’s executing and approving roles, captures the request itself: the policy clause at issue, why it cannot be met, the compliant alternative rejected and why, the cost and timeline of full compliance, the in-scope and out-of-scope boundary, the requested end date, the remediation milestone it is tied to, with the accountable sponsor resolved from the exception ownership record.\n- Link the Issue to the affected Risk items and the Policy item (items link).\n- Attach the assembled approval packet document (document upload).\n\n**Exit criteria** — Risk owner has endorsed the packet; ratings follow the standard methodology and cover the full duration and scope; the appetite position is stated honestly; every compensating control is operable by a named owner rather than aspirational; the required approver is identified.\n\n**Form recipient** — this step's form is answered by the business exception requestor outside the workflow’s executing and approving roles, not by any executing risk owner, sponsor, control owner, approver or monitor; those roles record their work in native results. Send it with a form assignment; the owner's own work goes in the step result.","label":"Assess and package","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"assess-and-package"},{"data":{"decisionField":"approval_decision","description":"Agent stages the endorsed packet with the approver the authority matrix requires; the approver decides: approve time-bound, reject, or escalate","formData":{"fields":[{"key":"approval_decision","label":"Route for approval","options":[{"label":"Approved time-bound","value":"approved_time_bound"},{"label":"Rejected","value":"rejected"},{"label":"Escalated to risk committee","value":"escalated"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve who bears the exposure and whether the exception proceeds. The approver the authority matrix names for the packet's residual level decides to approve the exception time-bound, reject it, or escalate it to the risk committee.\n\n**Decision criteria**\n- `approved_time_bound` — Residual risk sits within the approver's delegated authority and within documented appetite; the compensating-control plan is operable by its named owners; and the requested window ties to a real remediation milestone. Approve with an explicit expiry date — an approval is never open-ended.\n- `rejected` — The exposure is not acceptable at any compensating-control level the organization will fund, the justification does not hold, or a compliant alternative exists. The policy requirement stands and a dated compliance deadline applies.\n- `escalated` — The residual exposure exceeds the approver's delegated authority or breaches appetite/tolerance, so the decision belongs to the risk committee rather than this approver.\n\n**Record in AssureSwarm** — Submit `approval_decision` (SELECT). Enter the step result citing the specific evidence references (risk rating, appetite position, compensating-control plan) and, for an approval, the approved expiry date; record the step's approver record (approver name and role).\n\n**Exit criteria** — `approval_decision` is submitted with a rationale that cites evidence; for an approval, an explicit expiry date is recorded; the branches not selected are prunable.","kind":"decision","label":"Route for approval","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"route-for-approval"},{"data":{"description":"Agent schedules the committee slot, distributes the packet, and drafts minutes and the recorded decision; the committee decides","instructions":"**Objective** — Obtain and record the risk committee's decision on an escalated exception whose exposure exceeds delegated authority: accept time-bound, accept with conditions, or reject.\n\n**Inputs**\n- The endorsed approval packet and the escalation grounds (appetite breach or authority overflow) from the `escalated` branch of the approval decision.\n- The committee's schedule, quorum rules, and submission template.\n\n**Procedure**\n1. Schedule the item on the next committee session — or an interim delegated review if waiting would leave the requestor operating in an ungoverned gap — respecting quorum rules and the submission template.\n2. Distribute the decision memo and full packet to members ahead of the session: quantified exposure, the appetite-breach analysis, compensating controls and remaining gaps, and explicit options with a recommendation.\n3. Draft the minutes during the session, capturing attendees, quorum confirmation, questions raised, and the decision as stated.\n4. Draft the recorded decision — accepted time-bound, accepted with conditions, or rejected — translating every imposed condition into a named owner and due date and capturing the committee-approved scope, compensating-control requirements, and expiry date.\n5. Update the exception record with the decision verbatim from the minutes; if the committee rejected the request, mark it closed-rejected so the register preserves the history.\n\n**Record in AssureSwarm**\n- Attach the minutes and the recorded decision documents (document upload).\n- Link the packet and the related risk-register entries (document link).\n- Update the exception item with the verbatim decision, conditions, approved scope, and expiry.\n\n**Exit criteria** — The chair has verified that the drafted minutes and recorded decision match what was decided verbatim; every condition has an owner and a due date; the expiry is explicit rather than implied; the signed decision is attached and the record updated.","label":"Committee review","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"committee-review"},{"data":{"description":"Agent registers the exception with expiry, wires monitoring for compensating controls, schedules the re-review, and notifies stakeholders; human validates the register entry","instructions":"**Objective** — Bring an approved (or committee-accepted) exception live: create the register entry with a hard expiry and an accountable owner, stand up monitoring for every compensating control, schedule the pre-expiry re-review, and notify stakeholders. This node also records a committee rejection as closed-rejected with no active waiver.\n\n**Inputs**\n- The approval decision and expiry date from the `approved_time_bound` branch, OR the committee's recorded decision, conditions, and expiry from committee review. This is a join: it starts once whichever approving path applies has delivered its reviewed decision (only one path fires per request).\n- The compensating-control plan (owners, frequencies, evidence) from the endorsed packet.\n- The related risk-register items, the affected policy record, and the approval evidence.\n\n**Procedure**\n1. Complete the exception's Issue item as the register entry: set exception_approver (the approval authority), exception_expiry_date (the hard expiry — this filterable field IS the register's expiry index), and issue_owner (the accountable owner); record the approved conditions, compensating controls, and the remediation milestone the expiry is tied to in remediation_plan. For a committee rejection, record it as closed-rejected with no active waiver so the history is preserved.\n2. Link the entry to the related Risk items — setting treatment: accept on the Risk whose exposure this waiver accepts — the affected Policy item, and the approval evidence.\n3. Implement the monitoring hooks for each compensating control: where its operating evidence lands, the check frequency, and the breach condition that raises a flag. Capture first-run evidence that every control the approval requires to be live is actually operating before the waiver is relied upon.\n4. Schedule the pre-expiry re-review and reminder triggers well ahead of the expiry date.\n5. Draft and send the decision notice to the requestor, sponsor, policy owner, control owners, and assurance functions — stating the exact scope, the expiry, and each owner's compensating-control obligations — and collect acknowledgements from owners carrying ongoing obligations.\n\n**Record in AssureSwarm**\n- Field updates on the exception's Issue item: exception_approver, exception_expiry_date, issue_owner, with conditions and compensating-control obligations in remediation_plan (item update).\n- Link the Risk items (treatment set to accept where the waiver accepts that exposure), the Policy item, and the approval evidence (items link).\n- Attach first-run control evidence and the decision notice (document upload).\n\n**Exit criteria** — No exception is registered without exception_expiry_date and an accountable issue_owner; every approval condition is present with its owner and date; first-run control evidence is real rather than documented intent; obligation owners have acknowledged; the exception window is confirmed live (or the record is closed-rejected).\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-scan` wires the compensating-control checks and the pre-expiry reminders; `/coach-notify` sends the decision notice and collects owner acknowledgements.","label":"Register and implement","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload","coach-workflow-scan","coach-notify"]}},"id":"register-and-implement"},{"data":{"description":"Agent monitors compensating controls, flags breaches, and triggers the pre-expiry re-review; human re-decides the exception's end state at expiry","instructions":"**Objective** — Keep the compensating controls honest across the exception window and drive the pre-expiry re-review that sets the exception's end state before it lapses silently.\n\n**Inputs**\n- The live exception Issue with its exception_expiry_date, compensating-control obligations, and remediation milestone (from register and implement). The expiring-exceptions watchlist is a query on issue_type: policy_exception ordered by exception_expiry_date.\n- Operating evidence for each compensating control as it accrues.\n\n**Procedure**\n1. On the agreed cadence, pull operating evidence for each compensating control and verify it ran as designed — sample the actual evidence rather than accepting attestations alone.\n2. Chase gaps with the control owner within the period; log each monitoring cycle's date, evidence checked, control status, and gap resolution.\n3. Watch for scope creep beyond the approved boundary and for material shifts in the risk profile; raise a finding to the exception owner and approver when a control fails or exposure deteriorates, since that can force an early re-review.\n4. Ahead of expiry, trigger the scheduled re-review and prepare the brief: remediation-milestone status, the full monitoring trail, and whether the policy requirement can now be met.\n5. If renewal is sought, stage it as a fresh request with updated justification and risk assessment through this same workflow — never a silent auto-renewal.\n\n**Record in AssureSwarm**\n- Update the exception Issue with each monitoring cycle's status (item update); a retirement on evidence the requirement is met sets actual_remediation_date, and the re-review confirmation sets verified_date.\n- Attach the monitoring trail and the pre-expiry re-review brief (document upload).\n\n**Exit criteria** — At the re-review, the exception's end state is decided before exception_expiry_date passes — retired on evidence the requirement is now met, renewed via a properly grounded fresh request, or compliance enforced with a dated plan — and any early-termination call on a failed control or material risk shift is ruled on.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-scan` pulls each control's operating evidence on cadence and fires the pre-expiry re-review reminder.","label":"Monitor to expiry","performedBy":{"primitives":["coach-query-data","coach-item-update","coach-workflow-scan","coach-document-upload"]}},"id":"monitor-to-expiry"},{"data":{"description":"Automatically deliver any direct rejection, retain its compliance-gap tracking or the authorized expiry outcome, reconcile the register and archive the policy feedback.","instructions":"**Objective** — Retain the prior authorized exception outcome, process a direct rejection only on that route, and archive the full record with recurring-policy feedback.\n\n**Inputs**\n- The rejected exception record plus the approver's rationale and compliance guidance (from the `rejected` branch of the approval decision).\n- The in-scope systems/processes and their owners.\n- The final-state record from whichever terminal path reached here: a monitored exception's re-review outcome (retired / expired / renewed) from monitor to expiry, or a rejected exception's compliance-tracking outcome from communicate rejection.\n- The full trail: request, justification, risk assessment, compensating-control plan and evidence, approval or committee records, register entry, monitoring trail, re-review outcome, and stakeholder communications.\n\n**Procedure**\n*The agent incorporates Communicate rejection after the preceding authorized decisions, without an additional approval.*\n1. Only for the direct rejected route, draft the rejection notice to the requestor and sponsor, explaining the rationale in terms of risk appetite and policy intent and restating that the policy requirement stands as written.\n2. Only for the direct rejected route, derive the compliance deadline from the approver's guidance and state the date by which the in-scope systems/processes must be brought into compliance.\n3. Only for the direct rejected route, open a tracked issue for the outstanding compliance gap with a named owner and the communicated due date, so the gap lives in the system of record and not only in the notice.\n4. Only for the direct rejected route, send the notice; log the notification date and recipients; attach the issue reference and any requestor response to the exception record.\n5. Verify the register entry status matches the final outcome — retired, expired, renewed under a new request, or rejected — and that no compensating-control obligation remains active on a closing record.\n6. Archive the complete package where audit and certification reviews can retrieve it (every artifact listed under Inputs).\n7. Update the linked Risk items (re-confirm treatment and residual_rating now the waiver has ended) and the Policy item to reflect the closure.\n8. Compile policy feedback for the Policy item's policy_owner — surfacing recurring-exception patterns such as repeated waivers against the same clause (query the closed policy_exception Issues linked to that Policy) as input for its next review cycle (next_review_date) — and record the closure date, closer, final status, and archive location.\n\n**Record in AssureSwarm**\n- Create the compliance-gap Issue item — issue_type: deficiency, source: compliance_review, issue_owner, target_remediation_date (the compliance deadline), identified_date — linked to the affected Policy item (item create).\n- Mark the exception's policy_exception Issue rejected (no active waiver) so the register preserves the history.\n- Attach the rejection notice document and log recipients (document upload).\n- Export the closed workflow package to the archive location (workflow export).\n- Attach the policy-feedback summary to the affected Policy item (document upload).\n- Close the exception Issue; its history stays queryable in the register.\n\n**Exit criteria**\nAutomatically deliver any direct rejection, retain its compliance-gap tracking or the authorized expiry outcome, reconcile the register and archive the policy feedback.\nFor a direct rejection, the delivery record names both requestor and sponsor as recipients; the compliance deadline is dated and realistic; the gap is tracked as its own Issue in the system of record; the exception record is released for closure.\n\n\nThe archive is complete and retrievable; no obligation is still live; the register status matches reality; the recurring-pattern feedback is routed to policy governance; the exception record is closed under its prior authorized outcome.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the audit-ready archive from the workflow's linked artifacts.","label":"Close and archive","performedBy":{"primitives":["coach-item-create","coach-document-upload","coach-notify","coach-workflow-export","coach-render-package"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:grc-policy-exception-risk-acceptance"}