Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

An Introduction to Access Rights

As with a lot of the ISO 27001 standard and it’s controls, they often come in groups / batches that sit together and one doesn’t really exist without the other. Controls 5.15-5.18 work like this; 5.15 Access control sets out the rules, 5.16 (Identity Management) looks after the indentities of accounts through their lifecycle. Control 5.17 (Authentication Information) then governs the secret that proves it, and then control 5.18 (Access Rights) then decides what that actually gets you once in the system.

This is the control where the access control policy (the “topic specific policy” mentioned) meets reality. Control 5.15 lays down the rules about who ought to be able to reach what and then 5.18 is whether that is true in your systems this morning, and whether you can demonstrate it.

The most common finding here is not somebody holding inappropriate access. It is somebody holding perfectly appropriate access that nobody can show was ever authorised. Those two things look identical in an audit until you are asked for the approval, and only one of them has an answer.

What control 5.18 actually asks for

Unpacked into practice, the control expects:

• Access provisioned in line with the access control policy, so the two line up with each other.
• Authorisation is requested by the owner of the system or information BEFORE rights are granted, and it’s logged.
• Rights are amended or removed when somebody changes role or leaves.
• Periodic review of who holds what, and review triggered by change as well as by the calendar.
• Records of what was granted, by whose authority, when it changed and when it was removed.
• Particular attention to privileged rights, which get their own control at 8.2.
• Access obligations written into employment and supplier contracts.

Worth noticing how much of that is about records rather than about configuration. This is the control where the standard is most insistent that you can evidence the decision, not merely the outcome. That emphasis is the whole reason the approval trail section below comes before anything technical.

Where 5.18 sits among the access controls

Five controls in this family run together, and it is worth knowing which one an auditor is testing when they ask you something.

5.15 sets the rules. 5.18 is whether you follow them. If your access control policy says finance data is restricted to the finance team, 5.15 is the policy saying so and 5.18 is the eleven people who can currently open the folder. The access model itself, the matrix, and the joiner-mover-leaver process are all covered properly on the 5.15 page, so this page assumes them rather than repeating them.

The pairing people confuse most often is 5.16 against 5.18. Identity is who you are; access rights are what you may do. It is entirely possible to have an immaculate identity register and still fail this control because everybody in the business is an administrator.

The approval trail

Start here, because it is the part almost nobody has and the part an auditor reaches for first.

Nearly every business can show you what access somebody has. Very few can show you who decided they should have it. The access exists, it is probably correct, and there is no record of the decision anywhere. That is a finding even when the access itself is entirely sensible.

An adequate approval record answers four questions:

• Who asked for the access.
• Who approved it, and on what authority.
• What was actually requested, described in business terms rather than group names.
• When.

The approver should be the owner of the system or the data, not IT. IT knows how to grant access. Only the business owner knows whether somebody should have it. When IT both authorises and configures, you have lost the check entirely, and you have created a segregation of duties problem under control 5.3 as a side effect.

In a very small business the same person genuinely may do both. That is survivable, but say so and put something around it: a monthly look at what was granted, signed by a director, is a reasonable compensating control. What is not survivable is claiming a separation you do not operate.

The record does not need a system. A ticket, an email thread filed against the personnel record, or a row in a spreadsheet all count. It needs to exist, to be findable in an audit, and to name a person. “We always check with the manager” describes a habit, not a record.

Provisioned versus approved

The second gap, and the one that quietly creates over-privilege across an entire company.

Somebody joins. The request says they need access to the CRM and the shared drive. Whoever sets the account up types the fastest possible instruction into practice: set her up the same as Dave.

Dave has been here nine years. Dave covered finance for a quarter in 2023, ran a project that needed admin rights, and still sits in a distribution group from a department that no longer exists. All of that now belongs to somebody who asked for two things.

Cloning an existing user is the single most efficient way to spread excessive access in a small company, and it is the default precisely because it is quick. It also breaks the approval trail, because what was provisioned no longer matches what was approved, and nobody notices until somebody compares the two.

The fix is to provision from a role rather than from a person. This does not require a formal role-based access model; a one-page note saying what a new account manager gets is enough, and it is dramatically better than copying Dave. Where you genuinely do need to clone, clone and then strip back to the request.

The check takes ten minutes: take your most recent starter, put the original request next to the account as it exists now, and see whether they match.

Why access reviews fail, and how to run one that works

Everybody knows they should review access. Most organisations do review access. The reviews are, in the main, worthless, and it is worth understanding exactly why before you run your next one.

The five reasons they fail

1. The list is unreadable. You export permissions and send a manager a spreadsheet containing entries like GRP-FIN-AP-RW-02. They have no idea what that grants. Nobody has ever told them, and they are not going to ask.

2. The list is too long. Two hundred lines arrive in an inbox belonging to somebody with a day job. It is approved in full in four minutes, because the alternative is an afternoon of work with no obvious reward.

3. The wrong person is reviewing. IT is asked to confirm that access is appropriate. IT can tell you what access exists. Only the person who owns the process can tell you whether it should.

