A.5.15 Access control: requirements and evidence

What A.5.15 access control requires before an auditor arrives

A.5.15 requires the organization to establish and implement rules that control physical and logical access to information and other associated assets, and those rules must be based on business and information security requirements. Before an auditor arrives, you need a written access control policy that states who may access what, on what basis, and who approves exceptions, plus evidence that the rules were actually put into practice. The control merges two controls from the 2013 edition, A.9.1.1 (access control policy) and A.9.1.2 (access to networks and network services), so the policy now has to cover network access as well as application and physical access.

A.5.15 is the policy layer. The identity, authentication and access rights controls, namely A.5.16, A.5.17 and A.5.18, are where the rules are carried out, and A.8.2 and A.8.3 cover privileged access and restriction of information access. Auditors test whether each rule in the policy traces to a mechanism that enforces it. The hard part is that many organizations hold a policy that says access is role-based and approved, while directories, cloud consoles and network segments still grant access by habit. Before the audit, pick three or four in-scope systems and confirm that each one enforces the rules as written. Ask your identity team which system is the source of truth for each rule.

Confirm the policy's scope against your asset inventory, since A.5.15 applies to physical locations and network services as well as software. The NIST crosswalk for SP 800-53 Rev. 5 relates A.5.15 to AC-1 Policy and Procedures, AC-3 Access Enforcement and AC-6 Least Privilege, which gives you a useful checklist of questions the policy must answer. Evidence for the policy usually includes the approved document, its review record and the reconciliation between rules and configuration. Your certification body will decide what is sufficient, so confirm the expected evidence set with them early.

Which systems, sites and people A.5.15 access rules must cover

The access control rules only work if they reach every place where information is used. Scope decisions about systems, sites, networks, cloud tenants, shared accounts and third parties determine how much of the access work the organization must govern and evidence.

Information systems inside the ISMS scope

Decide which applications, databases, directories and administration consoles hold information within the ISMS boundary. Each one needs a documented access rule that fits its classification. Check whether the inventory of systems matches what the access rules actually cover, because a system left out of scope often ends up with no owner and no review. Confirm the list with system owners before the access policy is approved.

Physical sites and secure areas

Server rooms, records storage, network closets and offices where screens show sensitive data all fall under the physical side of A.5.15. The access rule must say who may enter each area, how that right is granted and removed, and which logs prove it. Check that badge systems, key registers and visitor logs are included in the scope, since auditors often sample physical access alongside logical access.

Network and remote access paths

VPN gateways, wireless networks, remote desktop services and bastion hosts are routes into the information. Each path needs its own access rule, with clear conditions for who may connect from where and on which devices. Confirm that remote access is documented as a separate scope item, because a control that governs office logins alone leaves these routes unaddressed.

Cloud tenants and accounts

Each cloud account, subscription or project that stores or processes in-scope information counts as an access domain. Multiple tenants, shared landing zones and development accounts often fall outside the original scope. Check that every account has a named owner, that administrative roles are listed, and that the access rule covers the provider's console as well as the workloads running inside it.

Shared and non-human accounts

Service accounts, shared mailboxes, break-glass logins and automation credentials can grant access without a named person behind them. The access rule must define who approves each one, who holds the secret, and how use is traced to a purpose. Confirm that every shared or non-human account appears in the identity inventory, since untracked accounts are a common gap in access reviews.

Third parties with access

Contractors, managed service providers, auditors and vendor support staff may log in to systems or enter sites. Decide whether their access falls under the same rules as employees, and document it in the supplier agreement. Check that each third-party account has an end date, a sponsoring employee and a periodic review, so that access does not outlive the contract.

How the access control policy relates to identity and access rights controls

