Why Identity Management Is Now Critical for MSPs Under ISO 27001 A.5.16

Why identity management became existential for MSPs

Identity management has become existential for MSPs because a small number of engineer and tool identities now mediate access to many client tenants at once, turning every poorly governed account into a potential multi‑customer incident. If you cannot show that each identity and privilege is deliberate, appropriate and easy to revoke, customers, auditors and your own leadership will treat that as a critical, systemic risk rather than a minor operational detail.

This information is general in nature and does not constitute legal or regulatory advice.

Identity is now the front door to every client tenant

Identity is now the front door to every client tenant because almost every action your engineers or tools take runs through an account, role or token. When those identities span multiple tenants, poor design or weak governance turns each one into a potential entry point to many customer environments at once.

For an MSP, identity has effectively replaced the traditional network perimeter because almost every action in a client environment now flows through an account, role or token that can cross tenant boundaries. Independent analysis of cloud and provider‑side risks, such as European network and information security guidance on “inside the cloud” threats, similarly highlights how identity and access paths have become the practical control surface in multi‑tenant environments.

In older, more perimeter‑driven models, you could reassure yourself that a VPN, a firewall rule, and a small set of “trusted” engineers kept things safe. Today, cloud platforms, remote work, and shared management planes make it easy to operate at scale, but they also mean that every extra privilege your team holds in one tenant can increase exposure across many. When you overlay ISO 27001:2022 Annex A.5.16, which elevates identity management to an explicit control, the shift is even clearer: the companion standard ISO/IEC 27002:2022 introduces A.5.16 as a standalone identity management control, explicitly reinforcing the need to treat identities and their lifecycles as first‑class security objects rather than incidental implementation details.

When identity design lags growth, risk grows in the shadows.

Customers have noticed this shift as well. Security‑mature buyers now ask detailed questions about which MSP staff can reach their systems, how those accounts are created and removed, and how you prevent one customer’s incident spilling over into others. Identity controls are no longer just “good hygiene”; they are rapidly becoming table stakes for winning and keeping the kinds of customers who care about ISO 27001 or similar frameworks.

Why customers and auditors have started to care

Customers and auditors care about your identity management because your engineer accounts sit inside their supply chain and can directly affect the confidentiality, integrity and availability of their systems and data. If those identities are weakly controlled, any incident in your environment can quickly become their incident too, regardless of where the initial compromise occurred.

From your customer’s point of view, you are part of their extended environment. If an attacker compromises one of your engineer accounts and uses it to manipulate their tenant, the impact is very real to them even if the first foothold was in your systems. That is why many regulators and insurers now treat MSP access as a high‑value risk topic rather than a low‑level technical detail. For example, third‑party and outsourcing guidance in the financial sector, such as the European Banking Authority’s outsourcing guidelines, explicitly frames provider access and governance as a material operational risk that needs board‑level attention.

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

Audit teams have followed the same path. Where earlier ISO 27001 audits might have focused largely on your internal user lists and a handful of access reviews, A.5.16 encourages auditors to ask sharper questions. They want to know whether every MSP identity is unique, whether you can trace who approved its access into each tenant, how quickly you remove access when people leave, and whether you periodically review privileges against current roles. Accreditation and certification guidance for ISO/IEC 27001, such as IAF’s material on ISO/IEC 27001 audits, reinforces this focus on traceability, uniqueness and robust evidence around identity‑related controls.

This is also why identity has become a conversation topic in sales and renewals. Large prospects often ask for detailed descriptions of your identity governance model before signing. Existing customers may push for assurances that you have retired shared admin accounts or tightened legacy access paths. If you can answer confidently and show structured evidence, identity becomes a trust‑builder. If you cannot, it becomes a recurring source of friction and delay.

The commercial upside of getting identity right

Default Description

Book a demo

What ISO 27001:2022 A.5.16 actually requires

ISO 27001:2022 A.5.16 requires you to show that every identity in scope is deliberately created, assigned appropriate rights, reviewed regularly and removed promptly when no longer needed, rather than appearing through habit or convenience. For MSPs, this discipline must apply consistently across your internal systems and every relevant customer tenant your staff or tools can reach, not just the systems you own directly. The supporting control text in ISO/IEC 27002:2022 A.5.16 makes this explicit by calling for policies and processes that govern identification, assignment and lifecycle management of identities used to access information and services.

At its core, A.5.16 asks you to prove that identities and their associated access rights are managed deliberately throughout their lifecycle. For an MSP, that means moving beyond ad‑hoc account creation or “give them what they need for now” approaches, and instead defining clear rules for how identities are created, changed, reviewed, and removed across all the environments you touch. You do not need to be an ISO specialist; you need a repeatable way to manage identities that auditors and customers can understand.

In the 2025 ISMS.online survey, almost all organisations said that achieving or maintaining security certifications such as ISO 27001 or SOC 2 is a top priority.

The core obligations in A.5.16

A.5.16 can be translated into a small set of concrete obligations that are straightforward to describe but demanding to implement consistently across multiple tenants. For MSPs, these obligations must extend beyond internal systems into every place your people and tools can act on customer environments, including cloud consoles and management platforms.

If you strip A.5.16 down to essentials, four obligations stand out:

Ensure every identity that can reach in‑scope information or systems is unique and traceable to a real person or function.
Register, approve and create each identity through a defined process before access is first granted.
Assign access rights based on documented roles or business needs, rather than habit or individual preference.
Review identities and rights on a planned cycle, adjusting or revoking them when they are no longer appropriate.

