Access Control Policy: ISO 27001 Controls 5.15–5.18

Derek Voss's Active Directory account should have died in June 2023. It didn't die until an incident response retainer forced the question in November.

I got the call from Solander Freight & Logistics about ten days after that November weekend, and by the time I sat down with their leadership team the shape of the story was already painfully clear. Solander is a mid-market third-party logistics provider outside Columbus, Ohio — about 340 employees, contracts with a dozen regional retail chains to run warehousing and last-mile delivery. In early 2023 they brought on a contractor, Derek Voss, through a staffing firm called Ridgeline Technical Partners, for a fourteen-week engagement to help migrate their warehouse management system (WMS) onto a new cloud platform. Because the migration touched billing feeds, Voss was given a domain account with sweeping rights — effectively domain-admin-equivalent — nicknamed internally "WMS-Migration-Admin," plus a persistent VPN certificate and standing access to the financial reporting tool so he could validate invoice reconciliation during cutover.

The engagement wrapped in June. The project sponsor thanked Voss, Ridgeline invoiced final hours, and everyone moved on. Nobody told IT to turn anything off — because nobody in IT had been told to turn anything on in the first place through a formal process. Voss had never appeared in an HR onboarding feed because he wasn't an employee; the account had been created ad hoc by a systems administrator doing a favor for the project sponsor, outside the normal identity workflow. There was no leaver ticket because there was no joiner ticket. The account, the VPN certificate, and the financial-tool credentials sat there, fully privileged, for a hundred and fifty-two days.

In November, Voss's personal email was swept up in an unrelated credential-stuffing breach — one of those mass password dumps that circulates on criminal forums. He'd reused a close variant of that password for the VPN certificate passphrase he'd set up back in the spring, the kind of shortcut almost everyone takes under deadline pressure. An attacker who bought the credential list didn't even need to be sophisticated. They logged into Solander's VPN on a Saturday night, found a domain account with standing elevated rights and no multi-factor prompt in front of it, and moved laterally with almost no resistance. They pulled shipment manifests and billing records for forty retail clients out of the financial reporting system over about eighteen hours, then — seemingly as a parting message — dropped ransomware on two file shares before they left.

Solander didn't pay the ransom. They rebuilt from backups. But the total bill still came to roughly $1.85 million once you added it up: about $240,000 in digital forensics and incident response, six-figure legal and breach-notification costs, a state attorney general inquiry that dragged on for months, and — the part that actually got the board's attention — three retail clients who declined to renew, worth close to $700,000 in annual revenue, citing "access governance concerns" directly in their non-renewal letters.

I wasn't brought in to fix the breach; a specialist IR firm had already done that work by the time I arrived. I was brought in because the board's post-incident resolution instructed the CISO to pursue ISO 27001 certification, and the incident review report — in language almost identical to Annex A — had already named the failure: no access control policy, no identity lifecycle process, no authentication information standard, and no access rights review. In other words, Solander's breach was a controls 5.15 through 5.18 case study before I ever opened a laptop. This article is built around what fixing that actually looks like, because an orphaned privileged account is one of the most common — and most expensive — findings I see across every industry I audit.

The revenue-loss line is the one that changed how Solander's board talked about the incident internally. Nobody on that board could get worked up about a password policy in the abstract, but three client contracts walking out the door over "access governance concerns" turned an IT problem into a board-level one overnight.

Who This Is For

This guide is for the person who owns access governance inside an ISO 27001 project — a CISO, IT director, or IAM lead who needs to turn four dense-sounding Annex A controls into a policy people actually follow, a provisioning process that survives contact with HR turnover, and a review cycle an external auditor will sign off on without a laundry list of findings. You should already have a rough handle on your ISO 27001 Annex A organizational controls and ideally have finished (or be finishing) asset inventory work, since access control decisions are meaningless without a defined set of assets to control access to. By the end, you'll walk away with a documented access control policy, a joiner-mover-leaver (JML) workflow diagram you can hand to HR and IT, and an access-review evidence package that turns "we think we revoked that" into "here's the ticket, the approver, and the timestamp."

Control 5.15 — Access Control: The Policy That Everything Else Hangs On

