{"description":"Implement a new or changed regulatory obligation end to end on the Audit item created for this implementation (audit_type = compliance or readiness): its scope names the obligation and authority, its period_end holds the effective (compliance-by) date, and the workflow instance attaches to it. There is no native Regulation type, so the regulator, region, and obligation summary live in the anchor Audit.description with the operative source text uploaded to the gap-analysis step. The work — gap analysis, policy updates (Policy items), control design (Control items), process operationalization (a Process item), and coverage validation — enriches that Audit rather than creating a parallel record. In scope are the legal entities, products, systems, and vendor relationships (Vendor items) the obligation touches; entities and processing below the regulation's applicability thresholds are out of scope. This workflow consumes the obligation map handed off from Regulatory Impact Analysis & Obligation Mapping and hands its named deliverable — a validated coverage package (the gap list, the drafted policies and controls, the operationalized process, and the validation run) — to the Regulatory Compliance Attestation Cycle.","edges":[{"id":"e-lock-executable-workplan-draft-or-update-policy","source":"lock-executable-workplan","target":"draft-or-update-policy"},{"id":"e-draft-or-update-policy-operationalize-the-process","source":"draft-or-update-policy","target":"operationalize-the-process"},{"id":"e-operationalize-the-process-classify-disposition","source":"operationalize-the-process","target":"classify-disposition"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"clean"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"escalate"},{"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":{},"controls":["UC-GOV-03","UC-GOV-14","UC-GOV-16"],"department":"compliance-legal","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-obligation-implementation","contentDigest":"sha256:1d07282aea30741e1be3a50057f444f6ebc5e5cadefc69e1e45d54f762f47f4b","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:1d07282aea30741e1be3a50057f444f6ebc5e5cadefc69e1e45d54f762f47f4b","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-obligation-implementation"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-obligation-implementation","source":"coworkcanvas-gallery","standards":["gdpr","dora","nydfs-500","eu-ai-act","nis2","pci-dss","hipaa","ccpa"],"teams":["compliance-legal"]},"name":"Regulatory Obligation Implementation","nodes":[{"data":{"description":"Lock the executable workplan","instructions":"**Objective** — Lock the executable workplan: a dated, owned remediation schedule in which every deadline is derived backward from the obligation's effective (compliance-by) date.\n\n**Inputs**\n- The gap list with its classifications — at this point, the expected gaps carried by the obligation map handed off from Regulatory Impact Analysis & Obligation Mapping (a document on that workflow's handoff step, or uploaded here if the upstream did not run in AssureSwarm); the parallel gap analysis confirms or refines the gaps.\n- The obligation's effective date — held on the anchor Audit item as `Audit.period_end` — plus any earlier filing or certification dates recorded in `Audit.scope`.\n- The proposed owner for each policy, control, and process item, which lands as `Policy.policy_owner`, `Control.control_owner`, and `Process.process_owner` on the drafted items.\n\n**Procedure**\n1. Confirm final scope, owners, evidence requirements, and review expectations for every planned item — what will exist, who builds it, what evidence proves it, and who reviews it.\n2. Set due dates using the backward-from-effective-date schedule: the policy drafted and signed off by legal or exec roughly four weeks ahead of the effective date; controls designed and rolled out six to eight weeks ahead; the process operationalized with its workflow template two to four weeks ahead; and a first validation run completed before the effective date itself.\n3. Verify the anchoring: every deadline is anchored to the effective date, and no item's date falls after the point it must be complete by — a control cannot land after the policy sign-off that references it, and nothing lands after the validation run that must exercise it.\n4. Confirm each item has an accountable owner — a named person with authority to deliver, not a team alias. An item without an owner is not planned; it is deferred.\n5. If backward scheduling produces dates already in the past (a late start), do not silently compress: sequence by exposure, record which milestones cannot be met, and escalate per this obligation's escalation thresholds.\n6. Lock the plan. Reclassification by the detailed gap analysis updates line items, but date changes after lock are recorded as plan revisions with reasons — never silent edits.\n\n**Record in AssureSwarm**\n- Attach the locked workplan as an XLSX document on this step — one row per planned item with its owner, its target date derived from the effective date (`Audit.period_end`), its evidence requirements, and its review expectations. This step defines no decision form, so the workplan lives as the step document.\n- Note any escalated infeasibility and the sequencing decision taken in that same document.\n\n**Exit criteria** — A dated, owned workplan covering every gap is locked and ready to execute; every date traces to the effective-date anchor; every item names its accountable owner.","label":"Lock executable workplan","performedBy":{"agent":"reg-artist","note":"Lock dated plan","primitives":["coach-form-fill"]}},"id":"lock-executable-workplan"},{"data":{"description":"For each policy-missing or policy-obligation-incomplete gap, draft or revise the governing Policy item so its commitment text commits the organization to what the authority requires.","instructions":"**Objective**\nFor each policy-missing or policy-obligation-incomplete gap, draft or revise the governing Policy item so its commitment text commits the organization to what the authority requires.\n\n**Inputs**\nThe obligation summary and operative source text: regulator, region, and summary carried in the anchor `Audit.description`; the source document uploaded to this step (there is no native Regulation item type). The effective date is `Audit.period_end`.\n- Every existing Policy item citing this authority (the standard appears in `Policy.framework`), every Control item citing it (`Control.framework`), and every Process item that operationalizes those controls.\n- The in-scope entities and vendor relationships from `Audit.scope` (in-scope vendors are Vendor items linked to the anchor Audit), for scoping and dating each classified gap.\n\nThe gap list entries classified policy-missing or policy-obligation-incomplete, with their proposed remediations.\n- The obligation source text uploaded at the gap-analysis step and the anchor `Audit.description` (regulator, region, summary); the source document's preview URL.\n- Any existing Policy item whose `framework` already cites the authority.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Conduct gap analysis”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Conduct gap analysis: Produce the gap analysis that drives the whole implementation: decompose what the authority requires into discrete requirements and classify exactly how far current coverage falls short of each one. This is a confirm-and-refine pass over the obligation map's expected gaps — it does not redo the applicability determination the upstream Regulatory Impact Analysis & Obligation Mapping already settled.\n\n2. Read the authority summary and its attached source document — the operative text, not a vendor summary of it.\n3. Query the existing coverage: the Policy items whose `framework` includes this authority (read each one's commitment text in `Policy.description`), the Control items citing it (`Control.framework`), and the Process items operationalizing them. Classification is made against the union of that coverage, so an incomplete query fabricates gaps.\n4. Break the authority into discrete requirements — a single authority typically yields several distinct obligations. Decompose to the level of separately satisfiable duties (\"maintain a register\", \"notify within 72 hours\", \"test annually\"), each pinned to its article or section.\n5. Classify each requirement against the existing coverage using exactly one fixed label: **policy-missing** — no citing Policy covers it; **policy-obligation-incomplete** — a Policy cites the authority but its commitment text (`Policy.description`) does not address this requirement; **control-missing** — no Control implements the policy commitment; **control-needs-modification** — an existing Control partially satisfies it and needs changes; **process-missing** — no Process operationalizes the controls. One label per requirement; where a requirement fails at multiple layers, classify at the earliest failing layer, because fixing that unblocks the rest.\n6. For every gap, propose the specific remediation and whether it is a new item or an amendment to an existing one — the drafting steps consume this verbatim.\n\n7. Assessment scope for Draft or update policy: For each policy-missing or policy-obligation-incomplete gap, draft or revise the governing Policy item so its commitment text commits the organization to what the authority requires.\n\n8. For a **missing policy**, create a new Policy item whose `description` states in plain language exactly what the organization commits to do under the cited authority (Policy has no separate obligation field — the commitment IS the policy's `description` text). Write commitments that are testable: \"we will X within Y of Z\", a named function, a stated frequency — not a paraphrase of the regulation's own prose. Set `policy_type` (policy | standard | procedure), `policy_owner`, `effective_date`, `review_frequency`, and `next_review_date`.\n9. Cite the authority by setting `Policy.framework` to the governing standard (e.g. gdpr, dora, nydfs-500, eu-ai-act, nis2, pci-dss, hipaa, ccpa) so the linkage is explicit and queryable — the same standard value the implementing controls carry in `Control.framework`.\n10. For an **incomplete obligation**, revise the existing Policy's `description` in place (and bump `version`) rather than creating a new Policy. A materially amended authority should reuse existing items so the audit trail is not fragmented — one policy with a revision history beats two policies with half a history each.\n11. Never finalize an item automatically: every create or update is proposed as a draft the operator reviews and confirms, and every rationale cites the authority source's preview URL so the reviewer can check the drafted commitment against the operative text in one click.\n12. Match each draft to its gap-list requirement one-to-one: a policy paragraph that answers no named requirement is scope creep, and a requirement no draft answers is still a gap.\n\n**Record in AssureSwarm**\nAttach the gap list as an XLSX (or CSV) gap-register document on this step, one row per requirement with: its requirement ID, its classification label, the citing items reviewed, and the proposed remediation.\n- Link the reviewed Policy, Control, and Process items to this step (Item relationship) so the judgment basis is navigable.\n\nItem create — Policy: `policy_type`, `description` (the commitment text), `framework` (the cited authority), `policy_owner`, `approved_by`, `version`, `effective_date`, `review_frequency`, `next_review_date`.\n- Item field update — for in-place revisions, update the existing Policy's `description` and `version`.\n- Item relationship — link each Policy to the anchor Audit so the implementation's policy changes are navigable from the engagement.\n- Keep the confirm-or-reject outcome of each proposed draft as a decision-log document on this step.\n\n**Exit criteria**\nA structured gap list — one classification and one proposed remediation per requirement — is documented and ready to drive policy, control, and process drafting; every requirement traces back to specific source text; every classification names the existing items it was judged against; no requirement is left unclassified. A confirmed set of draft or revised Policy items, each citing the authority in `framework`, covering every policy gap; every commitment text maps to a named requirement from the gap list; amended authorities were revised in place, not duplicated.\n\n> **⚡ Audit Artist accelerator:** `/coach-query-data` — pulls every policy, control, and process item citing the authority so classification starts from complete coverage data.","label":"Draft or update policy","performedBy":{"agent":"reg-artist","note":"Draft policy Gap classification Draft policy","primitives":["coach-item-create","coach-items-link","coach-query-data"]}},"id":"draft-or-update-policy"},{"data":{"description":"Where a process-missing gap exists, draft the Process item that operationalizes the new controls and capture the workflow template it will need — so the controls run on a schedule with owners, not on good intentions.","instructions":"**Objective**\nWhere a process-missing gap exists, draft the Process item that operationalizes the new controls and capture the workflow template it will need — so the controls run on a schedule with owners, not on good intentions.\n\n**Inputs**\nThe gap list entries classified control-missing or control-needs-modification, with proposed remediations.\n- The related Policy commitments confirmed in the previous step.\n- The obligation source text and the anchor `Audit.description`; the source document's preview URL.\n\nThe gap list entries classified process-missing.\n- The confirmed Control items the process must operationalize.\n- The obligation source text and the anchor `Audit.description`; the source document's preview URL.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Design controls”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Design controls: For each control-missing or control-needs-modification gap, draft or amend the Control items that implement the policy commitments — designed so their operation can later be evidenced and tested.\n\n2. For a **missing control**, create a new Control item that implements the relevant Policy commitment, and cite the authority by setting `Control.framework` to the governing standard.\n3. Make each design testable, because the downstream attestation cycle must evidence it: set `control_type` (preventive | detective | corrective), `automation` (automated | manual | hybrid), `frequency`, the named operator role in `control_owner`, a stable `control_id`, and describe in `description` the evidence each execution produces. A control whose operation leaves no artifact cannot be attested and will resurface as a finding.\n4. For a **control that needs modification**, amend the existing Control in place (update its fields) rather than creating a duplicate — the operating history and prior test results stay attached to one record.\n5. Each control is proposed as a draft the operator confirms — never finalized automatically — and every rationale cites the authority source preview URL so the reviewer can verify the design against the operative text.\n6. Check pair-coverage before leaving the step: every Policy commitment from the previous step has at least one implementing Control, and no drafted Control implements nothing — an orphan control is either mis-linked or unnecessary.\n\n7. Assessment scope for Operationalize the process: Where a process-missing gap exists, draft the Process item that operationalizes the new controls and capture the workflow template it will need — so the controls run on a schedule with owners, not on good intentions.\n\n8. Create a new Process item and hold it inactive until validated (Process has no framework or validation-status field beyond its default ACTIVE status — keep the item in draft and note the held-inactive-pending-validation state in its `description`). An unvalidated process presented as live coverage is a false attestation waiting to happen.\n9. Define the process concretely enough to run: set `process_type`, `process_owner`, and `frequency` (event-driven on an incident, monthly, per onboarding), and describe in `description` the controls each part of it executes and the evidence each pass produces.\n10. Flag that the process needs a workflow template that sequences its steps: capture the template's required steps and each step's owner so it can be authored. The template is created as a separate build step, not inline in this drafting — record the requirement here precisely enough that the builder needs no further interviews.\n11. As with policies and controls, the Process item is a draft the operator confirms, with the authority preview URL cited in the rationale.\n12. Confirm mapping completeness: every confirmed Control that needs operationalizing appears in a process's coverage — a control no process runs will never generate operating evidence.\n\n**Record in AssureSwarm**\nItem create — Control: `control_id`, `description`, `framework` (the cited authority), `control_type`, `control_category`, `automation`, `key_control`, `frequency`, `control_owner`.\n- Item field update — for modifications, update the existing Control's fields.\n- Item relationship — Control ↔ the implementing Policy, and Control ↔ the anchor Audit.\n- Keep the confirm-or-reject outcome of each proposed draft as a decision-log document on this step.\n\nItem create — Process: `process_type`, `process_owner`, `frequency`, `description` (the controls it operationalizes and the held-inactive-pending-validation note).\n- Item relationship — Process ↔ its Control items (the authority linkage flows through those controls' `framework`, since Process has no framework field), and Process ↔ the anchor Audit.\n- Step document — the workflow template requirement (required steps and each step's owner) as a document on this step, for the separate template-build step to consume.\n- Keep the confirm-or-reject outcome of the proposed draft on this step.\n\n**Exit criteria**\nA confirmed set of draft or amended Control items, each citing the authority in `framework` and traced to a Policy commitment, covering every control gap; modifications reused existing controls rather than fragmenting the trail. A confirmed draft Process item, held inactive pending validation, linked to its controls and the anchor Audit, with its workflow template requirement documented — concrete steps and owners — covering the process gap.","label":"Operationalize the process","performedBy":{"agent":"reg-artist","note":"Operationalize process Design controls Operationalize process","primitives":["coach-item-create","coach-items-link","coach-workflow-build"]}},"id":"operationalize-the-process"},{"data":{"decisionField":"disposition_path","description":"Validate end-to-end coverage against the gap list, then classify the result of Regulatory Obligation Implementation so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"No reportable gap","value":"clean"},{"label":"Remediation required","value":"remediate"},{"label":"Escalate significant issue","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Validate, before the effective date, whether the drafted policy, controls, and process actually close the obligation, then classify the implementation's end-state so closure follows the right path. The implementation owner classifies, with compliance-officer concurrence for any non-clean pick.\n\n**Inputs**\n- The confirmed Policy, Control, and Process items.\n- The gap list they were built to close, with its requirement IDs (the gap-register document on the gap-analysis step).\n- The effective date (`Audit.period_end`) and the workplan's validation milestone.\n\n**Procedure**\n_Items 1–5 are agent-run (folded from the former \"Validate coverage\" step); the human moment is the classification in item 6._\n1. Execute a first run of the process via its workflow template as a validation cycle — real steps, real owners, real evidence, not a tabletop. Capture what each step produced and where it stalled.\n2. Confirm coverage requirement by requirement: each gap-list requirement now resolves to a linked Policy whose commitment text (`Policy.description`) answers it, an implementing Control, and an operational Process. Read the links in both directions — a requirement \"covered\" by a policy whose commitment text never mentions its subject is a paper link, not coverage.\n3. Verify the first run completes before the effective date. A validation that finishes after the compliance-by date documents lateness; it does not cure it — carry that fact straight into the classification below.\n4. Note any requirement still uncovered — or covered on paper but failed in the run — as a residual gap with an owner and a date. Do not soften run failures into \"observations\"; the classification needs them countable.\n5. Where the run surfaced fixable friction (a wrong step owner, evidence stored outside AssureSwarm), fix it and note the fix; where it surfaced design failure, leave the item as a residual gap rather than patching live.\n6. Classify the end-state against the criteria below, on the coverage trace and the residual-gap list.\n\n**Decision criteria**\n- **clean** (\"No reportable gap\") — validation confirmed every gap-list requirement covered by a linked policy obligation, an implementing control, and an operational process; the first process run completed before the effective date; no residual gaps remain open. Documentation tidy-ups already fixed during validation (item 5) do not break clean.\n- **remediate** (\"Remediation required\") — residual gaps exist but are bounded and schedulable: a control landing after the effective date, a validation-run step that failed and needs redesign, coverage confirmed for some entities but not yet all. Pick this when interim mitigation can be articulated, a credible completion date exists, and no external certification, filing, or attestation is jeopardized in the meantime.\n- **escalate** (\"Escalate significant issue\") — the miss is material or time-critical: a core obligation uncovered at the effective date with real enforcement exposure; a certification or filing the organization cannot truthfully sign as things stand (an NYDFS Part 500 certification, a DORA register submission); an interpretation dispute that changes scope; or a fix needing budget or authority beyond the implementation owner. Escalation is also the required path for deliberate risk acceptance — that decision belongs to the compliance officer or governance delegate, never to this workflow's own owner.\n\n**Record in AssureSwarm**\n- Step document — the requirement-by-requirement coverage trace (XLSX) on this step, recording each requirement's confirmed policy/control/process links and the residual gaps with owners and dates.\n- Workflow instance — link the executed first-run workflow instance of the new process to this step as the validation evidence.\n- Submit the `disposition_path` SELECT. The rationale cites the validation results and names each residual gap driving a non-clean pick. Record the decision owner; note compliance-officer concurrence for remediate and escalate.\n\n**Exit criteria** — Every requirement from the gap list is traced to live linked coverage or a named residual with an owner and date; the completed first process run predates the effective date or the lateness is recorded in the rationale; form submitted with rationale and owner; unselected branches are prunable because their edge `whenValue`s do not match the selected value.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"reg-artist","note":"Validate coverage","primitives":["coach-workflow-execute","coach-query-data"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert every residual gap into an owned, dated, closure-testable Issue with interim mitigation, so remediation is tracked to completion instead of decaying into a list.\n\n**Inputs**\n- The residual gaps from validation (the coverage-trace document), each tied to the requirement it leaves uncovered.\n- The disposition rationale; the effective date (`Audit.period_end`) and any regulator-facing dates.\n- This obligation's escalation thresholds.\n\n**Procedure**\n1. Run a short root-cause pass per gap: under-scoping, drafting capacity, an external dependency (vendor, system change), or an interpretation stall. The cause picks the fix — re-plan, re-draft, or unblock the dependency — and prevents re-treating symptoms.\n2. Write each action at closure-testable granularity: \"deploy the retention-deletion control at entity B and evidence one execution\", not \"improve retention\". Each action gets exactly one accountable owner and a due date; where completion falls after the effective date, justify the exposed interval explicitly.\n3. Specify interim mitigation for the exposed window — compensating manual checks, restricted processing, heightened monitoring — and name who operates it until the fix lands. An action plan without interim mitigation is a schedule, not a risk response.\n4. Define the closure evidence per action: the same requirement-to-policy-to-control-to-process trace validation ran, plus execution evidence for the fixed piece. Closure is declared against that evidence, not against the owner's assurance.\n5. Set the reporting cadence and forum (for example, biweekly to the compliance officer until closure) and the slippage trigger — an action more than two weeks late, or re-dated twice, escalates automatically.\n\n**Record in AssureSwarm**\n- Item create — one Issue per residual gap: `issue_type: deficiency`, `source: compliance_review`, `description`, `root_cause`, `remediation_plan` (interim mitigation, closure evidence required, reporting cadence and slippage trigger), `issue_owner`, `identified_date`, `target_remediation_date`.\n- Item relationship — Issue ↔ the anchor Audit, and Issue ↔ the affected Control or Process.\n- The open Issues' `target_remediation_date` values are the follow-up dates the attestation cycle and the archived workflow instance track — there is no separate watchlist surface.\n\n**Exit criteria** — Every residual gap has an owned, dated Issue with interim mitigation and defined closure evidence; reporting cadence and slippage trigger recorded in `remediation_plan`; each Issue linked to the anchor Audit and the affected control/process.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Escalate to compliance officer, legal owner, obligation owner, or governance delegate or document risk acceptance","instructions":"**Objective** — Put the significant gap in front of the right decision authority with a decision-ready memo, and leave with either a resourced remediation decision or an explicit, conditioned, expiring risk acceptance.\n\n**Inputs**\n- The escalation rationale from disposition; the residual gap detail and validation evidence.\n- Exposure inputs: penalty regimes, certification or filing dates at risk, affected entities and data volumes.\n- This obligation's escalation thresholds and contacts.\n\n**Procedure**\n1. Route to the right authority per the thresholds: the compliance officer for interpretation and priority calls; the legal owner for positions with enforcement exposure; the obligation owner for business-side fixes; the governance delegate or committee where acceptance authority formally sits. An acceptance signed below the exposure's authority level does not stand.\n2. Quantify impact honestly: which requirement is uncovered, since and until when, the enforcement range it sits under (GDPR's up-to-4%-of-worldwide-turnover tier, DORA and NIS2 penalty regimes, contract and attestation consequences), and the likelihood drivers — regulator attention on the topic, prior findings, data volumes.\n3. Present real options with costs and dates: crash-schedule remediation, interim mitigation plus a dated fix, or time-boxed acceptance. Recommend one — a memo without a recommendation exports the analysis to the decider.\n4. If the decision is acceptance, record it as a policy-exception Issue (the AssureSwarm pattern for waivers and risk acceptances): capture exact scope in `description` (what is accepted and what is not), the compensating conditions that must operate, `exception_approver` (the accepting officer), and `exception_expiry_date` (the filterable expiry index — an undated acceptance is indefinite non-compliance). Set `treatment: accept` on the linked Risk.\n5. Define follow-up ownership: who tracks the acceptance conditions or the funded remediation, and where it reports — normally the Regulatory Compliance Attestation Cycle picks it up each cycle.\n\n**Record in AssureSwarm**\n- Step document — attach the decision memo and recorded outcome (DOCX) to this step.\n- Item create — for a risk acceptance: an Issue with `issue_type: policy_exception`, `exception_approver`, `exception_expiry_date`, `source: compliance_review`, `description` (scope + conditions); and a Risk item (`category: compliance_regulatory`, `treatment: accept`, `residual_rating`, `risk_owner`) capturing the accepted exposure.\n- Item relationship — link the policy-exception Issue to the affected Policy and/or Risk, and link the Risk to the anchor Audit.\n- The `exception_expiry_date` is the filterable expiry index the attestation cycle re-checks each cycle — there is no separate watchlist surface; the named follow-up owner tracks it.\n\n**Exit criteria** — A decision by the authority matching the exposure level is recorded, with conditions, expiry (for acceptance, as `exception_expiry_date`), and a named follow-up owner; memo and outcome attached.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"description":"Hand the implemented obligation to the Regulatory Compliance Attestation Cycle with everything it needs to attest ongoing compliance and an explicit list of what it must not redo, and close the implementation on that acknowledged receipt with an audit trail a future examiner can reconstruct without relying on anyone's memory.","instructions":"**Objective**\nHand the implemented obligation to the Regulatory Compliance Attestation Cycle with everything it needs to attest ongoing compliance and an explicit list of what it must not redo, and close the implementation on that acknowledged receipt with an audit trail a future examiner can reconstruct without relying on anyone's memory.\n\n**Inputs**\nEverything the executed path produced: the obligation map, the gap list, the confirmed policies, controls, and process, the validation results, and the action plan or escalation/risk-acceptance record where those paths ran.\n- The proposed conclusion from the implementation owner.\n\nThe final package from the preceding procedure, and the full linked item set: authority, policies, controls, process, actions, acceptances.\n- The open-item ledger: action-plan items, risk-acceptance conditions and expiries.\n- The owner roster for the obligation's policies, controls, and process; this obligation's distribution list and escalation contacts.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Prepare final package”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Prepare final package: Assemble the single evidence package from which a reviewer, the attestation owner, or an examiner can reconstruct the whole implementation — what the authority required, what changed, and what proves coverage — without chasing anyone.\n\n2. Assemble in the order a reviewer needs: (a) the authority and its effective date; (b) applicability and scope, including exclusions; (c) the gap list with classifications; (d) requirement-by-requirement coverage — policy obligation, control, process, with links; (e) the validation run evidence; (f) residual items — the action plan or the escalation/acceptance decision; (g) the proposed conclusion.\n3. Walk the traceability chain one final time: every requirement resolves to either evidenced coverage or an owned action or acceptance. Anything resolving to neither is an undisposed gap — stop and route it back to disposition rather than packaging around it.\n4. State the conclusion in one sentence with its qualifier: \"obligation implemented and validated before the effective date; two entity-B actions open to 2026-09-30\".\n5. List the unresolved constraints and assumptions the attestation cycle must carry forward — pending counsel confirmation, approvals conditioned on a later rollout, acceptance expiries.\n6. Have the implementation owner review the package for completeness before handoff; downstream attestations will be signed on this record.\n\n7. Assessment scope for Handoff to related workflow: Hand the implemented obligation to the Regulatory Compliance Attestation Cycle with everything it needs to attest ongoing compliance and an explicit list of what it must not redo, and close the implementation on that acknowledged receipt with an audit trail a future examiner can reconstruct without relying on anyone's memory.\n\n8. Create or link the Regulatory Compliance Attestation Cycle for this authority and pass the final package.\n9. Draw the consume-versus-verify line explicitly: the attestation cycle consumes the applicability decision, the gap analysis, and the design-stage validation; it re-verifies operating evidence every cycle — control executions, process runs, evidence freshness. State plainly that it should not redo gap analysis or re-litigate applicability absent a change trigger (an amendment, a scope change, an expired exclusion re-affirmation).\n10. Transfer the open-item ledger with owners and dates: each action-plan item and each acceptance condition or expiry becomes something the attestation cycle checks every cycle until closed.\n11. Pass the assumptions the downstream owner must know: interpretation positions taken and any approvals carrying conditions.\n12. Get an acknowledged receipt: the attestation cycle's owner confirms the package — an approval on this step or a comment on the handoff — so the ownership transfer has a name and a timestamp.\n13. Sweep the executed path for completeness: every step carries its records and attachments; every decision form is submitted with rationale and owner; the traceability chain from authority text to evidence holds end to end. Fix gaps now — after archive they become addenda, not edits.\n14. Bring linked records to their end-state: policies and controls reflect the approved versions and owners; the process item drafted here leaves its held-inactive state only if validation passed (otherwise it stays inactive and the action plan owns activation); the authority item reflects its implemented status.\n15. Schedule what outlives this workflow as watchlist entries with owners, not calendar folklore: the attestation cadence, action-plan report dates, risk-acceptance expiries.\n16. Communicate closure to this obligation's distribution list: the conclusion, its qualifier, and where the package lives.\n17. Record the archive confirmation on this step; post-archive corrections are new dated addenda, never edits to the archived record.\n\n**Record in AssureSwarm**\nStep document — attach the compiled implementation evidence package (PDF/DOCX) to this step.\n- Item relationship — link the anchor Audit, the Policy, Control, and Process items, the validation-run workflow instance, and the action-plan Issues or the risk-acceptance record so the package is navigable from here.\n- Record the proposed conclusion, its qualifier, and the owner's completeness review as a note on this step (or the package's cover section) — this step has no native form fields.\n\nWorkflow instance — create or link the downstream Regulatory Compliance Attestation Cycle workflow instance from this step; the archived run of this workflow is the durable audit trail.\n- Handoff package — attach the handoff note document (package contents, the open-item ledger with owners and dates, assumptions, and the do-not-repeat list) on this step, and record the receiving owner's acknowledgment as an approval or comment so the ownership transfer carries a name and timestamp.\n- Item field update — set the anchor `Audit` status to completed and `Audit.report_date` to the closure date; bring linked Policy and Control items to their approved end-state; the Process item leaves its held-inactive state only if validation passed.\n- Open action-plan Issues keep their `target_remediation_date` as the durable follow-up dates (there is no native watchlist surface); risk-acceptance `exception_expiry_date` values carry the review dates.\n- Record the closure communication note and the archive confirmation on this step.\n\n**Exit criteria**\nPackage attached and complete against the assembly list; traceability verified with zero undisposed requirements; conclusion, qualifier, and open constraints stated; owner review recorded. Downstream workflow linked; package, open items, and assumptions transferred with the do-not-repeat list stated; receipt acknowledged by the named downstream owner; all executed-path records complete; linked items at end-state; follow-ups scheduled with owners; closure communicated; archive confirmation recorded.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — compiles the linked items, documents, decisions, and evidence into the reviewer-ready package.","label":"Handoff to related workflow","performedBy":{"note":"","primitives":["coach-render-package"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:reg-obligation-implementation"}