How MSPs Stay ISO 27001 Compliant Using Public Cloud Platforms

The multi‑cloud, multi‑tenant headache for ISO 27001 MSPs

Multi‑cloud, multi‑tenant public cloud makes ISO 27001 compliance harder because shared layers and virtual boundaries increase the blast radius of mistakes. You are running customer workloads across AWS, Azure and Google Cloud while reusing teams, tools and management planes, so one error can affect many tenants at once. To stay compliant, you need your ISMS to describe this reality, treat shared layers as first‑class risks and show how you keep customer environments separated. That expectation aligns with ISO 27001:2022 requirements to understand organisational context, define scope and plan risk treatment and controls in a way that reflects how you actually deliver services, as set out in the standard.

Public cloud can make your services more scalable and profitable, but it also changes your ISO 27001 risk picture in ways that are easy to underestimate. When you manage dozens of customer environments across several platforms, multi‑tenancy, shared tooling and complex data flows create paths for misconfiguration that the older, on‑prem version of your ISMS may never have considered. If your management system still assumes physical separation and bespoke stacks per customer, it will struggle to describe how you actually operate today.

Almost all respondents in the 2025 ISMS.online survey list achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority.

For a managed service provider (MSP), “multi‑tenant” is not just a software term. It describes your whole operating model: many customers share the same underlying cloud platforms, support teams, monitoring stacks and often the same management plane. ISO 27001:2022 expects you to understand those shared layers, treat the associated risks explicitly, and show how you keep one customer’s issues from spilling into another’s. This follows directly from the standard’s emphasis on identifying information security risks arising from your context and processing activities, and selecting and operating controls to treat those risks in a demonstrable way in line with the standard.

Strong cloud assurance starts when you describe reality as it is, not as you wish it were.

Why multi‑tenancy changes your risk profile

Multi‑tenancy changes your risk profile because isolation is now logical rather than physical, and shared components can create wide blast‑radius failures. Instead of relying on separate hardware per customer, you rely on configurations, identities and central platforms, so a single error can break your assumptions about tenant separation. ISO 27001 expects that change to appear clearly in your risk assessments, controls and evidence. That is consistent with ISO 27001:2022’s risk‑based approach, which requires you to analyse how changes in technology and service delivery affect risks, then document the resulting controls and supporting evidence in your risk treatment plan and Statement of Applicability.

In an on‑prem world, you typically had separate hardware, networks and sometimes separate tool stacks per customer. Isolation was mainly physical. In public cloud, isolation is logical and depends heavily on configuration and identity and access management (IAM). That brings three big shifts for ISO 27001:

Tenant boundaries are mostly virtual.
A misconfigured role, security group or storage policy can suddenly span multiple customers. ISO 27001 expects you to analyse this in your risk assessment and design controls that keep it unlikely and detectable.
Shared components become high‑impact assets.
Logging pipelines, backup targets, management networks, monitoring tools and identity providers now serve multiple customers. If one is compromised, the impact can be wide, so these assets must appear in your inventory, risk register and Statement of Applicability.
Responsibility is split three ways.
For each control, you must decide what is handled by the cloud provider, what is owned by you as the MSP and what your customer must do. If that split is unclear, your risk picture is incomplete and your evidence will be challenged by auditors. Industry guidance on cloud shared responsibility models, including community resources such as the OWASP cloud shared responsibility documentation, reinforces the need to assign and document ownership for each activity across provider, MSP and customer so there are no gaps.

If you do not recognise these shifts inside your ISMS, you may still pass an audit once or twice, but you will find it harder to justify decisions if something goes wrong in a shared environment.

Typical weak spots MSPs overlook

Typical weak spots in public‑cloud MSP environments include over‑relying on provider certifications, forgetting shared platforms in the asset list and leaving critical knowledge in peoples heads instead of your ISMS. These gaps undermine otherwise strong ISO 27001 stories and often show up first under audit pressure or during incidents.

Several patterns appear again and again when MSPs move services into public cloud and try to keep ISO 27001:

Assuming the cloud is certified, so we are fine.:

Cloud certifications cover the provider; you still have to configure and operate each customer environment securely.

Not listing shared platforms as assets.:

Treating central logging, management or bastion platforms as generic infrastructure leaves multi‑tenant risks and controls undocumented.

Inconsistent tenant isolation patterns.:

Mixing dedicated and pooled models without standard patterns or rationale makes isolation decisions hard to explain and defend.

Undocumented hero knowledge.:

Relying on a few senior engineers instead of documented roles, processes and diagrams detaches the ISMS from reality.

You do not have to fix all of this at once. A practical first‑quarter goal is to acknowledge multi‑tenant risks in your risk assessment, identify shared platforms as critical assets and document the main tenant patterns you use today.

Book a demo

Reframing cloud as an extension of your ISMS scope

Treating cloud as an extension of your ISMS scope means you stop seeing AWS, Azure and Google Cloud as generic suppliers and start treating them as core parts of your environment. ISO 27001:2022 clauses on context, scope, risk and interested parties make it natural to treat major cloud platforms as sitting inside your system boundary, not just on the edge of it. When your scope reflects that reality, everything else becomes easier to explain and defend.

If your ISMS still reads as if you run one or two data centres with a few SaaS tools, it is probably out of step with your current public‑cloud reality. A clear, cloud‑aware scope sets expectations for auditors, customers and internal teams, and it prevents arguments later about whether a particular service, region or account is “in scope”. Without that clarity, you risk hidden gaps where customer workloads or supporting platforms sit outside your documented system.

