ISO 27001 User Access Review (How to Move From Convenience-Based to Risk-Based Frequency)

Your organization is pursuing ISO 27001 certification to win a European enterprise contract.

Your certification auditor reviews your ISMS documentation and asks:

"Show me evidence of regular reviews of user access rights as required by Control A.9.2.5."

You explain you conduct annual access reviews every December using Excel spreadsheets.

The auditor responds:

"Your risk assessment identified customer data access as high risk. Annual reviews for high-risk access don't align with your documented risk treatment. A.9.2.5 requires reviews at intervals appropriate to the risk. What's your justification for annual frequency for high-risk systems?"

You realize your access review frequency isn't risk-based—it's convenience-based. Customer databases containing 2 million records get reviewed annually. The facilities management spreadsheet gets reviewed annually. Same schedule, vastly different risk, no documented rationale.

"Your risk assessment correctly identified customer data as high risk," the auditor continues. "But your treatment doesn't match your assessment. Show me the documented rationale for why annual frequency is appropriate for high-risk customer data access."

You don't have one. You review everything annually because that's when IT has time.

The auditor flags a nonconformity. "Access review frequency does not reflect the risk-based approach required by ISO 27001 Clause 6.1.2."

Why ISO 27001 Is Different From Prescriptive Frameworks

SOX mandates quarterly reviews. PCI DSS requires a semi-annual minimum. SOC 2 expects you to define frequency and follow it consistently.

ISO 27001 does something different. It requires you to determine appropriate intervals based on your risk assessment, then prove your approach is rational.

This flexibility is powerful but creates uncertainty.

"Appropriate" review frequency for high-risk systems could be monthly, quarterly, or even continuous depending on your risk tolerance, control environment, and business context.

The framework tests your thinking, not your compliance with prescriptive rules.

Auditors evaluate: Is your risk assessment comprehensive? Do your frequency decisions logically follow from identified risks? Are you executing consistently with your documented approach? Are you improving over time through PDCA cycles?

This makes ISO 27001 simultaneously easier (no rigid quarterly mandate) and harder (you must justify every decision) than prescriptive frameworks.

The Three Documentation Failures Auditors Find

We've helped organizations across healthcare, finance, and technology achieve ISO 27001 certification. The same three documentation failures appear repeatedly in pre-certification assessments, and auditors flag them consistently.

Failure 1: No Documented Frequency Rationale

Your auditor asks: "Why annual reviews for customer database access?"

You explain: "That's when we have time to conduct reviews."

"Where's the documented risk-based rationale for annual frequency?"

You don't have one. Your procedures say "conduct annual access reviews" without explaining why annual is appropriate for high-risk systems versus low-risk systems.

The auditor marks their notes. "No documented frequency rationale linking risk assessment to review intervals."

ISO 27001 requires you to justify why quarterly, semi-annual, or annual reviews are appropriate for each risk tier. "We review everything annually because that's when we have time" fails certification audit.

A research organization explained their ISO 27001 access review challenge: "Currently our annual access reviews are done in Excel. It's reliant on the system owner to produce the user listing and review it manually. We want centralized visibility and automated remediation. We need something we can show the auditors."

Failure 2: No Evidence of Continuous Improvement

Your auditor reviews your access review procedure. "This procedure is identical to last year's certification audit. What improvements have you made?"

You explain you run the same Excel-based process each December. Same exports, same spreadsheets, same email workflow.

"Your management review minutes don't show any efficiency improvements, process optimizations, or automation initiatives. Where's evidence of the PDCA cycle?"

You realize you've operated the same static process for three years with no measurable improvement. That's evidence of stagnant ISMS maturity, not continuous improvement.

ISO 27001 tests PDCA (Plan-Do-Check-Act) cycles. Traditional organizations run the same Excel-based review process for three years with no optimization or efficiency gains. That's evidence of static operations, not continuous improvement.

Failure 3: No Proof of Complete Coverage

Your auditor asks: "How do you know this Excel list represents all users with access?"

You explain: "System owners export user lists and send them to IT."

"What if a system owner forgets to send their list? What if new applications were deployed mid-year? What if shadow IT exists outside official IT processes?"

You realize your Excel compilation might miss applications, users added between annual reviews, or systems deployed outside IT visibility.

