What does SOC 2 require for onboarding and offboarding?

The criteria do not list steps. CC1.4 expects the company to hire and develop competent people, which auditors usually test with background checks and training records. CC6.2 expects access to be granted only after approval and removed when it is no longer needed, and CC6.3 expects access to follow the role. Your own policies turn those into specific steps and deadlines, and the auditor tests against what the policies say. These checklists list those steps for your systems.

What if we do not use an MDM tool?

Then the checklists do not pretend you do. The device steps become the manual baseline checklist before a laptop is issued, and a secure erase recorded on the offboarding checklist when it comes back, as the Endpoint and Workstation Security Policy describes for companies without device management.

Do contractors need the same checklist?

The generated Human Resources Security Policy says contractors, agency workers and vendor staff with access meet the same screening, acknowledgment, training and offboarding requirements as employees. Use the same checklist and mark them as contractors; where an agency screens them, keep its written confirmation as the screening evidence.

What does the Audit Kit version add?

The free checklists quote the policy template text rendered from your answers. In the Audit Kit, the policies are tailored to your tools and team first, and the people folder is built from that tailored text, with the generation date and intake reference in the document footers so the files trace back to the policy set they came from.

Is anything uploaded?

No. The generator keeps your answers in this browser's local storage, the policies are rendered here, and the checklists and tracker are built on your device. With no saved answers the page shows the sample company, Northwind Cloud Inc.

SOC 2 onboarding and offboarding checklists

Updated 23 October 2026

An onboarding checklist and an offboarding checklist with one step per system you use, each with an owner, a deadline taken from your own policies, the policy section it comes from and the evidence to keep. Plus a joiners and leavers tracker that works out every due date and flags what is overdue. Built in your browser; no signup.

How auditors sample joiners and leavers

In a SOC 2 Type II examination the auditor usually asks for a list of everyone who joined and everyone who left during the period, picks a sample from each list, and asks for evidence for each person in the sample:

Joiners: a background check where the law allows it, signed policy acknowledgments and security training within the deadline, and access granted from an approved request. These are tested under CC1.4 and CC6.2.
Leavers: access removed within the deadline in every system, not only the identity provider, and devices returned and wiped. These are tested under CC6.2 and CC6.3.

The deadlines come from your policies, not from SOC 2. In the generated Human Resources Security Policy, section 4.6 reads: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.” Its offboarding procedure (section 5.6) sums it up as “Timing: identity disabled by the end of the last working day; all other access removed within one business day.” A leaver whose source control or cloud account was still active two days later is a finding, even if the identity account was disabled on time.

Your checklists

This is the sample company, Northwind Cloud Inc. The steps list its systems and quote its generated policies, not yours. Answer the generator questions and come back: the checklists then list your systems and quote the policies written from your answers.

Download the checklists

A 16-step onboarding checklist and a 17-step offboarding checklist in Word, with a sign-off box per step, and a joiners and leavers tracker in Excel, for Northwind Cloud Inc. Built in your browser from the policy template text; nothing is uploaded and there is no signup.

Systems with their own step: Okta, GitHub, AWS, Vercel, GitHub Actions, 1Password, Kandji, Datadog. Vendors with their own offboarding step: Supabase, Stripe, Slack.

Onboarding checklist

Deadlines are counted from the start date. Open a step’s policy line to see the sentences it comes from.

