How to Build an ISO 27001 Multi-Tenant Risk Register for MSPs That Scales

Why your MSP risk registers start to break as you grow

MSP risk registers start to break when the way you track risk no longer matches how your shared services actually run. You probably began with one ISO 27001 risk register per client in a spreadsheet or simple tool, which works for a handful of customers. Once you are managing dozens of tenants on common platforms, that “one register per customer” pattern stops giving you reliable information or credible ISO 27001 evidence, and every assessment or audit feels harder than the last.

A well‑designed, multi‑tenant risk register is about more than tidying up spreadsheets. It is how you prove, to yourself and to others, that you understand the risks that flow through your shared services, that these risks are treated consistently per client, and that you can stand behind your ISO 27001 storey when an auditor or key customer starts asking hard questions.

Multi‑tenant risk is a portfolio problem, not a spreadsheet problem.

If you are an MSP owner, COO, CISO, security lead or service manager, the patterns in this guide are designed to match your reality: shared tools, many customers, tight margins and constant external scrutiny.

The tell‑tale symptoms of a register that does not scale

You can tell a multi‑tenant risk register is failing when familiar issues reappear but your data is fragmented and hard to explain. At that point, you no longer have a single version of the truth about risk across your customer base, and every audit or questionnaire becomes a stressful reconstruction exercise where people scramble to reconcile different lists under time pressure.

A multi‑tenant risk register that is starting to fail usually shows the same set of symptoms. When MSPs reach a certain size, the pain becomes obvious:

According to the 2025 ISMS.online survey, customers increasingly expect their suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials and SOC 2 rather than relying on informal good practice claims.

The same risk appears in ten different spreadsheets with slightly different descriptions, ratings and owners.
Some client registers define “high” as a score of 12, others as 15, so portfolio‑wide reporting becomes meaningless.
Shared risks, such as compromise of your remote monitoring and management (RMM) platform, are treated completely differently per client.
Every audit or major RFP triggers a scramble to reconcile lists, chase updates and fix inconsistencies under time pressure.
Teams hesitate to store multi‑tenant information in one place because they are unsure how to keep client data segregated.

Under ISO 27001, this is not just an efficiency problem. The standard expects you to have a systematic, maintained risk assessment and treatment process within your ISMS scope, and fragmented, inconsistent registers make it very hard to show that discipline. This expectation appears in ISO 27001’s requirements to establish, implement, maintain and continually improve an information security risk assessment and treatment process, as described in the standard published by ISO.

Why multi‑tenancy changes the risk equation

Multi‑tenancy changes the risk equation because one compromise or design decision can affect many customers at once. Traditional ISO 27001 implementations often assume a single organisation; your reality is that shared tools and platforms amplify both good and bad decisions across your entire book of business, so weaknesses spread further and faster if you do not manage them centrally. This kind of cascading impact is a well‑recognised feature of supply‑chain and shared‑service risk in guidance from regional cyber security agencies such as ENISA.

For example:

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

A single design decision in your platform (for example, changing security settings for RMM or backup) can affect risk for dozens of tenants.
An attacker who compromises your shared tools can pivot into many client environments at once.
A weakness in one client’s configuration can reveal a pattern that exists across your entire portfolio.

If you manage each client’s risks in isolation, you have no reliable way to see those patterns, prioritise systemic fixes or explain them to your board and customers. A multi‑tenant risk register makes those cross‑cutting issues visible while still giving each client a clean, tenant‑specific view.

The opportunity: from scattered lists to a portfolio‑wide backbone

A strong multi‑tenant risk register turns scattered lists of issues into a portfolio‑wide backbone for decisions, audits and client conversations. The goal is not to abandon ISO 27001 foundations, but to express them in a data model that understands tenants, shared services and portfolio‑level reporting, so you can answer detailed audit questions and high‑level leadership questions from the same underlying data.

You do not need to abandon ISO 27001 foundations to fix this. Instead, you need to:

Keep the core ISO 27001 concepts that auditors expect to see.
Re‑think the data model so it explicitly understands tenants and shared services.
Separate reusable risk definitions from per‑tenant risk instances.
Wrap everything in workflows and access controls that are comfortable for MSP staff, auditors and clients.

Instead of treating each client register as a separate artefact, you can move towards a single, multi‑tenant model that supports both individual audits and portfolio‑level decisions.

Book a demo

ISO 27001 risk concepts you must represent in a multi‑tenant world

A multi‑tenant risk register still has to embody core ISO 27001 risk concepts, even if the way you store and slice data becomes more complex. Before you change the architecture, you need to be clear on what ISO 27001 actually expects from your risk process. The standard does not prescribe a particular “risk register” format, but it does require you to identify what matters, what can go wrong, where you are weak, how likely events are and what you are doing about them, and to identify, analyse, evaluate, treat and monitor information security risks in a systematic way. In practice, that means your register needs to capture certain ideas explicitly so auditors can see how you move from threats and weaknesses to decisions and controls. ISO 27001 and its companion risk management standard describe these outcomes in terms of a repeatable assessment and treatment process, even though they deliberately avoid mandating a single register format, as reflected in materials published by ISO.

Clarity about risk concepts makes it far easier to defend your decisions.

The building blocks: assets, threats, vulnerabilities, risks and controls

Every risk you record should be understandable in terms that non‑specialists can follow. For each risk, you should be able to point to what is at stake, what could happen to it, why it could happen, and what you are doing in response, so an auditor or client can follow the storey without having to translate jargon or guess at your logic.

