A.5.23 Cloud Security: Shared Responsibility for MSPs Under ISO 27001

Why MSP Cloud Security Broke Overnight

MSP cloud security “broke” when cloud platforms stopped being simple suppliers and became shared‑responsibility environments that you must actively govern. ISO 27001 A.5.23 makes that shift explicit by expecting you to control how you select, use and exit cloud services in line with your ISMS, instead of relying on provider certificates alone. That expectation reflects the wording of ISO 27001:2022 A.5.23 and mainstream cloud security guidance, which emphasise defined processes for the acquisition, use, management and exit of cloud services rather than reliance on provider assurances alone, as highlighted in commentary on ISO 27001 A.5.23 guidance.

Cloud services let your MSP grow fast, but they also exposed gaps in ownership, governance and evidence that the old supplier model never had to solve. When customers and auditors now ask who is responsible for what in the cloud, “the provider does that” is no longer enough. A.5.23 crystallises this tension by expecting a controlled, documented approach to cloud use instead of ad‑hoc platform choices.

Cloud only becomes an advantage for MSPs when responsibility is shared deliberately, not assumed.

Cloud has outgrown your old “supplier” mindset

Cloud has outgrown the idea that you can sign a contract, trust a certificate and assume security stops at the provider’s edge. For MSPs, A.5.23 forces you to recognise that identities, configurations and day‑to‑day operations on each platform now sit firmly within your responsibilities.

Many MSPs still treat cloud providers like traditional suppliers, and that is exactly where A.5.23 starts to fail. For years, you could sign a contract, trust certifications, bolt some monitoring on top and carry on. That worked when cloud was just email hosting or a few virtual machines.

Today, entire service catalogues run on hyperscale platforms, with your engineers holding powerful admin roles and automation tools touching dozens of tenants at once. In that environment, “the supplier manages security” stops being true. The cloud provider secures its infrastructure and core services, but you decide identities, configurations, integrations and much of the operational resilience. Customers increasingly understand this and expect you to show how shared responsibilities are defined and how your team runs those controls day to day.

A.5.23 is the point where the standard explicitly calls out that shift. It expects you to move from generic supplier assurance to active governance of how cloud platforms support your services and your customers.

The hidden complexity of your current cloud stack

The hidden complexity of your cloud stack only becomes obvious when you write it down. A short, focused inventory usually reveals far more services, data flows and admin roles than you expected, which is exactly what A.5.23 wants you to see and then manage deliberately.

Most MSPs discover that they are running far more services, in far more ways, than anyone realised:

Internal SaaS tools for collaboration, ticketing, CRM and finance.
Public cloud platforms powering managed infrastructure, backup, monitoring and security services.
Niche cloud tools chosen by individual teams or engineers to solve specific problems.

Taken together, these services create a web of data locations, admin roles, logs and failure modes. Without a central view, risks accumulate quietly: one engineer holds global admin across multiple tenants, a “temporary” SaaS tool becomes business‑critical, a backup service has never been tested for real restoration scenarios. An ISMS platform such as ISMS.online can help you maintain that central view so the complexity does not stay hidden.

To make the shift concrete, it helps to compare the old supplier mindset with the cloud governance A.5.23 expects.

A short comparison shows how your approach must change:

Aspect	Old supplier model	A.5.23 cloud governance for MSPs
View of provider	“Trusted vendor handles security.”	“Partner in a defined shared responsibility model.”
Scope of control	Contract plus basic monitoring	Full lifecycle: selection, use, change, exit
Evidence you hold	Certificates and contracts	Registers, risk records, matrices, lifecycle artefacts
Ownership inside the MSP	Implicit, person‑dependent	Explicit roles, runbooks and ISMS integration

Once you see your situation through this lens, it becomes easier to decide where you need structure rather than more ad‑hoc fixes.

Where customers and auditors are exposing the cracks

Customers and auditors are exposing the cracks in your cloud storey by asking clear questions about services, data and responsibilities. Their questions often highlight gaps in ownership, lifecycle and evidence long before a breach or outage does. Managing third‑party risk and tracking supplier compliance was cited as a top challenge by 41% of organisations in the 2025 ISMS.online survey.

Typical questions include:

Which cloud services do you use on our behalf, and where is our data stored?
Who is responsible for backup, identity, logging and configuration in each platform?
How do you vet, monitor and, if necessary, exit cloud providers?
How will you support us if we want to move away from a given service?

These questions reveal where your current approach is vague. If your answers depend on who is in the meeting, or require someone to go and check, A.5.23 is already a problem. The control expects you to have processes for acquiring, using, managing and exiting cloud services in line with defined security requirements. For an MSP, that means moving from an improvised cloud storey to a structured one that auditors and customers can test.

This is where having a live register of cloud services, linked to risks, responsibilities and lifecycle records, becomes essential rather than nice to have.

Book a demo

What ISO 27001 A.5.23 Really Asks of You

ISO 27001 A.5.23 asks you to treat cloud as a governed service landscape with clear rules, responsibilities and evidence, not as a loose collection of tools and providers. In practice, that means being able to show how cloud services are selected, controlled and retired in line with your information security requirements.

The 2025 State of Information Security report notes that customers most commonly expect suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 and emerging AI standards.

In the 2022 edition, A.5.23 states that you should establish and implement processes for the acquisition, use, management and exit of cloud services, consistent with your information security requirements. That formulation is consistent with the published control text in ISO 27001:2022 A.5.23 and with supporting cloud guidance such as ISO 27017 and ISO 27018, which all stress end‑to‑end governance of cloud services rather than one‑off supplier checks. A central ISMS platform such as ISMS.online can make that work manageable by holding policies, risks, responsibilities and records in one place.

