What Does Control 5.15 Actually Require?

ISO 27001 Control 5.15, Access Control, requires you to establish, document, and implement access control rules.

The standard asks you to define who can access what based on your business and security requirements, covering both logical access (user accounts, systems, applications) and physical access (buildings, server rooms, equipment).

That’s the governance layer. The standard doesn’t prescribe a particular access control model or system – it just requires that you have thought it through, written it down, and that what you do in practice reflects what you’ve documented.

The policy you write for 5.15 is then what drives everything under 5.18 – the joiners, movers, leavers process, least privilege, access reviews, and revocation. Get 5.15 right, and the rest has a clear foundation to build on.

SME Shortcut: Minimum Viable Compliance

For a smaller organisations preparing for a first certification audit, here is what you actually need to satisfy 5.15:

1. Draft an access control policy – doesn’t need to be long, does need to reflect reality. There’s one in my toolkit (hint).
2. A documented JML process – a written procedure or flowchart showing how access is requested and approved.
3. A named owner or role responsible for granting and revoking access (per system if necessary)
4. Evidence of at least one access review in the last quarter (I don’t recommend annually, it’s indefensible in an audit)
5. Privileged accounts listed, justified, and documented separately
6. Physical access is considered and documented in the policy

That’s the minimal compliance foundation. Everything else is refinement.

How to Write the Access Control Policy

Before anything else, you need a documented access control policy. It doesn’t need to be long. It does need to clearly address:

• Who is responsible for granting, reviewing, and revoking access – typically, managers authorise, and IT implement
• That all access is denied unless explicitly granted
• How access is handled for new starters, role changes, and leavers (the JML process)
• That user accounts are personal and unique – no shared accounts, especially on privileged systems
• That privileged accounts are managed separately, documented, and logged
• How often access is reviewed – quarterly is standard
• Physical access – building access, server rooms, equipment

⚠️ Important: Your policy sets the benchmark against which everything else is measured. If it says “quarterly reviews,” you need to provide evidence of them. Write what you can commit to, not what sounds impressive.

A note on MFA: Your access control policy should explicitly require MFA for all privileged accounts and for any remote access to your systems. The implementation detail lives in 5.17, but the requirement to use it needs to be anchored in the policy here. If your policy doesn’t mandate it, an auditor has no baseline against which to measure 5.17.

Access Control Matrix Example

Capturing access rights in a matrix can be a pretty effective tool. It describes just at a glance who should have what access levels, based on their roles.

Here’s an example of how you can implement a matrix, either alongside or within your policy, to explicitly capture roles and the access rights they should have by default.

The Concept of “Least Privilege” in Practice

Many Access Control Policies advocate for the principles of “least privilege”, which is simple to describe and easy to get wrong: People get access to exactly what they need to do their job. No more.

The most common failure I see is admin rights creep. For example, early in a company’s life, when IT resources are thin, admin access gets handed out freely because it’s easier. Fast forward a year or two, and by the time you’re preparing for ISO 27001 certification, you might have twelve people with full admin rights to your cloud environment when three would do the job.

I worked with a ~40-person company where we found exactly this. Getting from twelve to three admin accounts took a lot of work (and arguments). That single change – documented and evidenced – satisfied the auditor’s sampling on this control.

The principle isn’t complicated. The discipline of maintaining it is what requires attention.

Joiners, Movers, and Leavers – Where Most Organisations Fall Short

In my experience, the JML process is where auditors gravitate to find the most evidence of nonconformity for this control. Not because organisations don’t have a process, but because they don’t follow it consistently, or haven’t written it down.

Joiners

A new person joins. HR notifies the recruiting manager that a start date is confirmed. The manager submits a request to IT (a form, a ticket, an email with a defined structure) specifying exactly what systems and access levels are needed for that role.

IT then provisions the accounts based on that request. Not based on what the last person in the role had, and not based on verbal requests from the new starter on their first day.

On day one, the person has what they need. Nothing more.

Movers

A person moves to a different role. Their previous access is reviewed and adjusted – not just added to.