For each risk, you should be able to point to:

Asset: – what is at stake? This might be a client’s ERP system, a shared backup platform, a set of privileged accounts, or a business process like “customer billing”.
Threat: – what could go wrong? Phishing, credential theft, insider misuse, denial of service, data centre outage and so on.
Vulnerability: – what weakness makes that threat more likely or more damaging? Lack of multi‑factor authentication, unpatched systems, excessive privileges, weak supplier due diligence and similar issues.
Risk: – the combination of likelihood and impact if the threat exploits the vulnerability on that asset.
Controls: – the measures you put in place to modify the risk: technical, organisational and procedural.

ISO 27001 and ISO 27005 give you freedom to use an asset‑based or scenario‑based approach, but these concepts are always present in the background. Both standards outline asset‑based and scenario‑based techniques for identifying and analysing information security risks without prescribing one approach, so you can adopt the method that best fits your organisation while still aligning with the guidance from ISO. Your multi‑tenant register must be able to record and link these elements so you can show auditors how you think about each risk.

Fields every MSP risk record should include

Your risk records need a consistent set of fields so you can compare, aggregate and report across clients without manual clean‑up. If every risk row looks different, you will fight your own data before you can answer basic questions about your portfolio, and auditors may question whether you apply your methodology consistently.

A consistent set of fields makes it easier to compare and report across many tenants. Whether you start in a spreadsheet or a dedicated ISMS platform, a sensible row‑level structure for each risk is:

Risk ID (unique and stable over time).
Tenant (client) identifier.
Service or environment (for example, “Managed Endpoint”, “Azure subscription A”, “Production”, “Test”).
Asset name and type.
Risk description (often phrased as “Threat exploiting Vulnerability on Asset leading to Impact”).
Primary impact area (confidentiality, integrity, availability, or another property you track).
Inherent likelihood and impact (before controls).
Inherent risk score (according to your chosen scale or matrix).
Existing controls.
Treatment decision (reduce, avoid, transfer, accept).
Planned additional controls or actions.
Residual likelihood, impact and score (after treatment).
Risk owner.
Status (open, in treatment, closed, accepted).
Next review date.

In a multi‑tenant context you will also add metadata such as “MSP‑owned risk vs client‑owned risk”, regulatory tags and references to shared components. These fields become the backbone of portfolio reporting and give you the traceability auditors look for when they sample a risk and ask you to justify its rating and treatment.

Make the language usable for non‑specialists

A risk register only works at scale if engineers, account managers and client stakeholders can contribute without getting lost in jargon. If people are unsure how to word risks or score them, they will avoid the process or fill it with inconsistent data, and your carefully designed model will quickly lose credibility.

Most of the people who will contribute to your risk register are not risk specialists. They are engineers, account managers, architects and client stakeholders. If you want consistent, high‑quality data, you need to:

Provide simple definitions and examples for each field in your template or tool.
Use drop‑down lists and scoring guidance rather than free text wherever possible.
Offer example risk statements for common MSP scenarios to copy and adapt.

This is where a platform such as ISMS.online can help by embedding risk templates, scoring scales and field descriptions into the user experience, so your teams do not need to memorise the standard or debate terminology every time they add a risk.

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

ISO 27001 made easy

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

Get started

Designing a multi‑tenant risk data model that actually works

A multi‑tenant risk data model has to give each client a clean, isolated view of “their” risks and give you, as the MSP, a connected portfolio‑wide view of trends, themes and shared exposures. That means going beyond “one register per customer” or simply sticking a “tenant” column onto your existing spreadsheet; you need a structure that lets you slice and philtre confidently, keep tenant isolation and ISO 27001 clarity, and answer both tenant‑specific and portfolio‑wide questions without constant manual work or bespoke reporting every time someone asks a new question.

Before you change your tooling, it can help to compare how single‑tenant and multi‑tenant risk registers behave.

A simple way to see the difference is to contrast the two patterns side by side:

This table shows why a lightly modified single‑tenant register is unlikely to cope with MSP scale and why you need to be more deliberate about your data model.

Use a two‑layer model: templates and instances

Separating global risk templates from tenant‑specific instances lets you keep consistent definitions while tailoring impact and treatment per client. This two‑layer pattern is usually the only sustainable way to manage many tenants without drowning in duplicated risk statements or awkward exceptions, and the most robust pattern is to separate:

Global risk templates: – reusable definitions of common MSP risks.
Tenant risk instances: – per‑client records that reference those templates.

A global template might include:

Template ID and name (for example, “R‑PHISH‑001: Phishing leads to credential theft”).
Description of the scenario.
Typical affected asset types and services.
Recommended controls (security awareness training, email filtering, MFA, login risk monitoring).
Default qualitative likelihood and impact (for a “typical” tenant).
Mapped control themes (for example, ISO 27001 Annex A categories).

Each tenant instance then adds the specific context:

Tenant ID.
Actual assets and user groups affected in that client.
Actual likelihood and impact in that client’s situation.
Actual implemented controls and gaps.
Treatment plan, ownership and review dates.
Residual risk decision (for example, accepted, further reduction planned).

This allows you to maintain consistent wording and mapping for common risks while tailoring impact, likelihood and treatment per tenant.

Decide how you will isolate tenant data

Your risk model has to encode tenant isolation clearly enough that you can explain it to auditors and client security teams without hesitation. That means choosing a storage pattern you can operate safely and documenting how access, encryption and monitoring support it, so you can show not only that risks are identified but also that sensitive information remains segregated.

