What About Recertification? Access Reviews Are Still a Superpower
Recertification is not a quarterly compliance tax. Done well, it is the fastest way to shrink your attack surface, cut permission debt, and make audits boring in the best way.
The question keeps coming up
Recertification sounds like something you get after passing a compliance course. In practice, it is the periodic review of who has access to what—and whether they still need it. It sits at the intersection of security, operations, and trust. Teams often postpone it, because it feels like internal paperwork. But in developer tools and infrastructure platforms, stale access is not paperwork. It is an attack surface.
At Sapior, we see recertification as a product problem, not just a governance ceremony.
What recertification actually means
Access recertification is an audit process where resource owners or managers confirm that user entitlements are still appropriate. The SOC 2 framework's CC6.1 criterion calls for logical access controls, while ISO 27001 control A.9.2.5 explicitly requires owners to review user access rights at regular intervals. Recertification is how that review becomes operational.
It usually covers:
Employee roles and permissions in production systems
Third-party integrations and service accounts
Elevated access such as admin, deploy, or data-plane roles
Temporary grants that quietly became permanent
The goal is simple: remove access that no longer has a human justification.
Why recertification breaks in dev-tool environments
Developer infrastructure moves faster than traditional enterprise software. Ephemeral environments, CI/CD pipelines, bot accounts, and shared clusters make access feel fluid, but the underlying grants often persist. A contractor gets production read access for a one-week migration. A service token is created for a demo. A teammate who moved teams keeps the old repo permissions. None of this looks broken until it is.
The result is permission debt: the accumulated gap between who should have access and who actually does.
The recertification loop that works
1. Inventory entitlements in one place
You cannot review access spread across GitHub, Vercel, AWS, your database, and your internal admin tool without a source of truth. This inventory should include human users, non-human identities, groups, and roles.
2. Assign a reviewer who can actually decide
Every entitlement should have an owner. That owner is usually the engineering manager, service owner, or team lead who understands why a permission exists. If nobody can explain a grant, that is already the answer: remove it.
3. Use time-boxed decisions
Recertification fails when it becomes a long-running campaign. Set a short window—seven to ten days—with explicit choices: approve, modify, or revoke. The goal is momentum, not perfection.
4. Make revocation safe and reversible
Teams hesitate to remove access because they fear breaking production. A clean recertification workflow should log the original state, revoke with a single action, and allow fast reinstatement with a justification. This reduces the fear that keeps stale access alive.
5. Turn the outcome into evidence
For SOC 2, ISO 27001, GDPR, and other frameworks, a recertification cycle is only real if you can show it. Store the review record: who approved what, when, and why. That evidence should be exportable into an audit pack without manual screenshots.
Recertification is not a replacement for real-time controls
It would be a mistake to rely only on quarterly access reviews. Strong systems combine periodic recertification with:
Just-in-time access for elevated roles
Role-based and attribute-based access control
Anomaly detection for unusual permission usage
Automated deprovisioning when someone leaves
Recertification is the safety net. It catches what real-time controls miss.
What changes when recertification becomes a product feature
Most teams treat recertification as an operations task. When it becomes a product workflow—visible, reviewable, automated—it changes behavior. Engineers can see why they have access, managers can act in a few clicks, and auditors get a clear narrative instead of a spreadsheet pile.
At Sapior, we think of recertification as part of the identity lifecycle, not a separate annual event. That matters because developer tools create access faster than any compliance calendar can keep up.
The real payoff
The obvious payoff is audit readiness. The less obvious one is operational clarity. A clean permission system is easier to reason about, cheaper to secure, and less likely to produce a headline-level incident. Recertification is unglamorous, but it forces the question that matters: does this access still need to exist?
If the answer is not yes, then the access should not be yes.