The auditor marks a finding: "No systematic discovery process to ensure complete access review coverage."

Another organization preparing for certification described similar coordination challenges: "We have tons of different applications and platforms. Different departments like HR and Finance own specific systems. It's difficult to coordinate reviews and ensure all reviewers complete their assignments. We need to ease the process for everyone involved."

The Risk Assessment That Drives Everything

ISO 27001 requires risk assessment (Clause 6.1.2) before you can design controls. For access reviews, assess risk based on:

Asset criticality. Customer PII creates higher risk than internal collaboration tools. Financial systems create higher risk than project management applications. Regulated healthcare data creates higher risk than marketing analytics.

Access privilege level. Administrative access creates higher risk than standard user access. Production environment access creates higher risk than development access. Database direct access creates higher risk than application-mediated access.

User population. Employees with established tenure create lower risk than contractors on short-term engagements. Third-party vendors with potential conflicts create higher risk than internal staff. Remote workers create different risk profiles than office-based staff.

Breach impact. Systems where unauthorized access could lead to data breach, financial fraud, or regulatory violation require more frequent review than systems with limited impact potential. Calculate potential breach cost including fines, remediation, and reputation damage.

Historical control effectiveness. Systems with a history of access control violations need more frequent review than systems with clean track records. Applications with high user turnover need more frequent review than stable systems.

Conducting the Risk Assessment

You start with asset inventory from visibility tools—847 applications identified across the organization. For each application, evaluate:

Asset criticality: Your customer database stores PII for 500,000 customers including names, addresses, payment methods, purchase history. Breach would trigger GDPR notification requirements and potential fines. Risk score: High.

Your internal wiki stores meeting notes, project documentation, and process guides. No customer data, no financial information, no regulated content. Breach impact limited to temporary productivity loss. Risk score: Low.

Access privilege level: Your payment gateway has 8 users with administrative access who can view full card numbers, process refunds, and modify transaction records. Risk score: High.

Your project management tool has 127 standard users who can view tasks, update status, and comment on projects. No administrative functions, no sensitive data access. Risk score: Medium-Low.

User population: Your production database has 12 employee DBAs, 5 contractor DBAs on 6-month engagements, and 2 vendor support accounts from your database hosting provider. The contractors and vendors elevate risk due to temporary engagement and external affiliation. Risk score: Medium-High for employees, High for contractors and vendors.

Example Risk-Based Frequency Matrix

High risk (monthly or continuous review):

Admin access to production customer databases
Privileged access to financial systems
Third-party vendor access to sensitive data
Systems processing regulated healthcare information
Applications with history of access violations

Medium risk (quarterly review):

Standard business application access
Contractor access to non-sensitive systems
Administrative access to development environments
Customer support tools with limited data exposure
Systems with moderate breach impact

Low risk (annual review):

Read-only access to non-sensitive systems
Access to collaboration tools with limited data exposure
Departmental tools with narrow scope and minimal impact
Internal productivity applications

Document your risk assessment methodology showing how you evaluated each factor. When auditors ask "How did you determine quarterly reviews are sufficient for customer database access?", your risk assessment provides quantitative justification.

A hospital preparing for ISO certification discovered the gap in their approach: "We were reviewing everything annually because that's what we could manage. When auditors asked why our EHR system with patient PHI had the same review frequency as our facilities management system, we had no answer. We hadn't actually assessed risk—we'd just picked a convenient schedule."

How Visibility-First Enables Risk-Based Reviews

Traditional ISO 27001 implementations start with policy development: Define your access review approach, document procedures, execute reviews.

The challenge is you're defining frequency before you understand your actual risk landscape.

A Singapore financial services firm managing 200+ applications explained this problem to us: "We have more than 200 SaaS applications. Some don't even have native integrations—they require plugins to build or custom scripts. We're spending over a week to consolidate all these reports and validate everything. It's going to be more than 30 days of window every time we review."

When you don't know what applications exist, you can't classify risk accurately. When you don't know who has access, you can't determine appropriate review frequency. When visibility gathering itself takes 30 days, you can't sustain quarterly or monthly reviews for high-risk systems.

Visibility-first principles solve this sequence problem. Reveal your actual application estate before committing to review frequencies:

Multiple discovery methods identify complete application coverage—not just SSO-federated apps, but shadow IT, departmental purchases, web applications, and desktop software. Finance integration shows what's being expensed. Browser extensions catch what's actively used. HR integration reveals access patterns by role and department.

Automated classification evaluates each application against risk criteria: customer PII storage, financial data processing, regulated information handling, administrative access levels, production system integration.

Historical activity data shows actual usage patterns: 47 people have payment gateway access but only 12 logged in this quarter. Database admin access exists for 23 users but only 6 are actively using it. These patterns inform both risk assessment and review focus.

Once you see the complete picture, risk classification becomes data-driven rather than speculative:

Systems handling customer PII warrant monthly or quarterly review based on data volume and breach impact (high risk). Administrative access to production environments warrants quarterly review with additional monitoring (high risk). Standard business tools with minimal data get annual review (low risk). Contractor access patterns get quarterly review to catch contract end dates and role changes (medium risk).

Your risk assessment becomes evidence-based: "We identified 847 applications across the organization through systematic visibility tools. Classification determined 23 contain customer PII (high risk), 89 have privileged access or administrative functions (medium-high risk), 156 are standard business applications (medium risk), 579 are low-risk collaboration or productivity tools."

This granular risk understanding lets you implement truly risk-based frequency that auditors can validate. The approach scales—as you grow from 500 to 5,000 applications, classification methodology remains consistent.

A research organization described how visibility transformed their approach: "Previously we just reviewed the obvious applications. But comprehensive visibility found tools we didn't know existed—the sales team using their own CRM, engineering with shadow IT project tools, contractors with access to systems nobody remembered granting. Our risk assessment changed completely when we saw the actual landscape."

The Four Patterns That Ensure ISO 27001 Certification

We've helped organizations across healthcare, finance, and technology achieve ISO 27001 certification. The certification process reveals consistent patterns about what works and what fails. Organizations that achieve certification without major nonconformities have systematically implemented these four approaches:

Pattern 1: Risk Assessment Before Procedures

Traditional organizations write access review procedures before conducting risk assessments. They commit to specific review frequencies, assign reviewer roles, define escalation paths—all before understanding their actual risk landscape.

This creates procedures that don't align with reality. You document monthly reviews for high-risk systems before testing whether IT can sustain that cadence. Your procedures reference 35 high-risk systems before visibility reveals you actually have 55.

What works: Discover applications first, assess risk second, document procedures third. This sequence produces risk-based approaches auditors can validate.

Start with complete visibility of what exists. Classify each application by risk. Test review execution at proposed frequencies. Document procedures based on demonstrated capability rather than aspirational process.

Pattern 2: PDCA Evidence Through Metrics

ISO 27001 auditors test continuous improvement by examining metrics over time. Static processes suggest stagnant ISMS maturity.

What auditors want to see:

Year 1: 149 person-hours per quarterly review, 34 violations found, average 18-day remediation time.

Year 2: 90 person-hours per quarterly review (implemented automation), 22 violations found (upstream provisioning improving), average 9-day remediation time.

Year 3: 55 person-hours per quarterly review (optimized workflows), 15 violations found, average 4-day remediation time.

This demonstrates process maturity through measurable improvement. Not just "we run access reviews" but "we run access reviews more efficiently quarter over quarter with better outcomes."

Pattern 3: Frequency Adjustments Based on New Risks

Risk landscapes change. A peer company breach elevates risk perception for similar systems. Regulatory changes create new high-risk data categories. New application deployments shift your risk profile.

ISO 27001 certification requires adjusting review frequency when risk changes—document the decision, update the ISMS, implement the new cadence.

For example, your organization deploys a new customer portal mid-year. Initial risk assessment classifies it as medium-risk (quarterly reviews). Three months later, you integrate payment processing into the portal. Risk elevates from medium to high.

The required action would be to increase review frequency from quarterly to monthly, document the risk change in your risk register, update ISMS documentation, and execute the first monthly review within 30 days.

Auditors test whether you're reassessing risk continuously or treating risk assessment as an annual checkbox exercise.

Pattern 4: Service Account Governance