Once you separate templates from instances, decide how tenant data is isolated and stored. Typical options are:

Separate database or schema per tenant: – strongest isolation, but more operational overhead as you scale. Good when you have strict regulatory or residency constraints, or large, high‑value clients.
Shared database with tenant keys: – a single set of tables where every row includes a tenant ID; isolation is enforced in the application logic and queries. Easier to run at scale, but requires rigorous design and testing.
Hybrid: – for example, shared database for common templates and small tenants, separate schemas for regulated or high‑risk clients.

Whichever you choose, document it clearly and ensure your access controls, encryption and monitoring match the model. Auditors and client security teams will ask how you prevent one customer’s risk data from leaking into another’s view.

Add the right tenant‑aware metadata

Tenant‑aware metadata should make portfolio‑level questions easy to answer without exporting and hand‑joining data. If you cannot answer simple cross‑tenant questions quickly, your model is not yet giving you the value a multi‑tenant approach should provide, and reporting conversations will continue to feel like one‑off projects.

To support both per‑tenant and portfolio reporting, each risk instance should carry, at minimum:

Tenant ID and name.
Tenant sector (for example, healthcare, finance, manufacturing).
Region or regulatory jurisdiction.
Services in scope (for example, “Managed Network”, “Cloud Platform Support”).
Environment (production, staging, test).
Flag indicating whether this is primarily an MSP platform risk, a client environment risk, or shared responsibility.

These fields make it easy to answer questions such as:

“Which of our financial services clients still have high residual risk on privileged access management?”
“How many tenants are still exposed to RMM compromise at a ‘high’ level?”
“Which clients in a particular region have open risks related to data residency?”

A well‑designed ISMS platform will let you philtre and slice by these attributes without exporting and re‑joining data manually, which is particularly important when auditors or large customers ask for portfolio‑wide evidence.

Fields and metadata that keep auditors comfortable

Auditors are most comfortable when they can take any sampled risk and trace it to clear assessments, treatments, controls and evidence. Your fields and metadata should make that journey simple to follow, even in a multi‑tenant environment where responsibility is shared between you and your clients, so that sampling a handful of risks gives a fair picture of how your process actually works.

Core risk fields, revisited for auditors

Imagine an auditor pulling one risk from your register and asking why you rated it that way and what you did about it. If you can answer those questions directly from your register without digging through separate documents or guessing at context, you reduce their concerns and make it much easier to show that your ISO 27001 process is both designed and operating effectively. You can think of each risk as something an auditor might pull out of the register and interrogate step by step, and from their point of view the following questions must be easy to answer for any risk they sample:

What is the risk?: – the risk description must be clear and specific. Make it obvious which asset and impact area are in play.
Why is it rated that way?: – your methodology and criteria for likelihood and impact should be documented and applied consistently; the register should show the chosen ratings.
What are you doing about it?: – the treatment decision, planned actions and owners must be documented, with dates.
What is the residual position?: – if you are accepting residual risk, the rationale should be clear.
How is this linked to controls?: – the risk should be linked to one or more controls in your Statement of Applicability or equivalent.

In practice, an auditor might choose a risk relating to your RMM platform, ask you to walk through the inherent and residual ratings, and then request evidence for the controls you list. If your fields support that conversation, you are on solid ground. You do not need a separate column for every nuance, but you do need to be able to answer these questions from what is recorded.

Multi‑tenant‑specific metadata auditors care about

In a multi‑tenant context, auditors also want to understand how you draw scope boundaries and manage systemic risks in shared platforms. They know that one weak shared control can affect many clients, so they look closely at the way you categorise and assign responsibility for those risks and how you show that the same issue is not being ignored in different places. Concerns about shared controls and single points of failure are a recurring theme in guidance from national cyber security agencies such as the UK’s NCSC, which highlight the need to understand scope boundaries and common dependencies in cloud and managed service environments.

In particular, they look for:

Scope clarity per tenant: – which services and assets are covered by the MSP’s ISMS, and which are out of scope or client‑only?
Responsibility clarity: – for each risk, whether treatment actions sit with you, with the client, or are shared.
Consistent treatment of shared platform risks: – evidence that you are not ignoring systemic issues that affect multiple tenants.
Segregation of duties: – for example, ensuring that the person operating a control is not the only person assessing the associated risk.

Adding explicit fields such as “Responsibility (MSP / client / shared)” and linking risks to your service catalogue and shared platforms helps answer these points without confusion and makes it easier to justify why some actions sit inside your ISMS while others belong in client‑side programmes.

Make the register usable for everyday work

A risk register that only comes out during audits quickly becomes stale and resented; you want something that supports day‑to‑day decision‑making for engineers, managers and account leads. That means linking risk records to tickets, changes and simple views your teams can actually use, so updating the register feels like part of normal work, not a separate administrative task.

Helpful additions include:

Fields for ticket or change references so teams can jump between your risk record and the operational tools where work happens.
Status flags such as “Needs review after incident”, “Pending client decision”, or “On hold awaiting supplier”.
Simple philtres and views for different audiences: management, engineers, account managers, client contacts.

This is where using a dedicated ISMS platform such as ISMS.online, with built‑in philtres, views and linked records, can save you from wrestling with complex spreadsheets or generic tools that are not designed for multi‑tenant risk management.

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

Book your demo

Building a standard MSP risk catalogue without losing client context