Control 5.15 requires the organization to establish and implement rules to control physical and logical access to information and other associated assets, based on business and security requirements. It's the parent control — the topic-specific policy that 5.16, 5.17, and 5.18 exist to operationalize. ISO 27002:2022's guidance on 5.15 is explicit that the policy must account for two disciplines that get lip service everywhere and genuine enforcement almost nowhere: need-to-know (you get access to the specific information required for your role, not the whole system) and least privilege (you get the minimum permission level — read, not write; single-record, not bulk export — required to do the job).

At Solander, this control didn't exist in any documented form. There was an informal understanding that "IT handles access," but nothing written down about who approves what, what business justification is required, or how access decisions map back to data classification (which ties directly to the asset management work in controls 5.9–5.14 — you can't set access rules around assets you haven't classified). An auditor assessing 5.15 wants to see a topic-specific access control policy that names the rules, not just the aspiration.

"The single biggest gap I find in access control policies isn't the writing — it's that nobody can point to the moment a specific access decision was actually tested against the policy. A policy that's never been used to say no to a request isn't a control, it's a poster." — Elena Vasquez, Information Security Manager, Harlow & Finch Insurance

Control 5.16 — Identity Management: Owning the Full Lifecycle

Control 5.16 requires managing the full lifecycle of identities — the unique digital representation of a person, system, or service that access rights get attached to. This is broader than "user accounts." It covers employees, contractors, third-party users, service accounts, and non-human identities like API keys and automated integrations, from the moment an identity is created through every change in status until it's retired.

Solander's failure traced directly back here. Derek Voss never had a properly managed identity in the first place — he had an account that a well-meaning administrator created outside the identity system of record, with no linkage to an HR or vendor-management record that could ever trigger deactivation. ISO 27002's guidance on 5.16 is specific that identities should be uniquely attributable to one person (no shared logins), verified before issuance, and — critically — that the process for creating an identity must be the same process capable of destroying it. If your onboarding workflow doesn't have a corresponding offboarding trigger built into the same system, you have exactly the gap that cost Solander $1.85 million.

A practical note from the field: identity management often gets confused with access rights management (5.18), and auditors will probe the distinction. 5.16 is about the existence and state of the identity itself — does Derek Voss have a valid, current, uniquely attributable account. 5.18 is about what that identity is permitted to do — should Derek Voss's account (if it should exist at all) have rights to the financial reporting system. You need both disciplines working together, because a beautifully governed identity with runaway permissions is still a breach waiting to happen, and a tightly scoped permission set attached to an identity nobody remembers to disable is just as dangerous.

"We used to think of identity management as an HR handoff problem. It's not — it's an architecture problem. The moment you let a second system create identities outside your system of record, you've built a second front door nobody's watching." — Tomasz Nowak, Head of Infrastructure, Corvex Logistics Group

Control 5.17 — Authentication Information: Passwords, Secrets, and the MFA Question

Control 5.17 covers the allocation and management of authentication information — passwords, passphrases, cryptographic keys, tokens, and other secrets used to verify an identity. This is an organizational control: it's about the process for issuing, managing, and protecting authentication information, not the technical mechanism itself. The technical mechanism — how systems actually verify identity, including multi-factor authentication design — falls under the Technological control 8.5 Secure authentication, and the two controls are meant to be read together. Think of 5.17 as the policy and process layer (how we issue a password, how long it lives, what happens on suspected compromise) and 8.5 as the engineering layer (what authentication protocol enforces that policy).

ISO 27002's guidance on 5.17 calls out several specific practices: users must acknowledge confidentiality obligations for authentication information they hold (don't write your password on a sticky note); initial or reset credentials must be communicated through a secure channel, not plaintext email; users should be required to change any temporary or default credential at first use; and — importantly for anyone running legacy systems — default vendor passwords must be changed on all systems before they go into production. At Solander, the VPN certificate passphrase Voss set up himself, with no organizational password quality requirement enforced and no rotation trigger tied to contract end, was exactly the kind of authentication-information gap 5.17 exists to close.

