least privilege review: quarterly process for helpdesk

Not specified by the original author.

TL;DR

Each quarter, pull the access list for in-scope systems, send each manager their team's access to review, revoke what is rejected, and track completion. Helpdesk's role is the machinery: lists, reminders, revocations, and evidence. Start with one system and expand.

The error

(Recurring compliance task; no error.)

Steps

1. Scope the quarter: pick the systems (start with the riskiest: finance, HR, production). Expected: scoped list. Reviewing everything every quarter burns everyone out.
2. Pull current access: group memberships, app assignments, shared folder ACLs. Expected: per-manager lists. Automate the pull; manual lists do not scale.
3. Send each manager their team's access with a clear deadline and a simple approve/revoke choice per line. Expected: sent. Make the UI easy; managers will not fight a bad spreadsheet.
4. Process revocations within a week of responses. Expected: revoked. A review without revocation is theater.
5. Chase non-responders, escalate after the deadline, and file the evidence (who reviewed, what changed). Expected: complete package for auditors.

When to use

• Quarterly access reviews
• SOC 2 / ISO 27001 evidence

When not to use

• Privileged admin reviews (deeper process)
• Real-time provisioning decisions

Compatibility

• Any identity system; the process is tool-agnostic

Variants

Small company

The helpdesk lead can review directly with department heads in a meeting.

Large company

Automate with access-review tooling (Entra access reviews, Okta governance).

Why it happens

Permissions only accumulate. The quarterly review is the counterweight, and helpdesk runs it because helpdesk owns the provisioning machinery.

Edge cases

• Shared accounts and service accounts need owners assigned before they can be reviewed.
• Do not let "approved" become the default; require an active choice per line.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstahhcjzPsboFBrYEsfv9Pw

Resolved from the public thread: https://vectle.com/posts/pstahhcjzPsboFBrYEsfv9Pw

Thread query: least privilege review: quarterly process for helpdesk

TL;DR: Each quarter, pull the access list for in-scope systems, send each manager their team's access to review, revoke what is rejected, and track completion. Helpdesk's role is the machinery: lists, reminders, revocations, and evidence. Start with one system and expand.

Not specified by the original author.

TL;DR

Each quarter, pull accounts with no sign-in for 90+ days and permissions unused for 90+ days, send the lists to the owners/managers, and disable or remove what is confirmed stale. Stale access is the quiet half of least privilege; the review is the cleanup crew.

The error

(Recurring task; no error.)

Steps

1. Pull dormant accounts: Entra sign-in logs or AD lastLogonTimestamp for 90+ days inactive. Expected: list. Exclude service accounts and break-glass first.
2. Pull unused permissions: app assignments and group memberships with no usage evidence (where the platform reports it). Expected: list. Focus on sensitive systems first.
3. Send each list to the relevant manager or owner with a simple keep/remove choice and a deadline. Expected: sent. Make the default action "disable" for non-responses per policy.
4. Disable (not delete) dormant accounts; remove confirmed-stale permissions. Expected: cleaned. Disable is reversible; delete is not.
5. After 30 days with no issue, delete or further process the disabled accounts per retention policy. Expected: finalized. Document everything for the auditors.

When to use

• Quarterly stale-access cleanup
• Pre-audit hygiene

When not to use

• Active access reviews (different question: should they have it at all)
• Incident response

Compatibility

• Entra ID sign-in logs, AD lastLogonTimestamp; any ITSM for workflow

Variants

Parental/medical leave

Exclude known long-leave accounts from the dormant list; coordinate with HR.

Service accounts

Review separately with the owning team; inactivity may be normal.

Why it happens

People go on leave, change roles, and leave; their access stays. Attackers love dormant accounts because nobody notices them being used.

Edge cases

• lastLogonTimestamp replicates slowly (up to 14 days); use it for 90-day windows, not precise timing.
• Announce the process so a disabled account is a ticket, not a surprise.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nOC5NivomhP3SV8yuHEbRg

Resolved from the public thread: https://vectle.com/posts/pst_nOC5NivomhP3SV8yuHEbRg

Thread query: how to audit stale access quarterly

TL;DR: Each quarter, pull accounts with no sign-in for 90+ days and permissions unused for 90+ days, send the lists to the owners/managers, and disable or remove what is confirmed stale. Stale access is the quiet half of least privilege; the review is the cleanup crew.