A standard MSP risk catalogue is your way of capturing recurring risk scenarios once and reusing them consistently across many tenants. Done well, it gives you shared language and patterns without flattening the specific realities of each client, so you increase efficiency without losing the context that makes individual treatment decisions sensible. Once you can represent risk properly, the next question is how you stop reinventing the wheel for every tenant; a multi‑tenant register should make it easy to reuse patterns while still respecting each client’s specific situation, especially when you balance shared platforms with different business models, geographies or regulatory expectations.

Start with a master MSP risk library

Your master risk library should capture the patterns you see across clients, especially those involving shared platforms, third parties and common attack techniques. Starting from these recurring scenarios gives you a coherent language for risk and stops teams writing near‑identical risks in slightly different words for every tenant, which in turn makes portfolio‑level reporting and improvements much easier.

For each, define a clear risk statement, likely affected services, typical controls and example impacts. These become your master templates in the global catalogue layer described earlier and establish a repeatable language for your teams.

Around 41% of organisations in the 2025 ISMS.online survey said that managing third‑party risk and tracking supplier compliance was a top information‑security challenge.

Begin by listing the common risk scenarios that apply to most of your clients. For example:

Phishing and social engineering leading to credential theft.
Compromise of your RMM or remote access tools.
Failure or misconfiguration of shared backup and recovery services.
Outage or security incident at a key third‑party cloud or SaaS provider.
Inadequate privilege management on shared admin accounts.
Data residency or transfer issues in shared platforms.

Make clear what is standard and what is local

Your catalogue needs to make it obvious which parts of a risk are global definitions and which must be tailored per tenant. If this distinction is vague, you either lose consistency or crush important client‑specific detail, and both outcomes will undermine trust in the catalogue and the reports that rely on it.

For each template, decide which elements are:

Standardised: – for example, the wording of the scenario, the mapped control themes and perhaps a default qualitative risk level for an “average” tenant.
Client‑specific: – for example, the exact assets and systems affected, the real impact on their business, and the actual likelihood given their environment and users.

When you instantiate a template for a tenant, your teams should be free to adjust the local fields while leaving the global definition intact. Your tooling should make that distinction obvious so you do not accidentally overwrite tenant work when you improve the template.

Promote local discoveries into the global catalogue

Over time, new risks will appear in individual clients that actually hint at broader, cross‑tenant patterns. You want a simple, disciplined way to promote those discoveries back into your global risk library so you do not miss emerging themes or allow them to remain hidden in isolated registers.

You will not anticipate every risk in advance. Your teams will discover client‑specific issues, especially in specialised industries or bespoke setups. Some of those will turn out to be variants of existing templates; others will be genuinely new patterns.

Establish simple rules for when to promote something into the global library. For example:

The scenario has been seen, or is likely to be seen, in at least three tenants.
It relates to a shared platform, service or third‑party upon which many clients depend.
It reflects a new regulatory or threat trend that you want to track systematically.

Agree who is responsible for approving these changes, and record the rationale. That way, your catalogue evolves deliberately rather than by accident, and it becomes a strategic asset that feeds into how you develop and harden your shared services.

Putting it into motion: workflows and governance across tenants

A multi‑tenant risk register is not just a database; it only delivers value when it is wired into clear workflows and governance. ISO 27001 expects a cycle of identify, analyse, evaluate, treat and monitor, and you need to translate that into repeatable steps that work across many clients and can be explained to auditors and customers without ambiguity, so your register reflects a living process rather than a static inventory that quickly goes out of date once real life intervenes. That cycle mirrors the risk management process described in ISO 27001 and elaborated in ISO 27005, where organisations are expected to identify, analyse, evaluate, treat and monitor information security risks on an ongoing basis, as set out in documentation from ISO.

Roughly two‑thirds of respondents in the 2025 ISMS.online State of Information Security report said that the speed and volume of regulatory change are making compliance significantly harder to sustain.

Define clear, repeatable workflows

You need a small, well‑defined set of workflows that describe how risks move from identification to closure and who is involved at each stage. If those workflows are vague or change from client to client, your teams will struggle to keep the register current and ISO 27001 will be hard to defend, because you will not be able to show that similar issues are treated in a similar way.

At a minimum, design workflows for:

Step 1 – Risk intake

Define how new risks are identified and logged from assessments, incidents, changes, client conversations and threat intelligence, and make sure teams know which fields to complete.

Step 2 – Assessment and scoring

Set out who evaluates likelihood and impact, which scales they use and how disagreements are resolved, so ratings feel consistent across tenants and over time.

Step 3 – Approval and treatment planning

Describe how risk owners approve assessments and agree treatment options, including clear thresholds for when acceptance is allowed or escalation is required.

Step 4 – Execution and tracking

Show how treatment actions are recorded, prioritised and monitored to completion, ideally linked to your ticketing and change tools so work is visible in both places.

Step 5 – Periodic review

Explain how and when risks are re‑assessed, for example annually, after incidents or when services change, so you can demonstrate that risk is actively monitored.

Each step should specify roles and responsibilities for both your teams and, where relevant, client stakeholders. RACI matrices and simple flow diagrams can help communicate this clearly, and the same pattern can often be applied across many tenants.

Coordinate across many tenants without losing control

You need central coordination that keeps dozens of tenant registers aligned without turning every decision into a bottleneck. The aim is to define rhythms and thresholds so the right work happens at the right level, whether tenant‑specific or portfolio‑wide, and so you can show that systemic issues are managed consistently rather than left to individual accounts.