Auditors typically look for a clear line from that control text through to actual policies, procedures and records. If you can explain in your own words what A.5.23 means for your business, you are already ahead of many MSPs that rely solely on the formal wording.

From one sentence to practical objectives

Turning A.5.23 into practical objectives means breaking the formal wording into a small set of concrete, testable expectations that you can design controls and evidence around. These objectives give you a framework for explaining the control to your team and to auditors. Interpretations from cloud‑focused ISO 27001 practitioners commonly group A.5.23 requirements into themes such as cloud policy, risk and requirements, shared responsibility, lifecycle and evidence, which is the approach reflected here.

In practice, A.5.23 expects you to do five things consistently and be able to prove them. A useful way to interpret the control is to break it into five practical objectives:

Cloud policy and scope – define what “cloud” means for your organisation, which services and data are in scope, and who can adopt new services.
Risk and requirements – identify cloud‑specific risks such as multi‑tenancy, data location and connectivity, and set minimum security and privacy requirements.
Shared responsibility – document who is responsible for key controls across provider, MSP and customer for each major platform and service.
Lifecycle management – build security into selection, onboarding, change, monitoring and exit for cloud services, not just into contracts.
Evidence and improvement – keep records that show these processes are working and review them as platforms, customers and regulations change.

Together, these objectives turn A.5.23 from a single sentence into a set of habits. They also give you a structure for mapping the control into your Statement of Applicability and your wider ISMS. Recording the objectives, owners and supporting evidence in a system such as ISMS.online helps you keep them consistent as services and standards evolve.

How A.5.23 extends the older supplier model

A.5.23 extends the older supplier model by recognising that cloud is a technical foundation, not just another outsourcing contract. When your services depend on shared platforms, your configuration, access and operations choices strongly influence security outcomes, even if the underlying infrastructure belongs to someone else.

Compared with generic supplier controls in domains such as supplier management and operations security, A.5.23:

Emphasises the cloud service lifecycle, not just supplier selection.
Expects explicit consideration of shared responsibility and multi‑tenancy.
Focuses on how you will exit or replace cloud services without losing control of data.

These emphases are echoed in specialist A.5.23 commentaries and cloud control mappings, which highlight lifecycle, shared responsibility and exit planning as distinct from traditional supplier oversight. For MSPs, A.5.23 also sits alongside access control, asset management, incident management and other Annex A controls. The aim is not to duplicate work, but to make sure your existing controls fully account for cloud and the way you deliver services.

Linking this control clearly to your ISMS helps auditors see that cloud governance is integrated, not treated as a separate track.

Document types auditors expect to see

Document types that auditors expect to see for A.5.23 are those that prove your cloud policies, processes and responsibilities are real, consistent and applied. They will look for a small, coherent set of artefacts rather than a large volume of loosely related documents. Cloud governance implementation guides for A.5.23 frequently point to a combination of policies, service registers, risk assessments and lifecycle records as the core evidence set that auditors expect.

During an audit, you are likely to be asked for evidence such as:

A cloud use or cloud security policy.
A register of cloud services used internally and on behalf of customers.
Cloud‑specific risk assessments and treatment plans.
Due diligence records for key cloud providers and sub‑processors.
Shared responsibility matrices or equivalent role definitions.
Procedures or playbooks for onboarding and exiting services.
Samples of logs, reviews or tickets showing these processes operating.

If you can locate these quickly, and they tell a consistent storey, A.5.23 will feel controlled and proportionate. If they exist only in scattered documents or people’s heads, the control becomes a source of findings and extra work. Using an ISMS platform such as ISMS.online to hold these artefacts in one place makes it far easier to show how cloud is managed in practice.

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

The MSP’s Double Life: Cloud Customer and Provider

Your MSP has a double life under A.5.23: you are both a demanding cloud customer of upstream providers and an accountable cloud provider to your own clients. The control expects you to understand, document and govern both roles, including how they interact across the shared responsibility chain.

As a cloud customer, you rely on hyperscale platforms and SaaS tools to run your own business and deliver services. As a cloud provider, your customers see you as the party responsible for security, continuity and support, even when the underlying technology belongs to someone else. A.5.23 brings those two perspectives together and asks you to manage them coherently.

Understanding your upstream and downstream roles

Understanding your upstream and downstream roles means recognising that you consume cloud services as an internal customer while also selling cloud‑based services as a provider to your own clients. A.5.23 expects you to keep both perspectives in view and to ensure they support, rather than contradict, each other.

As a cloud customer, you consume services such as productivity suites, ticketing, monitoring platforms and public cloud infrastructure. You are responsible for how those services are configured, who has access and how they are monitored. When incidents occur or regulators ask questions, your ability to show control depends on how well you manage that consumption and how clearly it is linked into your ISMS processes, such as risk assessment and change management.

As a cloud provider or manager, you design, deliver and support services that run on these platforms. You may be selling managed infrastructure, backup, SOC, application hosting or security services. Your customers see you as the accountable party, even when you build on a third‑party cloud. They do not distinguish between your service and the hyperscaler it runs on; they assume you have taken care of the details.

A common misalignment appears when you make commitments to customers about log retention or backup history, but an upstream tool is still running on its default, much shorter setting. In that case, your downstream commitment has outpaced your upstream configuration, and A.5.23 will expose that gap.

Building a dual‑role responsibility view

Building a dual‑role responsibility view means mapping responsibilities across providers, your MSP teams and customers in a single, coherent model. This gives your CISO, head of service delivery and account managers a shared picture of who owns what across the whole chain.

