Top ISO 27001 MSP Questions: Evidence, Scope, and Annex A Controls Explained

Why do ISO 27001 questions to MSPs now matter more than ever?

ISO 27001 questions to MSPs now matter more than ever because their controls directly shape your organisation’s risk and regulatory exposure. Enterprise security teams such as CISOs, security managers, vendor‑risk owners, and third‑party risk leads now depend on managed service providers for critical operations, so weak ISO 27001 alignment at a provider quickly becomes your problem. Asking sharper ISO 27001 questions lets you see how controls really run day to day and helps you prove to boards, audit committees, and regulators that outsourcing is strengthening, not diluting, your security posture.

When you first adopted ISO 27001 internally, you probably focused on your own data centres, applications, and teams. Today, a significant portion of that estate may sit in an MSP’s environment or in cloud platforms they manage. That might include a managed security operations centre analysing all your logs, or a managed identity platform underpinning single sign‑on for every employee. The standard still holds you accountable for information security risks, even when other organisations operate key controls on your behalf. ISO 27001 makes this explicit by requiring you to define your organisational context, assess information‑security risks, and control outsourced processes rather than transferring accountability wholesale to suppliers, as highlighted in core overviews of the ISO 27000 family such as the ISO 27000 series introduction. That is why “Are you ISO 27001 certified?” has become the weakest possible starting point rather than a sufficient answer.

The 2025 State of Information Security report notes that customers increasingly expect suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials and SOC 2 rather than relying on generic good practice.

Trust grows when you see how controls run every day, not just at certification time.

You need to understand whether an MSP’s Information Security Management System (ISMS) truly covers the services you plan to use, how they interpret shared responsibility, and how they evidence ongoing control operation. Each of those themes should show up in the questions you put to every provider and in the storey you later tell internally about why a particular MSP is acceptable. This article offers general information to support those conversations; it is not legal or regulatory advice, and you should always work with your internal governance bodies and qualified advisers when making final decisions.

How outsourcing changed your ISO 27001 risk landscape

Your risk landscape changed the moment you let an external provider manage parts of your technology stack. You have not outsourced accountability; you have outsourced activities, so ISO 27001 still expects you to stay in control of how security is managed.

A majority of organisations said they had been impacted by at least one third‑party or vendor‑related security incident in the past year.

ISO 27001 expects you to:

Understand internal and external issues that affect your ISMS.
Define interested parties, including MSPs, and their requirements.
Control outsourced processes that affect information security.

When core services such as identity, infrastructure, monitoring, or incident response sit with MSPs, those outsourced processes become central to your risk treatment plan. If you cannot describe how an MSP’s controls support your own Annex A controls, you can create a material blind spot that is likely to concern your board, auditors, major customers, and regulators. Supply‑chain guidance from national cyber‑security agencies, including resources from CISA, similarly highlights unmanaged third‑party controls as a significant governance risk. A practical next step is to ensure each strategic MSP appears explicitly in your risk register, with links to the controls you rely on them to operate.

From the board’s perspective, questions are now less about whether you are certified and more about whether your extended ecosystem behaves like a coherent, well‑governed ISMS. That is why your MSP due diligence has to look and feel like an extension of your internal ISO 27001 work, not a separate procurement checklist or a one‑off security questionnaire. If you can show that MSP‑operated controls are embedded into your risk register, Statement of Applicability (SoA), and management reviews, it becomes much easier to defend outsourcing decisions under scrutiny.

Why Are you certified? is not enough

A certificate tells you that, at defined points in time, a certification body found an ISMS to be conformant within a stated scope. It does not tell you which of your services are inside that scope, how Annex A controls are implemented, or whether those controls continue to operate effectively.

It also says nothing about how responsibilities are split between provider and customer, which is where many incidents and audit findings arise. If you stop at Are you certified?, you learn almost nothing about whether the MSPs controls are the right ones for your risk profile. Strong enterprise security teams now treat the certificate as the entry ticket, not the answer.

The real work starts with questions such as:

How does your ISMS scope map to the services and regions we will actually use?
Show us how your controls for this service map to Annex A in ISO 27001:2022.
What ongoing evidence can you share that these controls keep working?

A shared ISMS platform such as ISMS.online can help you hold these questions and answers in one place, turning scattered email threads and PDFs into structured, repeatable assurance that is easy to reuse with your board, audit committee, vendor‑risk forum, and regulators. Whatever tooling you choose, capturing the answers centrally makes it far easier to maintain a consistent third‑party assurance storey over time.

Book a demo

What does ISO 27001:2022 really require from managed providers?

ISO 27001:2022 requires managed providers to operate a risk‑based ISMS that clearly covers the services, locations, and processes affecting your information, and to justify their Annex A control choices. For you as a customer, that translates into questions that probe scope, risk assessment, control selection, and how those controls relate to the specific services the MSP runs for you.

Many providers still talk about ISO 27001 as if it were simply a library of controls. In reality, the standard defines a full management system that must understand organisational context, assess risks, plan treatment, operate controls, monitor performance, and improve over time. The 2022 revision sharpened that picture, modernised Annex A, and highlighted topics such as threat intelligence, data leakage prevention, and cloud‑specific risks that now appear frequently in enterprise due‑diligence discussions. Official descriptions of ISO/IEC 27001:2022, including the standard overview on the ISO website, emphasise these structural updates and the additional focus on modern threat and cloud scenarios.

Visual: a simple map that links ISO 27001 clauses to the MSP services that affect your data.

The ISO 27001:2022 elements that touch MSPs most

When you work with MSPs, several parts of ISO 27001:2022 are particularly relevant and should show up in how they answer your questions.

