Why MSP Access Recertification Is Essential for ISO 27001 A.5.18 Compliance

Why MSP Access Is the New Shared Blast Radius

MSP access is a shared blast radius because a single over‑privileged identity in your organisation can impact many customer tenants at once. When your teams hold powerful tools and administrative rights across dozens of environments, least privilege and regular access recertification stop being background admin and become core safety controls for limiting damage and keeping customers, boards and insurers comfortable.

Around 41% of respondents in the 2025 ISMS.online State of Information Security survey said that managing third-party risk and tracking supplier compliance is one of their top information-security challenges.

The MSP blast radius problem in plain terms

The MSP blast radius problem is the risk that one compromised identity or shared tool can open many customer environments in a single step. Multi‑tenant platforms and broad admin roles often span dozens of tenants, so a mistake or breach can quickly escalate from a single incident into cross‑customer impact. Security reporting has repeatedly highlighted real incidents where attackers abused MSP management tools and shared admin accounts to pivot into multiple customer networks at once, as covered by specialist outlets such as Dark Reading.

Your people cannot support customers without meaningful access, but every extra permission increases how much harm a mistake or breach can cause. Multi‑tenant tools amplify that risk, turning one set of credentials into a shortcut between customers. In a multi‑tenant MSP, a compromised shared admin account or remote management tool rarely affects just one company; it can become an attacker’s route into many, often with deep privileges and long‑standing trust.

A majority of organisations in our 2025 ISMS.online State of Information Security survey reported being impacted by at least one third‑party or vendor‑related security incident in the past year.

Many MSPs grew up on speed and trust: whoever was on call or “knew that customer best” received broad access so they could fix things quickly. Over time, those decisions accumulate into a complex tangle of shared accounts, unexpired test access and legacy admin roles that nobody wants to touch because they “just work”. ISO 27001:2022 A.5.18 shines a light on that tangle and expects you to decide, document and review who has access and why, rather than relying on informal history. The control text in Annex A.5.18 requires access rights to information and other associated assets to be provisioned, reviewed, modified and removed in line with your access control policy, which only works when those decisions about who has access and why are clearly documented and periodically challenged, as set out in ISO 27001:2022 Annex A.5.18.

Strong access governance is the quiet difference between trust and tolerated risk.

From a COO or security lead perspective, the real question is no longer “do we have access controls?” but “can we clearly describe, within minutes, which identities can touch which customer systems, with what level of privilege, and on what business basis?”. If the honest answer involves trawling through tools, tickets and tribal knowledge, then your blast radius is larger than you think and poorly governed.

Privilege creep and good enough access cultures

Privilege creep is the gradual build‑up of access when people, customers or tools change but old rights are left in place just in case. In an MSP this creep is multiplied by the number of tenants you serve: a senior engineer who has worked across many customers for years may end up with an almost unbounded combination of live accounts, roles and backdoors.

Privilege creep usually emerges from good intentions: you avoid revoking rights in case they are needed during an incident or to keep a long‑standing customer happy. Over time, those well‑meant decisions build up to a level of access nobody would accept if they saw it laid out on a single page.

Culturally, it often feels safer to leave old access alone, especially if you fear breaking service. That convenience is exactly what attackers and auditors exploit. When a breach investigation or certification audit starts asking why a particular person or service account still has high‑level access years after a project finished, we never got around to removing it is not an answer anyone is comfortable putting on record.

Seeing access as a shared blast radius rather than a purely technical detail changes the conversation. You are no longer debating whether a single VPN group or remote monitoring role is too wide; you are deciding how much cross‑customer damage your organisation is willing to tolerate if that identity is misused. That shift in framing is the perfect on‑ramp into A.5.18, because the controls purpose is precisely to make those decisions deliberate, documented and reviewable.

Book a demo

What ISO 27001:2022 A.5.18 Really Demands

ISO 27001:2022 A.5.18 expects you to control the full lifecycle of access rights so people only have the minimum they need, for as long as they need it. For an MSP that means being able to show how you provision, change, review and remove access for each identity, with clear approvals and evidence behind every decision. The Annex A.5.18 wording calls out provisioning, reviewing, modifying and removing access rights in accordance with your access control policy, and ISO 27001’s broader access‑control principles reinforce the idea that access should be limited to what is necessary for the task and duration, as reflected in implementation guides from standards bodies such as BSI.