Once you treat public cloud as inside your boundary, each account, subscription or project that hosts managed workloads becomes another facility you must understand, document and control. That shift may sound administrative, but it has very practical consequences for how you write policies, track assets, manage suppliers and explain your assurance storey to customers.

Refreshing your scope statement for public cloud

Refreshing your scope statement for public cloud means answering, in plain language, which services, environments and parties are covered by your ISMS. Instead of listing only data centres, you need to name cloud accounts and describe how new environments become in scope. This gives auditors and customers a clear picture of where your responsibilities start and end.

Your scope statement should answer three questions:

Which services are covered?:

For an MSP, that typically includes managed hosting, monitoring, backup, security operations, service desk and any customer portals you host or operate.

Which environments are covered?:

Rather than only named data centres, you should refer to cloud accounts, subscriptions and projects. Where possible, describe how new environments become in scope by default once they meet certain criteria, such as hosting production customer data.

Which parties and locations are relevant?:

This includes your own organisation, customer environments under your management, key suppliers (major cloud providers, core SaaS tools) and, where necessary, geographic considerations like data residency.

A simple way to update your scope is to treat each cloud account, subscription or project that hosts managed customer workloads as an “information processing facility” under ISO 27001. That language helps align scope with the standard and makes it easier to justify why certain controls apply.

Adjusting risk management, assets and suppliers

Adjusting risk management, assets and suppliers for cloud means making your existing ISO 27001 processes speak the language of accounts, regions and managed services. Instead of hiding cloud under generic outsourcing risks, you give it explicit entries in your methodology, inventory and supplier tiers so Clauses 4, 5 and 6 stay grounded in how you really operate.

A strong majority of organisations in the 2025 ISMS.online State of Information Security survey say that the speed and volume of regulatory change are making compliance harder to sustain.

Once cloud appears explicitly in scope, several supporting parts of the ISMS need a refresh:

Risk methodology.:

Cloud‑specific risks such as regional outages, managed service changes, identity federation issues and concentration risk on a single provider should appear as named items, not generic outsourcing risks.

Asset inventory.:

Cloud services, shared management planes, landing zones and configuration baselines should be listed as assets with owners, classification and lifecycle states.

Supplier management.:

Major cloud providers belong in a high‑criticality tier with deeper due diligence and ongoing monitoring, while lower‑risk SaaS tools sit in lighter tiers.

Statement of Applicability.:

Controls that have a cloud dimension, including Annex A 5.23 on the use of cloud services, need explicit notes on how they apply to cloud services and configurations. Organisations that publish mappings between Annex A controls and cloud‑platform configurations, such as technical papers on cloud control mapping from independent bodies like MITRE, highlight the value of spelling out how objectives such as A.5.23 are met in specific services and settings in resources such as cloud control mapping papers. Exact mappings will always depend on your architectures, so treat examples as patterns rather than fixed prescriptions.

In the next quarter, aim to update your scope statement, risk methodology, asset inventory and supplier tiers so they explicitly reflect the cloud platforms you depend on.

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 ISO 27001‑aligned multi‑tenant architectures (AWS, Azure, GCP)

Designing ISO 27001‑aligned multi‑tenant architectures means choosing a small set of patterns that balance security, cost and complexity, then applying them consistently. Instead of letting every team invent its own tenant model, you standardise on pooled, siloed and hybrid approaches you can explain in ISO terms, document them and link them back to risks and controls in your ISMS.

With scope and risk clarified, the next step is to settle on a small number of multi‑tenant patterns that you can defend technically and in front of an auditor. Trying to support every possible structure leads to exceptions, technical debt and audit friction. If you can point to a short list of patterns, explain when you use each and show how they connect back to your risk assessments, your cloud architectures become much easier to justify.

In public cloud, multi‑tenant design is usually a choice between three high‑level models: pooled, siloed and hybrid. The standard does not prescribe a pattern, but it does expect you to make deliberate choices, document them and manage the residual risks. This is consistent with ISO 27001:2022 being technology‑agnostic while requiring you to select and justify controls and treatments based on documented risks and your chosen operating model, as described in the standard.

Comparing pooled, siloed and hybrid models

Comparing pooled, siloed and hybrid models helps you decide which patterns fit which services and risk levels. Pooled designs favour efficiency and logical isolation, siloed designs favour clearer boundaries, and hybrid designs mix shared tooling with segregated data planes. ISO 27001 does not mandate a model, but it does expect you to justify your choice and manage the associated risks.

Here is a simplified view of the trade‑offs you face:

Model	Security & assurance	Cost & operational effort
Pooled	Depends heavily on logical isolation and testing; harder to justify for high‑risk data.	Efficient use of resources; simpler to operate at smaller scales.
Siloed	Clearer isolation boundaries; often easier to explain to auditors and regulators.	Higher cost per tenant; more environments to manage.
Hybrid	Balances isolation for critical elements with shared components for efficiency.	Design and governance complexity increases; needs strong patterns.

Pooled model.:

Many customers share the same infrastructure, application and database, with separation provided by tenant IDs, row‑level security, schemas or namespaces. You must show how access control, testing and monitoring reduce the chance of cross‑tenant exposure.

Siloed model.:

Each customer has its own account, subscription or project, often with its own database and sometimes its own instance of core services. This is attractive for higher‑risk sectors because the isolation is easier to understand. You must still show how you enforce consistent baselines and avoid configuration drift.

Hybrid model.:

Shared control planes and tooling feed into segregated data planes, such as per‑tenant accounts, networks or databases. You must show how you protect and monitor shared components and limit blast radius from shared failures.

Most MSPs end up using a mix: more pooled models for low‑risk, high‑volume services, and siloed or hybrid for high‑assurance offers. The important thing for ISO 27001 is that you define which services use which pattern and why, document the risks and controls for each, and apply patterns consistently.

Using cloud building blocks in an ISO‑friendly way

Using cloud building blocks in an ISO‑friendly way means aligning AWS, Azure and Google Cloud constructs with Annex A control themes such as access control, segregation, logging and supplier management. If you can explain accounts, subscriptions, projects and management groups in that language, you turn potentially confusing cloud terminology into a coherent assurance storey.

Each major cloud has its own terminology and features, but the ISO‑aligned principles are similar:

On AWS, multiple accounts under an organisation with central guardrails give you tenant isolation, while shared tools live in separate management accounts.

On Azure, Entra tenants, management groups and subscriptions provide hierarchy; many MSPs use a subscription‑per‑customer pattern with shared management services.

On Google Cloud, organisations, folders and projects create layers; a project‑per‑tenant model with central logging and shared networking is common.

In all cases, you should codify your chosen patterns in architecture documents, diagrams and infrastructure‑as‑code templates. That way, you can show auditors that your designs were intentional, reviewed, linked back to risk assessments and implemented consistently.

Embedding security into pipelines and documentation

Embedding security into pipelines and documentation turns your multi‑tenant patterns into repeatable, auditable practice. Instead of relying on one‑off configurations, you enforce isolation, logging and tagging in code and leave a clear history of who changed what and why. This directly supports ISO 27001 expectations around change control, operational planning and performance evaluation.

Step 1 – Build guardrails into infrastructure code

Use templates, policies and configuration rules to enforce isolation, encryption, logging and tagging baselines whenever you create a new environment.

Step 2 – Integrate security checks into CI/CD

Automatically scan infrastructure code and cloud configurations for issues that could undermine tenant separation or other key controls before changes reach production.

Step 3 – Capture decisions and threats in documentation

Record why you chose each pattern, which threats you considered and which controls you rely on, using concise decision records and threat models.

As a realistic target for the next quarter, standardise on two or three tenant patterns, capture them in code and diagrams, and link them back to your risk assessments and Annex A controls.

Mapping ISO 27001:2022 Annex A to cloud services and patterns

Mapping ISO 27001:2022 Annex A to cloud services and patterns gives you a shared language between auditors and engineers. Instead of arguing about whether a control “applies”, you point to a simple matrix that shows which AWS, Azure and Google Cloud services, baselines and reports satisfy each objective. This reduces audit friction and makes change management more predictable.

ISO 27001:2022 does not tell you which cloud service to use or how to configure a firewall rule. It defines control objectives and lets you choose the technical means. That is by design: ISO 27001:2022 focuses on the “what” of information security (risk management, control objectives and continual improvement) and remains technology‑neutral so you can decide “how” to implement those objectives in your chosen platforms, as reflected in the standard. In a complex MSP environment, the only practical way to keep this manageable is to build a simple control‑to‑service map that engineers trust and auditors can follow.

This map becomes your bridge between the language auditors use (Annex A controls) and the language your engineers use (cloud services, APIs, configuration baselines). When you maintain it, you also gain a head start on mapping into other frameworks such as SOC 2 or sector‑specific standards.

Building a control‑to‑service matrix

Building a control‑to‑service matrix means identifying which Annex A controls have a strong cloud dimension and then listing the services, configurations and processes you rely on to satisfy them. When you do this once and maintain it, you lower the effort of every future audit and framework mapping exercise.

A useful starting point is to focus on the Annex A themes that change most when you move to public cloud, such as:

Access control and identity.:

Controls around user access, privileged access and authentication map to identity providers, role‑based access control, multi‑factor authentication and access reviews in your cloud platforms.

Logging and monitoring.:

Controls about event logging, monitoring and anomaly detection map to cloud logging services, central SIEM, alerting and runbooks for incident handling.

Backup, recovery and information deletion.:

Controls on backup, restore testing, retention and secure deletion map to snapshot policies, backup tooling, lifecycle rules and data sanitisation procedures.

Supplier and cloud use.:

Controls relating to cloud service use, including Annex A 5.23, map to your process for selecting cloud services, assessing shared responsibility and monitoring provider assurance.

For each control, you then list the cloud services and configurations you rely on.

Step 1 – Pick the cloud‑heavy control themes

Identify Annex A control themes that change most in cloud, such as access control, logging, backup and cloud use, and prioritise them in your matrix.

Step 2 – Link each control to concrete services

For each priority control, record the identity, logging, backup or management services, plus key configurations, that make it effective in AWS, Azure or Google Cloud.

Step 3 – Decide what counts as evidence

Define the screenshots, configuration exports, logs, reports or ISMS records you will use to prove each control is implemented and operating. Exact mappings will vary by MSP, so use this as a guide and adapt it to your architectures.