A practical way to do this is to create a dual‑role responsibility matrix. Across key control areas – identity and access management, configuration, logging, backup, incident response, change control, data protection – you list:

What your upstream providers commit to.
What you, as the MSP, commit to upstream (for example, enabling certain features, managing certain risks).
What you commit to downstream in your customer contracts and SLAs.
What you expect customers to do themselves.

This exercise often reveals misalignments: obligations to customers that have no upstream support, or assumptions about providers that are not backed by their contracts. It also clarifies where you need stronger controls, clearer wording or different service designs. When you build this view into an ISMS platform such as ISMS.online, you give teams a single source of truth about shared responsibilities.

Turning responsibility maps into daily practice

Turning responsibility maps into daily practice means making sure everyone who touches cloud services understands the parts that apply to them and can act on them quickly. The maps should shape behaviour in sales, engineering, support and account management.

Making responsibility maps real means:

Using them to brief sales and account teams, so they do not over‑promise or improvise commitments.
Aligning runbooks and playbooks with the responsibilities you have defined, so technical teams act consistently.
Training engineers on how and when to exercise their rights in customer tenants, including time‑bound elevation and approvals.
Agreeing how incidents involving providers will be communicated and handled with customers, including escalation paths.

When your dual‑role view is embedded in this way, A.5.23 stops being an abstract requirement and becomes a natural lens on how your MSP operates in the cloud. It also gives you a clear narrative for boards and customers who want to understand your place in the shared responsibility chain.

A Practical Shared Responsibility Model for MSP Cloud Platforms

A practical shared responsibility model for MSP cloud platforms is a set of clear matrices that show who does what across provider, MSP and customer for each service. Under A.5.23, these matrices turn the idea of shared responsibility into something you can run, teach and audit.

Most public cloud providers describe a simple split: they secure the infrastructure; you secure what you build on it. That pattern is documented in shared responsibility model explanations from major providers such as AWS, Azure and Google Cloud, and it has become a common baseline for cloud control design. For MSPs, that is only the starting point. You need models that reflect the specific platforms you use, the services you offer and the way your teams actually operate.

Moving beyond generic “joint responsibility”

Moving beyond generic “joint responsibility” labels means replacing vague statements with specific, named tasks that individuals and teams understand. A.5.23 rewards this clarity because auditors and customers can see who is accountable for real actions, not just abstract concepts.

Generic “joint responsibility” labels hide real risks. To move beyond them, you need to consider:

The specific platforms you use (for example, infrastructure‑as‑a‑service, software‑as‑a‑service, managed security tools).
The specific services you offer (for example, managed backup, managed SOC, managed modern workplace).
The way your team actually operates (for example, use of automation, centralised monitoring, maintenance windows).

For each combination of platform and service, a responsibility matrix should define responsibilities in enough detail that people can act. That means naming who enables logging, who tests restores, who handles subject access requests and who leads incident communication, rather than simply stating “shared”.

Taking this extra step also supports related controls, such as incident management and operations security, because everyone can see where their role starts and ends.

Structuring your responsibility matrices

Structuring your responsibility matrices well means using a consistent layout that mirrors how your engineers and service managers think, while still being detailed enough to guide action. A simple structure, repeated across services, makes training and review much easier.

A practical matrix for each service might cover domains such as:

Identity and access management: – who creates and revokes accounts, manages roles and reviews access.
Configuration and hardening: – who applies baselines, handles security updates and reviews configuration drift.
Logging and monitoring: – who enables logs, stores them, reviews alerts and responds to incidents.
Backup and recovery: – who configures backups, tests restores and verifies recovery objectives.
Data protection and privacy: – who classifies data, applies retention rules and manages subject rights.
Continuity and exit: – who is responsible for resilience patterns, failover and data export or deletion at the end of a contract.

For each row, the matrix should mark responsibilities clearly: provider, MSP, customer, or shared with specific tasks assigned. You should also ensure that each matrix is version‑controlled and reviewed when services, platforms or contracts change, so it remains accurate over time.

A simplified example for managed backup on a public cloud platform might look like this:

Domain	Provider / MSP / Customer responsibilities
Backup configuration	Provider offers feature; MSP configures policies; customer reviews scope
Restore testing	MSP performs periodic test restores; customer validates data completeness
Retention settings	Provider enforces limits; MSP sets retention; customer approves policy

You can then reuse these matrices across customers that use the same service pattern, adjusting only where truly necessary.

Linking the model to your ISMS and customers

Linking the shared responsibility model to your ISMS and customers ensures it influences decisions from pre‑sales to off‑boarding rather than sitting in isolation. The more you connect it, the more useful and credible it becomes.

Once you have defined these models, connect them:

Internally, by referencing them in policies, procedures, runbooks and training.
Commercially, by aligning your service descriptions, proposals and SLAs with the responsibilities you have set.
With customers, by sharing simplified views or diagrams during onboarding, so expectations are clear from day one.

When an auditor asks how you manage shared responsibility under A.5.23, you can point to these matrices, their links into your ISMS and examples of how they have guided real decisions. When a customer such as a CISO or head of IT asks “who owns this control?”, you have an answer that is consistent across the business. A central platform such as ISMS.online can hold these matrices alongside risks, controls and contracts so they are easy to maintain and evidence.

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

Book your demo

Designing Cloud Service Lifecycle Processes for A.5.23

Cloud service lifecycle processes are how you prove that A.5.23 is more than a policy statement: they show that you select, run and retire cloud services in a controlled, repeatable way. For an MSP, the goal is to weave cloud lifecycle steps into your existing ISMS processes, not to create a separate bureaucracy.

