9.3 Provisioning, Deprovisioning, and Access Reviews

The Joiner-Mover-Leaver Lifecycle

Provisioning creates, enables, or changes access for a subject; deprovisioning disables, removes, or reduces it when it is no longer needed. Together they form most of identity lifecycle management, and the goal is one sentence: the right identities should have the right access at the right time, and stale access should be gone.

Organizations model lifecycle events as joiner, mover, and leaver (JML):

Movers are the trickiest event. When a developer transfers from billing to the mobile-app team, the new repositories and tooling get added, but the old billing-deployment rights too often remain. Repeated over years, that produces privilege creep — access far beyond current duties — which violates least privilege and inflates the blast radius of any compromise.

Good provisioning starts with a request and approval from a manager or application owner who confirms business need. Access should map to a role when possible, and any exception should be documented with an end date — for example, temporary access to a project folder that auto-expires.

Deprovisioning Timing and Access Reviews

Deprovisioning timing depends on the scenario, and the exam expects you to distinguish them:

• Voluntary resignation — schedule removal for the final working day, coordinated with HR.
• Involuntary termination or insider-risk case — disable access before the employee is notified, to prevent retaliation or data theft.
• Contractor end-date — set expiration at provisioning time so access lapses automatically.

At termination, sweep every system: SSO, email, VPN, cloud apps, privileged accounts, building/badge access, and company devices. A single forgotten cloud admin account becomes an orphaned account — an active credential with no valid owner, a prime target for attackers.

Access reviews (recertification)

Access reviews, also called recertifications, are periodic checks where managers, data owners, or application owners confirm that current access is still appropriate. Typical questions: Does this user still work here? Still hold this job? Still need this application? Does this privileged role still have a valid owner? Reviews matter most for privileged access, financial systems, sensitive data, and contractors, and they support audit requirements such as Sarbanes-Oxley (SOX) for financial-system access.

A review must produce action, not just a spreadsheet. If a manager flags access as no longer needed, the identity team or an automated workflow must actually revoke it. If no one can explain why a service account exists, investigate and document its owner and purpose before disabling — or retire it safely. A review that merely collects rubber-stamp approvals becomes a paper exercise.

Automation does not remove responsibility

HR systems can trigger JML workflows, identity-governance tools route approvals and reviews, and SSO centralizes disablement. Even so, business owners must define appropriate access, managers must certify accurately, and security must monitor for gaps. For CC scenarios, the warning signs are delayed deprovisioning, orphaned accounts, and accumulated cross-role permissions — and the remedy is timely JML execution plus recurring reviews.

Least Privilege, Need to Know, and Provisioning Models

The principles that govern what to provision matter as much as the lifecycle mechanics. Least privilege says a subject receives only the access required to perform its tasks — no more. Need to know is the data-focused companion: even a user cleared to a level only sees the specific information their duties require. A common CC distractor offers "grant access in case they need it later" — always wrong, because it violates least privilege and fuels privilege creep.

Provisioning is most defensible when it is role-based. Instead of hand-granting permissions per person, the organization defines roles (Accounts Payable Clerk, Help Desk Tier 1) and assigns users to them. This makes provisioning consistent, deprovisioning clean (remove the role), and reviews tractable (recertify roles, not thousands of individual grants). Watch for toxic combinations that break separation of duties — for example, one person who can both create a vendor and approve its payments. JML and access reviews should detect and split such combinations.

A mover walkthrough

Consider a developer moving from billing to the mobile-app team:

1. Add new repository, issue-tracker, and cloud-dev access for the mobile role.
2. Remove billing test-data access and billing deployment privileges.
3. Record the change with manager approval and an effective date.
4. Verify at the next access review that no billing entitlements remain.

A mature mover process performs step 2 as part of step 1. Skip it, and the developer silently retains both permission sets for years — the exact pattern auditors flag.

Reconciliation and orphan hunting

Beyond scheduled reviews, mature programs reconcile the identity store against authoritative sources. Comparing the HR roster to active accounts surfaces logins for people who already left (orphaned/ghost accounts). Comparing application accounts to the central directory surfaces local accounts that bypass SSO and offboarding. The CC takeaway: lifecycle controls are only as good as the evidence that they actually ran — reviews and reconciliation provide that evidence, and an unremediated review finding is itself a deficiency.