ISO 27001 A.5.15: Access Control

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 5.15 requires rules to be established to control access to information and systems based on business and security requirements.

The Bottom Line: If everyone can access everything, you have no security. Access control is the gatekeeper of your entire information security program.

What the Standard Actually Requires

The ISO 27001:2022 Text

Annex A 5.15 states:

ISO 27001:2022 Annex A 5.15 asks organizations to set and implement rules to control physical and logical access to information and associated assets, based on business and security requirements.

What ISO 27002:2022 Adds

The implementation guidance requires:

• Access control policy documented and approved
• User registration and de-registration process
• Privilege management (granting, modifying, revoking)
• Regular access reviews and recertification
• MFA for privileged and sensitive access
• Password and authentication policy
• Session management (timeout, lockout)
• Access control for systems, applications, data, network
• Privileged access management (PAM)
• Shared account management
• Remote access controls
• Third-party access controls
• Emergency/break-glass access

The Six Mandatory Components

Why Access Control Is the Foundation of Security

The Access Control Pyramid

                    ┌─────────────┐
                    │  RESTRICTED  │  (Top Secret, CEO, Board)
                    │   Access     │  (MFA + PAM + JIT + Biometric)
                    ├─────────────┤
                    │ CONFIDENTIAL │  (Finance, HR, Customer Data)
                    │   Access     │  (MFA + PAM + Role-Based)
                    ├─────────────┤
                    │   INTERNAL   │  (Employees, Standard Systems)
                    │   Access     │  (Standard Auth + MFA Preferred)
                    ├─────────────┤
                    │    PUBLIC    │  (Website, Marketing, No Auth)
                    │   Access     │  (No Auth or Basic Auth)
                    └─────────────┘

Access Control Failure Statistics

Access Control Principles

Core Principles

Role-Based Access Control (RBAC)

RBAC Model

RBAC Implementation

Attribute-Based Access Control (ABAC)

ABAC Model

ABAC Policy Examples

Policy-Based Access Control (PBAC)

PBAC vs RBAC vs ABAC

PBAC Implementation

Privileged Access Management (PAM)

PAM Requirements

PAM Architecture

┌─────────────────────────────────────────────────────────────┐
│                        PAM PLATFORM                         │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │   VAULT     │  │   SESSION   │  │   WORKFLOW  │         │
│  │  Passwords  │  │  Recording  │  │  Approval   │         │
│  │  Keys       │  │  Monitoring │  │  JIT        │         │
│  │  Certificates│  │  Analytics  │  │  Rotation   │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │  DISCOVERY  │  │   ANALYTICS │  │    CLOUD    │         │
│  │  Scan AD    │  │  UEBA       │  │  AWS/Azure  │         │
│  │  Scan Cloud │  │  Anomaly    │  │  GCP PAM    │         │
│  │  Scan Apps  │  │  Reporting  │  │  SaaS PAM   │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
└─────────────────────────────────────────────────────────────┘
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
   ┌────▼────┐          ┌────▼────┐          ┌────▼────┐
   │ SERVERS │          │ CLOUD   │          │  APPS   │
   │ Linux   │          │ AWS     │          │ Database│
   │ Windows │          │ Azure   │          │ Code    │
   │ Network │          │ GCP     │          │ CI/CD   │
   └─────────┘          └─────────┘          └─────────┘

Identity and Access Management (IAM) Architecture

IAM Components

IAM Architecture Diagram

┌──────────────────────────────────────────────────────────────┐
│                      IDENTITY PROVIDER                          │
│              (Azure AD / Okta / Ping Identity)                │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐      │
│   │   SSO    │  │   MFA    │  │ Lifecycle│  │   PIM    │      │
│   │  SAML    │  │  TOTP    │  │  SCIM   │  │   JIT    │      │
│   │  OAuth   │  │  FIDO2   │  │  Workday│  │ Approval │      │
│   │  OIDC    │  │  Push    │  │  HRIS   │  │  Review  │      │
│   └──────────┘  └──────────┘  └──────────┘  └──────────┘      │
└──────────────────────────────────────────────────────────────┘
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
   ┌────▼────┐          ┌────▼────┐          ┌────▼────┐
   │  CLOUD  │          │ ON-PREM │          │  SAAS   │
   │  AWS    │          │  AD     │          │ Office  │
   │  Azure  │          │  LDAP   │          │ Google  │
   │  GCP    │          │  Apps   │          │ Salesforce│
   └─────────┘          └─────────┘          └─────────┘
        │                     │                     │
   ┌────▼────┐          ┌────▼────┐          ┌────▼────┐
   │  PAM    │          │  PAM    │          │  PAM    │
   │  AWS IAM│          │CyberArk │          │Azure PIM│
   │  Azure  │          │Delinea  │          │Okta     │
   │  PIM    │          │BeyondTrust│        │         │
   └─────────┘          └─────────┘          └─────────┘

