ISO 27001 A.5.15: Define Access Control Rules
ISO 27001 A.5.15 concerns the rules that permit authorised access and prevent unauthorised access to information and associated assets. Those rules apply to people, systems and physical settings. The central question is what an entity needs to do, under which conditions, rather than whether it has been given a login.
What A.5.15 requires in practice
Annex A control A.5.15 asks the organisation to set up and apply rules that control who can reach information and its related assets, both in person and through systems. These rules are based on business and information security requirements. Physical access covers buildings, rooms and equipment; logical access covers systems, applications and data.
Two phrases deserve attention. Based on business requirements means access rules should reflect what people genuinely need to do their work, and not default to everything or nothing. Established and implemented means the rules are decided and then actually put into practice, through approval routes and technical settings.
The control does not prescribe a particular access model. The organisation might use roles, groups or case-by-case approval, depending on size and risk. What matters is that the rules are clear, that they reflect real needs and risks, and that other access controls, such as granting and reviewing rights, follow from them.
Translate business needs into permissions
Ask information owners what activities different users actually require. Reading an account record, changing it, exporting a collection and administering the application are different permissions with different consequences. A broad “system access” approval can hide those distinctions and leave the technical administrator to make the business decision.
Define restrictions in terms that owners and implementers can both understand. A job role may provide a useful starting point, but department membership alone rarely describes every legitimate need. Consider customer, project, location or service boundaries where they matter. Include non-human entities such as an integration that needs to submit records without reading the entire database.
Use the least access needed for the agreed activity and make exceptions deliberate. Too much granularity can become unmaintainable; too little can expose unrelated information. ISO 27002 discusses different access approaches, but it does not require every organisation to adopt the same role or attribute model. Choose an approach whose decisions you can explain and operate.
Connect the physical and digital boundaries
A well-restricted application can still expose information through unattended printouts or a shared operations room. Conversely, controlling building entry does not determine which records a visitor may view on a workstation. Map the physical and logical routes to consequential information and align their expectations.
Consider access from remote locations, partner connections and administrative paths. A rule expressed only in the main user interface may be bypassed by an export, application interface or support tool. Technical implementation should reflect the decision across the relevant routes, including changes to labels or ownership that alter the intended audience.
Why access control rules matters to the business
Access rules are the foundation for most other protection. If it is unclear who should reach what, individual decisions become inconsistent, access accumulates and sensitive information ends up visible to people with no need for it. Clear rules make granting, reviewing and removing access faster and easier to defend.
They also support customer confidence. Clients expect their information to be limited to those who need it and want to know how that is decided. Assessors usually check whether rules reflect actual business needs. Rules that are too tight block work and encourage workarounds, while rules that are too loose expose the organisation.
How to implement A.5.15
Write rules that describe decisions people actually make, and then check that systems reflect them. Involve the owners of key systems, because they know which roles really need which kind of access.
- Identify the information, systems and areas that need controlled access, starting with the most sensitive.
- For each, decide who needs access and why, based on roles, tasks and business needs rather than seniority.
- Set principles that will guide decisions, such as granting only what a task requires and approving exceptions through a named route.
- Cover physical access as well as logical, including visitors, shared spaces and equipment rooms.
- Document the rules in a form that approvers and administrators can use, and share them with the people affected.
- Make sure systems are configured in line with the rules and that approvers understand their role.
- Revisit the rules when services, structures or risks change, and use review findings to improve them.
Illustrative construction example: one project, different audiences
A hypothetical construction company uses a common project environment for engineers, subcontractors and commercial staff. All parties need current approved drawings, but only selected staff need commercial claims and tender comparisons. A single project membership group unintentionally grants access to both.
The information owners separate drawing collaboration from commercial records and define who can approve each permission. Site-room access and printed meeting packs receive corresponding restrictions. The team tests a subcontractor account against both areas. The exercise evaluates the intended boundary rather than merely confirming that the account can log in.
Illustrative software example: a reporting integration
A hypothetical software company gives a reporting connector a powerful database account because that makes installation easier. The connector only needs selected performance fields, but its account can modify customer records. No human user has requested this wider capability.
The service owner specifies the necessary data and operations, and the technical team implements a narrower permission arrangement. A controlled test checks both successful reporting and denied modification. The owner documents any remaining limitation and treatment decision. The lesson is that machine access deserves the same business justification as staff access.
Make exception decisions visible
Urgent work may require unusual access. Define who can approve it, how the boundary changes and when the need ends. An emergency arrangement should not quietly become a permanent role. Where a temporary restriction cannot be implemented, assess compensating measures and the residual risk through an authorised route.
Align decisions with segregation of duties. A permission may be reasonable alone yet create a conflict when combined with another role. Review the full set of capabilities available to the entity, including secondary accounts and delegated access.
Evidence and useful tests
The control calls for access rules that are established and implemented. A permission matrix is one optional way to express them; it is not the only acceptable document. Useful evidence connects approved business rules to configurations, permission decisions and representative tests. Protect exported access information because it may reveal sensitive system structure.
Test negative as well as positive cases. Verify that an authorised user can perform the needed task and that an unrelated user cannot reach the same information through another route. Common failures include copying a predecessor’s permissions, treating a broad job title as unlimited need and checking the user interface while overlooking administrative interfaces.
Common nonconformities with A.5.15
Findings tend to show rules that are unclear, unused or out of step with real practice. Assessors usually test the rules by comparing them with how access is actually granted in sampled systems.
- No written rules exist for a significant system, so access decisions vary between administrators.
- Rules cover digital access but not physical areas where sensitive information is held.
- Access is granted by default to large groups, with no link to business need.
- Rules were written once and no longer match the way roles or systems are organised.
- Visitor and contractor access to buildings is not covered by the same thinking as employee access.
Frequently asked questions
Does A.5.15 apply only to IT accounts?
No. Its access rules include physical and logical access to information and associated assets. Account permissions are one part of that wider decision framework.
Is role-based access mandatory?
No single access model is universally prescribed. Roles can simplify recurring decisions, but the chosen model must fit information sensitivity, business tasks and maintainable administration.
Should administrators decide business access?
Administrators implement permissions and advise on technical limits. Appropriate owners should authorise the business need. Combining both decisions without oversight can create unnecessary access or conflicts.
Turn access policy into enforceable decisions
Discuss access-control design with Sterling. Consulting and scoped Effivity ISO & GRC automation software can support the governance and evidence around implementation. Use 93 Annex A Controls training to develop owners’ understanding. Certification decisions remain independent. See the wider organisational controls for connected responsibilities.