For an MSP, this is not limited to your internal Microsoft 365 tenant or ticketing system. It includes the accounts and roles your staff use inside each customer tenant, the service accounts your tools rely on, and even generic or shared identities you might still be using for historical reasons. A.5.16 does not necessarily ban non‑personal accounts, but it does expect that where they exist, their use is minimised, tightly controlled, and fully traceable. Practical ISO 27002 commentaries, such as community‑oriented guidance on ISO/IEC 27002, highlight that service or shared accounts are acceptable when they are clearly justified, governed and auditable.

From a practical standpoint, you need to be able to answer questions such as “who requested this access, who approved it, when was it granted, what does it allow, and when was it last reviewed?” That is a more demanding bar than “we have a list of users”, but it is also the kind of bar that helps your customers sleep at night.

How A.5.16 relates to other ISO 27001 controls

Understanding how A.5.16 relates to nearby controls makes it much easier to design a coherent system that satisfies auditors without duplicating effort. For MSPs, the most important links are to A.5.17, A.5.18 and A.8.2, which cover authentication information, access rights and privileged accounts, respectively.

Identity management does not sit in isolation. A.5.16 is closely linked to several other controls in the 2022 revision of ISO 27001, and auditors will often consider them together. A.5.17 (authentication information) focuses on how you protect passwords, tokens, keys, and other authenticators. A.5.18 (access rights) addresses the granting, modification, and revocation of access rights. A.8.2 looks specifically at privileged access rights, such as administrative or root‑level accounts. ISO 27002 mapping guidance and control descriptions, including those summarised in independent ISO 27002 digests, treat these areas as distinct but coordinated aspects of access control.

One way to think about this cluster is that A.5.16 answers “who exists in the system and what have we decided they are allowed to do?”, A.5.17 answers “how do we prove it is really them when they log in?”, and A.8.2 answers “how do we treat the most powerful accounts with extra care?”. When you design a multi‑tenant identity model, you are effectively designing how all three of these controls will work in practice for your engineers and tools.

Understanding these relationships helps you avoid duplication and gaps. For instance, if you adopt just‑in‑time privileged access for engineers, you are touching identity lifecycle (A.5.16), access granting (A.5.18), privileged access rights (A.8.2), and authenticator protection (A.5.17) all at once. The more clearly you can show how your patterns satisfy each, the easier audits and customer conversations become.

Who and what is in scope for identity management

A.5.16 applies to every identity that can influence in‑scope information or services, regardless of whether the account technically belongs to your organisation or to a customer. For MSPs, the scope must cover internal staff, tools and automation across all relevant tenants, not just a narrow slice of “internal users”.

A common mistake is to assume that A.5.16 is only about employee accounts in systems you own. For an MSP, that scope is far too narrow. Any identity used by your organisation that can influence information or services within the boundaries of your information security management system should be considered, regardless of whether the account technically “belongs” to you or to a customer.

That includes named engineer accounts inside customer cloud tenants, delegated roles granted to your corporate identities, service accounts used by backup or monitoring tools, and automation identities used by scripts or integration platforms. It also includes shared or generic accounts that may still exist in legacy setups. Even if you plan to phase those out, you should treat them as in scope until they are gone.

The more carefully you define this scope up front, the less likely you are to be surprised later when an auditor or customer asks about a category of accounts you had not considered. Clear scope also makes it easier to decide where to invest in automation and where you can safely rely on well‑controlled manual processes.

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

Reframing A.5.16 for multi‑tenant MSP reality

Reframing A.5.16 for multi‑tenant MSP reality means treating cross‑tenant blast radius and shared supply‑chain risk as first‑class design problems. Your interpretation of the control has to reflect the fact that one identity can span many customer environments and therefore carries more systemic risk than in a single‑tenant enterprise.

Once you understand the formal wording of A.5.16, the next step is to reinterpret it in the context of a provider that operates across many client environments. The risks and responsibilities look different when one of your identities can land you in several tenants with a single click, and your identity model has to reflect that difference in scale and impact.

Understanding the MSP multi‑tenant risk profile

An MSP’s risk profile is defined by the possibility that a single engineer identity or tool account could be misused to access many customer tenants at once, rather than just harming one organisation at a time. That makes blast radius and shared exposure the core questions your identity design has to answer, rather than a secondary concern.

Most organisations in the 2025 ISMS.online survey said they had already been impacted by at least one third-party or vendor-related security incident in the past year.

In a traditional single‑tenant enterprise, the impact of a compromised admin account is usually contained within one organisation. In an MSP, a compromised engineer identity may, in some service models, carry rights into dozens or even more customer tenants, especially if you have historically favoured convenience over strict separation. Analyses of supply‑chain attacks against MSPs, such as published case studies on MSP‑targeted compromises, show how misuse of provider credentials can cascade across many customer environments at once.

Reframing A.5.16 for this world means thinking in terms of blast radius and shared exposure. You need to know which identities can cross tenant boundaries, which permissions they hold in each environment, and how you prevent a failure in one place from cascading elsewhere. That includes considering how your own cloud tenants, management tools, and on‑premises infrastructure could be used as stepping stones into customers if an attacker gained control.

It also requires you to revisit informal practices. Shared “MSP admin” accounts, legacy VPN profiles reused across clients, or undocumented exceptions for particular engineers can all undermine the clean identity picture A.5.16 expects. Surfacing these issues without blame is the first step toward designing something more robust.

