Stop Leftover Access From Outliving the Job

The Problem: Why This Matters Now

Granting access is quick. A manager requests it, an approver clicks yes, and the person is productive by lunch. Removing access, however, often lacks an owner and a deadline, so it rarely happens.

This leads to accumulation. Someone changes teams, gains new entitlements, and retains all previous access. During an access review, the reviewer sees a name next to an entitlement and asks: is this still valid? There's no indication of when it was last used. Clicking "yes" is easy; clicking "no" risks a support ticket if something breaks.

The risk is real. According to the 2026 Verizon Data Breach Investigations Report, exploitation of vulnerabilities accounts for 31% of breaches, and credential abuse for 13%. While stale permissions aren't measured, an attacker's potential with a compromised account depends on accumulated access. A March 2023 PasswordManager.com survey found 58% of respondents used passwords from previous employers without updating them after leaving. This survey is a signal, not a definitive measurement.

For framework alignment, NIST SP 800-53 Rev. 5 controls AC-2 (Account Management) and AC-6 (Least Privilege) require reviewing accounts, handling transfers and terminations, and granting only necessary privileges. If you're working toward SOC 2 or ISO/IEC 27001, this maps to your User Lifecycle Management evidence, and auditors will ask about transfer handling, not just terminations.

This playbook implements three changes: transfer-triggered removal, owner-and-expiry on every permission, and last-used data in every review.

What You Need Before Starting

• HR system access (Workday, BambooHR, or equivalent) with event or webhook capabilities for role and department changes.
• Identity provider admin rights (Okta, Entra ID, or similar) to access last sign-in timestamps and group memberships.
• A ticketing or workflow tool to assign tasks to managers.
• An entitlement inventory for at least one system holding sensitive data: users, groups, direct grants, service accounts.
• Application log access for usage logs.
• A named executive sponsor who agrees that removal ownership is a managerial responsibility, not just IT's.

Pick one pilot system. Don't start with everything.

Step-by-Step Implementation

Step 1: Treat Every Role Change as a Removal Event

1. In your HR system, define a trigger for job title, department, or manager changes.
2. Auto-create a task for both outgoing and incoming managers, pre-populated with the employee's current groups, direct grants, and application roles from your IdP.
3. Ask: what will this person no longer need? Give managers a short window to answer, with a due date of a few business days.
4. Route answers to IT for revocation. Anything not confirmed as needed goes to the permission owner (Step 2) for decision.
5. Log the task, the answer, and the revocation ticket. This chain is your audit evidence.

If you only do one of these fixes, do this one. Transfers trigger nothing today, while terminations at least hit an offboarding checklist.

Step 2: Give Every Permission a Named Owner and an Expiry Date

1. For project folders, privileged roles, and production access, add two required fields: owner (a named person) and expiry date.
2. Set the default expiry to three months from issuance, or the project end date if sooner.
3. Build renewal as a one-click action for the owner. If the owner has left or is unreachable, escalate to their manager.
4. Make expiry the default outcome. If nobody acts, access lapses. Never make silent renewal the default; it turns inaction into the risky path.
5. Model accounts, owners, and the applications they touch as a graph, or at least a queryable table. When an account changes, one query should reveal what that person owns and what depends on it.

Handle exceptions: quarterly close accounts and break-glass accounts are rarely used. Assign each an owner and a documented note explaining why it persists.

Step 3: Put Last-Used Data in Front of Every Reviewer

1. Pull last login and activity timestamps from your IdP and application logs.
2. Join them to each entitlement in your review tool or spreadsheet.
3. Sort so the least-used access appears first, and pre-select those items for removal.
4. Require reviewers to justify keeping anything pre-selected. Flip the burden of proof.
5. Keep attestation, rotation, vaulting, and retirement in a single workflow. When confirmation happens in one tool and action in another, people confirm and then skip the action.

Be honest about limits: not every application keeps usage logs. For those, flag "no usage data" explicitly and require owner justification.

Step 4: Run the Pilot

This quarter, pick one system that stores sensitive data and run a last-used report. Start with users who changed roles in the past year, since nobody has reviewed their access since the move. Send the system owner the list of those who haven't used the system in six months and ask: do they still require this?

Validation: How to Verify It Works

• Trigger test. Change a test user's department in HR. Confirm both managers receive the task and that revocation tickets appear within your target window.
• Expiry test. Issue a test permission with a short expiry. Confirm it lapses without action and that renewal routes to the manager when the owner is disabled.
• Review test. Open your next access review and confirm every row shows a last-used date and that stale entries are pre-selected.
• Sampling. Pull a sample of recent transfers and trace each one: HR event, manager task, answer, revocation. Gaps in that chain are what an assessor would flag as a Nonconformity.
• Residual check. Query for accounts with no named owner or no expiry. The count should trend toward zero.

Maintenance: Ongoing Tasks

• Per transfer: confirm the manager task closed and revocations completed.
• Quarterly: rerun the last-used report on the pilot system, then extend to the next system holding sensitive data.
• Quarterly: review exceptions (break-glass, periodic accounts) and confirm owners and notes are current.
• Ongoing: track metrics in line with ISO/IEC 27004 guidance, such as time from role change to revocation and percentage of permissions with a valid owner. Report them in your Performance Evaluation cycle.
• When owners leave: reassign their permissions as part of offboarding, so ownership doesn't orphan.

The pilot findings will usually make the case for broader rollout more effectively than any framework citation.