# Vendor Offboarding and Access Removal Mini-Course

A free, reviewable cybersecurity training package for teaching managers, vendor owners, IT, procurement, and operations teams how to remove third-party access safely when a vendor, contractor, tool, project, or client engagement ends.

**Use this as a starter asset, not legal advice, a compliance guarantee, proof of control effectiveness, or a promise of outcomes. Review and adapt it to your approved systems, contracts, access workflows, data-retention rules, and LMS requirements before publishing.**

## Course snapshot

- **Audience:** Vendor owners, managers, procurement teams, IT admins, GRC teams, MSP/vCISO teams, L&D teams, and operations leaders responsible for third-party access.
- **Format:** 6 to 8 minute micro-course plus three scenario questions.
- **Training goal:** Help learners recognize when vendor access should be reviewed, removed, or escalated.
- **Learner decision:** Before a vendor relationship, contractor engagement, SaaS tool, shared folder, integration, or project ends, confirm the access owner, business purpose, data location, removal date, evidence path, and escalation owner.
- **Content Studio use case:** Turn a vendor offboarding checklist or access policy into a reviewable course draft, quiz, remediation note, captions/transcript guidance, and LMS-ready export notes.

## Learning objectives

By the end of this course, learners should be able to:

1. Identify common vendor-offboarding triggers that may require access removal or review.
2. Confirm the approved owner and system of record before removing, retaining, or changing access.
3. Avoid risky shortcuts such as leaving shared accounts, stale folders, orphaned integrations, or unmanaged admin permissions in place.
4. Escalate uncertainty when access, data retention, legal hold, contract terms, customer commitments, or operational continuity may be affected.
5. Document completion through the approved process so the organization can review evidence when appropriate.

## Lesson copy

Vendor access does not become safe just because the project is over.

Many organizations are good at onboarding vendors because there is urgency. A tool needs to be launched. A contractor needs access. A service provider needs a shared folder. A consultant needs a temporary account. A support team needs a portal. The business need is visible, so access gets created.

Offboarding is quieter. The contract ends. A project pauses. A contractor rolls off. A proof of concept expires. A department stops using a SaaS tool. A vendor contact changes jobs. A client engagement wraps up. Nobody is trying to be careless, but access can remain because no one is sure who owns the cleanup.

That is the training problem: vendor offboarding is not just an IT task. It is a shared decision between the business owner, procurement, security, IT, GRC, legal, privacy, finance, and operations depending on the relationship and the data involved.

The practical habit is simple: when vendor work ends or changes, do not assume access will clean itself up. Confirm the owner, confirm the system, confirm the access, confirm the data location, and confirm the approved next step.

Common offboarding triggers include:

- A vendor contract ending or not renewing.
- A contractor, consultant, or agency employee leaving the engagement.
- A project, pilot, proof of concept, or implementation phase closing.
- A SaaS tool being replaced, retired, or moved to a different owner.
- A shared folder, portal, integration, API key, service account, or admin permission no longer being needed.
- A vendor-risk review identifying access that no longer matches business purpose.
- A customer, regulatory, audit, or internal review asking who still has access.

The safest next step depends on your organization's process. In some cases, IT removes an account. In others, procurement updates the vendor record, GRC requests evidence, legal confirms retention obligations, privacy reviews data handling, finance closes billing, or the business owner confirms whether access is still needed.

The lesson is not to delete everything immediately. That can create its own risk if systems, records, evidence, customer commitments, legal holds, or operations are affected. The lesson is to use the approved path instead of ignoring stale access or improvising a cleanup.

A strong vendor offboarding process usually asks six questions:

1. **Who owns the relationship?** Identify the business owner, vendor owner, or system owner responsible for confirming need.
2. **What access exists?** Review accounts, groups, shared folders, admin roles, integrations, API keys, service accounts, support portals, VPN access, and collaboration spaces.
3. **What data is involved?** Check whether the vendor touched customer data, employee data, confidential business information, regulated data, CUI, payment information, security data, source code, or AI prompts/outputs.
4. **What should happen now?** Remove, reduce, transfer, suspend, or retain access according to the approved workflow.
5. **What must be documented?** Record completion in the approved system when documentation or evidence is expected.
6. **Who reviews exceptions?** Escalate uncertainty to the right owner when access needs to continue, data retention is unclear, or removal could affect operations.

Vendor offboarding also includes communication. If the vendor still has a legitimate support role, the approved owner should define what access remains, why it remains, who approved it, when it will be reviewed again, and what monitoring or restrictions apply. If access is no longer needed, remove it through the approved process and document the result.

Be especially careful with shared credentials and integrations. A named user account can be visible in an access review. A shared password, API token, webhook, mailbox rule, file share, or service account may be easier to miss. Those access paths can outlive the vendor relationship unless someone checks for them.

The same caution applies to collaboration tools. Vendors may have access to project folders, chat channels, document libraries, design tools, ticket queues, cloud workspaces, repositories, AI tools, recording platforms, LMS systems, or customer portals. Offboarding should include the places where work happened, not just the identity provider.

