How A.8.3 Access Controls Stop Lateral Attacks in MSP Supply Chains

Why MSPs are now prime targets for cross‑tenant attacks

MSPs are prime targets for cross‑tenant attacks because one compromised technician account or shared tool can reach many customer environments at once. When remote management paths quietly span tenants, a single foothold can become a multi‑customer outage, with ransomware, data theft or backdoors pushed across dozens of tenants, leading to lost revenue and contractual disputes. Government joint advisories on managed service provider security describe this same pattern, where weaknesses in segregation or privileged tooling let one compromise spill across multiple downstream customers (example guidance). As attackers increasingly treat managed service providers as shortcuts into many organisations rather than hunting one victim at a time, A.8.3 access restrictions become your main way to contain that blast radius.

Attackers follow the path of least resistance; flat, shared access models quietly show them the way.

For years, many MSPs assumed that a breach would affect one customer at a time, within one network boundary. That assumption no longer holds. Recent campaigns have shown that once an attacker lands inside an MSP’s core toolset, they can quietly push ransomware, steal data or plant backdoors across many tenants before anyone realises what is happening. Ransomware guidance from law‑enforcement and national security agencies notes that criminals increasingly abuse service providers’ remote tools to distribute malware at scale across multiple organisations rather than attacking them individually (ransomware overviews). The risk is no longer just “our customer’s firewall failed”; it is “our own shared infrastructure became the path into all of them”.

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

You reduce cross‑tenant risk only when you stop modelling attacks per customer and start modelling them across your entire MSP supply chain. That shift forces you to look at how your shared tools, identities and networks really behave in practice, not just how they are described in diagrams.

This information is general and does not constitute legal, regulatory or certification advice. You should take your own professional advice before making decisions.

From single‑tenant thinking to supply‑chain reality

Moving from single‑tenant thinking to a supply‑chain view means treating your MSP stack as one interconnected system rather than a set of isolated customers. When you interrogate shared tools and identities instead of only customer firewalls, the cross‑tenant paths that attackers can abuse become visible, especially through remote monitoring and management (RMM) tools, remote access gateways, cloud consoles and backup platforms. Because these tools operate privileged routes into many clients, broad, persistent access in any of them lets a single compromise fan out across your whole customer base.

Attackers used to be pictured as breaking directly into each customer’s network, one at a time. In reality, many now target MSPs first because MSPs operate those shared, privileged routes. Industry analyses of MSP incidents highlight this shift, describing attackers going after central admin consoles and shared tooling to maximise downstream impact (industry whitepapers).

It helps to make the contrast explicit:

Aspect	Single‑tenant mindset	Supply‑chain reality
Main attack target	Individual customer environment	MSP core tools and shared infrastructure
Risk model	“Customer A’s network stands alone”	“Shared consoles can bypass each customer’s defences”
Result of compromise	One environment affected at a time	Many tenants exposed through the same access pathways

In a single‑tenant mindset, you model risk as if “Customer A” is isolated; you focus on their firewall rules and their employee passwords. In a supply‑chain mindset, you also ask “Which of our shared consoles can override Customer A’s defences, and what else can those same credentials touch?” The second question is where lateral‑movement risk hides.

The tools that quietly connect all your customers

Your highest‑risk tools are usually the ones that can operate across many tenants from a single control plane. When you identify those platforms and map exactly which tenants and data each one touches, you gain a practical target list for A.8.3 access restriction and monitoring.

Most MSP stacks contain a handful of “crown jewel” tools that bridge many environments:

RMM or endpoint management platforms that can push scripts, software and configuration changes.
Remote access gateways that open interactive sessions on customer systems.
Identity or directory integrations that synchronise accounts, groups and access rights.
Backup, recovery and continuity systems with broad visibility of customer data.

If those tools are configured with global administrator roles, shared accounts or flat network access to every customer, an attacker who compromises one identity or appliance does not need to break into each tenant separately. They can simply use your normal pathways, often with your own automation.

Shadow admin paths you may have missed

Shadow administration paths are informal or legacy routes that give real access but are often missing from formal designs and policies. When you seek them out and bring them under A.8.3 control, you close lateral‑movement routes that attackers would otherwise find first.

Even if your main tools look well managed, there are often shadow administration routes that have grown organically:

Shared jump servers that can reach multiple customer environments without strict scoping.
Generic VPN profiles used for quick troubleshooting across many tenants.
Legacy service accounts that were never de‑scoped when environments changed.
Emergency break‑glass accounts created for outages and never fully withdrawn.

These routes may not be documented in access control policies, yet they provide real paths for lateral movement. A.8.3 asks you to identify and deliberately control such paths, not just the ones that appear in network diagrams. If you can explain these pathways clearly to non‑technical colleagues in terms of customer impact, data protection and contract risk, it becomes much easier to gain support for changing them.

Book a demo

What ISO 27001:2022 A.8.3 really asks you to do in an MSP zero‑trust model

ISO 27001:2022 A.8.3 asks you to make sure that people and systems can only reach the information and assets they genuinely need, from appropriate locations and at appropriate times, and to enforce those decisions technically in a way you can demonstrate. For an MSP, “information and associated assets” includes not only internal systems but every customer tenant you manage and every shared tool that can touch them. Aligning A.8.3 with a zero‑trust mindset means you stop assuming any engineer, device or network segment is implicitly safe.

ISO 27001:2022 control A.8.3, “Information access restriction”, is easy to summarise but demanding to implement: decide who should be able to reach which information and assets, from where and when, then enforce that decision technically and be able to show it works. For an MSP, “information and associated assets” is wider than many expect; it explicitly covers customer tenants and the shared platforms that connect them, which must be governed by clear, enforced access rules rather than informal trust.

At a high level, A.8.3 sits on top of your broader access control approach. Other ISO 27001 controls tell you to define access policies, manage identities through their lifecycle and classify information, and plain‑language explainers of ISO/IEC 27001:2022 often present A.8.3 alongside these Annex A access‑control clauses to show how they work together (access‑control summaries). A.8.3 is where those policies and classifications become concrete rules in consoles, networks and applications. It is less about writing policy and more about how your systems behave when someone logs in.