A.5.15 sets the rules: the access control policy that decides who may reach which information and assets, and on what basis. It does not itself create accounts, issue passwords or remove access. Those jobs belong to the controls that implement the rules. A.5.16 Identity management covers the life cycle of each identity, including shared and non-human ones. A.5.17 Authentication information covers how passwords, keys and tokens are issued and handled. A.5.18 Access rights covers provisioning, changes, removal and periodic review of what each identity can do. A.8.2 Privileged access rights and A.8.3 Information access restriction apply the same rules to administrator accounts and to the technical limits placed on data and functions. Before you map these controls to evidence, confirm the wording of each in ISO/IEC 27001:2022 and its guidance in ISO/IEC 27002:2022, because the split is easy to blur in internal documents.

An auditor looks for the join between the policy and the systems. A typical gap is a policy that says access is granted on least privilege and approved by the information owner, while the identity provider grants group membership by default and nobody can name the approver. Another is a policy that requires quarterly reviews, with no review records in the identity system. In both cases the auditor will sample a few real accounts and trace each one back to a written rule and a recorded decision. Practical checks include comparing the policy's approval roles with the approvers recorded in your identity tooling, sampling leavers from the last review period, and confirming that privileged groups have their own owners. Where a self-hosted identity provider such as authentik delegates sign-in to applications, the evidence sits in its configuration and audit trail, and you should confirm which of those records your version can export.

For readers who map controls across frameworks, NIST's crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022 (October 2023) relates A.5.15 to AC-1 Policy and Procedures, AC-3 Access Enforcement and AC-6 Least Privilege. This is a crosswalk relation between two frameworks, not an equivalence, so the NIST control text does not satisfy the ISO requirement on its own. Use it to find related evidence, then confirm the mapping against the wording your auditor accepts. Access reviews are also where the policy is tested most directly. midPoth-style certification campaigns, such as those in midPoint, have designated reviewers decide whether to keep, change or revoke each role assignment within a set period, which gives you a dated record that the policy was applied.

How an assessor tests the access control rules

This table sets out how an assessor typically tests the access control rules for A.5.15, what evidence they ask for and where organizations most often fall short. Read each row as a test step: the approach, the evidence it produces and the gap that tends to surface.

Test area	What the assessor does	Evidence requested	Common findings
Approved policy and scope	Reads the access control policy and checks it names the systems, sites, data classes and asset types it covers, plus who approves and reviews it.	Signed or approved policy version, revision history, scope statement and review record.	Policy exists but omits cloud tenants, SaaS applications or physical areas, or has not been reviewed since the environment changed.
Tracing policy to configuration	Takes each policy statement, such as least privilege or role-based grants, and looks for the setting that enforces it in the identity provider, directory or cloud console.	Screenshots or exports of identity provider groups, role mappings, MFA enforcement settings and application provider configurations.	Policy says access is granted by role, but applications are configured with local accounts or default admin groups.
Sampling access to systems and sites	Selects a sample of systems, applications and secured physical areas and checks who can reach them and whether that matches approved needs.	Access lists per sampled system, approval tickets, badge or door access lists for secure areas.	Former contractors or project members still hold access, or sampled systems have no named owner who approves access.
Network access rules	Reviews how network access to information assets is restricted, including segmentation, firewall rule sets and remote access paths.	Firewall or security group rule exports, network diagrams, VPN and remote access configuration, rule change records.	Broad rules such as any-to-any between segments, or remote access granted outside the approved access control rules.
Reconciling documented rules with actual permissions	Compares the rules in the policy and procedures with the permissions that exist in practice, looking for accumulated or unexplained access.	Permission exports from directories and key applications, reconciliation reports, records of access reviews and corrective actions.	Documented rules describe role-based access, but actual permissions show users holding several roles or direct grants with no recorded justification.
Exceptions and emergency access	Checks how exceptions to the rules are approved, time limited and removed, including break-glass or emergency accounts.	Exception register, approvals with expiry dates, logs of emergency account use and their review.	Exceptions granted verbally with no expiry, or emergency accounts used without a documented reason or follow-up review.

Implementing access control rules in order

This sequence turns A.5.15 from a policy statement into enforced rules, each traceable to a business requirement, a system that enforces it and a review record that shows it still works. Work through the steps in order, because each one produces the input the next step needs.