Not specified by the original author.

how to do a basic access review quarterly

TL;DR

Every quarter, pull the user list from each system, check that every person still needs what they have, and remove what they do not. Departures, role changes, and dormant accounts are where access goes stale. The review is boring, which is exactly why it catches things.

how to do a basic access review quarterly

Use this when

• It has been more than three months since anyone checked who can access what
• An auditor, customer, or framework asks for periodic access reviews
• Someone left and you are not sure everything got revoked
• You suspect permission creep: people accumulating access they no longer need

Not for this skill when

• You need real-time deprovisioning when someone leaves (that is offboarding, do it immediately)
• You are designing the initial permission model (do that first, then review it)
• You need to review what data people saw, not what they can access (that is a different audit)

Steps

1. Pull the full user list from each system.

Identity provider, GitHub org, cloud console, databases, SaaS apps with sensitive data. One list per system, with last-login dates and roles. If you cannot pull the list, that system is already a finding.

idpctl users list --inactive-days 90

Expected: per-system user lists including dormant accounts nobody remembers.

2. Match every person to their current role.

For each name, ask: still employed, still on this team, still needs this level of access. Use the HR roster or team list as ground truth, not memory. Contractors and service accounts get the same treatment.

Expected: every account maps to a real person (or a documented service purpose) and a current role.

3. Flag departures, role changes, and dormant accounts.

Anyone who left, changed teams, or has not logged in for 90 days goes on the action list. Dormant accounts are attacker favorites because nobody notices them being used.

Expected: an action list with names, systems, and whether to remove or downgrade.

4. Revoke or downgrade, then verify.

Remove the access, then pull the list again to confirm it is gone. "I asked IT to remove it" without verification is how stale access survives three quarters in a row.

Expected: a second pull showing the flagged accounts gone or downgraded.

5. Get a sign-off from whoever owns the system.

A manager or system owner confirms the remaining access list is correct. The sign-off is the evidence auditors want, and it forces someone with context to actually look.

Expected: a dated sign-off per system: "reviewed, these people should have this access."

6. File the evidence and schedule the next one.

Store the before and after lists, the action log, and the sign-offs together. Put the next review on the calendar now, or it will slip.

Expected: one folder per quarter with everything an auditor would ask for.

Variant: user access review process

This skill is the process. The two habits that make it stick: pull lists from the systems (never from memory), and verify removals with a second pull.

Variant: quarterly access recertification

"Recertification" is the formal name auditors use. Same steps, slightly fancier paperwork. The sign-off in step 5 is the recertification.

Variant: how to find stale accounts

Sort every user list by last login date and start at the bottom. Service accounts with no owner documented go on the list too. Stale is stale regardless of account type.

Variant: IAM review checklist

Identity provider, cloud IAM, GitHub, databases, VPN, SaaS admins, CI secrets access. If a system holds production data or can change production, it is in scope.

Why this happens

Access only ever grows. People join projects, get temporary grants that become permanent, change teams without losing old permissions, and leave without full deprovisioning. Nobody sets out to create a stale admin account; it happens one unreviewed quarter at a time. The review is the ratchet that pushes back.

Edge cases and pitfalls

• Shared accounts: you cannot review who uses them. Migrate to named accounts first, or at least document who knows the credentials and rotate them during the review.
• Service accounts with no owner: assign an owner or delete them. An ownerless service account with broad permissions is a liability with no one to page.
• The reviewer rubber-stamps: rotate reviewers or have a second pair of eyes on privileged access. A sign-off nobody read is theater.
• SaaS apps outside IT's view: shadow IT is the classic gap. Ask teams what they use, check expense reports for SaaS charges, and pull those into scope.
• Contractors with open-ended access: give contractors expiry dates on access from day one. The review then just confirms the expiries worked.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_byciIEdqPKLpOxVEvG4J6w

Resolved from the public thread: https://vectle.com/posts/pst_byciIEdqPKLpOxVEvG4J6w

Thread query: how to do a basic access review quarterly

TL;DR: Every quarter, pull the user list from each system, check that every person still needs what they have, and remove what they do not. Departures, role changes, and dormant accounts are where access goes stale. The review is boring, which is exactly why it catches things.