Clauses 4–6 (context, leadership, planning): – the MSP should define an ISMS scope that clearly includes the services, data centres, and supporting systems used to deliver managed services. They should also demonstrate that leadership, not just operations staff, owns information security.

Clauses 6–8 (risk assessment and treatment): – a certified MSP should explain how risks to customer data, service availability, and regulatory obligations are identified, evaluated, and treated. Their risk registers and treatment plans should clearly drive control selection for your type of service.

Annex A controls (93 controls in four themes): – in the 2022 edition, Annex A contains 93 controls grouped into organisational, people, physical, and technological themes, as described in public summaries of ISO/IEC 27001:2022 from standards bodies and overviews such as the BSI ISO 27001 information security page and the ISO/IEC 27001 article. For MSPs, you care deeply about access control, logging and monitoring, operations security, supplier relationships, and business continuity, and you want to know which of these are implemented for the services you buy.

Statement of Applicability (SoA): – the SoA records which Annex A controls are applicable, how they are implemented, and why any are excluded. For you, it is the primary map for understanding the MSP’s control environment and spotting unusual exclusions for your type of service.

Stronger providers can talk through each of these areas in concrete terms, using real processes and artefacts. Weaker providers tend to stay at the level of slogans such as “aligned with best practice” without connecting those claims to specific clauses, controls, or services. As you listen, ask yourself whether you could retell their explanation to your own management team in clear, non‑technical language.

What this means for your due diligence questions

When you translate the standard into questions for MSPs, you are essentially asking them to walk you through their ISMS with your services in mind. In practice, that means going beyond generic “yes/no” answers and inviting them to describe how their management system works.

Useful questions include:

Scope: “Describe the ISMS scope and confirm how it covers the specific services, environments, and regions you will use for us.”
Risk: “How do customer‑specific risks influence your risk register and treatment plans?”
Controls: “Which Annex A controls are implemented for our service, and where are you still maturing?”
Operation: “How do you monitor control effectiveness and respond when something is not working as intended?”

The 2013 to 2022 transition timeline is another useful lens. If an MSP is still certified against the older version, ask for their transition plan, milestones, and what changes they expect to control coverage. Industry transition guides for ISO/IEC 27001:2022, including practitioner blogs from providers such as OneTrust, commonly recommend requesting documented transition plans and explanations of how the revised controls affect services, rather than assuming the new requirements are already covered.

Strong MSPs typically show a clear, time‑bound plan with ownership and communication points. Weak MSPs often respond vaguely, or say they are “working on it” without concrete steps.

A practical next step is to record the answers in a standard template and link them to your own risk register and SoA entries. That way you can revisit them during management reviews and supplier‑risk forums rather than treating them as one‑off documents filed after procurement.

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

How do you move from generic controls to service‑specific Annex A mappings?

You move from generic assurances to service‑specific assurance by insisting on a clear mapping that shows, for each relevant Annex A control, who is responsible, how it is implemented, and which evidence backs it up for the particular service you are buying. This mapping turns ISO 27001 from an abstract comfort into a concrete, auditable view of how your risks are treated in an MSP environment.

Most providers can talk in general about “strong access control” or “secure operations”. Fewer can show you, for a given managed service, exactly how those statements relate to named Annex A controls, documented procedures, and real monitoring. That is where your questioning should focus if you want material you can reuse with auditors, procurement, and internal stakeholders.

What a good service‑specific control mapping looks like

A strong mapping document for a single managed service will usually include a clear description of the service, the Annex A controls that matter for that service, and how each control is owned and evidenced. The emphasis is on specificity rather than slogans.

A strong mapping document usually includes:

A clear service description and how it sits within the MSP’s ISMS scope.
A list of relevant Annex A controls, filtered to those that genuinely matter for that service.
For each control:
Whether it is provider‑owned, customer‑owned, or shared.
A short description of how the control is implemented.
Pointers to evidence such as policies, procedures, logs, tickets, and reports.

A simplified example might look like this:

Control theme	Strong answer from MSP	Red flag answer
Access control	“We operate role‑based access for this service, with approvals, periodic reviews, and central logging. You manage your user roles; we manage platform access.”	“Access is restricted as needed; details are internal.”
Logging and monitoring	“All admin actions on your environment are logged, retained for a defined period, and reviewed by our operations team with clear escalation rules.”	“We have logs, but we only review them if something goes wrong.”
Business continuity	“This service is covered by recovery procedures, tested at agreed intervals, with defined recovery time and recovery point objectives.”	“Our data centre provider guarantees uptime; we rely on them.”
Incident detection and response	“We run a SOC that monitors your service, with playbooks, severity‑based SLAs, and joint incident reviews for events affecting your data.”	“We will let you know if we see anything unusual.”

Security teams that review many MSPs often see the same patterns: stronger providers give answers like those in the left column, with ownership, specific mechanisms, and time‑bound testing. Weaker providers cluster in the right column, with vague assurances, over‑reliance on sub‑suppliers, and little evidence that anyone tests recovery or response. Once you have a few examples, it becomes much easier to explain to your internal stakeholders what “good” looks like.

How to ask for and use service‑specific mappings

In requests for proposal or due‑diligence calls, you can translate this into explicit requests such as:

“For this managed service, provide a control matrix mapping your controls to ISO 27001:2022 Annex A, with responsibilities and evidence for each control.”
“Where a control is shared, describe what you do and what you expect us to do, including any configuration or process requirements on our side.”
“Explain how you keep this mapping up to date when you change the service or when ISO 27001 is updated.”

Once you have the mapping, treat it as a working document rather than another static attachment. Your security architects can align it with your own control framework and identify gaps. Your GRC and vendor‑risk teams can reference it in risk registers, SoA entries, and supplier‑risk reports. Your operations and service‑owner teams can see exactly what they need to configure or monitor to hold up your side of the shared controls.

