Compliance
SOC 2 and ISO 27001 offboarding requirements: what auditors check
Updated · 9 min read
Neither SOC 2 nor ISO 27001 hands you an offboarding checklist. Both expect you to define how access is removed when someone leaves, do it consistently, and prove it. Most offboarding audit findings are not about missing policy. They are about missing evidence: a leaver whose account stayed active, or a removal nobody can show happened on time.
This guide explains which controls apply, how auditors actually test them, and what evidence to keep so a sample of departures holds up.
Which SOC 2 criteria cover offboarding
SOC 2 reports are organised around the AICPA Trust Services Criteria. Offboarding falls mainly under the logical access criteria in the Common Criteria (CC6 series).
- CC6.2: user credentials are registered and authorised before access is granted, and removed when access is no longer authorised. This is the criterion most offboarding tests map to.
- CC6.3: access is authorised, modified, and removed based on roles and responsibilities, which covers role changes as well as departures.
- CC6.1: logical access security over in-scope systems in general, which is where identity provider and SSO controls usually sit.
SOC 2 does not set a deadline for removing access. Your own policy does (for example "access is removed within one business day of the termination date"), and the auditor tests you against it. Pick a timeframe you can meet every time.
Which ISO 27001 controls apply
ISO/IEC 27001:2022 lists its controls in Annex A. The ones auditors most often look at for leavers are:
- A.5.18 Access rights: provisioning, review, modification, and removal of access to information and systems.
- A.6.5 Responsibilities after termination or change of employment: security duties that stay in force after someone leaves, communicated to them.
- A.5.11 Return of assets: equipment and information assets are returned when employment or a contract ends.
- A.8.2 Privileged access rights: admin and privileged accounts, which deserve the fastest removal.
- A.6.6 Confidentiality or non-disclosure agreements: agreements that continue to apply after departure.
How auditors test offboarding
The test is usually the same for both frameworks. The auditor pulls the list of people who left during the audit period from your HR system, picks a sample, and asks you to show, for each one, when access was removed from each in-scope system.
- 1
Termination list from the HR system
The population comes from HR, not IT, so contractors and people who never had a ticket raised are included.
- 2
Termination date for each person in the sample
This is the clock your removal policy is measured against.
- 3
Removal evidence per system
Timestamps showing the identity provider account and every in-scope application account were disabled or deleted, and by whom.
- 4
Comparison against your policy
Any removal later than your stated timeframe, or any account still active, becomes an exception in the report.
- 5
Supporting controls
Periodic user access reviews, asset return records, and signed confidentiality acknowledgements are often reviewed alongside the sample.
The evidence to keep for every departure
Screenshots taken months later rarely satisfy an auditor. Evidence created at the moment of removal, with a timestamp and an actor, does.
- The HR termination record and the date access removal was requested.
- A per-system record of what was revoked, when, and by whom, including systems outside single sign-on.
- Proof that failed or partial removals were followed up, not just the successful ones.
- Asset return confirmation for laptops, tokens, and badges.
- Signed or acknowledged confidentiality obligations where your policy requires them.
- The results of your periodic access review, which catches anything the offboarding process missed.
Common offboarding audit findings
- An account in a SaaS tool that is not connected to single sign-on stays active after the identity provider account is disabled.
- Removal happened, but later than the policy timeframe because IT learned about the departure days after HR did.
- A contractor never appeared on the HR termination list, so nobody started their offboarding.
- A revocation script or ticket was marked complete even though one system returned an error.
- Shared or service credentials the person knew were never rotated.
How PurpletGo produces this evidence
PurpletGo records offboarding evidence as the work happens instead of rebuilding it before an audit. Each revocation is written with the system, the result, the time, and the admin who ran it.
- A result for every selected system (revoked, failed, or needs manual action), with the vendor error reason for failures. Retrying only re-runs what failed.
- An audit log of every offboarding action with actor and timestamp, exportable as CSV and as a PDF case report on every plan.
- Pre-built SOC 2, ISO 27001, HIPAA, GDPR, and PCI DSS control lists, with auto-collected evidence from revocation results and offboarding events and an exportable report (Team plan and up).
- A tamper-evident audit log where each entry is cryptographically chained to the previous one, with on-demand verification (Team plan and up).
- Offboardings opened automatically from BambooHR, Workday, Rippling, Gusto, or ADP (beta) terminations during the nightly sync (Team plan and up), so IT is not the last to know.
30-day free trial - no credit card required