Authentication Methods

Authentication Comparison

Password Policy Requirements

Multi-Factor Authentication (MFA)

MFA Requirements by Role

MFA Implementation

Access Control for Cloud

Cloud IAM Best Practices

Cloud IAM Controls

Access Control for Databases

Database Access Control

Database Access Best Practices

Access Control for Applications

Application Access Control

Application Authorization Patterns

Access Control for APIs

API Security Model

Access Control for Remote Work

Remote Access Controls

Access Control for Third Parties

Third-Party Access Controls

Access Reviews and Recertification

Access Review Schedule

Access Review Process

ACCESS REVIEW PROCESS

1. Initiation
   - Automated trigger (schedule) or manual trigger (event)
   - Generate access review report for reviewer
   - Notify reviewer via email + dashboard

2. Review
   - Reviewer logs into access review tool
   - Reviews each user's access to their resources
   - For each access: Approve, Revoke, or Reassign
   - Comments required for Revoke or Reassign
   - Can delegate review to another reviewer

3. Approval
   - Reviewer submits completed review
   - Manager of reviewer approves (if required)
   - Security reviews exceptions (if any)

4. Action
   - Approved access: No action, access continues
   - Revoked access: Access removed within 24 hours
   - Reassigned access: Access modified per reassign request
   - No response: Escalate to manager, then revoke

5. Documentation
   - Review record saved in audit trail
   - Access changes logged in IAM
   - Exceptions documented and approved
   - Report generated for audit

6. Follow-up
   - Verify revoked access is removed
   - Verify no orphaned accounts
   - Update risk register if exceptions
   - Report to CISO

Just-in-Time (JIT) Access

JIT Access Model

JIT Implementation

Break-Glass and Emergency Access

Break-Glass Requirements

Tool Comparison

Implementation Roadmap: 8 Weeks

Common Audit Failures and Fixes

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: SaaS Company Implements Zero Trust with MFA and PAM

Company: 500-employee SaaS, no MFA, shared admin accounts, excessive privileges
Challenge: Audit finding on A.5.15, no MFA, shared admin accounts, no access reviews
Solution:

1. Deployed Azure AD as identity provider with SSO for all 200+ applications
2. Implemented MFA for all users (TOTP app + push notification)
3. Implemented hardware keys (YubiKey) for all admin accounts (50+ admins)
4. Deployed Azure PIM for just-in-time privileged access
5. Eliminated all shared admin accounts, created individual admin accounts
6. Implemented quarterly access reviews for all applications
7. Implemented automated de-provisioning via Workday → Azure AD integration
8. Deployed Conditional Access for device compliance, location, and risk
9. Implemented PAM for database and server access (CyberArk)
10. Implemented break-glass procedure with pre-approved emergency accounts

Outcome: 100% MFA adoption. Zero shared admin accounts. Access reviews completed quarterly with 95% manager participation. Unauthorized access incidents reduced by 90%. Passed ISO 27001 audit with zero findings on A.5.15.

Illustrative Scenario 2: Bank Implements RBAC and PAM for 2,500 Employees

Company: 2,500-employee bank, 500+ roles, no RBAC, shared admin accounts, manual access management
Challenge: RBI requirement for access control, no RBAC, manual process, audit finding
Solution:

1. Designed 200+ standardized roles across all departments
2. Implemented SailPoint for identity governance and access management
3. Implemented CyberArk for privileged access management (300+ admin accounts)
4. Implemented MFA for all users (hardware tokens for high-risk, app for standard)
5. Implemented monthly access reviews for all privileged access
6. Implemented quarterly access reviews for all standard access
7. Implemented SoD rules (separation of duties) for finance and payments
8. Implemented JIT access for production database and server access
9. Implemented break-glass procedure with dual control and enhanced logging
10. Implemented automated provisioning and de-provisioning via HR system integration

Outcome: 100% RBAC coverage. All admin accounts vaulted in CyberArk. Access reviews automated with 98% manager participation. SoD violations detected and resolved within 24 hours. RBI audit passed with no findings. Internal fraud attempts reduced by 80%.

Multi-Framework Mapping