A.5.23 expects you to demonstrate that cloud services follow defined steps from idea to exit, with security and shared responsibility considered at each stage. This aligns closely with the control’s own language around “acquisition, use, management and exit” of cloud services in line with information security requirements, and with common lifecycle models used in ISO 27001 and cloud standards guidance such as ISO 27001 A.5.23 commentary. That aligns naturally with ISO 27001 clauses on risk treatment, operational planning, change management and supplier management.

Defining a cloud service lifecycle that people can follow

Defining a cloud service lifecycle that people can follow means turning A.5.23 into a small set of repeatable stages that fit your existing ways of working. The lifecycle should be simple enough that product owners, engineers and procurement teams can apply it without specialist knowledge. Two‑thirds of organisations in the 2025 ISMS.online State of Information Security survey say the speed and volume of regulatory change are making compliance harder to sustain.

A typical lifecycle for significant cloud services might include stages such as:

Idea and assessment – someone proposes a new cloud service or a new way to use an existing one. You screen it for business value, security and compliance fit.
Selection and due diligence – you check certifications, data locations, contractual terms and support capabilities, and compare options.
Design and onboarding – you decide how the service will be configured, integrated and monitored, and who will own it.
Operation and change – you run the service, review logs and metrics, handle changes and incidents, and keep the configuration aligned with your standards.
Review and renewal – you periodically review whether the service still meets needs, whether risks are acceptable and whether improvements are needed.
Exit or replacement – if you switch off or replace the service, you handle data export, deletion and customer communication.

These stages make cloud service decisions repeatable instead of ad‑hoc. For each one, define the minimum actions, approvals and records you expect. That might include risk assessments, due diligence checklists, configuration baselines, change records and exit confirmations, all aligned with your central ISMS.

To make this even more usable, you can express the lifecycle as a simple set of steps for teams to follow.

Step 1: Capture and screen the idea

Capture and screen each cloud service idea before anyone signs up or integrates it, so you can weigh value, risk and alignment with your ISMS.

Record the proposed cloud service, its purpose and initial risks before anyone signs up or integrates it.

Step 2: Complete due diligence and design

Complete due diligence and design before a cloud service is adopted, so configuration, monitoring and responsibilities are defined rather than improvised.

Check assurance, contracts and data handling, then define configuration, monitoring and shared responsibilities.

Step 3: Onboard, operate and plan exit

Onboard, operate and plan exit in a structured way, so you can prove how the service is controlled throughout its life.

Onboard the service according to your baselines, monitor it and record how you will exit or replace it safely.

Embedding lifecycle controls into how you work

Embedding lifecycle controls into how you work means integrating them into processes and tools your teams already use. When the lifecycle is the default path, compliance with A.5.23 becomes much easier to sustain.

Consider:

Aligning it with procurement workflows, so contracts cannot be signed until security, privacy and operational requirements are checked.
Linking it to your service introduction process, so new offerings or major changes go through the cloud lifecycle gates.
Integrating lifecycle tasks into your ticketing and change systems, not just into separate cloud documents.

By connecting lifecycle steps to established processes such as change management and supplier management, you reduce friction and improve adoption. People follow the lifecycle because it is the path of least resistance, not because they were told to read another policy.

Making lifecycle evidence audit‑ready

Making lifecycle evidence audit‑ready means being able to show a few complete examples that demonstrate the same logic applied to different services. Auditors want to see patterns, not one‑off successes.

For each example, aim to demonstrate:

Why the service was chosen, based on risk and requirements.
How responsibilities were defined, using your shared responsibility model.
Which controls were implemented at onboarding, including baselines and access patterns.
How the service is monitored and reviewed, with examples of changes or improvements.
How data and access would be handled at exit, even if that exit has not yet happened.

If you can produce this evidence without a major scramble, A.5.23 will feel embedded rather than bolted on. A system like ISMS.online can help by linking services, risks, responsibilities, changes and exit records in one place, so you do not have to assemble the picture from scratch every time someone asks.

Multi‑tenant Technical Controls: Implementing Consistent Safeguards

Multi‑tenant technical controls are the practical expression of your A.5.23 cloud governance decisions in everyday engineering work. They translate shared responsibility models and lifecycle processes into concrete baselines that protect many customers at once.

When you manage multiple tenants on common platforms, A.5.23 expects you to take a proactive, standardised approach to identity, configuration, logging, backup and isolation. That way, you can show that your technical safeguards match the responsibilities you have accepted and the commitments you make to customers.

Why multi‑tenant baselines matter

Multi‑tenant baselines matter because small weaknesses can have large consequences across many customers at once. A single over‑permissive role, missed update or untested backup could undermine your overall cloud assurance storey. Cloud security frameworks and national guidance, such as multi‑tenant risk discussions in control catalogues and cloud security collections from national cyber security centres, consistently highlight identity management, patching and backup as systemic risk areas that can rapidly scale across tenants when they fail. A majority of organisations in the 2025 ISMS.online survey reported being affected by at least one third‑party or vendor‑related security incident in the past year.

In an MSP environment, one over‑privileged admin account, unlogged critical action or untested backup process can affect dozens of customers in one incident. A.5.23 expects you to manage those risks systematically, not reactively, and to be able to show how your controls apply across the cloud services you use and provide. Consistent baselines define the minimum controls in place for any customer using a given platform or service and give auditors and customers confidence that you are not reinventing security every time.

From a leadership perspective, these baselines also provide an assurance storey: you can show boards and customers that technical safeguards align with the governance and contractual decisions you have already made.

