You completed access certification in Q1. Every user's access was reviewed, approved, and documented. Perfect.
But it's now Q3.
Since that certification, 47 employees changed roles, 23 contractors finished projects, 12 employees left the company, 8 new apps were adopted, and 156 new group memberships were created.
The question: Is the access still appropriate? You certified it six months ago, but access isn't static—it changes constantly.
This is why compliance frameworks don't just require certification. They require recertification—periodic re-validation that access remains appropriate.
Organizations conducting quarterly recertifications spend an average of 149 person-days per cycle on manual processes. That's 596 person-days per year—roughly 3 FTEs—just maintaining a compliance process.
Unless you automate.
What is recertification?
Access recertification is the periodic re-validation of user access to applications and data, conducted at regular intervals (quarterly, semi-annually, annually) to ensure access remains appropriate as roles, responsibilities, and employment status change.
Certification vs. recertification
Initial Certification: Establishing baseline—confirming current access is appropriate NOW
Recertification: Re-validating baseline—confirming access REMAINS appropriate since last review
Why "re" matters
The assumption in recertification is that access WAS appropriate (you certified it), but circumstances have changed.
Role changes mean different access needs—Engineer becomes Manager.
Department transfers mean different apps—Sales moves to Marketing.
Employment status changes mean no access needs—Active becomes Terminated.
Project completion means time-bound access expired. Privilege creep means users accumulated permissions over time.
What gets recertified
All user access certified in the previous cycle, new access granted since last certification, access modifications (permission changes), group membership changes, and application-level access (who has access to which apps).
Frequency by framework
- SOX: Quarterly (financial systems)
- PCI DSS: Quarterly (payment systems)
- SOC 2: Annually minimum, quarterly recommended
- HIPAA: Annually minimum
- ISO 27001: Annually minimum
Why recertification is critical
Reason 1: Access drift is inevitable
What is access drift?
Access drift—the gradual deviation of actual access from appropriate access as organizational changes occur.
Types of access drift:
1. Role-based drift
The employee promoted from Engineer to Engineering Manager still has access to all engineering tools (appropriate) and gained access to HR systems for team management (appropriate). Problem: Still has admin access to production (no longer appropriate).

2. Temporal drift
The contractor hired for a 6-month project gets access granted in Month 1 (appropriate). Project completes and contract ends in Month 6. Month 7-12: Still has access (drift).

3. Accumulation drift (privilege creep)
Employee over 5 years: Year 1 gets Salesforce for sales role, Year 2 gains Jira admin while leading project, Year 3 gains HubSpot access helping marketing temporarily, Year 4 gains NetSuite reader access while covering for finance, Year 5: Current role only needs Salesforce, but has 4 apps of accumulated access.

