{"description":"Third-Party ICT Vendor Regulatory Assurance as a decision-aware workflow. Each cycle runs on its own Audit engagement item (audit_type = vendor_review) created at kickoff, with Audit.scope set to the in-scope legal entities, regimes, and vendor population; every workpaper, decision form, and gap attaches to that instance. In scope: ICT third-party service providers — including intra-group ICT providers — assessed against DORA, NIS2, and US interagency/FFIEC third-party expectations; out of scope: non-ICT vendors, which stay with the general vendor lifecycle. It consumes the arrangement-level inventory, tiering, and due-diligence handoff package from Third-Party Vendor Risk Lifecycle (whose provider records are the Vendor items); refers vendor SOC 1/SOC 2 reports carrying real reliance to the Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow and folds back its reliance conclusions; and produces a provision-cited, severity-rated gap register (Issue items linked to the anchor Audit and the affected Control/Vendor records) plus a qualified final assurance package. It hands the validated obligation statuses to the Regulatory Compliance Attestation Cycle, exchanging handoff packages with related workflows instead of duplicating repeated work.","edges":[{"id":"e-lock-executable-workplan-classify-disposition","source":"lock-executable-workplan","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"clean"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"escalate"},{"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-TPRM-01","UC-TPRM-04","UC-ASSET-05","UC-LOG-09","UC-TPRM-05","UC-TPRM-06"],"department":"procurement","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-third-party-ict-vendor-assurance","contentDigest":"sha256:b4c06cb6a2ba39ca07accbded09c9f8aedbc921ced294ee70b6041ac580956fa","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:b4c06cb6a2ba39ca07accbded09c9f8aedbc921ced294ee70b6041ac580956fa","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-third-party-ict-vendor-assurance"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"reg-third-party-ict-vendor-assurance","source":"coworkcanvas-gallery","standards":["dora","nis2"],"teams":["procurement","compliance-legal"]},"name":"Third-Party ICT Vendor Regulatory Assurance","nodes":[{"data":{"description":"Freeze scope, owners, dates, evidence requirements, and review expectations into a single dated workplan, so both execution and any later scope change are traceable.","instructions":"**Objective**\nFreeze scope, owners, dates, evidence requirements, and review expectations into a single dated workplan, so both execution and any later scope change are traceable.\n\n**Inputs**\nThe vendor inventory from Third-Party Vendor Risk Lifecycle — the lifecycle-owned Vendor items (tier, category, data_classification, monitoring_status) plus the handoff document's arrangement-level rows and criticality flags.\n- Independent completeness sources uploaded at this step (PBC/external): the AP/spend extract for ICT service payments, the contract repository index, the asset/CMDB inventory, SSO or network-egress lists for shadow ICT.\n- Subcontracting notifications received during the period; the register-of-information extract if maintained.\n\nThe anchor Audit engagement item for this cycle (audit_type = vendor_review), created at kickoff — the instance attaches to it and every workpaper below hangs off it.\n- Consumes the handoff-package document from Third-Party Vendor Risk Lifecycle: the vendor inventory at arrangement level, risk tiers, criticality flags, and due-diligence artifacts forming this cycle's population baseline (the upstream provider records are Vendor items).\n- The in-scope entities, regimes, vendor-population boundary, and materiality floor for the cycle, plus any drivers that warrant deeper testing or wider samples (first cycle under a regime, a new critical provider, a material subcontracting change, a vendor incident, a concentration flag, or an exam/authority request).\n- The anchor dates (register-of-information submission, examination, attestation-cycle start) that drive the back-plan.\n- Reviewer expectations: who reviews workpapers and what sign-off closes each phase.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Inventory relationships”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Inventory relationships: Establish the complete, attribute-accurate population of ICT third-party arrangements this assurance runs over; every later test inherits this population, so a completeness failure here silently exempts a vendor from everything downstream.\n\n2. Work at contractual-arrangement level, not vendor level — a provider with three service contracts is three arrangements, and the DORA register of information is kept per arrangement.\n3. Triangulate completeness across at least two independent sources: reconcile the inventory against AP spend (providers paid for ICT services but absent), the contract repository (executed ICT contracts with no inventory row), and CMDB/SSO (services in production with no contract record — shadow ICT). Disposition every unreconciled item: added to the population, or documented out with a reason.\n4. Verify register-grade attributes per arrangement: provider legal name and LEI, ICT service type, the function supported, data processing and storage locations, and the subcontractor chain (rank 1..n) for arrangements supporting critical or important functions.\n5. Challenge the criticality flags against DORA Art. 3(22): would disruption materially impair financial performance, the soundness or continuity of services, or continuing compliance with authorization conditions? Sample the \"not critical\" designations — a provider whose outage would halt payments or regulatory reporting cannot be non-critical. Misclassification here exempts the arrangement from Art. 30(3) contract requirements and exit-plan obligations, which is exactly where examiners look first.\n6. Build the concentration view: group arrangements by provider and by connected providers (same group); flag single providers supporting multiple critical functions or serving multiple group entities. This feeds the Art. 29 concentration assessment in the governance step.\n\n7. Assessment scope for Lock executable workplan: Freeze scope, owners, dates, evidence requirements, and review expectations into a single dated workplan, so both execution and any later scope change are traceable.\n\n8. Enumerate the test matrix: arrangement × obligation area — inventory/register accuracy, governance (strategy, pre-contract assessment, exit strategy), contract provisions (DORA Art. 30(2), plus 30(3) for critical arrangements), assurance evidence, and monitoring operation. Every in-scope arrangement appears in at least the inventory and register tests; critical arrangements appear in all areas.\n9. Specify per-cell evidence before fieldwork: a register test needs the register extract and the executed contract; a contract-clause test needs the contract and all amendments; a monitoring test needs the period's SLA reports, incident notifications, and review evidence. A cell with no locatable evidence source is a finding waiting to happen — flag it now, not mid-fieldwork.\n10. Set an owner and due date per cell; back-plan so fieldwork ends with review buffer (two weeks is a workable floor) before the earliest anchor date.\n11. Fix the change-control rule: after lock, scope changes need the assurance lead's documented approval and become dated plan amendments — never silent edits. Additions discovered in fieldwork follow the same rule.\n12. Route the plan through the assurance lead's approval on this step.\n\n**Record in AssureSwarm**\nLink the anchor Audit to the lifecycle-owned Vendor items for the in-scope providers (the provider population of record). The finer arrangement-level rows and register-grade attributes — LEI, ICT service type, data-processing/storage locations, and the rank-1..n subcontractor chain — have no native Vendor field, so they live in the reconciliation workpaper attached as a step document (XLSX) alongside every discrepancy's disposition; say so rather than implying a native home.\n- Record criticality-challenge results in the workpaper; route corrected criticality flags to the Vendor items as suggested changes on Vendor.tier (never a direct edit — those records are owned by the vendor lifecycle).\n- Attach the concentration view and the discrepancy list as step documents; where triangulation surfaces material third-party concentration, note it for the third_party Risk item feeding the governance step.\n\nAttach the locked workplan as a step document (XLSX test matrix with owners, dates, evidence sources).\n- Set the anchor engagement fields: Audit.scope (in-scope entities, regimes, vendor-population boundary, materiality floor), Audit.description (cycle trigger/drivers), and the back-plan dates on Audit.period_start / Audit.period_end / Audit.fieldwork_start / Audit.fieldwork_end (register-submission and attestation dates that have no native Audit field stay in the workplan document).\n- Record the change-control rule and reviewer/sign-off expectations in the step document; capture the assurance lead's approval on this step.\n\n**Exit criteria**\nPopulation reconciled against at least two independent sources with every discrepancy dispositioned; every arrangement carries register-grade attributes; criticality challenges documented; concentration view built. Matrix complete with owner, date, and evidence source per cell; dates clear the earliest anchor date with review buffer; change-control rule stated; plan approved by the assurance lead.\n\n> **⚡ Audit Artist accelerator:** `/coach-query-data` — pulls the arrangement population with attributes and links from AssureSwarm so the reconciliation starts from complete in-system data.","label":"Lock executable workplan","performedBy":{"note":"","primitives":["coach-query-data"]}},"id":"lock-executable-workplan"},{"data":{"decisionField":"disposition_path","description":"Bring the vendor obligation register — and the DORA register of information where testing found it wrong — to the assessed state, then classify this cycle's end-state so closure follows the right path and the downstream attestation cycle consumes current statuses instead of re-deriving them. The assurance lead classifies, with compliance-officer concurrence required for any non-clean pick.","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**\nBring the vendor obligation register — and the DORA register of information where testing found it wrong — to the assessed state, then classify this cycle's end-state so closure follows the right path and the downstream attestation cycle consumes current statuses instead of re-deriving them. The assurance lead classifies, with compliance-officer concurrence required for any non-clean pick.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe reconciled arrangement population and concentration view from the prior step (the Vendor items plus the reconciliation workpaper).\n- The ICT third-party risk strategy and outsourcing/TPRM policy — Policy items (policy_type: policy/standard, policy_owner, approved_by, framework including dora/nis2, next_review_date) with the governing documents attached; approval records on the items.\n- The register-of-information extract and evidence of its last submission to the competent authority (the authoritative register is an external system; AssureSwarm holds the tested extract as a step upload).\n- Pre-contract assessment records for recent onboardings; exit plans for critical arrangements; board or committee minutes covering ICT third-party risk — uploaded at this step (PBC).\n\nExecuted contracts and all amendments for the sampled arrangements.\n- Vendor assurance artifacts: SOC 2 / SOC 1 (ISAE 3402) reports, ISO 27001 certificates with Statements of Applicability, penetration test summaries, questionnaire responses.\n- Criticality flags from the inventory step; the locked test matrix.\n\nThe monitoring procedures and the period's artifacts: SLA/performance reports, incident notifications, KRI dashboards, reassessment records, subcontractor change notices, exit-plan review and test evidence.\n- The internal incident register for the period.\n- The monitoring cells of the locked test matrix.\n\nExceptions from the governance assessment, contract/control evaluation, and monitoring tests.\n- The arrangement population with criticality flags; the escalation thresholds set for the cycle.\n\nThe gap register and per-arrangement conclusions.\n- The vendor obligation register and the register of information with its last-submission record.\n- The ownership map: which register fields this workflow owns versus the vendor lifecycle.\n\n*Agent retrieval, preparation and filing absorb “Assess regulatory governance”, “Evaluate vendor controls”, “Test ongoing monitoring”, “Report regulatory gaps”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Assess regulatory governance: Rate the organization's third-party ICT governance against what the regimes actually mandate — strategy, register, pre-contract assessment, exit strategies, board oversight — element by element, with the failed provision named for anything that misses.\n\n2. Strategy and policy (DORA Art. 28(2)): a strategy on ICT third-party risk exists, includes a policy on the use of ICT services supporting critical or important functions, is approved by the management body, and was reviewed within the cycle. Check the review was substantive (dated changes), not a rubber-stamped re-adoption. FFIEC analog: board-approved third-party risk management commensurate with risk.\n3. Register of information (Art. 28(3)): maintained at entity, sub-consolidated, and consolidated levels; distinguishes arrangements supporting critical or important functions. Test both directions — sample arrangements from the reconciled population into the register (completeness) and register rows back to executed contracts (accuracy), checking LEI, service type taxonomy, and subcontractor ranks against the ESAs' register templates. Confirm the annual submission to the competent authority happened or is scheduled with an owner.\n4. Pre-contract assessment (Art. 28(4)): for a sample of period onboardings involving critical or important functions, verify the criticality determination, the Art. 29 concentration assessment (substitutability, multiple arrangements with the same or connected providers), and due diligence proportionate to the tier were completed before signature — not backfilled.\n5. Exit strategies (Art. 28(8)): every critical arrangement has a documented exit plan naming alternatives and transition arrangements, reviewed within the cycle and tested where appropriate; contracts contain the transition-period support required by Art. 30(3).\n6. Oversight: the board or delegated committee received ICT third-party risk reporting during the period and the minutes evidence challenge, not mere receipt; for NIS2 entities, management approval and oversight of supply-chain security measures (Art. 20, Art. 21(2)(d)).\n7. Rate each element: designed and operating / designed but not operating / not designed — each with the specific provision and evidence reference. Ratings without citations do not survive the gap report.\n\n8. Assessment scope for Evaluate vendor controls: Conclude, arrangement by arrangement, whether vendor-side contract provisions and control evidence satisfy the regulatory obligations — clause-level contract testing plus a triage of each arrangement's independent assurance.\n\n9. Test every sampled contract against DORA Art. 30(2) clause by clause: service and function description; data processing and storage locations with change notice; availability, integrity, and confidentiality provisions including personal data; access, recovery, and return of data on insolvency or termination; service level descriptions; incident assistance at no additional or ex-ante-agreed cost; cooperation with competent authorities; termination rights and notice periods. Score each clause present / partial / absent with a pinpoint contract reference.\n10. For critical-or-important-function arrangements, add Art. 30(3): full SLAs with quantitative performance targets and remedies; provider notice and reporting obligations; provider ICT security and contingency-testing obligations; participation in the entity's threat-led penetration testing where applicable; unrestricted rights of access, inspection, and audit for the entity and its regulator; and exit assistance with an adequate transition period. A missing audit-rights or exit clause on a critical arrangement is a per-se gap however strong the SOC report — the contract is the enforceable instrument.\n11. Read the supplied assurance artifacts and request any missing report, bridge or scope evidence from the sampled vendor’s assurance contact as documents, then triage the arrangement’s independent assurance: report type and period versus your assurance period (a coverage gap over ~3 months needs a bridge letter), scope match (the service you consume appears in the system description), opinion qualifications, exceptions touching your obligations, and subservice carve-outs — every carve-out supporting a critical function is your fourth-party exposure. Refer the reports carrying real reliance for full review and CUEC mapping to the related Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow, and fold its reliance conclusions into your per-arrangement conclusions.\n12. Where a critical arrangement has no usable independent report, plan alternative assurance under the contractual audit right (targeted evidence requests tied to the uncovered obligations, or an on-site visit) and rate the interim uncertainty honestly rather than defaulting to \"met\".\n13. For US-supervised entities, overlay the Interagency Guidance lens: due diligence and monitoring artifacts commensurate with criticality — financial condition, information security, resilience testing, subcontracting visibility.\n14. Conclude per arrangement, per obligation area: met / met-with-conditions / gap, each naming the failed clause or missing evidence.\n\n15. Assessment scope for Test ongoing monitoring: Conclude whether ongoing vendor monitoring actually operated through the full assurance period — SLA review, incident flow, reassessment, subcontracting-change and concentration refresh — not merely that procedures exist.\n\n16. Sample all critical-or-important-function arrangements plus the risk-based remainder, and spread testing across the whole period — recency-only sampling misses mid-period lapses, which is precisely what examiners re-test.\n17. SLA monitoring: for each sampled arrangement, verify performance reports arrived on the contractual cadence, a named owner evidenced review (sign-off, minutes, ticket), and breaches were pursued to remediation or service credits per contract. A quarter with no report and no chase means the control did not operate that quarter — record it as a lapse with its window, not as a nuance.\n18. Incident flow: reconcile vendor incident notifications against the internal incident register in both directions. Test that vendor incidents affecting the entity entered the entity's own classification under DORA Art. 18 within required timelines — a vendor outage can be the entity's reportable major incident under Art. 19, and a notification that died in a mailbox is a finding on the entity, not the vendor.\n19. Reassessment cadence: risk reassessments occurred at the policy frequency (at least annually for critical arrangements is the common floor) and covered changed facts — new subcontractors, changed data locations, deteriorated vendor financials.\n20. Subcontracting and concentration: material subcontracting changes on critical arrangements were notified and risk-assessed before taking effect (per the DORA RTS on subcontracting); the Art. 29 concentration factors were re-evaluated when the estate changed; exit plans for critical arrangements were reviewed or tested on schedule.\n21. Where vendors connect into the estate, verify the period's reviews of vendor accounts and access, and of security-event feeds from vendor-operated services, actually happened.\n22. Conclude per monitoring control: operated throughout / lapsed (state the arrangement and window) / did not operate — with instance-level evidence.\n\n23. Assessment scope for Report regulatory gaps: Consolidate every exception from the governance, contract, and monitoring work into one rated, provision-cited gap register and issue the report to accountable owners.\n\n24. Build the gap register: one row per gap — the provision failed (DORA article and paragraph, NIS2 article, Interagency Guidance element), the affected arrangement(s), the evidence reference, and the source test. Every exception from the preceding procedure appears exactly once; an exception that vanishes between fieldwork and report is the finding an examiner enjoys most.\n25. Rate severity with stated criteria: **Critical** — a mandatory provision or control missing on a critical-or-important-function arrangement with live regulatory exposure (no audit rights, no exit plan, a materially inaccurate register submission). **High** — the same class with partial mitigation, or a systemic monitoring lapse across arrangements. **Medium** — gaps confined to non-critical arrangements or bounded single-period lapses. **Low** — documentation hygiene. Roll up: multiple Mediums sharing one root cause (e.g. a contract template predating DORA) escalate to a single systemic High.\n26. Split entity-side from vendor-side gaps: an inaccurate register, a missing exit plan, or a monitoring lapse is fixable internally on internal clocks; missing contract clauses or unremediated report exceptions need vendor negotiation and often wait for renewal. Different owners, different remediation physics — the action plan downstream depends on this split.\n27. Draft the report — scope, method, coverage statistics, the gap register, thematic root causes, and a proposed disposition per gap — and circulate to arrangement owners for factual accuracy only. Corrections land as dated updates on the gap items with comments; severity is not negotiated in the accuracy pass.\n\n28. Assessment scope for Classify disposition: Bring the vendor obligation register — and the DORA register of information where testing found it wrong — to the assessed state, then classify this cycle's end-state so closure follows the right path and the downstream attestation cycle consumes current statuses instead of re-deriving them. The assurance lead classifies, with compliance-officer concurrence required for any non-clean pick.\n\n29. Set per-obligation status on each in-scope arrangement: compliant / gap-open / gap-remediating, each with an evidence link and assessment date. A status without an evidence link does not count as assessed — leave it explicitly unassessed rather than fake precision.\n30. Correct register-of-information inaccuracies found in testing (wrong LEI, missing subcontractor rank, stale criticality flag, wrong data location) as dated updates citing the test workpaper. If the annual submission to the competent authority already went out containing material inaccuracies, raise to the compliance officer whether correction or notification to the authority is required — that call is theirs, but this step forces the question and records the disposition.\n31. Apply criticality changes from the inventory challenge: a newly-critical arrangement inherits Art. 30(3) contract requirements and exit-plan obligations — schedule the uplift as a gap/action if it is not already one.\n32. Reconcile: the set of register rows touched equals the set of in-scope arrangements assessed — no orphan updates, no assessed arrangement left stale.\n33. Route corrections to records owned by the vendor lifecycle (tiers, due-diligence fields) as suggested changes rather than direct edits, keeping ownership honest.\n34. Classify the cycle's end-state against the criteria below, on the assessed register and the gap severities.\n\n**clean** (\"No reportable gap\") — no open gap rated Medium or above; the register of information is accurate or already corrected; every critical-or-important-function arrangement has compliant contract provisions (Art. 30(2) and (3)), current assurance evidence with a reliance conclusion, and monitoring that operated through the whole period; only Low/hygiene items remain, logged with owners.\n- **remediate** (\"Remediation required\") — open gaps are bounded and schedulable: a missing contract clause slated for amendment at a renewal inside a defensible window, a monitoring lapse with the process already restarted, unmapped CUECs assigned to control owners, register corrections in flight. Pick this when interim mitigation is articulable for every gap, credible dates exist, and no register submission, attestation, or certification would be signed inaccurately in the meantime.\n- **escalate** (\"Escalate significant issue\") — the exposure is material or time-critical: a critical arrangement with no audit rights or exit plan and a vendor unwilling to amend; a register submission to the competent authority that was materially inaccurate (the item 30 question dispositioned toward notification); a vendor incident that met reporting thresholds but did not flow through required notifications; concentration on a non-substitutable provider with no exit strategy; or any fix needing budget or authority beyond the assurance lead (vendor exit, contract termination). Deliberate risk acceptance also routes here — acceptance belongs to the compliance officer or governance delegate, never to the workflow's own lead.\n\n**Record in AssureSwarm**\nAttach the governance assessment workpaper (XLSX/DOCX) as a step document, with per-element ratings and provision citations.\n- Record the two-direction register test results (sample sizes, error counts) in that workpaper.\n- Link the anchor Audit to the Policy items for the strategy and TPRM/outsourcing policy examined; attach the register extract, exit-plan, and minutes documents to this step (they have no native item home).\n\nRecord independent assurance type, period and carve-outs from the reports; processing/storage locations from the reconciled inventory and contract; and access, inspection, audit and exit terms from executed instruments. Attach any missing evidence supplied by the vendor and record specific unresolved questions in the triage/alternative-assurance workpaper.\n- Attach the clause-level contract test matrix and the assurance-evidence triage as step documents (XLSX). Per-arrangement met / met-with-conditions / gap conclusions live in that matrix — there is no native per-arrangement obligation field, so keep them in the workpaper and say so.\n- Note where a conclusion depends on a SOC report referred for full review; upload the executed contracts, amendments, SOC/ISAE reports, and ISO certificates examined to this step (PBC), linked to the anchor Audit and the corresponding Vendor items.\n- List the arrangements referred to the Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow in the same matrix; link that workflow run so its reliance conclusions fold back here.\n\nAttach the monitoring test workpapers (XLSX) as step documents, with the sample list and period coverage.\n- Record per-control operated-throughout / lapsed / did-not-operate conclusions and every lapse with its bounded window in the workpaper. The entity monitoring controls under test ARE Control items (UC-TPRM-*, UC-ASSET-05, UC-LOG-09) — a lapse becomes a gap Issue linked to that Control in the reporting step; identify the Control here so the linkage is unambiguous.\n- Attach the two-way vendor-incident reconciliation as a step document (the internal incident register arrives as an extract — there is no native Incident type); link the artifacts examined.\n\nBuild the gap register as Issue items — one per gap: issue_type: finding (issue_type: exception where the gap is a failed entity control test), source: compliance_review, severity: low..critical per the criteria above, description carrying the provision failed and the entity-side/vendor-side split, root_cause, identified_date, and the proposed issue_owner. Each Issue relates to the anchor Audit; relate it to the affected Vendor item(s) and, where the gap is a lapsed entity control, to the Control item that failed.\n- Attach the issued gap report (DOCX/PDF) as a step document; factual-accuracy corrections land as dated comments on the gap Issue items (severity is not negotiated in the accuracy pass).\n\nSet per-obligation compliant / gap-open / gap-remediating statuses with evidence links and assessment dates in the vendor obligation register, attached to this step as the updated register document (XLSX) — there is no native per-arrangement obligation-status field, so the register carries them and unassessed cells stay explicitly blank.\n- Attach the dated register-of-information corrections memo with workpaper citations; record the compliance-officer disposition on any resubmission question as a step note.\n- Route criticality changes from the inventory challenge to the Vendor items as suggested changes on Vendor.tier (a newly-critical arrangement's Art. 30(3) uplift is scheduled as a gap Issue); submit suggested changes for any other lifecycle-owned fields; record the reconciliation note confirming register rows touched equal the in-scope arrangements assessed.\n- Submit this step's form: `disposition_path` (SELECT: clean / remediate / escalate), the step result citing the specific gap Issue items and severities driving the pick, and the step's approver record for the deciding assurance lead. Note compliance-officer concurrence in the rationale for remediate and escalate.\n\n**Exit criteria**\nEvery governance element rated against a specific provision with evidence links; the register tested in both directions with quantified results; failures carry provision-level citations ready for the gap report. Every sampled arrangement has clause-level contract results and an assurance-evidence conclusion or a documented alternative-assurance plan; critical arrangements missing Art. 30(3) provisions are flagged as gaps; the SOC-review referral queue is explicit. Each sampled monitoring control carries an operating conclusion covering the full period; every lapse is bounded to arrangement and window; the incident reconciliation is documented with discrepancies dispositioned. Every fieldwork exception appears exactly once in the register with provision, severity, and rationale; the entity-side/vendor-side split is recorded; the report is issued to owners. Every in-scope arrangement's obligation status reflects the assessed state with an evidence link; register corrections are dated and sourced; upstream-owned corrections routed as suggested changes; any resubmission question dispositioned; form submitted with rationale and owner; unused branches are prunable because edge `whenValue`s match the selected value.","kind":"decision","label":"Classify disposition"},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert every open gap into exactly one owned, dated, verifiable action, with interim mitigation wherever the fix date is distant, so remediation is trackable by the attestation cycle rather than aspirational.\n\n**Inputs**\n- The gap register with severities and the entity-side/vendor-side split.\n- Vendor contract renewal dates — vendor-side fixes usually land at renewal.\n- The escalation thresholds and reporting expectations established for this cycle.\n\n**Procedure**\n1. Capture one owned action per gap on that gap's Issue item — or fold related gaps under one root-cause plan where a systemic cause (a pre-DORA contract template) spawned many findings. State the root cause honestly: \"template lacked Art. 30 clauses\" is fixable at the template; \"negotiator missed it\" is not the real cause when five contracts show the same hole.\n2. Assign the owner who actually controls the fix: the vendor relationship manager for contract amendments, control owners for unmapped CUECs, the register owner for data corrections, the monitoring owner for lapsed reviews. An action owned by someone who cannot execute it is a status-meeting fixture, not a plan.\n3. Set dates that respect vendor-side physics: contract amendments often wait for renewal — if renewal is nine months out, define interim mitigation now (enhanced monitoring cadence, a compensating internal control, exit-plan readiness raised) and record it on the action. Entity-side fixes get short windows: 30/60/90 days by severity is a workable default.\n4. Define validation evidence up front — the artifact that proves closure: an executed amendment containing the clause, the first quarter's SLA report with evidenced review, a passed test of the CUEC control. Closure without the named artifact reopens.\n5. Set the reporting cadence and escalation trigger: Critical and High actions report to the compliance officer at least monthly; a second missed date auto-escalates to the escalation path's authority.\n6. Keep every gap Issue related to its Vendor and Control records so the attestation cycle traces status without re-deriving context.\n\n**Record in AssureSwarm**\n- Record each remediation action on its gap Issue item: remediation_plan (the action, interim mitigation, validation evidence, reporting cadence, and escalation trigger), issue_owner (the person who actually controls the fix), and target_remediation_date (30/60/90 by severity for entity-side; renewal-driven for vendor-side). There is no separate Action type — remediation lives on the gap Issue.\n- Capture the systemic root-cause roll-up plan as a step document; ensure each gap Issue stays related to its affected Vendor and, where applicable, Control item.\n\n**Exit criteria** — Every open gap has exactly one owning action with owner, date, and defined validation evidence; distant-dated actions carry interim mitigation; cadence and escalation triggers recorded.","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 issue in front of the authority who can actually decide it, with a decision-grade memo, and capture the decision, its conditions, and follow-up ownership; any risk acceptance here is time-bound and never self-granted.\n\n**Inputs**\n- The escalated gap items with provisions, arrangements, and evidence.\n- The escalation thresholds and authority map established for this cycle (compliance officer, legal owner, risk or governance committee).\n- Vendor posture: amendment willingness, renewal dates, exit-plan state.\n\n**Procedure**\n1. Route by issue type: regulatory-position questions (register accuracy, notification duties) to the compliance officer; contract and enforcement exposure to the legal owner; accept-versus-exit on a critical provider to the risk or governance committee per the threshold map.\n2. Write the memo to decision grade: the issue and the provision failed; the affected arrangements and the functions behind them; quantified exposure — the functions that stop if the provider fails, the supervisory measures and remediation orders available to the authority, and for NIS2 essential entities the fine ceiling of at least €10 million or 2% of worldwide annual turnover (Art. 34); the options (remediate now / accept with conditions / exit the vendor) with cost and time for each; and a recommendation. A memo without options and a recommendation is a briefing, not an escalation.\n3. Apply risk-acceptance discipline: any acceptance names the accepting authority, is time-bound with an expiry and re-affirmation date, states its conditions (compensating monitoring, exit readiness), and is refused where no acceptance path exists — a register submission must be accurate; a filing inaccuracy cannot be \"accepted\", only corrected.\n4. Record the decision verbatim: who decided, what, when, under which conditions; every condition becomes a watchlist entry with an owner and expiry.\n5. If exit is chosen, execution belongs to the vendor lifecycle's termination and exit machinery — record the handoff and what this workflow retains (monitoring the transition against the exit plan).\n\n**Record in AssureSwarm**\n- Attach the escalation memo and the recorded decision (who decided, what, when, under which conditions) as step documents.\n- For a deliberate risk acceptance, use the exception pattern: set the accepted gap Issue to issue_type: policy_exception with exception_approver (the accepting compliance officer / governance authority) and exception_expiry_date (the time-bound expiry / re-affirmation date), related to the affected third_party Risk item; set treatment: accept (with residual_rating and risk_owner) on that Risk; and record the acceptance conditions in Issue.management_response. Refuse acceptance where no acceptance path exists (a materially inaccurate register submission is corrected, not accepted).\n- Each acceptance condition and expiry becomes a watchlist entry — there is no native Watchlist/Task type, so keep them in the decision record with an owner and expiry; link follow-up items with owners.\n- Record the exit handoff to the vendor lifecycle's termination/exit machinery if exit was chosen (this workflow retains monitoring the transition against the exit plan).\n\n**Exit criteria** — Decision recorded by the named authority with a date; every condition carries an owner and expiry; no acceptance recorded for non-acceptable obligations; follow-ups scheduled.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"description":"Hand the validated obligation statuses 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 cycle on that acknowledged receipt with a reconstructable audit trail — a future examiner can see what was assessed, what was concluded, by whom, on what evidence, without relying on anyone's memory.","instructions":"**Objective**\nHand the validated obligation statuses 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 cycle on that acknowledged receipt with a reconstructable audit trail — a future examiner can see what was assessed, what was concluded, by whom, on what evidence, without relying on anyone's memory.\n\n**Inputs**\nEverything the executed path produced: locked workplan, inventory reconciliation, governance assessment, contract and monitoring test matrices, gap register and report, action plan or escalation record, and all decision forms.\n- Coverage statistics: arrangements assessed versus in-scope, critical-arrangement coverage, monitoring period coverage.\n\nThe final package from the preceding procedure, and the full linked set: arrangements, gap items, actions, decision forms.\n- The open-item ledger: actions with owners and dates, acceptance conditions and expiries, unresolved constraints.\n- The owner roster for arrangements, the register, and the monitoring controls; the distribution list and escalation contacts established for this cycle.\n- The regulatory calendar: next register submission, next cycle date.\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: Compile the evidence, analysis, decisions, and open items into one internally consistent package with a qualified conclusion a reviewer can sign — and an examiner can reconstruct.\n\n2. Assemble the package in the order a reviewer reads it: scope and trigger, population and reconciliation, the three assessment workpapers, the gap register with dispositions, the action plan or escalation decision, and the decision-form trail with rationales.\n3. Run a traceability spot-check: pick two or three gaps and walk provision → test → evidence → conclusion → action; pick one clean conclusion and walk it back to evidence. Any break gets fixed before sign-off, because after archive it becomes an addendum.\n4. State coverage honestly: critical arrangements must show 100% coverage or a named, justified exception; sampled coverage of the remainder is stated as a percentage with the sampling basis.\n5. Write the conclusion with its qualifier — e.g. \"obligations under DORA Chapter V assessed as met for the in-scope population, except the N rated gaps in the register, remediation on plan\". Never an unqualified conclusion while open items exist, and never a conclusion broader than the population actually tested.\n6. Surface unresolved constraints as constraints — a vendor that refused evidence, a report unobtainable — in the conclusion section, not buried in a workpaper footnote.\n\n7. Assessment scope for Handoff to related workflow: Hand the validated obligation statuses 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 cycle on that acknowledged receipt with a reconstructable audit trail — a future examiner can see what was assessed, what was concluded, by whom, on what evidence, without relying on anyone's memory.\n\n8. Create or link the Regulatory Compliance Attestation Cycle for the covered regimes and pass the final package.\n9. Draw the consume-versus-verify line explicitly: the attestation cycle consumes the applicability decisions, the population reconciliation, the clause-level contract conclusions, and this cycle's severity ratings; it re-verifies operating evidence each cycle — monitoring reports received and reviewed, register currency, action-plan progress, acceptance conditions still honored. It does not redo contract-clause testing absent a contract change, and it does not re-litigate criticality absent a function change.\n10. Transfer the open-item ledger with owners and dates: every action and every acceptance condition becomes something the attestation cycle checks each cycle until closed or expired.\n11. Pass the assumptions the downstream owner must know: reliance conclusions and their bridge-letter windows, subservice carve-outs added as fourth parties, and intra-group inclusion decisions.\n12. Get 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 chain from provision to test to evidence to conclusion holds end to end. Fix gaps now — after archive they become dated addenda, not edits.\n14. Bring linked records to end-state: each arrangement shows its assessed status and date; register corrections are applied and sourced; gap items are closed-with-evidence or open-with-owner; the downstream handoff from item 8 is linked.\n15. Schedule what outlives this cycle as watchlist entries with owners, not calendar folklore: the next assurance cycle, the register-of-information submission date, action due dates, acceptance expiries, and exit-plan review dates.\n16. Communicate closure to the distribution list: the conclusion with its qualifier, the disposition, 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**\nAttach the rendered package as a step document (PDF); mirror the conclusion onto the anchor engagement item — Audit.rating (satisfactory / needs_improvement / unsatisfactory), Audit.opinion (qualified while open items exist), and Audit.report_date. The qualifier text and coverage statistics live in the package.\n- Capture the assurance lead's sign-off approval on this step.\n\nLink the downstream Regulatory Compliance Attestation Cycle workflow run to this instance, and attach the handoff note as a step document: package contents, the open-item ledger (traceable via the open gap Issue items with owners and dates), assumptions, and the do-not-repeat list.\n- Record the receiving owner's acknowledgment as an approval or comment on this step.\n- Archive the workflow instance as the cycle's audit trail; bring linked records to end-state — the anchor Audit's final status, and each gap Issue closed-with-evidence (actual_remediation_date / verified_date) or left open-with-owner.\n- Schedule every follow-up (next assurance cycle, register-of-information submission date, action due dates, acceptance expiries, exit-plan review dates) as a watchlist entry with an owner — there is no native Watchlist type, so record them in the closure note.\n- Attach the closure communication note and the archive confirmation to this step.\n\n**Exit criteria**\nPackage complete and internally consistent; traceability spot-checks passed; conclusion qualified to match open items and the tested population; sign-off captured. Downstream workflow linked; package, open-item ledger, 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-third-party-ict-vendor-assurance"}