Because you manage risks for many clients, you need some central coordination:

Use standard review cycles where possible (for example, annual reviews per tenant, with staggered schedules).
Bundle similar activities per tenant (for example, updating all RMM‑related risks after a major platform change).
Establish thresholds that trigger portfolio‑wide actions (for example, “if more than five tenants report high residual risk on X, schedule a platform‑level improvement review”).

As your internal workflows stabilise, you can safely expose more structure to clients, for example by agreeing joint review cycles or co‑authoring treatment plans with higher‑risk tenants.

Involve clients at the right moments

Your process should clearly show when client input is needed on risk decisions, especially where spend, user experience or legal exposure are affected. Getting this right strengthens relationships and supports your role as an ISO 27001‑certified supplier, because clients can see that you take shared responsibilities seriously and are willing to discuss trade‑offs.

Some tenants, especially regulated ones, will want to be directly involved in certain risk decisions. Make sure your process allows for this by including steps for client consultation and approval where needed.

You might, for example, involve clients when:

A treatment plan implies new spend or notable user impact.
The residual risk is being accepted at a level that could affect their legal or contractual obligations.
Cross‑tenant issues require coordinated action across several of their suppliers.

By being explicit about when and how you involve clients, you avoid surprises and support both ISO 27001 expectations and commercial relationships.

Make the process auditable and improvable

Your workflows should generate records and metrics that demonstrate a functioning risk process and highlight where you can improve. If you can show that you regularly review risks, close actions and learn from incidents, audits become much more straightforward and your own leadership gains more confidence in your risk information.

Governance for your multi‑tenant risk process should include:

Documented procedures for each workflow.
Records of who made which decisions, and when.
Metrics such as:

Number of open risks per tenant and per service.
Percentage of risks with current reviews.
Treatment completion rates.
Time from risk identification to treatment approval.

Use these metrics to identify bottlenecks and improvement opportunities. Over time, you should see fewer last‑minute surprises before audits and more predictable, calm risk reviews. A platform such as ISMS.online can support this by linking risks, actions, audit activities and management reviews in a way that auditors and customers can follow.

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

Book your demo

Turning the register into reporting and client value

A multi‑tenant risk register becomes truly strategic when it supports clear reporting for leaders, meaningful client conversations and better product decisions. When you build it well, reporting stops being a painful compliance chore and becomes a source of insight and even commercial value; instead of wrestling with mismatched spreadsheets, you can answer leadership questions quickly, give clients clear risk stories and use portfolio‑level patterns to guide platform improvements and service design.

Design views for different audiences

You should design three core views over your register: one for MSP leadership, one for each tenant and one for internal operations. Each view draws from the same data but presents it in the language and level of detail that audience needs, so nobody has to interpret raw risk records that are full of internal codes and abbreviations.

You will need at least three types of view:

Portfolio view for MSP leadership: – aggregated risk data across tenants, showing:

Top recurring risk themes.
Residual risk distribution by service, platform or region.
Trends over time in risk levels and treatment completion.
Signals for investment (for example, many tenants relying on a weak control pattern).

Tenant‑specific view for clients: – a filtered view showing:

Their own risks, treatments and statuses.
Shared platform risks that affect them, presented in clear language.
Progress over time (for example, the number of “high” risks closed over the last period).

Operational view for your teams: – lists of risks and actions filtered by service, owner or timeframe, designed for day‑to‑day management rather than board‑level storytelling.

Make sure that each view respects tenant isolation and that client‑facing reports do not unintentionally reveal anything about other customers.

Link portfolio insights to MSP strategy

Portfolio‑wide risk data should actively influence how you design, price and develop your managed services. If repeated patterns show that a control is weak, or that a service carries disproportionate risk, those are signals to adjust your platforms and offers rather than just accepting the risk and hoping it does not materialise.

Around one third of organisations in the 2025 ISMS.online State of Information Security report said employees were already using generative‑AI tools without permission or guidance.

For example, if you see many tenants carrying high residual risk around privileged access, that may justify investing in a centralised privilege management solution or additional hardening of your admin tools. Centralising privileged access management and hardening administrative tooling are repeatedly highlighted in best‑practice material from security communities and professional bodies such as the SANS Institute, which treat privileged accounts as a primary target for attackers.

Similarly, if you notice that certain services consistently drive more risk or more treatment effort, you can:

Revisit how those services are designed and delivered.
Adjust pricing to reflect the risk and effort involved.
Use risk reduction as a key outcome when proposing service changes to clients.

Using your risk register as a feedback loop into product and platform decisions strengthens both your security posture and your commercial storey.

Integrate with the tools you already use

Your risk register stays accurate and trusted when it is connected to the tools where your teams already work, such as service desks, asset inventories and monitoring platforms. That way, the register reflects real changes rather than becoming an isolated document that only gets updated before audits or large client renewals.

To keep the register alive and accurate, integrate it with:

Service desk and PSA tools: – so tickets and changes that affect risk (for example, patching, MFA rollout, new projects) can be linked and sometimes even created from risk treatment actions.
Asset management and CMDB: – so the assets referenced in your risks remain in sync as clients add and remove systems.
Monitoring and security tools: – so major incidents and repeated alerts trigger risk reviews rather than being handled entirely outside the risk process.

You do not have to automate everything at once. Start with simple, high‑value connections (for example, linking risk actions to tickets, or pulling asset data from a reliable source), and expand as your teams get comfortable.