4. There is no practical way to say no. The form has an approve column. It rarely has a straightforward route to flag something, and almost never makes removal easy. So everything gets approved.

5. Nothing happens afterwards. The review is filed. No access is removed. People learn within one cycle that the exercise is theatre, and they treat the next one accordingly.

How to run one that works

Translate before you send. Add a plain-English column. Not GRP-FIN-AP-RW-02, but “can create and approve supplier payments”. If nobody in your business can write that sentence for a group, you have found something more interesting than the review was looking for.

Send it to the owner, not to IT. IT prepares the review. The system or data owner makes the decisions. That split is also what makes the sign-off worth anything.

Review by exception. This is the change that makes the difference. Do not ask “is all of this correct”. Pre-filter to the things that look wrong and ask for a decision on those:

• Access not used in the last ninety days.
• Anyone who changed role since the last review.
• Anyone holding more than one role’s worth of rights.
• All privileged and administrative access.
• Anything granted as temporary that is still live.
• Accounts nobody can immediately account for.

A manager asked to decide on twelve lines will think about twelve lines. The same manager asked to confirm two hundred will confirm two hundred. You are not lowering the standard; you are spending the attention you actually have where it changes an outcome.

Make removal the default for anything unused. Put the burden on justifying retention rather than on justifying removal. Access can always be granted again, and the request will be quick because you already have a process for it.

Close the loop and count what came off. A review that removes nothing in a business of thirty people has not found nothing; it has failed to look. Track the number of removals per cycle. That figure is the best single piece of evidence that the process is real, and it is the number I would ask for.

Set a cadence you will keep. Quarterly for privileged access, annually for everything else, plus a review triggered whenever somebody changes role. That matches the cadence recommended on 5.16 and 5.17, so it stays a single entry in the calendar rather than three.

Keep four things from every review: the list exactly as it was sent, the decisions made, who made them and when, and what actually changed afterwards. The fourth is the one people forget, and it is the one that turns a signed spreadsheet into evidence.

Revocation, and the leaver test

Auditors test leavers first on this control, for the same reason burglars try the door handle: it is quick and it works more often than it should.

Two things make leaver revocation harder than it looks.

Disabling the identity is not the same as removing the rights. 5.16 gets you the disabled account. 5.18 is everything that account could reach. In a cloud business, removing somebody’s licence frequently leaves group memberships, shared folder permissions and third-party application access sitting exactly where they were.

Anything outside single sign-on has to be handled by hand. That is where the misses happen. The list worth writing down once and then reusing: SaaS applications not behind SSO, shared drive and site permissions, the CRM, code repositories, the supplier or client portal, building access cards, and any recurring calendar invitations that carry document links.

Commit to a timescale you can actually meet and can evidence. One working day is defensible for most SMEs. “Immediately” is a promise you will break the first time somebody resigns at five o’clock on a Friday, and a broken promise in your own policy is worse than a modest one you keep.

One carry-over from control 5.16 that belongs here too: when the leaver is somebody who granted access to others, removing their rights is only half the job. Rotate what they issued and review what they set up.

Temporary access that became permanent

Project access. Cover for parental leave. “Just for the migration.” Every one of these is granted in good faith and almost none of them is ever taken away.

The reason is structural rather than careless: the request never asked when it should end, so nothing anywhere holds an expiry date, and no event will ever prompt anyone to reconsider it.

The fix is a single mandatory field on the request: until when? Three consequences follow from it, all good:

• Anything genuinely temporary now has a date, which can be diarised rather than remembered.
• If the requester cannot answer the question, the access is not temporary and should go through the normal approval route with a permanent justification.
• Your access review gets a free exception filter: anything past its expiry date and still live goes straight onto the list.

Cover arrangements are the worst offenders. Somebody covers finance for three months during a maternity leave and still has the access three years later, long after everyone involved has forgotten the reason it was granted.

What auditors will look for

As a Lead Auditor, this is broadly how I would work through 5.18.

1. One starter, traced end to end. Show me the request, the approval, and the account as it stands today. I am comparing what was asked for with what was configured, and the gap is usually the story.

2. One leaver, traced across every system. Not just the account. Name everything they could reach, and show me when each was revoked and how you know.

3. Your most recent access review. The list as sent, the decisions, and what changed as a result. If nothing was removed, I will want to understand why, and “it was all correct” is a harder answer to defend than people expect.

4. Somebody who changed role in the last twelve months. What did they gain, and more importantly, what came off?

5. Administrative access and who authorised it. Specifically whether the person who approved it is a different person from the one who configured it.

6. Temporary access currently live. What is outstanding, and when does each item expire? If nothing has an expiry date, that is the finding.

Common issues