Over time, you can standardise the structure of these mappings across all MSPs. At that point, using a shared ISMS platform such as ISMS.online becomes valuable, because it lets you store, compare, and maintain these matrices centrally instead of juggling them in disconnected spreadsheets or email archives. Even if you start in simple documents, agreeing a common format is a practical first step.

How should you read an MSP’s ISO 27001 certificate and SoA with a sceptical eye?

You should treat an MSP’s ISO 27001 certificate and Statement of Applicability as starting points that frame further questions about scope, controls, and maturity. A sceptical reading looks at what is inside the certificate’s scope, what is outside, and how that aligns with the services, locations, and sub‑processors you care about, rather than assuming the badge covers everything you need.

Almost all respondents listed achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority for the coming year.

A certificate that looks impressive at first glance can hide important gaps, and certification and audit bodies regularly remind organisations that a certificate is only an assurance opinion over a defined scope and period, not a blanket guarantee of security; for example, ISO 27001 certification overviews from providers such as TÜV stress the importance of understanding scope and limitations. Thinking like an auditor or regulator when you read these documents makes it much easier to spot such problems early.

Reading scope and SoA like an auditor

When you review a certificate and related documents, focus on a few key areas that reveal whether the paperwork matches the reality of the services you are buying.

Pay particular attention to:

Scope statement: – does it explicitly mention the type of services you plan to use (for example, “managed security operations centre” or “managed cloud hosting”) and the locations from which they are delivered?

Locations, legal entities, and sub‑processors: – are the data centres, support centres, group companies, and named sub‑processors that will process your data listed, or are any critical ones missing or only indirectly referenced?

SoA coverage and exclusions: – which Annex A controls are marked as applicable, which are excluded, and why? Are any exclusions surprising for a provider of their type, such as excluding backup, logging, business continuity, or supplier controls?

Audit cycle and findings: – when was the last certification or surveillance audit, and are there known non‑conformities being addressed that might affect the services you receive?

Experienced enterprise teams can uncover services delivered from locations not listed in the scope, sub‑processors or data centres not covered by the ISMS, or Annex A controls marked as “not applicable” that they consider essential. Third‑party risk assessments and consulting insights, including cyber‑risk reports from firms such as Deloitte, describe scope gaps and surprising exclusions as common findings when reviewing supplier certifications. Teams that have been through several external audits often notice a pattern: strong providers can walk through scope and SoA with confidence, explain exclusions in plain language, and acknowledge improvement areas. Weak providers struggle to link the documents to real services and sometimes treat questions about exclusions as hostile. As a practical follow‑up, you can summarise your key observations and store them alongside the certificate in your supplier‑risk file.

Questions that reveal the limits of the certificate

Armed with this sceptical lens, you can pose questions that turn static documents into a richer conversation rather than relying on the certificate alone. The aim is to understand how far the documented scope and controls really support your use cases.

Questions such as these are useful:

“Which of our planned services fall fully within the ISMS scope, and which are partially or not yet covered?”
“Walk us through the key Annex A controls that underpin this service, and explain any exclusions that might affect us.”
“How do you decide when to bring a new service, feature, sub‑processor, or location into scope, and how do you inform customers when that happens?”
“What did your most recent internal and external audits highlight as areas for improvement that could impact us?”

These questions remind the provider that you understand ISO 27001 as a living system, not a marketing label. They also set the stage for later conversations around shared responsibilities for risk, incident management, continuity, and regulatory notifications, where scope clarity becomes even more important for your own SoA and risk treatment plans. Documenting the answers in your internal governance tools makes it easier to show boards and regulators how you reached your conclusions.

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

Book your demo

How do you draw the line on shared responsibility for risk, incidents, and continuity?

You draw the line on shared responsibility by turning high‑level ISO 27001 roles and responsibilities into concrete, written agreements that specify, for each major risk area, what the MSP will do, what you must do, and how both parties will coordinate. Without that level of clarity, even a certified provider can leave you uncomfortably exposed during incidents or disruptions.

ISO 27001 expects roles, responsibilities, and authorities related to information security to be defined and communicated. Clause 5.3 of ISO/IEC 27001 explicitly requires you to define and communicate information‑security roles, responsibilities, and authorities, as highlighted in core standard commentaries such as the ISO 27000 series introduction. In an MSP relationship, that expectation extends into contracts, service descriptions, and operational playbooks that should stand up to audit and regulatory scrutiny when something goes wrong.

Clear boundaries prevent arguments about accountability when the pressure is highest.

Clarifying risk management responsibilities

Clarifying risk management responsibilities starts with understanding how your risks appear in the MSP’s planning and how their risks appear in yours. Many later problems arise because neither side has written this down.

Useful steps and questions include:

Ask the MSP how risks related to your services and data make their way into their risk register and treatment plans.
Clarify whether they expect you to carry out specific risk assessments or to supply them with risk information for their own planning, including data protection impact assessments where privacy is in scope.
Ensure that your own risk register records the use of the MSP and the controls you rely on them to operate.

Good shared‑responsibility models often include a RACI (responsible, accountable, consulted, informed) matrix for key activities such as:

Access provisioning and periodic reviews.
Configuration and change management for shared platforms.
Patch and vulnerability management across infrastructure and applications.
Monitoring, alert handling, and escalation.

Operations and security best‑practice resources, including RACI guidance in SANS Institute white papers, frequently recommend this style of matrix to avoid gaps and overlaps in accountability. In practice, a patch‑management RACI might state that the MSP is responsible for patching the underlying operating system and platform; you are accountable for approving maintenance windows and patching your own applications; your security team is consulted on high‑risk changes; and your service owners are informed of upcoming patch cycles. Once you agree that split, you can reflect it in your risk register and SoA so that auditors see a consistent picture.