Turning dense control text into practical verbs

A.5.18 boils down to four actions for your MSP: provision, modify, review and remove access in a consistent, traceable way. If you can describe and evidence these four stages for real identities, you are already close to satisfying the control’s intent.

On paper, A.5.18 can look abstract: “Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organisation’s topic‑specific policy and rules for access control.” In practice, this becomes four concrete verbs for your MSP, taken directly from ISO 27001:2022 Annex A.5.18:

Provision: – how new access is requested, approved and granted.
Modify: – how access is changed when roles, responsibilities or customer scopes change.
Review: – how existing access is periodically checked and recertified.
Remove: – how access is revoked when people leave, projects end or tools are retired.

For each of these verbs, A.5.18 is looking for both process and evidence. Process means you have defined who can request, who must approve, which systems are updated and how quickly. Evidence means you can show, for a sample of real identities, the request, the approval, the change and the review history.

Experienced auditors usually look less at how impressive your tooling is and more at whether they can follow a coherent access lifecycle from request to removal. If the storey is consistent, traceable and linked back to policy, they are far more comfortable than when they see isolated tickets and logs with no clear business context.

Connecting A.5.18 to least privilege and least blast radius

A.5.18 links directly to least privilege by demanding that access rights reflect business need and are actively maintained over time. The control does not just ask for a policy; it expects you to show how that policy is built into real provisioning, review and removal decisions so that the blast radius of any single identity remains as small as practical.

Least privilege and need‑to‑know are not new ideas, but A.5.18 gives them a specific operational home. It does not simply ask whether you have an access control policy; it expects that policy to be reflected in how you grant and maintain access over time. For example:

Access requests should reference role definitions that embody least privilege.
Approval workflows should ensure that business owners, not just technical leads, sign off on rights that carry material risk.
Recertification cycles should be frequent and risk‑based enough to catch privilege creep before it becomes dangerous.
Removal of access should be automatic and timely when people leave or contracts change.

For MSPs, there is an extra twist: least privilege needs to apply across internal systems (HR, finance, ticketing, documentation) and customer systems (cloud tenants, on‑prem servers, SaaS admin portals). These are often reached through the same multi‑tenant tools you already use, so A.5.18 expects you to treat that combined reach as part of your access governance, not as an informal side channel handled by engineers. This cross‑environment view is echoed in national and European guidance on MSP and supply‑chain risk, including work from bodies such as ENISA, which stresses that provider access into customer environments must sit inside formal access‑governance arrangements.

ISMS.online can help by giving you a structured place to hold policies, role definitions, approval records, review schedules and evidence of removals, all mapped back to A.5.18 and related controls. Regardless of tooling, the mindset shift is the same: access rights are no longer just about who can log in; they are about who can affect customer outcomes and how you prove that those powers are proportionate and regularly challenged.

ISMS.online gives you an 81% Headstart from the moment you log on

ISO 27001 made easy

We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.

Get started

Interpreting A.5.18 for MSPs: Internal vs Customer Access

A.5.18 applies to every in‑scope system your organisation can touch within the boundaries of your ISMS, not just your own network. As an MSP you need to be able to separate internal access, access through shared tools and direct access into customer environments, then govern all three consistently if you want a controlled blast radius.

Drawing clean boundaries between internal and customer access

You satisfy A.5.18 more easily when you map internal, shared and customer systems clearly. That map helps you decide who approves access, who operates it day to day and where to focus reviews when you are dealing with complex, multi‑tenant tools and overlapping responsibilities.

From an ISO 27001 perspective, “access rights” covers accounts, roles and technical paths into:

Your own business systems (for example, HR, CRM, finance, ticketing, documentation).
Your shared MSP tools (for example, remote management platforms, remote access gateways, password vaults, backup consoles, monitoring systems).
Your customers’ environments (for example, cloud management consoles, on‑prem servers, SaaS admin interfaces).

In reality, these categories often overlap. Your ticketing system may contain customer credentials or sensitive incident details. Your remote management platform might be both a core service tool and a gateway into hundreds of tenants. To satisfy A.5.18, you need to make those overlaps explicit and decide where each system sits in scope for access rights governance.

Practical questions that help:

For each critical system, is it “MSP‑internal”, “customer‑environment” or “mixed”?
For each category, who is allowed to approve access and who actually operates it day to day?
Can you quickly list which staff and service accounts currently have access and at what permission level?

