ISO 27001 Control 5.16: Identity Management

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 →

Introduction

Identity management answers a single question: who or what is this? Not what they are allowed to do, which is handled by control 5.18. Not how they prove it is really them, which is control 5.17. Just who.

Most of the trouble I see on this control comes from collapsing all three into “we have user accounts and passwords, tick”. It holds up fine until the auditor asks who owns the service account that has been running the nightly backup since 2021, and people go a bit quiet.

The 2022 version of the standard widened this control deliberately. The 2013 wording was about user registration and de-registration, which almost everyone read as meaning people. Control 5.16 is really about identities, and an identity can belong to a system, a service, a device or a script just as easily as a person. For most small and medium businesses, that single change is the entire difficulty of this control, because the human side is usually in reasonable shape and well managed, but the non-human side (those automated accounts you’ve set up everywhere) has never been looked at.

What control 5.16 actually asks for

Stripped back, the control expects six things:

• A defined process covering the whole life of an identity, from the point it is created to the point it is removed.
• Unique identification, so that an action recorded in a log can be traced back to one entity.
• Verification of the entity before an identity is issued.
• Shared identities only where there is a genuine business need, and then only where that need is approved and documented (I’ll come back to this common no-no in a bit)
• Non-human identities managed and overseen in the same way as human ones.
• Records kept of significant events in the life of an identity.

The requirement in ISO 27001 Annex A is a single sentence, so open to a huge amount of interpretation and confusion. The six points above are my reading of what that sentence and the supporting ISO 27002 guidance expect in practice. It’s worth remembering that ISO 27002 is recommended guidance rather than a certifiable requirement: you are audited against ISO 27001, and how you meet it is your decision to justify.

The four kinds of identity you actually have

Before you can manage identities, you need to know which sorts you are dealing with. In practice, the typical SME has only four, and they fail in four different ways.

If you only take one thing from this table: the first two categories can be exported from your platform in about a minute. The other two have to be built by hand, and they are the ones that any auditor worth their salt asks about.

How to implement control 5.16 in four steps

Step 1: Build the identity inventory

You cannot manage what you have never listed (a rule of thumb for everything on my website). The good news is that most of the list already exists and simply needs exporting rather than typing out.

Export your human and guest identities from your main platform. Then build the harder list by hand, because no system knows which of its accounts are shared and which are non-human. Only you will know that.

For every entry, record:

• The identifier itself.
• What it is for, in one line a non-technical person would understand.
• Which system or systems it operates in.
• A named human owner.
• Whether it holds privileged or administrative rights.
• Where the credential is stored.
• The date it was last reviewed.

The named human owner is the crucial field. Everything else describes the identity. Ownership is the field that means somebody has to answer for it next year. Owned by IT is not an owner. Departments do not answer questions; people do. Generic ownership and accountability is a weakness I see way too often. It’s not a major nonconformity, but it does demonstrate the human ability to be slopey-shouldered when it suits people.

Step 2: Set the one-per-person rule, then be honest about your exceptions

One person, one identity, is the rule. Put it in your Access Control Policy and mean it.

Then be honest about the exceptions. The standard permits shared identities where there is a business or operational need, provided their use is approved and documented. It does not require you to pretend you do not have any.

I said I’d come back to it earlier, and if I have one bug-bear that I’ve seen over the years I’ve spent in IT governance, it’s the shared account. When you do share accounts, usually one or more of three things is happening;

• Either you are unable to determine who made a change (if Bob and Jim are both using the account and it deleted crucial data, who then did it? Bob, or Jim?)
• You need to rotate passwords constantly (What happens if Bob leaves?)
• You are breaking a licence agreement (We can’t afford another licence, so Bob uses Jim’s one).

The most common self-inflicted wound on this control is a policy that prohibits shared accounts written by an organisation that runs on them. When an auditor reads your prohibition and then finds info@ shared between four people, they have not found a gap against the standard. They have found that you do not follow your own ISMS’s rules.

The workable answer is to permit them (they aren’t illegal, just discouraged), list them, and put controls around each one:

• The credential lives in a password manager, with individual logins, so you can see who retrieved it and when.
• Multi-factor authentication is enabled wherever the platform supports it.
• Each shared identity has a named owner who is accountable for its continued existence.
• The credential is rotated when anyone with access to it leaves.