Your questions should aim to uncover these models and test whether they are understood on both sides. If your teams and the MSP’s teams would give different answers about who is responsible for a task, you have work to do before you can tell your board that risks are under control.

Splitting incident response and continuity in practice

Risk management becomes very real when something goes wrong, so you need the same level of clarity for incident response and continuity. Here you are looking for precise handovers, timelines, and assumptions rather than high‑level promises.

Two critical areas are:

Incident response: – who monitors for events, who triages alerts, under what conditions the MSP contacts you, through which channels, and who is responsible for forensics, evidence preservation, customer and regulatory notifications, and post‑incident reviews.

Business continuity and disaster recovery: – what recovery time and recovery point objectives the MSP commits to for the service, how these align with your business impact analysis, and what assumptions the MSP makes about your own continuity arrangements such as alternate access routes or manual workarounds.

Your questions might sound like:

“Describe the end‑to‑end process for handling an incident affecting our managed service, from detection to closure, and show us where our responsibilities begin.”
“For this service, which outage and data‑loss scenarios are covered by your continuity and recovery plans, and which scenarios do you expect us to handle ourselves?”
“How often do you test joint incident and continuity processes with customers like us, and how can we participate?”

The answers form part of your own incident response and business continuity planning and give comfort to stakeholders such as your audit committee, privacy officer, and regulator if they review your arrangements. They also feed into the evidence storey you will later ask for: test reports, post‑incident reviews, and improvements implemented by both parties over time. Documenting the agreed splits in your incident runbooks and continuity plans is a practical way to turn these conversations into auditable reality.

How can an MSP prove ongoing ISO 27001 compliance, not just a one‑off certification?

An MSP can prove ongoing ISO 27001 compliance by sharing structured evidence that shows its ISMS and controls are operating and improving throughout the year, not only at certification time. That evidence spans internal and external audits, technical testing, vulnerability management activities, supplier assessments, training outcomes, and metrics that track how issues are found and resolved.

A certificate alone is a point‑in‑time judgement: assurance guidance describes certifications as opinions based on the evidence available at the audit date, not guarantees of future performance, a distinction underlined in audit‑focused resources such as Audit Analytics. Ongoing evidence shows a pattern of behaviour that reassures your board, auditors, privacy regulators, and vendor‑risk forums that the MSP’s security posture is being actively managed rather than allowed to drift. Your questions should therefore focus on how they plan, test, and improve security continuously, rather than just what appears on a certificate.

Around two‑thirds of organisations in the 2025 ISMS.online survey said that the speed and volume of regulatory change are making compliance harder to sustain.

Evidence types that show a living ISMS

When you ask for proof beyond the certificate, you are really asking the provider to demonstrate that their Plan‑Do‑Check‑Act cycle is working in practice for your services. You do not need every detail, but you do need enough to see that checks, findings, and improvements are real.

Useful evidence includes:

Internal audit reports or summaries: – these demonstrate that the MSP regularly assesses its own ISMS, finds non‑conformities, and follows through with corrective actions rather than waiting for external audits to discover problems.

Surveillance and recertification outcomes: – high‑level results from external audits show that an independent body also tests conformance between major certification events, and whether improvement actions are being closed on schedule.

Penetration testing and vulnerability assessments: – appropriately sanitised reports can show what was tested, which issues were found, how they were classified, and how quickly they were remediated for systems relevant to your services.

Vulnerability management metrics: – trends for patch deployment, average time to remediate high‑severity issues, and the volume of outstanding vulnerabilities on platforms that process your information.

Supplier and sub‑processor assessments: – evidence that the MSP manages third‑party risks in a way that supports your ISO 27001 and NIS 2 expectations, rather than blindly trusting upstream suppliers.

Training and awareness records: – data on completion rates for security training, phishing exercises, and role‑specific awareness activities for staff involved in delivering your managed services.

Certification bodies and assurance providers describing ISO 27001 programmes, such as TÜV’s overview, commonly reference these kinds of artefacts as typical components of an effective ISMS assurance regime. In many cases, you will see summaries, trends, and sample artefacts rather than full, confidential reports, which is usually reasonable. The key is that you can see regular checks, clear findings, and follow‑through that relate directly to your services. A practical step is to define which evidence types you expect for each strategic MSP and record what you receive during annual reviews.

Metrics and questions that make “ongoing” real

To make “ongoing” more than a buzzword, you can request and track specific metrics over time that directly affect your risk picture. This also makes it easier to brief internal stakeholders without overwhelming them with raw data.

Useful metrics include:

The number and severity of open versus closed findings from internal audits and technical tests across systems that support your services.
Average time to remediate critical vulnerabilities on those systems, compared with agreed targets.
Frequency and scope of continuity or recovery tests affecting your services, and whether objectives were met.
Training completion rates for staff with privileged access to your environments or customer data.
The number, impact, and root‑cause themes of incidents affecting your managed services over the last year.

Your questions might include:

“How often do you conduct internal ISMS audits, and when was the last one that covered systems used for our services?”
“What service‑level targets do you set for resolving high‑severity vulnerabilities, and how well have you met them over the last twelve months?”
“How do you share lessons learned from incidents or tests that could affect our risk picture, including any regulatory or customer notifications that followed?”

Stronger MSPs will be able to show clear metrics, trends over time, and examples of how those metrics have driven improvements, a pattern echoed in third‑party‑risk and cyber‑maturity research from consulting firms such as KPMG. Weaker MSPs often respond with static statements such as “we patch promptly” without backing them up. Once you understand the pattern of behaviour over time, you can standardise the way you ask for, record, and compare those answers across providers, rather than treating every engagement as a one‑off exercise.

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

