Why MSP Access Control Is Critical for ISO 27001 Trust and Audits

When MSP access control becomes a multi‑tenant liability

MSP access control becomes a multi‑tenant liability when the same people and tools can reach many customers without clear, enforced rules. In that situation, one weak identity or misused tool can affect many tenants at once, and you struggle to show customers or auditors that access is genuinely under control.

When you manage many customers, unmanaged access can quietly turn into a multi‑tenant liability that affects every organisation you serve. Even if you have not yet experienced a breach or a difficult audit, rising expectations from regulators and customers mean your access practices are already under scrutiny. This information is general and does not constitute legal or professional advice; you should always seek guidance from a qualified adviser for your situation.

Trust is fragile when many people hold invisible keys to many places.

Why multi‑tenant access magnifies risk

Multi‑tenant access magnifies risk because a single weak identity or tool can be a bridge into many customer environments at once. Guidance from national cybersecurity agencies, such as CISA’s insights on MSP supply‑chain cyber risk, notes that attackers deliberately target shared MSP tools and identities because of the leverage they offer across multiple customers. If that bridge is misused or compromised, the impact can quickly jump from one tenant to many and turn a local issue into a systemic outage.

A useful first step is to map every way your staff and tools can touch client systems. That includes privileged accounts in customer directories, access to cloud management consoles, shared vaults for credentials, remote monitoring and management platforms, backup systems and support jump hosts. When you sketch these relationships on one page, you often discover that a small set of identities and tools can reach a large percentage of your customer base.

This visual “blast radius” view does two things. It sharpens leadership’s understanding of where access risk really lives, and it makes the business case for investing in access governance easier to explain. Instead of abstract talk about zero trust, you can point to a concrete diagram and say, “If one of these identities is misused, here is what could happen.”

Where customers and regulators are focusing

Default Description

Book a demo

What ISO 27001:2022 Annex A.5.15 really expects

ISO 27001:2022 Annex A.5.15 expects you to define clear rules for controlling physical and logical access to information and assets, then prove they are applied in practice. For an MSP, that means a central access control policy that covers internal systems and every path your people and tools use to reach customer environments. ISO’s own overview of ISO 27001:2022, including Annex A, emphasises that access controls such as A.5.15 must be supported by evidence of implementation and effectiveness, not policy statements alone, which is why auditors consistently ask how your rules work in practice.

The 2025 ISMS.online State of Information Security survey reports that almost all respondents list achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority.

The control pushes you beyond vague good intentions towards systematic access decisions. It requires you to be explicit about who may access what, under which conditions, and how that access is granted, adjusted and removed across all customer environments you serve.

The formal objective of A.5.15

The formal objective of A.5.15 is to ensure that access is authorised based on business and security needs, and that unauthorised access is prevented. In practice, auditors often ask to see not only your policy but also the evidence that real access decisions follow it.

It is not enough to say you use strong passwords or enable multi‑factor authentication. The standard expects you to think systematically about how access decisions are made and enacted, and how you can demonstrate that in a consistent way. That expectation aligns with ISO’s own description of ISO 27001:2022, which presents Annex A controls as requirements that must be both defined and demonstrably implemented.

At a minimum, an access control policy should define the scope of assets it covers, the principles that guide access decisions and the roles and responsibilities involved. In an MSP, that scope includes your internal systems and every path into client environments that your staff or tools can use. The policy should also state how often it will be reviewed, by whom and how changes will be approved.

A.5.15 sits alongside other access‑related controls in the 2022 revision. Identity management is captured under A.5.16 and privileged access under A.8.2, while A.5.17 covers authentication information. Together, these controls form the backbone of your access governance storey: the policy sets the rules, identity lifecycle implements them, and privileged access management keeps the most powerful rights under tight control. Independent explainers of the updated control set, such as summaries of ISO 27001:2022 Annex A controls, group these requirements together as the access‑governance family that must work in concert.

What a good access control policy covers

A good MSP access control policy turns principles like “least privilege” and “need‑to‑know” into specific, repeatable rules. People should be able to read it and understand how to grant, use and remove access in a consistent way.

You would typically expect to see sections covering:

scope and applicability (services, systems, tools and environments)
access principles (least privilege, separation of duties, default deny)
standard role definitions for core MSP job families
access categories (user, administrative, emergency)
joiner‑mover‑leaver lifecycle for staff and contractors
approval rules for different access types and changes
authentication requirements, including multi‑factor for high‑risk access
logging and monitoring expectations for privileged activity
frequency and scope of internal and joint access reviews
exception handling, including approval, documentation and review

For Annex A.5.15, these elements demonstrate that you have thought through access at a policy level and are not relying solely on tool defaults or informal norms.

How A.5.15 connects to identity and privileged access

In an MSP setting, Annex A.5.15 only works when it is tightly connected to identity and privileged access management. Your policy must describe the rules, and your identity and privilege processes must reliably apply them across many tenants.