Step 3: Wire identity into the joiners, movers and leavers processes

Identity management is not a standalone process. It is three moments in your existing HR process, and it works or fails there. I’ve mentioned in other articles, and I always spend time on the importance of the JML processes when I’m coaching companies in ISO 27001.

Having a robust JML process will manage so many things for you, but for now, focusing on identity management, the process can help manage the lifecycle.

Step 4: Set a review cadence you will actually keep

If you say you are going to review accounts in your documentation, then you need to do it, and prove you’ve done it. What follows is just a recommendation, not an actual stated timescale from the ISO 27001 standard.

I’d suggest quarterly for privileged and service accounts, annually for everything else, is a defensible position for most small organisations. It is proportionate to the risk, and it is achievable by one person with other responsibilities.

A quarterly review you perform is worth far more than a monthly review you document and skip. If you commit to a frequency in your policy, you are committing to producing that many pieces of evidence, and the auditor will ask for them by date.

Keep the evidence as you go. A dated export with initials against each line is evidence. A recollection of having looked at it is not.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call

Identity Management in Microsoft 365 and Google Workspace

For most SMEs, identity management is whatever your main platform does, plus a handful of applications hanging off it. Generic advice about implementing a centralised identity provider is not much use when you already have one and simply have not looked inside it. Here is where to actually look.

Microsoft 365 and Entra ID

• All users. Exportable to CSV from the Entra admin centre. That is your human identity list, done.
• Guest users. Filter the same list by user type. This is your third-party list, and it is almost always longer than people expect.
• Enterprise applications and app registrations. This is where service principals and application identities live. In my experience, it is the screen most SMEs have never opened, and it is the one that answers the auditor’s hardest question on this control.
• Privileged roles. Check who holds Global Administrator. In a 30-person business, anything above about three raises an eyebrow, and every one of them needs a justification you can say out loud.
• Shared mailboxes. Worth understanding the distinction. A shared mailbox that nobody signs into directly, accessed through people’s own named accounts, is not a shared identity problem at all. A mailbox with a licensed, sign-in-enabled account and a password that four people know is. Find out which of yours are which.
• Sign-in logs. Filter by last sign-in date to find identities nobody has used in 90 days. Those are your candidates for removal and your evidence that you looked.

Google Workspace

• Directory, then Users. Exportable from the admin console. Your human identity list.
• Suspended versus active. Filter on account status to confirm your leavers were actually shut off, and when.
• Groups versus users. The same distinction as shared mailboxes. A group alias such as sales@ that delivers to named individuals is not an identity. A standalone user account called sales@ with its own password is.
• Third-party app access. Under security settings, the API controls section lists the external services holding OAuth tokens against your data. This is a large part of your non-human identity inventory and it builds up quietly, one convenient integration at a time.
• Admin roles. Check who holds Super Admin, and apply the same scepticism as above.

Whichever platform you are on, the export is your evidence. Save it with the date in the filename, keep it somewhere the auditor can be shown, and repeat at your review cadence. Two dated exports six months apart, showing that four leaver accounts present in the first are absent from the second, will do more for you in an audit than any amount of policy wording.

Administration console layouts change fairly often. The locations above are accurate at the time of writing, but if a menu has moved, the thing you are looking for has not.

Service accounts and non-human identities

This is the part of control 5.16 that changed in 2022, and it is where nearly every SME I assess has its largest gap.

Most businesses have far more non-human identities than they think, because every convenient integration creates one. The automation platform moving form submissions into your CRM. The backup agent. The monitoring tool. The connector between your accounting package and your bank. The deployment pipeline. None of these felt like creating a user account at the time, but each one is an identity that authenticates to your systems and acts on them.

Three rules, pitched at a scale you can actually sustain:

There is also a credential problem specific to service accounts… Their passwords and keys have a habit of ending up hard-coded in a script, sitting in a configuration file, or pasted into a chat message in 2022 that is still perfectly searchable today. A password manager is the SME-scale answer. A proper secrets vault is the grown-up one. Either beats the chat message.

The realistic minimum for a small business is a register, a named owner on every line, credentials held in the password manager, and a quarterly look at whether each identity is still needed. That is proportionate and it is enough. You do not need an identity governance platform to satisfy this control.

The mover problem

