{"description":"A standing quarterly cycle the vendor-management office runs as control owner. The workflow instance is a recurring run attached to the EXISTING Process item \"Third-Party / Vendor Risk Management\" (process_type: operational, process_owner: Vendor Risk Program Lead, frequency: quarterly), linked to the Control items for the unified controls it operates (UC-TPRM-01/04/05/08) — it enriches that standing program, never recreating it. It consumes no upstream workflow handoff: each run is self-feeding, drawing its criteria and prior state from the program's own standing artifacts — the SCRM plan, third-party risk policy, and program strategy held as Policy items; the criticality-tiered Vendor register (Vendor items); and the prior cycle instance's step documents (the DORA Article 28(3) register of information and the ICT concentration-risk view). In scope: reaffirming or revising the governing Policy items; re-tiering the Vendor register; refreshing the DORA Article 28(3) register of information and the concentration-risk view (a dashboard over the Vendor items); verifying critical-provider exit strategies; executing this cycle's tier-based reassessments and driving findings to tracked third-party Risk items (remediation or risk-committee escalation); confirming external and cloud service provider oversight; and verifying critical suppliers carry live incident-notification coverage. Named deliverables: the refreshed criticality-tiered Vendor register, the updated DORA Article 28(3) register of information, the recomputed ICT concentration-risk view, the exit-readiness summary, this cycle's tracked Risk items, and the archived cycle evidence package on the workflow instance. Terminal at close-and-archive with no downstream handoff — open or escalated vendor risks persist as Risk items in the risk register. Out of scope and handled by separate workflows: the continuous monitor-line vendor lifecycle and the per-engagement due-diligence gate for onboarding a new vendor.","edges":[{"id":"e-review-scrm-policy-and-strategy-apply-policy-revisions-and-reapprove","label":"Revise and re-approve","source":"review-scrm-policy-and-strategy","target":"apply-policy-revisions-and-reapprove","whenValue":"revise_and_reapprove"},{"id":"e-review-scrm-policy-and-strategy-verify-critical-provider-exit-strategies","label":"Reaffirm, no change","source":"review-scrm-policy-and-strategy","target":"verify-critical-provider-exit-strategies","whenValue":"reaffirm_no_change"},{"id":"e-apply-policy-revisions-and-reapprove-verify-critical-provider-exit-strategies","source":"apply-policy-revisions-and-reapprove","target":"verify-critical-provider-exit-strategies"},{"id":"e-verify-critical-provider-exit-strategies-track-service-changes-and-vendor-risks","source":"verify-critical-provider-exit-strategies","target":"track-service-changes-and-vendor-risks"},{"id":"e-verify-critical-provider-exit-strategies-close-and-archive","source":"verify-critical-provider-exit-strategies","target":"close-and-archive"},{"id":"e-track-service-changes-and-vendor-risks-escalate-unresolved-risks-to-committee","label":"Escalate to risk committee","source":"track-service-changes-and-vendor-risks","target":"escalate-unresolved-risks-to-committee","whenValue":"escalated_to_risk_committee"},{"id":"e-track-service-changes-and-vendor-risks-close-and-archive","label":"Closed within cycle","source":"track-service-changes-and-vendor-risks","target":"close-and-archive","whenValue":"closed_within_cycle"},{"id":"e-escalate-unresolved-risks-to-committee-close-and-archive","source":"escalate-unresolved-risks-to-committee","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-TPRM-01","UC-TPRM-04","UC-TPRM-08","UC-TPRM-05"],"department":"procurement","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-third-party-risk-program-vendor-oversight-cycle","contentDigest":"sha256:a897ce21c38e200ae7741ba040630159a3e639a9f926f61653e2dc07ba3c28f6","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:a897ce21c38e200ae7741ba040630159a3e639a9f926f61653e2dc07ba3c28f6","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-third-party-risk-program-vendor-oversight-cycle"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-third-party-risk-program-vendor-oversight-cycle","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2","iso-27001","cobit-2019","dora"],"teams":["procurement","executive"]},"name":"Third-Party Risk Program & Vendor Oversight Cycle","nodes":[{"data":{"decisionField":"policy_review_decision","description":"Agent compiles the governing SCRM plan, policy, and strategy against the change log since last review; human program lead decides whether they are reaffirmed as-is or must be revised and re-approved this cycle","formData":{"fields":[{"key":"policy_review_decision","label":"SCRM plan, policy, and strategy review decision","options":[{"label":"Reaffirm policy and strategy without changes","value":"reaffirm_no_change"},{"label":"Revise policy or strategy and re-approve","value":"revise_and_reapprove"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether the program's governing supply-chain risk management (SCRM) plan, third-party risk policy, and strategy remain accurate for this cycle or must be revised and re-approved; the Vendor Risk Program Lead owns the call.\n\n**Decision criteria**\n- Select **reaffirm_no_change** (Reaffirm policy and strategy without changes) when: the SCRM plan, third-party risk policy, and strategy have been reviewed within the required periodic interval; no logged significant change (regulatory update, supply-chain disruption, new threat intelligence, or material shift in the organization's structure or critical services) invalidates them; and the documented cybersecurity roles and responsibilities for suppliers, customers, and partners are still current for internal and external stakeholders.\n- Select **revise_and_reapprove** (Revise policy or strategy and re-approve) when any governing document is past its periodic review interval, a logged significant change materially affects it, or the documented supplier/customer/partner roles and responsibilities no longer match the organization (UC-TPRM-01). Note this is also the expected pick on the annual re-approval cadence.\n\nAgent procedure feeding the decision: (1) Retrieve the current SCRM plan, third-party risk policy, and program strategy — each held as a Policy item (policy_type: policy / standard / charter, policy_owner, version, review_frequency, next_review_date) with its governing document attached, cross-checked against the current copies carried on the prior cycle instance's close-and-archive step — and compile the change log since last review (regulatory updates, disruptions, threat intel, structural/critical-service shifts). (2) Confirm the documented roles and responsibilities for suppliers, customers, and partners are still current. (3) Check each document against its required periodic review interval and flag any that is due or triggered by a logged significant change. (4) Draft a review packet with a per-document recommendation (reaffirm vs revise which sections) and supporting rationale.\n\n**Record in AssureSwarm** — Submit the `policy_review_decision` SELECT field. In the step result, state the reasoning with evidence references (which Policy item, which review interval or logged change, which section). Name the approver in the step's approver record. On reaffirm, stamp each governing Policy item's `next_review_date` and confirm its `policy_owner` and `version` (coach-item-update). Attach the review packet as a document on this step (coach-document-upload).\n\n**Exit criteria** — The form is submitted with a rationale and named owner; the unused branch is prunable. On reaffirm, the reviewed governing documents are the confirmed criteria basis for the inventory refresh; on revise, the apply-and-re-approve step is released.","kind":"decision","label":"Review SCRM plan, policy, and strategy","performedBy":{"primitives":["coach-document-upload","coach-query-data","coach-item-update"]}},"id":"review-scrm-policy-and-strategy"},{"data":{"description":"Agent applies the approved revisions to the SCRM plan, policy, and strategy and routes them for re-approval; human program lead confirms the revised documents are approved and published","instructions":"**Objective** — Turn the program lead's revise decision into version-controlled, re-approved, and published SCRM plan, policy, and strategy documents so the rest of the cycle runs against current criteria.\n\n**Inputs**\n- The `revise_and_reapprove` decision, review packet, and per-section change recommendations from the SCRM review step.\n- The current SCRM plan, third-party risk policy, program strategy, and the documented supplier/customer/partner roles and responsibilities.\n- The governing documents as Policy items (`version`, `approved_by`, `effective_date`, `next_review_date`, `review_frequency`, `policy_owner`) and the program's version-control and approval conventions.\n\n**Procedure**\n1. Translate each requested change into a specific edit to the SCRM plan, third-party risk policy, program strategy, or the documented supplier, customer, and partner roles and responsibilities. Keep edits traceable to the review packet line that motivated them.\n2. Apply the edits and produce a version-controlled change log recording what changed, why, and against which prior version (UC-TPRM-01). Bump the document version and effective date.\n3. Route the revised documents to the accountable approver for formal re-approval; capture the approval record (approver, date, decision) as evidence.\n4. Publish the re-approved documents to the program document register and notify affected first-line vendor owners and second-line governance stakeholders that new criteria are in force.\n\n**Record in AssureSwarm** — Update each revised governing document's Policy item — bump `version`, set `approved_by`, `effective_date`, and `next_review_date`, and confirm `review_frequency` and `policy_owner` (coach-item-update) — and attach the re-approved document and its version-controlled change log to that Policy item, registering the approval record (coach-document-upload). Record publication, version and effective date in the native result, retaining the actual approval record.\n\n**Exit criteria** — Revised SCRM plan, policy, and strategy are approved by the named approver, correctly versioned with a change log, and published to the document register; affected stakeholders are notified. These re-approved documents are the confirmed criteria basis for the vendor inventory refresh.","label":"Apply policy revisions and re-approve","performedBy":{"primitives":["coach-document-upload","coach-form-fill","coach-item-update"]}},"id":"apply-policy-revisions-and-reapprove"},{"data":{"description":"Confirm every provider of a critical or important function has a documented, current, and tested exit strategy, and surface any exit-readiness gap as a candidate vendor risk before reassessment results are dispositioned.","instructions":"**Objective**\nConfirm every provider of a critical or important function has a documented, current, and tested exit strategy, and surface any exit-readiness gap as a candidate vendor risk before reassessment results are dispositioned.\n\n**Inputs**\nThe confirmed governing criteria: the reaffirmed or (if revised) re-approved SCRM plan and third-party risk policy Policy items, which define the criticality-scoring criteria and tier-to-requirement mapping.\n- The current Vendor register (Vendor items) and the vendor onboarding, offboarding, and ownership-change records since the last cycle.\n- Prior-cycle `tier`s and the risk-based `reassessment_cadence` schedule carried on the Vendor items.\n\nThe refreshed Vendor register (Vendor items) and their criticality `tier`s.\n- Active contractual arrangements with ICT third-party service providers and their contract terms.\n- The prior register of information and concentration-risk view documents carried on the prior cycle instance's update step.\n\nThe updated concentration-risk view (dashboard) and register-of-information document from the preceding procedure, plus the Vendor items' `tier`, which together identify the providers supporting critical or important functions.\n- Documented exit/transition/substitution strategies per provider and their test histories.\n- The program's required exit-strategy test cadence.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Refresh vendor inventory and criticality tiers”, “Update DORA contract register and concentration view”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Refresh vendor inventory and criticality tiers: Produce a complete, current, criticality-tiered third-party inventory with each vendor mapped to its risk-based due-diligence and reassessment requirements, so this cycle's register, reassessment, and oversight scope all draw from one authoritative list.\n\n2. Pull the current third-party inventory and reconcile it against onboarding, offboarding, and ownership records since the last cycle so every active relationship appears exactly once and no retired vendor lingers.\n3. Re-score each vendor's criticality against the program's defined criteria — data sensitivity, service dependency, substitutability, and financial or operational exposure — and assign or confirm its tier (UC-TPRM-01). Record the score inputs so the tier is defensible.\n4. Cross-check that the risk-based requirements for due diligence, contractual security provisions, and periodic reassessment frequency are correctly mapped to each tier; flag every vendor whose tier changed since the last cycle and note the driver of the change.\n5. Publish the refreshed, tier-ranked inventory as the authoritative scope for this cycle's register update, tiered reassessments, and oversight steps.\n\n6. Assessment scope for Update DORA contract register and concentration view: Bring the DORA Article 28(3) register of information current for every in-scope ICT contract and recompute the ICT concentration-risk view, so exit-strategy verification and supplier incident-notification checks run against an accurate contract-and-concentration picture.\n\n7. Update the register of information covering all contractual arrangements with ICT third-party service providers, capturing the mandatory provisions for each active contract — security requirements, audit and access rights, termination rights, and sub-outsourcing conditions (UC-TPRM-01).\n8. Recompute the ICT concentration-risk view across the refreshed inventory: identify single points of failure, shared sub-processors, and clusters of critical or important functions concentrated in one provider or one region.\n9. Reconcile the register against the criticality tiers so every provider supporting a critical or important function is correctly flagged in both the register and the concentration view.\n10. Compile the concentration-risk findings and any register gaps (missing contracts, missing mandatory provisions) into a summary, marking material concentrations for potential escalation.\n\n11. Assessment scope for Verify critical-provider exit strategies: Confirm every provider of a critical or important function has a documented, current, and tested exit strategy, and surface any exit-readiness gap as a candidate vendor risk before reassessment results are dispositioned.\n\n12. For every provider supporting a critical or important function identified in the concentration-risk view, retrieve the documented exit strategy and confirm it names a concrete transition or substitution plan with an owner (UC-TPRM-01).\n13. Check each exit strategy's test history against the required test cadence; flag any provider whose exit strategy is undocumented, untested, or overdue for testing.\n14. Reassess, using the latest concentration-risk findings, whether any additional provider should now be treated as critical for exit-strategy purposes (e.g., newly concentrated function or region) and pull it into scope.\n15. Compile the exit-readiness summary, listing providers with current, tested exit strategies separately from those with gaps, and characterize each gap's severity.\n\n**Record in AssureSwarm**\nCreate or update each Vendor item with its refreshed classification — `category`, `tier` (criticality), `data_classification`, `business_owner`, `risk_owner`, `reassessment_cadence`, `next_reassessment_date`, `monitoring_status` — carrying the criticality score inputs and the tier-to-requirement (due-diligence / contract / reassessment-frequency) mapping in its `description` (coach-item-create, coach-item-update); flag every Vendor whose `tier` changed this cycle and note the driver in its `description`.\n\nMaintain the DORA Article 28(3) register of information as an XLSX document on this step — there is no Contract / register item type, so the register document is the record of the mandatory provisions per contract (coach-document-upload); stamp each in-scope Vendor item's `contract_end_date` and confirm its `tier` marks providers of critical or important functions, creating a Vendor item for any provider surfaced by the register but absent from the inventory (coach-item-create, coach-item-update). Build or refresh the ICT concentration-risk view as a dashboard over the Vendor items (coach-dashboard-create), and attach the register-gap / findings summary as a document on this step.\n\nIdentify the critical-or-important-function providers by querying the Vendor items where `tier` is high or critical (coach-query-data); Vendor items carry no native exit-strategy field, so record each provider's exit-strategy status (documented / tested / overdue, with gap severity) in the exit-readiness summary and upload it — together with the exit-strategy documents and test evidence — as documents on this step (coach-document-upload).\n\n**Exit criteria**\nThe inventory is complete and reconciled; every vendor carries a justified criticality tier; tier changes are flagged with a driver; and the tier-to-requirement (due-diligence / contract / reassessment-frequency) mapping is confirmed. This tiered inventory and its reassessment schedule are the basis downstream steps consume. The register of information is complete and current for all in-scope contracts with mandatory provisions captured; the concentration-risk view is recomputed and reconciled to tiers; material concentrations and register gaps are documented. The register and concentration view are the inputs the exit-strategy and supplier incident-notification steps read. Exit-strategy status is confirmed accurate for every critical/important provider; providers with undocumented, untested, or overdue strategies are flagged with severity. This exit-readiness summary and its flagged gaps feed both the vendor-risk disposition and the external/cloud oversight step.","label":"Verify critical-provider exit strategies","performedBy":{"note":"","primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-item-update","coach-dashboard-create"]}},"id":"verify-critical-provider-exit-strategies"},{"data":{"decisionField":"vendor_risk_disposition","description":"Agent runs the questionnaires, assurance-report collection, and audit requests due this cycle by vendor tier and records and prioritizes every risk they surface; human program lead decides whether the cycle's risks close within the standard remediation track or must escalate to the risk committee","formData":{"fields":[{"key":"vendor_risk_disposition","label":"Cycle vendor risk disposition","options":[{"label":"All identified risks closed or on-plan within cycle","value":"closed_within_cycle"},{"label":"Material risks escalated to risk committee","value":"escalated_to_risk_committee"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Complete every vendor reassessment due this cycle at the depth its tier requires, record and prioritize every risk it surfaces, and resolve whether the cycle's vendor risks close within the standard remediation track or whether material risks must be escalated to the risk committee; the Vendor Risk Program Lead owns the call.\n\n**Inputs**\n- The refreshed Vendor register (Vendor items) and each vendor's `reassessment_cadence` / `next_reassessment_date` (which vendors are due, at what depth).\n- Each vendor's contacts and prior assurance artifacts (SOC 2 / ISO 27001 certificates, prior questionnaires).\n- The program's risk-scoring criteria for reassessment results.\n- The exit-readiness gaps carried in from the critical-provider exit-strategy verification.\n\n**Procedure**\n_Items 1–8 are agent-run (items 1–4 folded from the former \"Execute tiered reassessments due this cycle\" step); the human moment is the disposition call in item 9._\n1. From the tier-based schedule, determine which vendors are due reassessment this cycle and generate the tier-appropriate package for each — an assurance-report request (e.g., SOC 2 or ISO 27001 certificate), targeted questions for genuinely missing vendor-held facts, or an on-site/remote audit request (UC-TPRM-04). Use existing artifacts first; any questionnaire names the external vendor contact, asks only missing facts and excludes executor assessments and known report/identity metadata.\n2. Distribute the questionnaires and evidence requests to vendor contacts and track responses against the cycle deadline, escalating non-responders as the deadline approaches.\n3. Collect and log returned questionnaires, assurance reports, and audit results against each vendor record; reconcile any reported supplier service changes — new sub-processors, scope changes, service-level changes — into the vendor record.\n4. Score each completed reassessment against the program's risk criteria and flag any vendor whose posture, reported service change, or missing/late response indicates elevated risk. Every vendor due this cycle must end with a completed, scored reassessment or a logged non-response.\n5. Record every risk surfaced this cycle — reassessment findings, flagged service changes, and exit-strategy gaps — as a tracked vendor risk item, prioritized by vendor criticality tier and finding severity.\n6. Assign each item an owner and a remediation plan with a target date, and link it to the responsible vendor record and the reassessment or exit-readiness evidence that raised it.\n7. Roll up open and newly closed items into a cycle risk summary, separating standard-track risks from material/overdue/repeat risks.\n8. Draft the escalation recommendation and rationale for any risk exceeding standard remediation tolerance.\n9. Confirm reassessment coverage is complete for the cycle and select the disposition below.\n\n**Decision criteria**\n- Select **closed_within_cycle** (All identified risks closed or on-plan within cycle) when every recorded vendor risk — reassessment findings, flagged service changes, and exit-strategy gaps — is either remediated or on an accepted remediation plan with an owner and target date within the program's standard tolerance, and none is material, overdue, or a repeat finding needing committee visibility.\n- Select **escalated_to_risk_committee** (Material risks escalated to risk committee) when one or more risks are material, overdue against their plan, or repeat findings that exceed the program's standard remediation tolerance and require second-line committee-level visibility or a contract/relationship decision (UC-TPRM-04).\n\n**Record in AssureSwarm**\n- Issue only the necessary missing-fact questions to each named vendor contact as form assignments, and attach each vendor's returned questionnaire, assurance report (SOC 2 / ISO 27001), and audit result to its Vendor item, stamping `last_assessment_date` (this cycle) and `next_reassessment_date` (from its `reassessment_cadence`) (coach-form-create, coach-item-document-attach, coach-item-update).\n- Capture the scored-results summary and elevated-risk flags as a document on this step, which has no native per-score Vendor field (coach-document-upload).\n- Record every surfaced risk as a Risk item — `category: third_party`, `taxonomies: third_party_risk`, `domains: third_party_supply_chain_risk`, `risk_owner`, `likelihood`/`impact`/`inherent_rating`, `treatment` — with the responsible vendor named in its `description` (no per-Risk Vendor field exists) (coach-item-create); link each Risk to the UC-TPRM Control items it informs, to the anchor Process item, and to the reassessment or exit-readiness evidence that raised it (coach-items-link).\n- Submit the `vendor_risk_disposition` SELECT field. In the step result, record the reasoning with evidence references (which Risk items, severity, tier, overdue/repeat status). Name the approver in the step's approver record.\n\n**Exit criteria** — Every vendor due this cycle by tier has a completed, scored reassessment or a logged non-response and reported service changes are recorded; every surfaced risk is a tracked item with an owner and target date; the form is submitted with rationale and named owner and the unused branch is prunable. On escalate, the committee package step is released; on closed-within-cycle, the risk record drains to close-and-archive.","kind":"decision","label":"Track vendor risks to remediation","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-form-create","coach-document-upload","coach-item-update"]}},"id":"track-service-changes-and-vendor-risks"},{"data":{"description":"Agent packages the material vendor risks for risk-committee review and tracks the committee's direction; human program lead confirms the escalation package is complete","instructions":"**Objective** — Get every material, overdue, or repeat vendor risk in front of the risk committee, capture the committee's direction against each risk, and confirm the revised remediation plans are owned before the cycle closes.\n\n**Inputs**\n- The `escalated_to_risk_committee` disposition and the tracked vendor risk items flagged for escalation, with evidence, prior remediation attempts, and vendor criticality tier.\n- The risk committee (or equivalent second-line governance forum) roster and meeting cadence.\n- The vendor-relationship owners for each escalated vendor.\n\n**Procedure**\n1. Package each flagged risk item into a risk-committee briefing with its evidence, prior remediation attempts, severity, and vendor criticality tier (UC-TPRM-04). Group by vendor and by proposed action.\n2. Route the briefing to the risk committee and capture the committee's direction per risk — accept the risk, mandate a revised remediation plan, or require contract or relationship action (e.g., renegotiation, substitution, exit).\n3. Update each escalated risk item with the committee's decision, the assigned owner, and a revised target date.\n4. Notify the affected vendor-relationship owners of the committee's direction and the revised remediation expectations.\n\n**Record in AssureSwarm** — Upload the committee briefing and minutes as documents on this step (coach-document-upload) and link them to each escalated Risk item (coach-items-link); update each escalated Risk item per the committee's direction — `treatment` (accept | mitigate | avoid), `residual_rating`, `risk_owner` — recording the revised target date in its `description`, and set `treatment: accept` on any risk the committee formally accepts (coach-item-update).\n\n**Exit criteria** — The escalation package reached the committee; the committee's direction is recorded against every escalated risk item with an owner and revised target date; and affected vendor owners are notified. The escalated risk record then drains to close-and-archive.","label":"Escalate unresolved risks to committee","performedBy":{"primitives":["coach-items-link","coach-document-upload","coach-item-update"]}},"id":"escalate-unresolved-risks-to-committee"},{"data":{"description":"Assemble a self-contained, durable evidence record of the full oversight cycle and update the program's linked records, so an auditor or regulator can trace the cycle end-to-end without oral explanation and the next quarterly cycle starts from a confirmed state.","instructions":"**Objective**\nAssemble a self-contained, durable evidence record of the full oversight cycle and update the program's linked records, so an auditor or regulator can trace the cycle end-to-end without oral explanation and the next quarterly cycle starts from a confirmed state.\n\n**Inputs**\nThe register of external system services and cloud services in use, and the organization's information security requirements for acquiring, using, managing, and exiting those services.\n- The refreshed vendor inventory criticality tiers.\n- The confirmed exit-readiness summary for providers of critical or important functions.\n\nThe updated DORA register-of-information document (the contract source for notification provisions) and the refreshed Vendor items' criticality `tier`s.\n- The organization's incident-response plans, incident contact trees, and the next scheduled incident-response exercise or tabletop roster.\n- Each critical/important supplier's contract.\n\nEvery upstream deliverable: the reaffirmed or revised SCRM plan/policy/strategy; the refreshed criticality-ranked vendor inventory; the updated DORA register of information and concentration-risk view; the exit-readiness summary; this cycle's scored reassessment results and reported supplier service changes; the vendor risk tracking record and any risk-committee escalations; the external and cloud service oversight review; and the supplier incident-notification verification.\n- The program's evidence-retention location and the program register.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Govern external and cloud service oversight”, “Verify supplier incident-notification readiness”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Govern external and cloud service oversight: Confirm every external system service and cloud service in use complies with the organization's security requirements, carries named current oversight roles, and holds documented service and exit terms consistent with verified critical-provider exit readiness.\n\n2. Retrieve the register of external and cloud services in use and check each provider's compliance with the organization's information security requirements for acquiring, using, managing, and exiting those services (UC-TPRM-08).\n3. Confirm the oversight roles and responsibilities defined on both the organization's side and each provider's side are named, current, and consistent with the vendor inventory's criticality tiers.\n4. Verify the agreed service terms and exit terms for each external or cloud service are documented and consistent with the confirmed exit-strategy status for providers of critical functions; reconcile any discrepancy against the exit-readiness summary.\n5. Flag any external or cloud service with an undefined oversight role, a stale service or exit term, or an unresolved security-requirement compliance gap, and route each flag to a vendor risk owner for resolution.\n\n6. Assessment scope for Verify supplier incident-notification readiness: Confirm every critical or important supplier is contractually bound to notify the organization of security incidents within a defined timeframe and is represented in the organization's incident-response planning, so a supplier-side compromise is detected and actioned in time.\n\n7. For each critical or important supplier, check the contract for a live, defined provision requiring the supplier to notify the organization of security incidents and supply-chain compromises within a specified timeframe, cross-referenced against the DORA register of information (UC-TPRM-05).\n8. Confirm each such supplier is represented in the organization's incident-response plans, incident contact trees, and the next scheduled incident-response exercise or tabletop roster.\n9. Reconcile the supplier incident-notification list against this cycle's refreshed criticality tiers — add newly critical vendors, remove offboarded or downgraded ones.\n10. Flag any critical supplier missing a notification provision, absent from the incident-response plan or contact tree, or missing from the exercise roster, and assign an owner to each gap.\n\n11. Assessment scope for Close and archive: Assemble a self-contained, durable evidence record of the full oversight cycle and update the program's linked records, so an auditor or regulator can trace the cycle end-to-end without oral explanation and the next quarterly cycle starts from a confirmed state.\n\n12. Assemble the complete cycle record from all upstream deliverables above, checking each is attached, versioned, and internally consistent (e.g., tiers referenced across register, reassessment, oversight, and incident-notification all match the refreshed inventory).\n13. Archive the evidence package to the program's retention location with the cycle date, tier scope, and version, and link it to the program register for auditor and regulator traceability.\n14. Update linked records so downstream work reflects this cycle's confirmed state — vendor profiles, the contract register, the risk register, and the incident-response plan and contact tree.\n15. Communicate the cycle's close, any escalated risks still open with their owners and target dates, and the next quarterly cycle date to program stakeholders.\n\n**Record in AssureSwarm**\nQuery the external and cloud service providers as Vendor items (`category`: cloud_infrastructure / saas_software / managed_services) and confirm `monitoring_status` and `risk_owner` for named oversight (coach-query-data, coach-item-update); record each provider's compliance status and service/exit terms in the oversight summary document on this step, which has no native Vendor compliance field (coach-document-upload). Raise every unresolved compliance, oversight-role, or stale-term gap as a Risk item (`category: third_party`) and link it to its Vendor item and the anchor Process item (coach-item-create, coach-items-link).\n\nQuery the DORA register-of-information document and the critical/important-function Vendor items (`tier` high or critical) to confirm notification coverage (coach-query-data); record the provision-coverage and IR-representation verification as a document on this step (no native Vendor notification field) and link each critical supplier's Vendor item to that verification (coach-items-link). Raise every gap — missing notification provision, or absent from the IR plan / contact tree / exercise roster — as a Risk item (`category: third_party`) with an assigned `risk_owner`, linked to its Vendor item (coach-item-create).\n\nExport the assembled cycle record as the workflow instance's archived evidence bundle and store it to the retention location (coach-workflow-export); link the archived package to the anchor Process item and to this cycle's updated records — the governing Policy items, the refreshed Vendor register, the DORA register-of-information document, and the tracked Risk items (coach-document-link). The workflow instance itself, attached to the standing TPRM Process item, is the cycle's audit trail.\n\n**Exit criteria**\nExternal and cloud provider compliance, oversight roles, and service/exit terms are confirmed current; every flagged gap has an assigned owner. This oversight review drains to close-and-archive. Every critical/important supplier has a live incident-notification provision and current representation in incident-response plans, contact trees, and the exercise roster; every gap has an assigned owner. This verification drains to close-and-archive. The archived record is self-contained and durable enough to serve as evidence to auditors and regulators without oral explanation; linked records are updated; open escalations and the next cycle date are communicated; closure is recorded under the program lead’s external/cloud oversight and supplier incident-readiness approval.","label":"Close and archive","performedBy":{"note":"","primitives":["coach-workflow-export","coach-document-upload","coach-query-data","coach-items-link","coach-item-update","coach-item-create"]}},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:grc-third-party-risk-program-vendor-oversight-cycle"}