Clarifying ownership of identities across MSP, customer, and suppliers

Clarifying ownership of identities across MSP, customer and supplier boundaries is essential because A.5.16 expects you to know who approves access, who operates accounts and who is accountable if those identities are misused. Without that clarity, you carry more risk than you realise and struggle to answer basic due‑diligence questions.

Multi‑tenant reality also blurs the lines between who owns which identities. Some accounts are clearly controlled by you, such as your corporate identity provider accounts and the roles they hold in customer tenants. Others may be created and managed by customers but used by your staff. Yet others may be managed by third‑party suppliers whose tools you resell or integrate.

A workable interpretation of A.5.16 for MSPs has to define ownership and responsibility across all of these. For each category you should be able to say who approves new access, who creates and configures the identity, who reviews it periodically, and who is accountable if it is misused. Those answers should line up with your contracts, with customer expectations, and with your risk assessments.

Writing this down in simple language-alongside diagrams that show where identities live and how they traverse systems-can be surprisingly powerful. It gives your own teams a shared mental model and gives customers and auditors a way to understand a complex topic without getting lost in technical detail.

Regulatory and jurisdictional angles you cannot ignore

Regulatory and jurisdictional angles matter because identities can bridge regions and data sets where different privacy and access rules apply. Regulators increasingly expect MSPs to demonstrate that cross‑border or sensitive access is justified, logged and constrained, so identity design that ignores those boundaries creates avoidable problems.

Many MSPs work with customers in regulated industries or across multiple countries, where identity management intersects with privacy, data residency, and cross‑border access requirements. If staff in one jurisdiction can log into systems holding data from another, regulators may expect you to demonstrate how you control and justify that access, particularly where local laws restrict who can see which data and from where. European data‑protection guidance on controllers and processors, such as that from the European Data Protection Supervisor, stresses governance, logging and contractual clarity for processors handling cross‑border or sensitive data on behalf of controllers.

According to the 2025 ISMS.online survey, around two-thirds of organisations say the speed and volume of regulatory change are making compliance harder to sustain.

When you redesign identity under A.5.16, it helps to ask: which engineers in which locations can access which classes of data, under what conditions, and how is that documented? This is especially relevant where customer contracts or local law require that certain data never be accessed from particular regions, or that access is limited to named individuals with specific clearances.

Bringing your privacy, legal, and security teams together to review these questions through the lens of identity can prevent painful surprises later. It also helps you avoid creating a theoretically strong identity architecture that turns out to be misaligned with regulatory realities, particularly for cross‑border services.

Designing a multi‑tenant identity management model

Designing a multi‑tenant identity management model means choosing an architecture, toolset and set of failure‑handling patterns that enforce unique, least‑privilege identities across customer tenants without overwhelming engineers. The model should be intentional, documented and practical to operate as your MSP grows and changes.

With the risk picture and responsibilities clarified, you can start designing a multi‑tenant identity model that is both practical and aligned to A.5.16. This is where you decide how identities flow from your own directory into customer tenants, which tools sit at the centre of your world, and how you handle exceptional situations without undermining the whole design.

Choosing a multi‑tenant identity architecture

Your identity architecture should make it clear where identities live, how they assume roles in customer tenants and how easily you can revoke access across all those environments when staff change. Most MSPs end up choosing between a hub‑and‑spoke model, a per‑tenant account model or a hybrid that mixes elements of both.

At a high level, MSPs tend to choose between three patterns. In a hub‑and‑spoke model, your own identity provider is the hub and engineers use identities from that directory to assume roles in multiple customer tenants. In a per‑tenant model, each customer tenant has its own set of accounts for your staff, sometimes with local directories. Hybrids combine central control for some aspects with per‑tenant isolation for others.

A simple comparison can help frame the decision:

In short, hub‑and‑spoke optimises central control, per‑tenant maximises isolation, and hybrid balances both at the cost of more design effort and documentation work. Professional IT audit guidance, such as that published by ISACA and similar bodies, tends to emphasise that auditors are less concerned with which pattern you choose and more concerned that you can explain it clearly, show how it reduces risk, and evidence that you apply it consistently.

Your choice should be driven by your size, your customers’ expectations, the platforms you support, and your appetite for complexity. Whichever architecture you choose, A.5.16 expects it to be intentional and documented. You should be able to show why you chose it, how it keeps identities unique and traceable, and how lifecycle events flow through it. That documentation does not have to be verbose, but it does have to be coherent.

Placing the right tools at the centre

Placing the right tools at the centre of your model ensures there is a single, reliable chain from business events-joiners, movers, leavers and new customers-through to account, role and evidence changes. Without that, identity quickly becomes an opaque mix of habits and exceptions that is hard to defend under audit.

Once you have a conceptual architecture, you need to decide which tools occupy the “source of truth” position for identity and access. For some MSPs, that will be the corporate identity provider. For others, it may be an identity governance platform, a privileged access management solution, or even a ticketing system that acts as the authoritative record of who requested and approved what.

The key is that there is a clear chain from business events-someone joining, changing role, or leaving; a new customer onboarding; a change in contract-to identity changes in your various systems and tenants. If your HR system or professional services platform is where new roles are born, you need to know how that flows into your IdP, into customer tenants, and into your evidence trail.