• Access that is entirely appropriate but whose authorisation cannot be evidenced. The most common finding on this control by some distance.
• New accounts cloned from an existing employee, inheriting nine years of accumulated rights.
• Access reviews signed off in full with zero removals, cycle after cycle.
• IT reviewing and approving its own provisioning, with no owner involvement.
• Leaver rights removed from the identity platform but left in place across every application outside single sign-on.
• Temporary access with no expiry date, because the request never asked for one.
• Movers who gained the new role’s access and kept the old role’s as well.
• Group and role names nobody outside IT can interpret, which quietly makes meaningful review impossible.
• Access records held entirely in one person’s memory, which works right up until they are on holiday during the audit.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• Take your last three access grants. Can you show who approved each one?
• Does your most recent starter have exactly what was requested, and nothing more?
• What did your last access review actually remove?
• Take your last leaver. Can you name every system they could reach, and show when each was revoked?
• What temporary access is live right now, and when does each item expire?

The third question is the one worth sitting with. If the honest answer is nothing, the review is not working.

A worked example

The figures below are typical rather than drawn from a single engagement. This is a composite of what a first proper access review turns up in a business of this size.

A 45-person business running Microsoft 365, an ERP system and a CRM, conducting its first access review because a client questionnaire asked for evidence of one.

The first attempt

• IT exported every permission across the three systems. The result was 340 lines.
• The spreadsheet went to four department managers, with group names exactly as the systems reported them.
• All four approved in full. Two replied within the hour.
• Nothing was removed. The review was filed as evidence and, on its own terms, was complete.

It would have satisfied a superficial look and failed the first follow-up question, which is what changed as a result.

The second attempt

• Every group was given a plain-English description. Three of them nobody could explain at all, which became the first three actions.
• The list was filtered to exceptions: unused in ninety days, role changed since last review, privileged, or granted as temporary and still live. That reduced 340 lines to 31.
• The 31 went to the owners of each system rather than to IT, with a removal column and the default set to remove.

What came out of it

• Eleven access rights removed, including two people who still had ERP access from a project that finished in 2024.
• Four administrative accounts reduced to standard user rights.
• Two accounts nobody could account for, both traced to contractors who had finished eighteen months earlier.
• One genuine surprise: a manager discovered a member of their own team could approve purchase orders, which nobody had intended and which had been true for over a year.

The whole exercise took about half a day, most of it spent writing the plain-English descriptions. Those descriptions are reusable, so the next review will take an hour. The difference between 340 lines and 31 is the entire reason it worked.

How control 5.18 links to other clauses and controls

• Control 5.15, Access control. The policy that 5.18 implements. 5.15 states who should be able to reach what; 5.18 is the evidence that they can and others cannot.
• Control 5.16, Identity management. Identity is who you are, access rights are what you may do. Disabling an identity is not the same as removing its rights, which is why leaver processes fail across the boundary between these two controls.
• Control 5.17, Authentication information. Authentication proves the identity is being used by its owner. 5.18 decides what that unlocks.
• Control 5.3, Segregation of duties. The person approving access should not be the person configuring it, and no individual should accumulate rights that let them run a transaction end to end. Both failures show up in access reviews before they show up anywhere else.
• Control 6.5, Responsibilities after termination or change of employment. The HR side of the leaver process. Your revocation is only as timely as your notification.
• Control 8.2, Privileged access rights. The elevated subset, reviewed more often and scrutinised harder.
• Control 8.3, Information access restriction. 5.18 governs the rights a person holds; 8.3 governs the technical restriction applied at the information itself.
• Control 5.11, Return of assets. Runs alongside revocation on the same trigger. The laptop and the access should come back on the same checklist.
• Control 5.33, Protection of records. Your approval trail and review evidence are records, and they need retaining accordingly.

Frequently asked questions

What is the difference between control 5.15 and control 5.18?

5.15 is the policy layer: the rules about who should be able to reach what, and the model you use to express them. 5.18 is the operational execution of those rules and the evidence that you follow them. An auditor assessing 5.15 asks to read your access control policy. An auditor assessing 5.18 asks to see a specific person’s access and who approved it.

How often should access rights be reviewed?

The standard does not prescribe an interval. Quarterly for privileged and administrative access and annually for everything else is defensible for most small organisations, with an additional review triggered whenever somebody changes role. Choose an interval you will keep, because committing to monthly and performing it twice a year is a worse position than committing to annually and doing it.

Who should approve access requests?

The owner of the system or the information, not the IT function that will configure it. IT knows how to grant access; only the business owner knows whether it is appropriate. In a very small business the same person may unavoidably do both, in which case document that and add a compensating control such as a periodic review of grants by a director.

Do I need an access management tool to satisfy this control?

No. A spreadsheet, a ticket queue or a filed email thread will all satisfy the requirement for records, and the standard is deliberately silent on tooling. Automation helps at scale, but the control is about whether decisions are authorised, evidenced and reviewed, not about what software recorded them.

How quickly must access be removed when somebody leaves?

The standard says timely rather than giving a number, which means you set the target and are then held to it. One working day is a realistic commitment for most SMEs and is straightforward to evidence. What causes findings is a policy promising immediate removal against a reality of the following Monday.

What records do I actually need to keep?

Four things: who approved each grant and when, what was provisioned as a result, the access reviews including the decisions and who made them, and the revocations with their dates. If you keep those, the rest of this control largely takes care of itself.