Book your demo

How do you turn ISO 27001 questions into a control‑mapping playbook for managed services?

You turn ISO 27001 questions into a control‑mapping playbook by standardising the structure of the questions you ask, the way MSPs respond, and how those responses map to controls, responsibilities, and evidence. The playbook becomes a reusable backbone for MSP due diligence, comparison, onboarding, and ongoing governance across security, risk, vendor‑management, and procurement teams.

Around 41% of organisations in the 2025 ISMS.online survey said that managing third‑party risk and tracking supplier compliance was one of their main security challenges.

Instead of reinventing your approach every time a new provider appears, you create a consistent template that any MSP can complete and your teams can interpret quickly. Over time, this gives you a portfolio‑wide view of MSP maturity that you can explain to boards and regulators without diving into every individual contract, because the format and scoring are already understood.

Designing a reusable mapping template

A good playbook template typically has three layers that work together: structured questions, control mappings, and commentary or scoring. Keeping those layers consistent across providers is more important than getting every detail perfect on day one.

A practical template usually includes:

Questions – prompts aligned to key ISO 27001 topics such as scope, risk assessment, Annex A controls, shared responsibility, evidence, and privacy or regulatory obligations where applicable. For example:

“Describe how your ISMS scope covers this service.”
“Provide an Annex A mapping for this service with responsibilities.”

Control mapping – a table that, for each relevant Annex A control:

States whether it is provider‑owned, customer‑owned, or shared.
Links to a short description of implementation.
Points to evidence types and locations, including any links to your own processes.

Scoring and commentary – a way to rate the clarity and strength of answers and record comments, gaps, or follow‑up actions you want the MSP to address.

When you use this template across all MSPs, you gain a comparable view of their maturity and fit. Procurement, security, GRC, legal, privacy, and vendor‑risk functions can all refer to the same artefact without creating separate questionnaires or spreadsheets that drift out of sync. Revisiting the playbook at least annually, or when services or regulations change, keeps the picture current rather than letting it become another stale repository. As a neutral next step, you can pilot the template with one or two high‑risk providers before rolling it out more widely.

Turning answers into a comparative scorecard

Once your template is in place, scoring becomes more systematic and less about personal impressions. You can weight the topics that matter most to your organisation, then evaluate each provider consistently against those criteria.

Typical practices include:

Weighting certain areas more heavily, such as:
Clarity and completeness of scope description.
Depth and specificity of Annex A mappings.
Quality and freshness of ongoing evidence.
Precision of shared‑responsibility definitions.
Alignment with your own risk appetite and regulatory profile.

Defining what a “strong” answer looks like in advance, so evaluating responses is less subjective and easier to explain to stakeholders.

For example, for a question such as “How do you handle incidents involving our data?”, a strong answer might include defined detection and triage processes with clear ownership, agreed notification timelines and channels tied to severity and regulatory thresholds, joint investigation and root‑cause analysis steps, and links to recovery objectives that align with your business impact analysis. A weak answer might simply say “We investigate and inform you where necessary”, with no detail on timing, roles, or evidence.

By applying this playbook consistently, you build a library of MSP profiles grounded in ISO 27001, not in marketing. Aligning it with your internal ISO 27001 processes makes it even more powerful: the playbook can feed management reviews, risk register updates, SoA changes, and board reporting. Storing the templates, mappings, and scores in a collaborative ISMS platform such as ISMS.online then lets you reuse the work across audits, renewals, and new projects, rather than starting from zero each time a stakeholder asks, “How do we know our MSPs are really aligned to ISO 27001?”

Book a Demo With ISMS.online Today

ISMS.online gives you a single shared place to structure ISO 27001 questions, control mappings, and evidence with your MSPs so third‑party assurance becomes faster, clearer, and easier to defend. Instead of juggling certificates, spreadsheets, and email threads, you can see how internal and external controls work together to protect your organisation and satisfy your stakeholders.

Why a shared ISMS platform helps both you and your MSPs

A shared ISMS platform helps you and your MSPs keep answers consistent, evidence centralised, and assurance repeatable even as services, controls, and regulations change. When enterprise security teams and MSPs try to collaborate through static documents alone, three problems recur again and again.

Common problems include:

Answers drift out of sync as services evolve.
Evidence lives in multiple tools and is hard to tie back to controls.
Each audit or request for proposal forces both sides to rebuild the same explanations.

A shared ISMS platform changes that dynamic. With ISMS.online, you can capture your standard ISO 27001 MSP question set once and reuse it across providers. You can store service‑specific Annex A mappings and shared‑responsibility matrices in the same structure you use for your internal controls. You can link MSP evidence such as audit summaries, test reports, and key metrics directly to the controls and risks they support.

That structure helps your MSPs as well. They can respond to multiple customers from a single, authoritative set of mappings and evidence, rather than recreating content for each questionnaire. Over time, this reduces friction on both sides and raises the quality of assurance conversations instead of turning them into paperwork exercises. Even if you later change providers, having a consistent model makes the transition far easier to explain to boards and regulators.

Practical next steps to explore ISMS.online

If you recognise the challenges described here, you do not need to redesign your third‑party governance from scratch. A focused trial is often enough to demonstrate value without committing to a wholesale transformation, and you can run it alongside your current processes.

You might:

Choose one or two strategic MSPs that support high‑impact services.
Use your existing ISO 27001 question set as a starting point.
Configure a simple mapping template and shared‑responsibility model in ISMS.online.
Invite your MSP counterparts to collaborate on completing and refining the content.
Use the output to brief your board or audit committee on how third‑party controls are now integrated into your ISMS.