Use the register as a value‑add for clients

Your risk register can be a visible part of how you prove value and build trust with clients, not just a behind‑the‑scenes ISO artefact. When you share the right level of information, you demonstrate discipline and create a shared basis for decisions, rather than asking clients to trust platform changes without understanding why they matter.

A well‑structured, multi‑tenant register allows you to:

Provide regular, client‑specific risk reports as part of your service.
Demonstrate your own ISO 27001 discipline as a selling point.
Use risk data to justify service improvements or upsells (for example, advanced monitoring, security awareness training or additional controls) based on documented residual risk.

Done carefully, this is not about scaring clients into buying more. It is about using shared facts to make better decisions together and to support the external attestations that larger customers often require when they assess you as a supplier.

Book a Demo With ISMS.online Today

ISMS.online gives you a practical way to move from scattered, tenant‑by‑tenant risk lists to a single, multi‑tenant ISO 27001 risk backbone that works for your teams, your auditors and your clients. If you recognise the pain of fragmented client risk registers and you are serious about building a portfolio‑wide, ISO 27001‑aligned risk backbone, seeing a live environment built for multi‑tenant MSPs makes it much easier to decide whether a dedicated ISMS platform is the right foundation for your next phase of growth.

Almost all organisations in the 2025 ISMS.online survey listed achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority for the coming years.

What you can see in a demo

A focused demo should show you how a multi‑tenant ISMS platform represents common risks once and then reuses them across many tenants without losing client‑specific detail. It is also your chance to test how well the workflows, access controls and reporting views match the way your MSP actually operates, so you know you are not just buying theory. Vendor and practitioner guidance, including material from ISMS.online, often notes that home‑grown, spreadsheet‑based ISMS tooling can accumulate significant engineering, governance and audit overhead as your obligations and customer expectations grow.

A platform such as ISMS.online can give you:

A structured risk model that already understands assets, controls, treatments and ISO 27001 expectations.
The ability to maintain a global library of common MSP risks and instantiate them per tenant with local context.
Clear segmentation of tenant data, with role‑based access for your teams and for client stakeholders.
Linked workflows for risk assessment, treatment, internal audit and management review, so risk is never just a static spreadsheet.
Reporting views that support both your own certification needs and client‑ready risk summaries.

You could build some of this yourself with spreadsheets and generic tools, but that comes with ongoing engineering, governance and audit overhead. Exploring a platform that has already solved these patterns for many organisations can shortcut a lot of trial and error.

How to decide if a platform is right for you

To decide whether ISMS.online is a good fit, come to the demo with a few concrete scenarios: a complex shared service, a demanding client or a recent audit challenge. Seeing how those cases look in the platform will tell you more than any generic feature list, because it forces the conversation into your real constraints and goals.

If you want to see what a multi‑tenant ISO 27001 risk register looks like in practice, using your own scenarios and questions, you can arrange a short session with the ISMS.online team. You can use that conversation to test the ideas described here against your environment, map out a migration from your current registers and decide whether a dedicated ISMS platform is the right foundation for your next phase of growth.

Book a demo

Frequently Asked Questions

How is a multi‑tenant ISO 27001 risk register different from separate per‑client spreadsheets for an MSP?

A multi‑tenant ISO 27001 risk register gives you one consistent risk backbone across all customers, instead of dozens of fragile, divergent spreadsheets.

Why do per‑client spreadsheets stop working as your MSP grows?

At small scale, a spreadsheet per customer feels manageable. Once you have ten, twenty or fifty tenants, the cracks are hard to ignore:

The same scenario (“RMM compromise”, “backup platform outage”, “identity provider failure”) appears in slightly different words in every file.
Each sheet drifts into its own scoring scales and labels.
Nobody is confident changing anything globally in case they miss a tab and create inconsistencies.

That makes simple portfolio questions painful. “Which customers still have high residual risk on our shared RMM?” can mean hours of manual hunting, copy‑pasting and checking. It also weakens your storey with auditors and boards, because you know some risks are systemic, but your evidence is scattered and hard to compare.

A multi‑tenant risk register shifts you from duplicating logic in every spreadsheet to maintaining a single, joined‑up backbone. You still identify, assess, treat and review risks per tenant, but you do it through one structured view that matches how your managed services actually work.

When you centralise the structure, you can answer portfolio‑wide questions in a few clicks, not a few days, and you give yourself a far stronger foundation for ISO 27001, NIS 2 and similar frameworks.

How does a multi‑tenant risk model actually work in practice?

In a multi‑tenant model, you hold your MSP‑wide risk catalogue once, then create tenant‑specific instances that reference those patterns.

Each instance carries:

A tenant identifier, service and environment.
Local scoring, ownership, treatment choice and review date.
Clear flags for whether the risk is MSP‑owned, client‑owned or shared.

That lets you philtre cleanly per customer while still rolling everything up into portfolio and service‑line views. Shared risks-like privileged access in your RMM platform or resilience of a central backup service-are defined once, updated once and reused everywhere they apply.

An integrated Information Security Management System such as ISMS.online already supports this multi‑tenant pattern. You move away from scattered files into a governed ISMS, without having to design the structures, relationships or access controls yourself.

When is it worth moving away from spreadsheets?

You know it is time to move when:

It takes more than a working day to answer a portfolio‑level risk question for leadership or an important customer.
The same service risk appears in different words and different scores across multiple spreadsheets.
Auditors or key customers start asking how you manage shared risks across your whole platform, not just within their own scope.