"Password policy debates always turn into arguments about complexity rules. The more important question is simpler: if this credential leaked today, would anything stop an attacker from using it? If the answer is 'no, and there's no MFA either,' the complexity rules were never the point." — Anthony Reyes, Identity and Access Management Lead, Brightfield Health Systems

Control 5.18 — Access Rights: Provision, Review, Modify, Remove

Control 5.18 is where policy meets action. It requires that access rights be provisioned, reviewed, modified, and removed in accordance with the organization's access control policy (5.15) and topic-specific rules for access control. This is the control that failed most directly at Solander — Voss's rights were provisioned outside any approval workflow, never reviewed once during the entire engagement, and never removed when the engagement ended. If 5.15 is the rulebook and 5.16 is the roster, 5.18 is the referee actually enforcing the rules on the field, continuously, for as long as the identity exists.

ISO 27002's guidance on 5.18 lays out the full cycle: rights are granted based on documented approval consistent with the access control policy; rights are modified when a person's role changes (a "mover" event, which is where I see the most silent privilege creep — nobody actively grants excess access, it just never gets removed as someone moves department to department); rights are reviewed at planned intervals and after any relevant change; and rights are removed immediately upon termination of the employment, contract, or agreement, or when access is no longer required for the role. That word "immediately" is doing a lot of work in an ISO 27002 sentence, and auditors will ask you to define what immediate means in hours, not adjectives.

Mapping Access Tiers to Data Classification

Least privilege and need-to-know are only meaningful once you can point to a classification scheme that says which data is sensitive enough to restrict in the first place. This is where controls 5.15–5.18 lean directly on the asset management work in controls 5.9–5.14 — specifically classification of information — because an access control policy that treats all data as equally sensitive either over-restricts routine work or, far more dangerously, under-restricts the records that matter most. At Solander, the financial reporting tool Voss retained access to held customer billing and shipment data that should have been classified as confidential, restricted to a named list of finance and operations staff. Instead it inherited the same access tier as general operational dashboards, because nobody had mapped classification to access tier at all.

A workable mapping doesn't need to be complicated — most organizations I work with land on three to four tiers that scale cleanly from public to restricted, with access rules and review frequency escalating at each level.

Once this mapping exists, the rest of 5.15–5.18 gets significantly easier to write and to audit — your access control policy can simply state "access to Confidential and Restricted data requires named-individual approval and quarterly-or-tighter review," rather than trying to describe every system individually.

Access Control Models: RBAC, ABAC, and the Principle Underneath Both

ISO 27001 doesn't mandate a specific technical model for enforcing access control — it mandates outcomes (least privilege, need-to-know, documented approval, timely review). But almost every organization I work with ends up choosing between two practitioner models, or a hybrid, to operationalize those outcomes at scale. Understanding both helps you write a 5.15 policy that's actually implementable rather than aspirational.

Role-Based Access Control (RBAC) assigns permissions to defined roles (e.g., "Warehouse Supervisor," "AP Clerk," "Regional Sales Manager"), and users inherit permissions by being assigned to a role. It's the dominant model for mid-sized organizations because it's auditable — you can hand a reviewer a role-to-permission matrix and a user-to-role list, and the review largely writes itself. Attribute-Based Access Control (ABAC) grants or denies access dynamically based on attributes of the user, the resource, and the context (department, data classification, device posture, time of day, location) evaluated against policy rules at the moment of the access request. It's more flexible and more precise, but harder to audit by inspection because the "why" of a decision lives in a policy engine rather than a static table. Least privilege isn't a competing model — it's the design principle both RBAC and ABAC are supposed to serve; neither model automatically produces least privilege if roles are defined too broadly or attribute rules are too permissive.

"Don't let a vendor sell you ABAC as a maturity upgrade from RBAC. Most mid-market companies I audit haven't even gotten RBAC role definitions clean yet — adding a policy engine on top of messy roles just gives you a more sophisticated way to be wrong." — Sana Kural, IT Director, Vantage Precision Manufacturing

The Joiner-Mover-Leaver (JML) Process: Where 5.16 and 5.18 Actually Live