This is also where an information security management platform such as ISMS.online can help. By linking your policies, role catalogues, diagrams, and records of approvals to specific controls like A.5.16, it gives you one place to see whether the model you have designed is actually being followed, and to show that linkage when auditors or customers ask for proof.

Designing for failure and continuity

Designing for failure and continuity means planning how identities will behave when key tools, people or infrastructure are unavailable, so you can protect customers even under stress. That requires controlled break‑glass paths and recovery procedures that still follow A.5.16’s intent instead of bypassing it.

No identity model is complete if it only works when everything else is healthy. You also need to plan for situations where your identity provider is unavailable, a key management platform is down, or an engineer with critical knowledge is suddenly absent. Those scenarios are uncomfortable, but ignoring them often leads to ad‑hoc workarounds that undermine your controls.

A resilient design will include clearly defined emergency access paths that still respect the spirit of least privilege. That might mean a small number of break‑glass accounts with very strong protections and strict procedures, or pre‑approved offline processes for specific scenarios. Crucially, their existence and use should be documented, monitored, and reviewed so they are not quietly misused over time.

Thinking about these failure modes early and capturing them in your information security management system makes it much easier to explain to customers and auditors how you would handle a crisis without simply bypassing all of your carefully designed identity controls. It also gives your own team confidence that they can act under pressure without having to invent risky shortcuts.

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

Book your demo

RBAC, least privilege, and admin account separation patterns

Role‑based access control, least privilege and clear separation between standard, privileged and emergency accounts turn your high‑level identity architecture into concrete day‑to‑day behaviour that limits multi‑tenant blast radius when something goes wrong. These patterns are where A.5.16 becomes a living control for MSPs rather than a policy statement on a shelf.

Once your high‑level model is clear, you can move one level down into the patterns that govern day‑to‑day access. Role‑based access control, least privilege, and careful separation between standard, privileged, and emergency accounts are the tools that turn the principles of A.5.16 into practical design that engineers can follow and auditors can test.

Building an MSP‑wide role catalogue

An MSP‑wide role catalogue should give you a small, well‑defined set of roles that map consistently into permissions across platforms and tenants, so that engineers receive access because of responsibilities rather than personal history or informal exceptions. It also makes it easier to explain your model to non‑specialists.

A role catalogue is simply a list of defined roles, each with a clear purpose and associated entitlements. For an MSP, typical roles might include first‑line support, senior engineer, security analyst, project engineer, and account manager. Each role should be described in terms that both business and technical staff understand, with examples of the kinds of tasks it covers.

The value in a catalogue is that it gives you a standard starting point. Instead of deciding access tenant by tenant and person by person, you decide it once at the role level, then map those roles to platform‑specific permissions in each environment. That makes it much easier to demonstrate that access is tied to responsibilities, not personal relationships or historical accidents.

When you create such a catalogue, it is worth starting small. Identify the handful of roles that cover most of your staff, define them well, map them into one or two major platforms, and refine from there. You can then handle exceptions as documented variations, rather than inventing new roles for every unusual case. Over time, you can add more roles or refine existing ones as your services grow.

Separating standard, privileged, and break‑glass access

Separating standard, privileged and break‑glass access allows you to apply different controls, monitoring and review cycles to everyday work, administrative activity and genuine emergencies. Clear separation also helps engineers understand which identity they should use in each situation and what level of scrutiny to expect.

In many MSPs, the same engineer identity is used for everyday work and for highly privileged actions in customer tenants. That may feel convenient, but it blurs accountability and makes it hard to apply extra safeguards to sensitive operations. A.5.16 and its related controls encourage you to draw clearer lines so you can protect customer environments more effectively.

A practical pattern that many MSPs adopt looks like this:

Standard identities for day‑to‑day work and low‑risk support tasks.
Privileged identities or roles for administrative tasks, ideally with just‑in‑time elevation.
Break‑glass accounts reserved strictly for emergencies, with heightened protection and oversight.

Standard identities handle routine tickets and low‑risk changes and are monitored through normal logging. Privileged identities are used only when necessary, are elevated temporarily, and are subject to closer review. Break‑glass accounts are tightly controlled, used rarely under defined conditions, and always reviewed after use so you can prove that emergencies do not become back doors.

Testing that your design actually contains blast radius

You only know that your role‑based access and separation patterns work when you have tested how they behave under realistic failure scenarios, such as compromised devices or leaked credentials. Without this testing, you may rely on a design that looks strong on paper but does little to contain real‑world incidents.

Roles and separation patterns can look excellent in diagrams but behave poorly under stress. To avoid a false sense of security, you should periodically test whether your design really limits the impact of a compromised account or a misuse scenario in the way you expect, using both technical and organisational exercises.

That might involve tabletop exercises where you walk through hypothetical incidents: an engineer’s device is stolen; an attacker gains access to a password vault; a privileged token is leaked. It could also involve technical simulations, using tooling or manual review to see which tenants and systems a given identity can reach and what it can do there.

The goal is not to “break” your design for its own sake, but to find weak spots before an attacker does. When you adjust roles, privileges, or patterns in response, capture those changes and the reasons for them. Over time, this becomes powerful evidence that you are treating identity as a living control, not a static configuration frozen on the day of certification.

Joiner–mover–leaver and just‑in‑time access across tenants

Joiner–mover–leaver and just‑in‑time processes are where your identity model meets everyday change, so they need to keep accounts aligned with reality across tenants without creating unbearable friction. A.5.16 is often judged on how well these flows work in practice, not just how they are described in policies or diagrams.