At that point, a multi‑tenant ISMS is less about tidiness and more about protecting your margins, your reputation and your ability to talk credibly about risk as you scale.

Which core fields and metadata make a multi‑tenant MSP risk register genuinely auditor‑friendly?

An auditor‑friendly multi‑tenant risk register lets someone pick any risk and see, in a single place, what could happen, why it matters, who owns it and what has been done.

What information should every multi‑tenant risk record carry?

For an MSP, each risk record should consistently answer five questions:

What could happen?
A concise risk description that links a threat, a vulnerability and an impact.
To what?
The tenant, service and asset(s) affected.
Why does it matter?
Impact on confidentiality, integrity and availability, and on any contractual or regulatory commitments.
What are you doing about it?
Existing controls, chosen treatment option and planned actions.
Who owns the outcome?
Named owner(s) on your side and, where relevant, on the client’s side.

In practical terms, that usually means fields for:

Risk ID, tenant ID and tenant name.
Service or environment (for example, “Managed Endpoint – Production”).
Asset details and a standardised risk statement.
Impact areas and inherent likelihood/impact scores.
Existing controls mapped to ISO 27001 Annex A and other frameworks you use.
Treatment option (reduce, avoid, transfer, accept) and target date.
Residual risk rating after treatment.
Risk owner, action owners, status and review date.
Responsibility flag (MSP, client, shared).

If your records follow this pattern, auditors and customers can trace decisions from scenario through to treatment in a few clicks, rather than reverse‑engineering your intent from scattered notes.

How does extra metadata make your MSP register more useful day to day?

Once you have the basics, adding a few well‑chosen metadata fields turns your register into a decision tool instead of a compliance archive. Common examples include:

Tenant sector, size and geography.
Criticality tier (to your business and to the client).
Regulatory profile (for example, “NHS‑connected”, “PCI in scope”, “subject to NIS 2”).

With that in place, questions like “Which regulated UK customers still carry high residual risk on remote access?” or “Which healthcare tenants depend on our legacy backup platform?” become simple philtres, not mini‑projects.

ISMS.online includes an ISO 27001‑aligned schema that already anticipates these needs. You model tenants and services once, add the metadata that matters to your MSP, and then use that structure to answer the questions auditors, customers and your own leadership actually ask you.

How does this structure reduce noise for auditors and your own team?

Clean structure and metadata shorten discussions. Instead of long email chains trying to unpack what a row in a spreadsheet meant, you can:

Walk an auditor from a clause to a control to a concrete risk and the evidence of treatment.
Give engineers filtered worklists focused on the highest residual risks in their service line.
Provide account teams with concise, repeatable views they can share in QBRs.

That shift-from “interpret what this document is trying to say” to “use this data to decide what we do next”-is one of the fastest ways to ease the pressure on both your practitioners and your external reviewers.

How can an MSP standardise common ISO 27001 risks across tenants without losing each client’s context?

You standardise common ISO 27001 risks by defining shared patterns once, then letting each tenant instance carry its own scoring, controls and business context.

What does a reusable MSP risk pattern actually look like?

In a typical MSP portfolio, a large portion of risk comes from repeatable scenarios: phishing, ransomware, abuse of privileged credentials, failure of a shared monitoring or backup service, supplier outages and so on. You rarely want to reinvent the description and control ideas every time.

A reusable pattern in your ISMS usually includes:

A standard risk statement.
Typical services and assets it affects.
Suggested Annex A controls and supporting processes.
Example indicators that show whether the risk is moving up or down.

For each client, you then create an instance of that pattern and:

Link it to their specific assets, identities and data classifications.
Tune likelihood and impact to their use of the service and their regulatory setting.
Capture their actual controls and any gaps.
Agree concrete treatment actions and review cadence.

Think of the pattern as a mould and each tenant instance as a casting shaped by that customer’s reality.

Over time you will spot local risks that crop up repeatedly-particular ways customers integrate identity, expose management interfaces or depend on third‑party remote access. When the same scenario appears across multiple tenants, you can promote it into the master library and stop solving it from scratch.

How do you stay away from “tick‑box” standardisation?

Standardisation only becomes box‑ticking if it hides the differences that really matter. You avoid that by:

Being explicit about which elements are shared and which are mandatory to tailor.
Building checks into your process so a sample of tenant instances is reviewed against live reality, not just the template.
Making room in your catalogue for new patterns discovered by engineers, not just those written at a whiteboard.

Done well, the library gives engineers and account managers a starting point, not a straightjacket. You get the efficiency of common language and control ideas, while still leaving space to reflect each customer’s appetite, architecture and obligations.

An ISMS like ISMS.online is designed around this library‑plus‑instance model, so you can keep your risk catalogue both tidy and grounded in what your managed services really look like today.

How should MSPs design the underlying data model for a multi‑tenant ISO 27001 risk register?

The data model behind your multi‑tenant register should make it impossible to mix tenant data by accident, but easy to see how shared platforms drive risk across your portfolio.

What are the essential building blocks of a secure multi‑tenant model?

Most successful MSP models share a few core components:

Tenants or organisations: – representing each client environment.
Services and assets: – describing what you deliver and what it runs on.
Risk templates and instances: – shared patterns and customer‑specific records.
Controls and evidence: – technical, procedural and organisational measures plus supporting documentation.
Incidents and changes: – events that trigger new risks or re‑assessments.

