{"description":"Vendor Offboarding & Secure Termination as a decision-aware workflow triggered on a relationship termination. It runs on the vendor's existing Vendor register item - the offboarding enriches that record, it never creates a duplicate: the run marks the Vendor `monitoring_status: exited` and stamps `contract_end_date`, and where the vendor's risk is registered it links to the existing third-party Risk item (`category: third_party`). In scope: executing one vendor's contractual exit end to end - inventorying the vendor's access, data, and dedicated components; containing access immediately on for-cause exits; transitioning each service to its successor; revoking every credential; verifying data return or destruction; disposing of internal-side components using defined techniques; and retaining the post-relationship evidence. Out of scope: the underlying contract-termination or renewal business decision and any separately-governed affiliate contracts. Initial inputs are the termination trigger and effective date, the vendor's contractual exit provisions (master agreement, data processing addendum, exit plan) - which also carry the data-disposition and evidence-retention clauses consumed downstream - and the existing Vendor register item with its risk tier; there is no upstream workflow. The named deliverable is the retained, audit-standing termination evidence package assembled at compile-termination-evidence-and-retain; the workflow is terminal - close-and-archive exports the run and hands off nothing downstream.","edges":[{"id":"e-classify-termination-urgency-emergency-access-lockout","label":"Expedited, for cause","source":"classify-termination-urgency","target":"emergency-access-lockout","whenValue":"expedited_for_cause"},{"id":"e-inventory-access-and-data-footprint-emergency-access-lockout","source":"inventory-access-and-data-footprint","target":"emergency-access-lockout"},{"id":"e-classify-termination-urgency-plan-and-execute-service-transition","label":"Standard, orderly","source":"classify-termination-urgency","target":"plan-and-execute-service-transition","whenValue":"standard_orderly"},{"id":"e-emergency-access-lockout-plan-and-execute-service-transition","source":"emergency-access-lockout","target":"plan-and-execute-service-transition"},{"id":"e-inventory-access-and-data-footprint-plan-and-execute-service-transition","source":"inventory-access-and-data-footprint","target":"plan-and-execute-service-transition"},{"id":"e-plan-and-execute-service-transition-execute-data-return-or-destruction","source":"plan-and-execute-service-transition","target":"execute-data-return-or-destruction"},{"id":"e-inventory-access-and-data-footprint-execute-data-return-or-destruction","source":"inventory-access-and-data-footprint","target":"execute-data-return-or-destruction"},{"id":"e-execute-data-return-or-destruction-verify-data-disposition","source":"execute-data-return-or-destruction","target":"verify-data-disposition"},{"id":"e-verify-data-disposition-dispose-internal-components-and-tools","label":"Accepted","source":"verify-data-disposition","target":"dispose-internal-components-and-tools","whenValue":"accepted"},{"id":"e-verify-data-disposition-remediate-data-disposition-gap","label":"Remediate","source":"verify-data-disposition","target":"remediate-data-disposition-gap","whenValue":"remediation_required"},{"id":"e-remediate-data-disposition-gap-dispose-internal-components-and-tools","source":"remediate-data-disposition-gap","target":"dispose-internal-components-and-tools"},{"id":"e-plan-and-execute-service-transition-dispose-internal-components-and-tools","source":"plan-and-execute-service-transition","target":"dispose-internal-components-and-tools"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-TPRM-06"],"department":"procurement","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-vendor-offboarding-secure-termination","contentDigest":"sha256:68ba255991c944b50697cf043f9bc7fbde7ecf065f42ccb12f684c5a448b351c","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:68ba255991c944b50697cf043f9bc7fbde7ecf065f42ccb12f684c5a448b351c","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-vendor-offboarding-secure-termination"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-vendor-offboarding-secure-termination","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2"],"teams":["procurement","it"]},"name":"Vendor Offboarding & Secure Termination","nodes":[{"data":{"description":"Agent compiles the complete inventory of vendor access, credentials, data holdings, and embedded tooling; human verifies nothing is missing","instructions":"**Objective** — Produce the single authoritative inventory of everything the vendor can touch - logical and physical access, credentials, the organizational data it holds or processes, and the components dedicated to the relationship - so every downstream revocation, data-disposition, and disposal step works from one complete, reviewed list.\n\n**Inputs**\n- The existing Vendor register item (the anchor): its `tier`, `data_classification`, `business_owner`, `risk_owner`, and `contract_end_date` scope the exit, and its `tier` feeds the urgency decision. Enrich this item - never create a duplicate.\n- The termination trigger and effective date (initial workflow input): why this exit is running now - contract expiration or non-renewal, a for-cause termination (security incident or material breach), or a business decision to exit. Uploaded as the trigger notice / decision memo on this step (PBC/external).\n- The vendor's contractual exit provisions (initial workflow input, uploaded on this step): master agreement, data processing addendum, and any supply-chain or exit plan. Extract the obligations this workflow must execute - data-return or destruction terms, access-revocation timing, transition-assistance terms, and evidence-retention requirements (including the post-relationship retention schedule) - and the in-scope boundary (which legal entities, contracts, subprocessors and subcontractors, and data flows are covered). These clauses are the auditable criteria this workflow operationalizes for control UC-TPRM-06 (third-party termination) under NIST 800-53 and NIST CSF 2.0.\n- Identity and access systems, VPN and remote-access logs, the physical badge system, API gateways, the data map, and the asset and license register (external systems queried; extracts land in the inventory document below).\n\n**Procedure**\n1. Confirm scope from the contract before querying: list the in-scope entities, contracts, subprocessors, and data flows. Anything outside that boundary (for example a separately-governed affiliate contract) is explicitly out of scope and noted.\n2. Access inventory: query every IAM system, directory, VPN and remote-access log, physical badge system, and API gateway to enumerate the vendor's logical accounts, service accounts, API keys, certificates, OAuth grants, and physical or site credentials. Capture owner, system, entitlement level, and last-used date for each.\n3. Data inventory: from the data map and contract records, enumerate the organizational data the vendor holds or processes - data category, sensitivity classification, system, format, and physical or geographic location - and tag each entry against its contractual disposition obligation (return, destroy, or both).\n4. Component inventory: enumerate vendor-supplied or vendor-dedicated components in scope for later disposal - dedicated hardware, software licenses, test and staging environments, integration endpoints and configurations, and relationship-specific documentation.\n5. Reconcile all three inventories against the vendor's own asset and access attestation where one exists, and against business-unit knowledge of shadow or informally-granted access; flag every discrepancy for confirmation.\n\n**Record in AssureSwarm**\n- Anchor the run on the existing **Vendor** register item: enrich it (coach-item-update) - set `monitoring_status: exited` and `contract_end_date` to the effective termination date. If the vendor is not yet in the register, create the Vendor item (coach-item-create); do not create a duplicate.\n- Attach the consolidated access, data, and component inventory - each entry carrying owner, system, entitlement level, and (for data) the contractual disposition tag - as a step document, XLSX (coach-document-upload). There is no native Asset/Credential item type, so the inventory lives as this document rather than per-entry items.\n\n**Exit criteria** — All three inventories are complete and current; each entry has an owner and (for data) a contractual disposition tag; discrepancies against the vendor attestation and known shadow access are flagged and confirmed by the Vendor Relationship Manager and system owners.","label":"Inventory access and data footprint","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-item-update"]}},"id":"inventory-access-and-data-footprint"},{"data":{"decisionField":"termination_urgency","description":"Agent assembles the risk context for the termination and drafts a routing recommendation; human classifies the termination as standard or expedited","formData":{"fields":[{"key":"termination_urgency","label":"Termination urgency","options":[{"label":"Standard, orderly termination","value":"standard_orderly"},{"label":"Expedited, for-cause termination","value":"expedited_for_cause"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide, and have the accountable owner ratify, whether this termination can proceed through normal transition-then-revoke sequencing or whether the vendor's access is dangerous enough to contain immediately. Owned by the Vendor Relationship Manager together with the security lead.\n\n**Decision criteria**\n- **standard_orderly** (Standard, orderly termination): the exit is an ordinary contract expiration, non-renewal, or business decision; there is no active security incident, breach, investigation, or contractual dispute; the vendor is cooperative; and the vendor's remaining, lower-risk access can safely stay in place while the successor transition is planned.\n- **expedited_for_cause** (Expedited, for-cause termination): the trigger is a security incident, material breach, evidence of non-cooperation or data misuse, or any active indicator of compromise or dispute that makes continued access a live risk. The sensitivity of the data and systems the vendor can reach and the Vendor item's `tier` and `data_classification` push the pick toward expedited; when in doubt at a high or critical `tier`, choose expedited.\n\nAgent preparation before the human picks: assess the trigger circumstances against the Vendor item's `tier` and the sensitivity of reachable systems and data; check for active indicators of compromise, open investigations, or contractual disputes; and draft a routing recommendation with the supporting risk context for the decision owner.\n\n**Record in AssureSwarm** — Submit the `termination_urgency` SELECT (standard_orderly or expedited_for_cause). Record the rationale and evidence references in the rationale field and name the decision owner or approver (coach-document-upload for the supporting risk context).\n\n**Exit criteria** — The form is submitted with a rationale citing the specific risk evidence; the decision owner is named; and the unselected branch is prunable.","kind":"decision","label":"Classify termination urgency","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"classify-termination-urgency"},{"data":{"description":"Agent immediately suspends the vendor's critical access ahead of transition planning; human security lead confirms containment is complete","instructions":"**Objective** — On a for-cause exit, immediately suspend the vendor's high-risk access so its continued reach cannot be used against the organization, before any unhurried transition planning begins.\n\n**Inputs**\n- The reviewed access inventory (from the inventory step): the full credential, session, and integration list with risk tags.\n- The expedited, for-cause classification (from the urgency decision) authorizing immediate containment.\n- The system owners and the security lead for each high-risk system.\n\n**Procedure**\n1. From the access inventory, select every credential, active session, and integration classified high-risk or reaching sensitive systems and data - privileged accounts, VPN and remote access, production API keys, service accounts, and physical access to sensitive sites.\n2. Suspend or revoke each one, terminate active sessions, and disable the associated API keys and service accounts, working with each system owner to execute the lockout; do not wait for the later full-revocation step.\n3. Verify no dependent production process breaks silently: for each disabled integration, confirm with its owner that no live business function depends on it, or arrange an immediate compensating path.\n4. Notify the affected system owners and the security team that emergency containment is underway.\n5. Log every action taken: system, credential, action, timestamp, and operator.\n\n**Record in AssureSwarm** — Attach the emergency containment log - system, credential, action, timestamp, and operator per entry - as a step document (coach-document-upload). Link the Vendor register item to the existing third-party Risk item (`category: third_party`) so the emergency action is traceable from the register (coach-items-link); there is no per-credential item (no Asset/Credential type), so the suspended credentials are enumerated inside the containment log rather than linked individually.\n\n**Exit criteria** — Every high-risk credential and session in the inventory is suspended or revoked; no unintended business disruption resulted; and the security lead confirms containment is complete and that the vendor's remaining, lower-risk access can now proceed through standard transition sequencing.","label":"Execute emergency access lockout","performedBy":{"primitives":["coach-items-link","coach-document-upload"]}},"id":"emergency-access-lockout"},{"data":{"description":"Stand up a working successor for every in-scope service the vendor provides and confirm cutover, so that no live business process still depends on the vendor's access when revocation and data destruction proceed.","instructions":"**Objective**\nStand up a working successor for every in-scope service the vendor provides and confirm cutover, so that no live business process still depends on the vendor's access when revocation and data destruction proceed.\n\n**Inputs**\nThe urgency classification (from the urgency decision) - on a for-cause exit this step follows emergency containment.\n- The in-scope service list from the contract and dependency mapping; the access and data inventory for the credentials, runbooks, and data extracts the successor will need.\n- The receiving owners for each successor arrangement (an alternate vendor, an in-house team, or a planned discontinuation).\n\nThe reviewed access inventory (from the inventory step) - the authoritative credential list.\n- The transition-completion record (from the service-transition step) confirming no live process still needs the vendor.\n- On a for-cause exit, the containment log from the emergency lockout (available upstream) noting which credentials were already suspended.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Revoke remaining access and credentials”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Plan and execute service transition: Stand up a working successor for every in-scope service the vendor provides and confirm cutover, so that no live business process still depends on the vendor's access when revocation and data destruction proceed.\n\n2. For each in-scope service, identify the successor arrangement: an alternate vendor, an in-house team, or a deliberate service discontinuation with documented sign-off.\n3. Determine the knowledge-transfer artifacts, runbooks, configurations, and data extracts the successor needs, and capture them now - before any vendor-held data is destroyed downstream.\n4. Sequence the cutover steps and dependency handoffs with named receiving owners and target dates; create a tracker item per handoff.\n5. Track each handoff to completion, chase overdue items, and collect confirmation from each receiving owner that the transitioned function is operating correctly.\n6. Compile the transition-completion record: every in-scope service, its successor, and its confirmed cutover date.\n\n7. Assessment scope for Revoke remaining access and credentials: Drive the vendor's standing access to zero: revoke every remaining logical, integration, and physical credential against the inventory and prove that no residual access survives.\n\n8. Reconcile the access inventory: mark the entries already suspended during emergency containment (if that path ran) and compile the full remaining list requiring revocation.\n9. Revoke every remaining credential - logical and service accounts, API keys, certificates, OAuth grants, VPN and remote-access entitlements, shared or generic accounts, and physical badges and site access - working with each system and facilities owner.\n10. Re-query each system after revocation to confirm zero active sessions, zero enabled credentials, and zero standing entitlements remain for the vendor.\n11. Reconcile the results line by line against the original inventory so no entry is left unaddressed; investigate any credential that cannot be confirmed disabled.\n\n**Record in AssureSwarm**\nMaintain the per-handoff tracker - service, successor, named receiving owner, target date, and cutover confirmation - inside the transition plan / transition-completion record, attached as a step document (coach-document-upload); there is no native Task/handoff item type, so routine handoffs are tracked in the document rather than as items. Scan the run for overdue handoffs (coach-workflow-scan). Where a handoff slips into a genuine exposure, raise it as an Issue (coach-item-create - `issue_type: observation`, `source: management_identified`, `issue_owner`, `target_remediation_date`) linked to the Vendor item.\n\nRe-query systems for residual access (coach-query-data); attach the revocation-verification record showing every inventoried credential and its confirmed revoked status (coach-document-upload).\n\n**Exit criteria**\nEvery in-scope service has a working successor arrangement (or a signed-off discontinuation) with a confirmed cutover date; no live process still needs the vendor; and the Vendor Relationship Manager and each receiving owner confirm. The revocation-verification record shows zero residual access against the full inventory with no orphaned or forgotten credential; the Vendor Relationship Manager confirms.","label":"Plan and execute service transition","performedBy":{"note":"","primitives":["coach-item-create","coach-workflow-scan","coach-document-upload","coach-query-data"]}},"id":"plan-and-execute-service-transition"},{"data":{"description":"Agent coordinates return or verified destruction of organizational data held by the vendor per the contract and sends the confirmation form and certificate requests; human reviewer packages the instruction and reconciles the returned evidence against the data inventory","formData":{"fields":[{"key":"disposition_by_category","label":"For each unresolved data category and location, state returned, destroyed or still held and its actual return/destruction completion date; do not use the form submission date","required":false,"type":"textarea"},{"key":"destruction_method","label":"Method used to destroy the data","options":[{"label":"Cryptographic erasure (keys destroyed)","value":"cryptographic_erasure"},{"label":"Certified media sanitization","value":"certified_media_sanitization"},{"label":"Physical destruction of media","value":"physical_destruction"},{"label":"Secure overwrite / deletion","value":"secure_overwrite"},{"label":"Not applicable — data returned, not destroyed","value":"not_applicable_returned"}],"required":false,"type":"select"},{"key":"residual_copies","label":"Copies still held after this disposition","options":[{"label":"None — no copies remain in any environment","value":"none_remain"},{"label":"Backup or archive copies remain until their retention expires","value":"backups_pending_expiry"},{"label":"Copies retained under a legal or regulatory obligation","value":"retained_legal_obligation"}],"required":false,"type":"select"},{"key":"residual_copies_detail","label":"If any copies remain, state where they are held, the reason, and the date they will be destroyed","required":false,"type":"textarea"},{"key":"subprocessor_disposition","label":"Disposition by your subprocessors and downstream providers","options":[{"label":"All have returned or destroyed the data and confirmed it","value":"all_confirmed"},{"label":"Some confirmations outstanding (detail above)","value":"partially_confirmed"},{"label":"No subprocessor held the data","value":"not_applicable"}],"required":false,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Get the organization's data out of the vendor's hands per the contract - returned, verifiably destroyed, or both - and collect the evidence that proves it.\n\n**Inputs**\n- The data inventory (from the inventory step) with each category's contractual disposition tag.\n- The vendor's contractual data-return and destruction provisions (initial workflow input): required methods, deadlines, and certificate or written-confirmation requirements.\n- The transition-completion record (from the service-transition step) confirming the successor has already captured any data it needs, so destruction is now safe.\n\n**Procedure**\nFirst reconcile the current inventory, contracts, prior responses, reports, certificates and other supplied evidence against the assessment period. Record supported answers and their sources as request context. Send a form only for unresolved facts, and identify exactly which optional questions need an answer; leave known questions unanswered and do not require their re-entry. If the artifacts answer every question, omit the form assignment and assess those artifacts directly. Use a named supplier contact who holds none of this workflow’s preparation, execution, review or approval assignments. The internal executor resolves evidence conflicts and records the assessment in the step result.\n\n1. For each data category and location, determine the required disposition from the inventory tag and the contract - return to the organization, verified destruction by the vendor, or a mix across categories and locations.\n2. Before dispatch, the Vendor Relationship Manager must approve the category-by-category disposition, contractual method and deadline, confirm successor receipt, and resolve legal or retention holds; record that prospective authorization in native approval. Then issue the formal data-return or destruction instruction to the vendor for each category, specifying the required method (for example cryptographic erasure or certified media sanitization), the deadline, and the certificate or written confirmation required as evidence; request certificates and receipts as documents, using only unresolved optional form questions for missing completion facts.\n3. Obtain the actual return or destruction completion date for each category and location from receipts, certificates or, where missing, the disposition_by_category response. A response submission timestamp identifies the response only and must never substitute for an actual completion date. Track the vendor's response and receipt of returned data or destruction certificates against each deadline; log receipt of each item against its inventory entry. A returned confirmation that names residual copies, an unconfirmed subprocessor, or a method weaker than the contract required is a gap, not a completion.\n4. Compile the data-disposition package: the instructions issued, the vendor's confirmation, the returned data and destruction certificates received, and any gaps where evidence has not yet arrived.\n\n**Record in AssureSwarm** — The form on this step, answered by the vendor's data-protection contact, captures the vendor's own confirmation: the disposition of each data category and location, the destruction method, per-category dates, any residual copies with the reason and their destruction date, and its subprocessors’ disposition. Bind the named assigned certifying representative and native response timestamp to the confirmation; attach certificates and receipts as documents. Vendor-supplied return receipts and destruction certificates are uploaded (PBC/external) and compiled, reconciled line-by-line against each data-inventory entry, into the data-disposition package as a step document (coach-document-upload); there is no per-data-category item (no Asset type), so the reconciliation lives inside the package. Scan the run for deadlines and outstanding receipts (coach-workflow-scan). Link the data-disposition package to the Vendor register item (coach-items-link).\n\n**Exit criteria** — Every data category has an issued instruction with a required method and deadline; engagement-specific certificates, receipts or any necessary attributable missing-fact confirmation are returned or logged as outstanding; returned data or destruction evidence is being tracked to completion; and the package is ready for verification.\n\n**Form recipient** — Vendor data-protection contact, only when that person holds none of the preparation, execution, review or approval assignments anywhere in this workflow. Request only the unresolved facts listed in the assignment; the optional fields do not require known information to be entered again. If no facts are missing, no form response is required.","label":"Execute data return or destruction","performedBy":{"primitives":["coach-workflow-scan","coach-items-link","coach-document-upload"]}},"id":"execute-data-return-or-destruction"},{"data":{"decisionField":"disposition_status","description":"Agent reconciles the vendor's return and destruction evidence against the full data inventory and drafts a completeness assessment; human decides whether the evidence is acceptable","formData":{"fields":[{"key":"disposition_status","label":"Data disposition status","options":[{"label":"Evidence accepted, disposition verified","value":"accepted"},{"label":"Remediation required, evidence insufficient","value":"remediation_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether the vendor's return and destruction evidence adequately covers every data category in the inventory, or whether gaps require another round of remediation. Owned by the Vendor Relationship Manager.\n\n**Decision criteria**\n- **accepted** (Evidence accepted, disposition verified): every inventoried data category and location has adequate evidence - a destruction certificate naming the correct data, method, and date, or returned data matching the required scope and format - and no generic or templated certificate is being relied on where engagement-specific evidence was required.\n- **remediation_required** (Remediation required, evidence insufficient): one or more categories are missing evidence, evidenced only partially, covered by a certificate that does not tie to this specific engagement, or destroyed by a method the contract or the data's sensitivity does not accept.\n\nAgent preparation before the human picks: reconcile every inventoried category and location against the evidence received (evidenced, partially evidenced, or missing); validate that each destruction certificate names the correct data, method, and date and that returned data matches the required scope and format; and draft a completeness assessment listing every gap by category, location, and responsible vendor contact.\n\n**Record in AssureSwarm** — Submit the `disposition_status` SELECT (accepted or remediation_required); record the rationale citing the specific categories relied on or missing, and name the decision owner (coach-document-upload for the completeness assessment).\n\n**Exit criteria** — The form is submitted with a coverage-based rationale; the decision owner is named; and the unselected branch is prunable.","kind":"decision","label":"Verify data disposition","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"verify-data-disposition"},{"data":{"description":"Agent re-engages the vendor to close the specific evidence gaps and re-validates the corrected evidence; human confirms the gap is closed","instructions":"**Objective** — Close the specific evidence gaps the verification found, re-engaging the vendor until every data category is fully evidenced.\n\n**Inputs**\n- The completeness assessment (from the verification decision) listing each gap by data category, location, and defect.\n- The vendor's contractual exit provisions (initial workflow input) for the clauses that compel compliance and any remedy for non-performance.\n\n**Procedure**\n1. Parse the completeness assessment into a gap list: each item's data category, location, and specific defect - a missing certificate, mismatched scope, or an unacceptable destruction method.\n2. Re-issue the data-return or destruction instruction for each gap, escalating through the vendor relationship and, where the contract allows, citing the specific clause requiring compliance and any remedy for non-performance.\n3. Re-validate the newly received evidence against the same completeness checks the originals failed, and cross-reference it against the outstanding gap list to confirm each gap is resolved.\n4. Draft a remediation addendum documenting what was missing, what was obtained, and the re-validation result.\n\n**Record in AssureSwarm** — Re-query and track the outstanding gaps (coach-query-data); attach the corrected evidence and the remediation addendum (coach-document-upload).\n\n**Exit criteria** — Every previously identified gap now has adequate, engagement-specific evidence; the Vendor Relationship Manager confirms and releases the fully evidenced data-disposition package.","label":"Remediate data disposition gap","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"remediate-data-disposition-gap"},{"data":{"description":"Approve complete sensitivity-matched internal disposal and the evidenced exit outcome, then retain the full termination record under contractual retention and carry every residual obligation to a named owner.","instructions":"**Objective**\nApprove complete sensitivity-matched internal disposal and the evidenced exit outcome, then retain the full termination record under contractual retention and carry every residual obligation to a named owner.\n\n**Inputs**\nThe component inventory (from the inventory step), plus any internal-side data copies surfaced during the data-return step.\n- The verified or remediated data-disposition outcome confirming the vendor side is handled, so internal copies can now be destroyed.\n- Data sensitivity classifications and the technical owners who can execute each disposal.\n\nThe revocation-verification record (from the revoke step).\n- The data-disposition package and any remediation addendum (arriving through the verification and disposal chain) and the internal disposal log (from the disposal step).\n- The access and data inventories, the transition-completion record, and the vendor's contractual post-relationship and evidence-retention provisions (initial workflow input).\n\nThe retained termination evidence package and its applied retention schedule (from the compile step).\n- The vendor register and any active vendor-risk or oversight dashboards.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Compile termination evidence and retain”, “Close and archive”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Dispose of internal components and tools: Securely dispose of the organization's own internal-side residue of the relationship - working copies of vendor data, dedicated components, tooling, and documentation - using a defined technique matched to each item's sensitivity.\n\n2. From the component inventory, list every internal-side item dedicated to the relationship for disposal: working copies of vendor data, integration configurations and secrets, dedicated hardware, software licenses, test and staging environments, and relationship-specific documentation no longer needed.\n3. Determine the defined disposal technique per item by sensitivity: cryptographic erasure or certified wipe for storage, physical destruction for decommissioned hardware, and secure deletion for configurations and documentation no longer under a retention hold. Anything still under a legal or retention hold is excluded and noted.\n4. Before any internal disposal begins, the Vendor Relationship Manager and responsible technical owner must approve the enumerated population, sensitivity-matched method and hold exclusions in native approval. Execute or route only those authorized disposals to the appropriate technical owner; for every item, record the technique used, the date, the operator, and a witness where required.\n5. Compile the disposal log covering every disposed item and its recorded technique.\n\n6. Assessment scope for Compile termination evidence and retain: Assemble the complete, audit-standing termination evidence package for this exit and place it under the contractual retention schedule.\n\n7. Assemble the full termination record: the contractual exit provisions and in-scope boundary, the access, data, and component inventories, the revocation-verification record, the transition-completion record, the data-disposition package (including any remediation addendum), and the internal disposal log.\n8. Cross-check the assembled package against the contractual post-relationship provisions so no required evidence type is missing.\n9. Apply the retention schedule required for post-relationship vendor records; set the retention date and file the package in the designated evidence repository, tying every artifact to the vendor's termination record.\n10. Draft the closure summary for the Vendor Relationship Manager and the system owners: what was completed, on what date, and where the evidence is retained.\n\n11. Assessment scope for Close and archive: Archive the retained evidence package, mark the vendor relationship formally terminated, and confirm nothing is left open without an owner - the single closing checkpoint for this exit.\n\n12. Export the final termination evidence package and archive it alongside the vendor's contract record under the applied retention schedule.\n13. Update the vendor register and any active vendor-risk or oversight dashboards to mark the relationship terminated, record the effective date, and point to the archived evidence.\n14. Confirm no open items remain - outstanding revocations, undelivered destruction certificates, unresolved disposal items, or pending transition handoffs - and create a tracked follow-up item with a named owner and due date for anything still open.\n15. Notify the accountable stakeholders and the vendor-management program that the termination cycle is closed.\n\n**Record in AssureSwarm**\nRe-query the asset and license register for vendor-dedicated components (coach-query-data); record each disposal - technique, date, operator, and witness where required, with retention-hold exclusions noted - in the internal disposal log attached as a step document (coach-document-upload). The component inventory itself is the document produced upstream, not per-entry items.\n\nLink every step document (the access/data/component inventory, containment log, transition-completion record, revocation-verification record, data-disposition package and any remediation addendum, and internal disposal log) to the **Vendor** register item (coach-document-link); assemble them into one retained, indexed and paginated termination evidence package (coach-render-package) and attach it as a step document, PDF or ZIP, with the contractual retention date stamped (coach-document-upload).\n\nExport and archive the full run as the durable termination record (coach-workflow-export). Enrich the **Vendor** register item (coach-item-update): confirm `monitoring_status: exited` and `contract_end_date`; where a third-party Risk item (`category: third_party`) covers the vendor, close it and reassess its `residual_rating` post-exit. For any residual open item - outstanding revocation, undelivered destruction certificate, unresolved disposal, or pending transition handoff - create an Issue (coach-item-create - `issue_type: exception`, `source: management_identified`, `issue_owner`, `target_remediation_date`) linked to the archived run.\n\n**Exit criteria**\nEvery in-scope internal item is individually recorded as disposed with a technique matching its sensitivity (no blanket assertions); items under a retention hold are noted; and the Vendor Relationship Manager confirms nothing dedicated to the relationship was overlooked. The package is complete against the contractual provisions; the correct retention period is applied; the evidence would stand to an auditor or regulator without oral explanation; and the Vendor Relationship Manager confirms. Nothing remains open without a tracked owner; the archive is retrievable and self-contained; and the Vendor Relationship Manager formally declares the vendor termination closed.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — assembles the linked evidence artifacts into a single retained, index-paginated package.","label":"Dispose of internal components and tools","performedBy":{"note":"","primitives":["coach-query-data","coach-document-upload","coach-render-package","coach-workflow-export","coach-item-create","coach-item-update"]}},"id":"dispose-internal-components-and-tools"}],"sourceTemplateId":"workflow-library:grc-vendor-offboarding-secure-termination"}