Join our Newsletter — 33% off our NHI Course

What should auditors expect to see for onboarding and offboarding evidence?

Auditors should be able to trace a request from creation through approval, execution, and removal or closure. If those lifecycle records are missing, incomplete, or scattered across teams, the organisation has not produced a credible access evidence chain.

What auditors expect to see in the access lifecycle record

Auditors are usually looking for an unbroken chain, not just a final approval or a closure ticket. They want evidence that the request was initiated, reviewed, approved by the right owner, implemented as intended, and then removed, expired, or formally closed when the need ended.

The strongest file is one that links those steps to a specific person or system, a date and time, a business reason, and the actual access change. If the record cannot show who asked, who approved, what changed, and when it was reversed, the evidence is weak even if the control existed in practice.

How onboarding evidence should be assembled

For onboarding, auditors expect to see the request source, the identity being provisioned, the access scope granted, and the approval path that justified it. That usually means a ticket or workflow record, plus supporting artefacts such as role assignment, entitlement details, provisioning logs, and any required manager or system-owner approval.

Good onboarding evidence also shows that the access granted matched the request and the role design. Where organisations use formal joiner processes, the most defensible record is one that shows the joiner flow from request to provisioning without relying on email threads or tribal knowledge. Auditors are less interested in the tool name than in whether the workflow is complete, consistent, and traceable.

If elevated or sensitive access was issued, the onboarding pack should show the extra control step that justified it, such as a narrower approval chain, a time limit, or a separate entitlement review. The practical test is whether a reviewer can reconstruct why the person or account received that access on that date.

How offboarding evidence should be assembled

For offboarding, auditors expect the mirror image of onboarding: a trigger for removal, a record of the action taken, and proof that access was actually revoked or the account was closed. The evidence should cover accounts, entitlements, tokens, keys, and any other active access paths that could survive the personnel or contract change.

The best offboarding records do not stop at “deactivated.” They show whether access was disabled immediately, whether secrets were rotated, whether delegated access was removed, and whether residual access was checked across connected systems. Where machine or application credentials are involved, lifecycle records should also capture deprovisioning and offboarding so the organisation can prove that access did not outlive the need for it.

Auditors also look for completeness across systems. A single HR exit record is not enough if the supporting evidence does not show revocation in the directory, SaaS platforms, privileged systems, and any downstream applications that inherited access. The control has failed if one orphaned account or forgotten token remains active.

Where access evidence commonly breaks down

Evidence usually fails when onboarding and offboarding are treated as operational tasks rather than controlled lifecycle events. Common weak points are missing approvals, inconsistent timestamps, duplicate records across teams, and removal evidence that proves a ticket was closed but not that access was actually revoked.

Another frequent failure is partial traceability. An organisation may have a request and an approval, but no execution log; or a deprovisioning ticket, but no confirmation that access was removed from all systems. In practice, auditors expect the evidence chain to be internally consistent and complete enough that a second reviewer could follow it end to end without guessing.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 PS-4 — Personnel Termination Covers documented removal of access when people leave.
AC-2 — Account Management Covers account provisioning, review, and deactivation evidence.
IA-5 — Authenticator Management Covers revocation or rotation of authenticators and credentials during offboarding.
Recommendation — Retain termination evidence that shows access was removed and accounts were closed. Track account lifecycle events from request through disablement or closure. Verify authenticator revocation or rotation when access ends.
ISO/IEC 27001:2022 A.5.16 — Identity management Requires controlled identity lifecycle evidence for joiners and leavers.
A.5.18 — Access rights Applies to evidence of granting, reviewing, and removing access rights.
Recommendation — Document identity lifecycle actions from provisioning through removal. Keep records that show access rights were approved and later withdrawn.

Practitioner Guidance

What to verify: Make sure every onboarding or offboarding case can be traced from request to approval to execution to closure, with the same subject, scope, and timestamps appearing across the records. If any step lives only in email, chat, or a separate team tracker, treat that as a documentation gap until it is reconciled.

What good looks like: A strong file contains the access request, approver identity, provisioning or revocation evidence, and a final confirmation that the resulting access state matched the intended outcome. For high-risk access, the file should also show who checked the revocation and whether any residual access paths were reviewed.

Common mistake: Teams often keep the request and approval but forget to retain the execution proof, especially for offboarding. That leaves auditors unable to distinguish between “we intended to remove access” and “we actually removed it.”

Practitioner takeaway: The evidence standard is not a stack of tickets, it is a coherent lifecycle narrative that proves access was both authorised and brought to the correct end state.