Human user accounts get reviewed systematically. Service accounts get forgotten. Your auditor asks: "Does your access review include service accounts?"

"What service accounts?" you ask.

Your CRM has 7 integration accounts. Your database has 5 batch processing accounts. Your cloud infrastructure has 12 service accounts for automation. None appeared in your annual access reviews.

The auditor marks a finding:

"Access reviews incomplete—service accounts excluded from scope despite having privileged access to sensitive data."

Service accounts represent significant risk; they often have elevated privileges. ISO 27001 Control A.9.2.5 requires reviewing all access rights, including service accounts.

The PDCA Cycle in Practice

ISO 27001 is built on Plan-Do-Check-Act continuous improvement cycles. For access reviews, auditors test whether you're genuinely improving or just running the same process repeatedly.

What PDCA Looks Like Operationally

Q1 Review (Plan → Do): You execute quarterly reviews for 23 high-risk systems. The process takes 47 person-hours. You find 34 violations: 18 dormant accounts, 12 contractor access beyond engagement dates, 4 over-privileged access grants.

Q1 Management Review (Check): Review metrics show dormant accounts represent 53% of violations, suggesting offboarding process gaps. Contractor violations suggest your HR system doesn't track engagement end dates. Present findings to management with recommendation to automate dormant account detection.

Q2 Process Update (Act): Implement automated dormant account flagging. Configure 60-day inactivity threshold. Update offboarding procedure to include access review within 24 hours of termination notification.

Q2 Review (Do): Execute quarterly reviews. The process now takes 32 person-hours (33% improvement). You find 22 violations: 6 dormant accounts (67% reduction), 11 contractor access issues (slight improvement), 5 over-privileged grants.

Q2 Management Review (Check): Dormant account automation working effectively. Contractor access is still problematic. Decide to implement bi-weekly contractor access reports to managers.

Q3 Process Update (Act): Deploy contractor access monitoring. HR system integration flags upcoming contract end dates 30 days in advance.

Q3 Review (Do): Process takes 28 person-hours. You find 16 violations: 4 dormant accounts, 5 contractor access issues (55% reduction from Q2), 7 over-privileged grants.

This is the PDCA cycle auditors want to see—measurable improvement, data-driven decisions, documented actions taken based on findings.

What Auditors Look For

Quarterly or annual management review of access review effectiveness with documented minutes showing discussion topics, decisions made, actions assigned.

Metrics showing trends over time demonstrating process maturity: violations decreasing, review time decreasing, coverage increasing.

Frequency adjustments based on new risk assessments with documented rationale for changes.

Process improvements documented with before/after comparison showing efficiency gains.

Technology evolution showing progression from manual to automated approaches.

A research organization described the PDCA gap auditors found: "We'd run the same Excel-based review for three years. Same process, same effort, same problems. Auditors asked what we'd improved. We had no answer. That became a finding—lack of continual improvement evidence."

ISO 27001 certification requires demonstrating maturity through continuous improvement, not just operating the same process year after year.

Implementation Timeline: 30 Days to Your First Access Review

Traditional enterprise IGA platforms require 6-12 months of implementation. For organizations pursuing ISO 27001 certification with audits scheduled in 6 months, that timeline fails.

The research firm explained their constraint: "Our ISO audit is in February. If we start implementation in September and it takes until March, we'll miss our certification window and lose the contract that required certification."

We deploy risk-based access reviews in 30 days:

Week 1—Discovery & Classification: Connect to identity providers, HR systems, and finance tools. Multiple discovery methods identify all applications. Automated classification evaluates each system against risk criteria: customer PII storage, financial data processing, administrative access level, regulatory requirements.

Week 2—Risk Assessment: Conduct risk assessment workshop defining frequency matrix based on ISO risk criteria. Document rationale for each tier: monthly for high-risk customer data, quarterly for medium-risk business applications, annual for low-risk collaboration tools. Management approves the approach.

Week 3—Reviewer Configuration: Configure reviewer assignments per risk tier. Assign department heads their team rosters. Identify application owners for each system. Assign security team for privileged access review. Designate fallback reviewers for coverage gaps.

Week 4—Pilot & Production: Execute first pilot review for 2-3 systems spanning risk tiers. Generate evidence packages. Internal audit reviews against ISO requirements. Production rollout—all systems enter risk-appropriate review schedules with automated workflows enforcing processes.