The goal is not to create a huge spreadsheet. It is to make the relationship between controls and cloud reality explicit, so you can spot gaps and explain the design to auditors.

Aligning baselines, frameworks and evidence

Aligning baselines, frameworks and evidence around your matrix turns it into an everyday tool rather than a one‑off exercise. When you change a standard build, adopt a new framework or prepare for internal audit and management review, you consult the same map instead of starting from scratch.

Once you have a basic matrix, three practical benefits follow:

Technical baselines become easier to justify.
When you update a standard build-for example, to require encryption everywhere-you can quickly see which controls are affected and update your documentation accordingly.
External frameworks overlap more cleanly.
Mapping ISO controls to cloud baselines means one set of technical standards can satisfy multiple frameworks, reducing duplication.
Evidence becomes predictable.
For each control in the matrix, you can define what evidence you will use: configuration exports, screenshots, logs, policy documents, reports from monitoring tools, or outputs from your ISMS platform.

A dedicated ISMS platform such as ISMS.online can help here by giving you a single place to link controls, cloud assets and evidence, instead of spreading this across spreadsheets, diagrams and issue trackers. Over the coming months, aim to build a first‑pass matrix for your most important services and refine it as your architectures evolve.

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

Book your demo

Operationalising the shared responsibility model across clouds

Operationalising the shared responsibility model across clouds means turning provider diagrams into concrete ownership for you and your customers. Instead of vague statements about “securing the cloud”, you maintain clear matrices that show who does what for each service and keep your contracts, procedures and risk assessments aligned to those splits.

Every major cloud provider publishes a shared responsibility model. Major providers such as AWS, Microsoft Azure and Google Cloud all publish their own shared responsibility models, and industry groups like the Cloud Security Alliance discuss how to communicate and implement them in practice in resources such as its blog on communicating cloud shared responsibility. At a high level, they all say the same thing: the provider secures the cloud, you secure what you put in the cloud. When you add MSP services and customer obligations to that picture, the split becomes more complicated-and more important for ISO 27001.

ISO 27017, the cloud security extension to ISO 27001, exists largely to clarify these splits. Cloud security guidance and shared responsibility references, including community work such as the OWASP cloud shared responsibility material, emphasise ISO 27017’s role in clarifying provider–customer responsibilities for cloud services and helping organisations apply ISO 27001 principles in hosted environments. Even if you are not formally certified to it, the concepts are useful for your ISMS and can help you explain your model more clearly to auditors, customers and legal or privacy stakeholders who care about defensible accountability.

Turning shared responsibility diagrams into concrete ownership means recording, for each managed service, which tasks are owned by the provider, which are owned by you and which are owned by the customer. When those allocations are written down and kept in sync with your ISMS, it becomes much easier to answer auditors’ questions about who is responsible for each control.

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

For each major service you offer-managed hosting, security monitoring, backup, identity, endpoint management-you should be able to answer three questions:

What is the cloud provider responsible for?
What are you, as the MSP, responsible for?
What is the customer responsible for?

The most practical way to record this is a simple responsibility matrix (often called a RACI: responsible, accountable, consulted, informed) for each service or service category. This matrix should align with:

Your contracts and service descriptions.
Your internal policies and procedures.
Your risk assessments and treatment plans.
Your control mapping and evidence model.

When auditors see a clear, consistent set of matrices that match your real‑world operations and documents, they gain confidence that you understand and manage shared responsibility.

Embedding shared responsibility into contracts and day‑to‑day work

Embedding shared responsibility into contracts and day‑to‑day work makes RACI charts meaningful. Instead of living in an isolated spreadsheet, the splits show up in legal documents, operational playbooks and training content, so people act in line with what you have promised customers and auditors.

Shared responsibility must be visible in two places:

Customer‑facing commitments.
Contracts, statements of work, service descriptions and information security annexes should reflect who does what and under which conditions.
Internal playbooks and training.
Runbooks, incident procedures, onboarding materials and team briefings need to reference the same splits, so engineers and support teams know which actions are theirs and which are escalated.

Your ISMS is the glue that keeps these two views aligned. When the responsibility model changes-for example, if you start managing more of the customer’s security configuration-your scope, risks, procedures and contracts should change with it.

Over the next quarter, a realistic goal is to build RACIs for your top three cloud services, update the matching contract clauses and brief your teams so they understand the new splits. For privacy and legal officers, this alignment also strengthens your position if a regulator later examines who was responsible for a particular control.

Continuous compliance: governance, monitoring and evidence

Continuous compliance in public cloud means building ISO 27001 governance into the same monitoring, reporting and automation you already use to run your services. Instead of preparing for audits once a year, you design your dashboards, alerts and reviews so they also demonstrate control effectiveness, support internal audits and feed management review.

Public cloud environments change constantly. New services appear, existing ones gain features, customer workloads move and regulations evolve. An ISO 27001 programme that only comes to life before an audit cannot keep up with this pace. For MSPs, the answer is to integrate ISO 27001 governance into the same monitoring, reporting and automation used to run services, so assurance becomes a routine by‑product of good operations.

Continuous compliance is easier when it rides on the systems you already trust for operations.

Designing monitoring that doubles as evidence

Designing monitoring that doubles as evidence means planning your metrics and alerts so they demonstrate control operation as well as keeping services healthy. If your dashboards already show whether backups ran, access was reviewed and incidents were handled to plan, you have less extra work to do for ISO 27001 performance evaluation.

