What SOC 2 onboarding and offboarding evidence must show
A company facing a customer or contract requirement for SOC 2 should ask one question early: will its joiner and leaver records hold up when an auditor samples them? The organization owns these controls. Its CPA firm tests them and issues the report, and no implementation partner can do either. Under CC6.2, the auditor checks that new users are registered and authorized before credentials are issued, and that credentials are removed once access is no longer authorized. Under CC6.3, the auditor checks that access is created, changed and removed according to approved roles. Those two criteria decide what gets sampled, so the records behind each new hire and each leaver need to exist, be dated, and show who approved what.
Cost and effort depend on a handful of drivers: headcount and turnover during the observation period, the number of systems that still keep local accounts outside the identity provider, contractor volume, and how much of the evidence is already system-generated. A company with most applications behind a single identity provider and a ticketed request workflow has far less manual collection than one where each tool issues its own logins. Before requesting a quote, confirm the number of joiners and leavers expected in the period, list every system that holds user accounts, and ask the implementation partner to state which records are generated automatically and which must be assembled by hand.
The reader should plan for the leaver side first, because it is the failure auditors find most often. A departed employee who still has a working account in a production tool, a shared repository or a cloud console is a visible exception, even if the account was disabled days later in a different system. Check that the HR or identity source of truth drives deprovisioning, that device recovery is logged against the same person, and that contractor accounts carry an end date set at approval. Where provisioning is automated from the identity provider, with connectors such as the SCIM provider in authentik or the account synchronization in midPoint, the evidence trail is easier to produce, but the team must still confirm that each connected system is covered and that exceptions are recorded.
What the onboarding and offboarding work costs and who is paid
This table separates the cost lines for joiner and leaver evidence by who is paid, whether the cost is one-time or recurring, and what drives it up. Read it as a checklist for the quote, since each line should appear separately in writing. The main takeaway is that the audit fee is recurring, while the workflow build is mostly one-time and the identity licence and staff time continue through every period.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Auditor testing of sampled joiner and leaver records | The CPA firm issuing the report | Recurring, once per audit period | Number of hires and leavers in the period, the sample size the auditor selects, and how complete the records are |
| Building the provisioning and deprovisioning workflow | Implementation partner or internal engineers | Mostly one-time, with optional retainer for changes | Number of target applications, whether SCIM is available, and how many role mappings must be defined |
| Identity platform licensing | Identity platform vendor or support provider | Recurring, usually per period | User count, enterprise feature tiers, and whether lifecycle or access certification features sit in a paid edition |
| Approvals, access reviews and device recovery by staff | Internal managers, HR, IT and the security owner | Recurring, every joiner and leaver | Volume of hires and exits, how many approvals are manual, and whether HR data feeds the identity system |
| Maintaining integrations after upgrades | Internal platform team or implementation partner | Recurring when a retainer is used | Number of connected systems and how often they change version or API |
| Evidence exports and walkthrough preparation | Internal staff, sometimes the implementation partner | Recurring, at audit time | Whether reports are system-generated and retained by default, or assembled by hand from tickets |
What makes joiner and leaver evidence cost more or less
Joiner and leaver evidence gets expensive when the same person's access lives in many places and each change is recorded by hand. The cards below cover the drivers that move that cost up or down, and the control decision that tends to change each one.
Headcount and turnover
Every hire and departure produces records the auditor may sample, so the volume of joiners and leavers during the observation period sets how much evidence you must produce. A stable team with few changes is cheap to evidence. A fast-growing or high-turnover company needs a repeatable ticket or workflow that produces the same record every time. Ask your CPA firm how many population items they expect to sample, and confirm your HR system can export a dated list of starters and leavers.
Systems with separate local accounts
Each application that keeps its own user list adds a grant, a revocation and a record to prove both. Five systems with local accounts means five places a leaver's access can survive. Federating applications to one identity provider collapses those steps into one disable action. Inventory every production system and mark which ones authenticate locally, because the unfederated list is where removal failures usually hide.
Contractor and vendor access volume
Contractors, consultants and managed service provider staff often hold accounts that outlive their engagements and sit outside the HR feed. Their access needs its own approval record, an end date and a removal step tied to the contract. CISA's advisory AA22-131A recommends limiting provider accounts to the systems they manage, auditing their use and disabling them when not in use or when the contract ends. Confirm who owns the contract end date and how that reaches the access team.
HR as the source of truth
When the HR system records start and end dates, provisioning and deprovisioning can follow those events instead of a manual ticket from a manager. This makes the leaver record date-stamped by a system the auditor can trust. If HR updates lag behind the actual last day, removal will lag too. Check how termination is entered, who enters it, and whether a missed update is caught by a reconciliation report.
Shared and service accounts
Shared logins and service accounts have no single owner, so removing a departing employee does not remove their access to them. Each one needs a named owner, a documented list of who knows its credentials, and a rotation step when someone leaves. Moving human access into individual federated identities and keeping shared accounts to a short, reviewed list reduces both the record-keeping and the risk. Inventory these accounts before the observation period starts, not during fieldwork.
Physical access and device recovery
Badge deactivation, office key return and laptop recovery each generate separate evidence under CC6.4, and devices often leave with the employee even when logical access is removed on time. Ask who collects equipment, how the return is logged, and how a device that is not returned is handled. Automated removal from the identity provider covers logical access only, so the physical and device steps need their own checklist with a signed or dated completion record.
How a joiner and leaver control moves from design to audit evidence
This sequence turns an onboarding and offboarding procedure into a control that runs the same way for every joiner and leaver, and leaves behind records an auditor can sample across the whole examination period. Each phase produces a named artifact that the next phase depends on.
Define access request and approval rules
The control owner, usually the people operations or IT lead, writes down which roles need which systems, who may approve each request, and what must exist before credentials are issued. Approval rules should name the approver for each role and state that no account is created until that approval is recorded. The output is an approved access matrix and a request workflow. You know this step is done when every role in the matrix has a named approver and the workflow can produce a ticket for each request.
Connect the identity provider to target applications
Engineers connect the organization's identity provider to the applications in scope, using federated sign-on where the application supports it and provisioning connectors where it does not. Each connection is tested with a non-production account to confirm that the application accepts the identity and applies the expected group mapping. Confirm with the vendor of each application which provisioning protocols it supports, because the options differ by product. The output is a list of connected applications with their connection method. The step is done when every in-scope application appears on that list.
Configure provisioning and deprovisioning rules
Engineers configure the rules that create, change and remove accounts from group membership, so that an approved request results in the right access and a removed request or termination results in its removal. Open-source options such as authentik's SCIM provider, which pushes user and group creations, changes and deletions to target applications over SCIM 2.0, or midPoint, which creates, updates and deletes accounts based on role assignments, can implement these rules. The output is a documented rule set with its configuration under version control. The step is done when the rule set is reviewed and approved by the control owner.
Run a test joiner and leaver
The team creates a test identity, assigns it a role through the approved request path, confirms the access appears in each connected application, then removes the identity and confirms access is withdrawn. The test should cover a deprovisioning path that does not depend on a person remembering to act, such as a status change in the source system. Record the timestamps and screenshots of each state, and store the results with the test plan. The output is a dated test record showing both transitions. The step is done when the leaver test shows access removed in every connected application.
Collect tickets and system logs for the audit period
Across the whole examination period, the team exports approval tickets, provisioning and deprovisioning logs from the identity provider, and application-side records that show the account state. Records should be system-generated where possible and linked to the matching request so an auditor can trace one joiner or leaver from approval to removal. Gaps, such as a leaver whose access was removed after the agreed process, should be documented with their cause and correction. The output is a complete population of joiner and leaver events with supporting records. The step is done when the population can be reconciled against the HR starter and leaver lists.
Hand the evidence package to the CPA firm
The team assembles the population, the sample-ready records, the control description and the test records into an evidence package, then provides it to the CPA firm on the auditor's request list. The CPA firm samples from the population, tests each selected item and issues the report. DeployOpen prepares systems, controls and evidence but does not issue the report or opinion. Agree in advance how the auditor will access the records, and confirm the format and transfer method in writing. The output is a delivered package with an index. The step is done when the auditor confirms receipt and has no outstanding requests on this control.
Automating provisioning with authentik and midPoint
Automation is the strongest way to make joiner and leaver records consistent, because a directory change can drive account creation and removal in every connected application without relying on a person to remember each step. In a self-hosted stack, authentik's SCIM provider is the usual starting point for applications that accept SCIM 2.0. It pushes user and group creations, changes and deletions to the target application, runs a full sync every hour, and deprovisions a user from the target when that user loses access to the application. The SCIM provider's settings are documented in authentik's SCIM provider guide, which the team should read alongside its own application list.
For systems that do not speak SCIM, midPoint covers the gap. It creates, updates and deletes accounts on connected systems based on user changes and role assignments, and keeps them aligned through provisioning, live synchronization and scheduled reconciliation. Its inbound and outbound rules are defined separately, so the team must decide which system is authoritative for each attribute. Reconciliation is the step that catches accounts changed outside the pipeline, which is exactly the drift an auditor looks for when sampling leavers. The midPoint synchronization documentation explains how these modes fit together.
Before relying on either tool, confirm which connectors your applications support, whether through SCIM, a native connector or an API you must build. Gaps found at this stage are cheaper to close than gaps found in fieldwork. Automation does not replace the records SOC 2 asks for. Each provisioning path still needs an approved access request, and the team should review automated grants and removals periodically to confirm that the rules still match the approved roles. Keep the rule definitions, sync logs and exception tickets as evidence, because the auditor will test the design and the operation of the pipeline, not only the tool's configuration.
Choosing an approach by how many apps and accounts you run
Applications that accept SCIM 2.0 provisioning can be fed directly from your identity provider. When an employee is hired, granted a group, or removed, the identity provider sends that change to the application, and the application's account state follows without a person touching it. For SOC 2 this is the strongest pattern because the identity provider's audit log becomes the record of who was approved, when access was granted and when it ended. Authentik's SCIM provider, for example, pushes user and group creations, changes and deletions to target applications, runs a full sync every hour and deprovisions users who lose access to the application (illustrative of the pattern, not a claim about your stack).
- Confirm the SCIM version and operations: Check whether the target supports SCIM 2.0 and which operations it accepts, such as create, update, deactivate and delete.
- Check deletion behavior: Some applications deactivate accounts instead of deleting them. Your evidence should show the account is disabled, not merely unlinked.
- Test the sync interval: A scheduled sync sets the upper bound on how long a leaver keeps access. Record that interval as part of the control description.
- Keep group mappings reviewed: Group-to-role mappings decide what a new joiner receives, so they belong in your change records.
- Export the logs: Keep provisioning logs from both the identity provider and the target for the audit period.
Before relying on any SCIM target, confirm its capabilities with the vendor and test a joiner and a leaver in a non-production instance.
Many applications, especially older internal tools, appliances and some database or network platforms, keep their own user store and do not accept SCIM. For these you have three choices: a connector that reads from or writes to the application's interface, an integration that federates login through single sign-on while still leaving a local account behind, or a documented manual step with a ticket. Identity governance platforms such as midPoint can create, update and delete accounts on connected systems from user changes and role assignments, and keep them aligned through reconciliation. Connectors are not available for every target, so the choice depends on the application.
- Find every local account store: Inventory applications that hold their own credentials, including break-glass and service accounts.
- Prefer a connector with a reconciliation job: Scheduled reconciliation finds accounts that were created outside the process.
- Write the manual procedure: Where no connector exists, define who removes the account, the deadline, and the ticket that closes the step.
- Pair removal with evidence of completion: Screenshots of a disabled account are weaker than a system report showing the account state at a point in time.
- Review federation gaps: A user who leaves the identity provider may still have a working local password, so check for that path.
Confirm whether each target can disable accounts, not just delete them, and whether its API or connector covers the operations you need.
Vendors, contractors, managed service providers and their staff often hold accounts in your environment, and they are the accounts most likely to be forgotten. CISA advisory AA22-131A, *Protecting Against Cyber Threats to Managed Service Providers and their Customers*, advises customers to limit MSP accounts to the systems the MSP manages, audit their use, and disable them when they are not in use or when the contract ends. It also recommends regularly tested, isolated backups. Those steps map naturally onto joiner and leaver evidence: the scope of each account, the record of its use and the date it was disabled.
- Limit scope per account: Record which systems each third-party account can reach, and remove access beyond the contracted systems.
- Tie accounts to contracts: Store contract end dates alongside the account record so disabling happens on the contract date, not when someone remembers.
- Audit use regularly: Keep logs of sessions and privileged actions that show the account was used for approved work.
- Disable idle accounts: Set a recurring review that disables accounts not used within a period your policy defines.
- Include staff of the vendor: Track the individuals behind shared or vendor-owned accounts, and avoid shared credentials where you can.
Confirm with each vendor how it manages its own staff's access to your systems and what evidence it can provide, since the vendor's controls may also appear in your vendor management records.
What to have in place before the auditor samples your leavers
An auditor samples recent hires and leavers and asks for the record behind each one. The six items below are the records that make that sample easy to trace, and each one can be checked against a small sample of recent joiners and leavers before fieldwork starts.
Written joiner and leaver procedure
A short, dated procedure that states who starts an onboarding or offboarding request, which systems each role receives, and the deadline for removing access after a departure. Auditors test the procedure against the behavior they sample, so the steps in it must match what staff actually do. To check it, pick five recent hires and five recent leavers and confirm each one followed the written steps, noting any step that was skipped or done by a different route.
Named approval step and approver
Access to protected systems should be authorized by a named person before credentials are issued, which is the behavior CC6.2 asks an organization to show. Record who approved each grant, when, and for which roles, so the approval comes before the account exists. To check it, confirm for each sampled hire that the approval date precedes the account creation date and that the approver held authority over that system.
Single source of truth for employment status
One system, usually the HR platform or the identity provider, should hold the authoritative start and end dates for each person. Downstream accounts follow that record, so a leaver cannot be missed because a manager sent an email. To check it, compare the termination date in HR with the disabled date in the identity provider for each sampled leaver and explain any gap.
Inventory of systems and account owners
Keep a list of every application, cloud account, repository and shared credential that holds company or customer data, with a named owner for each. Without that list, a leaver's account in a forgotten tool can survive the offboarding step. To check it, take three sampled leavers and confirm every system they used appears on the inventory and that the owner removed their access.
Device return checklist
Laptops, phones, badges, tokens and removable media issued to staff should be returned or wiped on a checklist signed by the manager and IT. Physical access points under CC6.4 are tested the same way as logical access. To check it, confirm each sampled leaver has a completed checklist, a return or disposal record for each issued device, and a badge deactivation date.
Dated record of each removal
For every leaver, keep a timestamped record showing each account disabled, each group membership removed and each device recovered, with the person who performed the action. An auditor who cannot see the removal date cannot test timeliness. To check it, pull the logs for a sample of leavers and confirm that each removal has a date, an actor and a matching ticket or automated event.
Who owns the control, who builds the workflow and who tests it
The organization owns CC6.2 and CC6.3 in full. Management decides who may hold access, who approves each request, how quickly leavers lose access, and who answers for exceptions. None of those decisions can be delegated to a consultant or a tool. The auditor will ask who designed the control, who operates it and who reviews it, and the answers must name people inside the company.
- Approval authority: Name the approvers for each role, such as the hiring manager for standard access and a system owner for privileged access.
- Written procedure: Document the joiner and leaver steps, the deadlines and the exception path, and keep the procedure current.
- Operating records: Someone inside the company must run the control every period and retain the tickets, approvals and removal records.
- Accountability for exceptions: Decide who signs off when a leaver's access stays open past the deadline and how that gets logged.
- Ownership of the policy: The access and personnel policies sit with management, not with the partner.
Before engaging anyone, confirm that a named employee can explain the control end to end without notes.
An implementation partner can configure the identity provider, connect target applications, set up provisioning and deprovisioning, and build the export jobs that produce evidence. This is systems work, and it is where most of the effort in an engagement sits. The partner does not approve access, decide who leaves or sign off on the control. Those steps stay with the organization, and the workflow should record who approved what.
- Identity provider configuration: Set up single sign-on, group structures and role mappings in the chosen identity platform.
- Automated provisioning: Configure SCIM or connector-based account creation and removal for the applications in scope.
- Evidence exports: Build scheduled reports of joiners, leavers and access lists that the organization can hand to the auditor without editing.
- Documentation of configuration: Provide runbooks and configuration records that describe how the workflow behaves.
- Hand-off and training: Transfer administration to named staff so the control runs after the engagement ends.
Ask the partner which parts of the workflow remain manual and which system is the source of truth for the approval record.
Only an independent CPA firm can test the controls and issue a SOC 2 report. The auditor selects samples from the period, requests the supporting records and forms an opinion. This independence is what gives a report value to customers, so the organization and its partner must stay out of the auditor's judgment. Helping prepare evidence is acceptable; deciding whether the control worked is not.
- Sample selection: The auditor picks joiners and leavers from the period and asks for the approval and removal records for each.
- Timing tests: The auditor compares the approval date with the credential issue date, and the leaver date with the removal date.
- Independence boundary: Confirm in the engagement letter that the firm will not design or operate the controls it tests.
- Access to evidence: Agree early on which systems the auditor may view directly and which exports it will accept.
- Report ownership: The CPA firm issues the report. The partner does not issue attestations, and the organization does not write its own opinion.
Ask the audit firm how it wants evidence delivered before the workflow is built.
Responsibilities are usually shared, and the split is easiest to see in a table of activities. Work that prepares the environment can be outsourced. Work that creates the authority behind the control stays inside. The illustrative split below shows a common pattern, not a fixed rule.
- Usually kept in-house: Approving access, deciding urgency, signing exceptions and reviewing the leaver log.
- Often outsourced: Connector configuration, SCIM setup, scheduled exports and runbook writing.
- Shared work: Testing the workflow against a sample joiner and leaver before the observation period starts.
- Auditor-only work: Sampling, testing and forming the opinion on operating effectiveness.
- Scope agreements: Define the applications in scope and the owners of each in a written scope before work starts.
Review a draft RACI with the organization, the partner and the audit firm before fieldwork begins.
Questions buyers ask about joiner and leaver evidence
Does SOC 2 require a specific onboarding or offboarding tool?
No. SOC 2 does not name a product or require a particular identity platform. The auditor tests whether your controls work and whether you can show evidence that they operated during the period. A spreadsheet, a ticketing workflow or an identity provider can all support the control, provided the approvals, removals and device returns are recorded and retrievable. Tooling mainly affects how much manual effort the evidence takes and how easily it can be pulled for sampling. Confirm with your CPA firm which evidence formats it accepts before you build the process around one tool.
How long does it take to set up joiner and leaver controls?
The duration depends on scope and systems, so it should come from the written scope rather than a general rule. The main drivers are how many applications hold customer or production data, whether an identity provider already exists, how many HR and IT handoffs must be defined, and whether provisioning will be automated or handled by tickets. A narrow scope with one identity provider and a few applications is quicker than a broad estate with many local accounts. Ask any implementation partner to list the systems in scope, the deliverables for each and the dates they depend on, and confirm those items in writing before work starts.
Can a small team handle joiner and leaver evidence without outside help?
Often yes, if one person owns the process and the team keeps the records consistently. A small company needs a written procedure, a named approver for each access request, a checklist for leavers and a place where every record is stored. The harder part is discipline during the observation period, because an auditor will sample real joiners and leavers, not the ones you prepared for. Outside help is most useful for designing the control set, configuring automated deprovisioning and running a readiness review before the examination. An independent CPA firm, not the consultant, issues the report.
What do HR and IT each need to provide for leaver and joiner records?
The control only works when HR and IT share a common trigger and a common record. HR should confirm start dates, role changes and termination dates in a system of record, with the time of each event captured. IT should record who approved each access grant, which systems were granted, when credentials were issued and when access was removed. Facilities or IT should record device returns and the date they were received. Define who is responsible for each step, how long each step may take, and what happens when a termination is recorded late. Without that handoff, the auditor cannot tell whether removal was timely.
How many joiner and leaver records will the auditor sample?
The sample size is set by the CPA firm under its testing approach, and it can depend on how often the control runs and the size of the population during the period. Do not plan around a fixed number from a blog post. Ask the CPA firm, before fieldwork, how many joiners and leavers it expects to select, what period the population covers, and which records it will need for each item. Then confirm that your records can be produced for every person in the population, not only those you remember. Complete and consistent records matter more than a clean sample, because gaps are what auditors report.
What happens if a leaver's access was not removed on time?
A late removal is treated as a control deviation, and the auditor records it as an exception. In a Type 2 examination, exceptions are reported with management's explanation of the cause and any corrective action. The report is not automatically qualified because of one exception, but repeated or unexplained failures can change the opinion. The practical response is to find out whether the credential was used after the termination date, document that review, remove the access, and fix the cause, such as a missed handoff or a missing automated rule. Disclose the exception to the auditor early rather than letting it surface during sampling.
Can an identity provider automate deprovisioning for SOC 2 evidence?
Yes, it can reduce the manual steps and produce system records, but it does not remove the need for a documented process. For example, the authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour and deprovisions users from the target when they lose access to the application. midPoint creates, updates and deletes accounts on connected systems based on user changes and role assignments. Confirm with each vendor which connectors your applications need and how sync events are logged, because the auditor will still ask how the trigger and the removal are tied together.
Which access must be removed when a contractor or vendor account leaves?
Any account a contractor or vendor uses to reach your systems falls under the same expectation as an employee account. Guidance from CISA advisory AA22-131A recommends limiting managed service provider accounts to the systems they manage, auditing their use and disabling them when not in use or when the contract ends. Build the same logic into your offboarding: list shared administrator accounts, service accounts with personal credentials and vendor support access, and assign an owner to each. Confirm that the contract end date triggers removal, and keep the ticket or record that proves it happened.
How DeployOpen prepares joiner and leaver evidence
DeployOpen is a Chainscore Labs company that plans, implements and hardens self-hosted open-source identity and provisioning platforms inside your own cloud accounts, data centers or air-gapped networks. For joiner and leaver evidence, that work usually means configuring the identity provider as the single source of truth for who holds access, wiring it to the applications in scope, and setting up the logs and records an auditor will sample. The organization still owns its controls, its access decisions and its policies. DeployOpen prepares the systems and the evidence trail so that your team can show an approval happened before credentials were issued and that access was removed on time.
Scope, deliverables and timelines are agreed in writing before any work starts, so the boundaries are clear from the outset. Typical written scope items for this topic include which applications are connected to the identity provider, which provisioning rules and group mappings are built, which leaver steps are automated and which remain manual, and what records the client receives at handover. Ask for those items to be listed by name in the quote. DeployOpen does not publish a price list; a quote follows from the written scope, so the more precisely your application inventory and HR source are described up front, the more reliable that quote will be. DeployOpen prepares systems and evidence but does not issue audit reports, attestations or certifications. Only an independent CPA firm performing the SOC 2 examination can do that. Ongoing support, upgrades and periodic review of joiner and leaver configurations are available as a retainer, which suits teams whose headcount changes often or whose application estate keeps growing. Before engaging, confirm with your CPA firm which evidence samples they will request, so the handover records match what they will test.