Identity management under A.5.16 covers how staff identities are created, changed and removed, and how those identities link to accounts and tokens in the systems you manage. If your policy says access is removed promptly when staff leave, your identity processes must ensure that access into every client environment is revoked when a person leaves or changes roles.

Privileged access under A.8.2 focuses on elevated rights, such as domain administrators, cloud subscription owners or security tool administrators. Your access control policy should define what counts as privileged, which roles can hold such rights, and under what safeguards (for example, separate named admin accounts, multi‑factor authentication and session monitoring).

Without robust identity lifecycle and privileged access controls, Annex A.5.15 remains largely theoretical. When auditors review your implementation, they will expect to see that the policy, identity lifecycle and privileged access practices reinforce one another. Customers will expect the same alignment when you present your access governance narrative during due diligence.

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

Designing one central MSP access control policy for many tenants

A single, central MSP access control policy gives you one rule‑set for all customers, while still allowing for customer‑specific add‑ons where contracts or regulations demand more. It becomes the backbone for every access decision your teams make.

Designing one central access control policy for an MSP means creating a rule‑set that applies across all customer environments while still allowing for clear exceptions. Done well, this central policy becomes the anchor for every access decision your teams make and the main reference point for auditors and customers.

Choosing MSP‑wide scope and structure

Choosing the right scope and structure means writing from your own organisation’s perspective and then describing how that model applies wherever you touch customer systems. The policy should feel like your operating manual, not an abstract standard, and it should reflect the realities of multi‑tenant tools rather than a single internal network.

A central MSP access control policy should describe how your workforce identities, roles, processes and tools operate when accessing any client environment within your service scope. That includes remote monitoring and management platforms where one console account may have visibility of dozens of customers at once.

A practical approach is to structure the policy around your services and role types. For example, you might define standard roles such as service desk analyst, network engineer, cloud engineer, security analyst and customer success manager. For each role, describe the types of systems they may access, the maximum level of privilege and the conditions that must be met.

Instead of writing separate policies for each customer, use annexes or profiles to capture variations. Your core policy might state that all privileged access must use multi‑factor authentication and named accounts, while a profile for a highly regulated financial or health customer adds more detailed logging, shorter session time‑outs or stricter approval rules. This lets you maintain one consistent backbone while flexing where contractual or regulatory obligations demand more.

It is also important to define which systems and tools fall under the policy: your own internal systems, shared multi‑tenant platforms such as remote monitoring tools and access directly into customer networks and cloud environments. If your staff or tools can touch it, it should be in scope.

Defining baselines, exceptions and ownership

Defining non‑negotiable baselines, tightly controlled exceptions and clear ownership makes a central policy enforceable instead of aspirational. People need to know what always applies, when you can deviate and who must sign it off.

A central policy works best when it sets out baselines that apply to every customer and every environment. Typical baselines might include unique named accounts for staff, multi‑factor authentication for any privileged or remote access, time‑bound emergency access and logging of all administrative actions in systems above a defined risk level.

You can then define a process for exceptions. Sometimes a customer environment or legacy system cannot meet your baseline straight away. In those cases, the policy should require a documented risk assessment, formal approval at an appropriate level, clear compensating controls and an expiry or review date. Otherwise, “temporary” exceptions quickly become permanent.

Ownership is equally important. The policy should spell out who is responsible for authoring, approving and reviewing it, and who is accountable for implementing specific parts. In practice this might involve your CISO, information security manager, heads of service lines and team leaders. Embedding these responsibilities into job descriptions and objectives helps ensure the policy does not become “everyone’s job and no one’s job.”

Keeping the policy living and usable

Keeping the policy living and usable means reviewing it when your services, tools or risks change, and presenting it in a way that engineers can actually use. A smaller, clear policy with supporting guides is more valuable than a dense document nobody reads.

A central access control policy only adds value if it reflects how your MSP actually works today. That means it must be reviewed and updated as services, technologies and threats evolve, not just on a fixed calendar.

A simple mechanism is to set a review cadence, such as annually for the full policy and more often for high‑impact sections. However, you should also identify triggers that warrant an out‑of‑cycle review, such as onboarding a major new customer in a regulated sector, adopting a new core platform or identifying access‑related findings in an incident or audit.

Usability matters too. Long, dense policy documents may satisfy a documentation requirement, but they do little to guide daily behaviour. Consider producing short, role‑specific guides derived from the policy, explaining in plain language how a service desk analyst should request and use access, how an engineer should handle emergency changes or how a customer success manager should answer access‑related questions.

A platform such as ISMS.online can help you keep this central policy “alive” by linking it directly to risks, controls, tasks and evidence. Updates and responsibilities are tracked in one place instead of disappearing into shared drives, which makes it easier for your teams to act on the policy and show auditors that Annex A.5.15 is embedded rather than theoretical.

Making shared responsibility real with customers

Access control for MSPs is always a shared responsibility: you control how your people and tools behave, and customers control their environments and approvals. Annex A.5.15 lands well when this shared model is written down, agreed and revisited regularly. Regulators that emphasise accountability, such as the UK Information Commissioner’s Office in its accountability framework, stress clear allocation of responsibilities between parties in exactly this way.

