ISO 27001 A.5.15: Access Control

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 5.15 asks for rules that control physical and logical access to information and other associated assets, based on business and information 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 Control Asks For

The Control in Brief

In short:

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.

Do you need this control?

A.5.15 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Essentially every organisation with systems and data includes it. What varies is the model (role-based, attribute-based) and the depth of documentation, which should match your size and risk.

What ISO 27002:2022 Adds

ISO/IEC 27002 guidance for 5.15 (paraphrased). Information owners decide the access requirements, and a topic-specific access control policy, communicated to relevant parties, should consider:

• who needs which type of access to which information and assets
• security of applications (A.8.26)
• physical access: backed by physical entry controls (A.7.2, A.7.3, A.7.4)
• need-to-know and classification of information (A.5.10, A.5.12, A.5.13)
• restrictions on privileged access (A.8.2) and segregation of duties (A.5.3)
• legal, regulatory and contractual limits on access to data or services (A.5.31 to A.5.34, A.8.3)
• segregation of access control functions: requesting, authorising and administering access are done by different people
• formal authorisation of access requests and management of access rights (A.5.16, A.5.18)
• logging (A.8.15)

When defining the rules, keep access rights consistent with classification and with physical perimeter needs, cover every type of connection (networks and network services included), and decide how dynamic factors such as location or device can be reflected. 27002 also recommends least privilege ("everything is forbidden unless expressly permitted"), need-to-know and need-to-use, and notes that RBAC, ABAC, MAC and DAC are all valid models: business needs and risk decide how granular the rules should be.

MFA, password rules, session controls and PAM are not part of 5.15 itself. They come from A.8.5 (secure authentication), A.5.17 (authentication information) and A.8.2 (privileged access rights), chosen through your risk assessment.

What Auditors Usually Look For

None of these is mandated by ISO; they are what auditors typically ask to see for A.5.15.

Relationship to Other Controls

Physical Access Rules

The access control policy covers physical as well as logical access, and the two should be consistent: someone who may not open a system remotely should not be able to walk into the room that hosts it.

• Define zones (public, office, restricted, server or network room) and who may enter each, by role
• Grant badges by the same request-and-approve process as system access, and remove them at exit (A.5.18, A.5.11)
• Review physical access lists with logical access reviews
• Log entry to restricted areas and investigate anomalies (A.7.2)

Why Access Control Is the Foundation of Security

The Access Control Pyramid

                    ┌─────────────┐
                    │  RESTRICTED  │  (Board papers, keys, bulk customer data)
                    │   Access     │  (Phishing-resistant MFA + JIT)
                    ├─────────────┤
                    │ 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                          │
│              (Microsoft Entra ID / 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 │          │Microsoft Entra PIM│
   │  Azure  │          │Delinea  │          │Okta     │
   │  PIM    │          │BeyondTrust│        │         │
   └─────────┘          └─────────┘          └─────────┘

Authentication Methods

Authentication Comparison

Password Policy Requirements

ISO 27001 sets no password rules. A.5.17 asks for a process for authentication information; current practice follows NIST SP 800-63B.

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: About 8 Weeks for the Basics

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 Microsoft Entra ID 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 Microsoft Entra 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 → Microsoft Entra ID 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: Neither: A.5.15 sets the access rules; authentication strength comes from A.8.5 and your risk assessment. In practice auditors expect MFA at least for privileged, remote and internet-facing access, and MFA for all users is now normal good practice, with phishing-resistant methods for admins.

Q: Can we use shared admin accounts in small organizations?
A: Only where genuinely necessary. 27002 (5.16) allows shared identities when needed for business or operational reasons, with approval and documentation. Prefer individual admin accounts; if a shared account is unavoidable, vault the password, log who checked it out, and review it regularly.

Q: How often should access reviews be conducted?
A: ISO sets no frequency; base it on risk. A common pattern: privileged and third-party access quarterly, standard access semi-annually, plus reviews when roles change or after incidents.

Q: What is the minimum password policy for ISO 27001?
A: ISO 27001 has none. Follow NIST SP 800-63B: long passphrases (15+ characters if the password is the only factor), no forced composition rules or periodic expiry, a breached-password check, and MFA.

Q: Does A.5.15 require PAM for all organizations?
A: No. A.8.2 requires privileged access rights to be restricted and managed, not a particular product. Small organisations can meet it with individual admin accounts, a password vault, MFA and logging; PAM tools make sense as the estate grows.

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.

Industry-Specific Access Control Requirements

Banking and Financial Services (BFSI)

Practice under RBI's Cyber Security Framework for banks (2016, Annex 1) and the IT Governance Master Direction (2023); exact expectations vary by entity:

• 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.
• SWIFT Access: Dedicated, isolated operator terminals, MFA and the other mandatory controls of the SWIFT Customer Security Controls Framework (CSCF).
• Third-Party Access: Vendor access to banking systems must be through a bastion host with MFA, session recording, and time-limited sessions approved per task.

BFSI Access Control Matrix Example:

Healthcare

Healthcare practice (DPDP Act duties; NABH accreditation standards):

• 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

Government and critical infrastructure practice (NCIIPC guidance for CII; MHA security instructions for classified data):

• 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.
• 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

Figure · Tiers

Maturity levels for access control

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

More Questions

Q: 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.

Q: 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.

Q: 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.

Q: Can we use biometric authentication for ISO 27001? A: Yes, biometrics (fingerprint, face, iris) are acceptable and often more secure than passwords. However: (1) Under the DPDP Act, employee biometrics for attendance and access fall under employment-related legitimate use (s.7(i)), but tell staff what you collect and why, (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.

Q: 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 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

Last year, 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 monetary penalty for inadequate cyber security controls. The NBFC reported the breach to CERT-In within 6 hours, as the 2022 Directions require.
• Customer Trust: 400+ customers closed their accounts. Social media coverage damaged the brand.
• Legal: Customers complained to the NBFC and the RBI Ombudsman. Once the DPDP Act's duties apply, a breach like this can draw Data Protection Board penalties of up to ₹250 crore; the Act gives individuals no compensation claim, so customers would sue under other law.

Remediation

The NBFC implemented 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

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-cost 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: Verifiable credentials let users prove facts (employment, qualifications, age) without revealing the underlying data. In India, DigiLocker already issues digitally verifiable documents; W3C verifiable credentials are the emerging standard.

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.

References

• ISO/IEC 27001:2022, Annex A 5.15; ISO/IEC 27002:2022, 5.15 (consulted, paraphrased)
• NIST SP 800-53 Rev. 5 (AC-1, AC-3, AC-6); NIST SP 800-63B (Digital Identity Guidelines)
• NIST Cybersecurity Framework 2.0 (2024)
• PCI DSS v4.0.1, Requirements 7 and 9
• CIS Controls v8, Control 6
• RBI Cyber Security Framework in Banks (2016) and Master Direction on IT Governance, Risk, Controls and Assurance Practices (2023)
• SWIFT Customer Security Controls Framework
• Digital Personal Data Protection Act, 2023 and DPDP Rules, 2025
• Verizon Data Breach Investigations Reports 2024 and 2025

Document Control

• Version: 1.1
• Review Cycle: Annual + event-triggered
• Next Review: June 2027