Core technical themes to standardise

Core technical themes to standardise are the areas where consistent safeguards reduce the likelihood of cross‑tenant issues and give engineers a clear starting point on every platform.

While details vary by platform, most MSPs benefit from standardising at least the following themes. Doing this makes it easier for your head of security, operations lead and engineering teams to pull in the same direction.

Identity and access management: – role‑based access, least privilege, separation of duties, time‑bound elevation for high‑risk actions and robust off‑boarding.
Configuration and hardening: – baseline templates for network segmentation, encryption, endpoint protections, patching policies and resource naming.
Logging and monitoring: – consistent logging configurations, central log aggregation, defined alert rules and documented response playbooks.
Backup and recovery: – standard backup schedules, retention, encryption, restore testing routines and documentation of client recovery objectives.
Isolation and tenancy: – patterns for separating tenants at the network, identity and data layers, and checks to verify that isolation holds.

Each baseline should clearly state what the provider delivers, what you configure and maintain, and what you expect customers to do. Taken together, these themes become the technical backbone of your A.5.23 implementation.

After you define these themes, the next step is to embed them where engineers live: templates, scripts, infrastructure‑as‑code, central management tools and documented playbooks.

Connecting technical controls to A.5.23 and beyond

Connecting technical controls to A.5.23 and related controls ensures that your governance, legal commitments and engineering practices support one another rather than pull apart. This alignment makes your overall system easier to explain and defend.

That means:

Mapping each baseline element to your shared responsibility matrices, so technical controls match the responsibilities you have assigned.
Ensuring baselines are part of your cloud service lifecycle, so they are applied at onboarding and revisited during reviews.
Linking themes such as access, logging and backup to Annex A controls on access control, operations security, incident management and business continuity.

This alignment makes your overall control system coherent. It also means that when A.5.23 is discussed during audits or customer reviews, you are ready to show not just policies, but working technical safeguards that match your governance storey. If you manage these baselines in a central system like ISMS.online, you can demonstrate the connection from a cloud service, to its risk assessment, to its technical controls, in a few clicks.

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

Book your demo

Contracts, SLAs and Sub‑processor Clauses That Stand Up in Audit

Contracts, SLAs and sub‑processor clauses are where your A.5.23 cloud governance decisions become legally binding promises. The control expects your agreements with providers, sub‑processors and customers to reflect the shared responsibility, lifecycle and technical choices you have made, rather than contradict them.

A.5.23 does not require you to write contracts in a particular way, but auditors and customers will test whether your legal commitments and your technical reality line up. Principle‑based guidance on A.5.23 and related cloud controls routinely stresses the importance of aligning contractual promises with actual controls and shared responsibility models, because misalignment is where many audit findings and disputes arise.

A.5.23 does not require you to write contracts in a particular way, but auditors and customers will test whether your legal commitments and your technical reality line up. If they do not, the control becomes a source of risk and findings.

Making responsibilities and expectations explicit in contracts and SLAs means translating your internal responsibility matrices into clear, stable wording that legal, sales and customers can all understand. A.5.23 is much easier to evidence when those documents match the way you actually operate.

Contracts and SLAs are where misunderstandings turn into disputes, especially when cloud services are involved. To support A.5.23, your agreements should:

Describe the services clearly, including any reliance on third‑party cloud platforms.
Set out security and data protection obligations in enough detail to be meaningful, without promising what you cannot deliver.
Explain who is responsible for which aspects of incident detection, response and communication.
Clarify what happens at the end of the contract, including data export or deletion and any transition support.

Where possible, align this language directly with the domains in your shared responsibility matrices, so there is a clear line from model to wording. This also helps satisfy related ISO 27001 requirements around legal, regulatory and contractual obligations.

Once responsibilities are explicit in both matrices and contracts, your teams have less room for conflicting interpretations when incidents or complex customer demands arise.

Aligning technical reality with legal commitments

Aligning technical reality with legal commitments means checking that what you promise in contracts is achievable with your current tools, processes and baselines. It reduces the risk that customers or auditors discover gaps between words and practice. Only about 29% of organisations in the 2025 ISMS.online survey said they had received no fines for data‑protection failures, with the majority reporting fines and some facing penalties above £250,000.

It is easy for legal clauses to drift away from technical reality over time. Perhaps a template promises very rapid incident notification, but your monitoring and escalation processes make that difficult in practice. Or an SLA commits to recovery objectives that do not match backup designs.

To avoid this, review your contracts and SLAs jointly across legal, security, operations and account management. Ask:

Can we consistently meet the commitments we are making, given our current monitoring, support hours and technical baselines?
Are there areas where we need to invest in better controls or tooling to honour them?
Are there obligations that should instead sit with the customer or provider, and be communicated as such?

When your legal commitments and technical capabilities are aligned, A.5.23 becomes easier to evidence and less risky to live with. You also reduce the likelihood of surprises for customers, regulators or auditors who dig into the detail behind your promises.

Incorporating governance into your agreements

Incorporating governance into your agreements means using contract language to reinforce the way you want providers and customers to behave, not just documenting services and prices. It can make shared responsibility and lifecycle thinking part of the everyday relationship.

That might include:

Rights to receive or review provider assurance, such as updated certifications or independent reports.
Expectations around participation in joint incident or continuity exercises.
Obligations to notify about significant service or location changes.
Requirements to follow agreed exit processes, including timelines and cooperation.

By weaving these into your contracts, you ensure that governance is not just an internal matter. It becomes part of the way you, your providers and your customers work together over the life of the service. When auditors test A.5.23, they can see that lifecycle and shared responsibility are reflected consistently in your agreements, not just in your policies.