ON-01
Open the onboarding ticket with the role, manager, start date, device requirement and the role-based access profile, approved by the hiring manager.
Owner
People Operations, with the hiring manager
Due
3 business days before the start date (counted from the start date)
Evidence
The ticket with its creation date, the access profile for the role and the hiring manager's approval, dated before any account is created.
Policy: P18 5.2, P18 4.3, P03 4.5
- P18 Human Resources Security Policy, section 5.2: “Three business days before the start date, People Operations opens an onboarding ticket listing role, manager, start date, device requirement and access profile.”
- P18 Human Resources Security Policy, section 4.3: “Access is provisioned within one business day of the start date through Okta, the source of identity for all company accounts, using a role-based access profile approved by the hiring manager.”
- P03 Access Control Policy, section 4.5: “Access requests are made in the ticketing system, name the system and role required, and are approved by the requester's manager and the system owner before provisioning.”
ON-02
Complete pre-employment screening: identity, right to work, most recent employment and a criminal record check where legally permitted. Review the results with the hiring manager before confirming the start date.
Owner
People Operations
Due
Before the start date (counted from the start date)
Evidence
The screening report or the record of each manual check, with the date it was completed; where a check is not permitted, the recorded reason and the alternative used; for contractors, the contracting entity's written confirmation.
Policy: P18 4.1, P18 4.9
- P18 Human Resources Security Policy, section 4.1: “Every candidate for a role with access to Northwind systems, customer data or company finances is screened before their start date: identity verification, right-to-work confirmation, verification of the most recent employment, and a criminal record check where legally permitted in the candidate's jurisdiction and proportionate to the role.”
- P18 Human Resources Security Policy, section 4.1: “Where a check is not permitted, People Operations records the reason and applies an alternative such as additional reference checks.”
- P18 Human Resources Security Policy, section 4.9: “Where the contracting entity performs screening, Northwind Cloud Inc obtains written confirmation that it is equivalent to Section 4.1.”
ON-03
Collect the signed employment or services agreement with confidentiality and intellectual property terms.
Owner
People Operations
Due
Before any account or device is issued (before the start date) (counted from the start date)
Evidence
The signed agreement, dated before the first account or device was issued.
Policy: P18 4.2
- P18 Human Resources Security Policy, section 4.2: “No account, device or system access is issued until the individual has signed an employment or services agreement with confidentiality and intellectual property terms and has acknowledged the Information Security Policy and the Acceptable Use Policy in writing.”
ON-04
Collect the written acknowledgment of the Information Security Policy and the Acceptable Use Policy before any account is created.
Owner
People Operations
Due
Before any account or device is issued (before the start date) (counted from the start date)
Evidence
The signed acknowledgments, dated before the account creation date in Okta.
Policy: P18 4.2, P02 5.1
- P18 Human Resources Security Policy, section 4.2: “No account, device or system access is issued until the individual has signed an employment or services agreement with confidentiality and intellectual property terms and has acknowledged the Information Security Policy and the Acceptable Use Policy in writing.”
- P02 Acceptable Use Policy, section 5.1: “People Operations sends this policy with the offer paperwork, obtains a signed acknowledgment, and files it before the Security Owner approves account creation.”
ON-05 · Kandji
Prepare the company device: enroll it in Kandji, check that encryption, screen lock and update policies have applied, and record the device and its user in the asset register.
Owner
IT/Operations Lead
Due
Before the start date (counted from the start date)
Evidence
The Kandji enrollment record for the device serial number and the asset register entry with the assigned user.
Policy: P19 5.1, P02 5.2, P19 4.3
- P19 Endpoint and Workstation Security Policy, section 5.1: “Timing: before the user's start date, or within one business day of a replacement request.”
- P02 Acceptable Use Policy, section 5.2: “Engineering or the designated IT function configures each company device to the baseline in 4.4 before handover, enrolls it in Kandji and verifies that encryption, screen lock and update policies have applied, and records the device and its user in the asset register under the Asset Management Policy.”
- P19 Endpoint and Workstation Security Policy, section 4.3: “Every company endpoint is enrolled in Kandji before it is issued, and enrollment may not be removed by the user.”
ON-06 · Okta
Create the Okta account and assign the groups in the approved access profile, active no earlier than the first working day.
Owner
Engineering
Due
Within 1 business day of the start date (counted from the start date)
Evidence
The Okta account creation date and group assignments, matching the access profile on the ticket.
Policy: P18 4.3, P03 5.1
- P18 Human Resources Security Policy, section 4.3: “Access is provisioned within one business day of the start date through Okta, the source of identity for all company accounts, using a role-based access profile approved by the hiring manager.”
- P03 Access Control Policy, section 5.1: “Engineering provisions the standard bundle for that role in Okta, GitHub and the relevant groups in AWS and Vercel, activated no earlier than the first working day.”
ON-07 · Okta
Enroll multi-factor authentication on the Okta account before any other system is used.
Owner
New starter, checked by Engineering
Due
On the first day (counted from the start date)
Evidence
The Okta MFA enrollment record (factor type and date) for the person.
Policy: P18 4.3, P03 4.4
- P18 Human Resources Security Policy, section 4.3: “Multi-factor authentication is enrolled on the first day, before any other system is used.”
- P03 Access Control Policy, section 4.4: “Multi-factor authentication is enforced for every workforce account, with phishing-resistant methods for administrative roles, under the Authentication and Password Policy.”
ON-08 · GitHub
Add the person to the GitHub organization and the teams in the access profile.
Owner
Engineering
Due
Within 1 business day of the start date (counted from the start date)
Evidence
The GitHub audit log entry for the invitation and the ticket line listing the teams granted.
Policy: P18 4.3, P03 4.8
- P18 Human Resources Security Policy, section 4.3: “Access is provisioned within one business day of the start date through Okta, the source of identity for all company accounts, using a role-based access profile approved by the hiring manager.”
- P03 Access Control Policy, section 4.8: “Access to GitHub is granted through organization membership enforced by single sign-on with Okta, repository permissions are assigned by team, and protected branches require a review from someone other than the author before code is merged and deployed by GitHub Actions.”
ON-09 · AWS
Grant AWS console access from the standard bundle for the role. Production roles need their own request approved by the Engineering lead.
Owner
Engineering
Due
Within 1 business day of the start date (counted from the start date)
Evidence
The AWS identity or IAM change record and the ticket line for the role granted; for a production role, the Engineering lead's approval.
Policy: P18 4.3, P03 5.1, P03 4.6
- P18 Human Resources Security Policy, section 4.3: “Access is provisioned within one business day of the start date through Okta, the source of identity for all company accounts, using a role-based access profile approved by the hiring manager.”
- P03 Access Control Policy, section 5.1: “Engineering provisions the standard bundle for that role in Okta, GitHub and the relevant groups in AWS and Vercel, activated no earlier than the first working day.”
- P03 Access Control Policy, section 4.6: “Production access to AWS and Vercel is granted only to engineers whose role requires it, through federated identity and short-lived credentials rather than long-lived access keys.”
ON-10 · Vercel
Grant Vercel console access from the standard bundle for the role. Production roles need their own request approved by the Engineering lead.
Owner
Engineering
Due
Within 1 business day of the start date (counted from the start date)
Evidence
The Vercel identity or IAM change record and the ticket line for the role granted; for a production role, the Engineering lead's approval.
Policy: P18 4.3, P03 5.1, P03 4.6
- P18 Human Resources Security Policy, section 4.3: “Access is provisioned within one business day of the start date through Okta, the source of identity for all company accounts, using a role-based access profile approved by the hiring manager.”
- P03 Access Control Policy, section 5.1: “Engineering provisions the standard bundle for that role in Okta, GitHub and the relevant groups in AWS and Vercel, activated no earlier than the first working day.”
- P03 Access Control Policy, section 4.6: “Production access to AWS and Vercel is granted only to engineers whose role requires it, through federated identity and short-lived credentials rather than long-lived access keys.”
ON-11 · GitHub Actions
Grant the permissions the role needs in GitHub Actions.
Owner
Engineering
Due
Within 1 business day of the start date (counted from the start date)
Evidence
The membership or permission record in GitHub Actions and the ticket line.
Policy: P18 4.3
- P18 Human Resources Security Policy, section 4.3: “Access is provisioned within one business day of the start date through Okta, the source of identity for all company accounts, using a role-based access profile approved by the hiring manager.”
ON-12 · 1Password
Invite the person to 1Password and give access only to the vaults the role needs.
Owner
Engineering
Due
On the first day (counted from the start date)
Evidence
The 1Password member record with the date and the list of vaults shared.
Policy: P18 5.2, P02 4.2
- P18 Human Resources Security Policy, section 5.2: “On day one the new starter receives their device, already enrolled in Kandji, enrolls multi-factor authentication, joins 1Password and acknowledges the required policies.”
- P02 Acceptable Use Policy, section 4.2: “Work credentials are stored only in 1Password.”
ON-13 · Datadog
Grant Datadog access only if the role needs log access (Engineering and the Security Owner).
Owner
Engineering
Due
Within 1 business day of the start date (counted from the start date)
Evidence
The Datadog user record and the ticket line, or a note on the ticket that the role does not need log access.
Policy: P18 4.3, P12 4.6
- P18 Human Resources Security Policy, section 4.3: “Access is provisioned within one business day of the start date through Okta, the source of identity for all company accounts, using a role-based access profile approved by the hiring manager.”
- P12 Logging and Monitoring Policy, section 4.6: “Log access is restricted to Engineering and the Security Owner under the Access Control Policy, administrative access is limited to named individuals, and all access is logged and reviewed quarterly.”
ON-14
Acknowledge the Information Security Policy, the Acceptable Use Policy and the Human Resources Security Policy electronically.
Owner
People Operations
Due
Within 5 business days of the start date (counted from the start date)
Evidence
The electronic acknowledgment records with their dates, stored with the personnel record.
Policy: P18 5.3
- P18 Human Resources Security Policy, section 5.3: “All personnel acknowledge the Information Security Policy, the Acceptable Use Policy and this policy within five business days of starting and within 30 days of each revision.”
ON-15
Complete security awareness training.
Owner
New starter; Security Owner assigns it and People Operations chases it
Due
Within 30 days of the start date (counted from the start date)
Evidence
The training record (date, completion and quiz score) in the training tracker.
Policy: P18 4.4, P18 5.4
- P18 Human Resources Security Policy, section 4.4: “All personnel complete security awareness training within 30 days of starting and at least every 12 months thereafter.”
- P18 Human Resources Security Policy, section 5.4: “The Security Owner maintains the curriculum and assigns it to new starters within 30 days and to all personnel annually.”
ON-16
Where the role calls for it, complete secure development training for engineers; data protection training for people who handle personal data.
Owner
New starter; Security Owner assigns it
Due
Within 30 days of the start date (counted from the start date)
Evidence
The training record for each course the role requires, or a note that none applies.
Policy: P18 4.4
- P18 Human Resources Security Policy, section 4.4: “All personnel complete security awareness training within 30 days of starting and at least every 12 months thereafter.”
- P18 Human Resources Security Policy, section 4.4: “Engineers also complete secure development training covering the OWASP Top 10, secrets handling and change management.”
- P18 Human Resources Security Policy, section 4.4: “Personnel who handle personal data complete data protection training on lawful processing, data subject rights and breach reporting.”