Most organisations in the 2025 ISMS.online State of Information Security survey say they have already been impacted by at least one third-party or vendor-related security incident in the past year.

When you define monitoring requirements, aim to satisfy both operational and ISO objectives:

Map alerts to controls.:

For each key control, ensure there is a corresponding metric or alert; frequent alerts may mean the control is not effective.

Centralise cross‑tenant visibility carefully.:

Use central logging and monitoring to see activity across customers, but restrict access by role to respect isolation and privacy.

Capture context with events.:

Enrich logs with information that matters for audits, such as which policy triggered a remediation or which change request approved a configuration change.

Step 1 – Decide which controls need direct monitoring

Identify access, change, backup and incident‑related controls where metrics or alerts will best demonstrate effectiveness over time.

Step 2 – Design dashboards and alerts around those controls

Configure dashboards and alerts so they show control status, trends and outliers in language your leaders and auditors can understand.

Step 3 – Reuse monitoring outputs in internal audit and review

Feed monitoring reports into internal audits and management reviews so Clause 9 performance evaluation is anchored in live data, not opinion.

If you can show an auditor that your dashboards and reports already answer their questions about control operation, the line between operations and compliance becomes pleasantly thin.

Automation, reporting and triggers for change

Automation, reporting and triggers for change are what keep continuous compliance sustainable across many tenants. Instead of manually checking every environment, you enforce baselines in code, summarise control status for leadership and define clear conditions for revisiting risks and controls.

To keep many tenants aligned with your ISO 27001 commitments, manual checking is not enough. You will need:

Automation to enforce baselines.:

Policy‑as‑code, configuration management and remediation tools keep environments aligned with your standards and record when they correct drift.

Regular governance reports.:

Dashboards and summaries for leadership include control status, exceptions, trends and outstanding risk treatments, feeding Clause 9 and management review.

Clear triggers to revisit controls.:

New cloud services, major architecture changes, recurring alerts or regulatory shifts should all trigger review of your risk assessments and controls.

A platform like ISMS.online can help you connect these operational signals to the ISMS itself-linking risks, controls, actions and evidence-so the management system truly reflects what is happening in the cloud. In the coming months, aim to identify a handful of high‑impact controls, wire them into your monitoring and automation, and ensure the resulting reports flow into your internal audit and management review cycles. For IT and security practitioners, this reduces painful manual checks and turns good engineering work into visible compliance outcomes.

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

Book your demo

Turning “ISO in the cloud” into a commercial advantage

Turning “ISO in the cloud” into a commercial advantage means treating your cloud‑aware ISMS as part of your offer, not just a compliance badge. Instead of hiding your practices behind a certificate, you package isolation options, assurance artefacts and responsive governance as features that reduce customer effort and build trust.

Many MSPs treat ISO 27001 as a necessary badge for tenders. In a modern public‑cloud practice, it can be more than that: it can become a way to differentiate your services, reduce sales friction and build long‑term trust. Industry material on using ISO 27001 and cloud security in RFPs and marketing, including guidance from large vendors such as IBM on positioning certifications in enterprise buying cycles, often assumes this “badge for tenders” baseline and then shows how to go beyond it, as in resources like IBM’s guidance on security attestations in RFPs. When your ISMS describes multi‑tenant reality clearly, you can reuse that work to answer prospect questions more quickly and with greater credibility.

Customers, especially in regulated sectors, increasingly want to know how you secure their workloads in cloud, not just whether you have a certificate. This matches what many cloud security and marketing guides report: buyers, particularly in regulated industries, increasingly expect detailed explanations of how workloads are secured, not just a list of certificates, as reflected in vendor guidance on cloud‑security marketing best practices from providers such as Oracle’s cloud security marketing best practices. If you can turn your ISO‑aligned cloud practices into clear service options and reusable evidence, you make it easier for them to choose you and justify that choice internally.

Packaging assurance as features, not just certificates

Packaging assurance as features means explaining how you secure workloads in cloud, not only that you have ISO 27001. When you present isolation tiers, evidence packs and clear responsibility splits as part of your services, you make your sales and customer‑success teams’ jobs easier.

The 2025 ISMS.online survey reports that customers increasingly expect suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 and emerging AI standards.

You can use your ISO‑aligned cloud practices to:

Offer clear service tiers that tie tenant isolation and assurance levels to documented ISO‑aligned controls.

Provide standard evidence packs customers can reuse in their own audits, including matrices, mappings, logs and summary risk views.

Shorten procurement cycles by presenting a coherent, pre‑packaged storey about how your ISMS covers public cloud in language security teams recognise.

For founders and commercial leaders, these elements turn security from an objection into a reason to buy. For CISOs and privacy officers on the customer side, they provide enough depth to trust your approaches without needing to reverse‑engineer them. For your own practitioners, they validate the engineering effort that went into your architectures and controls.

The work you have done to document scope, patterns, control mappings and monitoring can be selectively reused in sales material and customer communications, as long as you keep it accurate and focused on helping customers meet their own assurance obligations.

Measuring and communicating the commercial impact

Measuring and communicating the commercial impact of your ISO‑aligned cloud practice helps reposition compliance as a revenue enabler. When you can point to faster questionnaires, higher win rates and renewals citing security as a reason to stay, your investment in the ISMS is much easier to defend.

If you want ISO 27001 to be seen as a revenue enabler rather than a cost, it helps to track a few simple metrics:

Win rate in regulated or security‑sensitive sectors.

Time from security questionnaire to contract signature.

Deals lost on security or compliance grounds.

Retention where security and compliance are key renewal reasons.

Step 1 – Choose a small set of commercial security KPIs

Select two or three metrics, such as questionnaire turnaround time or win rate in regulated sectors, that are clearly influenced by your assurance storey.

Step 2 – Capture and review those metrics regularly

Build simple reports that show trends over time and discuss them in commercial and leadership meetings, alongside traditional sales metrics.

Step 3 – Feed insights back into your ISMS and offers

If you see better outcomes when you provide richer assurance packs or stronger isolation options, reflect that in your services and in your ISMS documentation.

You can also coach your account and customer success teams to talk about ongoing security value: regular control reviews, evidence packs, roadmap briefings and responses to new threats or regulatory changes. That keeps ISO 27001 present in renewal conversations without turning them into audit meetings.

Book a Demo With ISMS.online Today

ISMS.online helps you run a single, cloud‑aware ISO 27001 management system that keeps pace with how your MSP actually uses AWS, Azure and Google Cloud. Instead of juggling spreadsheets, diagrams and ad‑hoc evidence folders, you can bring risks, controls, shared responsibility matrices and cloud‑specific documentation into one place and connect them to the day‑to‑day work your teams are already doing.

For MSP founders and leaders, that means a clearer view of how your AWS, Azure and Google Cloud practices relate to ISO 27001:2022, and more confidence that your certification reflects what actually happens in your environments. For compliance managers, it provides structured support for updating scope, risk assessments, Annex A mappings and evidence as your cloud footprint grows, including cloud‑focused controls such as those covering the use of cloud services. For service leads, architects, and security practitioners, it offers practical ways to link reference architectures, change workflows and monitoring outputs back into the ISMS without creating a separate layer of paperwork.

If you are serious about using public cloud platforms while staying ISO 27001 compliant-and about turning that capability into a tangible advantage for your customers-booking a short demonstration of ISMS.online is a simple next step. You will see how your existing cloud architectures and processes can be translated into a living, audit‑ready ISMS that scales with your managed services business and reduces the strain on your team.

This information is general in nature and does not constitute legal, certification or audit advice; you should always consult a qualified professional or certification body for decisions that affect your obligations.

Frequently Asked Questions

How does moving MSP customers into public cloud really change your ISO 27001 compliance?

Moving customers into AWS, Azure or Google Cloud alters your ISO 27001 compliance because your scope, risks and controls shift from physical kit to cloud platforms, accounts and automation, and your ISMS has to capture that shift or it stops reflecting how you actually run services.

Which ISMS elements should you update first for public cloud?

There are three places most ISO 27001‑certified MSPs should revisit before anything else:

Scope and context:

Your scope statement should explicitly name the cloud providers, core accounts/subscriptions, regions and shared management planes (for example, central logging, security tooling, CI/CD, identity). That tells an auditor exactly where your ISO 27001 boundaries now sit and which platforms underpin your managed services.

Asset inventory and classification:

Physical servers turn into cloud accounts, projects, services, pipelines and configurations. Landing zones, tenant baselines, management subscriptions, shared monitoring stacks and automation should be treated as information assets, with the data they process clearly classified. This helps you show exactly where customer information lives in AWS, Azure or Google Cloud.

Risk assessment and treatment:

Physical threats decline in relevance; cloud‑centric risks rise. Misconfiguration, overly broad roles, exposed management interfaces, weak API controls, insecure automation and provider region outages should be visible in your risk register, with treatments mapped to Annex A controls such as A.5.23 (use of cloud services) and the network controls in A.8.20–A.8.22.

If your ISMS still reads like an on‑premises operation while your customers live in public cloud, an auditor will question whether your risk picture and control set are still valid.

How does public cloud change what “control” looks like in practice?

In public cloud, a lot of control is expressed through patterns and automation, not just documents:

Access control appears in identity providers, roles, policies, conditional access and privileged‑access workflows.
Network segregation shows up in VPCs/VNets, security groups, NSGs, firewalls, private endpoints and peering rules.
Backup, monitoring and incident handling rely on native services wired together via infrastructure‑as‑code, serverless functions and runbooks.

For an ISO 27001‑certified MSP, the test is whether those levers are:

Standardised: into patterns and baselines, rather than unique per project.
Owned: through clear responsibilities between provider, you and the customer.
Governed: by your ISMS (change, testing, review), not left as “whatever the cloud team prefers”.

When those cloud realities are reflected in a structured ISMS platform such as ISMS.online-with updated scope, risks, controls and evidence-you can reassure auditors that your certification still matches the way you actually operate.

How should an MSP design multi‑tenant cloud architectures that still work for ISO 27001?

You keep ISO 27001 on your side by limiting yourself to a small number of multi‑tenant patterns, tying each to risks and Annex A controls, and applying them consistently instead of inventing a bespoke design for every new customer or workload.

Which multi‑tenant patterns tend to work well for ISO 27001 in AWS, Azure and Google Cloud?

Most MSPs converge on two or three standard models and treat anything else as an exception that needs stronger justification:

Pooled tenancy for lower‑risk services:

Multiple customers share underlying infrastructure (for example, shared Kubernetes clusters or multi‑tenant SaaS), with isolation enforced by IDs, schemas, namespaces and authorisation. To keep this ISO‑friendly you should spell out:

How tenant data is separated (network segmentation, database controls, per‑tenant keys).
How isolation is tested and monitored (automated checks, simulated attacks, logging).
How you contain a noisy or compromised tenant (rate limits, throttling, safe suspension).

Dedicated account/subscription/project per tenant for higher‑assurance services:

Each customer has its own account, subscription or project, connected to shared landing zones and management tooling. This aligns naturally with Annex A expectations for segregation, but increases the number of environments you must keep aligned with your baselines.

Shared control plane with segregated data planes:

A central control plane (CI/CD, logging, security tooling) serves separate data planes where customer workloads and data live. This can give you operational efficiency while preserving clear data‑isolation boundaries.

What matters most is that you can show:

A documented reference architecture for each pattern, with diagrams and infrastructure‑as‑code examples.
A trace from each pattern into your risk register and Annex A controls (for example, A.8.20–A.8.22 for network security and segregation).
Change and test processes that ensure every new tenant follows a known pattern rather than “whatever an engineer did under pressure”.

When those architectures and controls live inside your ISMS and your teams work from the same designs, you can explain multi‑tenancy to auditors and buyers without screen‑sharing raw cloud consoles.

How do you explain your multi‑tenant model so auditors and customers trust it?

Both audiences want to see a clean route from risk → design → configuration → evidence. A simple narrative works well:

Risk: “Cross‑tenant data access in a shared platform.”
Design: “Pooled‑cluster pattern with per‑tenant namespaces, network policies and tenant‑scoped encryption keys.”
Configuration: “Baseline templates and guardrails we apply via Terraform or deployment pipelines.”
Evidence: “Test results, isolation checks, logs and incidents that show the controls working over time.”

Putting that chain into your ISMS, with supporting diagrams and baselines, lets you guide an auditor or prospect through your model in a calm, repeatable way. ISMS.online helps you keep those risks, architectures and controls in one place so each new environment strengthens your storey instead of adding confusion.

How can an MSP map ISO 27001:2022 Annex A controls to AWS, Azure and Google Cloud services?

You make Annex A usable in AWS, Azure and Google Cloud by translating each control theme into specific services, baseline configurations and supporting processes, and recording that in a control‑to‑service mapping your engineers and auditors can both follow.

What does a practical control‑to‑service mapping look like?

A simple, expandable matrix might look like this:

Annex A focus area	Cloud services in scope	Baseline configuration & processes
Access control (A.5, A.8.x family)	IAM, Azure AD, Cloud IAM, PIM/PAM	Standard roles, MFA, just‑in‑time elevation
Logging & monitoring (A.8.15–A.8.16)	CloudTrail, Defender, Cloud Logging, SIEM	Centralisation, alert routing, on‑call duties
Backup & recovery (A.8.13–A.8.14)	Snapshots, backup vaults, cross‑region copies	Schedules, retention, restore tests
Use of cloud services (A.5.23)	Provider catalogues, service onboarding flow	Supplier review, risk sign‑off, exit planning

For each row you define:

Which services: you use for that theme in each platform.
The baseline settings you expect (encryption, retention, private access, logging, MFA).
The evidence you can produce (IaC, reports, tickets, logs, screenshots if needed).

You then map each row back to specific Annex A controls and mark whether a control is:

Handled by the provider: (data‑centre physical security, core infrastructure).
Implemented and monitored by you: (configuration, monitoring, response).
Dependent on the customer: (application‑layer security, some data‑handling decisions).

That mapping becomes a shared reference between security, engineering and audit teams, and a foundation you can build on as your cloud footprint grows.

Why is this mapping useful beyond ISO 27001 certification?

Once you have a good control‑to‑service mapping, you can reuse it in several ways:

Extend it to cover SOC 2, NIS 2, DORA or ISO 27701, rather than designing new matrices from scratch.
Speed up responses to security questionnaires and RFPs because you already know which patterns and services satisfy common requirements.
Give your teams a single source of truth for how AWS, Azure and Google Cloud must be configured and operated to stay inside your ISMS.

Keeping that mapping in an integrated ISMS platform such as ISMS.online-alongside risks, policies, SoAs and internal audits-means every change to cloud services or patterns automatically feeds into your assurance storey instead of disappearing into a forgotten spreadsheet.

What does shared responsibility really mean for an ISO 27001‑certified MSP in public cloud?

For an ISO 27001‑certified MSP, shared responsibility in public cloud means you have explicitly decided, documented and agreed who does what for each major control area, and that picture is consistent across your ISMS, contracts, service descriptions and runbooks.

How can you turn shared responsibility from a slide into something auditable?

A straightforward way is to maintain a responsibility matrix per service, usually using RACI:

Responsible: who carries out the work (for example, configuring tenants, running backups, tuning alerts).
Accountable: who owns the risk and outcome (you, the customer or sometimes both).
Consulted: who provides input (customer security, legal, data owners).
Informed: who needs updates (account managers, customer stakeholders).

Apply that matrix across control themes such as:

Tenant, platform and network security.
Identity and access management.
Backup, recovery and resilience testing.
Logging, monitoring and alert handling.
Compliance reporting and customer‑facing assurance.

Each matrix should align with:

Contracts and statements of work: , so scope and assumptions are explicit.
Internal runbooks and diagrams, so engineers follow the same split of work.
Risks and controls: in your ISMS, including where you rely on customers to act.