Joiner-Mover-Leaver, or JML, is the practitioner shorthand for the identity lifecycle process that operationalizes controls 5.16 and 5.18 together. It isn't an ISO 27001 control name — it's the industry term for the workflow that turns an HR event (hire, transfer, promotion, termination) into an access event (provision, modify, revoke) without a human having to remember to do it manually. Solander's breach is, in one sentence, a JML failure: there was a joiner event with no formal trigger, no mover event because there was no formal role to move from, and no leaver event at all.

A mature JML process treats every access change as downstream of an authoritative event, not as a standalone IT ticket. That means your HR system (or vendor/contractor management system, for non-employees) needs to be the system of record that starts the workflow, and IT provisioning needs to be structurally incapable of skipping the chain — no side-door account creation, ever, without an equivalent, auditable exception process.

The last row of that table is Solander's exact failure mode, and it's the one JML diagrams almost never show explicitly — the safety net for identities that never entered the formal workflow at all. If your JML process only reacts to HR events, you need a separate, scheduled reconciliation sweep that compares every active identity and credential against your systems of record and flags anything that can't be traced to a current employee or active contract. That sweep is what would have caught Derek Voss in July, not November.

Authentication Hardening: Passwords, MFA, and Secrets Management

Control 5.17 sets the policy expectations; making those expectations real requires specific technical and procedural hardening across every category of authentication information in your environment — human passwords, machine secrets, and privileged credentials each need distinct handling. For human passwords specifically, standardising the organisation on one of the best business password managers does more to enforce genuine uniqueness and length than a written policy ever will on its own.

"MFA gets treated like a checkbox for the certification audit. It's not a checkbox — it's the one control that would have stopped Solander's entire incident cold, because the attacker had a valid password and nothing else. Every access control policy I write now has one non-negotiable line: no privileged or remote session without a second factor, full stop." — Maria Ostrowski, CISO, Solander Freight & Logistics

Access Review Cadence and the Evidence Auditors Actually Accept

Access reviews are the single most-cited nonconformity I see in Stage 2 audits and surveillance audits alike, and it's almost never because organizations skip reviews entirely — it's because the review happened, but nobody kept evidence that would satisfy an auditor asking "prove it." A verbal confirmation from a manager that "access looks fine" is not evidence. A signed report naming the system, the reviewer, the date, the accounts examined, and the remediation actions taken on any discrepancy — that's evidence.

Different access tiers warrant different review frequency. Standard user access can reasonably be reviewed quarterly or semi-annually depending on your risk appetite. Privileged and administrative access — the tier that turned Voss's account into a $1.85 million incident — needs tighter cycles, often monthly, precisely because the blast radius of an unnoticed error is so much larger. Third-party and vendor access deserves its own cadence tied to contract milestones, not just calendar dates, because a contract renewal or scope change is exactly the kind of event that should re-trigger a rights review under 5.18.

A well-run review doesn't just confirm access is correct — it produces a documented trail an internal auditor can pick up cold and follow from request to approval to provisioning to review to (eventually) revocation. That trail is also what turns your access governance from a defensive compliance obligation into something your sales team can point to when a prospective enterprise client asks about your security posture during procurement.

Privileged Access Rights: The Technological Control That Backs Up 5.18

Control 5.18 sets the organizational policy for provisioning, reviewing, modifying, and removing access rights. Control 8.2 Privileged access rights, a Technological control, is where that policy gets enforced with teeth for the accounts that matter most — the ones that, if compromised, can do the most damage in the least time. Voss's WMS-Migration-Admin account is the textbook case: a privileged account that was never segregated from his day-to-day access, never time-boxed, never subject to just-in-time elevation, and never monitored with session recording.

Mature privileged access management treats admin-tier credentials as fundamentally different from standard user access, not just a higher permission tier on the same account. That means separate privileged accounts (never the same login used for email and for domain administration), just-in-time elevation instead of standing access, session recording or command logging for anything touching production systems, and a "break-glass" emergency access procedure that's itself logged and reviewed after use rather than left as an unaudited backdoor.

"If I had to pick one control that determines whether an incident stays a nuisance or becomes a headline, it's 8.2. Standard user compromise is a bad day. Privileged account compromise with no session logging and no time-boxing is a bad year." — Tomasz Nowak, Head of Infrastructure, Corvex Logistics Group