Reason 2: Compliance frameworks mandate it
Why one-time certification isn't enough:
Compliance frameworks understand that access changes constantly. That's why they require PERIODIC review—not just initial setup.
Regulatory language:
- SOC 2 CC6.2: "Logical and physical access controls are reviewed periodically"
- SOX Section 404: "Controls over financial reporting must be evaluated quarterly"
- HIPAA 164.308: "Review access to ePHI annually"
- ISO 27001 A.9.2.5: "Review user access rights at regular intervals"
What auditors actually look for
Evidence of scheduled recertifications (not ad-hoc), proof certifications happened on time (no delays), documentation of changes since last certification (what's new?), and remediation of newly identified violations (drift caught and fixed).
Common audit red flags
Last certification was 18 months ago (should be quarterly/annual), no evidence of remediation between certifications, can't produce historical certification records, and certifications exist but no proof of follow-through.
Reason 3: Security—catching what changed
How the threat model works
Scenario 1: The departed employee
Q1 Certification shows an employee is active with appropriate access. March arrives and the employee leaves, offboarding happens. But from April through June, some apps were missed in offboarding. Q2 Recertification catches 3 apps where access wasn't revoked.
Scenario 2: The finished project
Q1 Certification shows a contractor working on Salesforce integration with appropriate admin access. March brings project completion and contract end. April through June pass and access isn't revoked—nobody remembered. Q2 Recertification flags the contractor with admin access but no active project.
Scenario 3: The role change
Q1 Certification shows a sales rep with Salesforce and LinkedIn Sales Nav (appropriate). April brings a promotion to Sales Manager. May brings new access to compensation data, pipeline forecasts, and pricing tools. Q2 Recertification reveals old Sales rep access PLUS new manager access (excessive).
When researchers examined breach data, organizations with manual processes attribute substantial percentages to ex-employees with retained access (should have been caught in recertification) and third-party vendors with excessive access (should have been reviewed and reduced).

Both are caught systematically through recertification—if the recertification actually happens and remediation follows.
Reason 4: Cost—finding waste that accumulated
How licenses accumulate between certifications
Between certifications, users accumulate SaaS licenses through trials that converted to paid without approval, apps added for one-time projects (never removed), duplicate tools across departments, and licenses for departed employees (billing continued).
For a 1,000-employee company with 200 SaaS apps, average $50/user/month per app, and 5% of licenses becoming unnecessary between quarterly recertifications:
Waste per quarter: 10 licenses × 200 apps × $50 = $100K
Annual waste if not caught: $400K
The ROI appears in every cycle
Each recertification cycle catches unused licenses (never logged in), dormant licenses (>90 days inactive), duplicate licenses (same user, multiple instances), and phantom licenses (ex-employees still billed).
The recertification process
Step 1: Schedule & scope
Start by determining frequency
High-risk apps need quarterly recertification (SOX, PCI, sensitive data). Standard apps need semi-annual review. Low-risk apps need annual validation.
Define what changed since last time
What's NEW since last certification? New apps adopted, new users onboarded, role changes, department transfers, and terminated employees (verify offboarding complete).
How automation changes the game
System tracks what changed since last certification and highlights for focused review: "47 new users added to Salesforce since Q1," "12 users changed departments," "8 users terminated—verify access removed."
Step 2: Delta review + full re-validation
Two approaches:
Incremental (delta only): Review only what changed since last certification. Faster because of smaller dataset. Risk is you may miss drift on "approved" users.
Full recertification (recommended): Review ALL access, not just changes. Thorough because it catches drift on previously approved access. Efficient with automation because group-based approach makes full review fast.
Why group-based recertification works
Instead of recertifying 2,000 users individually: recertify 50 SSO groups and focus on group membership changes.Each group recertification covers 10-50 users. Result is full recertification in 1/10th the time.
Step 3: Execute review
What reviewers validate
For each user or group, check whether employment status is still active, role is unchanged or access was updated to match new role, usage data shows access is being used, and there are no red flags (external user, excessive admin, dormant account).
Four possible decisions
Approve when access remains appropriate. Deny when access is no longer appropriate (triggers remediation). Modify when permission level needs adjustment. Escalate when situation is unclear and needs app owner or security review.
Step 4: Remediate & document
How closed-loop remediation works
Denied access gets immediate revocation (not tickets). Modified access gets permission level adjusted automatically. All changes are logged with timestamp and proof.
What audit documentation includes
Who recertified (reviewer name), what was recertified (users, apps, access levels), when recertification occurred (timestamp), changes since last certification (delta report), and remediation actions taken (proof of completion).
Step 5: Trend analysis
What comparing cycles reveals
Q1 vs Q2 reveals whether violations are increasing or decreasing, whether same apps keep showing up as high-risk each quarter, whether same users keep accumulating excessive access, and whether remediation is happening faster each cycle.
How recertification data drives improvement
Recertification data informs onboarding improvements (reduce initial over-provisioning), offboarding improvements (catch missed apps), and access request policies (prevent future drift).
Recertification challenges
Challenge 1: Recertification fatigue
Reviewing the same 2,000 users every quarter leads to reviewers clicking "Approve All" without reading.
How to solve it: Focus on delta where AI highlights what CHANGED since last review, use group-based approach to certify groups instead of individual users, and implement risk-based methodology to auto-approve low-risk items while focusing reviews on anomalies.
Challenge 2: Tracking what changed
Reviewer sees user X has access to App Y, but can't tell if this is NEW access (since last review) or existing access. Without context, you can't make informed decisions.
How to solve it:
Zluri shows delta clearly: "User X: Access granted on April 15 (AFTER Q1 certification)" and "User Y: Access unchanged since Q1, last login 90 days ago."
This transforms recertification from "review everything again" to "focus on what changed and what's risky."
Challenge 3: Proving continuous compliance
Auditor asks to see recertifications for the past 12 months. You have Q1 and Q4 records. Q2 was delayed. Q3 is "in progress."
How to solve it:
Automated scheduling ensures recertifications happen on time, every time, with complete audit trail showing Q1 completed March 15, Q2 completed June 14, Q3 completed September 16, and Q4 completed December 13.
No gaps. No delays. No "we're working on it" explanations.
Challenge 4: Remediation follow-through
Q1 Recertification identifies 47 access denials. Q2 Recertification shows same 47 issues still exist because tickets never got closed.
How to solve it: Closed-loop remediation means Q1 denials are remediated immediately, so Q2 recertification shows 0 outstanding items from Q1.
Zluri's 2024 research found that organizations with manual processes often have substantial portions of violations persisting from previous cycles—creating an ever-growing backlog.
Recertification = continuous governance
One-time certification establishes a baseline. Recertification maintains it. Without regular recertification, access drifts away from appropriate, compliance gaps accumulate, security risk increases silently, and license waste compounds.
The modern approach
Automated recertification with Zluri delivers scheduled campaigns (never miss a deadline), delta-focused reviews (highlight what changed), group-based efficiency (10x faster), closed-loop remediation (no gaps), and complete audit trail (permanent evidence).
Compliance that stays compliant. Security that stays secure. Access that stays appropriate—not just once, but continuously.
See who has access to what in your environment and prioritize access risks.
[Start Discovery Scan] → Book a Demo to understand your complete access landscape across all applications



.png)



















.webp)




.webp)
.webp)





.webp)