In the 2025 ISMS.online State of Information Security survey, about 41% of organisations highlighted managing third-party risk and tracking supplier compliance as a top challenge.

Access governance for MSPs is always a shared responsibility between provider and customer. Annex A.5.15 expects you to define your side of the rules clearly, but you cannot manage access risk in isolation. You need a shared model that customers understand, accept and help maintain through everyday decisions and governance forums.

Designing a shared responsibility model

A shared responsibility model clarifies who is accountable, who executes and who reviews each access‑related task across the service boundary. It turns vague expectations into specific “who does what” for every major system type, which is exactly what many enterprise customers now expect to see in security reviews.

For each major system type-such as on‑premise infrastructure, cloud subscriptions, security tools and software‑as‑a‑service platforms-you should clarify:

who approves access for MSP staff into the customer’s environment
who technically grants and revokes that access
who is responsible for monitoring and logging
who performs periodic access reviews
how responsibilities change in emergency situations

In many cases, you as the MSP will grant and remove access in your own tools and in customer systems where you hold administrative roles, but the customer will retain authority to approve or reject access requests. Documenting this division helps avoid gaps where neither party realises they are accountable.

A simple way to capture this is through a responsibility matrix that assigns roles such as “Responsible”, “Accountable”, “Consulted” and “Informed” to both parties. This matrix then becomes a reference point for contracts, onboarding plans and periodic governance reviews, including regular service review meetings or quarterly business reviews.

Steps to build a shared responsibility model

List system types your services touch, such as on‑premise, cloud, security tools and SaaS.
Define key activities for each system, including approve, grant, monitor, review and respond.
Assign RACI roles between your organisation and the customer for each activity.
Review and agree the model during onboarding, then update it as services and risks change.

Embedding access governance into contracts and relationships

Embedding the shared model into contracts and governance meetings ensures it is acted on rather than forgotten. Contracts set expectations, and regular reviews keep both sides aligned as services and risks evolve.

Once you have a shared responsibility model, it needs to be reflected in your contractual documents and ongoing interactions. Master service agreements, statements of work and data processing agreements should all describe how access will be governed.

This may include commitments to maintain a central access control policy, to use named accounts and strong authentication, to log and review privileged access and to notify customers of significant changes or incidents related to access. On the customer side, contracts can require timely notification of staff changes, timely review of access reports and participation in joint access reviews.

During pre‑sales, onboarding and QBRs, it is helpful to discuss these topics explicitly. Asking customers which regulations, internal policies or industry expectations they must meet can reveal where your standard baseline should be strengthened for them. Capturing these needs clearly at the start reduces friction later when security questionnaires or regulators ask for evidence.

Regular governance meetings-quarterly or semi‑annual-provide an opportunity to review how the model is working. You can walk through access reports, exceptions, incidents and upcoming changes. Recording actions and decisions from these sessions strengthens both Annex A.5.15 compliance and customer trust.

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

Book your demo

Technical and procedural controls for multi‑tenant access

Annex A.5.15 becomes real when technical controls and procedures work together to enforce your rules across many tenants. Strong identity lifecycle, careful privileged access design and well‑configured multi‑tenant tooling are where MSPs can materially cut risk.

A well‑designed policy must be supported by practical technical and procedural controls. For multi‑tenant MSPs, controls that centralise decision‑making while enforcing separation between tenants are particularly important, because one mis‑step can have consequences across a large customer base.

Identity lifecycle and least privilege in practice

Identity lifecycle management and least privilege keep access aligned with people’s roles from their first day to their last. If you can reliably trace and adjust every identity, you dramatically reduce the chance of forgotten access paths into customer systems.

Identity lifecycle management is fundamental to making Annex A.5.15 work in real operations. Every member of staff and every contractor who can access customer environments should have a unique identity, with all access tied back to that identity.

Joiner‑mover‑leaver processes should be tightly integrated with access workflows. When someone joins, their role determines which standard access roles they receive. When they move between teams or responsibilities, access should be adjusted rather than simply added. When they leave, all access into your own systems and all customer environments should be revoked promptly and verified.

Least privilege in this context means designing role‑based access so that staff have only the rights they need for their usual duties. For example, first‑line support may need limited access to view configuration and initiate certain tasks, while senior engineers can perform higher‑impact changes but only in systems they are responsible for. Generic “super admin” roles should be replaced with narrower scopes wherever the technology allows.

A simple identity lifecycle sequence

Define standard roles and map each role to allowed systems and privileges.
Provision access by role when people join, not by ad hoc direct permissions.
Adjust roles on moves and remove access that no longer matches responsibilities.
Revoke and verify access across all systems, including customer tenants, when people leave.

Combining role‑based access with automated provisioning makes it easier to avoid privilege creep and orphaned accounts. It also makes periodic access reviews more meaningful because reviewers can see whether access matches defined roles, rather than trying to interpret long lists of individual permissions.

Stronger controls for privileged access