If the answers are unclear or scattered across different owners, this is your first sign that A.5.18 is not yet fully implemented in a way an auditor would find comfortable and that your blast radius is still being defined by tribal knowledge rather than governance.

Shared responsibility between you and your customers

Access rights governance is a shared responsibility: customers remain accountable for risks to their information and systems, while you are responsible for how your teams exercise the access they are given. A.5.18 expects that shared responsibility to be explicit, documented and reflected in how access is granted, reviewed and removed across internal and customer environments.

Your customers remain accountable for the risks to their information and systems, even when you operate them. That means they ultimately decide which kinds of access they are willing to grant to your teams and tools. You, in turn, are responsible for operating those access rights within the agreed scope, proving that you follow your own policies and theirs, and keeping rights aligned with least‑privilege principles over time. Shared‑responsibility models in regulator and national‑cyber guidance for cloud and MSP arrangements, including publications from ENISA, consistently emphasise that customers retain ultimate accountability for their information risk even when operations are outsourced.

Across our 2025 ISMS.online State of Information Security survey, typical security requirements on suppliers included ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 and emerging AI‑related standards.

A practical way to express this is a simple shared responsibility model:

Customer: – defines and approves which roles are acceptable (for example, “MSP level‑two support may have read‑only access to production data, but not write access”), and participates in periodic recertifications for their environments.
MSP: – implements and enforces access according to those decisions, ensures joiner‑mover‑leaver changes are reflected quickly, runs daily controls (for example, monitoring, logging, password management) and provides clear evidence back to the customer and auditors.

In contracts, statements of work and service level agreements, you can then document who does what for granting, modifying, reviewing and revoking access. That clarity is good for ISO 27001, but it also reduces friction when incidents occur. When everyone knows exactly who owns which pieces of the access storey, you avoid the “I thought you were doing it” problem that leads to unmanaged rights and finger‑pointing.

Designing Least-Privilege Access for MSP and Customer Environments

Least privilege only works in practice when it is built into the way you design roles, assign permissions and handle temporary elevation. For an MSP that means creating realistic role models, minimising standing powerful rights and making high‑risk rights deliberate, monitored and time‑bound across both internal and customer environments.

Role-based models that actually fit MSP reality

Role‑based access works for MSPs when roles reflect how work really gets done and map directly to systems and permission levels. By defining a small, clear set of MSP roles and their required access across internal and customer systems, you can stop handing out one‑off permissions and start managing access through reusable, auditable patterns.

The first building block is a role model that reflects how your teams actually work. Instead of granting access on a per‑person, ad‑hoc basis, define a small, manageable set of role profiles, such as:

First‑line service desk engineer.
Second‑line or escalation engineer.
Project engineer or architect.
Platform administrator (for example, remote management, backup, security tooling).
Service manager or customer success lead.

For each role, describe:

Which systems the role needs to access (internal and customer‑facing).
What level of privilege is required in each (read, standard user, administrator).
Which customers or tenant groups that access should cover.

By doing this once, you avoid debating least privilege from scratch for every new person or customer. When someone joins, moves teams or picks up a new responsibility, you assign or adjust roles rather than stacking individual permissions. That also makes access reviews and recertification cycles much easier, because you can ask, “Does this person still fit role X?” rather than “Which of these many rights do they still need?”.

Reducing standing privileges and controlling temporary elevation

Standing powerful access is where MSP blast radius becomes unacceptable, so you need deliberate patterns for limiting permanent admin rights and handling temporary elevation. If you can explain which rights are permanent, which are time‑bound and how emergency access is logged and revoked, you are in a much stronger position with both attackers and auditors.

Even with good roles, MSPs often rely on powerful, always‑on access for convenience: shared “god‑mode” accounts, domain administrators left active indefinitely or broad remote management roles granted “just in case”. These are precisely the patterns that violate least privilege and amplify the shared blast radius described earlier.

A more defensible approach is to:

Limit how many people have permanent admin‑level roles, especially across multiple tenants.
Use just‑in‑time elevation for tasks that genuinely require extra rights, with clear justification and short time limits.
Enforce strong authentication and additional checks (for example, device posture or location) for all privileged access into customer environments.
Treat “break‑glass” or emergency accounts as exceptions, with strict logging, after‑the‑fact review and rapid revocation after use.