Define requirements for each information asset
Start by listing the information and other associated assets in scope, using the asset inventory from A.5.9, and record who owns each one. For each asset, document the business need for access, the information security requirements tied to its classification, and any contractual or regulatory limits on who may see or change it. The output is a requirements register with one entry per asset, approved by the asset owner. The step is complete when every in-scope asset has an owner and a stated access need.
Write the access control policy and topic rules
Turn the requirements register into an access control policy that sets the principles, such as least privilege and need-to-know, and the topic-specific rules that apply them. Cover physical access to facilities and secure areas as well as logical access to systems, networks and network services, since A.5.15 covers both. Name the roles that may grant, approve and review access. The output is a draft policy and rule set that refers to the identity, authentication and access rights controls it feeds. The step is complete when each rule can be traced back to a requirement in the register.
Map each rule to an enforcement point
For every rule, identify the system that enforces it: an identity provider for application sign-in, a directory or single sign-on service for Linux and UNIX hosts, network controls for segmentation, or a physical access system for doors and secure areas. Record the rule, the enforcement point, the configuration owner and where the configuration can be inspected. Where a rule has no technical enforcement point, record the manual procedure that covers it. The output is a rule-to-system register. The step is complete when no rule lacks an enforcement point or a documented manual alternative.
Configure and test enforcement
Implement the mapped controls in the self-hosted platforms or infrastructure the organization runs, then test each one with a sample user or device that should be allowed and one that should be refused. For example, a quick test might confirm that a user outside an approved group cannot reach a protected application. Keep the test results, the configuration exports and the change records. The output is a test log per enforcement point. The step is complete when each rule has at least one recorded test that matches the policy.
Approve and communicate the policy
Have the policy and rule set approved by the people named in the policy, usually senior management and the information security function, and record the approval date and version. Then communicate the relevant rules to the people who request, grant or use access, and to the managers responsible for physical areas. Collect acknowledgements where the organization requires them. The output is an approved, versioned policy and a distribution record with acknowledgements. The step is complete when the approved version is the one people can find in the document store.
Run and record the first access review
Before the first formal review, confirm the scope, the reviewers and the decision options: keep, change or revoke. Have each reviewer check current access for their assets against the rule-to-system register, then record every decision and the action taken. Where access is granted through roles, check the role assignments as well as direct grants. Tools such as midPoint can run certification campaigns with designated reviewers and a set timeframe, which helps produce a consistent record. The output is a signed review record with exceptions and their follow-up. The step is complete when every exception has an owner and a closure date.
Keep the rules and records under version control
Store the policy, the rule-to-system register, the test logs and the review records in a controlled repository so that changes are visible. A wiki with page history, such as XWiki, can record what changed, when and by whom, and let reviewers compare versions. Set a review trigger for changes in assets, systems, staffing or contracts, and update the policy and register when one occurs. The output is a version history an auditor can sample. The step is complete when each change to a rule has a dated record linked to its approval.

Who owns access control rules, and what a partner can prepare

Your organization owns the access control policy. Leadership, the information security function and the owners of information and other associated assets decide what access is allowed, who may approve it and how exceptions are handled. The policy must reflect your business and information security requirements, so it cannot be copied from a template and left unexamined. Approval, communication and periodic review are decisions you make and records you keep.

Policy decisions: Define the rules for physical and logical access, including who may grant access to which information and systems.
Approval authority: Name the people who approve the policy and any changes to it, and record those approvals.
Asset owners: Confirm that each system and information set has an owner who decides on access requests for it.
Exceptions: Decide how temporary or emergency access is approved, limited in time and reviewed afterward.
Review cycle: Set how often the policy is reviewed and what triggers an earlier review, such as a new system or a reorganization.

Before engaging anyone, confirm internally who signs the policy and where its approval record will be kept.

Evidence that passes an A.5.15 review and how to keep it current

An assessor testing A.5.15 Access control looks for a written rule set, proof that the rules are enforced in each system, and records showing someone checks them over time. The cards below cover the six artifacts that usually carry that proof, with the routine that keeps each one accurate between audits.

Approved access control policy