Privileged access needs tighter controls because mistakes or attacks at this level can affect many tenants at once. Named admin accounts, multi‑factor authentication and just‑in‑time elevation reduce blast radius and support your Annex A.5.15 storey.

Privileged access is where the stakes are highest. These are the rights that can change security settings, create or delete accounts, alter backups or access sensitive data across multiple tenants. A mistake or compromise at this level can undo many other controls.

Good practice includes using separate named accounts for administrative tasks, distinct from day‑to‑day user accounts. These admin accounts should always use multi‑factor authentication, ideally with methods that resist phishing attacks. Shared administrator accounts should be eliminated or tightly controlled with secure vaulting and detailed access logs.

Just‑in‑time access, where elevated rights are granted temporarily in response to approved requests and then removed, can significantly reduce the amount of standing privilege in your environment. Even if full automation is not possible for all systems, implementing time‑bound access for the highest‑risk platforms is a strong step.

Logging and monitoring must be proportionate to the risk. Every privileged action in critical systems should be captured with enough detail to understand what was done, by whom and when. Alerts for unusual patterns-such as out‑of‑hours changes, access from unexpected locations or privileged activity outside normal service windows-help you detect misuse early and respond quickly.

Multi‑tenant tooling patterns that support A.5.15

Multi‑tenant tools can either reinforce or undermine your Annex A.5.15 implementation, depending on how you configure them. Tenant‑level separation, role scoping and central identity integration are simple design choices that make a big difference.

Many MSPs rely on shared tools such as remote monitoring and management platforms, ticketing systems, backup services and cloud management consoles. The way these tools are configured can either strengthen or weaken your Annex A.5.15 posture.

Where possible, use segmentation features to separate customer environments logically. That may include tenant or site constructs, separate groups or distinct management scopes per customer. Staff roles within these tools should restrict access to only the customers they serve, so an engineer can only see and act on systems for the organisations they support.

Integrating these tools with a central identity provider allows you to enforce consistent authentication, apply conditional access policies and simplify offboarding. When someone leaves, you should be able to remove them from the identity provider and know that their access disappears across all integrated tools and customer environments.

Procedurally, link your technical controls to ticketing or workflow systems. Requests for new access, changes to privilege levels and emergency access should all have corresponding records with approvals. This linkage makes it much easier to prove that access was granted according to your policy and business needs, not ad hoc.

As you put these controls in place, you will start to see which parts are strong and which are missing or inconsistent. Those weaknesses often show up clearly in audits, which is where many MSPs first confront the practical impact of Annex A.5.15.

Common MSP gaps and how they show up in audits

Common MSP gaps around Annex A.5.15 usually involve unclear scope, inconsistent treatment of identity types and a drift between written policy and actual practice. Auditors often discover these weaknesses quickly because they appear in both documents and day‑to‑day operations.

In the 2025 ISMS.online State of Information Security survey, roughly two-thirds of organisations said the speed and volume of regulatory change are making compliance harder to sustain.

Even mature MSPs often discover gaps when they look at Annex A.5.15 through a multi‑tenant lens. A typical pattern is that the concepts are understood, but the real‑world implementation lags behind, especially where many customer environments and tools are involved.

Imagine an MSP where the access control policy was written years ago for internal systems and never updated. In an ISO 27001 audit, the assessor asks how that policy applies to a remote monitoring platform that can reach every customer. The team can only describe informal practices and isolated tool settings. The likely outcome is a finding that the policy does not cover real access paths, even if no incident has occurred.

Typical policy and design gaps

Typical policy and design gaps appear when your central access control policy does not explicitly cover MSP‑to‑client access, or when it ignores contractors and third parties with powerful rights. These omissions are easy for auditors to spot, and they raise questions about how well your policy matches reality.

One common gap is that the access control policy does not explicitly cover MSP‑to‑client access. It may have been written with internal systems in mind and only later extended informally to customer environments. Auditors and customers will notice when the policy language feels generic and does not describe how your people and tools interact with client systems.

Another frequent issue is inconsistent handling of identity types at design level. Staff identities might be clearly defined in policy, but contractor, temporary, offshore or third‑party identities are treated as special cases or omitted. In an MSP, these populations often have significant access and must be included in the central policy, role model and risk assessments.

Policies may also describe ideals that are not reflected in real configurations. For example, the policy might state that multi‑factor authentication is required for all remote access, but legacy VPNs or service accounts bypass that requirement. When auditors compare documentation with practice, these inconsistencies quickly lead to findings.

Operational gaps auditors and customers notice

Operational gaps show up when auditors ask how access is actually managed and you can only describe manual processes, scattered spreadsheets or irregular reviews. Customers see the same weaknesses when you struggle to say who has access to their environment today and how that access was approved.

Operationally, auditors will look for evidence that your access rules are being followed day to day. They will ask how quickly access is revoked when staff leave, how often access reviews occur and how you ensure tenant isolation in shared tools.

If your answers rely on manual processes, spreadsheets and informal knowledge, you may be judged to have weak control effectiveness even if incidents have not occurred. Similarly, if access reviews are irregular, incomplete or poorly documented, auditors may conclude that excessive or orphaned access is likely.