This is where the concept of “least privilege” (having the minimum access rights necessary for your role) breaks down most often. That’s because access rights accumulate over time.

Someone spends six months in finance, moves to operations, and still has access to payroll systems two years later. An access review (both at the point of change of job role, but also on a regular schedule) should catch this, but only if it’s done properly.

Leavers

A person leaves. Every access right – every account, every system, every physical credential – is revoked. Not next week. The day they leave.

A former employee with active credentials is an audit finding and a genuine security risk. The leaver process needs to be a formal handoff, not something that gets done when IT has a spare moment.

I’ve personally seen IT staff with administrative access 18 months after their employment termination. The danger this poses, especially if the party was aggrieved, is astronomical.

The diagram below shows how a typical JML process flows:

A Quick Look at Access Control Models

There are different ways to approach access control, referred to as AC Models. I won’t explore them too deeply, but for reference, here’s a quick comparison of the four main access control models and where each fits:

Model	How it works	Typical example	SME suitability
RBAC — Role-Based	Permissions are tied to job roles, not individuals. Assign someone to a role and they inherit its access. Change their role, you change their access, not a list of individual permissions.	A “Finance Manager” role grants access to accounting systems. A “Developer” role grants access to code repositories. Clean JML process as a result.	✓ Recommended for most SMEs
DAC — Discretionary	The owner of a resource decides who can access it. Common in file systems and shared drives. Flexible, but hard to govern consistently as the organisation grows.	Government and military systems in which documents are classified as Confidential, Secret, or Top Secret, and users hold corresponding clearances.	Acceptable, with caveats
MAC — Mandatory	A central authority assigns classification levels to both users and resources. Users can only access what matches their clearance level. No discretion: the policy decides, not the person.	Government and military systems where documents are classified Confidential, Secret, or Top Secret and users hold corresponding clearance.	Rarely applicable outside regulated/government environments
ABAC — Attribute-Based	Access is determined by a combination of attributes: who you are, what you’re accessing, when, where, and under what conditions. Very flexible but significantly more complex to implement and manage.	A cloud IAM policy that grants access only if the user is in a specific country, during business hours, on an approved device. Used in zero-trust and complex multi-cloud environments.	Advanced use — overkill for most SMEs

Access Reviews – If the Policy Says Quarterly, Prove It Quarterly

Your policy defines how often access is reviewed. Whatever that interval is, you need to be able to evidence it happened – on time, every time.

What good looks like: a scheduled review, documented in some form (a spreadsheet, a ticket, a report from your identity system) showing who had access to what, signed off by the relevant manager, with any changes actioned.

The auditor doesn’t care how amazing and sophisticated your tooling is. They care that it happened when you said it would.

Auditors will focus on two key things: a review that was done once before the certification audit and never repeated, or a review in which someone checked the list but didn’t take action on anything unusual they found.

Account reviews are an opportunity to catch dormant accounts (with no activity for 90 days or more) and take action. Your policy should define what happens to them. Flag them, investigate them, and disable them if there is no good reason for their continued existence.

A dormant account is a huge risk, sitting there, waiting to explode on you.

Don’t Overlook Physical Access

It’s easy to overlook, but access control isn’t only about user accounts and passwords; it includes physical access to buildings, rooms, server infrastructure, and equipment.

Your policy needs to address physical security, and your JML process should also include it.

• Who has access to your server room?
• Is it documented?
• Is it reviewed?
• When someone leaves, is their physical credential revoked at the same time as their system access – or does the physical side get forgotten?

This is consistently an area that organisations underestimate. Auditors are expected to check it. And it’s one of the easier things to get right with a small amount of process discipline.

The Link Between 5.15 and 5.18

For clarification on my earlier point: 5.15 sets the rules. 5.18 is where you prove you’re following them.

An auditor looking at 5.15 will ask for your policy. An auditor looking at 5.18 will ask for your evidence – JML records, access review documentation, a list of who holds privileged accounts.

Both controls are usually reviewed together, and the evidence for 5.18 is what demonstrates that 5.15 is more than a document sitting on a server.

What the Auditor May Actually Ask You

When a Stage 2 auditor reviews Control 5.15, here is what they are typically looking for and likely to ask:

• “Show me your access control policy.” – Is it current? Does it reflect what you actually do?
• “Show me how you handle a new joiner.” – Walk me through what happened the last time someone joined.
• “Show me what happens when someone leaves.” – Can you pull up a recent example with evidence?
• “Show me your last access review.” – When was it? Who conducted it? What was actioned?
• “Who has admin rights to [key system]?” – Can you justify every name on that list?

If you can answer all five with actual evidence, you are in good shape.

Compliance Checklist

Use the interactive checklist below to assess your current position against Control 5.15:

Don’t Forget Non-Human Identities

Access control isn’t only about people and their accounts. Most organisations have a growing number of non-human identities like service accounts, API keys, automated scripts, and integrations between systems, and I believe these carry the same, or even greater, risk as human accounts if they’re not managed properly. I honestly don’t think I’ve worked in an IT environment over the years that didn’t have these kinds of legacy accounts floating around without any oversight or updates when people leave, and with people knowing the passwords, etc.

The same principles apply as user accounts: least privilege, regular review, and revocation when no longer needed. In practice, a few specific rules help:

• Service accounts should not have interactive login enabled. If a service account can be used to log in as a person, it’s a risk.
• API keys and credentials should be rotated regularly, and immediately if a team member who knew them leaves.
• Where possible, restrict service accounts by IP address or source system — so even if credentials are compromised, they can’t be used from an unexpected location.
• Include service accounts in your access reviews. A service account that connects to a system decommissioned six months ago is a dormant risk on your list.

This is an area auditors are increasingly probing, particularly for organisations using cloud platforms. If you can’t tell an auditor what your service accounts are and what they access, that’s a gap worth closing before your next audit.

Third-Party and Contractor Access

External consultants, contractors, and managed service providers often need access to your systems and this is one of the areas where access control most commonly breaks down. I rarely see it considered in access control policies.

The principle is straightforward: third-party access should be time-limited, need-based, and revoked the moment the engagement ends. In practice, what I frequently see is contractors who completed a project twelve months ago and still have active VPN credentials or mailbox access, because nobody triggered the offboarding process for someone who was never on the HR system.

A few things worth building into your process:

• Third-party access should be requested and approved through the same process as internal access — not granted informally because someone asked over email.
• Always set an expiry date at the point of provisioning. If the engagement runs longer, renew it deliberately rather than leaving it open-ended.
• Include third-party accounts in your quarterly access reviews. They are often the accounts most likely to be overlooked.

If an auditor asks you to demonstrate your leaver process and you can’t show what happens when a contractor finishes, that’s a nonconformity waiting to happen.

Emergency Access — Break-Glass Accounts

Most access control frameworks include a provision for emergency or “break-glass” access: a highly privileged account held in reserve for situations where normal access routes are unavailable. Think: a critical system outage, a key administrator unreachable, or an incident response scenario that requires immediate escalation.

If you have these accounts (and most organisations of any complexity should), a few principles apply:

• Credentials should be stored offline and physically secured — not in the same password manager everyone else uses.
• Any use of a break-glass account should trigger an immediate alert to a named individual, so its activation is always visible.
• Usage should be logged and reviewed after the fact, with a brief record of why it was needed.

Auditors don’t expect you to never need emergency access. They do expect that when it’s used, you know about it and can account for it.

Metrics Worth Tracking

A few simple measures will tell you whether your access control programme is working in practice, and give you something concrete to present to management or an auditor:

• MFA adoption rate – what percentage of active accounts (particularly privileged ones) have multi-factor authentication enforced? The target is 100% for privileged accounts. Anything less is a known gap.
• Orphaned account count – how many accounts in your systems belong to people who have left? Ideally zero. Any number greater than zero needs an explanation and an action.
• Access review completion rate – of the reviews you committed to in your policy, what percentage were completed on time? If you promised quarterly and you did two out of four, that’s a gap an auditor will find.

These don’t require sophisticated tooling. A spreadsheet updated after each review cycle is sufficient. What matters is that someone is looking at the numbers.

Frequently Asked Questions