FAQ

Q: Does A.5.15 require MFA for all users or just admins?
A: MFA is required for all privileged access and highly recommended for all users. Best practice is MFA for all users, with hardware keys for admins. The standard requires MFA for sensitive access at minimum.

Q: Can we use shared admin accounts in small organizations?
A: No. Shared accounts violate accountability. Even in small organizations, use individual admin accounts with PAM. If absolutely necessary, document the exception and implement compensating controls (enhanced logging, session recording, regular review).

Q: How often should access reviews be conducted?
A: Privileged access: monthly. Standard access: quarterly. Third-party access: monthly. Annual recertification for all access. Event-triggered reviews for role changes, incidents, and reorganizations.

Q: What is the minimum password policy for ISO 27001?
A: Minimum 8 characters, complexity (3 of 4: upper, lower, number, special), 90-day expiration, 5-password history. Best practice: 12+ characters, passphrase, no expiration if MFA is enabled, 12+ history, compromised password check.

Q: Does A.5.15 require PAM for all organizations?
A: Yes, for any organization with privileged accounts (admins, DBAs, root). If you have admin accounts, you need PAM. For very small organizations, use vaulting and session recording as a minimum.

Q: Can we use passwordless authentication?
A: Yes, passwordless (FIDO2/WebAuthn, Windows Hello, passkeys) is highly recommended and often more secure than passwords. It is acceptable for ISO 27001 if properly implemented.

Q: How do we handle service accounts?
A: Service accounts should be vaulted, rotated regularly, have minimal privileges, be non-interactive, and monitored. Use PAM or secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for service account management.

Q: What is the minimum evidence for A.5.15?
A: Access control policy, user account list, role definitions, access matrix, access review records, MFA enrollment records, PAM configuration, privileged access logs, and session records.

Q: Does A.5.15 require network access control (NAC)?
A: Not explicitly, but NAC is recommended for network-level access control. At minimum, implement network segmentation, VPN for remote access, and firewall rules.

Q: How do we handle BYOD access control?
A: Use MDM for device compliance, conditional access for device health, ZTNA for application access, and containerization for data separation. Require MFA for all BYOD access.

Need help? Contact us for a 20-minute readiness call.

Industry-Specific Access Control Requirements

Banking and Financial Services (BFSI)

RBI Cyber Security Framework Requirements:

• Privileged Access: All privileged access to core banking systems must be through PAM with session recording and approval workflows. No direct root/admin access.
• Segregation of Duties: Critical functions (transaction initiation, authorization, and reconciliation) must be separated. No single person should have end-to-end control.
• Customer Data Access: Access to customer PII and transaction data must be logged, limited to need-to-know, and subject to quarterly recertification.
• ATM Access: ATM service personnel must use unique credentials, be escorted, and have time-limited access. All ATM access logged with CCTV correlation.
• SWIFT Access: Dedicated SWIFT terminals with no internet access, biometric authentication, and transaction signing with hardware tokens.
• Third-Party Access: Vendor access to banking systems must be through a bastion host with MFA, session recording, and time-limited access (maximum 8 hours).

BFSI Access Control Matrix Example:

Healthcare

NABH and Data Protection Requirements:

• Patient Record Access: Role-based access where doctors see their patients, nurses see assigned wards, and administrators see operational data only. All access logged with user ID, timestamp, and action.
• Emergency Access: Break-glass procedures for emergency access to patient records (e.g., unconscious patient in ER). All break-glass access automatically flagged for review.
• Research Data: Anonymized research datasets require separate access controls. Researchers must not be able to re-identify patients.
• Third-Party Access: Insurance companies, government health programs, and vendors must have strictly limited, time-bound access. All third-party access monitored.
• Medical Device Access: IoT medical devices must be on isolated networks with no direct access to patient records or internet.

Healthcare Access Control Risks:

• Snooping: Healthcare staff accessing records of celebrities, neighbors, or family members. Implement alerts for unusual access patterns.
• Ransomware: Healthcare is a prime ransomware target. Strict access controls reduce lateral movement.
• Insurance Fraud: Unauthorized access to patient data for insurance fraud. Implement need-to-know and access logging.

Government and Critical Infrastructure

NCIIPC and MeitY Requirements:

• Classification-Based Access: Access to Top Secret, Secret, and Confidential data must be strictly controlled with multi-person approval and enhanced logging.
• Citizen Data Access: Access to Aadhaar, PAN, tax, and other citizen data must be logged, limited to authorized personnel, and subject to regular audit.
• Critical Infrastructure: Power, telecom, and transport systems must have air-gapped access controls. No internet-connected privileged access.
• Election Systems: EVM and VVPAT access must be restricted to election commission officials with biometric authentication and dual control.
• Defense Systems: Military IT systems require security clearance-based access, compartmentalized access, and physical token authentication.

IT/ITeS and SaaS

Multi-Tenant and Cloud-Specific Requirements:

• Tenant Isolation: Each customer's data must be accessible only to their authorized users. Tenant administrators must not access other tenants' data.
• API Access Control: API keys must be rotated, scoped, and rate-limited. OAuth 2.0 with PKCE for mobile apps.
• Customer Key Management: Enterprise customers may require customer-managed encryption keys (CMEK). Access to these keys must be strictly controlled.
• Dev/Prod Separation: Developers must not have production access. Production changes must be through CI/CD pipelines with approval gates.
• Bug Bounty Access: Controlled access for security researchers with scope limitations and time-bound credentials.

Manufacturing and Industrial

OT/IT Convergence Access Control:

• OT Network Isolation: SCADA, PLC, and DCS systems must be on isolated networks with no direct access from IT networks or internet.
• Maintenance Access: Vendor access to OT systems must be through a secure jump server with session recording and time limits.
• Engineering Workstations: CAD and design systems must have DLP, access logging, and strict egress controls.
• Supply Chain Access: Supplier access to production schedules and quality data must be limited and monitored.

Access Control Maturity Model

Progression Guidance:

• Level 1 → 2: Implement access control policy, basic RBAC, and MFA for admins. (Time: 2-4 weeks)
• Level 2 → 3: Full MFA for all users, PAM for privileged access, automated access reviews, and SIEM integration. (Time: 1-3 months)
• Level 3 → 4: Zero Trust architecture, passwordless authentication, ABAC, and UEBA. (Time: 3-6 months)
• Level 4 → 5: AI-driven access decisions, continuous authentication, and self-healing access controls. (Time: 6-12 months)

Access Control Metrics and KPIs

Additional FAQ

Q11: How do we implement access control for a hybrid workforce? A: Hybrid work requires: (1) ZTNA for all remote access, (2) MFA for every access regardless of location, (3) device compliance checks, (4) DLP for data exfiltration prevention, (5) VPN as a minimum, and (6) enhanced monitoring for remote sessions. Treat remote access as higher risk than on-site access.

Q12: What is Attribute-Based Access Control (ABAC) and when should we use it? A: ABAC grants access based on attributes (user role, department, location, time, device health, data sensitivity). Use ABAC when: (1) RBAC is too rigid, (2) Dynamic access decisions are needed, (3) Complex environments with many variables, (4) Fine-grained control is required. ABAC is more complex to implement but more flexible than RBAC.

Q13: How do we handle access control for contractors and temporary staff? A: Contractors require: (1) Time-limited accounts (auto-expire on contract end), (2) Supervised access (escorted or monitored), (3) Minimal privileges (need-to-know only), (4) Separate contractor domain or VLAN, (5) Signed security agreements, and (6) Immediate de-provisioning on contract termination. Never give contractors privileged access without enhanced controls.

Q14: Can we use biometric authentication for ISO 27001? A: Yes, biometrics (fingerprint, face, iris) are acceptable and often more secure than passwords. However: (1) Consider privacy implications under DPDP Act 2023, (2) Implement secure biometric storage (templates, not raw images), (3) Provide fallback authentication (biometric + PIN), (4) Document biometric data handling in privacy policy, and (5) Allow users to opt out if legally required.

Q15: How do we handle access control during a disaster or emergency? A: Maintain an emergency access procedure: (1) Pre-defined emergency access accounts (vaulted, require dual approval), (2) Break-glass procedures with automatic alerting, (3) Offline access control lists (if systems are down), (4) Physical access procedures for emergency personnel, and (5) Post-incident review of all emergency access. Test emergency procedures during DR drills.

Illustrative Scenario: Chennai NBFC, Access Control Breach to Compliance Success

Background

A Chennai-based non-banking financial company (NBFC) with 300 employees and AUM had grown rapidly over 3 years. Their access control was ad-hoc: shared admin passwords, no MFA, manual access provisioning via email, and no access reviews. Employees had access to systems they didn't need, and former employees' accounts were occasionally forgotten.

The Incident