Offboarding checklist

The rule leavers are tested against, from P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”

Deadlines are counted from the last working day.

OFF-01
Record the last working day in the HR system and notify the Security Owner and Engineering.
Owner
People Operations
Due
The day the departure is known, and no later than the last working day (counted from the last working day)
Evidence
The HR record with the last working day and the dated notification (ticket or message) to the Security Owner and Engineering.
Policy: P03 section 3, P18 5.6
- P03 Access Control Policy, section 3: “People Operations triggers provisioning at hire, notifies the Security Owner and Engineering of role changes and departures on the day they are known, and keeps the personnel records that reviews are reconciled against.”
- P18 Human Resources Security Policy, section 5.6: “People Operations records the last working day and notifies the Security Owner and Engineering.”
OFF-02 · Okta
Disable the Okta account and revoke its sessions, which cuts off the applications connected to it. For an involuntary departure, do it immediately.
Owner
Engineering
Due
By the end of the last working day (immediately for an involuntary departure) (counted from the last working day)
Evidence
The Okta system log entry showing the deactivation time and the session revocation, no later than the end of the last working day.
Policy: P18 4.6, P18 5.6
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- P18 Human Resources Security Policy, section 5.6: “Timing: identity disabled by the end of the last working day; all other access removed within one business day.”
OFF-03 · GitHub
Remove the person from the GitHub organization, and transfer ownership of their repositories to the manager.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
The GitHub audit log entry for the removal, with its date.
Policy: P18 4.6, P18 5.6
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- P18 Human Resources Security Policy, section 5.6: “On the departure date (immediately for involuntary departures) Engineering disables the Okta account, cutting off connected applications, then GitHub, AWS and Vercel and GitHub Actions access, removes the person from Supabase, Stripe, Datadog and Slack, revokes personal API tokens and transfers ownership of documents and repositories to the manager.”
OFF-04 · AWS
Remove the person's AWS console and command-line access, including any production role and access keys.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
The AWS identity or IAM change record showing the access removed, with its date.
Policy: P18 4.6, P03 5.4
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- P03 Access Control Policy, section 5.4: “When People Operations confirms a departure, Engineering disables the Okta account, revokes sessions and tokens, removes membership of GitHub and AWS and Vercel, and rotates any shared or break-glass credentials the leaver could have known.”
OFF-05 · Vercel
Remove the person's Vercel console and command-line access, including any production role and access keys.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
The Vercel identity or IAM change record showing the access removed, with its date.
Policy: P18 4.6, P03 5.4
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- P03 Access Control Policy, section 5.4: “When People Operations confirms a departure, Engineering disables the Okta account, revokes sessions and tokens, removes membership of GitHub and AWS and Vercel, and rotates any shared or break-glass credentials the leaver could have known.”
OFF-06 · GitHub Actions
Remove the person's access in GitHub Actions.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
The membership or audit record in GitHub Actions showing the removal, with its date.
Policy: P18 4.6
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
OFF-07 · 1Password
Remove the person from 1Password, review the vaults they could open and rotate every credential they could read.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
The 1Password member removal record and the list of rotated items with dates.
Policy: P18 4.8
- P18 Human Resources Security Policy, section 4.8: “When a person leaves, the vaults they could access are reviewed and any credential they could have read is rotated within one business day of departure, as the Access Control Policy and the Encryption and Key Management Policy require.”
OFF-08
Revoke personal API tokens and keys, remove the person from shared mailboxes, and rotate any shared or break-glass credential they could have known.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
A list of the tokens revoked and secrets rotated, with dates.
Policy: P18 4.6, P18 5.6, P03 5.4
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- P18 Human Resources Security Policy, section 5.6: “On the departure date (immediately for involuntary departures) Engineering disables the Okta account, cutting off connected applications, then GitHub, AWS and Vercel and GitHub Actions access, removes the person from Supabase, Stripe, Datadog and Slack, revokes personal API tokens and transfers ownership of documents and repositories to the manager.”
- P03 Access Control Policy, section 5.4: “When People Operations confirms a departure, Engineering disables the Okta account, revokes sessions and tokens, removes membership of GitHub and AWS and Vercel, and rotates any shared or break-glass credentials the leaver could have known.”
OFF-09 · Datadog
Remove the person's access in Datadog.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
The Datadog user list or audit log showing the removal, with its date.
Policy: P18 4.6, P12 section 3
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- P12 Logging and Monitoring Policy, section 3: “People Operations ensures on-call personnel and log reviewers complete the relevant training and that log access is removed at offboarding.”
OFF-10 · Supabase
Remove access in Supabase.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
The Supabase user list or audit log showing the account removed or deactivated, with its date.
Policy: P18 4.6
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- P18 Human Resources Security Policy, section 4.6: “Revocation covers the Okta identity and every application connected to it, GitHub, AWS and Vercel, GitHub Actions, Supabase, Stripe, Datadog and Slack, shared mailboxes, API tokens and any credential the person held personally.”
OFF-11 · Stripe
Remove access in Stripe.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
The Stripe user list or audit log showing the account removed or deactivated, with its date.
Policy: P18 4.6
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- P18 Human Resources Security Policy, section 4.6: “Revocation covers the Okta identity and every application connected to it, GitHub, AWS and Vercel, GitHub Actions, Supabase, Stripe, Datadog and Slack, shared mailboxes, API tokens and any credential the person held personally.”
OFF-12 · Slack
Remove access in Slack.
Owner
Engineering
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
The Slack user list or audit log showing the account removed or deactivated, with its date.
Policy: P18 4.6
- P18 Human Resources Security Policy, section 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- P18 Human Resources Security Policy, section 4.6: “Revocation covers the Okta identity and every application connected to it, GitHub, AWS and Vercel, GitHub Actions, Supabase, Stripe, Datadog and Slack, shared mailboxes, API tokens and any credential the person held personally.”
OFF-13
Collect every company device from the person and record the return in the device inventory.
Owner
People Operations, with the IT/Operations Lead
Due
On or before the last working day (counted from the last working day)
Evidence
The inventory entry with the serial number and return date; for remote staff, the tracked courier reference.
Policy: P18 4.7, P02 5.8
- P18 Human Resources Security Policy, section 4.7: “Company devices are returned on or before the last working day.”
- P02 Acceptable Use Policy, section 5.8: “On the last working day People Operations confirms that devices, badges and materials have been returned and that no copies of company or customer data are retained, and Engineering confirms that accounts are disabled and access removed on the timeline in the Access Control Policy.”
OFF-14 · Kandji
Wipe the returned device through Kandji, remove the leaver's assignment and update the device inventory. The device is not reassigned until the wipe is recorded.
Owner
IT/Operations Lead
Due
Within 5 business days of return (counted here from the last working day) (counted from the last working day)
Evidence
The Kandji wipe record with date and serial number, and the updated inventory entry.
Policy: P19 5.7, P18 4.7
- P19 Endpoint and Workstation Security Policy, section 5.7: “Timing: within five business days of return.”
- P18 Human Resources Security Policy, section 4.7: “They are locked and wiped through Kandji before reuse, and unreturned devices are wiped remotely within 24 hours of departure.”
OFF-15 · Kandji
If a device has not been returned, lock and wipe it remotely through Kandji. Leave blank when every device came back.
Owner
IT/Operations Lead
Due
Within 24 hours of departure (counted from the last working day)
Evidence
The Kandji remote lock and wipe record, or a note that every device was returned.
Policy: P18 4.7
- P18 Human Resources Security Policy, section 4.7: “They are locked and wiped through Kandji before reuse, and unreturned devices are wiped remotely within 24 hours of departure.”
OFF-16
Confirm that badges and materials are returned and that the person keeps no copies of company or customer data.
Owner
People Operations
Due
On the last working day (counted from the last working day)
Evidence
The person's signed or emailed confirmation, or the dated line on this checklist.
Policy: P02 5.8
- P02 Acceptable Use Policy, section 5.8: “On the last working day People Operations confirms that devices, badges and materials have been returned and that no copies of company or customer data are retained, and Engineering confirms that accounts are disabled and access removed on the timeline in the Access Control Policy.”
OFF-17
Verify the completed checklist and store it, with timestamps, in the personnel record.
Owner
Security Owner
Due
Within 1 business day of the last working day (counted from the last working day)
Evidence
This checklist with every step signed and dated, and the Security Owner's verification date.
Policy: P03 5.4, P18 5.6
- P03 Access Control Policy, section 5.4: “The checklist is completed on the last working day and verified by the Security Owner within one business day.”
- P18 Human Resources Security Policy, section 5.6: “The device is collected and wiped through Kandji, and the timestamped checklist is stored with the personnel record.”