Quiz feedback should teach judgment. If a learner chooses to leave access in place because the vendor might come back later, explain why that creates risk and what safer behavior looks like: confirm business need, use the approved exception process, set a review date, and document the decision.

Vendor offboarding is not about blame. It is about closing the loop. Access should match current business need, data should stay in approved places, exceptions should be visible, and uncertainty should move to the right owner instead of living quietly in old permissions.

## Scenario 1: The consultant rolled off

A department manager worked with a consultant for six months. The project ended last week. The consultant still appears in a shared drive and a project chat channel. The manager assumes IT will remove access automatically.

**Question:** What should the manager do next?

A. Leave the access alone because the consultant may be needed later.  
B. Delete every file the consultant touched.  
C. Use the approved vendor or access offboarding process to confirm ownership, access scope, data location, and removal timing.  
D. Ask the consultant to remove themselves from the systems.

**Preferred answer:** C.

**Teaching feedback:** Vendor access should not be left in place by assumption. The manager should use the approved process to confirm whether access is still needed, which systems are involved, what data is present, and who owns removal or exception approval. Do not delete business records or ask the vendor to self-offboard unless that is part of the approved workflow.

## Scenario 2: The SaaS tool is being replaced

A team is moving from one SaaS tool to another. The old tool includes customer files, several vendor admin accounts, an integration token, and exported reports. The new tool launches next week.

**Question:** What is the safest training-relevant habit?

A. Cancel the old tool as soon as the new tool goes live.  
B. Confirm the retirement plan, data handling expectations, integration cleanup, account removal, retention requirements, billing owner, and evidence path before closing the tool.  
C. Ask each user to download anything they might need to personal storage.  
D. Keep the old tool running indefinitely so nobody loses access.

**Preferred answer:** B.

**Teaching feedback:** Tool retirement can affect access, data retention, integrations, billing, audit evidence, and operational continuity. The safest path is to follow the approved retirement and offboarding workflow. Do not move data to personal storage, leave stale access indefinitely, or cancel systems without confirming retention and business requirements.

## Scenario 3: The vendor still needs temporary support access

A vendor contract ended, but the vendor says they need two more weeks of support access to help with transition questions. The business owner is under pressure and wants to keep the old permissions active.

**Question:** What should happen before access continues?

A. Keep the same permissions because the vendor already had them.  
B. Share a team member's login so the vendor can help without reopening the account.  
C. Use the approved exception or extension process to define scope, owner, end date, reason, and review requirements.  
D. Ignore the request until the vendor stops asking.

**Preferred answer:** C.

**Teaching feedback:** Temporary support access may be appropriate in some environments, but it should be approved, scoped, time-bound, and documented. Do not share credentials or let old permissions continue without review. If the right answer depends on contract terms, system sensitivity, customer commitments, or data type, escalate to the approved owner.

## Remediation note

If an access review shows stale vendor access, respond with a learning loop instead of a blame loop. Confirm the current owner, remove or reduce access through the approved process, document the result when evidence is expected, and update training or manager guidance so the trigger is easier to recognize next time.

Suggested manager reminder:

> When vendor work ends, access cleanup is part of the closeout. If you are not sure who owns removal, use the approved vendor offboarding path and ask before guessing.

## LMS packaging guidance

- Package as a 6 to 8 minute micro-course.
- Include the lesson copy, three scenario questions, and the remediation note.
- Add captions/transcript text if converted to video or narrated lesson format.
- Add a short acknowledgment: “I know where to start the vendor offboarding or access removal process in my organization.”
- Track completion by role or team when the course supports manager, vendor owner, procurement, IT, or GRC enablement.
- Set a refresh date tied to vendor-risk policy updates, access review cadence, SaaS retirement process changes, or procurement workflow changes.

## Review checklist before publishing

- Security confirms risk framing and access-control language.
- IT or identity owner confirms account, integration, API key, shared credential, and access-removal workflow language.
- Procurement or vendor-risk owner confirms vendor closeout and contract process language.
- Legal/privacy confirms data-retention, customer, regulated-data, contract, or legal-hold references when relevant.
- GRC confirms evidence and audit-support language is proof-safe.
- L&D confirms learner clarity, quiz feedback, accessibility considerations, and LMS fit.

## Content Studio prompt

Copy this into Content Studio by Jericho and replace the placeholders:

> Create a 6 to 8 minute cybersecurity training micro-course for [audience] on vendor offboarding and third-party access removal. Use [policy/checklist/source material] as the approved source. Teach the decision: when vendor work ends or changes, confirm the owner, access scope, data location, removal timing, documentation path, and exception owner before ignoring or changing access. Include one consultant rolloff scenario, one SaaS tool retirement scenario, one temporary support-access extension scenario, three quiz questions with teaching feedback, a remediation note, captions/transcript guidance, LMS-ready export notes, and a review checklist for Security, IT, Procurement/Vendor Risk, GRC, Legal/Privacy, and L&D. Use proof-safe language. Do not claim the course guarantees compliance, prevents incidents, or proves control effectiveness.

## Suggested CTA

Build the policy-fit version in Content Studio by Jericho: https://contentstudio.jerichosecurity.com/campaigns/course-giveaway-vendor-offboarding-access-removal