Using a shared environment in this way can help you build clearer mappings for critical services, reduce surprises in audits involving MSPs, and develop a more confident storey for regulators and major customers. Booking a demo is simply a way to see how this could look in your own environment and to decide whether a shared ISMS platform is the right way to manage it.

If you are also planning or undergoing a transition to ISO 27001:2022, the same environment can help you update Annex A mappings to the revised control set for both internal and MSP‑operated services. Transition guidance for ISO/IEC 27001:2022 notes that organisations need to update Annex A mappings, scope descriptions, and documented information, and using a shared environment that supports both internal and MSP‑operated services can make those updates easier to coordinate, as highlighted in ISO 27000 series overviews such as the ISO 27000 introduction. Any decision to adopt new tooling or change providers should still go through your usual governance processes and, where appropriate, be reviewed by qualified legal or regulatory advisers.

Ultimately, your ISO 27001 questions to MSPs are about more than due‑diligence checklists. They are about showing that your extended digital ecosystem behaves like a coherent, risk‑based management system that boards, regulators, and customers can trust. Booking a demo with ISMS.online is a straightforward way to explore how that coherence could work in practice for your organisation and your most important providers, and to see whether a shared ISMS platform can help you turn good questions into durable third‑party assurance.

Book a demo

Frequently Asked Questions

How do we align MSP due‑diligence with ISO 27001:2022 without drowning stakeholders in clause numbers?

You align MSP due‑diligence with ISO 27001:2022 by framing questions around business outcomes-risk, uptime, data handling and accountability-and only mapping those answers back to clauses and Annex A controls inside your own ISMS.

How do we turn ISO 27001 into themes that business and MSPs actually recognise?

Start from the conversations you already have with stakeholders and managed service providers, then anchor them to a handful of repeatable themes:

Service and scope fit: – “Which of your services, locations, platforms and sub‑processors will actually touch our data, and are they inside your ISMS scope?”
Risk and resilience: – “Where do our availability, confidentiality and regulatory risks appear in your risk register, and how are they treated?”
Control ownership and testing: – “For this service, which Annex A:2022 controls are in place, who owns them, and how are they tested over the year?”
Operational assurance over time: – “What have internal audits, penetration tests, monitoring and incident reviews told you about this service in the last 12–18 months?”
Shared responsibility: – “For access, configuration, monitoring, incidents, continuity and supplier management, which activities do you own, which do we own, and what is genuinely shared?”
Change and roadmap: – “How do new services, platform migrations and regulatory changes flow through your scope, risk assessments and controls?”

Those themes give you a stable backbone for MSP due‑diligence questionnaires, RFPs and renewal reviews. Internally, you can maintain a clean mapping from each theme and question back to ISO 27001:2022 clauses, Annex A controls and supplier‑management processes in your ISMS or Annex L‑aligned integrated management system. Externally, your MSP only sees clear, service‑level questions rather than clause citations.

If you are using a platform such as ISMS.online, it is straightforward to store the question set, answers and mappings alongside your Statement of Applicability and supplier records. That way, you can quickly show auditors how third‑party oversight is built into your ISMS rather than improvised around procurement deadlines.

How can we design MSP questions that trace to ISO 27001 clauses without quoting them?

Work forwards from real situations and backwards from ISO 27001, not the other way round:

Context, leadership and planning (Clauses 4–6):

Ask how the MSP defines scope, understands customer needs and plans risk treatment that could affect you:
“Show us how risks relating to our data, uptime and regulatory obligations are identified, evaluated and prioritised in your risk register.”

Support and operation (Clauses 7–8):

Focus on people, documented procedures and how the managed service actually runs:
“Which documented procedures and competencies are required to deliver this service, and how do you keep both current?”

Performance evaluation and improvement (Clauses 9–10):

Explore how they monitor effectiveness, audit themselves and drive changes:
“Over the last year, which audits, KPIs and corrective actions have directly related to the systems we would rely on?”

You do not need to ask “How do you comply with Clause 8.1?” for your own ISO 27001:2022 implementation to be defensible. What you do need is a consistent set of questions that reveal how the MSP’s management system behaves for your services, and a disciplined way of mapping those answers back to clauses and Annex A controls inside your own ISMS. Centralising that mapping in a shared environment such as ISMS.online means your team can keep refining questions while preserving a clear audit trail for regulators, customers and certification bodies.

How can we quickly tell whether an MSP’s ISO 27001 certificate genuinely covers the services we plan to use?

You can tell whether an MSP’s ISO 27001 certificate genuinely covers your services by reading the scope, Statement of Applicability and recent audit reports as if they were your own, then testing any gaps with concrete, service‑level questions.

Which parts of the certificate pack matter most for MSP services?

Treat the documentation as risk evidence, not sales collateral:

Scope description: – Check that it names the specific service types you care about (for example, managed SOC, managed database, managed identity, managed hosting) and the key technologies and platforms involved.
Locations and delivery chain: – Confirm that data centres, support locations and important sub‑processors for your workloads are explicitly in scope, or clearly fall under a broader scoped entity.
Control applicability: – Look at Annex A:2022 control applicability in the SoA; challenge exclusions around logging, monitoring, backup, continuity, supplier oversight and secure development where your own risk assessment treats those areas as non‑negotiable.
Audit recency and focus: – Note when the last surveillance or recertification audit took place, and whether recent findings relate to the environments and services you expect to consume.

Then move straight to pointed questions, for example:

“Of the services we are evaluating, which are fully in your current ISO 27001 scope, which are only partly covered, and which are out of scope today?”
“For systems supporting our data that fall outside your certified scope, what controls and assurance mechanisms apply instead?”