Customers performing third‑party risk assessments will notice when you cannot provide clear reports showing who has access to their systems, when that access was approved and when it was last reviewed. They may also question your maturity if you cannot explain, in simple terms, how your access model prevents one customer’s issue becoming another customer’s problem.

Using metrics to prioritise improvements

Simple, focused metrics help you move Annex A.5.15 from vague concern to concrete improvement work. They give you a way to prioritise and to show progress to leadership and customers.

Rather than trying to fix everything at once, it is often more effective to choose a handful of access‑related metrics and use them to guide improvements.

Identity and access hygiene metrics might include:

percentage of staff with access only through defined roles
average time to revoke access after a leaver is recorded
number of privileged accounts per engineer or per customer

Governance discipline metrics might include:

percentage of access reviews completed on time
number of open policy exceptions and their age

Tracking these metrics over time shows whether your changes are making a difference. It also gives you practical data to share with leadership when requesting investment or reporting on progress. Annex A.5.15 is easier to manage when you can point to measurable trends rather than relying on subjective judgements about whether access control “feels better”.

Organisations that tighten access governance in this way often report that audits feel more predictable, evidence searches are less time‑consuming and customer conversations about access become easier and more confident. Once you have clearer metrics and fewer gaps, the next step is to organise your evidence so it tells a coherent storey.

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

Book your demo

Proving access governance to auditors and customers

You prove Annex A.5.15 by showing a clear line from written rules, through processes, into real‑world evidence that access is granted, used and reviewed as you claim. That line should be easy to follow for auditors, customers and your own leadership.

Annex A.5.15 is ultimately judged not just by the words in your policy, but by the evidence that your rules are implemented and effective. A deliberate approach to evidence collection and presentation will make audits and customer reviews significantly less painful and more predictable. Guidance from standards bodies and certification organisations, such as overviews of ISO 27001 from national standards providers, emphasises the same point: auditors look for implementation and effectiveness through evidence, not policy text alone.

Designing an access governance evidence library

An organised evidence library turns a pile of screenshots and exports into a coherent storey about how you govern access. Each major part of your policy should have matching procedures, records and oversight documents that you can find and present quickly.

A helpful way to think about evidence is as a layered library. At the top sits your access control policy, describing what should happen. Beneath it are procedures and standards that explain how the policy is implemented in processes and tools. Below that are workflows, tickets and other records showing what actually happened. Logs and reports from tools provide another layer of detail. Finally, review records and management sign‑offs demonstrate oversight.

For example, an auditor might follow a single line from a policy rule on privileged cloud access, to a standard operating procedure for granting that access, to a ticket where a named engineer was approved, and finally to a log record showing how the account was used and later reviewed.

Designing this library structure on paper before you start gathering evidence clarifies what you need. For Annex A.5.15, you will want to ensure that each major aspect of the policy-such as access provisioning, privileged access, identity lifecycle, emergency access and access reviews-has corresponding procedures and records.

Once the structure is clear, you can map your existing systems to it. For example, your identity provider may provide access reports, your ticketing system may hold approval records, your privileged access platform may contain session logs and your ISMS platform may link risks, controls and evidence items together. The goal is not to centralise all data, but to have a clear, repeatable way to show where each piece lives.

Automating evidence wherever reasonable

Automating key evidence where possible keeps it current and reduces the scramble before audits or due diligence. Standard reports, tagged tickets and scheduled reviews all make Annex A.5.15 easier to demonstrate on demand.

Reliance on manual screenshots and one‑off exports leads to stale and inconsistent evidence. Where possible, aim to automate the capture of evidence or at least make it reproducible on demand.

For instance, you might design standard reports in your identity or access management tools that list current users and their roles per customer. You might configure your ticketing system to tag access‑related requests in a way that allows quick filtering for approvals. You might schedule regular exports from logging systems that summarise privileged activity for specific platforms.

Automating periodic access reviews can also help. If your tooling can send reviewers a list of accounts to certify, capture their decisions and record completion, then those review records become straightforward evidence. Even if technology does not support full automation, having a consistent template and schedule for reviews is a big improvement over ad hoc approaches.

A platform such as ISMS.online can act as the governance layer tying these sources together. By linking controls and policies to specific evidence items, tasks and owners, you can see at a glance whether there are gaps and where you need to focus before an audit or major customer review.

Packaging evidence for different audiences

Different audiences need different cuts of the same evidence library: auditors want traceability, customers want tenant‑specific assurance and leadership wants risk and trend visibility. Preparing a few standard packs in advance makes each conversation more controlled and efficient.

External auditors often want traceability. They will expect to follow a path from control objectives and policy clauses, through procedures, into samples of real access decisions and finally into logs and review records. Enterprise customers usually want tenant‑specific assurance: who from your organisation can access their systems, what they can do and how that access is overseen. Internal leadership is likely to focus on risk exposure and trends.