Designing this model can feel uncomfortable at first, because it challenges long‑standing habits. However, it does not have to slow delivery if you align it with existing workflows. For example, elevation can be tied to change tickets or incident records, so the context and approvals are already in place. Engineers still get what they need to do their job, but the organisation stops carrying unnecessary standing risk on idle credentials.

ISMS.online can support this design work by linking your role catalogue, access policies and change records into a single view. When you later run an access review for a customer or a tool, you see not only who has powerful access, but also whether that access aligns with a defined role, a documented business need and an agreed elevation pattern.

Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.

Book your demo

Building an A.5.18-Compliant Access Recertification Framework for MSPs

Access recertification is how you show that access rights stay aligned with least privilege instead of drifting back to “good enough”. For an MSP it is also how you prove to auditors and customers that privilege creep is actively managed across internal systems, shared tools and customer environments, rather than addressed only after incidents.

Using risk-based review frequencies instead of arbitrary dates

A risk‑based schedule for access reviews is more credible than a single review cycle for everything, and it fits naturally with MSP realities. By grouping accounts by risk and then giving each group a sensible review cadence, you show that you focus the most attention on identities that can cause the most harm if misused.

Two‑thirds of organisations in our 2025 ISMS.online State of Information Security survey said that the speed and volume of regulatory change are making security and privacy compliance harder to sustain.

ISO 27001 does not tell you exactly how often to review access rights, because appropriate frequency depends on risk. Annex A.5.18 and related implementation guidance simply require that access rights are reviewed periodically as part of your risk‑based ISMS, leaving you to choose intervals that match your own context and obligations, as explained in ISO 27001:2022 guidance.

A workable MSP pattern is to define review cadences by account or access type, rather than by system alone, and to treat the specific timings as example patterns you adapt to your risk appetite rather than fixed best practice. For example, a simple starting point is to group accounts by type and decide how often each group should be reviewed and what the reviewer should concentrate on.

Account / Access Type	Typical review cadence	What to focus on
Privileged admin accounts (internal and customer)	Monthly and after major changes	Necessity, scope, emergency use, separation of duties
Service accounts (scripts, integrations, automation)	Quarterly and after configuration changes	Ownership, purpose, logging, credentials, orphaned accounts
Support tools and remote access platforms	Quarterly	Group membership, shared roles, cross‑tenant rights
Standard internal user accounts	Six to twelve months	Role alignment, leavers, movers
Temporary or break‑glass privileged access	After each use and monthly review	Justification, duration, timely revocation, unusual activity

This table is not prescriptive, but it gives you a transparent starting point. You can adjust cadence based on your own threat model, customer commitments and regulatory context, as long as you can explain why higher‑risk identities are reviewed more often than lower‑risk ones. MSPs that adopt structured, risk‑based recertification often find that audits can become more predictable and less confrontational, because reviewers see a clear rationale behind your schedule instead of arbitrary dates.

Designing recertification workflows that people actually follow

Recertification works when reviewers see the right information, can make clear decisions and trust that changes will be implemented promptly. If you can show who reviewed what, what they decided and how fast changes were made, your A.5.18 storey is far more convincing than simply saying “we run reviews”.

Having a schedule is only half the work; you also need a repeatable workflow for each review cycle. Important design choices include:

Who reviews what: – for customer environments, a combination of your service owners and the customer’s risk or system owner often makes sense. For shared tools, your internal system owners are usually accountable.
What they see: – reviewers should see enough context to make decisions: the person or service account, their role, the systems and tenants they can access, when they last used that access and any linked tickets or projects.
What decisions they can make: – at a minimum: keep as is, downgrade (for example, from admin to user) or remove. For exceptions, there should be a path to document why access is temporarily kept despite doubts.
How changes are executed: – approved downgrades and removals must actually be implemented in the underlying systems within an agreed time frame, and that implementation should be visible in your evidence.

ISMS.online can help you orchestrate this by turning recertification into a scheduled activity with assigned owners, due dates and a single place to upload or link evidence of decisions and resulting changes. Instead of hunting through emails and tool logs, you have an audit‑ready record of who reviewed which access, when and what they decided.

Defining Roles and Responsibilities Between MSP and Customer