You meet A.8.3 in an MSP only when you treat RMM data, backups, secrets, tenant configurations and customer personal data as information assets, not just file shares. That requires you to be explicit about who can see and change those assets today, and how those rights are restricted, logged and reviewed over time.

Broadening “information” beyond internal file shares

A.8.3 becomes meaningful in MSP environments when you treat configuration data, credentials, monitoring outputs and backup images as information assets alongside documents. Once those assets are in scope, you can design access rules that stop attackers using them for silent cross‑tenant movement or unauthorised access to customer personal data.

Many organisations instinctively think of information assets as documents on a file server or records in a business application. In an MSP context, that definition is far too narrow. You also handle:

Customer configuration data in RMM and management platforms.
Authentication secrets and tokens in identity and access systems.
Backup images and replicas across multiple tenants.
Monitoring data, logs and diagnostic traces from many environments.

Each of these is an information asset that attackers can use for lateral movement if access is not tightly controlled. Each may also contain, or provide a path into, personal data that falls under privacy laws. When you interpret A.8.3, you should ask “For each of these asset types, who can see or change them today, how is that access justified, and how does it map back to our access control and privacy policy?” That simple mapping exercise often reveals unplanned cross‑tenant exposure.

Topic‑specific access policies, not one giant rulebook

A.8.3 is easier to apply when you express it through a small set of focused, topic‑specific access policies rather than one generic rulebook. Clear policies on cross‑tenant access, tenant isolation and privileged engineering give engineers, auditors and privacy officers a shared reference for how rights should work in practice.

ISO 27001 encourages “topic‑specific” policies: focused documents that cover particular areas in more detail than a single, generic access policy ever could. Implementation guidance for Annex A.8.3 frequently recommends breaking access control into these underlying topics, rather than relying on one monolithic access document, because auditors and engineers find focused policies easier to apply in practice (implementation discussions). To make A.8.3 effective for MSP lateral‑movement risk, you usually need at least:

A cross‑tenant access policy that governs any identity, network or tool able to operate in more than one customer environment and clarifies how customer data and privacy obligations are protected.
A privileged engineering access policy that defines when and how technicians may gain elevated rights, including logging and retention expectations.
A tenant isolation policy that defines the boundaries between customers in network, identity and tooling terms, including how regulators would see segregation.

These policies then drive the technical configurations you implement. If they exist only on paper, or are missing entirely, it becomes very hard to argue that A.8.3 is genuinely fulfilled. Using an ISMS platform such as ISMS.online, you can link these policies directly to risks, controls, legal obligations and evidence, which helps non‑technical stakeholders see that they are living documents rather than shelfware.

Risk‑based restriction, reviewed over time

Risk‑based restriction under A.8.3 means focusing your strongest controls on the tools and identities that could expose many tenants or large volumes of customer data at once. Those decisions are not one‑off; you need regular, structured reviews to keep access aligned with current MSP risk and regulatory expectations.

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

A.8.3 also implies that access restrictions are not static. They should reflect current risk and be reviewed regularly. For an MSP, this means:

Using risk assessments to decide which tools and identities represent the highest lateral‑movement and data‑exposure potential.
Tightening restrictions for those areas first, rather than focusing on low‑impact systems.
Reviewing cross‑tenant permissions, exception approvals and segmentation designs at an agreed cadence, not only before audits.

In a zero‑trust model, the question is no longer “Do we trust this engineer or tool?” but “Given our current risk picture and data obligations, what is the minimum access this engineer or tool needs, and for how long?” To see what this looks like in real MSP environments, it helps to trace a few typical attack paths through your stack and ask where existing controls genuinely stop them.

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

From abstract control to concrete MSP risk: lateral movement between tenants

You turn A.8.3 from an abstract requirement into concrete MSP risk management when you trace how an attacker could move between tenants using your actual tools and identities, and recognise that a single compromised account in an RMM, backup or identity platform can expose many customers at once. Once you see those paths, access restriction becomes a focused exercise in shrinking and hardening specific routes rather than trying to lock everything down equally.

Lateral movement describes the way attackers move from one foothold to other systems and identities after initial compromise. In an MSP, the most worrying form of lateral movement is cross‑tenant: using access to one customer, or to the MSP core, to reach other customers’ environments. A.8.3 becomes tangible when you trace real attack paths through your stack and ask which of them your current controls genuinely block.

The 2025 ISMS.online State of Information Security survey found that most organisations had already been affected by at least one third-party or vendor-related security incident in the previous year.

Consider a scenario where a technician account is phished. If that identity has broad, standing rights across many tenants, an attacker can pivot through your normal tools without sophisticated exploits. Even when multi‑factor authentication is in place, session theft, token reuse or misconfigured “remember this device” settings may still provide a path. Overviews of multi‑factor authentication explain that while MFA raises the bar for attackers, weaknesses such as session hijacking, token theft or poor configuration can still undermine its protection if underlying access scopes remain too broad (MFA backgrounders). The key question is not just “can the account log in?” but “once logged in, how far can it travel, which customer data is at risk and which regulators would be concerned?”

You reduce lateral movement only when you see your MSP environment as an attacker path graph, not as a list of tools. That means mapping how identities, roles, networks and platforms connect in practice, and then deliberately shrinking the most dangerous paths.

Seeing your environment the way an attacker does

Seeing your environment like an attacker means modelling routes from one compromised point to others, not just counting how many tools you run. When you draw the actual paths between identities, networks and tenants, high‑leverage nodes jump out and show you exactly where A.8.3‑driven restrictions will matter most.

Technical leaders and security owners can gain clarity by modelling typical attack paths in their environment. Common routes in MSP settings include:

Compromising an endpoint agent or RMM connection in one tenant, then using built‑in tools to push commands into others.
Abusing service accounts or API keys that can administer multiple customer tenants in a cloud platform.
Using an over‑privileged backup or monitoring account as a stepping stone into production workloads.
Pivoting from an on‑premises directory integration into cloud resources with broader scope.

