Introduction
Employee onboarding and offboarding evidence for SOC 2 is the dated record that shows how access, devices, and related controls were granted when someone joined or changed roles, and how they were removed when someone left: HR triggers, provisioning approvals, role assignments, MFA enrollment, asset issuance and return, and timely deprovisioning across the identity provider and in-scope apps.
Most teams onboard and offboard people somehow. The audit gap is usually the trail. A hire starts on Monday with Slack and email, picks up production access mid-week through a chat ping, and months later an auditor asks for the ticket that authorized that access and the timestamp when the leaver was disabled in the identity provider. "We usually do that" is not evidence.
Here is a concrete example. A new engineer is hired. Strong evidence includes an HR start date, an access request or workflow that names roles, manager or system-owner approval before production rights are granted, MFA enrollment before privileged paths open, a laptop enrollment record, and (later) a termination ticket that disables IdP access the same day employment ends, with app access and asset return checked off. Weak evidence is a welcome email and an undated screenshot of an active account.
In plain language: this guide is a joiner-mover-leaver evidence playbook. It is not a second definition of user access review, and it is not a repeat of the periodic attestation how-to (How to Run a SOC 2 User Access Review) or the Role-Based Access Control Evidence for SOC 2 catalog playbook. Those pages cover reviews and role design. This page covers the hire-to-terminate lifecycle tickets and timeliness records auditors sample.
What Onboarding and Offboarding Evidence Means
Onboarding evidence proves that new or changed access was authorized, scoped, and completed with the right prerequisites (such as MFA and training where your policy requires them). Offboarding evidence proves that access and assets were removed within your defined time window when employment or engagement ended.
A complete lifecycle file for a sampled hire or termination usually answers:
- What triggered the change (HR event, contract end, role change)?
- Who approved which access before it was granted?
- Which roles and systems were provisioned, and when?
- Were MFA, device, and other prerequisites completed?
- When the person left or moved, what was revoked, by whom, and how fast?
- Were assets returned and lingering accounts checked?
How This Guide Differs From Related Pages
| Page | Primary job | Use it when |
|---|---|---|
| What Is a User Access Review? | Defines periodic entitlement attestation | You need the concept of a review |
| How to Run a SOC 2 User Access Review | How-to for review packets and sampling | You are running a quarterly or annual review |
| Role-Based Access Control Evidence for SOC 2 | Role catalog, matrix, and assignment design evidence | You need to prove the role model |
| What Is Least Privilege? | Defines granting only needed access | You need the principle behind scoped roles |
| What Is Logical Access? | Defines access to systems and data via logical means | You need the broader access concept |
| This guide | Joiner-mover-leaver tickets, timeliness, and Type 2 samples of hires and terminations | You need the lifecycle evidence playbook |
What SOC 2 Requires vs Common Practice
Keep the criteria and your chosen practices apart.
What the criteria address. The AICPA 2017 Trust Services Criteria with revised points of focus (2022) include themes that joiner-mover-leaver controls commonly support:
- CC6.2: registering and authorizing new users before issuing credentials and granting access, and removing access when it is no longer authorized.
- CC6.3: authorizing, modifying, or removing access based on roles and responsibilities, considering least privilege and segregation of duties.
- Related logical access and credential themes under CC6.1 and neighboring criteria depending on your system description.
Points of focus are illustrative. SOC 2 does not prescribe a specific HRIS, ticketing tool, or same-day SLA by name.
What is common practice, not a fixed SOC 2 rule:
- Same-day or 24-hour disablement of identity provider access on termination
- Manager approval for every application (some programs use role-based auto-provisioning with exception approvals)
- A specific checklist length or tool (Jira, ServiceNow, Okta Workflows, and others all appear in the wild)
- Collecting a laptop before disabling accounts (order can vary; record what you did)
If your policy says production access requires approval before grant, and terminations disable IdP access within one business day, the evidence must show that for sampled events.
Related NIST account-management themes appear in NIST SP 800-53 Rev. 5 (for example AC-2 style account management expectations). Use them as design input; map carefully to your asserted controls.
The Lifecycle File at a Glance
| Lifecycle step | What to keep | Stronger evidence | Weaker evidence |
|---|---|---|---|
| HR trigger | Start, role change, or termination record | Dated HRIS event or ticket with effective date | Verbal "they start Monday" |
| Access request / plan | Roles and systems requested | Ticket naming roles tied to job function | Chat "give them Engineer-Admin" |
| Approval | Approver, decision, timestamp | Manager or system owner approval before grant | Approval after access already existed |
| Provisioning | IdP and app account creation | Logs or ticket steps with timestamps | Undated screenshot of an active user |
| MFA / prerequisites | Enrollment before privileged access | Enrollment export or checklist with time | MFA "reminded them later" |
| Device / asset | Issue and return | Asset tag, enrollment, return receipt | No record of the laptop |
| Mover changes | Old roles removed, new roles granted | Role swap ticket with before/after | Old production role kept "just in case" |
| Offboarding | Disable, revoke, transfer ownership | IdP disable timestamp vs last day; app checklist | Account lingered until next access review |
| Exceptions | Late disable or standing access | Documented exception with owner and expiry | Silence about the delay |
Onboarding Evidence in Detail
1. Trigger and identity creation
Start from an authoritative HR or contractor record: legal name or unique ID, start date, manager, department, and employment type. Create the identity in the identity provider from that trigger when possible, so the joiner trail is not a freehand admin console create.
2. Role and access plan
Map the job to roles from your catalog, not a copy of a teammate's over-permissioned account. See Role-Based Access Control Evidence for SOC 2 and least privilege. Privileged roles should be called out explicitly.
3. Approval before grant
Record who approved which access before provisioning, especially for production, finance, customer data, and admin roles. Workflow approval patterns apply: right approver, independence where required, timestamp before the grant.
4. Provisioning execution
Prefer automated group or role assignment from the approved plan. Keep logs or ticket steps that show when each system was granted. For apps outside SSO, keep a checklist of local accounts created.
5. MFA and secure authentication
Enroll multi-factor authentication before privileged paths open when your policy requires it. Retain enrollment evidence tied to the user and date.
6. Device and endpoint
Issue a managed device when that is your standard. Keep enrollment or asset records. If BYOD is allowed for some roles, keep the exception and the controls that apply.
7. Training and policy acknowledgement (when in policy)
If security awareness or policy acknowledgement is required before or shortly after start, keep completion records. See policy acknowledgement, Policy Acknowledgement Evidence for SOC 2, and Security Awareness Training Evidence for SOC 2.
Mover Evidence
Movers create as many findings as leavers. When someone changes team or seniority:
- Grant new roles through the same approval path as joiners.
- Remove prior roles deliberately; do not accumulate.
- Update shared mailbox, vault, and cloud project ownership if the old role required it.
- Record the effective date of the change.
A mover who keeps old production admin "for a few weeks" without an expiry is a standing privilege exception. Treat it like exception management, not a casual delay.
Offboarding Evidence in Detail
1. Trigger and last day
Capture the termination or contract-end event, last day, and whether access should end at end of day, immediately, or at another defined time (for example involuntary termination).
2. Identity provider disablement
Disable or delete according to policy, and retain the timestamp. Compare it to the last day. This is often the first sample auditors pull.
3. Downstream apps and non-SSO accounts
Revoke SSO-connected apps through IdP group removal when that is enough. For local accounts, API keys, and vendor portals, keep a checklist with completion times. Transfer ownership of shared resources.
4. Privileged and break-glass paths
Confirm the leaver is not in admin groups, root aliases, or emergency access lists. Rotate any shared secrets they could have known.
5. Devices, badges, and tokens
Record laptop return or remote wipe, badge deactivation, and hardware token return. Order can vary by risk; document what happened and when.
6. Communication and data handoff
Where relevant, forward email or transfer document ownership so business continuity does not require leaving the account active.
Timeliness: What "Fast Enough" Means
SOC 2 does not publish a universal "must disable within X hours" number. Your written control does.
Common practice patterns:
- Involuntary terminations: disable critical access immediately or within a short defined window.
- Voluntary terminations: disable by end of last day or within one business day, per policy.
- Contractors: end access when the engagement ends, not when someone remembers.
Evidence should show the delta between the effective end and the IdP disable timestamp. Large unexplained gaps become findings. If there was a delay, record why, who accepted the risk, and what compensating steps applied.
Example Scenario
A labeled hypothetical: a 40-person SaaS company hires a backend engineer and, six months later, that engineer resigns.
Onboarding file contains:
- HRIS start record and manager
- Access ticket requesting Engineer (non-prod) and temporary production read role, approved by engineering manager before grant
- IdP provisioning log and GitHub org invite timestamps
- MFA enrollment completed day one before production read was enabled
- Laptop enrollment in device management
- Security awareness completion within the policy window
Offboarding file contains:
- Resignation with last day Friday
- IdP account disabled Friday 5:12 PM ET
- GitHub, cloud, and vault group removals on the same ticket with timestamps
- Laptop returned Monday with asset receipt; remote lock recorded Friday evening as a compensating step
- Shared on-call calendar and runbook ownership transferred Thursday
During a Type 2 audit, both events are sampled. Every question about authorization, prerequisites, and timeliness has a dated answer.
Type 1 vs Type 2 Considerations
For a Type 1 report, auditors look at whether joiner-mover-leaver controls are suitably designed and in place at a point in time. Current procedures, templates, and a recent hire or termination file support that.
For a Type 2 report, auditors test operation over the period. They often sample hires, terminations, and movers from across the window and compare HR dates to IdP and app timestamps. A cleanup the week before fieldwork does not replace period history. See SOC 2 Type 1 vs Type 2 and What Is SOC 2 Evidence?.
Common Mistakes
- Cloning a peer's access instead of assigning scoped roles
- Approving access after it was already granted
- MFA enrollment delayed until after privileged access is live
- Movers who accumulate roles across teams
- Leavers whose IdP access lingers for days or weeks
- Disabling SSO but leaving local admin accounts and API keys
- No checklist for non-SSO vendor portals
- Shared passwords that survive the leaver
- Relying on the next user access review to catch offboarding failures
- Undocumented exceptions for "friendly" late disables
These patterns create findings and real incident risk. See Exception Management and Audit Findings Remediation.
Operating Model: Make Joiner-Mover-Leaver Repeatable
1. Write the SLAs and owners
Name who watches HR triggers, who approves privileged access, and what "timely" means for disablement.
2. Use one ticket template per event type
Standard fields: person, effective date, roles requested or revoked, approver, systems checklist, MFA, device, exceptions.
3. Prefer automation with human approval where needed
Auto-provision baseline roles from HR where risk allows. Require explicit approval for privileged paths.
4. Tie roles to a catalog
Do not invent access ad hoc. Connect to your RBAC catalog (Role-Based Access Control Evidence for SOC 2).
5. Measure timeliness
Track time from termination effective time to IdP disable. Review outliers monthly.
6. Include contractors and vendors with system access
Apply the same discipline to non-employees who reach production. See vendor management themes when the person is a third party.
7. Connect to access reviews
Lifecycle controls catch day-zero and day-exit events. Reviews catch drift in between (How to Run a SOC 2 User Access Review).
8. Dry-run before fieldwork
Sample 3 joiners, 3 leavers, and 2 movers from the period. Fix process gaps, and record any late items honestly.
Evidence Examples by Scenario
| Scenario | Stronger evidence | Weaker evidence |
|---|---|---|
| New hire baseline access | HR trigger, approved role plan, IdP create log, MFA enrollment | Admin created user from memory |
| Privileged grant on day 3 | Separate approval, time-bound role, expiry | Standing Admin because "they might need it" |
| Internal transfer | Role swap removing old team permissions | Old and new production roles both active |
| Voluntary termination | IdP disable same day, app checklist complete | Disabled a week later after reminder |
| Involuntary termination | Immediate IdP disable, remote wipe, secret rotation | Waited for laptop return before disabling |
| Contractor end date | Access ends on contract end date automatically or by ticket | Contractor account still active months later |
| Service account owned by leaver | Ownership transfer and key rotation recorded | Ownerless bot with production rights |
Linking Lifecycle Evidence to Neighboring Controls
- Logical access and access control. Onboarding and offboarding are how logical access and access control operate for people.
- Least privilege and RBAC. Scoped roles make joiners safer and leavers cleaner.
- MFA. Enrollment and de-enrollment are part of the same lifecycle.
- Workflow approval. Privileged grants need recorded approvals.
- Monitoring. Alerts on admin grants and re-enabled accounts catch failures.
- Access reviews. Periodic reviews should not be your only offboarding control.
- Security awareness and policy acknowledgement. Completions often ride the onboarding checklist.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For onboarding and offboarding, that can mean dated history for access request tickets, approvals, and related workflow steps so you can show when access was granted or revoked without rebuilding the story from chat. Your HRIS, identity provider, and ticketing tools remain the systems of record for employment events and account state. AuditFlo does not provision or deprovision users, does not replace your identity provider, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Final Thoughts
Employee onboarding and offboarding evidence is the proof behind joiner-mover-leaver controls: HR triggers, approved access plans, provisioning with MFA and device prerequisites, deliberate mover role swaps, and timely deprovisioning with checklists for non-SSO systems and assets. SOC 2 does not dictate your exact SLA or tool, so write the rules, follow them, and keep timestamps that survive Type 2 sampling. Keep this playbook distinct from access review packets and RBAC catalog evidence, and connect all three so auditors hear one coherent identity story.
If you are building the broader readiness path, start with How to Run a SOC 2 User Access Review, Role-Based Access Control Evidence for SOC 2, What Is Least Privilege?, What Is Logical Access?, What Is SOC 2 Evidence?, and how to prepare for a SOC 2 audit.
FAQ
Is same-day offboarding required for SOC 2?
SOC 2 does not set a universal same-day rule. Your policy defines the window. Many teams target end of last day or one business day for voluntary exits, and faster for involuntary exits. Evidence should show you met your written control.
How is this different from a user access review?
Access reviews attest that current access is still appropriate on a schedule. Onboarding and offboarding evidence proves access was granted and removed correctly at employment events. You usually need both. Reviews should not be the only way leavers lose access.
What should we sample before the auditor arrives?
Sample several joiners, movers, and leavers from the audit period. Compare HR effective dates to IdP and app timestamps, confirm approvals preceded privileged grants, and confirm MFA and device steps when required.
Do contractors follow the same process?
If contractors reach in-scope systems, yes in substance: authorized access, scoped roles, timely removal. Label them clearly in tickets and inventories.
What if we disabled a leaver late?
Record the fact, the reason, the residual risk acceptance, and the fix to process. Hiding the gap is worse than an honest exception with remediation.
Can RBAC automation replace onboarding tickets?
Automation can execute an approved role plan and still leave an audit trail. You still need a defined plan, approvals for privileged roles, and records for exceptions and non-SSO systems.
Does AuditFlo onboard or offboard employees?
No. AuditFlo helps organize dated evidence from systems you already use. It does not create or disable accounts and does not replace your auditor.