This is the written rule set that A.5.15 requires: who may access what, on which basis, and under which approval. Auditors check that it names an owner, carries an approval record, and lists a review date. Keep its version history in a tool that records what changed, when and by whom, so you can show the policy in force on any past audit date. Confirm the policy covers both physical and logical access, since the control names both.

Rule-to-system register

A register maps each access rule in the policy to the systems, applications and network segments that enforce it. Assessors use it to trace a rule to a real setting, so a gap between the policy and the systems shows up quickly. Review the register whenever a system is added, retired or changes its identity source, and record who signed off each change. A short owner column helps, because an unowned system is usually where enforcement quietly stops.

Identity provider and directory configuration exports

Exports of the identity provider and directory settings show how sign-in and group membership are enforced in practice, such as which applications delegate authentication and which providers are configured. Export them on a schedule and store each export with a date, so changes between exports are visible in diff form. Check that the exports cover application providers and single sign-on realms, not only the directory. Protect the exports as sensitive, since they describe your authentication design.

Network access rule sets

Network access rules show which sources can reach which information services, which is the network half of A.5.15 access to networks and network services. Export the rule sets from firewalls, segmentation tools and VPN gateways, and keep them under version control with a change ticket for every edit. Ask whether any rule is a broad allow without a named owner, and whether administrative interfaces are reachable only from management networks. Reconcile the export against the rule-to-system register at each review.

Physical access logs and authorization lists

Physical access applies to secure areas, server rooms and storage for information assets. Keep an authorization list that names who may enter each area, who approved the entry, and when it was last reviewed, alongside badge or visitor logs. Auditors often sample a badge event and ask whether the person was on the list at that time. Remove holders when they leave, and reconcile the list against the personnel and contractor roster each quarter so leavers do not keep entry rights.

Periodic access review records

Periodic reviews are where the other artifacts are tested. A reviewer confirms, changes or revokes each access item within a set timeframe, and the record shows the decision, the reviewer and the follow-up. Access certification tooling can run these campaigns and keep the decisions. Keep the schedule and the completed campaign reports, and document any revocation with the date it took effect. Between audits, run reviews at the frequency your policy states and check that every privileged and shared account has been covered.

What meeting A.5.15 costs in money and effort

This table lists the cost components of meeting A.5.15 Access control, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none were supplied, so use the questions in the last column to build a comparable quote from each provider.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Tooling or licenses for identity and access	Recurring when commercial; one-time setup	Number of users and applications, premium connectors, and whether the identity provider is commercial or self-hosted open source	Itemized license terms per user or per application, renewal terms, and whether the open-source components are deployed on infrastructure the organization already pays for
Engineering time to integrate applications and networks	One-time, with ongoing change work	Count of applications using OAuth2, OpenID Connect, SAML, LDAP or RADIUS, legacy systems without modern sign-in, and network segments needing access rules	A per-application integration plan, named deliverables, and a written statement of which systems are excluded from scope
Access control policy drafting and approval	One-time, with periodic review	Number of policy owners, how many topic-specific rules sit beneath the policy, and how many approval cycles management requires	Confirmation of who drafts, who approves, and how many review rounds the fixed scope includes
Evidence upkeep (access lists, change records, review outputs)	Recurring	Frequency of joiner, mover and leaver events, size of the workforce, and how much evidence is generated automatically versus collected by hand	Description of which evidence is produced automatically, where it is stored, and how long it is retained
Access certification campaigns and reviews	Recurring	Number of reviewers, number of access items per review, review frequency set by the organization, and whether reviewers can act in the tool	Who runs each campaign, the time each reviewer is expected to spend, and how revoked access is tracked to completion
External review or penetration testing of access paths	Recurring, per test cycle	Scope of applications and networks tested, whether testing covers authentication bypass and privilege escalation, and retest requirements	Written scope, test methods, retest rules and the form of the final report
Auditor sampling effort	Recurring, per audit cycle	Number of access requests, leavers and access reviews the auditor selects, and how quickly the organization can retrieve the records	Confirm with the certification body how it samples A.5.15 and A.5.18 evidence before the audit date