Tying Access Control to Segregation of Duties and Remote Working

Access control decisions don't happen in a vacuum — two adjacent controls shape how you should design 5.15–5.18 in practice. Control 5.3 Segregation of duties, covered alongside role definition in Controls 5.2–5.4 roles and responsibilities, requires that conflicting duties and responsibilities be separated to reduce the risk of unauthorized or unintentional modification or misuse of assets. Your access control policy should explicitly name conflicting-duty combinations — the same person shouldn't be able to create a vendor record and approve payment to that vendor, or provision their own privileged access and approve their own access request.

Control 6.7 Remote working, a People control, intersects with access control wherever employees or contractors connect from outside the office — which, for most organizations in 2026, means nearly everyone, nearly always. Remote access is exactly the pathway Solander's attacker used, and it's the pathway most organizations harden least, because VPN access often gets provisioned once and never revisited with the same rigor as an on-premises badge.

None of this lives in an ISO 27001 vacuum, either. If your organization is also pursuing or maintaining a SOC 2 report, the logical access controls criteria under the Common Criteria series ask examiners nearly the identical question Annex A 5.15–5.18 asks — who has access, why, and how do you prove it's reviewed — so a well-built JML process and access review cadence do double duty across both frameworks rather than requiring a separate build. The same is true if your board or a customer contract references the NIST Cybersecurity Framework's Protect function and PR.AC category, which covers identity management, credentials, and access permissions in language that maps almost one-to-one onto 5.16 through 5.18. I've found that framing access governance as a shared control set across frameworks, rather than three separate compliance projects, is what actually gets budget approved. Practitioners increasingly describe this whole discipline — spanning 5.15–5.18 plus the technological controls that enforce them — as Identity and Access Management for ISO 27001, and treating it as one coherent program rather than four isolated checkboxes is what separates organizations that pass audits from organizations that also stay breach-resistant between them.

Common Mistakes in Implementing Controls 5.15–5.18

Across the ISO 27001 implementations and post-incident reviews I've run, the same handful of mistakes show up in organization after organization. None of them are exotic — which is exactly why they're so common, and why auditors find them so reliably.

Handling Special Cases: Mergers, Reorganizations, and Emergency Access

Most access control failures I see happen during routine operations — the slow drip of role changes and contractor turnover that JML is built to handle. But a smaller number of severe failures happen during exceptional events, precisely because exceptional events tempt people to bypass the normal process "just this once." Mergers and acquisitions are a classic example: two organizations' identity systems get merged under deadline pressure, and duplicate or conflicting accounts often persist for months because nobody owns the reconciliation. Reorganizations create a wave of mover events all at once, which overwhelms a review process built for steady-state volume. And genuine emergencies — a production outage at 2 a.m., a ransomware response in progress — create legitimate pressure to grant access outside the normal approval chain.

ISO 27001 doesn't ask you to eliminate these exceptions; it asks you to control them. A documented emergency access (break-glass) procedure, reviewed after every use, is the difference between an exception and a permanent gap. The same discipline applies to M&A integration and reorganization waves: treat them as a defined, time-boxed project with its own reconciliation deadline, not an open-ended cleanup that quietly never finishes.

Case Studies: What Fixing 5.15–5.18 Actually Looks Like

Solander Freight & Logistics. In the six months following the incident, we rebuilt access governance from the ground up: a documented access control policy mapped to data classification, a JML workflow that made vendor and contractor management systems authoritative triggers alongside HR, mandatory MFA on all remote and privileged sessions, and a monthly privileged-access review chaired by the CISO. The first full access review under the new process found eleven dormant accounts across the environment — none as severe as Voss's, but the kind of finding that, left alone for another eighteen months, could have produced a second incident. Solander achieved ISO 27001 certification fourteen months after the breach and used the certificate directly in retention conversations with the three clients who had walked away, winning back two of them.