In August 2024, a former employee used a shared admin password (that was never changed after their departure) to log into the loan management system. They accessed 5,000 customer records, downloaded a partial database, and attempted to sell the data on a dark web forum. The breach was detected when a cybersecurity firm monitoring dark web markets flagged the data for sale.

Root Cause Analysis

1. Shared Admin Passwords: The "admin123" password was shared among 8 IT staff and 2 managers. It was never rotated.
2. No De-Provisioning Process: When employees left, HR sent an email to IT, but there was no tracking or confirmation. 12 former employees still had active accounts 6 months after departure.
3. No MFA: All systems used single-factor authentication. Compromised passwords provided full access.
4. No Access Reviews: Access rights were granted once and never reviewed. Employees accumulated access across multiple roles and projects.
5. No PAM: Database admin, server admin, and application admin credentials were stored in an Excel sheet on a shared drive.
6. No Logging: The loan management system had no centralized logging. The unauthorized access was not detected internally.

Impact

• Data Breach: 5,000 customer records (names, PAN, Aadhaar, phone numbers, loan details) exposed
• Regulatory: RBI imposed a penalty of for inadequate cyber security controls. CERT-In issued a directive to improve within 90 days.
• Customer Trust: 400+ customers closed their accounts. Social media coverage damaged the brand.
• Legal: Class action lawsuit filed by affected customers under DPDP Act 2023.
• Total overhead: s (fines, legal, customer compensation, remediation, reputational damage).

Remediation

The NBFC engaged Singahi to implement a complete access control program:

Phase 1 (Week 1-2):

• Emergency password reset for all admin accounts
• Immediate de-provisioning of all 12 former employee accounts
• Deployment of MFA for all systems (starting with privileged access)
• Quick audit of all active accounts and access rights

Phase 2 (Month 1-2):

• Implementation of PAM (CyberArk) for all privileged accounts
• RBAC redesign with role definitions for each department
• Access review process with quarterly recertification
• Centralized logging with SIEM (Splunk) for all access events

Phase 3 (Month 3-4):

• Automated user provisioning and de-provisioning via HR-IT integration
• ZTNA deployment for remote access
• Passwordless authentication pilot for executives
• Security awareness training for all staff

Phase 4 (Month 5-6):

• ABAC implementation for sensitive customer data
• UEBA deployment to detect anomalous access patterns
• Third-party access management portal
• Annual penetration testing and access control audit

Results:

• Zero unauthorized access incidents in 12 months post-implementation
• Passed RBI cyber security review with full compliance
• 100% MFA enrollment across all 300 employees
• Access review completion rate: 100% quarterly
• Orphan accounts: 0 (automated de-provisioning within 24 hours of HR termination)
• PAM coverage: 100% of privileged accounts
• Total Investment: . Avoided Future overhead: Estimated + crores per incident.

Key Lessons

1. Shared Passwords are a Ticking Time Bomb: Every shared password is a liability. Implement individual accounts and PAM immediately.
2. De-Provisioning is Non-Negotiable: Automated de-provisioning is the only reliable way to prevent former employee access.
3. Access Reviews Prevent Privilege Creep: Without regular reviews, employees accumulate unnecessary access over time.
4. MFA is the Best ROI: MFA prevents 99.9% of automated attacks. It is the highest-impact, lowest-overhead security control.
5. Detection is as Important as Prevention: Without logging and monitoring, breaches go undetected for months. Implement SIEM and UEBA.

Emerging Trends in Access Control

Zero Standing Privileges (ZSP): Instead of granting standing admin access, ZSP provides just-in-time (JIT) access that is requested, approved, time-limited, and automatically revoked. This eliminates the risk of persistent privileged accounts being compromised.

Continuous Authentication: Traditional authentication is a one-time gate. Continuous authentication verifies identity throughout the session using behavioral biometrics, device posture, and location analytics. If behavior deviates from baseline, the session is challenged or terminated.

Decentralized Identity: Blockchain-based identity systems allow users to own and control their credentials. Users present verifiable credentials without revealing underlying data. This is emerging in India with Aadhaar-based verifiable credentials.

AI-Powered Access Decisions: Machine learning models analyze user behavior, resource sensitivity, threat intelligence, and business context to make dynamic access decisions. AI can detect anomalies and automatically restrict access or trigger step-up authentication.

Passwordless-First Strategies: FIDO2/WebAuthn, Windows Hello, and hardware security keys are making passwords obsolete. Google, Microsoft, and Apple have all committed to passwordless futures. Organizations should plan a 3-year passwordless migration roadmap.

Need help? Contact us for a 20-minute readiness call.