By day 30, you're running risk-based reviews generating certification-ready evidence. This compressed timeline matters because ISO 27001 certification requires demonstrating sustained operation. Starting fast means you have multiple review cycles completed by certification audit, showing both design and operating effectiveness.

Getting to Certification Efficiently

ISO 27001 consulting typically follows a waterfall sequence: months of documentation (policies, procedures, risk assessments, training materials), then implementation, then evidence collection, then certification audit 12-18 months later.

This sequence creates a documentation-reality gap. You commit to monthly reviews for high-risk systems without testing whether IT can sustain that cadence. Your risk assessment identifies 35 high-risk systems before visibility reveals you actually have 87. Your procedures look rigorous on paper but fail operationally.

Certification audits test both design and operating effectiveness. Design: Are your procedures appropriate? Operating effectiveness: Do they actually work when executed?

A Faster Path: Visibility, Operation, Documentation

Start with reality—what applications exist, who has access, what risk they represent. Deploy access reviews immediately. Collect 3-6 months of execution data showing actual violation patterns, remediation timelines, and process efficiency. Use that operational data to inform your risk assessment, validate frequency decisions, and refine procedures.

When certification auditors arrive, you show them a mature, proven process with months of consistent operation and measurable improvement trends. Not theoretical procedures you've never tested.

What You Need for ISO 27001-Compliant Access Reviews

Risk-based scheduling lets you configure different review frequencies for different risk tiers. High-risk customer data systems get monthly reviews. Medium-risk business applications get quarterly reviews. Low-risk collaboration tools get annual reviews. The platform enforces your documented frequency automatically ensuring PDCA consistency.

Complete asset visibility through multiple discovery methods ensures all information systems are identified and classified before reviews begin. ISO 27001 requires knowing what assets exist (Control A.8.1.1). Continuous visibility maintains accurate asset inventory required by ISMS, showing not just applications but who has access and when they last used it.

Contextual review data shows risk indicators during certification: last login date (identify dormant accounts), assigned role and privilege level (identify over-privileged access), department and employment status (identify access persisting after role changes), AI-generated risk flags (privileged, external, dormant).

Flexible reviewer assignment routes work appropriately. Department heads review their teams. Application owners review their systems. Security reviews high-risk and privileged access. Configure multi-level reviews for sensitive applications: Manager validates business need → App owner validates technical appropriateness → Security validates policy compliance.

Automated evidence generation creates a timestamped audit trail for every review showing who reviewed what, when, with what result. Evidence format aligns with ISO 27001 certification auditor expectations. Export evidence packages on-demand showing reviewer decisions, attestations, remediation logs, before/after proof.

Closed-loop remediation demonstrates operating effectiveness through automated remediation. Issues identified get fixed immediately via API where supported, or route as tickets to app owners with complete context. Before/after proof captured automatically showing control actually works, not just exists.

Continual improvement metrics through built-in dashboards track efficiency, effectiveness, and trends quarter-over-quarter demonstrating PDCA cycle. Show violations decreasing over time (upstream provisioning improving). Show review time decreasing (process optimization working). Show coverage increasing (visibility finding previously unknown systems). Export metric reports for management review meetings.

Why GRC Platforms Fall Short on Access Reviews

GRC platforms excel at managing your overall compliance program—policy management, risk registers, control mapping, audit workflows, vendor assessments. They provide the governance framework ISO 27001 requires.

But their access review capabilities are typically basic, built as a checkbox feature rather than a core competency.

The gaps we see consistently:

No SaaS visibility. GRC platforms assume you already have complete application visibility. They fetch user data from your SSO provider and call that comprehensive. But SSO covers 30-40% of your application estate. Shadow IT, departmental purchases, apps with direct login—none of these appear in SSO-based discovery. You're reviewing access for a fraction of your actual risk surface.
No remediation for SaaS applications. GRC platforms identify violations but can't fix them. They generate reports showing "revoke this access" but can't execute the revocation. For SaaS applications, that means manual work—logging into each app, finding the user, removing access, documenting the change. Multiply across dozens of applications and hundreds of violations.
No multi-instance support. Organizations often run multiple instances of the same application—production and development Salesforce, regional Slack workspaces, separate Jira instances for different business units. GRC platforms typically treat these as a single application, missing instance-specific access patterns and risk profiles.
No service account governance. GRC platforms focus on human user accounts tied to your identity provider. Service accounts fall outside their visibility. These accounts often have elevated privileges and represent significant risk, but GRC platforms weren't designed to govern them.