Open-source tools that produce A.5.15 evidence

authentik is an identity provider that applications can delegate sign-in to, which makes it a natural place to enforce the rules your access control policy sets for applications. Its providers cover OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so web applications, directory-dependent services and network devices can all route authentication through one controlled point. The evidence this produces is configuration and logs that show which applications are bound to which sign-in flows, and who was granted access through them.

Application bindings: Export the list of providers and the applications linked to each, to show that access to in-scope systems runs through the controlled identity source.
Protocol coverage: Map OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers to the systems that use them, so gaps in coverage are visible.
Sign-in event records: Retain authentication and authorization events for sampling by an auditor who tests whether access matched policy.
Configuration as code: Keep provider and policy definitions in version control so changes to access rules leave a reviewable trail.
Licensing: authentik is released under the MIT license, which permits commercial use, but confirm the license terms of any add-ons or enterprise features you adopt.

Confirm with your architects which applications can be moved behind authentik, and which legacy systems will need a proxy provider or a separate control.

Where access control programs usually fall short

Most access control programs have a written policy, yet assessors still find gaps where the policy meets daily practice. The cards below cover the failure points an auditor tests first, and each one names the check that closes it.

Policy without enforcement

The access control policy states who may reach what, but nothing in the systems enforces it. Auditors compare the written rules with real group memberships, firewall rules and application roles. Check that every rule in the policy maps to a named technical control, such as an identity provider group or a network rule, and that the owner can show it working.

Shared accounts with no owner

Generic logins used by several people, such as a shared admin or service login, make it impossible to tie an action to a person. Under A.5.15 the organization still has to show who may use each account and why. Inventory every shared account, assign a named owner, record who holds the credentials, and move human use onto individual identities wherever the platform allows it.

Access accumulation after role changes

When people move between teams, old access often stays behind and new access is added on top. Over time a single identity holds rights far beyond its current job. Check whether mover events remove prior access, not only add new access, and compare current entitlements with the role each person now holds.

No periodic access certification

Access granted years ago is rarely revisited unless someone schedules a review. Without a periodic certification, the policy has no evidence that it still reflects who needs what. Set a review cycle in the policy, assign reviewers who are not the people receiving access, and keep the signed decisions to keep, change or revoke as evidence.

Physical access out of scope

Teams often define access rules for systems and networks but leave server rooms, network cabinets, backup media and office areas outside the rules. A.5.15 covers physical access to information and associated assets as well as logical access. Confirm that badge rights, visitor escorts and key holders are covered by the same policy and reviewed on the same cycle.

Third-party access left out

Contractors, managed service staff, suppliers and their remote support tools often hold privileged access but sit outside the identity process. Their accounts may never expire. Bring every external identity into the same provisioning and review flow, set an end date on each engagement, and confirm that supplier access is recorded in the access rules for the relevant assets.

Questions about A.5.15 cost, effort and outsourcing

How much effort does A.5.15 access control take for a small team?

The effort depends less on the control text than on how many systems, identity stores and access paths the team must cover. A.5.15 asks for an access control policy that is based on business and information security requirements, and then for that policy to be implemented. For a small team, the work usually concentrates in three places: writing a short policy that names the systems in scope, deciding who approves access to each one, and connecting the main applications to a single identity source so that rules are applied in one place. No figure for effort is supplied here, so ask any provider to break the estimate into policy work, system integration and evidence collection, and to state how many applications and user groups the estimate assumes.

Can a small team implement A.5.15 access control in-house?

Yes, a capable internal team can write the policy and run the controls, provided it has someone who owns access decisions and time to maintain them. The harder part is consistency: the policy must match what the identity provider, directories and applications actually do. Teams often find that the policy is easy to write and the enforcement is what slips, especially when applications keep local accounts. Outside help is most useful for the initial integration of identity systems, for hardening them, and for documenting the setup so an assessor can follow it. The organization still owns the policy and the decisions it records.

What does the team need to provide for A.5.15 work?