Clear roles and responsibilities are what turn your access‑governance design into daily practice. For an MSP, that means agreeing with each customer who defines acceptable access, who approves changes, who runs reviews and who actually removes rights when people or contracts change.

Creating a simple, explicit RACI for access rights

A simple RACI (Responsible, Accountable, Consulted, Informed) for access rights gives you a shared map of who makes decisions and who carries them out. When you can point to that map during audits or incidents, you reduce confusion and show that A.5.18 is embedded in your operating model rather than left to informal agreements.

A practical way to express the split is a RACI matrix covering the main activities in the access lifecycle. For example:

Defining who may access which customer systems: – customer is Accountable and MSP is Consulted.
Approving initial MSP access to a new customer environment: – customer is Accountable; MSP is Responsible for implementing.
Granting and changing internal MSP access to shared tools: – MSP is Accountable and Responsible; customers may be Informed.
Running periodic recertification of MSP access into a given customer: – MSP and customer share Responsibility, with clear agreement on who reviews what.
Revoking access when staff leave or contracts end: – MSP is Responsible for its staff and tools; customer is Responsible for its internal users.

Writing this down in contracts, service descriptions and procedures has two benefits. First, it gives auditors a clear narrative about how you satisfy A.5.18 across organisational boundaries. Second, it reduces friction when difficult decisions arise, such as removing access from long‑standing engineers or limiting the scope of shared admin tools.

Handling grey areas and high-pressure situations

Grey areas, such as subcontractors, offshore teams and emergency fixes, are where access rights usually drift away from policy, so you should treat them as design cases rather than exceptions. If you decide in advance who can approve unusual access, how long it may last and how it will be reviewed afterwards, you will handle incidents with more confidence and less improvisation.

Consider a subcontractor brought in to stabilise a high‑risk customer environment. Without clear rules, they might receive broad, long‑lived admin access to multiple tenants. With an agreed model, they receive a specific role for one tenant, time‑bound rights tied to a project, and a commitment that those rights are reviewed and removed as soon as the work ends.

Offshore network operations centres are another example. Teams may use shared tools that reach many customers, and time‑zone pressure can make it tempting to leave rights wide and permanent. If you define in advance which offshore roles exist, which tools they can use, how temporary elevation works and who reviews that access, you keep service fast without letting blast radius grow unchecked.

For privacy‑sensitive environments, ensure that your access rights governance also aligns with data protection obligations and privacy‑by‑design principles. That may mean involving data protection officers or legal teams in parts of the approval and recertification process, especially where personal data is concerned.

When you later demonstrate compliance, being able to show that you have thought through these difficult areas, documented them and aligned them contractually is often as important as the technical controls themselves.

ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.

Book your demo

Cadence, Metrics and Evidence: Proving Least Privilege in Practice

Once your roles, responsibilities and recertification cycles are in place, you still need to show that they work. Cadence, metrics and evidence turn least privilege from an internal claim into something boards, customers and auditors can see and trust.

Choosing meaningful indicators for boards and customers

Good access‑governance metrics help boards and customers see whether their blast radius is shrinking without drowning them in technical detail. The best indicators show coverage, timeliness and impact: how many systems are in scope, how often reviews happen on schedule and how many rights are reduced or removed because you are actively challenging access.

Examples include:

Percentage of in‑scope systems with an up‑to‑date access inventory.
Percentage of scheduled access reviews completed on time by risk tier.
Number and proportion of accounts downgraded or removed during each review cycle.
Time taken to remove access after leavers or role changes are notified.
Number of exceptions where risky access is kept with documented and time‑bound justification.

You can supplement these with qualitative indicators, such as feedback from reviewers about the clarity of the process or from customers about the transparency of reporting. Together, these measures provide a narrative that goes beyond “we have a policy” and shows tangible movement toward tighter control and reduced blast radius.

Quiet, consistent improvements in access data often tell a stronger storey than any single audit.

Standardising your evidence pack for A.5.18

A standard evidence pack for A.5.18 keeps you ready for audits and customer questions without last‑minute scrambles. When you know exactly which policies, records and logs you will present, and you keep them updated as part of normal operations, you transform access governance from a compliance fire drill into a repeatable business habit.

Auditors and customers do not want you to reinvent your evidence storey every time. A simple, standardised evidence pack for A.5.18 might include:

Current versions of your access control and access rights policies.
Role definitions for key MSP functions and how they map to permissions.
Sample access request and approval records for different systems.
Schedules and records of recent access reviews, showing decisions and completed changes.
Logs or reports demonstrating timely removal of access for selected leavers.
Examples of how emergency or temporary access was granted, used and then revoked.

If you maintain this pack in a platform such as ISMS.online, you can link each item directly to the relevant A.5.18 requirement and related controls. When an auditor or customer asks to see how you manage access rights, you are not scrambling to assemble screenshots and tickets; you are walking them through a structured, repeatable narrative.

A regular reporting cadence then keeps everyone aligned. Operational teams may look at dashboards monthly; risk committees or boards might review a summarised view each quarter; major customers might receive tailored extracts in line with contract commitments. The key is that you control the storey, anchored in data and documentation that you already use to run the business.

Book a Demo With ISMS.online Today

ISMS.online gives you a single place to design, operate and evidence MSP access governance in line with A.5.18, so you can limit blast radius and prove least privilege without drowning your engineers in extra admin. The platform is built to centralise policies, workflows and evidence for ISO 27001 and related frameworks, as described in our product documentation and customer implementation guidance on isms.online. If you want to test how robust your current access storey really is, a short demo is a practical way to compare your existing controls against the lifecycle, recertification and responsibility models described here.

A focused ISMS.online demo will show how your current access policies, role models and MSP tools can be translated into structured workflows, tasks and evidence packs. You will see how access requests and recertification cycles can be managed from one place while still respecting your existing ticketing and operational processes.

What you will see in a demo

A focused demo works best when it walks through a realistic access storey, not an abstract feature tour. You should expect to see how your roles, tools and customer environments could be mapped into a practical A.5.18‑aligned access governance model.

During a demonstration, you can expect to:

Walk through an example access rights framework mapped directly to A.5.18, built around your roles, tools and customer environments.
See how staff lifecycle changes, access requests and recertification cycles can be connected to tickets and activities your teams already manage.
Explore dashboards and evidence views that show, at a glance, which access reviews are due, where exceptions exist and how quickly changes are implemented.
Discuss a low‑risk starting point, such as piloting structured access reviews for a single high‑risk tool or a subset of key customers.

By the end of that session, you should have a concrete picture of how your existing practices could be organised into a more deliberate, auditable model without forcing a complete rebuild of your MSP.

How a demo helps you close A.5.18 gaps

A demo is not just a product tour; it is a chance to test your current access storey against the expectations of A.5.18 and related controls. Seeing how policies, roles, responsibilities and evidence come together in ISMS.online helps you spot where your biggest gaps are today and which changes would give you the greatest reduction in risk and effort.

Despite rising pressure, most respondents in our 2025 ISMS.online State of Information Security survey listed achieving or maintaining certifications such as ISO 27001 or SOC 2 as a top priority.

You do not have to redesign your MSP from scratch to satisfy A.5.18. You need a clear model, realistic recertification cadences and a place where responsibilities, workflows and evidence live together. ISMS.online is designed to give you exactly that, so you can reduce blast radius, contain privilege creep and prove least privilege with confidence. If you want to operate as a low‑blast‑radius MSP that can show controlled access on demand, booking a short demo is a practical next step for your organisation and a clear signal to your customers that you take their trust seriously.

Book a demo

Frequently Asked Questions

How does ISO 27001 A.5.18 change the way MSPs should think about “who has access to what”?

ISO 27001 A.5.18 expects you to treat access as a governed lifecycle for every identity, not a one‑time permission setting you forget about.

Viewing access across all three MSP layers

For a managed service provider, that lifecycle has to span three layers at once:

Your internal business systems – HR, CRM, finance, ticketing, documentation.
Your shared MSP platforms – RMM, remote access, password vaults, backup, monitoring.
Your customers’ environments – cloud tenants, on‑prem infrastructure, SaaS admin roles.

For each human or service account, an auditor now expects you to show:

How access was requested and approved: – who asked, who authorised, and why that level was justified.
How changes are made: when people move roles, teams or customers.
How often access is reviewed: , with different frequencies for different risk levels.
How and when access is removed: when staff leave, contracts end or tools are retired.

A quick health‑check is to pick any named engineer or service account and, without trawling through inboxes, walk someone through the full storey: original request, approval, current scope, last review, and the trigger that will remove that access. If you can’t do that reliably, you have A.5.18 gaps.