Drawing these as simple graphs-identities, groups, networks, tools and their permissions-often reveals that some accounts or systems sit at the centre of many paths. Those are the places where A.8.3‑driven restrictions have the most impact. When you can show that diagram to a business stakeholder and explain “this node touches twenty customers and their data”, it becomes easier to gain support for changing it.

Rethinking “MFA solves it” and introducing blast radius

Multi‑factor authentication is essential, but it does not fully solve lateral‑movement risk on its own. If a session is hijacked after MFA, or if a tool itself is compromised, the attacker inherits whatever scope that identity or service has, including any cross‑tenant reach.

The idea of “tenant blast radius” helps here: for any privileged identity or tool, you can ask “How many customers and which classes of information could be affected if this were misused right now?” When the answer is “almost all of them”, you have a clear A.8.3 problem. Restricting information access in line with policy means deliberately designing for small, controlled blast radii wherever possible. That design work then flows into your framework for minimising lateral movement.

The A.8.3 Lateral Movement Minimisation Framework for MSPs

An A.8.3 lateral‑movement minimisation framework gives you a structured way to shrink cross‑tenant attack paths instead of tackling them piecemeal. By ranking risks, defining topic‑specific policies, standardising technical patterns and assigning clear owners, you turn access restriction into an ongoing programme that supports audits, customer assurance and regulatory expectations, rather than a one‑off hardening sprint.

To move from theory to practice, it helps to treat A.8.3 as the anchor for a simple framework rather than as a single check box. The aim is to minimise lateral‑movement opportunities, especially between tenants, by tying together risk, policies, technical patterns and ownership. When that framework is implemented inside a live information security management system, you can track progress and evidence it without reinventing everything at audit time.

One useful way to think about the framework is in four layers: understand and rank the risks, define topic‑specific access policies, choose technical patterns that enforce those policies and assign clear owners for each. Those layers become the organising map for the decisions you make about access every day.

Layer 1: Risk and scope

Layer 1 focuses on identifying the tools, identities and zones that matter most for cross‑tenant movement so you can focus A.8.3 effort where it really reduces risk, turning the control from a vague principle into a short list of high‑impact risk areas. Once you list and rank those hotspots, you can explain clearly which routes are most dangerous today and why you are starting there.

You make A.8.3 actionable when you turn it into a short list of high‑impact risk areas rather than a vague principle. Start by defining the scope of A.8.3 from an MSP perspective:

List the tools, identities and network zones that can touch more than one customer.
Assess which of these represent the highest impact if misused, including data‑protection implications.
Document specific lateral‑movement scenarios you want to prevent or contain.

This gives you a concrete set of “A.8.3 hotspots” rather than a general sense that “everything needs access control”, which helps prioritise effort and explain decisions to management and to customer security or privacy teams.

Layer 2: Topic‑specific policies

Layer 2 turns those hotspots into clear rules for how people and tools should behave. Concise policies for cross‑tenant access, tenant isolation and privileged engineering give engineers, internal auditors and DPOs the same reference point when they discuss rights and exceptions.

Next, establish or refine the key policies that will drive your designs. Typical topics include:

Cross‑tenant access: who may ever have rights in more than one tenant, under what conditions and with which approvals from security and, where relevant, privacy or legal leads.
Tenant isolation: which kinds of traffic, data and identities may cross boundaries, and which may never do so.
Privileged engineering: how technicians gain, use and lose elevated access, including time limits and logging expectations.

In an ISMS platform such as ISMS.online, these policies can be linked directly to risks, controls, legal obligations and evidence, so they are not forgotten once written. That linkage also makes it easier to show auditors and customers that your technical designs have a clear policy basis.

Layer 3: Technical patterns

Layer 3 defines repeatable technical patterns that implement your policies so engineers do not have to invent their own approaches each time. When these patterns are documented, tested and reused, A.8.3 restrictions become consistent across customer environments instead of depending on individual preferences.

At this level you define the building blocks, not every implementation detail, for example:

Tenant‑scoped roles in cloud and RMM platforms, instead of global administrator access.
Segmented management networks and controlled jump hosts, instead of flat connectivity.
Just‑in‑time elevation mechanisms for privileged tasks, instead of standing high‑privilege accounts.
Per‑tenant encryption key scopes and log views, instead of shared keys and undifferentiated logs.

These patterns give your engineers a consistent toolbox to draw from when designing or improving services. When each pattern is documented, owned and tied back to specific A.8.3 obligations and topic‑specific policies, changes in one area are less likely to undermine controls elsewhere.

Layer 4: Ownership and improvement

Layer 4 assigns named owners and feedback loops so your framework stays alive and aligned with change. Without clear responsibility, A.8.3 quickly becomes a one‑off clean‑up rather than a sustained defence against lateral movement.

You sustain A.8.3 over time only when it has named owners and feedback loops. Assign clear owners for each element: who owns the cross‑tenant access policy, who designs segmentation, who monitors for violations, who approves exceptions, who ensures evidence is collected and who checks privacy implications. Build feedback loops so that incidents, near misses, threat intelligence and test results feed back into updated policies and patterns.

When you manage this framework in a structured ISMS such as ISMS.online, you can see at a glance which parts of A.8.3 are strong, which are in progress and where lateral‑movement exposure remains. This makes it easier to brief leadership and to prioritise investment, because you can point at specific gaps rather than speaking in generalities.

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

Book your demo

Designing technical guardrails: RBAC, segmentation, JIT and tenant isolation

Technical guardrails for A.8.3 are the concrete role, network and workflow designs that make over‑broad access impossible in normal use. For MSPs, that usually means tenant‑aware RBAC, segmented management networks, just‑in‑time elevation and deliberate tenant isolation in shared platforms, all aligned to clear policies, backed by logging and designed around real engineering workflows.

Technical guardrails are where A.8.3 becomes visible to engineers day to day. For MSPs, the most powerful levers are role‑based access control (RBAC), network segmentation, just‑in‑time (JIT) privileged access and robust tenant isolation in shared platforms. Together, they change the default from “everyone can see everything all the time” to “people and tools see just what they need, when they need it, in one tenant at a time”.

