Access Control Policy Template: Joiner, Mover, Leaver Procedures and Audit Evidence

Overview

Access control is not only a technical configuration. It is a repeatable governance process for deciding who may access which systems, why that access is needed, how long it should remain active, and who approves changes. A useful policy should cover workforce accounts, contractors, administrators, service accounts, remote access, applications, infrastructure, and sensitive data.

Your policy should identify an owner, define approval authority, describe the systems in scope, and establish a review schedule. It should also connect to related documents, such as your security policy suite, data retention policy, incident response plan, and privacy procedures. Where access involves personal data, the organization should be able to explain why access is necessary and how it supports an authorized business purpose.

Use the following policy statement as a starting point:

“Access is granted according to job responsibilities, approved business need, and least-privilege principles. Each account must have an identified owner. Access changes require documented approval, and access is removed or adjusted promptly when a worker joins, changes role, or leaves. Privileged access is limited, monitored, and reviewed at defined intervals.”

Adapt the wording to your environment and have the policy owner confirm that it matches actual identity-provider, human-resources, ticketing, and application workflows. A policy that describes a process nobody follows creates audit and security risk.

Checklist by scenario

Joiner: provisioning a new worker

• Confirm the worker’s identity, employment status, start date, manager, department, location, and approved role.
• Assign a unique account; do not share credentials or reuse another person’s account.
• Require strong authentication and enroll the user in the organization’s approved authentication method before access is granted.
• Use role-based groups or access packages where practical instead of assigning permissions individually.
• Record required applications, data classifications, privileged functions, and any time-limited access.
• Obtain approval from the manager or designated system owner before granting application or sensitive-data access.
• Provide security and acceptable-use guidance, including credential handling, reporting routes, and use of company devices.
• Capture evidence: approved request, account creation record, group membership, training acknowledgment, and completion date.

Mover: changing a worker’s role

• Start the change from an authoritative source, such as a human-resources or manager-approved record.
• Compare the old role with the new role before making changes. Identify permissions that must be removed, retained, or added.
• Remove access inherited from the previous department unless a new owner explicitly approves it.
• Review elevated privileges, shared project spaces, production access, and access to regulated or sensitive information.
• Set an effective date and assign responsibility for completing the change.
• Ask the system owner to validate the final access set after the transition.
• Preserve the change ticket, approvals, before-and-after group membership, and completion timestamp.

Leaver: disabling access after departure

• Receive a confirmed departure notice and classify it as planned, immediate, or potentially high risk.
• Disable the primary identity and revoke active sessions, tokens, API keys, VPN access, device certificates, and application sessions where supported.
• Remove group memberships, administrator roles, shared mailbox access, repository access, and access to cloud consoles.
• Recover or remotely lock company devices according to the organization’s procedure.
• Transfer business records and ownership of repositories, workflows, dashboards, and scheduled jobs to an approved owner.
• Rotate shared secrets if the departing person could have known them or had access to them.
• Document the completion time and retain evidence of each material deprovisioning action.

Example internal targets can distinguish between normal and urgent departures: complete planned deprovisioning by the end of the worker’s final authorized day, and begin immediate access removal as soon as an authorized manager or human-resources contact confirms an involuntary or high-risk departure. Treat these as internal control objectives, not universal legal deadlines. Your risk assessment, contracts, workforce arrangements, and applicable requirements may call for different targets.

Privileged access review

• Maintain an inventory of administrator accounts, emergency accounts, cloud roles, database privileges, and security-tool access.
• Assign an owner and business justification to every privileged identity.
• Separate everyday accounts from administrative accounts where the technology supports it.
• Require stronger authentication and log important privileged actions.
• Review privileged access on a defined recurring schedule and after role changes or security events.
• Remove dormant, duplicate, unnecessary, or unexplained privileges.
• Test emergency or break-glass accounts without exposing their credentials in ordinary evidence.

For audit preparation, pair this workflow with an audit evidence collection checklist and map the controls to the framework or customer commitment in scope. The same evidence may support SOC 2 readiness, ISO 27001 controls, or an internal cybersecurity compliance review, but the exact expectations depend on the assessment.

What to double-check

Use a role-and-permission matrix

A simple matrix makes access decisions reviewable. List roles down the first column and systems across the top. For each cell, record whether access is none, read-only, standard, elevated, or temporary. Add columns for the business purpose, approving owner, evidence location, review frequency, and removal trigger.

Do not treat a job title as sufficient proof of need. Two people with the same title may work with different customers, environments, or data. The system owner should confirm the permissions that the role actually requires.

Check the evidence chain

For each sampled account, an auditor or reviewer should be able to follow a clear chain:

1. Who requested access?
2. Who approved it?
3. What role or permission was granted?
4. When did it become active?
5. When was it last reviewed?
6. What happened when the person changed roles or left?

Useful evidence includes access requests, approval records, identity-provider logs, group exports, application-owner attestations, termination tickets, device-recovery records, and review sign-offs. Add an export date and system name to reports so older evidence is not mistaken for current state. Protect evidence that contains personal data and limit its retention to a documented business and compliance need.

Validate technical dependencies

Check whether disabling a central identity also removes application access, or whether separate applications require manual action. Review integrations, service accounts, local accounts, personal access tokens, SSH keys, scheduled jobs, and third-party platforms. A successful directory deactivation does not necessarily prove that every downstream session or credential has been revoked.

Common mistakes

• Relying on email alone: Informal requests are difficult to approve, track, and demonstrate later. Use a ticket, workflow, or other controlled record.
• Granting broad default access: A convenient baseline can become permanent excess privilege. Start with the minimum role and add exceptions with an owner and end date.
• Ignoring non-human identities: Service accounts, automation tokens, and integrations need owners, purpose, scope, rotation expectations, and review dates.
• Assuming termination equals deprovisioning: A human-resources update may not disable every application, session, token, or physical device.
• Failing to remove old permissions during transfers: Movers can accumulate access across departments unless the old role is explicitly compared and retired.
• Keeping sensitive evidence indefinitely: Access reports and termination records may contain personal information. Define secure storage, retention, and deletion rules.
• Writing an aspirational policy: If your tools cannot perform an action, describe the compensating manual control and assign a named owner rather than claiming automation.

When to revisit

Review this access control policy at least during the organization’s normal policy cycle and whenever the underlying workflow changes. Revisit it before seasonal planning cycles, after adopting a new identity provider, during an application migration, after reorganizing teams, or when introducing new privileged tools and cloud environments.

Run a focused review after a security incident, an audit finding, a significant contractor change, or evidence that an account remained active longer than intended. Also review the policy when authentication capabilities, employment processes, contractual commitments, or applicable privacy and security requirements change. Keep the document’s owner, approval date, version, related procedures, and next review date visible.

For a practical recurring routine, schedule a monthly review of urgent departures and privileged exceptions, a quarterly review of privileged and sensitive-data access, and an annual policy and role-matrix review. Adjust the frequency to your risk profile. Before an assessment, sample joiners, movers, leavers, and administrators; reconcile them against authoritative records; resolve exceptions; and store the evidence in one controlled location. If access governance exposes wider control gaps, use the compliance control testing checklist to assign owners, due dates, and follow-up testing.