A well‑designed identity model still fails if you cannot keep it up to date as people join, change roles, and leave. For MSPs, the joiner–mover–leaver process is where your theoretical design meets messy reality: staff turnover, organisational change, new customers, and urgent projects that pull people into new tenants at short notice.

Designing robust joiner–mover–leaver flows

Robust joiner–mover–leaver flows start from trustworthy business events and translate them consistently into identity changes in every relevant tenant, rather than leaving engineers to remember ad‑hoc updates. That means defining what should happen for joiners, movers and leavers and making those steps as automatic and repeatable as possible.

A robust JML process starts by anchoring identity changes in reliable events. Joiners should be triggered by HR or contractual onboarding, movers by role or responsibility changes that have been approved, and leavers by formal exit processes or contract terminations. Each type of event should map to clear actions in your systems and in each customer tenant that engineer or tool touches.

A simple way to make this tangible is to define a short, repeatable sequence for each stage:

Joiners

Create identities in the corporate directory.
Assign standard roles and baseline access.
Grant tenant‑specific access where contracts permit.
Capture approvals and log effective dates.

Movers

Review current roles and tenant access.
Add required roles and remove those no longer needed.
Update group memberships and tool permissions.
Record approvals and rationale for changes.

Leavers

Revoke all tenant and tool access promptly.
Disable or remove accounts in the corporate directory.
Remove from privileged groups and admin roles.
Confirm completion and retain evidence for audit.

The multi‑tenant twist is that these steps often have to be repeated across many environments and tools. Automating the predictable parts, such as group membership updates or workflow approvals, and limiting human intervention to exceptional cases, helps you stay consistent without overwhelming your teams or relying on individual memory. Identity governance literature, for example guidance on identity lifecycle and governance patterns, emphasises this end‑to‑end lifecycle discipline-registration, modification and revocation-which aligns closely with what A.5.16 is asking you to demonstrate.

Using just‑in‑time elevation without slowing engineers

Using just‑in‑time elevation without slowing engineers requires designing elevation paths that trim risk by shrinking privileged windows while still allowing rapid response. If you involve engineers in the design, JIT can feel like a normal part of work rather than a barrier people try to bypass.

Just‑in‑time access can feel like an added burden for engineers who are used to always‑on administrative rights. Done badly, it slows response times and encourages shortcuts. Done well, it can materially reduce risk while still letting your staff do their jobs with minimal friction.

In practice, JIT for MSPs usually means that engineers work with standard access most of the time, then request temporary elevation for specific tasks that genuinely require it. Requests may be triggered automatically from tickets, changes, or incident workflows, and may include approvals depending on the risk of the action. Elevation is time‑bound and logged, and access returns to normal afterwards without manual clean‑up.

To make this work, you need to design the process with engineers, not just for them. That includes choosing sensible default durations, avoiding unnecessary approvals for low‑risk tasks, and making the request path fast and familiar. If the process is clearly tied to your identity governance storey and customers recognise its value, it becomes easier to build cultural support and avoid workarounds.

Automating what you can, reviewing what you must

Automating what you can and reviewing what you must allows you to handle frequent, low‑risk identity changes at scale while reserving human judgement for higher‑risk or unusual cases. A.5.16 is easier to evidence when routine joiner–mover–leaver and just‑in‑time steps are consistent, well‑logged and repeatable.

Not every aspect of JML and JIT can or should be automated. High‑frequency, low‑risk changes-such as adding a standard role for a new engineer or updating group memberships-are good candidates for automation, especially in multi‑tenant tools where mistakes can propagate quickly. So are routine deprovisioning steps that can be reliably triggered from HR or contract systems.

On the other hand, unusual access requests, cross‑tenant exceptions, and emergency break‑glass use should always include human review. These are the places where judgement matters, and where you want to be able to show that someone considered the risk and made a deliberate decision rather than ticking a box.

Regular reconciliation between what your identity systems think is true, what your HR and contract records say, and what actually exists in each customer tenant is the final piece. When you find discrepancies-dormant accounts, lingering privileges, undocumented identities-treat them as learning opportunities. Fix the specific issue, then ask how you can adjust your processes or automation to prevent similar gaps in future. That reconciliation is strong evidence that you are meeting A.5.16’s lifecycle expectations rather than only its documentation requirements.

If you are already feeling the strain of keeping joiner–mover–leaver and just‑in‑time access aligned across many tenants using spreadsheets and memory, it may be worth exploring how a structured information security management platform could carry some of that weight and help turn A.5.16 into a more sustainable, living control rather than a series of ad‑hoc fixes.

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

Book your demo

Proving A.5.16 compliance: documentation, evidence, and audits

Proving A.5.16 compliance means being able to show, at any time, how you intend identities to be managed, how they actually behave in practice and how you learn from audits and incidents. For MSPs, that evidence needs to cover multi‑tenant realities as well as internal systems, so you can reassure customers and auditors under pressure.

Design and operation are only two‑thirds of the storey. A.5.16 also assumes that you can show, when asked, how your identity management actually works. That means having the right documents, keeping them aligned with practice, and turning everyday activity into evidence you can put in front of auditors, customers, and regulators without frantic last‑minute effort.

The minimum document set for A.5.16

The minimum document set for A.5.16 is a small group of clear, well‑maintained policies and procedures that describe your identity intent and responsibilities. These documents need to reflect multi‑tenant reality as you operate it today, not a theoretical picture that only exists for audits.