It is worth preparing a small set of standard evidence packs tailored to these audiences. An auditor pack might include the central access control policy, related procedures, samples of access requests and approvals, review records for a defined period and summary reports from your tools. A customer pack might focus on how your staff access their environment specifically, who currently has access, how that access was approved and how often it is reviewed. An internal leadership pack might highlight key metrics, recent improvements and any open risks.

Rehearsing how you will talk through these packs can reveal gaps in both evidence and narrative. Running internal mock audits or due diligence sessions focused solely on access governance helps your teams become comfortable explaining how Annex A.5.15 is implemented in your MSP. Organisations that invest in this preparation typically find that real audits and customer reviews feel more like confirmation of good practice than a hunt for weaknesses.

Book a Demo With ISMS.online Today

ISMS.online can help you turn Annex A.5.15 from a static policy document into a more living access governance practice that fits the way many MSPs operate. Instead of juggling spreadsheets, scattered documents and tool‑specific reports, you can manage your access rules, responsibilities, risks and evidence in one connected workspace.

See your central access policy in action

When your central access control policy is connected to day‑to‑day tasks and evidence, it stops being theory and starts guiding real decisions. In ISMS.online, you can host your central MSP access control policy, map it directly to Annex A.5.15, A.5.16 and A.8.2, and assign ownership for each part so responsibilities are always clear.

You can also attach current evidence to each control: access review records, summaries from identity platforms, privileged access reports and minutes from customer governance meetings. When an auditor or customer asks how you govern access, you are not scrambling for documents; you are walking them through a structured, up‑to‑date view of your governance model that reflects how you actually operate today.

If you would find it helpful to see a worked example of this kind of access governance library in a live system, the ISMS.online team can walk you through how other MSPs structure their Annex A.5.15 storey in practice and where you could adapt similar patterns.

Access governance becomes much easier to sustain when reviews, exceptions and improvements are handled through a shared workflow instead of ad hoc effort. ISMS.online is designed to support that workflow by helping you schedule reviews, track exceptions and manage improvements over time.

You can set up recurring tasks for access reviews, link them to specific systems or customers and record decisions in a way that is easy to retrieve. Exceptions to your access policy can be logged with risk assessments, approvals and expiry dates, so you can demonstrate control even when you need to deviate from the baseline. Role‑based views make it simple for founders, CISOs, compliance leads and account managers to see the aspects of Annex A.5.15 that matter most to them.

If you want to move from policy‑on‑paper or tool‑led but ungoverned access into a governance‑led, evidence‑ready model, ISMS.online is designed to help you do that in a structured way. When you are ready, a conversation with the team can show you how to map your current Annex A.5.15 reality into a coherent access governance workspace that supports ISO 27001, customer trust and day‑to‑day operations alike.

Book a demo

Frequently Asked Questions

What does ISO 27001:2022 Annex A.5.15 really expect from an MSP?

Annex A.5.15 expects your MSP to run one coherent, risk‑based approach to deciding who can access what, and to be able to prove that you follow it. That covers your own platforms and every route your people, partners and tools use into customer tenants.

What does this really mean in day‑to‑day MSP operations?

In practice, auditors and enterprise customers expect to see two things working together:

A clear, written access control policy that sets out:
Scope: internal systems, shared consoles, remote tools, VPNs and every customer tenant your staff can reach.
Principles: least privilege, separation of duties, named accounts, strong authentication and default‑deny.
Roles and access categories: standard user, admin, break‑glass/emergency and third‑party, with maximum access for each.
Approval rules: who may approve which type of access, on what conditions and for how long.
Review cadence: how often access is checked, by whom, and for which systems and tenants.

Evidence that those rules are followed:
Access requests and approvals linked to tickets or workflow items, so you can show the decision trail.
Logs proving that privileged access uses named, MFA‑protected accounts rather than shared logins.
Records of scheduled access reviews for internal systems and representative customer tenants, with customer involvement for higher‑risk environments.

An auditor will often pick a rule in your policy, trace it into your process, then sample real requests, logs and review records. If they can follow that line cleanly for your own platforms and a couple of typical tenants, you are meeting the intent of Annex A.5.15 instead of just repeating the wording.

Why is this control such a pressure point for MSPs?

Your biggest exposure sits in the paths into customer systems, not just in your back‑office tools. Annex A.5.15 is where you demonstrate that:

Access into each tenant is deliberate, justified and regularly reviewed, not a hangover from old projects.
Contractors, offshore teams and third‑party NOC/SOC providers follow the same access rules as permanent staff.
Multi‑tenant tools and consoles rely on named, logged and time‑bound admin access, never generic accounts shared across the team.

When A.5.15 becomes the hub that ties identity, privileged access, supplier management and logging together, you can explain your access model much more convincingly to auditors and enterprise buyers. If you want that hub to live somewhere practical rather than in a static document, ISMS.online gives you a single place to connect policy, tasks and evidence so you can show, not just tell, how access is governed across your MSP and every tenant you support.

How should an MSP design one access control policy that works across many tenants?