The team needs to supply decisions and access to systems, which are usually the constraints that set the pace. Expect to provide:

A named owner for the access control policy and for each system's access rules
A list of applications, cloud accounts and networks in scope, with current account sources
Administrative access to the directories and identity tools being configured
Time from application owners to test sign-in, role mapping and removal of local accounts

Without these inputs, integration work stalls, so ask the provider to confirm exactly what they expect from your staff before the work begins.

How long does A.5.15 access control take to implement?

The duration depends on scope, the number of applications that must integrate with the identity provider, and how quickly decisions are made. No timeline is supplied for this control, so do not accept a generic number. A reasonable scoping conversation should produce a schedule that separates policy approval, identity integration, application onboarding and evidence capture. Be aware that the access control policy has to be approved and communicated before enforcement can be tested, so decision cycles often set the calendar more than technical work does.

Will an auditor accept a self-hosted identity provider for A.5.15?

An auditor does not accept or reject a product as such. The assessor tests whether the access rules are defined, enforced and reviewed, and whether the evidence shows it. A self-hosted identity provider can satisfy that test if it gives you configuration records, sign-in logs, group and role assignments, and a documented method for changes. For example, authentik can act as the identity provider for applications through OAuth2, OpenID Connect, SAML and other protocols, so applications delegate sign-in to it, and FreeIPA can provide single sign-on for Linux and UNIX environments. Confirm with your certification body how it will sample evidence before choosing the tooling, since they will decide what is sufficient for your scope.

What should a fixed-scope quote for A.5.15 include?

A fixed-scope quote should state what is in scope and what is excluded, so the estimate can be compared across providers. Ask for the following in writing:

The systems, applications, identity sources and networks covered, listed by name
The deliverables: policy drafts, configuration documentation, integration records and an evidence list
Which tasks the organization performs, such as approvals and access reviews
The assumptions behind the effort, including number of applications and user groups
Handover terms and whether ongoing support or periodic access review support is priced separately

DeployOpen agrees scope, deliverables and timelines in writing before work starts, so a quote should follow directly from that written scope.

Which parts of A.5.15 can be outsourced and which must stay in-house?

Implementation work can be outsourced, while the control itself stays with the organization. An implementation partner can design the identity architecture, integrate applications, configure the tools and document how they work. The organization must still approve the access control policy, decide who gets which access, and perform or sponsor access reviews. Access certification campaigns, such as those supported by midPoint, rely on designated reviewers inside the business to keep, change or revoke access. Only an independent auditor or certification body issues the audit outcome, so the partner's work supports the evidence but does not replace it.

How DeployOpen prepares access control evidence

DeployOpen plans, implements and documents access control systems for A.5.15 inside the client's own cloud accounts, data centers or air-gapped networks, under a fixed scope agreed in writing before work starts. In practice that means defining which systems the access control policy covers, configuring the identity provider and directory services that enforce it, and writing down the rules for who may request, approve and revoke access. Where a client's policy is still a draft, the work includes helping its owners turn business and security requirements into rules that can be tested. DeployOpen can also prepare the records an assessor will ask for, such as configuration exports, role definitions and review campaign results, so the client's team can show how the rules operate.

DeployOpen does not issue audit reports, attestations or certificates. Only an independent certification body can certify an ISMS, and the client's assessor decides whether the evidence supports conformity with A.5.15. The organization remains the owner of its controls, its policy approvals and its risk decisions, and it must be able to explain them without relying on the implementation partner. Before engaging anyone, confirm with the certification body which evidence it expects, how it samples access records, and whether it accepts the tools and logs you plan to use.

When requesting a quote, ask for a written list of in-scope systems, the deliverables for the access control policy and its supporting procedures, the evidence package and the handover of administrative credentials and documentation to your team. Ask which items recur after the engagement, such as access reviews, configuration updates and upgrades, and which are one-time. A fixed-scope proposal makes these boundaries visible, so your team can confirm who approves each rule and who keeps the evidence current once the engagement closes.

A.5.15 Access control