The relationships between them matter. A single risk instance might link to a shared platform, a specific customer’s use of that platform, the ISO 27001 and NIS 2 controls you rely on, and the last incident that led you to change the score. That chain is what lets you tell a coherent storey when someone challenges how you manage risk in practice.

From a tenancy perspective, MSPs tend to pick one of three patterns:

Isolated databases per tenant with a reporting layer on top.
A shared database where every row carries a tenant key and strict access controls.
A hybrid where high‑sensitivity tenants are isolated and others share infrastructure.

Whichever you choose, you want a model that makes tenant‑level filtering unambiguous and portfolio‑level views safe and accurate.

How can you tell if your current model will stand up to external scrutiny?

A quick, honest test is to check whether you can do the following without manual workarounds:

Pull all risks, controls and evidence for a single tenant without exposing data from anyone else.
Show which tenants are affected if you change a shared template or retire a legacy platform.
Produce a filtered view of records in scope for ISO 27001, NIS 2, DORA or SOC 2 without hand‑editing lists.

If those tasks are awkward or unreliable, auditors and regulators will eventually feel the same discomfort. Moving to an ISMS that was designed for multi‑entity use, such as ISMS.online, means the tenancy, scoping and linkage questions are handled by the platform, and you can focus on making good risk decisions rather than debugging your own schema.

What practical workflows keep a multi‑tenant ISO 27001 risk register current across many MSP clients?

A multi‑tenant register only earns trust if it moves at the same pace as your managed services, not just at the pace of your external audits.

Which recurring workflows matter most for keeping the register alive?

ISO 27001 asks you to identify, assess, treat and monitor risks. For an MSP, the challenge is to turn that cycle into concrete behaviours that fit around customer work. The most effective setups usually nail a few predictable workflows:

Onboarding and change: – new customers and significant changes to services trigger defined risk patterns, not just a check‑the‑box review.
Operational signals: – incidents, vulnerability findings, supplier changes and monitoring alerts create or update linked risks, rather than generating disconnected tickets.
Scoring and calibration: – there is a clear, simple rubric for likelihood and impact so that “high” in a retail tenant looks broadly like “high” in a healthcare tenant.
Treatment and accountability: – decisions to accept, reduce, transfer or avoid risk are recorded with named owners and due dates on both the MSP and client sides.
Review cadence: – periodic reviews are scheduled per risk or per service, with prompts and visibility when they are missed.

You can sketch these flows in playbooks and RACI charts, but the work becomes much easier when the ISMS does the heavy lifting: assigning tasks, sending reminders, linking evidence and surfacing overdue reviews on dashboards.

ISMS.online was built for that style of enforcement. Rather than someone remembering to “update the risk spreadsheet before the auditor arrives”, your team sees risk work alongside tickets, changes and other activities that already shape their day.

How do you keep customers actively involved instead of carrying all risk decisions yourself?

The more you grow, the more dangerous it is to make risk calls on the customer’s behalf without visible agreement. Keeping customers engaged is easier when:

Every risk makes ownership obvious: MSP, client or shared, with names not just roles.
Review sessions use simple visual summaries that highlight the top risks, what changed and what you recommend.
Decisions are framed in business language (“accept this exposure”, “invest in extra control”, “adjust the service”) rather than in security jargon.

When those decisions are recorded in your ISMS, you build a history that protects both sides. If a regulator, auditor or new CISO later asks “Why did we accept this?”, you can show them when it was discussed, what options were presented and who signed it off.

How can MSPs turn a multi‑tenant risk register into reporting that clients actually value?

Clients value your register when it helps them see and steer their exposure, not when it is just a behind‑the‑scenes compliance artefact.

What reporting views usually matter most to MSP stakeholders?

You will usually find three audiences who need different slices of the same underlying truth:

Your own leadership: – cares about cross‑tenant themes, concentration of risk in shared platforms, trends in residual risk by service line and geography, and how this aligns with revenue.
Each customer’s leadership: – wants a clear, business‑friendly view of their top risks, what has changed since last time and where they are relying on you.
Operational teams: – both your engineers and the customer’s IT and security staff, who need tactical lists of open risks, overdue actions and dependencies.

When all three views come from one structured multi‑tenant register, you stop reinventing slide decks for each meeting. You can answer “What are the three biggest portfolio‑wide risks this quarter?” and “Which high risks did we close for this customer since our last review?” using the same data.

ISMS.online adds portfolio dashboards and client‑ready exports on top of the register, so building these views becomes part of your normal rhythm rather than a special‑occasion effort.

How does better risk reporting strengthen your MSP’s commercial position?

Over time, consistent reporting changes how customers perceive you:

Boards and regulators see that you run risk as a system, not as an afterthought before each audit.
Account conversations naturally open the door to service upgrades or additional controls, because residual risks and trends are visible rather than implied.
Prospects comparing providers can see that you are one of the few MSPs offering structured, repeatable insight into risk and compliance instead of ad‑hoc Excel summaries.

For many providers, that evolution-from “we react quickly when something breaks” to “we can show you, in plain language, how secure you are and what to prioritise next”-is what turns an Information Security Management System from an internal cost into a visible part of your value proposition.

If you want your organisation to be recognised as a long‑term security and compliance partner rather than just another support contract, building those reporting behaviours on top of a multi‑tenant risk register is one of the most reliable ways to get there.

How to Build a Multi-Tenant ISO 27001 Risk Register for MSPS