When you design these controls, it helps to start from administrative workflows rather than from technology features. Ask, for each type of work, which permissions are truly required, for how long and from where, then shape your guardrails accordingly. That approach keeps later discussions with customers, auditors and your own teams grounded in real tasks rather than in abstract settings.

You prevent cross‑tenant abuse with RBAC only when roles are tenant‑aware rather than global. That means designing roles with clear functional and scope boundaries, then resisting the urge to grant “temporary” global access that never quite gets removed.

Role‑based access control that respects tenants

RBAC supports A.8.3 when roles are both function‑specific and tenant‑aware instead of broad “global admin” buckets. By defining roles around what work is done, on which customers and at what authority level, you automatically limit the blast radius if an account is compromised and make it easier to demonstrate control to customers and auditors.

RBAC ties permissions to roles instead of individuals. In an MSP context, effective RBAC often means:

Having separate roles for first‑line support, senior engineers, cloud specialists and backup operators.
Scoping those roles to specific tenants, regions or service lines rather than “all customers”.
Avoiding generic “global admin” roles in shared tools; using narrowly scoped roles instead.

A useful pattern is to combine three dimensions: function (what kind of work), level (how much authority) and scope (which customers). For example, “Tier‑2 engineer – customer group X” is very different from “Platform owner – internal tools only”. When you mirror that structure across your tools and document it in your ISMS, it becomes much easier to maintain consistency and to answer customer questions about who can access their environment.

Network segmentation and management plane isolation

Network segmentation protects you when credentials fail by making it hard for a compromised system to reach everything. When management networks and tenant environments are strictly separated, attackers have fewer paths to exploit even if they capture a privileged identity.

Even perfect RBAC cannot compensate for flat networks. Attackers often exploit simple connectivity: if an admin workstation can reach every customer network over management protocols, compromising that workstation creates a highway for lateral movement.

Segmenting your networks typically involves:

Isolating management networks from customer production networks.
Placing jump hosts or bastion services in tightly controlled zones.
Using firewalls or zero‑trust network access controls to ensure that only authorised paths exist between administrative tools and tenant resources.

A simple but effective practice is to regularly review “From this subnet, which tenants and ports are reachable?” and compare the answer with your access control policies. If connectivity and policy do not align, A.8.3 gives you a concrete reason to change one or the other.

Just‑in‑time access and scoped sessions

JIT privileged access reduces risk by ensuring that high‑level rights are granted only when needed and for the shortest practical time. When you combine JIT with logging, you gain both better protection and better evidence for A.8.3.

Standing high‑privilege accounts are particularly attractive to attackers. JIT privileged access reduces this attraction by making elevation temporary and task‑bound. This can look like:

Engineers working with low‑privilege accounts most of the time.
Requesting elevation for a specific task or ticket, with explicit approval.
Automatic expiry and revocation after a short window.
Detailed logging of elevated sessions.

In combination with RBAC and segmentation, JIT ensures that even if credentials are stolen, the window and scope of abuse are greatly reduced. It also gives you better stories to tell auditors, customers and privacy officers: you can show that privileged access is exceptional and closely controlled, not routine and permanent.

Tenant isolation in shared platforms

Tenant isolation in shared platforms ensures that a compromise in one customer or sub‑tenant does not automatically expose others. When you deliberately use platform features to separate customers, you reduce the chance that a single misconfiguration or attack can breach multiple environments at once.

Cloud services, email security gateways, identity systems and similar platforms often support multiple tenants within one administrative interface. Cloud security foundation guides describe these multi‑tenant administration models and emphasise the need for strong logical separation using constructs such as projects, accounts or resource scopes to avoid unintended cross‑tenant access (cloud security foundations). Tenant isolation in these tools should reflect your cross‑tenant access policy and A.8.3 obligations. That normally means:

Separate tenants, subscriptions or equivalent logical containers per customer, where feasible.
Per‑tenant management accounts or roles rather than one “super admin” for everything.
Avoidance of “all customers” groups or policies that override per‑tenant boundaries.

It can be helpful to maintain a register of which tools are truly multi‑tenant and what isolation mechanisms they offer, then standardise how you use them. When this register is managed in your ISMS, it also becomes a ready‑made artefact for audits, customer due diligence and privacy impact assessments.

The following table summarises how these guardrails differ between legacy and A.8.3‑aligned approaches:

Area	Legacy pattern	A.8.3‑aligned pattern
Admin identities	Shared global admin accounts	Named, tenant‑scoped roles with JIT elevation
Networks	Flat management networks to all customers	Segmented management plane, per‑tenant pathways
Access duration	Standing high‑privilege rights	Time‑bound elevation linked to specific tasks
Tenant boundaries	“All customers” groups and shared consoles	Per‑tenant roles, projects or subscriptions
Visibility	Limited logging of admin actions	Detailed, correlated logs for privileged sessions

Procedural controls that make A.8.3 real in daily MSP operations

Procedural controls make A.8.3 real by governing how people request, approve, use and revoke access in the flow of daily work. When your joiner‑mover‑leaver flows, exception handling and training reflect cross‑tenant risk, you greatly reduce the chance that dangerous access paths re‑emerge as your MSP evolves, even as tools and teams change.

Even the best technical designs will fail if everyday processes pull in a different direction. Procedural controls ensure that access restrictions are requested, granted, reviewed and removed in consistent ways, especially under time pressure. For A.8.3, this means embedding cross‑tenant access thinking into onboarding, offboarding, change management and exception handling, not treating it as an occasional security project.

In practice, the question to ask is “How easy is it for someone to bypass these restrictions when they are busy, and what trail would show that happened?” If the honest answer is “very easy, and there is almost no trail”, then your procedural controls need just as much attention as your technology.

Access requests, joiners, movers and leavers

Joiner, mover and leaver processes are where cross‑tenant permissions most often persist unnoticed. Treating these flows as A.8.3 mechanisms means you apply the same discipline to MSP entitlements as you do to internal applications, including data‑protection obligations and customer commitments.