You design a single, workable access control policy by writing it from your MSP’s perspective first, then layering customer‑specific requirements on top. The core policy defines how your people and tools behave everywhere; light‑weight tenant profiles record where individual customers require something more restrictive.

What belongs in the core MSP access control policy?

A practical, MSP‑friendly structure usually includes:

Purpose and scope:

State that the policy covers your platforms, shared consoles, remote access mechanisms and all customer tenants you touch.

Principles and standards:

Explain how you apply least privilege, separation of duties, no generic accounts and strong authentication, and which frameworks or regulations you align with (for example ISO 27001 and ISO 27002).

Standard roles and mappings:

Describe roles such as service desk analyst, network engineer, cloud engineer, security analyst, project engineer and account manager, and set the maximum access each role is allowed to different classes of systems.

Access categories:

Define standard, privileged, emergency/break‑glass and third‑party access, with clear rules for how each is requested, granted, used and logged across tenants.

Approval rules and evidence:

Clarify who can approve each type of access, where those approvals are recorded, how long you keep them and how they link back to tickets or changes.

Review frequency and triggers:

Set regular review cycles for user and admin access, and note extra triggers such as organisational changes, new services or major incidents.

Exception handling:

Explain how temporary deviations are requested, risk‑assessed, time‑bound and reviewed so one‑off access cannot quietly become permanent.

You can then attach short tenant profiles that capture extra encryption, segregation, approval or logging requirements for particular sectors or customers (for example public sector, healthcare or finance).

How can you make this structure easy for engineers to use?

A policy that only compliance and auditors can understand will never shape day‑to‑day behaviour. MSPs get far better results when they:

Produce short, role‑specific guides from the main policy (for example “Access rules for service desk staff” or “How to use break‑glass access safely”).
Mirror the policy in tooling by using access request types, change templates and runbooks that match the categories and rules in the document.
Keep the main policy lean and principle‑based, and move detailed “click‑here, then here” instructions into standards, procedures and playbooks.

If an engineer can glance at a guide and immediately see what they are allowed to do in a given tenant, the policy starts to work as a real access governance tool. ISMS.online helps you keep the core policy, role‑level guidance and tenant‑specific requirements connected in one environment, so changes to your access model flow through to everyday work instead of living in an unread document.

How can MSPs join up Annex A.5.15 with identity and privileged access so rights don’t get out of control?

You keep access under control by ensuring that one set of access rules drives your identity lifecycle, role design and privileged access patterns. Annex A.5.15 sets the “who can access what” expectations; identity management and privileged access are where those expectations are enforced consistently in every system and tenant.

What does a joined‑up identity and access model look like for an MSP?

For Annex A.5.15, your identity and privileged access processes are where the policy turns into real decisions. A joined‑up model will usually include:

A joiner‑mover‑leaver process that covers everyone who can reach customer tenants, including contractors and long‑term partners.
Identities created and changed through defined roles, not ad‑hoc entitlement lists, with those roles updated when services or technologies change.
Movers having access removed as well as added across your own platforms and all affected customer tenants, with changes recorded and, where needed, approved by both your MSP and the customer.
Leavers fully revoked from internal systems, shared tools and each customer tenant, with a named person signing off that this has happened.

On the privileged side, a consistent model might include:

Named admin accounts: with multi‑factor authentication for tenant‑level or other high‑risk systems, never shared logins.
Just‑in‑time or time‑bound elevation: for sensitive tasks, linked to a change, incident or maintenance window.
Tight control over who can approve privileged access, with approvals captured in your ITSM or ticketing platform.
Scheduled access reviews for privileged roles, carried out jointly with customers for critical or regulated tenants.

When these elements align, it becomes much easier to show an auditor or customer that Annex A.5.15 runs through your identity, access and privileged access tooling rather than sitting on paper. Platforms like ISMS.online make this traceability simpler by linking your access policy, control records and evidence so you can demonstrate, in a few clicks, how a single person’s lifecycle was handled from first access to final revocation.

What access control weaknesses do auditors and enterprise customers most often find in MSPs?

The most common weaknesses show up where stated rules and real‑world access do not match, especially at the edge between your MSP and customer tenants. Gaps in multi‑tenant tools, shared consoles and remote access platforms are particularly well‑travelled ground for findings.

Which specific patterns keep surfacing?

Recurring issues include:

Policies that refer to “all staff” but in practice overlook contractors, offshore teams or third‑party operations centres.
Incomplete or undocumented offboarding: , especially from customer tenants and shared tools when staff or contractors move role or leave entirely.
Shared or generic admin accounts: in remote monitoring, PSA, backup or security tools that serve many tenants.
Legacy accounts in customer systems that no one clearly owns, with no current justification for the access they still hold.
Irregular access reviews: , or reviews that only cover internal systems and ignore customer‑facing platforms and tenants.
Temporary or emergency access that was never properly time‑bound, re‑approved or revoked, and has slowly become permanent.
Struggling to answer simple questions such as “Who from your organisation can administratively access our production tenant today?”

Even if none of these gaps has yet produced an incident, they make enterprise customers nervous. Many now treat MSP access as part of their wider supply chain risk, so they will probe these points harder in due‑diligence, renewal and incident‑response conversations.

