Control Definition
Rules governing physical and logical access to information and other associated assets must be defined, implemented, and enforced on the basis of the organization's business needs and its information security requirements.
Control Objective
To ensure that information and associated assets can be reached only by authorized users, processes, and devices — and that unauthorized access is prevented by design rather than by luck.
What This Really Means
A.5.15 is the rulebook, not the door locks. It does not ask whether you have configured permissions in your directory or installed badge readers — it asks on what documented basis anyone gets access to anything. Before a single account is provisioned or a single badge issued, there should be written rules stating who may reach which information and which assets, under what conditions, and on whose approval.
In practice the rules rest on two principles. Need-to-know: people see information only when a specific task requires it. Need-to-use: people get systems, applications, and facilities only when their job function requires them. Layer on deny-by-default — access that is not explicitly permitted is forbidden — and derive the specifics from your information classification (A.5.12). "The finance file share is restricted to the finance group, approved by the finance director, reviewed quarterly" is a rule; "we follow least privilege" on its own is a slogan.
You will also need to choose an access model. Role-based access control (RBAC) bundles entitlements into roles mapped to job functions and is the right default for most organizations; attribute-based access control (ABAC) grants access dynamically from attributes such as department, device posture, or location, and earns its complexity in larger or more dynamic environments. ISO 27001 mandates neither — auditors care that you chose deliberately and can administer your choice honestly. Note the scope, too: the control covers physical and logical access together. Badge zones for the server room and IAM policies for production belong in the same framework, because intruders do not respect the organizational split between facilities and IT.
A.5.15 is the first link in a four-control chain: it sets the rules, A.5.16 establishes the identities the rules apply to, A.5.17 protects the secrets that prove those identities, and A.5.18 grants and revokes the actual rights. Auditors treat one question as the heart of this control: do the documented rules match the access that actually exists? A policy that declares need-to-know while every developer holds production admin is a finding waiting to be written.
Why It Matters
Almost every serious incident — ransomware, insider exfiltration, cloud data exposure — involves access that was broader than the job required or lived longer than the need. Access control rules are the reference point that makes "broader than required" a measurable statement instead of an opinion. They also carry the legal weight: when a regulator or customer asks how you limit access to sensitive data, the answer is this policy plus the evidence that it is enforced.
When access rules are missing, vague, or ignored, the failures follow a pattern:
- •Unbounded blast radius – one phished account opens file shares, admin consoles, and customer data it never needed, turning a routine compromise into a reportable breach
- •Improvised provisioning – without rules, IT grants access by precedent ("give her what her teammate has"), silently copying years of accumulated privilege to every new joiner
- •No baseline for review – access reviews under A.5.18 and privileged-access checks under A.8.2 evaluate reality against the rules; if the rules do not exist, the downstream controls have nothing to test
- •Physical-logical seams – server rooms managed by facilities and systems managed by IT under different standards leave gaps that neither team owns
- •Contract and regulatory exposure – customer DPAs and data protection laws expect demonstrable access limitation, and "trust us" does not survive a diligence questionnaire
The asymmetry favors doing this early: writing and approving access rules is days of work, while untangling five years of rule-free provisioning across fifty SaaS applications is a quarter-long remediation project that stalls certification.
Regional Compliance Context
For organizations processing personal data in India, the DPDP Act 2023 requires data fiduciaries to apply reasonable security safeguards, and documented access limitation is a core part of any defensible answer — full compliance obligations land on 13 May 2027, so access rules written now become the evidence base for that deadline. Entities regulated by RBI or SEBI face supervisory expectations that go further: documented, need-to-know access control aligned to RBI master directions and SEBI's CSCRF respectively, with the access control policy itself routinely requested during inspections.
Organizations serving Saudi or UAE clients meet the same demand through the Saudi PDPL and the UAE federal PDPL: both expect controllers to limit personal data access to what processing genuinely requires, and Gulf enterprise customers increasingly ask for the access control policy during vendor onboarding.
Implementation Guidance
Write a Topic-Specific Access Control Policy as Rules, Not Aspirations
Draft a policy that states deny-by-default, defines need-to-know and need-to-use, names who may approve access to what, and covers both physical and logical access. Every statement should be testable — an auditor (or your own internal audit) should be able to take any sentence and check it against a live system. Have it approved by management per A.5.1 and keep it version-controlled.
Map the Rules to Your Assets and Classification
Work from the asset inventory (A.5.9) and classification scheme (A.5.12): for each asset group or classification level, record who may access it and on whose authorization. The output is an access rules matrix — systems or classification levels on one axis, roles and approval authority on the other. Asset and information owners, not IT, decide the requirements.
Choose and Document Your Access Model
Adopt RBAC unless you have a concrete reason for more: define a role catalog mapped to job functions, with each role's entitlements listed. Use ABAC-style conditions (device compliance, network location, time of day) where your identity provider supports them and the risk justifies it. Record the decision, and keep the role catalog small enough that a human can actually review it.
Unify Physical and Logical Access Under the Same Rules
Define physical zones (public, office, restricted, server room) and apply the same need-to-use logic: who gets a badge to which zone, who approves it, how visitors are escorted. If facilities and IT are separate teams, the policy must bind both, and zone access lists should be reviewed on the same cycle as system access.
Separate Request, Approval, and Provisioning Duties
Build the workflow so the person requesting access, the person approving it, and the person provisioning it are never the same individual — this is segregation of duties (A.5.3) applied to access administration. Route requests through a ticketing system so each grant carries a requester, an approver, a date, and a justification. That trail is exactly what A.5.18 reviews will sample later.
Define Exception and Break-Glass Procedures
Some access will legitimately bypass the rules — emergency production access during an outage, an interim grant during a reorganization. Predefine these paths: an exceptions register with business justification, expiry date, and compensating controls, plus a break-glass procedure whose every use is logged and reviewed afterward. Undocumented exceptions are how deny-by-default quietly dies.
Review the Rules at Planned Intervals and on Change
Review the access control policy and rules matrix at least annually and whenever the business changes shape — a new product line, an acquisition, a major system migration, a new regulatory obligation. Record what was reviewed, what changed, and who re-approved it. Stale rules that describe an org chart from two years ago undermine every control that depends on them.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.15:
Documentation
- Approved access control policy stating deny-by-default, need-to-know, and need-to-use principles, with version history and management sign-off
- Access rules matrix or role catalog mapping roles to entitlements and naming the approval authority for each system or classification level
- Sampled access request tickets showing requester, approver, justification, and provisioning date
- Exceptions and break-glass register with business justifications, expiry dates, and post-use reviews
- Physical access zone definitions and badge authorization records governed by the same policy
Interviews
- CISO or security manager on how the access rules were derived from business requirements and classification, and when they were last reviewed
- An information or system owner on how they decide and approve who gets access to their asset
- An IAM or IT administrator on how the documented rules translate into directory groups, IdP policies, and badge system configuration
Observations
- Auditor samples a critical system's live permissions (directory groups, IAM policies) and compares them against the documented rules matrix
- Walk-through of restricted physical areas, checking badge reader coverage and whether zone access lists match recorded authorizations
- Demonstration of a live access request moving through request, approval, and provisioning with the three duties separated
Practitioner Insights
The pattern I see across certification audits: organizations write access control policies full of intentions — least privilege, need-to-know — and an auditor cannot test an intention. We test rules. When the policy says "access to production requires the platform owner's approval," I can sample five grants and verify it; when it says "access is granted on a least-privilege basis," I have to construct the test myself, and what I usually find is that nobody else ever tested it either. Write every policy statement so it can be checked by a stranger, because that is exactly who will check it.
Smaller companies keep borrowing enterprise RBAC structures — I regularly see thirty-role catalogs in forty-person startups, unmaintained from the day they were written. A spreadsheet with six real roles, the systems each role touches, and a named approver per system passes audits and, more importantly, actually gets used. The other recurring gap is physical access: cloud-first teams in co-working spaces assume it is the landlord's problem, but if your office has a network closet or unattended laptops, your rules need to say who can be where. Scale the model to what you will genuinely maintain.
Common Challenges & Solutions
Challenge
The policy declares least privilege, but in practice every engineer has standing admin access to production because that is how the company grew.
Solution
Run a one-time entitlement cleanup before certification: export actual permissions from your top five systems, compare them against the role matrix, and strip what the role does not justify. Pair the cleanup with just-in-time elevation for genuine emergencies — PAM tooling or short-lived cloud roles — so engineers lose standing admin without losing the ability to respond at 2 a.m.
Challenge
Physical access is run by an office manager or facilities vendor with no connection to the security team or the access policy.
Solution
Bring badge administration under the access control policy explicitly: define zones, name an approver for restricted areas, and put the badge holder list into the same periodic review cycle as system access. A quarterly 30-minute review of who holds badges to the server room closes a gap auditors check on every site visit.
Challenge
The role catalog has exploded — dozens of one-off roles created for individuals, defeating the point of RBAC.
Solution
Set a rule that new roles require security approval and a named owner, then run an annual role rationalization: merge roles with near-identical entitlements and delete roles with one or zero members. Handle genuine edge cases with documented exceptions or attribute conditions instead of minting another role.
Challenge
Exceptions granted "temporarily" during incidents or crunch periods become permanent because nothing forces them to expire.
Solution
Give every exception a mandatory expiry date at creation, and configure the IdP or ticketing system to auto-revoke or at least auto-flag at expiry. Review the exceptions register monthly. An exception renewed three times is a signal that the rules need changing, not that the exception needs extending.
Challenge
Access rules exist for the core systems, but a long tail of SaaS applications was onboarded by individual teams with no rules at all.
Solution
Tier your applications: tier-1 (customer data, production, finance) gets full rules and owner approval; lower tiers get a lighter default rule set enforced through SSO. Route all new SaaS purchases through the identity provider so deny-by-default applies automatically, and sweep expense reports or DNS logs quarterly for shadow applications.