Book a Demo With ISMS.online Today

Booking a demo with ISMS.online is a practical way to see how your MSP can bring A.5.23 cloud governance under control without adding more complexity to your teams. In one place, you can see how cloud services, risks, responsibilities, lifecycle steps and evidence connect, so you are ready for audits, customer questions and board reviews.

You bring A.5.23 cloud governance under control when you replace scattered documents and ad‑hoc decisions with a single, coherent system that links services, risks, responsibilities, lifecycle steps and evidence. For many MSPs, using a purpose‑built ISMS platform such as ISMS.online can be a practical way to achieve that consolidation without adding more complexity.

ISMS.online helps you turn your A.5.23 cloud governance responsibilities into a single, joined‑up system that connects cloud inventories, shared responsibility models, lifecycle workflows, contracts and evidence. Instead of chasing documents across drives, consoles and inboxes, you can see how cloud services are governed and how responsibilities are managed in one place.

For MSPs, that means you can show auditors, boards and customers a clearer, more coherent narrative: which cloud services you use, how responsibilities are shared, what controls are in place and how those arrangements change over time. Observers of governance, risk and compliance (GRC) tooling often note that centralised platforms make this kind of narrative easier to assemble and keep consistent, because they bring together risks, controls and evidence in one environment. You stay in control of decisions; the platform helps you prove that control, consistently, as your business scales and standards evolve.

See your cloud storey in one view

Seeing your cloud storey in one view makes it easier for your CISO, operations lead and customer‑facing teams to answer difficult questions without friction. A.5.23 becomes less of a compliance exercise and more of a simple way to describe how you really work.

When you centralise your cloud governance in an ISMS platform, you give yourself and your team a single reference point for A.5.23. You can:

Maintain a live register of internal and client‑facing cloud services.
Link each service to risks, controls, responsibility matrices and lifecycle stages.
Attach contracts, due diligence, change records and exit evidence directly to the services they relate to.

Together, these capabilities make it much easier to respond to auditor questions, customer security reviews and internal decision‑makers who want to understand how cloud is being managed. You are no longer relying on memory or disparate spreadsheets to tell your cloud storey.

Take the next step with confidence

If you recognise your MSP in the challenges described here - blurred responsibilities, scattered evidence, growing pressure from customers and auditors - exploring a platform such as ISMS.online in a short, focused demonstration is a practical next step. Despite growing pressure, almost all respondents in the 2025 State of Information Security survey list achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority.

You can see how it supports your existing tools and ways of working while giving you the structure A.5.23 expects.

Choose ISMS.online when you want one place to hold your cloud service register, responsibilities, risks and evidence so you can show, not just claim, that A.5.23 is under control. If you value clear governance, smoother audits and a stronger storey for customers and boards, our team is ready to help you see what that looks like in your environment.

Book a demo

Frequently Asked Questions

What does ISO 27001:2022 A.5.23 really expect from an MSP using cloud services?

ISO 27001:2022 A.5.23 expects your MSP to actively govern the full lifecycle of every cloud service you rely on, not just collect provider certificates and hope for the best. You should be able to show, quickly and consistently, what you use, why you use it, what could go wrong, who owns which controls, and how you would exit without losing data or service.

What does “good” A.5.23 evidence look like for an MSP?

Auditors and switched‑on customers are usually looking for a small, coherent bundle of evidence, not a giant archive. For an MSP, the core set typically includes:

A clear cloud use / cloud security policy

This defines what counts as “cloud” in your world (IaaS, SaaS, PaaS, managed security services), who can approve new services, and your minimum expectations for configuration, monitoring and exit.

A cloud service register that covers:
internal tools (RMM, PSA, ticketing, billing, CRM, monitoring, secure file transfer); and
customer‑facing services (IaaS platforms, Microsoft 365 and other SaaS suites, backup/DR, SOC/XDR, managed firewalls and WAFs).

Cloud‑specific risk assessments and treatments:

These should call out multi‑tenant exposure, powerful cross‑tenant roles, data residency, vendor lock‑in, API dependencies and key management. The risks should link to real controls and improvement actions.

Due‑diligence records: for key providers and sub‑processors

Typically this includes security summaries, certifications (for example ISO 27001, SOC 2), DPAs, uptime history, breach history and known limitations or exclusions that affect your designs.

Shared responsibility matrices:

For each major service, show what the provider does, what your MSP does, and what the customer must do. The language should be concrete enough that an engineer or customer can see “my tasks” without a second meeting.

Cloud service lifecycle records:

Evidence that selection, onboarding, configuration, change, periodic review and exit are handled in a controlled, repeatable way rather than through ad‑hoc tickets.

If those elements are joined up and easy to navigate, A.5.23 feels under control and credible. Using ISMS.online to keep policies, risk entries, supplier records, responsibility matrices and lifecycle evidence in one ISMS workspace means you are not reconstructing your cloud storey from inbox searches and console screenshots every time an auditor or customer raises the clause.

How should an MSP build a usable shared responsibility model for cloud under A.5.23?

You satisfy the intent of A.5.23 when “shared responsibility” becomes a service‑by‑service map of real tasks, not just a marketing slide that says “we and the provider both care about security.” Anyone reading it – engineer, salesperson, contract reviewer or customer – should be able to see exactly what they own.

How do you turn “shared responsibility” into something concrete?

A practical pattern that works well for MSPs is to:

1. Catalogue your cloud services by category

Start with a short list of buckets:

Public‑cloud workloads (IaaS/PaaS).
SaaS productivity suites (Microsoft 365, Google Workspace and similar).
Managed backup and disaster recovery services.
Managed SOC/XDR and threat detection services.
Other recurring cloud‑based tools you rely on to run your business or deliver services.

This list usually mirrors the entries in your cloud service register, which makes it easier to keep things aligned.

2. Choose a common set of security domains

Pick a small set of domains that apply to most of your services, such as:

Identity and access management.
Baseline configuration and hardening.
Logging, monitoring and alerting.
Backup, restore and test routines.
Encryption and key management.
Incident detection, triage and response.
Change management and approvals.
Data retention, residency and disposal.

Sticking to a standard set makes the model easier to understand and to reuse across services.

3. Assign ownership per domain, per service

For each service and each security domain, decide who actually does the work in practice:

Cloud provider: – infrastructure resilience, physical security, most underlying platform patches, some log storage options.
Your MSP: – tenant configuration baselines, alert routing, backup schedules, restore testing, incident triage, customer reporting.
Customer: – user behaviour, acceptable use, data classification, access approval, content lifecycle decisions.

Where responsibilities are shared, write down the split as specific tasks, not vague “joint” labels. For example:

“Customer approves retention period; MSP implements and reviews configuration quarterly.”
“MSP reviews security alerts; provider handles platform‑level incident response.”

4. Embed the model into day‑to‑day operations

A responsibility matrix only matters if it turns up where people work. Make sure you:

Reference it in runbooks and playbooks, so engineers can see what to do during incidents and changes.
Align standard service descriptions and SoWs with it, so sales do not promise tasks you are not performing.
Reflect it in contracts and SLAs, so legal commitments match technical reality and upstream provider capabilities.
Include it in onboarding packs, so new customers understand which actions stay with them and which sit with you.

Maintaining these matrices centrally in ISMS.online – linked to services in your cloud register, risk entries and supplier records – lets you update a matrix once and have the change propagate into runbooks, documentation and audit evidence. That makes it much easier to show that A.5.23 works in practice, not only in a policy document.

What cloud‑specific risks does A.5.23 highlight for MSPs, and where do they tend to slip?

For MSPs, A.5.23 is less about generic “cloud breach” stories and more about misaligned expectations, configuration weaknesses and poor lifecycle control across shared environments. Problems tend to appear where your marketing promises, provider capabilities and team behaviours do not line up.

Where do MSPs commonly get caught out?

Patterns that repeatedly cause trouble include:

Over‑reliance on provider security assumptions

It is easy to talk about “secure by design” while assuming that tasks such as restore testing, log review, threat hunting or tenant‑level hardening are included in a cloud subscription. In reality, many of those activities are your responsibility as the MSP, and sometimes partially your customer’s. When they are not captured in your responsibility matrices and runbooks, they are rarely executed consistently.

Excessive, poorly governed privileged access

MSPs often hold powerful roles – global admin accounts, partner portals, break‑glass identities – that span many tenants. If those entitlements lack strong approval, logging and review, a single compromised credential or misused account can become a significant multi‑tenant incident. A.5.23 expects you to recognise that risk in your asset and risk registers, and to put clear controls around it.

Unregistered or “shadow” SaaS

Teams adopt SaaS tools that handle sensitive or customer data – for support, collaboration, development, sales or automation – without ever adding them to your ISMS, supplier register or risk processes. Those services then fall outside your monitoring, incident response and exit plans.

Weak or untested exit plans

Many MSPs only think about exit when a provider announces a product retirement, a major pricing change or an outage. Without a recorded exit plan – including data export, migration, evidence retention and customer communication – you are improvising at the point where you need the most control.

SLAs that over‑promise

Contracts sometimes commit you to recovery objectives, retention periods or data residency specifics that the underlying stack cannot guarantee. When the service design, cloud provider features and contract language do not match, you carry unnecessary risk.

A.5.23 gives you a framework to tackle these issues systematically:

Inventory and classify cloud services: so you know where risk concentrates.
Perform cloud‑specific risk assessments that address multi‑tenant issues, privileged access and provider failure modes.
Maintain responsibility matrices so tasks are assigned, owned and reviewed.
Evidence lifecycle steps – from onboarding to exit – so people can see that changes, reviews and exits are controlled events, not reactions.

When you can trace a risk – for example, excessive partner portal access – from your register to responsibility matrices, then to change records and improvement actions, you are not just compliant with A.5.23; you are also presenting a far stronger cloud risk storey to auditors and customers.

How can an MSP document A.5.23 in its ISMS without redesigning everything?

You can usually cover A.5.23 by layering cloud‑specific governance onto your existing ISMS, rather than building a parallel structure. The aim is that anyone familiar with ISO 27001 can follow how you select, control and retire cloud services as easily as they can follow traditional assets or suppliers.

How do you weave cloud governance into what you already have?

A simple but effective pattern is to start with three connected components and then plug them into your existing ISMS:

1. Cloud use / cloud security policy

Extend your existing information security policy set with a focused document that:

Defines what qualifies as a cloud service in your context.
Sets approval thresholds (for example, who can authorise a new provider).
States expectations for due diligence, configuration baselines, monitoring, incident handling and exit.

This policy becomes the anchor for related procedures and records.

2. Cloud service register

Create a register – often an ISMS.online asset or supplier list – capturing, at a minimum:

Service name and provider.
Internal owner.
Business purpose.
Data types handled and data locations.
Criticality and impact of loss.
Links to contracts, DPAs, certifications and responsibility matrices.

You can integrate this with your existing asset inventory so cloud services do not live in a separate universe.

3. Shared responsibility matrices

