Quarterly access reviews catch what onboarding misses

Access granted correctly at onboarding still needs revoking correctly at offboarding or role change. The gap between the two is where audit findings live.

When a new engineer joins a company, the provisioning process is usually highly structured. They receive a standard set of roles via a centralized identity provider. The access is tightly scoped to their immediate team requirements. The security baseline is perfect on day one.

Then, they start actually doing their job.

The Accumulation of Privilege Over the next two years, that engineer will temporarily cover an on-call shift for a different team and request production database access. They will join a cross functional project and be granted administrative rights to a third party cloud service. They will help debug a legacy microservice and get added to a specific AWS IAM group.

They get the access they need to solve the immediate business problem. But when the project ends, the permissions remain. Access in a growing engineering organization behaves like a ratchet. It only moves in one direction.

The Role Change Blind Spot When an employee leaves the company entirely, automated offboarding scripts usually disable the primary identity provider accounts. The real danger lies in internal role transitions.

If a senior backend engineer transitions into a product management role, human resources updates the payroll system, but no automated trigger alerts the infrastructure team to revoke their Kubernetes cluster access. The employee retains sweeping production privileges they no longer need for their daily duties. From a security perspective, this creates an enormous and completely unnecessary attack surface.

The Forced Reckoning You cannot rely on engineers to voluntarily relinquish access they no longer use. You have to implement mandatory quarterly access reviews.

This process forces engineering managers to manually review a complete matrix of their team members and their associated permissions across all active systems. It is tedious, unglamorous work, but it is the only mechanism that reliably catches permission drift. It forces a fundamental mindset shift. Instead of assuming access is retained permanently by default, the manager must actively justify why a specific permission is still explicitly required for the upcoming quarter.

Compliance frameworks like SOC 2 mandate this practice for a reason. Your automated provisioning scripts only prove that you know how to grant access. A quarterly review is the only way to prove that you actually know who still holds it.