A quarterly access review is a one hour pass where you list every account with access to your critical systems, ask the owner of each system whether each person still needs it, remove the rest, and record the result. For 5 to 20 engineers it is a spreadsheet and a calendar reminder.
Why quarterly
Access builds up. People change projects, contractors finish, a test account is never deleted. Each unused permission is a door nobody is watching. The CIS Controls IG1 set, aimed at small and medium organizations with limited security staff, treats account management and access control as foundational hygiene, which is why this small habit shows up in nearly every security questionnaire.
Quarterly is frequent enough to catch drift and rare enough to keep. If you add people often, run a lighter check at each leaver.
Pick the systems that matter
You do not review everything. Start with the systems where a stranger would cause real damage.
| System | Why it is in scope |
|---|---|
| Cloud console and production roles | Can change or delete live infrastructure |
| Code host organization and admin team | Can change code and settings |
| CI and deploy tooling | Can ship code and read secrets |
| Identity provider or email admin | Controls every other login |
| Customer data stores and support tools | Hold the most sensitive data |
| Package registry and domain registrar | Can publish as you or take your name |
The steps
- Export (15 minutes). Pull the user list and role for each system. Most tools can export a CSV, and if not, a screenshot is acceptable for a first round.
- Compare to a current roster (10 minutes). Anyone who is not on the team list is a removal candidate. Include contractors and shared or service accounts.
- Ask the system owner (20 minutes). For each remaining person, is this role still needed? Ask for the least privilege that does the job.
- Act (10 minutes). Remove or downgrade immediately where you can. Create a ticket where you cannot.
- Record (5 minutes). Save the date, reviewer, systems covered, changes made. One row per system is enough.
Rules that keep it honest
The reviewer should not approve their own access. Admin roles get questioned hardest. Shared accounts need an owner or should be retired. Service accounts and tokens belong in the review, because they outlive people.
Pair the review with your leaver routine: the offboarding security checklist handles departures as they happen, and the quarterly pass catches whatever slipped through.
What good evidence looks like
A dated export, a note of who reviewed it, and a list of changes. If an auditor or buyer asks how you manage access, that one page answers the question better than a policy paragraph.
Where Safeguard fits
Safeguard offers asset discovery and compliance and evidence automation, which can help keep inventory and evidence current. For the dependency side, it also provides SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Quick check
Do we need this if we are very small?
Yes, but keep it short. With five people the review may take ten minutes, and it still catches old contractor and service accounts.
Who should approve access?
The owner of each system, not the person who holds the access. In a tiny team, a second engineer or the founder can sign off.
Sources
Last reviewed: 19 October 2026.