Capturing those answers in your supplier‑risk records makes your choice defensible if your own auditors, board or customers later ask why you trusted a particular provider.

If you organise supplier evidence and notes in a system like ISMS.online, you can store scope statements, key SoA extracts, your questions and the MSP’s responses alongside the Annex A controls and risks they support. That allows you to reuse the same assessment when you renew, retender or go through surveillance yourself, instead of starting from a blank spreadsheet each time.

What are the practical red flags in MSP scope and SoA documents?

You do not need to be an ISO specialist to spot patterns that merit extra scrutiny:

Scope that is obviously narrower than delivery reality: , such as a certificate that only covers “head office operations” when real service delivery runs from multiple regions and cloud platforms.
Overly promotional wording: in place of concrete information about assets, systems and responsibilities.
Out‑of‑date audits: or an unclear surveillance schedule, which can indicate drifting practice.
Clusters of “not applicable” controls: in areas your own risk register treats as material, especially monitoring, backup, continuity, supplier oversight or secure development.

When something looks vague, ask the MSP to walk you through one specific service you care about: where your data would reside, which teams could interact with it, and exactly which aspects of their ISMS scope and controls cover those components. Strong providers will give you a consistent, testable storey. You can then attach that narrative as structured evidence in your own ISMS so that, when questions return from customers or auditors, you are relying on a clear record rather than recollection.

How should we agree shared responsibility with an ISO‑certified MSP so nobody is surprised in a real incident?

You should agree shared responsibility with an ISO‑certified MSP by taking the Annex A:2022 controls that touch both organisations, deciding who does what for each, and then reflecting that split consistently in contracts, runbooks and your ISMS.

Which areas of shared responsibility deserve the most attention?

Start where ambiguity becomes expensive during day‑to‑day operations or incidents:

Risk management and planning:

Make the link between your business risks and the MSP’s technical risks explicit.
– Ask how scenarios from your risk register-such as loss of a region, compromise of privileged access or regulatory breach-appear in their risk assessment and treatment plans.
– Build a concise RACI that covers access reviews, configuration baselines, vulnerability management, monitoring, backup and restore, and regular supplier review.
– Store that RACI in your risk treatment records, SoA and vendor notes so auditors and managers see the same picture.

Detection, response and communication:

– Clarify which alerts and telemetry the MSP is expected to monitor, which your own team must monitor, and how incidents flow between the two.
– Agree thresholds and timelines for incident notification, and which organisation leads communications to regulators, customers and data subjects under laws such as GDPR or sector rules.
– Document these flows in joint runbooks and rehearse them with realistic tabletop scenarios.

Continuity and recovery:

– Confirm that the MSP’s recovery time and recovery point objectives align with your business impact analysis and contractual promises.
– Ask them to distinguish clearly between disruptions they are accountable for (for example, platform failure) and those you own (for example, local network or endpoint compromise).

Request that the MSP walks you through a complete, service‑specific incident scenario: which metrics trigger action, who picks up the first response, when your team becomes involved, and how lessons are captured on both sides. Once that model works for one strategic service, you can mirror it across other MSPs and capture it centrally in a platform such as ISMS.online, linking each shared‑responsibility map to the relevant Annex A controls, risks and contracts.

How do we keep the shared‑responsibility model aligned with ISO 27001 and an Annex L‑integrated system?

Use ISO 27001:2022 and any companion standards as the structural backbone rather than an after‑thought:

Identify the Annex A controls that obviously span provider and customer-for example, those on logging and monitoring, secure configuration, backup, supplier management, network security and incident management-and decide whether each is primarily your responsibility, theirs, or shared.
Reflect those decisions in your planning activities under Clause 6 and operational descriptions under Clause 8, so outsourcing choices and interfaces appear in risk treatment plans, documented procedures and outsourced‑process notes.
Ensure the same allocation is respected when you perform performance evaluation under Clause 9 and improvement under Clause 10, so joint incidents drive corrective actions in both organisations’ management systems rather than just in operational ticket queues.

If you are running an Annex L‑aligned integrated management system that combines ISO 27001 with standards such as ISO 22301 for continuity or ISO 27701 for privacy, reuse the same shared‑responsibility logic there. Reviewers should be able to follow a straight line from a managed service through security, continuity and privacy responsibilities without finding contradictory assumptions in different parts of your IMS.

What evidence should we ask MSPs for to prove ongoing ISO 27001 practice, not just a framed certificate?

You should ask MSPs for evidence that shows how their ISMS and Annex A controls operate over time for the services you depend on-recent, structured artefacts that demonstrate planning, operation, measurement and improvement across at least the past year.

Which types of MSP evidence stand up best under internal and external audits?

Prioritise a small set of artefacts that map cleanly to controls and real changes:

Internal ISMS audit reports or snapshots: – which controls were sampled, what non‑conformities or weaknesses were found, and how corrective actions were tracked to closure.
External surveillance or recertification summaries: – outcomes from the certification body, with any findings or observations that involve your services, platforms or delivery locations.
Security test results: – scoped penetration tests and vulnerability scans for systems underpinning your workloads, with a clear remediation plan and status for significant findings.
Vulnerability management metrics: – trends in remediation times, counts of open issues by severity and any formally accepted exceptions.
Supplier and sub‑processor oversight: – documents or dashboards showing how they assess and monitor their own strategic suppliers and cloud platforms.
Training and awareness indicators: – evidence that people who design, operate and support the managed services have completed relevant security and privacy training.

Pair these with direct questions such as:

“How frequently do internal audits, technical tests and management reviews cover systems that support the services we will use, and what changes did you make as a result?”
“What target do you set for closing critical and high vulnerabilities, and how have you performed against those targets over the last 12 months?”