Brightfield Health Systems. A regional healthcare network with a sprawling mix of clinical and administrative systems came to their ISO 27001 project with over 40 loosely defined access roles and no formal review cadence. We consolidated roles to 16 well-documented RBAC definitions mapped to actual job functions, implemented quarterly access reviews for standard staff and monthly reviews for privileged clinical-systems access, and cut the average access review cycle time from roughly three weeks of manual spreadsheet reconciliation to four days using an identity governance tool integrated with their HR system. Their Stage 2 audit produced zero major nonconformities against 5.16 and 5.18 — a first for the organization after two prior failed attempts at a different framework's access control equivalent.

Harlow & Finch Insurance. This mid-size insurer had a recurring internal audit finding: access reviews were happening, but evidence was inconsistent across departments, with some managers emailing a one-line confirmation and others producing nothing at all. We standardized a single review template tied to the access rights register required under 5.18, automated distribution and reminder tracking, and required signed sign-off with named exceptions. Internal audit findings related to access review evidence dropped from seven in the prior cycle to zero in the following cycle, and the standardized evidence became a selling point in due-diligence questionnaires from reinsurance partners.

"The certification itself wasn't the win for our board. The win was being able to say, in writing, exactly how long it takes us to remove someone's access after their last day — and having a report that proves it." — Maria Ostrowski, CISO, Solander Freight & Logistics

Who Owns What: A RACI for Access Governance

One reason access control programs stall is that ownership is assumed rather than assigned. HR assumes IT handles deprovisioning; IT assumes managers report departures; managers assume HR's exit paperwork triggers everything automatically. Solander had exactly this triangle of assumptions, and Voss's account fell through the middle of it. A documented RACI (Responsible, Accountable, Consulted, Informed) closes that gap before it becomes a finding — or a headline.

This table itself doubles as evidence for an auditor asking how you satisfy Controls 5.2–5.4 roles and responsibilities in the specific context of access governance — role clarity isn't just good practice, it's a documented requirement the assessor will cross-check against what actually happens during your review cycle.

Building Your Access Control Policy Document: What to Include

I've reviewed enough access control policies to know that most fail not because the ideas are wrong, but because the document is too vague to act on. A policy that says "access will be granted based on business need" gives an auditor nothing to test and gives your own staff nothing to follow when a request lands in their queue at 4:45 on a Friday. The version that survives an audit — and, more importantly, actually gets used — reads like an operating manual, not a mission statement.

At minimum, your 5.15 access control policy document should state: the scope of assets and systems it covers; the access control model in use (RBAC, ABAC, or hybrid) and why; the approval chain for new access requests, including who can approve what tier of access; the standard for least privilege and need-to-know translated into concrete permission defaults (e.g., "new hires default to read-only on shared drives outside their department"); the review cadence by access tier; the JML triggers and owning systems; the authentication information standard (referencing 5.17 and 8.5); and the revocation SLA for leavers, both planned and involuntary. Solander's rebuilt policy runs eleven pages, which sounds long until you realize each page answers a question an auditor — or a new hire's manager — would otherwise have to guess at.

Access Governance Tooling: IAM, IGA, and PAM Platforms

ISO 27001 doesn't require you to buy software to satisfy 5.15–5.18 — plenty of small organizations run a disciplined manual process on well-structured tickets and spreadsheets and pass their audits cleanly. But as headcount, system count, and contractor turnover grow, the manual approach hits a ceiling, and most organizations I work with eventually invest in some combination of identity and access management (IAM), identity governance and administration (IGA), and privileged access management (PAM) tooling. Understanding what each category actually does helps you avoid buying the wrong layer for the problem you have.

IAM platforms handle the plumbing — authentication, single sign-on, and the technical provisioning/deprovisioning of accounts across connected systems. IGA platforms sit a layer above IAM and focus on governance: access certification campaigns, review workflows, segregation-of-duties conflict detection, and reporting that turns a review cycle into evidence rather than an email thread. PAM platforms specialize in the privileged tier specifically — vaulting admin credentials, enforcing just-in-time elevation, and recording sessions, which is exactly the gap that let Voss's account persist unnoticed. None of these categories is a substitute for the policy work in 5.15; a poorly configured IGA tool will happily automate a bad process just as efficiently as a good one.