When you adjust a service-for example, you take on more application‑layer security or the customer assumes more operational control-update the matrix, revise your documentation and bring that change through internal audits. That history gives you a defensible position in the event of an incident or dispute.

How can ISO 27017 strengthen your shared‑responsibility model?

ISO 27017 offers cloud‑specific security guidance to sit alongside ISO 27001 and ISO 27002. If you use it to shape your shared‑responsibility model, you can:

Show auditors and customers that your split of duties follows published good practice, not just a house view.
Clarify grey areas such as who configures virtual firewalls, who manages encryption keys, and who hardens virtual machines, containers or serverless functions.
Reduce friction at onboarding by presenting a standardised responsibility model that aligns with ISO guidance.

Referencing ISO 27017 in your ISMS and customer‑facing material turns shared responsibility from a marketing diagram into something that stands up in ISO 27001 audits and regulator conversations. ISMS.online helps you keep those responsibility models, risk registers and control mappings in sync as your cloud services evolve.

How can MSPs generate convincing ISO 27001 audit evidence when workloads run in public cloud?

You generate convincing ISO 27001 evidence in public cloud by showing that your management system fully incorporates cloud and that your cloud platforms are operated consistently with that system across tenants, regions and services.

Which ISMS artefacts should clearly show your use of AWS, Azure and Google Cloud?

On the management‑system side, auditors will look for cloud to appear explicitly in:

Your scope statement and context, including reliance on specific providers and shared management platforms.
Risk assessments: and treatment plans that highlight cloud‑specific issues such as misconfiguration, identity sprawl, region failures and supply‑chain dependencies.
The Statement of Applicability, especially where controls are implemented by providers or shared with customers.
Internal audit schedules and reports: that cover cloud governance activities like landing‑zone reviews, access reviews and configuration drift checks.
Management review inputs and outputs: where cloud incidents, changes and performance metrics are discussed and decisions recorded.

These artefacts demonstrate that cloud is part of your normal Plan‑Do‑Check‑Act cycle, not something handled informally outside the ISMS.

What cloud‑level evidence tends to reassure ISO 27001 auditors?

On the technical side, auditors usually want a mix of configuration, monitoring and operational records that tie back to your controls, for example:

Access review records: for landing zones, tenant environments and management tools, including how privileged access is approved and removed.
Configuration baselines and drift reports: (for example, IaC templates, policy packages, configuration‑compliance dashboards) showing how you detect and correct misconfigurations.
Backup and recovery evidence: such as backup schedules, job reports, restore‑test logs and how failed jobs were handled.
Logging and monitoring outputs: , including SIEM dashboards, sample alerts, tuning records and example incident timelines.
Change and incident tickets: that show how real events moved through your change control and incident‑management workflows.

Pulling this material into a structured environment-rather than chasing screenshots across different consoles-saves time and makes your storey more consistent. ISMS.online helps you connect each piece of evidence to the relevant risk, control and service so you can reuse it for both audits and customer assurance packs without rebuilding everything from scratch.

How can an MSP turn cloud‑aware ISO 27001 compliance into a commercial advantage?

You turn cloud‑aware ISO 27001 compliance into a commercial advantage by designing and describing your managed services so customers can feel that you lower their security and compliance workload in public cloud, rather than leaving them to piece everything together.

How can you package public‑cloud services so your ISO 27001 strengths are obvious?

A practical approach is to define a few named service tiers that tie architecture, assurance and price together:

Each tier couples a tenant‑isolation model (pooled, hybrid, dedicated) with:

Defined monitoring and reporting depth.
Agreed frequency of access reviews and restore tests.
Clear incident‑response commitments and communication patterns.

You then back each tier with:

A standard responsibility matrix for that tier so customers see exactly what you cover and what stays with them.
A matching control and evidence pack, listing which Annex A themes you handle and what artefacts customers can expect during due diligence.
Reusable RFP and questionnaire content, so your teams are not rewriting security answers for every prospect.

From there you can track:

Win rates where buyers asked explicitly about ISO 27001 or public‑cloud security.
Time from first security questionnaire to contract signature.
Renewal and expansion reasons that mention security, compliance or peace of mind.

Those data points help you prove internally that a cloud‑aware ISMS is not just a cost of doing business; it actively supports growth with the right customers.

How can an ISMS platform make that commercial storey easier to tell?

When risks, controls, responsibilities and evidence are scattered across teams and tools, it is hard to answer simple buyer questions like “How do you keep my data secure in AWS or Azure?” with confidence. A dedicated ISMS platform such as ISMS.online helps you:

Bring your ISO 27001 controls, multi‑cloud architectures and Annex A 5.23 expectations into one structured system that reflects how you really operate.
Keep shared‑responsibility matrices, risk treatments and control mappings up to date as your services, regions and cloud features change.
Generate consistent, auditor‑friendly outputs-scope statements, Statements of Applicability, audit reports and customer assurance packs-without rebuilding them every time a new opportunity appears.

If you want prospects and existing customers to experience you as the MSP that takes public‑cloud compliance off their shoulders, it is worth exploring how an integrated ISMS platform can connect your AWS, Azure and Google Cloud designs to your ISO 27001 commitments and the assurances buyers now expect as standard.

How MSPS Can Use Public Cloud Platforms While Staying ISO 27001 Compliant