A healthcare organization explained why they needed focused IGA capabilities alongside their GRC platform: "Our GRC platform handles our overall ISO program well—risk registers, policy management, audit coordination. But its access reviews were too basic. No visibility into our SaaS apps beyond SSO. No way to actually revoke access when we found violations. No support for our multiple Salesforce instances. We needed Zluri specifically for access reviews—it deployed in 30 days and gave us the evidence our auditors needed. Our GRC platform handles overall compliances. Zluri handles access reviews and overall identity governance."

ISO 27001 rewards organizations that demonstrate continuous improvement through data. Risk-based access reviews with complete visibility, contextual decision support, and PDCA metrics are what certification auditors validate.

See risk-based access reviews for ISO 27001 → Book Demo

Frequently Asked Questions

What is ISO 27001 and why does it matter?
ISO 27001 is an international standard for information security management systems (ISMS). Organizations pursue certification to demonstrate security maturity to customers, partners, and regulators. Unlike prescriptive frameworks, ISO 27001 requires risk-based approaches where you determine appropriate controls based on your risk assessment.

What is Control A.9.2.5 about access reviews?
Control A.9.2.5 requires regular reviews of user access rights at intervals appropriate to the risk. Unlike frameworks with fixed frequencies, ISO 27001 expects you to determine review frequency based on your risk assessment—high-risk systems may need monthly reviews, low-risk systems may need only annual reviews.

How often do I need to conduct ISO 27001 access reviews?
There's no prescribed frequency. You determine appropriate intervals based on risk assessment considering asset criticality, access privilege level, user population, breach impact, and historical control effectiveness. High-risk systems typically warrant monthly or quarterly reviews, medium-risk quarterly or semi-annual, low-risk annual.

What's the difference between ISO 27001 and SOX/PCI access reviews?
SOX mandates quarterly reviews. PCI requires a semi-annual minimum. ISO 27001 requires risk-based frequencies you must justify. This flexibility is powerful but creates a burden—you must document why your chosen frequency is appropriate for each risk tier and prove you're executing consistently.

What is PDCA and why does it matter for certification?
PDCA (Plan-Do-Check-Act) is the continuous improvement cycle ISO 27001 requires. Auditors test whether you're improving access review processes over time through metrics, process optimizations, and documented enhancements. Running the same static process year after year suggests stagnant ISMS maturity and can result in findings.

Why don't Excel-based reviews satisfy ISO 27001 auditors?
Excel-based reviews create three problems: no documented frequency rationale (difficult to justify risk-based approach), no evidence of continuous improvement (static process suggests stagnant maturity), no proof of complete coverage (manual compilation might miss applications or users).

What evidence do ISO 27001 auditors require?
Auditors require: documented risk assessment linking to review frequencies, access review results with timestamps and reviewer identities, remediation logs with before/after proof, management review minutes showing PDCA discussion, metrics demonstrating improvement trends over time, procedures showing frequency adjustments based on risk changes.

Do service accounts need to be included in reviews?
Yes. ISO 27001 Control A.9.2.5 requires reviewing all access rights, including service accounts. These are often forgotten because they lack traditional attributes (no employee ID, no manager, no last login), but they represent significant risk through elevated privileges and long-lived credentials.

How long does ISO 27001 certification take?
Traditional consulting approaches run 12-18 months from start to certification. A faster path: deploy access reviews immediately (30 days), collect 3-6 months of operational evidence showing actual execution and improvement trends, then proceed to certification audit with mature, proven processes rather than theoretical procedures.

Can I use the same review frequency for all systems?
Technically yes, but auditors will challenge it. If your risk assessment identifies high-risk and low-risk systems but you review them at the same frequency, auditors will ask for documented justification. Risk-based approach means different risks warrant different frequencies—that's a core ISO 27001 principle.

‍