"Buy the tool that fixes the process you've already documented. I've watched companies buy an expensive IGA platform to paper over an access control policy that didn't exist yet, and six months later they had a very well-automated version of chaos." — Anthony Reyes, Identity and Access Management Lead, Brightfield Health Systems

What Certification Reviewers Actually Test on 5.15–5.18

Stage 1 and Stage 2 audits treat these four controls differently, and knowing the difference saves you from over- or under-preparing. Stage 1 is largely a documentation check — does an access control policy exist, does it name an access control model, does it reference identity management and authentication information handling, and is a review cadence defined. Stage 2 is where the sampling happens: the auditor will pick specific joiners, movers, and leavers from your records over the audit period and ask you to walk the full trail for each one, from request to approval to provisioning to (if applicable) revocation. Surveillance audits in later years focus heavily on whether the review cadence you documented in year one is actually still happening in year three, because control fatigue is real and access reviews are one of the first things to slip once the certification is achieved.

Metrics That Matter: Measuring Your Access Governance Program

An access control program that can't produce a number is a program that's guessing. Beyond the pass/fail of an audit, a handful of operational metrics tell you — long before an assessor shows up — whether your JML process, your reviews, and your privileged access controls are actually working day to day. I ask every client I work with to start tracking these within the first quarter of building out 5.15–5.18, because the trend line matters more than any single snapshot.

Solander now reviews these six metrics monthly at the same meeting where the CISO reports to the executive team on other security KPIs. That single change — putting access governance metrics on a recurring leadership agenda rather than leaving them buried in an IT dashboard — did more to sustain the improvement than any policy document could have on its own.

Access Control as a Business Advantage, Not Just an Audit Line Item

It's tempting to treat 5.15 through 5.18 as paperwork you produce once for a certification body and then quietly let drift. I'd push back on that framing hard. Every enterprise procurement questionnaire I've seen in the last several years asks some version of "how do you provision and revoke access, and how do you know it worked" — and a company that can answer with a documented policy, a working JML diagram, and a signed review report closes deals faster than one answering from memory. Solander's board didn't fund an ISMS because they suddenly loved documentation; they funded it because the incident proved that weak access governance is a revenue problem, not just a security problem. The clients who declined to renew didn't cite the ransomware headline — they cited "access governance concerns," which is a procurement team's polite way of saying they no longer trusted the company's controls.

The organizations that get the most value out of controls 5.15–5.18 treat the work as building operational muscle memory rather than assembling an audit binder. A JML process that runs quietly every week, an access review that produces the same clean evidence every quarter, and a privileged access program that nobody has to think twice about — that's the difference between passing a Stage 2 audit and actually being harder to breach than the competitor down the street who's still doing this on sticky notes and institutional memory.

If you're building this program from scratch, start with the Statement of Applicability to confirm 5.15–5.18 are properly scoped and justified for your risk environment, and ground the underlying risk decisions in the work you did for Clause 6 planning and risk assessment — access control priorities should trace back to the risks you've already identified, not be bolted on separately. For shared terminology across your project team, PentesterWorld's ISO 27001 glossary of key terms is worth bookmarking so "identity," "access rights," and "authentication information" mean the same thing in every meeting.

To move from this article to a working program, PentesterWorld's Information Security Policy Template gives you a structured starting point for documenting your 5.15 access control policy rather than drafting from a blank page, and the Annex A — All 93 Controls at a Glance cheat sheet helps you see exactly how 5.15–5.18 sit alongside the adjacent controls referenced throughout this guide. If you're not yet sure which mandatory artifacts your auditor will expect, run through the ISO 27001 Mandatory Documents Checklist before your next internal review, and lean on the Complete ISO 27001 Implementation Guide eBook for a fuller build sequence across all four Annex A themes. When you're ready to test whether your access review evidence would actually survive scrutiny, PentesterWorld's Internal Audit Checklist is built to stress-test exactly the kind of gaps that took down Solander's first attempt at a clean audit.

Access control isn't glamorous work. It's also, control for control, one of the highest-leverage places to invest in an ISO 27001 program — because unlike a lot of Annex A, a failure here doesn't just cost you a nonconformity. It costs you the account, the contract, and sometimes the client relationship that took years to build.