You do not need hundreds of pages, but you do need a small set that clearly expresses your intent. At a minimum, that usually means an identity management policy, a standard for roles and access assignments, procedures for joiner–mover–leaver and just‑in‑time processes, and a standard for admin and emergency accounts.

Each of these should describe not only what you do but who does it and how you know it has been done. They should align with your risk assessment and with other relevant policies such as access control, supplier management, and business continuity. For MSPs, they should also explicitly cover multi‑tenant aspects: delegated admin, cross‑tenant roles, service accounts in customer environments, and legacy shared accounts.

Writing these documents in plainly understandable language pays off quickly. They become usable references for engineers and operations staff, not just formalities for auditors. ISMS.online can help you keep these documents linked to controls like A.5.16, to risk records, and to improvement actions so they stay current rather than being updated only when the next audit approaches.

Building an evidence register that works under pressure

Building an evidence register that works under pressure means mapping each A.5.16 requirement to specific, repeatable artefacts that you can produce quickly. The aim is to make it much easier to reuse routine work as audit evidence instead of turning every request into a reactive scramble.

When audit season arrives or a large prospect asks for proof, the worst time to assemble your evidence is the week before the conversation. Instead, it is worth building a simple evidence register that maps each requirement in A.5.16 to specific, repeatable artefacts: reports, configuration extracts, ticket samples, access review records, and logs that you can produce reliably.

For example, you might link the requirement for unique identities to exports from your identity provider that show naming conventions and account types, and to procedures for creating new accounts. You might link lifecycle requirements to change records that show how a joiner was onboarded and a leaver was removed across several tenants, combined with an IdP export for the same period. You might link periodic review expectations to documented access review campaigns and their outcomes.

By maintaining this register in a structured way, you turn everyday work into material that can be quickly assembled into a coherent evidence pack. When someone asks “how do you know your identities are properly managed?”, you are not scrambling; you are selecting from a set of agreed, easy‑to‑produce items. Any MSP can design such a register; a dedicated ISMS platform is simply one way to hold the mapping together and keep it visible.

Using audits and incidents to strengthen your storey

Using audits and incidents to strengthen your A.5.16 storey means treating them as structured feedback loops rather than one‑off compliance events. Each finding or near miss is a chance to improve your identity design, processes and evidence in ways you can demonstrate later.

Internal and external audits can feel adversarial, but they are also opportunities to validate and improve your identity management. When you plan an internal audit, consider deliberately sampling a mix of tenants, identity types, and roles. Look for consistency between your design and what you find, and capture both strengths and gaps in a form that you can feed back into your risk assessments and policies.

Similarly, when an incident touches identity-whether it is a genuine breach, a near miss, or simply a confusing access request-take the time afterwards to ask what it tells you about your design and processes. Did your documentation help or hinder investigation? Were logs available and useful? Did people understand which identities were in scope and which were not?

Recording the results of these reviews and feeding them back into your information security management system closes the loop. It shows auditors and customers that you treat A.5.16 as a living control, and it gives your leadership confidence that identity management is not just a one‑off project but an ongoing practice that improves as you learn.

Book a Demo With ISMS.online Today

ISMS.online helps you turn a complex, multi‑tenant identity landscape into a coherent, audit‑ready storey that satisfies ISO 27001 A.5.16 and reassures your customers that you take access seriously. By bringing your policies, role models, joiner–mover–leaver and just‑in‑time processes, and evidence into one structured space, it becomes far easier to see where you are strong, where you have gaps, and how changes in one area affect others.

What you gain by centralising your identity evidence

Centralising identity‑related evidence in a single, structured environment gives you a continuously updated picture of how A.5.16 is being met across your organisation and customer tenants, instead of relying on ad‑hoc document hunts in the run‑up to each audit or customer review. Experience from ISMS and identity‑governance practice, reflected in independent integration guidance such as industry whitepapers on tying ISMS and identity controls together, suggests that centralised control and evidence management can materially improve visibility of control status over time.

When identity management is scattered across spreadsheets, ticket comments, and individual memory, every audit or due‑diligence request becomes a mini‑project. By centralising your control design and evidence, you create a single place where your team can see how identities are supposed to be managed, which controls support that, and which records demonstrate it.

That makes it much easier to answer customer questions such as “who from your company can access our tenants?” with more than a vague assurance. You can point to defined roles, documented processes, and real access review results. It also reduces your dependency on a few people who “know how it all works”, which is crucial as you grow and as staff change roles or leave.

From an operational point of view, centralisation reduces duplication and confusion. When your policies change, you update them once and link them to the relevant controls, tasks, and records. When you complete a review or close an audit finding, the evidence is attached in context. Over time, this builds a rich, navigable history of how you have strengthened identity management for your own organisation and for the tenants you support.

A low‑risk way to get started with ISMS.online

Starting small with a focused slice of A.5.16 in ISMS.online lets you prove the value of centralisation without committing to a wholesale process change on day one. You can begin with identity policy and a single joiner–mover–leaver flow, then expand as your team becomes comfortable and sees practical benefits.

If you already feel the strain of managing multi‑tenant identity without a structured information security management system, the idea of adding another platform might sound daunting. The reality can be much lighter‑weight than you think. Many MSPs start by bringing a small, focused slice of A.5.16 into ISMS.online and learning from that experience before expanding to other controls and frameworks.