Drawing a simple swim‑lane diagram with four stages (Provision → Modify → Review → Remove) and rows for internal systems, shared MSP tools and customer tenants quickly shows where the real process is still “we ask around”. Those are exactly the weak spots ISO 27001 auditors and enterprise customers will probe.

ISMS.online helps you make that lifecycle visible and repeatable by keeping your access policies, role catalogue, workflows and evidence in one governed workspace. Your IAM, RMM and remote access tools still do the technical heavy‑lifting; ISMS.online gives you the verifiable storey about who has access to what, on what basis, and for how long – which is ultimately what A.5.18 is trying to enforce.

What does a practical least‑privilege model look like for an MSP across internal and customer systems?

A practical least‑privilege model for an MSP centres on a small, stable set of roles, very few standing admins, and short‑lived elevation when someone genuinely needs more power.

Defining roles that match how your teams actually work

Trying to tune permissions one person at a time collapses as you grow. You get more control and less administrative drag if you:

Define a clear role catalogue, for example:
First‑line support
Second‑line or specialist engineer
Project engineer
Platform / tools administrator
Service or account manager
Map each role to:
The internal systems it needs (ticketing, knowledge, limited finance views, CRM).
The MSP tools it should use (RMM, remote access, password vaults, backup consoles).
The customer environments it can touch, and at what level (read‑only, standard user, scoped admin, tenant‑wide admin).

Then decide, role by role:

Where permanent admin rights are truly justified – usually a small set of platform or security engineers.
Where admin should be just‑in‑time – temporary elevation for a specific change, with logging and clear approvals.
Where admin should never be needed, because tasks can be handled via automation, tickets or tightly scoped roles.

In practice, that usually means replacing shared “god” accounts with named admins, tightening cross‑tenant rights, and treating break‑glass accounts as rare, tightly governed exceptions rather than everyday tools.

ISMS.online lets you describe that role model once, link it to your access policies and line it up with joiner‑mover‑leaver events and access requests. When someone joins, moves team or starts supporting a new customer, you apply the same least‑privilege pattern every time instead of improvising permissions under pressure – and you have a clear, auditable explanation ready when an ISO 27001 auditor asks why a given person has a given level of access.

How should an MSP structure access reviews and recertification to keep privilege creep under control?

You keep privilege creep under control by reviewing high‑risk access more often than low‑risk, giving reviewers enough context to make decisions, and proving that downgrades and removals actually happened in the tools.

Using a risk‑based cadence rather than a flat annual review

Treating every account the same might feel tidy, but it doesn’t match how attackers or regulators think. A more defensible pattern is to set review frequencies by access category, for example:

Access type	Typical review cadence	Reviewer focus
MSP‑wide admin into customer environments	Monthly + after major changes	Necessity, scope, emergency use, SoD
Service accounts (scripts, integrations, backups)	Quarterly + after configuration	Ownership, purpose, logging, orphaned use
RMM, VPN and other remote access tooling	Quarterly	Group membership, cross‑tenant reach
Standard internal user accounts	Every 6–12 months	Role fit, movers/leavers
Temporary / break‑glass privileged access	After each use + monthly summary	Justification, revocation, unusual usage

Alongside cadence, keep reviews simple and consistent:

Assign clear owners: – typically service owners for shared platforms and joint owners with the customer for their tenants.
Provide context, not just usernames: who the account belongs to, what it can do, when it was last used, why it exists.
Record a decision for every identity (keep, downgrade, remove) and track that changes are implemented in your directories and tools, not just clicked in a spreadsheet.
Flag high‑risk access kept by exception and insist on short‑dated justification and a specific plan to revisit it.

ISMS.online allows you to schedule those reviews, assign reviewers, and attach exports or reports from IAM, RMM, VPN and remote access tools so that decisions and follow‑up live in one place. That turns “we review access regularly” from a hopeful statement in a policy into a visible, repeatable control you can walk through calmly with an ISO 27001 auditor or a demanding customer security team.

How can an MSP clearly split access‑rights responsibilities with each customer?

You avoid gaps and blame‑shifting when you agree a written, plain‑English responsibility split with each customer and embed it in contracts, service descriptions and runbooks.

Converting “shared responsibility” into a testable agreement

A simple, effective pattern is a RACI‑style model that spells out who is accountable for what:

The customer is accountable for:
Deciding who may access which of their systems, tenants and data.
Approving your initial and ongoing access into their environments.
Taking part in, or explicitly signing off, periodic access reviews for their tenant.

The MSP is accountable for:
Implementing and enforcing those decisions in your tools and among your staff.
Operating day‑to‑day controls – logging, monitoring, password and key management, automation rules.
Keeping access aligned with least‑privilege and revoking it promptly when people leave or scopes change.
Providing regular, clear evidence of access requests, approvals, reviews and removals.

Together, you agree how this works when:

A new customer is onboarded and initial access into their tenant is approved.
A new service, region or project requires deeper or broader access.
Subcontractors or offshore teams are brought in and need tightly scoped rights.
You require emergency access during an incident and then have to step that back safely.

Writing this down in a straightforward RACI and embedding it in agreements and operating procedures gives you a repeatable A.5.18 storey. When you need to decline an overly broad request or remove access that’s no longer justified, you can point to the agreed model instead of arguing case by case.

ISMS.online lets you link that RACI, your access policies, and customer records so you can answer the inevitable “Who decides what for this tenant, and how do you prove it?” with a single, coherent view rather than hunting through contracts and old meeting notes.

What kinds of metrics and evidence actually convince auditors and customers that least privilege is real?

Auditors and customers are persuaded when you combine a small, stable set of metrics with concrete artefacts that back up your claims, not by adding more policy text.

Building a short, credible access‑governance scorecard

For a managed service provider, a useful scorecard might track:

Coverage: – percentage of in‑scope systems and tenants that have a current, named access inventory.
Timeliness: – proportion of scheduled access reviews completed on time for each risk tier.
Impact: – number and percentage of accounts downgraded or removed in each review cycle.
Responsiveness: – median time to remove access after a leaver, role change or contract end.
Exceptions: – count of high‑risk rights retained with documented justification and a next review date.

Those numbers land best when they sit alongside a standard evidence pack, for example:

Your current access‑control policies mapped to ISO 27001 A.5.15–A.5.18.
Role definitions for core MSP and customer‑facing functions.
Samples of access requests and approvals, including where the customer has signed off.
Recent review records and change logs for representative tools and customer tenants.
A handful of examples that show leaver processes and emergency access being granted, logged and revoked.

ISMS.online lets you connect each metric and example back to the clause or control it supports, assign owners and keep everything refreshed through normal operations. When an ISO 27001 auditor or a key customer asks, “How do you know your least‑privilege model is working?”, you can pull a consistent pack in minutes and show that you can demonstrate control instead of hoping a slide deck or a verbal explanation will be enough.

How can ISMS.online help an MSP operationalise A.5.18 without slowing engineers down?

ISMS.online gives you a governance and evidence layer for A.5.18 so you can design, assign and prove access control, while your engineers carry on using the technical platforms they already know.

Converting today’s ad‑hoc decisions into a governed access regime

In day‑to‑day terms, your team can use ISMS.online to:

Capture an A.5.18‑aligned access policy, a realistic role catalogue and an MSP/customer RACI in one place, so everyone can see who can approve and hold what access.
Link joiner‑mover‑leaver workflows and access requests to HR or ticketing systems, so changes in people and responsibilities reliably drive changes in access.
Schedule risk‑based access reviews for high‑risk accounts, tools and tenants, assign reviewers, and attach exports or screenshots from IAM, RMM, VPN, password vaults and other platforms as the record of what was checked and adjusted.
Maintain a live evidence pack for A.5.18 and related access controls that is ready for ISO 27001 audits and customer due‑diligence requests, instead of re‑assembling it in a panic from spreadsheets and email trails.

Because ISMS.online focuses on who decides, who approves, who reviews and how you prove it, your engineers continue to make the actual permission changes in your existing stack. You gain a coherent, repeatable storey for access governance; they gain clearer guardrails, fewer improvised approvals and far fewer last‑minute “can you pull this access report by tomorrow?” requests.

If you want your MSP to be the one that can show boards and customers that access is controlled and blast radius is limited – rather than hoping people simply take your word for it – it is worth seeing how similar providers are using ISMS.online to structure A.5.18. It helps you show up as the partner who can show controlled access on demand, not just promise it at audit time.

A.5.18 Access Rights – MSP Access Recertification & Least Privilege