For the services that matter most, build and maintain responsibility matrices as described earlier. Focus initially on:

Your primary public‑cloud platform.
Your main SaaS productivity and collaboration suite.
Your flagship managed backup/DR offering.
Your managed SOC/XDR or similar security‑as‑a‑service solutions.

You can then connect these components into the ISMS elements you already operate:

Risk management: – link cloud services to risk entries and treatments, especially where multi‑tenant or provider failure scenarios exist.
Supplier management: – attach contracts, security summaries, DPAs and audit reports to the relevant providers; record periodic reviews and decisions.
Operational controls: – reference cloud‑specific onboarding, change, review and exit steps within your existing change management and incident handling processes.
Evidence management: – link incidents, backup test results, access reviews and improvement actions back to the relevant cloud entries and risks.

Using worked examples – for instance, one internal SaaS, one customer‑facing solution built on public cloud and one niche but critical platform – helps you show auditors that the pattern is repeatable without documenting every minor service individually. ISMS.online is designed for this style of modelling: policies, registers, risks, suppliers, tasks and evidence sit together, with links making the cloud governance picture easy to follow.

Which contracts and SLAs should an MSP align to demonstrate A.5.23 to customers?

To demonstrate A.5.23 convincingly, you need both your upstream and downstream agreements to match the way you actually manage cloud risk. That means your contracts and SLAs with providers and sub‑processors, and your terms with customers, should all point to the same responsibility splits and capabilities that you document in your ISMS.

What should you check in upstream provider and sub‑processor agreements?

Review the parts of each agreement that directly affect your services and claims:

Security and availability commitments: – ensure RPO/RTO targets, uptime SLAs and data durability align with how you design services and the promises in your own SLAs.
Data location and residency statements: – you should be able to answer “where is our data?” with confidence, including backup locations and failover regions.
Incident notification and escalation: – check how and when providers commit to informing you about incidents that may affect your customers.
Support for key controls: – confirm whether features such as detailed logging, customer‑managed encryption keys, immutable backups or advanced access controls you rely on are explicitly available and supported.
Assurance mechanisms: – identify certifications, assurance reports, penetration test summaries or contractual audit rights that you can use as evidence within your own ISMS and customer reporting.

You may not need to renegotiate every contract, but you should understand and document where a provider’s commitments fall short of your current service descriptions, and adjust your own offers or architectures accordingly.

How should customer contracts and SLAs change to reflect A.5.23?

Downstream, your customer‑facing documents should:

Clearly identify which services rely on which cloud platforms, especially where that affects data location, resilience or support.
Explain who is responsible for which control areas – such as user access approvals, acceptable use, classification, legal holds and content lifecycle – in line with your shared responsibility matrices.
Commit to recovery objectives, retention periods and incident communication timeframes that your upstream agreements and designs can reliably deliver.
Reference, or link to, responsibility and dependency information in a way customers can understand without reading your ISMS.

When upstream contracts, internal responsibility matrices and downstream SLAs all tell the same storey, it is much easier to walk a customer or auditor through how you manage cloud risk under A.5.23. Managing these documents inside ISMS.online, alongside your policies and risks, helps you keep the narrative aligned as providers update their terms, regulations evolve and customers become more demanding.

How can an MSP use ISMS.online to keep A.5.23 under control as cloud services change?

ISMS.online helps you keep A.5.23 under control by turning cloud governance into a continually updated, connected system, rather than a set of static documents that fall behind changes in your stack. As you adopt, modify or retire cloud services, your ISMS view can stay current, auditable and explainable.

What does day‑to‑day A.5.23 management look like in ISMS.online?

In a typical setup, your team would use ISMS.online to:

Maintain a live cloud service register

Record each cloud service with its owner, purpose, data types, data locations and criticality.
Tag services used internally versus those used to deliver managed services.
Link each entry to relevant policies, risks, suppliers and responsibility matrices.

Attach and track cloud‑specific risks and treatments

Create risk entries for multi‑tenant exposure, powerful cross‑tenant accounts, data residency, provider lock‑in and API dependencies.
Assign treatments, owners and review dates.
Use the platform’s linked work and projects to track remediation and improvement actions.

Store contracts, certifications and due‑diligence in one place

Upload provider contracts, DPAs, security summaries and assurance reports directly against supplier records.
Record review outcomes and decisions, so you can show that provider risk is managed over time.

Centralise shared responsibility matrices

Maintain one authoritative matrix per major cloud service or service family.
Link matrices into policies, service descriptions, risk entries and supplier records.
Use them as reference points when updating runbooks, SLAs and onboarding materials.

Evidence lifecycle activities

Log selection, onboarding, configuration baseline approvals, change reviews, periodic reassessments and exit steps as tasks or linked work items.
Associate related incidents, backup tests, access reviews and improvements with the relevant services and risks.

When you onboard a new platform, you can clone an existing entry, adjust configuration and responsibilities, and connect it into risks and suppliers within minutes. When you retire a service, you can record the data migration, sanitisation and evidence retention decisions in the same place.

For audits, customer questionnaires or board sessions, you can then assemble a focused A.5.23 evidence pack straight from ISMS.online: the cloud policy, the current register, example responsibility matrices, key cloud risks and treatments, supplier due‑diligence and a sample of lifecycle and incident records. That ability to tell a consistent, end‑to‑end storey is what makes an MSP look in control of cloud governance rather than constantly reacting. If you want customers and auditors to see you in that first group, investing in structuring A.5.23 properly inside ISMS.online is a high‑leverage next step.

A.5.23 Information Security for Use of Cloud Services – MSP Cloud Platforms & Shared Responsibility