For example, you might begin with your identity policy, role catalogue, and a single joiner–mover–leaver process, linking them to A.5.16 and related controls and attaching a handful of recent evidence items. From there, you can experiment with scheduling reviews, assigning improvement tasks, and mapping other parts of your identity model into the system as you gain confidence.

A short conversation with the ISMS.online team can help you decide whether this approach fits your culture, scale, and existing tools. You will see how other MSPs have used the platform to express multi‑tenant identity models, how auditors typically respond, and what a realistic roadmap looks like. Choose ISMS.online when you want multi‑tenant identity management to feel controlled, evidenced and explainable; if you value credible assurance for customers, auditors and regulators, the next step will be easy to take.

Book a demo

Frequently Asked Questions

How does ISO 27001:2022 A.5.16 really change the way an MSP must handle identities in client tenants?

ISO 27001:2022 A.5.16 pushes you from “we have access” to “we can always prove exactly who has what access, why, and for how long” across every client tenant. For a managed service provider, that includes your own corporate estate and every delegated or embedded identity inside customer environments.

What does “no anonymous hands” mean in a multi‑tenant MSP?

A.5.16 expects you to treat identity as a governed asset, not a scattered set of logins:

Every human and non‑human identity that can reach a tenant is listed, owned, and justified.
Each identity is tied to a role, contract or service, not vague “admin” access.
Changes over time – onboarding, project access, incident elevation, offboarding – follow defined steps.
Approvals, reviews and removals are logged and sampleable months later.

That discipline has to cross several layers:

Partner/delegated admin roles in hyperscalers.
Legacy direct admin accounts in older tenants.
Service accounts for RMM, backup, monitoring and security tooling.
Break‑glass identities for continuity or incident work.

From a buyer or auditor’s perspective, an MSP‑controlled admin path is now a prime attack surface. When you can point to a specific engineer or service identity, show where it lives, which roles it assumes in each tenant, and how approvals and reviews are embedded into your Information Security Management System, A.5.16 stops being a clause to “get through” and becomes a reason to trust you. ISMS.online helps you build that storey by linking policies, diagrams, risk records and lifecycle evidence directly against the control so what you say and what you do stay aligned.

How can an MSP design a multi‑tenant identity architecture that survives A.5.16 and enterprise due diligence?

A multi‑tenant identity architecture that stands up to scrutiny gives you a small set of standard patterns for how your people and tools enter and operate in any client tenant, with clear containment if something goes wrong. A.5.16 doesn’t prescribe technology; it asks whether your pattern is intentional, documented, and repeatable.

Which identity architecture decisions should you lock in once?

You reduce risk and audit pain when you stop debating the basics case by case and settle a few points as house rules:

Where identities live:

Decide whether engineer accounts live centrally (for example, in Entra ID) and assume roles into tenants, are created inside each tenant under strict rules, or use a hybrid model. Whatever you choose, document the pattern and stick to it.

What system is “source of truth” for change:

Pick a single master (HR, ITSM, IdP, governance tool) for joiner–mover–leaver events and enforce that everything else – including tenant access – follows downstream. A.5.16 is satisfied when you can show one clear signal driving all access changes.

Allowed entry paths into tenants:

Standardise on a short list: delegated admin groups, bastion access, just‑in‑time elevation, privileged access workstations, and so on. Unsupported one‑off paths are where surprises and audit findings tend to hide.

Planned break‑glass and failure modes:

Define what happens if your IdP, PAM, or a client control plane fails. Time‑bound, logged emergency access tied to tickets is far easier to justify than a memorised global admin password.

A simple visual that shows “MSP identity plane → access patterns → tenant planes” can do more for you in a due‑diligence call than a ten‑page policy. When that diagram, the related policies, and risk assessments live together in ISMS.online and are linked to A.5.16, you’re not just producing an artefact for an audit – you’re maintaining a living design that new engineers, new tenants and new platforms can plug into without improvisation.

What does strong role‑based access and least privilege look like for MSP engineers across many customers?

For an MSP, credible least‑privilege means that every engineer’s rights in every tenant are a current expression of their role, not a history of every incident and favour they have ever handled. A.5.16 becomes dramatically easier to evidence when rights follow a clean model and elevation is clearly exceptional.

How can you structure RBAC so you can defend it under pressure?

Providers that move through customer security questionnaires without panic usually share a few patterns:

A tight, maintained role catalogue:

Instead of dozens of “almost the same” roles, they define a focused set – for example, service desk, senior engineer, security specialist, project engineer, duty manager – and map each to rights per platform and per tenant tier (e.g. high‑regulation vs standard).

Strict separation of normal and privileged work:

Engineers use one identity for everyday activity and either elevate that identity or switch to a hardened account for high‑risk changes. Multi‑factor authentication and logging are non‑negotiable around elevation.

Tenant‑specific scoping:

Groups and roles reflect what has actually been sold and agreed with each customer. Being a senior engineer doesn’t automatically mean wide rights in every tenant.

Visible, time‑boxed exceptions:

Broad cross‑tenant or emergency roles exist only for clearly defined scenarios such as incident response, with explicit owners, expiry dates and review evidence.

A blunt but effective test is to pick a senior engineer and ask yourself, “if this identity were compromised today, which tenants could be harmed and how badly?” If you cannot answer from your systems within a few minutes, your RBAC model is more fragile than it looks. Centralising role definitions, mappings and access‑review evidence in ISMS.online gives you one place to refine that model and show auditors and customers that your risk is coming down, not drifting.