Useful practices include:

Standardised request workflows for any permission that spans more than one tenant, with risk‑based approval.
Role templates that pre‑define which tenants and tools are in scope for particular job functions.
Joiner processes that create accounts with minimal default access and then add specific tenant scopes as needed.
Mover and leaver processes that promptly remove cross‑tenant access when roles change or people leave.

You can make this concrete by shaping the process into a few simple steps.

Step 1 – Identify MSP‑specific entitlements

Catalogue the roles, groups and tools that grant cross‑tenant or high‑risk access so HR and managers know which requests need extra scrutiny.

Step 2 – Build scoped role templates

Create templates that bundle only the rights each role needs, mapped to specific customers or regions, and reference them in your request forms.

Step 3 – Automate provisioning and revocation

Integrate HR and identity systems so that role changes automatically trigger provisioning and de‑provisioning of cross‑tenant entitlements, reducing manual gaps.

Step 4 – Record approvals and reviews

Ensure every high‑risk entitlement has a recorded business reason, approver and review date, so you can demonstrate control to auditors, customers and privacy regulators.

Linking these processes to your HR system and identity platform reduces the risk of forgotten accounts and lingering permissions. When you manage the associated records inside a platform such as ISMS.online, you also gain an audit‑ready view of who approved what, when and for how long.

Structured exceptions and change management

Structured exception handling recognises that you sometimes need broader access, but insists that those rights are tightly scoped, time‑bound and visible. When your change management process always asks “What does this do to cross‑tenant access?”, A.8.3 stays aligned with your evolving MSP stack.

Operational reality sometimes demands exceptions-for example, a senior engineer may need temporary access to several tenants to manage an urgent incident. A.8.3 is not trying to prevent this; it is asking that such access be controlled and observable, not improvised.

That implies:

Documented criteria for when cross‑tenant exceptions are allowed.
Short, clear forms that capture reason, scope, duration and approvals, including privacy or legal sign‑off where relevant.
Automatic reminders or expiry for temporary entitlements.
Integration with your change management process so that new tools, integrations and workflows cannot be introduced without considering their impact on cross‑tenant access.

You can make exception handling easier to follow by breaking it into clear steps.

Step 1 – Define acceptable exception cases

Agree on a short list of situations where cross‑tenant elevation is allowed, such as major incidents or specific project work.

Step 2 – Capture scope, duration and approvals

Use a simple template to record which tenants and tools are in scope, for how long and who has signed off, including DPO input where data exposure is likely.

Step 3 – Implement and monitor temporary access

Apply the exception in your identity and access systems, log all privileged use and set automatic expiry or review reminders.

Step 4 – Close and review the exception

When the window ends, remove the access and capture lessons learned so policies and patterns can be refined.

When exceptions are handled transparently, they become managed risks rather than hidden weaknesses. You can then use those exception records to refine policies and technical patterns, rather than discovering them for the first time after an incident.

Training and communication

Training and communication ensure that engineers, account managers and leadership understand why access restrictions exist and how to work within them. When people see how A.8.3 controls protect customers, contracts and regulatory posture, they are more likely to support, rather than bypass, them.

Finally, people need to understand why restrictions exist. Engineers and account managers may otherwise see them as friction rather than protection. Effective communication uses real examples: how a single compromised account in another provider led to many customers being hit, and how your model is different.

Short, focused training that connects A.8.3‑driven rules to day‑to‑day tasks-raising a ticket for extra access, using JIT tools, avoiding informal credential sharing-does more for lateral‑movement defence than long, generic presentations. If that training is tracked through policy acknowledgements and simple completion metrics, it also becomes part of your evidence storey and supports both security and data‑protection narratives.

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

Book your demo

Proving it: evidence, metrics and audit‑ready artefacts for A.8.3

You prove A.8.3 in an MSP context by being able to show, at short notice, who can access which customer assets and how those rights are restricted, logged and reviewed. Auditors, customers and regulators increasingly expect concrete artefacts rather than verbal assurances, so a curated evidence pack and a small set of metrics are essential to show that your access restrictions are real and effective. Practitioner commentary on Annex A.8.3 stresses the importance of structured records, configuration samples and ongoing evidence of control operation during audits, reinforcing the need for more than informal explanations (control implementation discussions).

Control A.8.3 does not only expect you to restrict access; it also expects you to demonstrate that restrictions exist and operate. In an MSP, both auditors and customers increasingly ask “Who can access our systems and data, how is that access restricted and what evidence can you show?” Privacy regulators ask similar questions about access to personal data. Guidance on third‑party risk and cloud control frameworks emphasises providing verifiable information about isolation and who can access customer data in shared services, which aligns with the kinds of questions privacy regulators and customers now routinely ask (cloud control matrices). Building a structured evidence pack and a small set of metrics makes those conversations faster and more confident.

In the 2025 ISMS.online State of Information Security survey, almost all organisations listed achieving or maintaining security certifications like ISO 27001 or SOC 2 as a top priority.

The goal is simple: at any time, you should be able to show how access is restricted in line with policy, where cross‑tenant permissions exist and what you are doing to monitor and review them. This capability is not only an audit requirement; it is also a commercial signal that you take supply‑chain and data‑protection risk seriously.

You make your A.8.3 storey convincing when you can reach for a small, curated set of artefacts instead of scrambling through scattered documents and screenshots. That is where an ISMS platform such as ISMS.online makes a practical difference, because it ties risks, controls, policies and evidence together in one place.

Building your A.8.3 evidence pack

An effective A.8.3 evidence pack combines concise policies, current diagrams, configuration excerpts and sample logs into one coherent storey. When those artefacts live in your ISMS with clear ownership, you can answer most audit or customer questions without a last‑minute scramble.

A practical evidence set often includes:

Copies of relevant policies: cross‑tenant access, tenant isolation, privileged engineering, and how these support privacy obligations.
Architecture and data‑flow diagrams showing management planes, network segments and tenant boundaries.
Excerpts from tool configurations: role definitions, group memberships, conditional access rules, JIT settings.
Samples of logs showing privileged sessions, tenant‑scoped admin actions and blocked cross‑tenant attempts.
Records of access reviews, including decisions to tighten or revoke rights.
Results from tests that attempt to cross tenant boundaries and show they are blocked.

ISMS.online helps you attach these artefacts directly to the A.8.3 control and related risks, so you are not hunting through shared drives when an audit looms. It also means you can selectively share evidence with customers or regulators who want assurance without showing them more than they need to see.

Choosing meaningful metrics

Metrics turn evidence into ongoing insight and help you spot drift before it becomes an incident. The right measures for A.8.3 focus on cross‑tenant exposure, speed of control changes and how often exceptions are needed.

For lateral‑movement and A.8.3, useful measures include:

Number of user or service accounts with access to more than one customer environment.
Proportion of privileged sessions that use JIT elevation rather than standing rights.
Time between a role change or departure and removal of cross‑tenant access.
Count and trend of cross‑tenant access exceptions raised and approved.
Frequency and outcome of segmentation and access tests.
Proportion of customers who have seen a tailored view of their own A.8.3 evidence pack.

These numbers are not only for auditors. They give leadership and privacy officers a way to see whether investment in access restriction is paying off and where further work is needed. They also help commercial and account teams demonstrate supply‑chain security maturity during customer reviews and renewals.

Making the storey easy to tell

Evidence and metrics have most value when they support a simple, concrete storey of how you manage access. If you can walk through one complete example from request to removal, you show that A.8.3 is living, not theoretical.

A good test is whether you can show:

A named engineer requesting temporary cross‑tenant access for a clear reason.
The request being assessed, approved and implemented through defined workflows.
The engineer using the access within defined limits, with actions recorded in logs.
The entitlement being removed on time, with the change appearing in your monitoring and reviews.

If you can tell that storey with screenshots, configuration extracts and logs drawn directly from your ISMS and tools, A.8.3 stops feeling abstract and becomes a visible, living control. The more often you can rehearse and refine that storey, the more confident your teams will be when real audits, customer questions or regulatory inspections arrive.

Book a Demo With ISMS.online Today

ISMS.online gives you a practical way to see how A.8.3 and lateral‑movement controls can be designed, linked and evidenced in one ISMS, rather than scattered across ad‑hoc documents and tools. When you view your MSP access‑control model inside a live platform, it is easier to judge whether you can realistically shrink blast radius, simplify audits and strengthen your ISO 27001 storey, while keeping privacy and supply‑chain obligations in view.

ISMS.online helps you bring A.8.3 and lateral‑movement control together in practice by acting as the hub where policies, risks, controls, technical designs and evidence all live in one place. When you can see cross‑tenant access policies, segmentation patterns and privileged access workflows linked to concrete artefacts inside a single ISMS, it becomes far easier to manage them day to day and explain them to auditors, customers and privacy regulators.

What you will see in an A.8.3‑focused ISMS.online demo

An A.8.3‑focused ISMS.online demo is most useful when it shows how your real MSP access‑control challenges are represented and managed. Rather than a generic feature tour, you see risks, policies, controls and evidence linked around a small number of high‑risk cross‑tenant scenarios that match your environment.

The 2025 ISMS.online State of Information Security survey indicates that customers increasingly expect suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR or SOC 2 rather than relying on generic ‘good practice’ claims.

In a short, focused session, you can explore a worked example of an MSP access‑control architecture, see how A.8.3 maps onto your existing tools and understand how to attach real‑world evidence such as diagrams, screenshots and logs. You can also discuss a phased implementation plan that starts with one high‑risk area-such as your primary RMM or backup platform-and then scales across your wider service portfolio without overwhelming your teams.

How to prepare for a useful session

You get more value from a demo when you arrive with a clear view of your current access‑control pain points and priorities. A small amount of preparation makes it easier to see whether ISMS.online fits your MSP and your ISO 27001 ambitions.

You can shape that preparation into a few simple steps.

Step 1 – List your highest‑risk shared tools

Identify which RMM, backup, identity or monitoring platforms create the most cross‑tenant exposure today, and note any recent incidents or near misses.

Step 2 – Note upcoming audits and reviews

Capture the ISO 27001 audits, customer assessments or regulatory engagements on your calendar so you can discuss how the platform might reduce preparation effort.

Step 3 – Gather one or two tricky evidence examples

Bring a couple of recent cases where evidence was hard to assemble for A.8.3‑related questions, such as who can reach which tenants and why.

From there, it becomes much easier to answer the questions customers and auditors are already asking: who can access what, how is that access restricted and how do you know it stays that way. If you want to shrink blast radius, prevent cross‑tenant lateral movement and strengthen your ISO 27001 and privacy storey at the same time, seeing how ISMS.online supports A.8.3 in a live environment is a logical next step, and arranging a demo is an efficient way to do that on your schedule.

Book a demo

Frequently Asked Questions

How should an MSP interpret ISO 27001:2022 A.8.3 in a multi‑tenant world?

For a managed service provider, A.8.3 means you must know and control exactly who can reach which customer assets, by which route, under which conditions – and prove it on demand. It covers your internal platforms, every customer tenant, and the shared tools and networks that bridge them. A brief “least privilege” statement in a policy will not satisfy a serious auditor; your identity stack, management paths and consoles must actually enforce those boundaries, with evidence that you review and refine them.

Which MSP assets fall under A.8.3 in practice?

In a managed service model, “information and associated assets” includes far more than documents or tickets. You should treat all of the following as in‑scope:

Central identity stores, privileged groups and service accounts
RMM agents, security tool consoles and orchestration pipelines
Backup platforms, vaults, recovery jobs and runbooks
Monitoring systems, log streams and automation workflows
Jump hosts, bastion services and management subnets

Once you recognise these as information assets, A.8.3 forces you to answer three concrete questions for each customer and high‑value component:

Who can currently operate on it? Use specific roles and accounts, not “the engineering team”.
Through which entry points? Identity providers, VPNs, management networks, cloud consoles, APIs.
What limits their spread? Tenant scoping, segmentation, just‑in‑time elevation, monitoring and alerts.

An ISMS platform such as ISMS.online helps you capture those answers once, link them directly to A.8.3, and keep them current as your services evolve.

How can you tell whether your current A.8.3 storey would satisfy scrutiny?

A simple test is to pick a sensitive tenant and ask yourself:

“Who, by name or role, can sign in with effective control today?”
“How far could each of those identities move laterally if compromised?”
“What written decisions explain why that reach is acceptable, and where are they recorded?”

If you cannot produce a clear, consistent answer in minutes – with diagrams, role definitions and change records to back it up – your A.8.3 implementation is not ready for demanding customers or auditors. That gap is where an integrated ISMS comes into its own, because it gives you a single place to join design intent, configuration snapshots and ongoing reviews.

How does A.8.3 actually cut cross‑tenant risk for an MSP?

A.8.3 reduces the chance that a single mistake or compromise turns into a multi‑customer incident by pushing you to treat each tenant as a security domain with deliberately engineered boundaries. Instead of assuming “internal networks” are trustworthy, or that “senior engineers” will always behave perfectly, you design for small blast radii: narrow roles, segmented management planes and minimal standing privilege.

When those patterns are in place, a compromised account or agent should be able to reach only a defined subset of environments, and any attempt to cross into others should trip visible, logged controls.

How can you map lateral‑movement paths so they drive real changes?

Lengthy control spreadsheets rarely change how engineers design and operate systems. A lightweight path‑mapping exercise works better:

Sketch your central identity platforms, key groups and high‑risk roles
Add shared tools (RMM, backups, monitoring, security platforms) and customer tenants
Overlay the management networks, VPNs and jump hosts that connect them
Ask, “If this account or subnet falls, which tenants can it touch today?”

That visual usually reveals shortcuts nobody remembers approving: global admin roles, “catch‑all” VPN profiles, or management networks with near‑universal reach. You can then use A.8.3 as the mandate to remove or narrow those shortcuts and record the reasoning in your ISMS so those decisions survive staff turnover.

How do you keep that view of attack paths meaningful as you grow?

Your attack surface shifts every time you:

Add a new shared platform or integration
Change your management network topology
Onboard a large tenant with special connectivity
Create or deprecate a privileged role

The simplest way to keep pace is to treat your attack‑path map as controlled documentation:

Tie updates to your change management workflow (“does this create new reach?”).
Record revised diagrams, risk notes and approvals against A.8.3 in your ISMS.
Schedule a focused review when you cross clear thresholds (for example, every 25 new tenants or after each major tool rollout).

With that discipline, you can show auditors and customers that your view of cross‑tenant risk is not a one‑off workshop artefact but a living part of your Information Security Management System.

Which technical controls give an MSP the most credible A.8.3 position?

From an auditor’s perspective, the strongest A.8.3 implementations rely on tenant‑aware, identity‑centric controls you can demonstrate live, not just mention in a policy. In most multi‑tenant environments that means:

Tenant‑scoped RBAC: Roles and groups aligned to individual tenants or explicit clusters, rather than broad “global admin” rights.
Hardened identities and MFA: Strong authentication, particularly for privileged and cross‑tenant roles, with minimal shared accounts.
Segmented management paths: Management networks, VPN profiles and jump services that are constrained to specific tenants or regions.
Just‑in‑time elevation: Privileged rights granted for specific tasks and short durations, backed by approvals and logs.
Per‑tenant constructs in shared tools: Using projects, subscriptions, folders or management groups to reflect tenant boundaries inside your platforms.

Those controls do two things: they limit how far a single failure can spread, and they produce screenshots, configuration exports and log entries you can walk through with external assessors.

How can you balance strong isolation with the need for efficient central operations?

The goal is controlled centralisation rather than either a flat “one pane of glass to everything” or dozens of unmanageable islands. In practice, that might look like:

A central console that lists all tenants, with each admin session constrained to defined subsets through role scopes
Management networks limited by design to agreed paths, enforced by firewall policy and routing
A small number of hardened, monitored jump services per region, each tied to a specific set of customer environments

If you document those patterns once in an ISMS pattern library – including diagrams, example configurations and A.8.3 mappings – you can reuse them whenever you expand into a new geography or service line. That preserves both manageability and separation.

Where is the best starting point if your current design is still flat?

If you cannot redesign everything at once, focus first on components with the broadest impact:

Central consoles and identity stores that can administer many tenants
Privileged roles and groups that cut across large portions of your estate
Management networks and VPN profiles with wide‑open reach

Restrict global roles to scoped roles, strengthen MFA and conditional access for privileged identities, and remove unnecessary routes from high‑impact management paths. Once those foundations are in place, extend the same principles to secondary platforms like backup and monitoring so your overall A.8.3 storey becomes progressively stronger.

Why are RBAC, segmentation and just‑in‑time access so central to A.8.3?

Those three elements give you control over who can operate where, from where, and for how long – which is exactly what A.8.3 expects you to understand and manage. Tuned together, they create a layered defence:

Role‑based access control defines which tenants or asset groups each identity can manage
Network and platform segmentation restricts the routes those identities can use
Just‑in‑time access ensures powerful permissions exist only for tightly bounded tasks and time windows

In that model, a compromised technician account might still cause harm, but:

It sees only a subset of tenants or systems
Its usual paths are limited to what those tenants genuinely need
Elevated rights are visible, time‑boxed events instead of a standing condition

That is a compelling storey to take into an audit or a customer review, and it directly reduces the likelihood and impact of cross‑tenant incidents.

How can you introduce these controls without crippling support responsiveness?

The safest path is to design from real operational scenarios instead of abstract control frameworks. For a handful of common workflows – such as onboarding a new tenant, handling a major outage, or performing scheduled maintenance – capture:

Which tenants and environments are realistically involved
Which tools, protocols and consoles are actually needed
What level of privilege each step requires, and for how long

Use that to define:

A small set of standard roles tied to those patterns
Just‑in‑time elevation flows for the limited cases where emergency rights are essential
Network and connectivity paths aligned to those use‑cases, with everything else closed by default

Pilot those controls on one platform or region, track ticket metrics and ask engineers for direct feedback. If you can show that incident resolution times remain acceptable while risk clearly drops, it becomes much easier to extend the approach without resistance.

How do you bring engineers and operations staff along with a stricter model?

Engineers are more likely to back change when they can see how new controls protect them as individuals and simplify difficult conversations. Make three points explicit:

Narrow roles and short elevation windows reduce the chances that an attacker can use their account in a headline‑making breach
Clear patterns and approvals reduce “who said yes?” confusion during and after incidents
Demonstrable access discipline makes security due diligence calls with customers shorter and less confrontational

Support those messages with concrete examples from your own environment or published incident summaries, and with brief, focused training. If engineers can see, inside your ISMS, how their access requests, approvals and reviews are recorded against A.8.3 and related risks, they are more likely to view the system as a safety net rather than a bureaucratic hurdle.

Which everyday processes have the biggest impact on A.8.3 for an MSP?

Controls on paper matter far less than the routines that keep access aligned with reality. For most managed service providers, the processes that most strongly influence A.8.3 outcomes are:

Joiner–mover–leaver handling: Ensuring new staff gain only what they truly need, movers shed access that no longer fits, and leavers are fully removed from shared consoles and tenants
Structured access requests: Standardised forms, clear owners, approvals and expiry for new or elevated access, particularly when it spans tenants
Exception handling: A defined way to grant unusual reach, with justification, time limits and follow‑up checks
Change management: Treating “who gains new reach from this change?” as a mandatory question in design and deployment
Short, scenario‑based training: Explaining “why this matters” using incidents and near‑misses from MSP environments, not generic case law

If those processes run reliably, your technical controls and documented design choices are far more likely to remain accurate. Assessors will often spend as much time on how you run these routines as on the underlying technology.

Which process changes usually reduce lateral‑movement exposure fastest?

Two areas tend to deliver outsized benefit without major tool changes:

Tightening exception management: Replace informal “borrowed” admin accounts or generic VPN credentials with a simple, tracked exception process. Each special access request has a named owner, defined scope and automatic expiry. Informal shortcuts become visible and much less attractive.
Accelerating de‑provisioning: Ensure broad access is removed for leavers and role changers within hours, not weeks. Old accounts and forgotten group memberships are a favourite path for attackers, precisely because nobody feels responsible for them.

Document both processes clearly in your ISMS, link them to A.8.3 and related risks, and keep evidence (tickets, approvals, logs) close to those entries. That way you can show that high‑risk shortcuts are being actively constrained rather than tolerated.

How can you design procedures so people follow them under pressure?

Good procedures feel like an aid, not an obstacle. Signs that your A.8.3‑relevant processes are usable include:

They live inside tools your teams already use daily – your ticketing platform, identity portal and HR system
Most of the data is pre‑filled or derived; humans make decisions instead of retyping information
Forms are short and explicit about defaults, scope and expiry
People can see clear benefits: less time spent reconstructing historical access decisions before audits or customer reviews

An ISMS can act as the spine that links these procedures, assigned responsibilities and evidence. If you position it as the place that avoids panicked evidence hunts every time a questionnaire or audit arrives, adherence improves without heavy pressure.

How can an MSP present convincing A.8.3 evidence to auditors and demanding customers?

Convincing evidence for A.8.3 weaves risk understanding, design decisions, implementation details and operational proof into one storey. For a managed service provider, a compact but credible evidence pack usually combines:

Risk assessments: focused on cross‑tenant access, tenant isolation and privileged engineering activities
Up‑to‑date diagrams: of management planes, identity flows, connectivity and tenant boundaries
Configuration excerpts: showing how RBAC, conditional access and segmentation are implemented in key platforms
Representative logs: for privileged sessions, blocked attempts and relevant alerts
Access review records and test results: for segmentation and separation, including any remediation steps

You do not need to supply every log line you have ever generated. What matters is that each item in the pack clearly links back to the risks you identified and the A.8.3 control objectives you claim to meet.

How does an ISMS change the effort involved in building and maintaining that evidence?

Without an ISMS, A.8.3 evidence tends to be scattered across personal folders, email threads, wikis and individual knowledge. Each new audit or security questionnaire triggers a manual hunt, and the storey changes slightly every time.

With a structured ISMS such as ISMS.online you can:

Map A.8.3 directly to the risks it mitigates in your MSP model
Attach policies, diagrams, test results and configuration captures to that control once, then update them on a schedule
Record access reviews, exception decisions and corrective actions against the same entries
Produce consistent, role‑appropriate views for customers, auditors and internal leadership without re‑inventing the explanation

For you and your team, that means less stress when external scrutiny lands. For your customers and assessors, it signals that you treat access control for multi‑tenant services as a core discipline, not a last‑minute slide deck.

How can you prepare now for tougher questions about A.8.3 from customers and regulators?

Expect more pointed questions about tenant isolation and cross‑tenant risk over the next few years, especially if you operate in regulated sectors or handle larger customers. You can get ahead of that curve by:

Designing your environment around standard isolation patterns and narrow blast radii, and capturing those patterns clearly
Testing those patterns regularly – for example, by attempting controlled lateral movement between tenants – and recording outcomes
Organising your A.8.3 evidence so it can be reused across tenders, security questionnaires and audits rather than rebuilt each time
Reviewing your current narrative with a critical eye: any hesitation in answering “what prevents an engineer in location X from reaching tenants in region Y?” should become a prompt for both design and documentation work

If you invest now in that clarity – and anchor it in a living ISMS rather than loose files – every future customer or regulator conversation about A.8.3 becomes an opportunity to demonstrate maturity rather than a defensive exercise. Over time, that can become a meaningful differentiator in a crowded MSP market, especially when larger buyers are deciding who to trust with their environments.

A.8.3 Information Access Restriction – Preventing Lateral Movement in MSP Environments