You rarely need raw event logs or every detail from their tools, but you do need enough current, structured proof to demonstrate that the MSP’s ISMS is active and effective. Agreeing in advance what your organisation defines as a “complete evidence pack” and including that expectation in your supplier‑management procedure reduces friction later and makes your own ISO 27001 and integrated‑system audits more straightforward.

How can we file and reuse MSP evidence effectively inside our ISMS or Annex L IMS?

Handle MSP evidence with the same structure and discipline you expect internally:

Link each artefact to specific controls and services: – associate documents with the relevant Annex A:2022 controls, risks, supplier records and service definitions, so you can explain exactly what each piece of evidence supports.
Tag ownership and review cadence: – record who is responsible for reviewing the evidence, how often it must be refreshed, and any conditions or accepted residual risks.
Reuse where appropriate across frameworks: – for example, a penetration test that covers systems in scope for ISO 27001, SOC 2 and NIS 2 should be referenced once in a way that satisfies all three regimes, rather than being duplicated in separate silos.

A shared ISMS platform such as ISMS.online makes that linkage and reuse practical: MSP evidence can be attached directly to controls, risks, audits and supplier records. When senior stakeholders or auditors ask, “How do you know this MSP is still operating securely and in line with your policies?”, you can walk them through the linked items on‑screen instead of searching drives and email threads.

How can we compare ISO 27001 maturity across several MSPs without bringing in consultants every time?

You can compare ISO 27001 maturity across MSPs by asking each provider the same structured question set and converting their answers into a simple scoring model that reflects your risk priorities, rather than trying to weigh every response in isolation.

What does a practical MSP scorecard look like when based on ISO 27001?

A useful scorecard stays compact enough for non‑specialists to understand but rich enough to drive decisions:

Scope and certificate fit (1–5): – how clearly the MSP’s certified scope covers the services, locations and platforms you plan to use.
Service‑specific control mapping (1–5): – how well they map Annex A:2022 controls and other relevant controls to your services and data flows, with named owners.
Shared‑responsibility clarity (1–5): – how unambiguous their contracts, SLAs and RACIs are about “who does what” for risk treatment, monitoring, incidents and continuity.
Evidence depth and freshness (1–5): – how comprehensive and up to date their audit outputs, tests, metrics and supplier reviews are for the environments you rely on.
Openness and responsiveness (1–5): – how readily they provide extra detail, acknowledge gaps and commit to realistic improvement plans.

You can weight these dimensions to match your sector and obligations. For example, an organisation regulated for operational resilience might weight continuity and evidence higher; a fast‑growing SaaS provider might emphasise transparency, security testing depth and platform competence.

Running this scorecard jointly with procurement, legal, security and business sponsors gives you a common language for explaining why one MSP represents a better overall risk fit, even where commercial terms appear similar. Recording the underlying answers, scores and rationale in your ISMS-rather than just in a slide deck-means you can reuse and update the assessment at renewal and during audits, instead of rebuilding justification from memory each time someone asks “why did we pick this provider?”.

How can an MSP scorecard remain useful across different standards and regions?

A good scorecard focuses on behaviours and assurance mechanisms that multiple standards and regulators care about, not just ISO 27001 paperwork:

You can apply the same core model to MSPs who also support regimes such as PCI DSS, SOC 2, NIS 2 or DORA, because you are assessing how they scope services, implement and test controls, manage suppliers and communicate risk.
Boards and regulators see a consistent, comparable view of third‑party risk across security, continuity and privacy, rather than a patchwork of distinct questionnaires for each framework.
Your Annex L integrated management system gains a repeatable way of addressing external issues and interested parties under Clause 4, regardless of which specific standards are in force at any given time.

As you accumulate results, the scorecard becomes a living reference point. You can refine questions, adjust weights when regulations or business risk appetite change, and build internal benchmarks that make each new MSP assessment faster, more consistent and easier to defend to senior stakeholders.

When does it make sense to move MSP oversight into a shared ISMS platform instead of living in email and spreadsheets?

It makes sense to move MSP oversight into a shared ISMS platform when your team is repeatedly chasing the same ISO 27001 information from several strategic providers, struggling to keep evidence and mappings current across documents, and finding it hard to present a coherent picture of third‑party risk to your leadership or auditors.

What practical gains should we expect from managing MSPs inside a shared ISMS platform?

Starting with one or two high‑impact managed services can quickly show whether this model works for you:

Aligned control structures: – your ISO 27001 question sets, service‑specific Annex A:2022 control matrices, shared‑responsibility splits and risk records sit together in one environment that both your team and the MSP can access under controlled permissions.
Live, central evidence: – internal and external audit summaries, penetration‑test reports, vulnerability metrics and supplier assessments can be linked directly to the controls, risks and services they support, so you can respond to “show me” requests without searching through folders.
Single source for multiple audiences: – the same structured information supports board packs, risk‑committee updates, customer due‑diligence responses and certification audits, without asking the MSP for the same data in several different formats.
Faster assessments and renewals: – when you can view scope, control coverage, evidence and scorecard results side by side inside your ISMS, comparing providers and justifying renewals becomes less of an ad‑hoc spreadsheet exercise.

A sensible first move is to choose a service that matters to your business-such as managed security monitoring or a core cloud platform-set up a simple, ISO‑aligned structure for that service in a tool like ISMS.online, and invite the MSP to contribute evidence and refinements there. If, after a quarter, you can walk your board, audit committee or major customers through that shared view without last‑minute hunting for documents, you have strong proof that extending the approach to other MSPs will pay off. At the same time, your own ISMS or Annex L‑integrated system matures, because third‑party oversight becomes part of routine management rather than a yearly paper chase.

Top ISO 27001 Questions Enterprise Security Teams Ask MSPS