How can an MSP keep joiner–mover–leaver and just‑in‑time access reliable when staff work across dozens of tenants?

When people join, change roles or leave, access in every affected tenant should change in a predictable way – not through ad‑hoc edits that nobody can reconstruct six months later. A.5.16 focuses less on specific tools and more on whether identity changes follow defined, repeatable flows that leave behind evidence.

MSPs that don’t fear being sampled on access changes have usually simplified the reality into a few reliable habits:

Start from a single people event:

Capture new hires, internal moves, promotions, contract changes and leavers once in HR or your ITSM tool, then let that drive every downstream identity change – account creation, group membership, tenant access, and deprovisioning.

Standardise recurring access actions:

Onboarding engineers into tenant groups, changing which team covers specific hours, or revoking contractor access across shared tools all follow simple procedures rather than relying on memory. Those procedures specify who approves what, in what timeframe, and what evidence is kept.

Automate the routine, hold onto human judgement for risk:

Where patterns are repetitive – like adding a standard role to ten tenants or removing an identity from shared tools – automation works well, as long as it leaves logs you can point to. Exceptional changes, such as unusually broad rights in a regulated tenant, still go through explicit approval and recorded validation.

Treat JIT elevation as a controlled event, not a favour:

When engineers need higher rights, they request them for a defined window linked to a ticket. Grant, start and end of elevation all leave records you can show later.

People in your team often accept these controls more readily if they see they’re not just about auditors: done well, they mean less chasing, fewer manual steps and fewer awkward conversations about forgotten rights. Using ISMS.online to map JML and JIT procedures to real tickets, HR events and control A.5.16 makes it much easier to show – to your own leadership and to customers – that identity risk is part of how you manage the business every week, not a once‑a‑year checklist.

What identity evidence actually reassures customers and auditors that an MSP meets A.5.16 across tenants?

Auditors and enterprise buyers rarely expect perfection, but they do expect your storey, your processes and your records to agree. The identity evidence that lands best is usually more about coherence than volume.

Which A.5.16 artefacts build trust instead of drowning people in detail?

For a multi‑tenant MSP, a convincing evidence set often has these elements:

Policy and procedure documents: written in plain language that explicitly mention external tenants, the main platforms you support, and how joiner–mover–leaver, role assignment, and elevated access work.
A current role catalogue and mappings: that show how internal roles translate into specific rights in systems like Microsoft 365 delegated admin, RMM, backup, security tooling and on‑prem infrastructure.
A small number of real JML examples: where you can show onboarding, changes, and offboarding, including tenant access added or removed and approvals captured.
Records from scheduled access reviews: – say quarterly or semi‑annual – that list which MSP identities can reach each tenant, what changed since the prior review, and what corrective actions you took.
Change and incident records: tracing higher‑risk access events from request to approval to implementation, with test or rollback notes where appropriate.
Evidence of learning over time: – internal audit findings, penetration tests or incidents where access played a part, plus the follow‑up actions logged and closed.

Trying to assemble this on demand from personal mailboxes, exported spreadsheets and scattered files is where most MSPs feel the stress. Keeping it in a structured Information Security Management System and linking each artefact against A.5.16 lets you answer hard questions with a calm, consistent storey. When you use ISMS.online for that structure, your team can prepare once and then reuse the same controlled view for ISO audits, major tenders and insurer questionnaires instead of reinventing your evidence pack every time.

How can an MSP use ISMS.online to turn A.5.16 into a repeatable multi‑tenant identity practice instead of a one‑off project?

Most MSPs already know what “good” identity management looks like; the difficult part is doing it reliably while supporting many tenants, different platforms and a busy team. ISMS.online gives you a single place to describe how identity should work, anchor that description to real activity and show how it improves.

How do you embed multi‑tenant identity in your ISMS so it actually sticks?

Teams that manage A.5.16 confidently without constant fire drills tend to use the platform in a few tangible ways:

Document and own the identity blueprint:

Keep your identity architecture diagrams, role catalogue and standard admin patterns in one workspace, linked to A.5.16 and related controls like access restriction, logging and supplier access. When you adapt the model for a new platform, sector or risk appetite, the change is versioned, reviewed and clearly owned.

Tie procedures directly to lived practice:

Link JML/JIT procedures and access review steps to tickets, exports, logs and reports that show they actually run. That bridge turns A.5.16 from “what we say we do” into “what we can demonstrate we do” whenever somebody asks.

Turn findings into visible improvement:

When internal audits, incidents or customer questions surface weaknesses in identity, log them as actions with owners and dates rather than background worries. Over time, your ISMS view of A.5.16 becomes a timeline of hardening decisions rather than a static control statement.

Answer the same hard questions consistently:

Work from the same control view when an ISO auditor samples A.5.16, when a major customer’s security team asks which people can reach their tenant, or when your insurer wants to understand your identity model. You adjust the depth you share, not the underlying facts.

If your current identity storey depends heavily on a few people who “just know how it works”, start small rather than trying to map everything at once. Pick one critical flow – such as how privileged access for regulated tenants is granted, reviewed and removed – and model it clearly in ISMS.online against A.5.16. Once you can walk into a meeting and explain that flow without notes or scrambling for evidence, you have a pattern you can apply to the rest of your identities and tenants, and a much stronger hand when you present your managed service as not just functional, but demonstrably trustworthy.

A.5.16 Identity Management – Multi-Tenant Identity & Account Handling for MSPS