Annex A Controls

A.5.15 through A.5.18 — Access Control Done Properly

Alex Fuerst

13 Sep 2025 — 6 min read

Control A.5.15: Access Control Policy That Actually Works

Control A.5.15 requires establishing and implementing rules for controlling physical and logical access to information and other associated assets based on business and information security requirements. The key word here is "implementing" — I've seen countless organizations with beautiful access control policies that exist purely in documentation while actual access decisions happen through informal processes that nobody has mapped or reviewed.

The control guidance in ISO/IEC 27002:2022 emphasizes several critical elements that most organizations miss. First, your access control rules must consider "determining which entities require which type of access" — note that "entities" includes both human users and technical items like machines, devices, and services. Yet when I audit organizations, their access control policies typically only address human users, completely ignoring service accounts, API keys, and machine-to-machine authentication.

Your access control policy must operationally connect to your actual provisioning processes. The standard specifically mentions "segregation of access control functions" — separating access request, access authorization, and access administration. This means the person requesting access shouldn't be the same person approving it, and ideally, neither should be the person implementing it. In smaller organizations, this might require creative controls like requiring two-person authorization for privileged access or implementing automated approval workflows with audit trails.

The policy should explicitly reference your information classification scheme (Control 5.12) and ensure access rights align with data sensitivity levels. I frequently find organizations with elaborate classification systems that have no connection to their actual access controls. If you've classified data as "Confidential" but your access policy doesn't specify different controls for confidential versus public information, you're not implementing access control — you're implementing access theater.

What the auditor looks for: Evidence that your access control policy directly influences day-to-day access decisions. I'll ask to see access requests from the past month and trace them back to your policy requirements. Can you show me where your policy dictated the approval process? How does your policy handle exceptions? What happens when someone needs urgent access outside normal business hours?

Control A.5.16: Identity Management Beyond User Accounts

Control A.5.16 covers the complete identity lifecycle, but modern organizations face identity complexity that goes far beyond traditional user accounts. You're managing employee identities across federated systems, contractor accounts with time-limited access, service accounts for applications, API credentials for system integrations, and potentially customer or partner identities accessing your systems.

The standard requires "unique identification" for accountability, but this becomes nuanced in practice. Service accounts shared across applications create accountability gaps. Break-glass or emergency accounts violate uniqueness by design. Shared functional accounts in legacy systems can't always be eliminated immediately. Your identity management process needs to explicitly address these scenarios with compensating controls like enhanced monitoring or session recording.

For identity lifecycle management, the creation process needs appropriate authorization that varies by identity type. A new employee account might auto-provision from HR feeds, but a new service account with database access should trigger security review. The modification process is equally critical — when someone changes roles, their access should change accordingly, not accumulate permissions from previous roles.

Here's where most organizations fail: identity removal. I once audited a healthcare organization where we found an active account for an employee who had left two years prior. That account retained elevated access to patient records. The departure was processed correctly in HR, but the technical account removal process had failed, and nobody was monitoring for these gaps.

Your identity management process should integrate with HR systems for employee lifecycle events, but also needs processes for non-employee identities. Contractor accounts need expiration dates. Service accounts need ownership documentation. API keys need rotation schedules. Most importantly, you need regular reconciliation between your identity sources and your target systems to catch provisioning failures.

Control A.5.17: Authentication Information Management

Control A.5.17 addresses authentication information management — essentially, how you handle passwords, keys, tokens, and other authentication credentials. The standard requires that authentication information be "unique, of sufficient length, complex and protected during storage and transmission."

In practice, this control extends beyond password policies to encompass the entire authentication ecosystem. Multi-factor authentication (MFA) is becoming baseline rather than enhanced security, especially for privileged access. But MFA implementation varies dramatically in effectiveness. SMS-based MFA provides minimal protection against sophisticated attacks, while hardware tokens or authenticator apps offer stronger security.

For privileged accounts, consider requiring phishing-resistant authentication methods like FIDO2/WebAuthn or certificate-based authentication. The standard's emphasis on "sufficient length" reflects modern understanding that length matters more than complexity — a 12-character passphrase is typically stronger and more usable than an 8-character password with special characters.