How do these gaps feed back into commercial risk?

Once a customer or auditor sees inconsistent access control, three things tend to happen:

They raise findings and expect remediation plans, which consumes time and can slow sales cycles or renewals.
They limit the scope of systems or data you can reach or impose extra controls, which makes it harder to deliver efficient support.
In more serious cases, they re‑tender or diversify away from your MSP if confidence in your access governance continues to erode.

Strengthening Annex A.5.15 is therefore also a commercial strategy. If you can show that access into every tenant is controlled, justified and reviewed, you are far more likely to be treated as a long‑term guardian of customer environments rather than just another interchangeable supplier.

How can an MSP show auditors and enterprise customers that its access governance is effective?

You show effective access governance by telling a clear, consistent storey of how your access rules turn into day‑to‑day behaviour, and by backing that storey with organised evidence. Different audiences look from slightly different angles, but all of them want proof that your approach is structured, repeatable and not dependent on one or two heroic individuals.

What kind of evidence structure works well for Annex A.5.15?

For Annex A.5.15, an “access governance evidence library” makes it easy to show how policy becomes practice. A simple, layered structure looks like this:

Policy and scope
Your access control policy mapped to Annex A.5.15 and related controls, with in‑scope systems and tenants clearly listed.
Procedures and standards
Documents explaining how you onboard and offboard people, manage privileged and emergency access, and run access reviews.
Workflow records
Access requests, approvals and change records for representative staff and tenants, showing that the procedures are followed in real cases.
Logs and reporting
Logs from identity providers, remote access tools and admin consoles, plus periodic reports on privileged access and access review outcomes.
Reviews and governance
Minutes or records from access review sessions, customer governance meetings and management sign‑offs on key changes or exceptions.

Once you know where each of these sits, you can assemble concise evidence packs for different needs:

A focused pack for ISO 27001 auditors and other assessors.
A customer‑facing pack that supports supplier security reviews and due‑diligence questionnaires.
An internal pack for leadership to show how access governance supports risk management, resilience and service quality.

How should you walk through this in a meeting?

In conversations with auditors or enterprise customers, it helps to ground everything in real examples:

Walk through one or two real user journeys – for example, a new engineer joining, a role change and a leaver – and show how access was requested, approved, granted, logged and reviewed in at least one internal system and one tenant.
Show how exceptions and emergency access are requested, time‑bound and cleaned up, with evidence of approvals and follow‑up.
Explain how you detect and correct drift, for instance through scheduled reviews that compare current access with intended roles and tenant‑specific requirements.

This style of walkthrough demonstrates that Annex A.5.15 is embedded in your MSP’s operating rhythm. With ISMS.online, you can rehearse and deliver that storey more confidently because the policy, tasks and evidence for each of those journeys live in one place rather than across multiple folders, inboxes and tools.

How can ISMS.online help an MSP run Annex A.5.15 as a living access governance practice?

ISMS.online helps you move Annex A.5.15 from a static document into a connected access governance workflow that reflects how your MSP really onboards people, grants access and reviews high‑risk tenants. Instead of scattering rules and evidence across files, drives and inboxes, you manage them in a single ISMS built for ISO 27001:2022.

How does ISMS.online support Annex A.5.15 day to day?

Within ISMS.online you can:

Keep your central MSP access control policy in one place, map it directly to Annex A.5.15 (and related controls such as A.5.16 and A.8.2), and assign owners and review dates so it stays aligned with how you operate.
Create linked controls, actions and tasks for key activities such as provisioning, privileged access changes, emergency access and scheduled access reviews, so responsibilities are clear.
Schedule and track recurring work – quarterly access reviews, annual policy updates and customer‑specific governance checks – with status views that show where attention is needed.
Attach evidence such as access review confirmations, admin rights exports and meeting minutes directly to the relevant controls and tasks, so auditors and customers see the full storey without you pulling screenshots under pressure.
Capture customer‑specific requirements through additional controls, projects or notes, giving you a clear view of which tenants go beyond the baseline and how you handle those differences in practice.

This makes it far easier to answer questions like “who can access this tenant, how was that access approved and when was it last reviewed?” without a scramble across tools.

How does using ISMS.online change how customers and auditors perceive your MSP?

When your access governance is clearly documented, linked and monitored in ISMS.online, you demonstrate that:

Consistent standards: apply across tenants, rather than each environment being handled as a one‑off.
Exceptions and emergency access: are deliberate, recorded and revisited, instead of quietly persisting in the background.
Access governance is treated as part of your core quality of service, not just a certification checkbox.

That matters if you want customers to see your MSP as a long‑term guardian of their environments rather than just an extra pair of hands. If you want a concrete sense of how quickly your current Annex A.5.15 approach could be brought under control, spending time walking through an ISMS.online access governance workspace with a couple of your own tenants in mind is often the fastest way to decide whether this is the right fit for your team and your growth plans.

A.5.15 Access Control Policy – MSP Access Governance