Joiners and leavers get natural attention because they are visible events with a date attached. Movers are neither, and they are where access quietly accumulates. We’ve all seen it, even been the recipient of accrual of access rights like badges of honour, with nobody daring to take them away.

So, for example, if someone moves from finance to operations, the operations access gets added because they cannot do the new job without it. The finance access does not get removed, because it is nobody’s specific job to remove it and no event triggers anyone to think about it. Two or three moves later, you have somebody who can raise a purchase order, approve it, and process the payment. That is a segregation-of-duties failure under control 5.3, and it arose entirely from a gap in control 5.16.

The fix is to rebuild rather than extend. When somebody changes role, their access is reconstructed from what the new role requires, rather than added to what the old role had. For an SME, this is a five-minute conversation between the line manager and whoever administers the accounts, not a project. It simply needs a trigger, and the trigger is usually getting HR to treat an internal move as a change event rather than a job title update.

What auditors will look for

As a Lead Auditor, here is what I would ask for on control 5.16, in roughly this order.

1. Your active user list against your leaver list. Give me your current identities and your leavers from the last twelve months. I am looking for names that appear on both. (It takes about ninety seconds and it finds something more often than not.)

2. The administrator group. Show me everyone holding Global Administrator or Super Admin, and justify each one. Two things live in here: personal accounts carrying permanent elevated rights, and old service accounts nobody present can identify.

3. A joiner traced end to end. Pick a recent starter. Show me the request, show me the approval, then show me the account as it exists today. Does what they have match what was asked for?

4. The service account list. This is the question that catches people. If the answer is a pause followed by “I would have to check”, that is itself the finding, because it means nobody is managing them.

5. Shared accounts and what surrounds them. I am not asking whether you have any. I am asking which ones you have and what controls sit around them.

6. Evidence that reviews happened. Dated, with a name against it. “We review regularly” is a statement of intent, not evidence.

Common issues

So to recap to some extent, but to summarise the common issues I see;

• Leaver accounts disabled and then forgotten. Disabling is a perfectly good first step. Disabled and untouched for three years is an identity you are not managing.
• A policy that bans shared accounts, written by an organisation that runs on them. The most common self-inflicted non-conformity on this control.
• Service accounts holding administrative rights because it was easier during setup and nobody revisited it.
• Third-party identities with no expiry date. The support provider who did a project in 2023 and still has standing administrative access.
• Duplicate identities for the same person, usually j.smith in one system and john.smith in another because two systems were set up in different years by different people. Logs from either look like two different individuals.
• Ownership assigned to a department rather than a person, which in practice means ownership assigned to nobody.
• Reviews documented as monthly and performed twice.

The self-check

Five questions. Answer them honestly before you go into an audit, and someone else asks them.

• Could you produce a list of every identity in your main platform, including guests and service accounts, within ten minutes?
• Does every shared and service account on that list have a named human owner?
• Take your last three leavers. Are all of their accounts disabled, and can you show the date each one was disabled?
• How many people hold Global Administrator or Super Admin, and can you justify every one of them?
• When did you last review the list, and can you prove it?

Two or more noes potentially means this control is a gap.

How control 5.16 links to other clauses and controls

I’ve mentioned a number of these as I’ve walked through the article, but to be explicit, there are a number of links to several other controls which act as sister controls, and shouldn’t be considered in isolation;

• Control 5.15, Access control. 5.15 sets the policy for who should be able to reach what. 5.16 establishes who the “who” actually is. A 5.15 policy without 5.16 underneath it is a set of rules about people you cannot reliably identify.
• Control 5.17, Authentication information. 5.16 issues the identity; 5.17 governs the credential that proves someone is legitimately using it. The handover of the first credential sits right on the boundary between the two.
• Control 5.18, Access rights. The pair most often confused. 5.16 is who you are, 5.18 is what you can do. It is entirely possible to pass 5.16 with an immaculate identity register and still fail 5.18 because everybody is an administrator.
• Control 5.3, Segregation of duties. The person requesting an identity should not be the person approving and creating it. In a very small business, that is not always achievable; in which case, document the compensating control rather than claiming a segregation you do not have.
• Control 8.2, Privileged access rights. The elevated subset of your identities, and the area auditors concentrate on hardest.
• Control 8.15, Logging. Identity events are only useful if they are recorded, and logs are only useful if the identities appearing in them are unique. The two controls are worth very little without each other.

Frequently asked questions