Authentication information storage presents particular challenges for service accounts and API keys. These credentials often need to be accessible to automated systems, creating tension between security and operational requirements. Solutions include secure credential vaults, hardware security modules for key storage, or rotating credentials with short lifespans.

What the auditor looks for: Evidence of consistent authentication requirements across all system types. I'll sample different applications and verify they enforce the same baseline authentication policies. For privileged access, I want to see enhanced authentication controls and evidence of regular review.

Control A.5.18: Access Rights Management in Practice

Control A.5.18 requires that access rights be "provisioned, reviewed, modified and removed in accordance with the organization's topic-specific policy." This control is where access control theory meets operational reality, and where most organizations demonstrate significant gaps between policy and practice.

The provisioning process must include proper authorization from information asset owners before granting access. In practice, this means someone who understands the business value and sensitivity of the information should approve access requests, not just IT administrators. For a financial system containing customer account data, approval should come from someone who understands the regulatory and business implications of that access, not just someone with administrative privileges.

Access rights reviews represent the most critical aspect of this control and the area where I see the most audit failures. The standard requires "regular reviews" but doesn't specify frequency — that depends on your risk assessment and business requirements. However, privileged access should be reviewed more frequently than standard user access, and access to highly sensitive information should be reviewed more frequently than access to public information.

Effective access reviews require more than just listing current permissions. Reviewers need context about what access rights actually enable and why they were originally granted. Many organizations provide reviewers with incomprehensible technical permission lists without business context, leading to rubber-stamp approvals that miss inappropriate access.

The modification and removal processes are equally critical. When someone changes roles, their access should reflect their new responsibilities, not accumulate permissions from previous roles. This requires a formal process for role changes that includes access review and adjustment. For terminations, access removal should be immediate for high-risk departures and systematic for all departures.

Common Implementation Mistakes

I frequently encounter organizations using "cloning" for access provisioning — copying permissions from someone in a similar role. The standard specifically warns about this approach, noting it "has an inherent risk of resulting in excessive access rights." Each cloned permission set carries forward accumulated exceptions, temporary grants, and mistakes from previous users.

Another common mistake involves treating access reviews as compliance exercises rather than security controls. I've seen organizations conduct quarterly access reviews where 95% of access is automatically renewed without meaningful review. This doesn't satisfy the control's intent of ensuring access remains appropriate and necessary.

Emergency access procedures often bypass normal access controls entirely. While business requirements may necessitate emergency access, these procedures should include enhanced monitoring, limited duration, and post-incident review to ensure emergency procedures weren't abused.

Integration with Related Controls

These access control measures must integrate with your supplier management framework (Controls 5.19-5.22) when third parties require access to your systems. Supplier access should follow the same authorization, review, and removal processes as internal access, with additional consideration for contractual obligations and liability limitations.

The controls also connect to your incident management process (Controls 5.24-5.27). Inappropriate access often indicates policy violations or potential security incidents that require investigation and response. Your access monitoring should feed into your incident detection capabilities.

For organizations handling personal data, these controls support compliance with privacy regulations like GDPR through Control 5.34. Access to personal information requires additional consideration for data minimization and purpose limitation principles.

What the auditor looks for: Documentation of access decisions, evidence of regular access reviews with meaningful outcomes, and proof that access removal processes actually work. I'll test a sample of terminated employees and verify their access was properly removed across all systems. For access reviews, I want to see evidence that reviewers understood what they were approving and made informed decisions about appropriateness.

Effective access control isn't about implementing the most restrictive possible policies — it's about implementing controls that balance security requirements with business needs while ensuring consistent application across your entire organization. The key is making these controls part of your operational culture rather than compliance exercises that happen periodically and get forgotten until the next audit.

Need help implementing these access controls effectively? Connect with other ISO 27001 practitioners at the IX ISO 27001 Info Hub for practical implementation guidance, or reach out for specialized consultation on access control architecture and audit preparation.

Need personalized guidance? Reach our team at ix@isegrim-x.com.