How the checklists are built

From your systems. The identity provider, source control, each cloud console, CI/CD, password manager, device management and logging tool from your generator answers each get a step, and every vendor you listed gets its own “remove access” step on the offboarding checklist.
From your policies. Each deadline is read from the rendered Human Resources Security, Access Control, Acceptable Use and Endpoint and Workstation Security policies, and the sentence it came from is quoted with its section number. If no policy states a deadline for a step, the step says so instead of guessing.
Honest about your setup. If you said multi-factor authentication is not yet on every account, the MFA step records where it is enrolled and never says it is enforced. If you have no device management tool, the device steps are the manual checks your policy describes.
A tracker that does the date arithmetic. Enter a start date or last working day and each step’s due date appears, counted in business days where the policy says business days. A step turns red once its due date has passed with no completion date.

Related steps

Policy acknowledgments: the policy acknowledgment guide covers the form and what to keep.
Training within the deadline: the security awareness training pack gives you the session, the quiz and a completion tracker.
Leavers who were missed: the quarterly access review tool compares your user exports with a leavers list and flags accounts that are still active.

Free checklists and Audit Kit

The downloads on this page quote the policy template text, rendered from your answers. The Audit Kit includes the same three files in a people/ folder, built from your tailored policies instead, with the generation date and intake reference in the footers.

Frequently asked questions

What does SOC 2 require for onboarding and offboarding?: The criteria do not list steps. CC1.4 expects the company to hire and develop competent people, which auditors usually test with background checks and training records. CC6.2 expects access to be granted only after approval and removed when it is no longer needed, and CC6.3 expects access to follow the role. Your own policies turn those into specific steps and deadlines, and the auditor tests against what the policies say. These checklists list those steps for your systems.
How fast do we have to remove a leaver's access?: As fast as your policy says. The offboarding procedure in the generated Human Resources Security Policy (P18 5.6) reads: "Timing: identity disabled by the end of the last working day; all other access removed within one business day." For an involuntary departure it says immediately. If you change the deadline in the policy, the checklists and tracker follow it when you rebuild them.
What if we do not use an MDM tool?: Then the checklists do not pretend you do. The device steps become the manual baseline checklist before a laptop is issued, and a secure erase recorded on the offboarding checklist when it comes back, as the Endpoint and Workstation Security Policy describes for companies without device management.
Do contractors need the same checklist?: The generated Human Resources Security Policy says contractors, agency workers and vendor staff with access meet the same screening, acknowledgment, training and offboarding requirements as employees. Use the same checklist and mark them as contractors; where an agency screens them, keep its written confirmation as the screening evidence.
What does the Audit Kit version add?: The free checklists quote the policy template text rendered from your answers. In the Audit Kit, the policies are tailored to your tools and team first, and the people folder is built from that tailored text, with the generation date and intake reference in the document footers so the files trace back to the policy set they came from.
Is anything uploaded?: No. The generator keeps your answers in this browser's local storage, the policies are rendered here, and the checklists and tracker are built on your device. With no saved answers the page shows the sample company, Northwind Cloud Inc.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.