Why MSP supply chains are now your biggest attack surface
Modern managed service providers face growing risk from ICT supply chains, not just from their own data centres. Upstream tools, platforms and partners can become single points of failure that, when compromised or unavailable, affect many customers and services at once. Annex A.5.21 exists to help you understand those dependencies, agree clear security expectations with suppliers and customers, and treat supply chain risk as a deliberate part of your ISMS rather than an afterthought.
For many managed service providers, the supply chain of tools, platforms and partners you depend on has become one of the riskiest parts of your environment, alongside your own data centre. Those shared components underpin your revenue, your contracts and your regulatory promises. When one of them fails or is compromised, the impact can cascade across many customers in hours, which is why Annex A.5.21 is so important for turning that web of dependencies into something you consciously design and manage.
Modern MSPs inherit risk from the multi‑tenant nature of remote management platforms, cloud services, identity providers and niche tools that sit between you and your customers. A single upstream compromise can give an attacker privileged access into a large slice of your customer base. Equally, an outage in a core platform can take several clients offline at once, regardless of how well you run your own infrastructure.
Strong supply chains start with knowing who you really depend on.
The new reality of MSP supply chain risk
The new reality for MSPs is that attackers and outages now travel through shared ICT platforms faster than they travel through individual customer networks. As you stack remote management tools, cloud services, identity platforms and security products into your offerings, each shared component becomes a potential single point of failure. Annex A.5.21 is designed to help you recognise that reality and build proportionate controls around it.
Modern MSPs inherit most of their supply‑chain risk from the cloud platforms, SaaS tools and subcontractors they stack into their services. As you assemble new offerings, it is natural to keep adding specialised platforms, monitoring tools, backup providers and security services on top of a core set of capabilities.
The State of Information Security 2025 report shows that a majority of organisations experienced at least one security incident in the past year that originated from a third-party or vendor.
Over time, that growth creates dense, multi‑tier dependency chains: remote monitoring tools on top of public cloud, identity platforms linked into customer tenants, backup providers replicating data between regions and specialist security tools integrated through APIs. Attackers do not need to target each customer individually. Compromising one upstream service can grant privileged access into many managed environments, or allow ransomware to spread quickly between clients that share the same tooling. Analyses of software supply‑chain incidents describe exactly this pattern, where compromise of a widely used vendor or component can impact a large number of downstream organisations at once (software supply-chain attack analysis).
Outages behave in the same way. A failure in a central identity provider or remote management stack can take multiple customers offline, trigger contract penalties and draw regulatory attention even if your own infrastructure is unaffected. Industry guidance on assessing and managing supply‑chain cybersecurity risk often highlights how disruption or compromise of shared cloud or identity services can drive simultaneous outages and business impact across many customers, as well as contractual and regulatory consequences for providers that rely on them (supply‑chain cybersecurity risk overview). Annex A.5.21 is aimed squarely at that combined technical and contractual blast radius, not only at isolated vulnerabilities.
Security metrics in many MSPs have not caught up with this shift. Teams still track perimeter events, patching rates and endpoint alerts, but have little visibility of inherited vulnerabilities or supplier‑driven incidents. Without a clear view of upstream dependencies and their risk profiles, you are effectively running blind in the places where failures are most likely to hurt, which is why you need supply‑chain views inside your ISMS rather than network metrics alone.
Where visibility really breaks down
Visibility usually breaks down in the “shadow” supply chain: tools, services and partners that slipped in outside formal procurement. These often look like one‑off decisions at the time, but they become part of your permanent dependency map.
Most MSPs can list their primary vendors from memory, yet few can show a complete picture of who and what they truly rely on. Freemium services adopted by engineers, “temporary” pilot tools that never ended and customer‑mandated platforms you agreed to support all add to that hidden layer.
The problem is that attackers and regulators do not care whether a dependency was formally approved or quietly adopted. If a compromise passes through it into your managed environments, customers will still expect answers from you. Annex A.5.21 treats these relationships as in scope. It expects you to bring them into your supply chain map, classify them and decide what “secure enough” means for each based on risk.
A practical first step is to map the blast radius of your most critical shared components. For every major tool or platform, estimate how many customers, which types of data and which services depend on it. Seeing that a single remote management stack underpins a significant part of your revenue is often the moment when supply chain risk stops feeling abstract and starts to demand structured controls.
Annex A.5.21 and the new definition of ICT supply‑chain assurance
Annex A.5.21 asks you to agree, document and maintain appropriate information‑security expectations with the ICT suppliers and customers you depend on. In practical terms, you should know who you rely on, what you expect from them, what they expect from you and how those expectations are checked over time. For an MSP, that means recognising that you sit inside many customers’ ICT supply chains as well as managing your own. This reflects the way ISO/IEC 27001:2022 describes control A.5.21 in its catalogue of information‑security controls for ICT supply chains (ISO/IEC 27001:2022 overview).
Almost all organisations in the 2025 ISMS.online survey listed achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority.
Taken seriously, Annex A.5.21 shifts ICT supply‑chain assurance from gut feel to risk‑based, documented practice. It builds on the wider family of Annex A controls for supplier relationships, contracts and monitoring, and applies them specifically to ICT products and services. Understanding how it fits alongside A.5.19, A.5.20 and A.5.22 gives you a framework for doing this without reinventing your entire ISMS.
An integrated ISMS platform such as ISMS.online can help you keep that picture in one place by linking suppliers, customers, services, risks and Annex A controls so they are easy to review and update as your business evolves.
This information is general and does not constitute legal advice; organisations should seek appropriate professional guidance for regulatory decisions.
What Annex A.5.21 actually expects
Annex A.5.21 expects you to treat ICT supply chain security as a continuous, shared responsibility rather than a one‑off contract clause. It reinforces the idea that expectations should be risk‑based, documented and maintained over time instead of assumed or set once and forgotten. For MSPs, that means designing upstream and downstream expectations and checking that they continue to make sense as services and risks change.
Annex A.5.21 sits alongside three closely related controls:
- A.5.19, which covers policies for supplier relationships.
- A.5.20, which focuses on ensuring information security is addressed within supplier agreements.
- A.5.22, which deals with monitoring, review and change management of supplier services.
Together, these controls can be read in everyday language as: identify your ICT supply chain, define the information‑security requirements you expect from it, embed those requirements in how you select, contract with and oversee suppliers, and keep the oversight going as services change. Annex A.5.21 is where this becomes specifically about ICT services and products, both upstream and downstream. These control titles and groupings follow the structure published in ISO/IEC 27001:2022, which sets out the Annex A controls and their focus areas for supplier and ICT supply‑chain security (ISO/IEC 27001:2022 overview).
For an MSP, there is an additional twist. You are both a customer and a supplier. You rely on upstream ICT services to deliver your offerings, and you are a critical supplier in your customers’ own ICT supply chains. Annex A.5.21 expects you to manage both sides consistently in a way that reflects risk and is embedded into everyday processes, not handled in isolated documents.
Turning standard text into something everyone can understand
Your teams are more likely to engage if you translate the standard’s language into a small set of clear, practical commitments. These commitments should describe what you actually do, in terms that engineers, account managers and legal teams recognise, rather than quoting the standard.
You might restate Annex A.5.21 as commitments such as:
- “We vet and classify the ICT suppliers and platforms we rely on and use them when they meet agreed security criteria.”
- “We define and document who is responsible for which security measures in every managed service we sell.”
- “We monitor key suppliers and services over time and respond promptly and transparently when something changes or goes wrong.”
Once you have these translations, it becomes much easier to see where you already have parts of Annex A.5.21 in place, such as supplier onboarding checks, contract templates or periodic reviews. It also highlights where practices are ad hoc, undocumented or depend on individual staff. That mapping gives you a starting point for the more detailed upstream and downstream design work that follows.
Annex A.5.21 expects your requirements to be proportionate to risk rather than copied blindly from one relationship to another. High‑impact suppliers and customers usually need deeper diligence and stronger obligations than low‑impact ones, and the same principle makes your downstream contracts more defensible to regulators and auditors.
The control does not imply that you need to impose identical detailed security expectations on every supplier or customer. It expects you to justify your expectations in light of risk. A critical cloud platform that hosts customer data warrants deeper due diligence, stronger contract clauses and more intensive monitoring than a low‑risk, non‑critical tool.
The same logic applies downstream. A managed service delivered to a hospital or financial institution carries different obligations and scrutiny from one delivered to a small, unregulated business. Your implementation of Annex A.5.21 is credible when those differences are visible in your risk assessments and in the way you structure agreements, not when every relationship uses copy‑and‑paste wording regardless of impact.
Aligning Annex A.5.21 with frameworks you already use, such as SOC 2, recognised cybersecurity guidance or national supply chain recommendations, can help. Best‑practice supply‑chain guidance from security vendors and practitioners encourages you to map common control objectives across standards such as ISO 27001, SOC 2 and national cybersecurity frameworks so teams are not maintaining multiple, conflicting sets of requirements (overview of supply‑chain security practices). Here, “tiering” simply means grouping suppliers and customers into a few impact‑based levels, rather than treating each relationship as unique.
ISO 27001 made easy
An 81% Headstart from day one
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.
Upstream vs downstream controls in an MSP context
In an MSP, “upstream” covers the vendors, platforms and subcontractors you rely on, while “downstream” covers the customers and tenants that rely on you. Annex A.5.21 is easier to implement when you treat these relationships as distinct but linked, with clear responsibilities and expectations in each direction. That structure turns abstract supply chain concerns into contracts, playbooks and dashboards that people can act on.
A clear upstream/downstream model turns standard text into workable contracts, runbooks and dashboards. You can define how you select and monitor suppliers, how you share responsibility with customers and how you respond when incidents occur in either direction. Once this structure exists on paper, operationalising it in tooling and behaviour becomes much more straightforward.
Defining upstream, downstream, and hybrid relationships
Your first job is to name and classify the external relationships you depend on instead of treating them all as generic “suppliers” or “customers”. This classification shapes which parts of Annex A.5.21 apply most strongly and where to focus your design effort. It also creates a common language inside your organisation when you discuss supply chain risk.
Start by listing external parties and classifying them along two dimensions: do they supply you, or do you supply them, and how critical are they to your services? An upstream ICT supplier might be a cloud infrastructure provider, a remote monitoring tool, a backup platform or a specialist security partner. Downstream parties are your managed service customers, including those where you act as a data processor under data‑protection law.
Some relationships are hybrid. A peer MSP in a co‑managed arrangement both supplies certain capabilities to you and relies on your services in return. A customer that hosts their own cloud tenant but asks you to administer it blurs the line between customer platform and upstream environment. These hybrids require particular care, because it is easy for important responsibilities to be assumed by both sides or by neither.
Once you have these roles recorded, you can begin to define which categories of controls apply to which roles. For upstream relationships, due diligence, secure technical integration, incident notification and sub‑processor controls become central. For downstream relationships, shared responsibility, baseline security expectations and customer obligations are more prominent. Hybrid arrangements require a blend and very clear boundaries to prevent gaps.
Using risk‑based tiers to bring structure
Risk‑based tiers turn a long list of suppliers and customers into something you can work with. By grouping relationships into a few impact‑based classes, you can define standard control sets for each tier rather than designing every relationship from scratch.
You might, for example, create three tiers for upstream suppliers:
- Tier 1: critical platforms with privileged access or hosting customer data.
- Tier 2: important supporting services with limited direct access to customer systems.
- Tier 3: low‑risk tools with no access to sensitive data or production environments.
Downstream, you might adopt tiers such as “regulated”, “high‑availability” and “standard”, based on the sensitivity of data and the business impact of outages.
Each combination of upstream and downstream tiers drives different expectations. A Tier 1 upstream platform underpinning a regulated healthcare client demands deeper assurance and more stringent controls than a Tier 2 tool supporting a standard client. Documenting these combinations in simple patterns-for example, “MSP–hyperscaler–regulated client” versus “MSP–distributor–MSP–enterprise”-lets you design standard control sets instead of starting from scratch for each new relationship.
A concise way to visualise this is through a small matrix that shows how responsibilities differ by relationship type.
| Relationship type | Upstream responsibilities (examples) | Downstream responsibilities (examples) |
|---|---|---|
| MSP – cloud platform – regulated client | Certifications, incident notice, segmentation, access logs | Approvals, data protection duties, customer security communication |
| MSP – SaaS security tool – mixed clients | Secure integration, role design, monitoring, vendor review | Customer awareness of tool scope, consent where needed |
| MSP – peer MSP (co‑managed) – client | Boundary definition, joint incident handling, shared access | Customer understands split of duties and escalation paths |
As the table suggests, responsibilities change significantly between, say, a hyperscaler scenario and a co‑managed MSP arrangement. In practice, you can start by mapping your current relationships into one of these patterns, confirming which duties fall where and then standardising your contract clauses and internal runbooks around those patterns.
Designing upstream controls for vendors and sub‑processors
Upstream controls define how you select, onboard, monitor and exit the suppliers and platforms you rely on. A simple, repeatable lifecycle turns vendor trust from assumption into evidence backed by risk assessments, contracts and configuration. Annex A.5.21 expects that lifecycle to be proportionate to risk and applied consistently to suppliers that matter most.
Good upstream design converts trust from an informal judgement into a documented decision. That means understanding what each supplier does for you, what risks you inherit, which controls they operate and which ones you must provide yourself. A risk‑based lifecycle makes this manageable and gives auditors confidence that you are not treating suppliers as a black box.
Building a supplier lifecycle that auditors recognise
Auditors generally look for a clear, risk‑based lifecycle for critical suppliers: how you assess a supplier before use, how you embed controls when you adopt them, how you keep oversight going and how you exit safely. If you can show those steps and the evidence behind them, your Annex A.5.21 storey will feel credible and complete. Supplier‑risk guidance from institutes such as SANS describes risk‑based supplier lifecycles-covering selection, onboarding, ongoing oversight and exit-as a hallmark of mature third‑party security management (SANS supplier‑risk whitepaper).
The State of Information Security 2025 report indicates that a majority of organisations have already strengthened third-party risk management and plan to invest further in it.
A practical upstream lifecycle has four stages: due diligence before engagement, onboarding, business‑as‑usual oversight and exit. For each stage, define what is expected for each supplier tier and which artefacts should exist to prove that these activities took place.
Step 1: Perform risk‑based due diligence
Risk‑based due diligence is about gathering enough information to understand a supplier’s security posture and how it aligns with your needs. This typically includes independent certifications, high‑level security statements, summaries of testing, roles in processing personal data and information on sub‑processors. The output should be a completed assessment record that explains why the supplier is acceptable at the chosen tier.
Step 2: Onboard with concrete technical and contractual controls
Onboarding turns assessment into concrete controls. For a critical platform, this might include configuring strong authentication, restricting administrative roles, enabling and integrating logging and agreeing incident notification timelines and points of contact. A simple onboarding checklist helps ensure that these steps are not missed and that someone is clearly responsible for each.
Step 3: Maintain business‑as‑usual oversight
Business‑as‑usual oversight needs to be lightweight but real. For high‑impact suppliers, set review cadences to confirm that certifications are maintained, security commitments still hold and no major changes have occurred without your knowledge. For lower tiers, reviews can be triggered by events such as service changes, new data flows or incidents. Records of these reviews, even if brief, show that oversight is active rather than assumed.
Step 4: Exit safely and update your supply chain map
Exit is often overlooked but critically important. When you stop using a supplier or switch to a new platform, there should be a defined process for revoking access, returning or securely deleting data and updating your documentation so your supply chain map remains accurate. A short exit checklist and an updated register entry demonstrate that you have closed the relationship in a controlled way.
Auditors do not expect perfection, but they do expect to see that such a lifecycle exists, is risk‑based and is followed in practice for critical suppliers.
No supplier is perfect, and Annex A.5.21 does not require perfection. It expects you to make informed, documented decisions about the risks you inherit and the compensating controls you apply, and to be able to explain those decisions to auditors and customers.
Not every supplier will meet every ideal control, and not every supplier needs to. What matters is your ability to explain why a relationship is acceptable given the risk it introduces. Tiering helps, but you also need clarity on when you are comfortable inheriting controls from a supplier’s own security framework and when you prefer compensating measures.
For example, if a large cloud provider holds widely recognised certifications and runs to a strong security standard, it is usually reasonable to rely on those for many underlying controls, provided you manage your configuration securely. In contrast, for a smaller specialist platform with less formal assurance, you may decide to limit its scope, require specific contractual commitments or add your own monitoring and testing.
Incident handling deserves special attention. For core platforms, there should be explicit commitments about how quickly you will be notified of a security issue, what information you will receive and how you can coordinate responses to protect your customers. Those expectations are best written into contracts or service agreements rather than left as informal understandings.
Documenting these judgements in your risk register and Statement of Applicability shows auditors that Annex A.5.21 is being applied thoughtfully, not automatically. Your Statement of Applicability is simply your formal list of Annex A controls, where you explain which ones apply, how and why.
Free yourself from a mountain of spreadsheets
Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.
Designing downstream controls for customers and their obligations
Downstream controls define how you share responsibility with customers and what you expect from them to keep services secure. For MSPs, clear downstream controls reduce the risk of being blamed for exposures that sit with the customer and show regulators that you have set appropriate, documented expectations. Annex A.5.21 reinforces the need to make those expectations explicit, enforceable and evidence‑backed.
In practice, downstream control is about setting boundaries and making sure everyone understands them. You define what you do by default, what customers must do and how you will demonstrate that both sides are meeting their responsibilities. When this is done well, conversations about incidents, new requirements or additional services start from a shared understanding instead of a disagreement about who was responsible.
Designing service‑specific shared responsibility models
A useful shared responsibility model tells customers, in plain language, which parts of security you own and which they own for a given service. Different service families have different splits, so each needs its own simple model that mirrors how the service is designed in reality. In this context, a shared responsibility model is simply a clear description of how security duties are divided between you and the customer.
For each service family, build a shared responsibility model that answers three questions:
- What configuration and monitoring do you provide by default?
- What must the customer do to make that effective?
- How will you evidence that both sides are doing their part?
For example, for a managed Microsoft 365 service, your responsibilities might include configuring conditional access policies, enabling logging and monitoring key alerts. The customer’s responsibilities might include keeping user details accurate, enforcing acceptable‑use policies and responding promptly to security notifications. Evidencing the model could involve periodic configuration reports and documented customer approvals.
These models should be written in accessible language, reused across contracts and proposals, and supported by internal playbooks that show your teams how to meet your side of the bargain. When customers understand the model from the outset, later conversations about security incidents or additional obligations become grounded in that shared understanding rather than in ad hoc expectations.
Setting customer obligations and dealing with non‑compliance
Customer obligations describe what customers need to do to make your services effective and to keep their own risk within acceptable bounds. Annex A.5.21 expects you to set those obligations clearly, monitor them where you can and decide in advance how you will handle gaps.
Downstream controls often include obligations such as:
- Maintaining supported operating systems.
- Ensuring staff complete security awareness training.
- Enabling multi‑factor authentication on their own systems.
- Notifying you promptly of relevant changes in their environment.
Those obligations should be appropriate to the service and risk profile, written into contracts or security schedules, and supported by simple mechanisms to gather evidence. That might include periodic attestations, technical checks where you have visibility, or outputs from joint reviews.
It is equally important to decide, in advance, how you will handle non‑compliance. Some gaps can be mitigated; others may lead to exceptions, additional fees or, in extreme cases, refusal to provide a service.
Step 1: Define how non‑compliance is identified
Decide which obligations you can check technically and which rely on customer attestations or review meetings. Capture the checks in your processes or tooling so non‑compliance is visible.
Step 2: Decide who can grant and approve exceptions
Document which roles can approve temporary exceptions, under what conditions and for how long. This avoids on‑the‑spot compromises that later become permanent.
Step 3: Record and review residual risk
Ensure exceptions and non‑compliance cases are recorded in your risk register and reviewed at appropriate governance forums. This shows that you are managing, not ignoring, the residual risk.
Clear downstream models and obligations are attractive to mature customers. They demonstrate that you take their risk seriously and that you are prepared to set and hold sensible boundaries rather than agreeing to vague, unenforceable promises.
Governance, roles, and lifecycle for supply‑chain control
Supply chain security only scales when someone clearly owns it and the rest of the organisation understands their part. Annex A.5.21 becomes sustainable when it is embedded into governance, with defined roles, responsibilities and review rhythms, rather than being left as an informal side task for security. Effective governance is less about creating new meetings and more about asking better questions in the ones you already have.
If supply chain security is treated as “somebody’s problem” without clarity, it will drift. You need to decide who is accountable for the control, who provides input, who carries out specific tasks and how often performance is reviewed. Good governance is about clear decisions and regular feedback, not more meetings.
Effective supply chain governance is asking better questions in existing meetings.
Assigning ownership and RACI across the business
A named control owner gives Annex A.5.21 a clear home, but success depends on coordinated effort across procurement, operations, legal and account management. A simple RACI model makes it obvious who does what, who signs off and who needs to stay informed when supplier or customer risks change.
A practical starting point is to nominate a single control owner for Annex A.5.21, often your information security lead or virtual CISO. That person is accountable for ensuring the control is designed and working, but they cannot execute it alone. Procurement, legal, operations and account management all have roles to play.
A simple RACI (Responsible, Accountable, Consulted, Informed) matrix helps. For example, for onboarding a new Tier 1 supplier:
- Procurement is Responsible for ensuring agreed security clauses are in the contract.
- The information security lead is Accountable for approving the supplier’s risk assessment and tier.
- Legal is Consulted on complex terms, exceptions and liabilities.
- Operations and account management are Informed about obligations that affect how they deliver services.
When this distribution is clear, colleagues stop seeing Annex A.5.21 as “the ISO person’s problem” and start understanding their own part in meeting it.
Choosing governance rhythms that fit operations
Governance works best when supply chain questions are built into meetings that already matter, such as risk committees, management reviews and service reviews. Annex A.5.21 does not require new bureaucracy; it requires you to ask the right questions about suppliers and customers at the right times and record the answers.
Controls are more likely to stay alive when they ride on rhythms the organisation already respects. For supply chain security, that might mean:
- Including key supplier and customer risk topics as standing agenda items at existing risk or service review boards.
- Scheduling periodic reviews of critical suppliers and high‑risk customers in line with contract cycles or significant changes.
- Reviewing supply chain‑related incidents and near misses in post‑incident reviews and feeding lessons learned back into supplier and customer management.
Avoid creating entirely new committees unless you need them; instead, weave Annex A.5.21 into established governance forums. For example, your ISO 27001 management review can explicitly cover performance against supply chain indicators, such as the number of critical suppliers without current assessments, the frequency of supplier‑related incidents or the timeliness of incident notifications.
Governance should also extend to less visible relationships, such as subcontractors used for out‑of‑hours cover or white‑label providers that deliver services under your brand. The supply chain picture is incomplete without them, and incidents involving those parties can be just as damaging. Ensuring they are in scope for risk assessment, contractual controls and oversight is part of credible Annex A.5.21 implementation.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
Integrating A.5.19–A.5.22 with risk, supplier, and change processes
Annex A.5.19–A.5.22 work best when they are woven into processes you already use to manage risk, suppliers, change and incidents. Rather than standing apart as isolated “ISO tasks”, they should be reflected in your risk register, procurement workflow, change management and post‑incident reviews so that supply chain thinking becomes part of daily work. This integration is what turns policy statements into consistent behaviour.
Two-thirds of organisations in the 2025 State of Information Security survey said the speed and volume of regulatory change are making compliance harder to sustain.
Designing policies and models is necessary but not enough. Supply chain controls only work when they are knitted into the forms, tickets and workflows people already use to request changes, onboard new tools, assess risks and respond to incidents. Annex A.5.19–A.5.22 are most effective when they are reflected in how you record risks, take supplier decisions, approve changes and learn from incidents.
Embedding supply chain thinking into everyday workflows
The first step is to make ICT supply chain risk visible alongside other risks. That means creating explicit risk entries for critical services and suppliers and capturing how you plan to treat those risks. Once this is in place, you can add small, mandatory checkpoints to workflows your team already follows so decisions about suppliers and changes automatically reflect Annex A expectations.
Start by ensuring that your central risk register explicitly captures ICT supply chain risks. For each major service and critical supplier, there should be risk entries that reflect the potential impact of their failure or compromise, along with the chosen treatments. This puts supply chain risk alongside other vulnerabilities and helps leadership understand trade‑offs.
Next, integrate supply chain checkpoints into existing workflows:
- Procurement processes should include prompts to check whether a proposed supplier falls into a particular risk tier, whether due diligence has been completed and whether contract templates include the required security clauses.
- Change requests that introduce or replace significant tools or sub‑processors should automatically trigger review of upstream and downstream impacts, not just technical compatibility.
- Service design or onboarding processes for new customers should include steps to apply the appropriate shared responsibility model and confirm that downstream obligations are documented and accepted.
These prompts can often be added to forms and ticket templates with minimal friction, provided they are mandatory for the scenarios that matter and responses are recorded centrally so they feed back into your ISMS records.
Measuring performance and learning from incidents
You cannot improve what you cannot see. Annex A.5.21 becomes much more valuable when you track how well supply chain controls are working and feed lessons from incidents back into your tiers, templates and playbooks. The aim is not to drive every number to zero, but to understand where your biggest supply chain exposures really sit and demonstrate that you are managing them.
Once controls are operating, you need feedback to improve them. Useful measures might include:
- The proportion of critical suppliers with up‑to‑date risk assessments and documented security commitments.
- The number and severity of incidents where the root cause involved an upstream or downstream relationship.
- The time taken to be notified of relevant supplier incidents and to communicate with affected customers.
- The rate of customer non‑compliance with key downstream obligations and how often exceptions are granted.
When incidents occur, root‑cause analysis should deliberately distinguish between upstream failures, internal issues and downstream weaknesses. That distinction informs where you need to tighten expectations, improve your own practices or adjust customer obligations. Feeding these insights back into supplier tiering, contract templates and playbooks makes your Annex A.5.21 implementation genuinely iterative, not static.
A dedicated ISMS platform can help you link suppliers, services, customers, risks and controls in one place, so a single change or incident can be traced across the relationships it affects. Even if you are not ready to adopt such a platform immediately, designing your processes so that the necessary data could be captured centrally later is a pragmatic step towards a more integrated ISMS.
Book a Demo With ISMS.online Today
ISMS.online can help you move Annex A.5.21 from scattered supplier lists and contract clauses into a single, living picture of your ICT supply chain, controls and evidence. By replacing spreadsheets, email trails and isolated documents with one connected environment, you can see upstream and downstream relationships more clearly, trace responsibilities and answer tough questions from customers and auditors with greater confidence.
If you suspect that answering a complex customer questionnaire or an ISO 27001:2022 audit would still trigger a scramble, that is a signal to explore a more structured approach. Seeing your upstream and downstream relationships mapped clearly, with responsibilities and risks visible at a glance, gives you a more confident storey for customers, auditors and leadership.
How to pilot A.5.21 in one part of your supply chain
A focused pilot is the simplest way to see what Annex A.5.21 looks like when it is fully embedded in an ISMS. Instead of trying to model your entire world at once, you concentrate on a small, representative slice of your supply chain and test whether the structure and tooling genuinely reduce effort and uncertainty.
A practical pilot might start with one critical upstream platform and one high‑risk customer. You could import those relationships into ISMS.online, map them to Annex A.5.19–A.5.22 and capture the key artefacts: supplier risk assessments, shared responsibility models, customer obligations and monitoring evidence. Within that limited scope, you can see whether the platform meaningfully reduces effort, clarifies ownership and improves your readiness for questions from auditors and customers.
By keeping the pilot small, you stay in control of scope and avoid overwhelming already busy teams. At the same time, you give yourself concrete examples-a populated risk register entry, a documented supplier lifecycle, a shared responsibility matrix-that you can show to colleagues and leadership when discussing how to scale the approach.
What to bring to an ISMS.online conversation
You will get the most value from a conversation about ISMS.online if you arrive with a simple picture of your current supply chain and challenges. A small amount of preparation makes it easier to see how the platform could support your specific situation and whether it is a good fit for your organisation.
Useful inputs typically include:
- A list of your most critical upstream ICT suppliers and the services they support.
- A shortlist of high‑impact customers, especially those in regulated sectors.
- Any existing documents that describe shared responsibilities, customer obligations or supplier expectations.
- Examples of recent supplier‑related or customer‑related incidents that were hard to manage.
With those inputs, the ISMS.online team can walk through how your real relationships would look inside the platform and how Annex A.5.19–A.5.22 would be expressed in practice. The aim is not to propose a generic solution but to show, using your own examples, how a linked ISMS could simplify Annex A.5.21 and improve your supply chain storey.
If you recognise your own organisation in these scenarios and want to test a more integrated approach, ISMS.online is ready to explore a focused pilot with you, using your real suppliers and customers to see whether a connected ISMS is the right next step for your MSP.
Book a demoFrequently Asked Questions
How does ISO 27001:2022 Annex A.5.21 change the way an MSP should think about its ICT supply chain?
Annex A.5.21 expects you to run your ICT supply chain as one governed system from cloud platform to customer outcome, not as a set of disconnected vendors, tools and contracts. For an MSP, that means you need a live, defensible view of how upstream providers, your own services and downstream customers are tied together and how you manage risk across that chain.
What does “end‑to‑end ICT supply chain” really mean for an MSP?
End‑to‑end means you can start with a single service and trace:
- Which ICT products and services you rely on to deliver it.
- How your own platforms and processes sit in the middle.
- Which customers or customer segments are affected if something breaks.
Instead of “we use Vendor X and we serve Customer Y”, Annex A.5.21 assumes you understand and govern the whole path: cloud/platforms → MSP tools and processes → customer environments. If a core platform fails or is compromised, you should already know which services and tenants are exposed and what you will do about it.
In practice, that means you can:
- Point to a supplier register that maps ICT vendors to services and risk classes.
- Explain, in plain language, who does what (you, the supplier, the customer) for each service type.
- Show that this picture stays current when services, suppliers or regulations change.
If you can walk an auditor through that storey using everyday records instead of a one‑off “audit pack”, you are treating Annex A.5.21 as part of how you run the business, which is exactly what they are looking for.
How does Annex A.5.21 build on the other Annex A.5 supplier controls for a managed service provider?
Annex A.5.21 takes the general supplier themes from A.5.19, A.5.20 and A.5.22 and applies them specifically to the ICT stack that underpins your managed services. It is less about inventing new processes and more about connecting supplier selection, contracts, monitoring and change into one coherent approach for ICT products and services.
How do the Annex A.5 supplier controls fit together in an MSP’s ICT supply chain?
You can think of the four controls as one flow:
- A.5.19 – Information security in supplier relationships: Decide where security matters in your supplier landscape and how you factor it into choices.
- A.5.20 – Addressing information security within supplier agreements: Turn those expectations into clear clauses, addenda and service descriptions.
- A.5.21 – Managing information security in the ICT supply chain: Apply that thinking to the specific web of ICT platforms, tools and integrations that sit under your managed services.
- A.5.22 – Monitoring, review and change management of supplier services: Keep supplier risk and performance under review and react to incidents and changes.
For an MSP, this usually translates into three visible capabilities:
- A joined‑up register where ICT suppliers are tied to services, risk ratings and contractual commitments.
- A consistent pattern for how you onboard, monitor and exit ICT suppliers, rather than one‑off decisions in email.
- A traceable link from those activities to customer‑facing promises and your internal risk register.
Using a platform such as ISMS.online makes it easier to join these dots because you can hold suppliers, contracts, risks and Annex A.5.19–A.5.22 controls in one place. That allows you to show auditors and customers that you are managing an ICT supply chain, not just a filing cabinet of agreements.
How should an MSP design an upstream ICT vendor lifecycle that satisfies Annex A.5.21 without overloading the team?
The most effective way to satisfy Annex A.5.21 upstream is to define a single, repeatable vendor lifecycle and then scale the depth of checks by risk, not by guesswork. Your team only has to learn one pattern, and you reserve heavy due diligence for the suppliers that can really hurt you or your customers.
What does a practical, repeatable ICT vendor lifecycle look like for an MSP?
A simple four‑stage lifecycle usually balances effort and assurance:
- Select: Classify the supplier by impact before you commit. A platform that processes customer data or sits in the middle of your remote management stack deserves deeper checks than a low‑value utility.
- Onboard: Turn your expectations into concrete controls. Configure access, logging, change notifications, support channels and exit terms before you go live.
- Operate: Review performance and risk on a sensible cadence. For critical platforms, schedule at least an annual review, plus checks after security advisories, incidents or significant service changes.
- Exit: Plan how you will remove or migrate data, revoke access, switch dependencies and update your own documentation when you leave or downgrade a supplier.
You do not need complex tooling to prove you follow this lifecycle. A maintained supplier register, short due‑diligence notes, simple onboarding checklists and basic review records already give auditors a clear signal that you treat ICT vendors as part of your ISMS.
ISMS.online can strengthen this further by holding the supplier register, lifecycle evidence and linked Annex A.5.19–A.5.22 controls in one environment. That helps you keep the process lightweight for your team while presenting a clear, consistent pattern to customers, auditors and partners.
How can an MSP define downstream shared responsibilities with customers so Annex A.5.21 is covered without turning every contract into a legal novel?
Downstream, Annex A.5.21 is satisfied when your customers can see, in plain language, what you secure by default, what they need to do themselves and how you will work together when something changes or goes wrong. You do not need bespoke legal text for every deal, but you do need a small set of shared responsibility patterns that your teams understand and apply consistently.
What does a workable shared responsibility model look like for common MSP services?
A practical pattern is to standardise models by service family and keep the structure identical each time. For each family, define four blocks:
- Service scope: What this managed service covers and what it does not.
- Your responsibilities: For example, baseline configuration, logging, backup, monitoring, vulnerability handling and incident coordination.
- Customer responsibilities: For example, keeping endpoints supported, enforcing multi‑factor authentication, managing joiners/leavers and telling you about major changes.
- Shared responsibilities: For example, access reviews, approving high‑risk changes or running incident communications.
You can then express these models in several ways:
- Brief responsibility matrices in proposals, scopes of work and onboarding documents.
- Security addenda: that attach to contracts without rewriting the full terms.
- Internal runbooks: that your teams use when onboarding, operating and handling incidents.
When a customer needs an exception, you document that deviation explicitly instead of silently stretching the model. Once these patterns and exceptions live in your ISMS and are reflected in your risk register, you can show that downstream risk is being handled deliberately rather than informally. That is exactly what Annex A.5.21 aims to test.
ISMS.online gives you a central place to store and reuse these models, link them to specific services and customers, and keep contract wording, internal playbooks and risk entries aligned as your portfolio grows.
How can an MSP turn a complex web of vendors, platforms and customers into a clear ICT supply chain risk map that stands up to Annex A.5.21 reviews?
The easiest way to build a meaningful supply chain risk map is to start from how your services actually run today instead of starting from a static vendor list. When you follow data flows and control points from left to right, the relationships that matter most for Annex A.5.21 tend to reveal themselves.
What practical steps create an ICT supply chain map that auditors can follow?
You can build the map in three independent steps that reinforce one another:
- Service view: List your managed services (for example, managed Microsoft 365, managed endpoints, managed backup, co‑managed cloud) and note which upstream platforms, tools and integrations each one depends on.
- Relationship view: For each service, list:
- The upstream ICT suppliers and platforms that are essential.
- The downstream customers or customer groups who consume that service.
- Risk view: For each high‑impact supplier or customer segment, record a separate risk that states:
- What could reasonably go wrong (for example, outage, data breach, licence change).
- How that would affect your services and customer outcomes.
- Which controls, contract terms and operational practices reduce the likelihood or impact.
Many MSPs find a simple diagram helpful, even if you never show it externally: cloud/platforms → MSP tools and processes → customer environments, with colours or icons to show relative risk. That picture helps you decide where to invest effort and gives auditors and customers a straightforward way to understand your dependencies.
In ISMS.online you can mirror this structure by linking services, suppliers, customers and risks in one environment. That makes it much easier to demonstrate how a new platform or a new customer is added to the map, how it is classified and how related risks and responsibilities are updated consistently.
What everyday records convince ISO 27001 auditors that an MSP is genuinely managing Annex A.5.21 instead of just naming it in documentation?
Auditors are usually more interested in whether your everyday records tell a coherent storey than in how impressive your tools look. For Annex A.5.21, they want to see that you understand where ICT supply chain risk comes from, apply a repeatable treatment and can evidence that treatment without creating a second business dedicated to audit paperwork.
Which normal artefacts usually satisfy Annex A.5.21 for MSPs without building a parallel “audit industry”?
In most MSPs, a compact set of records is enough if it is complete and kept current:
- A supplier register that lists ICT suppliers, links them to services, shows their risk classification and records last review dates.
- Short due‑diligence notes for higher‑risk suppliers, such as references to certifications, questionnaire responses or concise risk assessments.
- Contracts or security addenda: that set out security expectations, incident notification rules, data handling and sub‑processor conditions.
- Monitoring and review records: , such as service review tickets, minutes from supplier check‑ins or post‑incident reviews that show how you responded.
- Shared responsibility models: and related clauses in customer contracts, plus real examples of how you act when obligations on either side are not met.
Instead of building separate “audit packs”, it is generally more efficient to make sure your normal documents-onboarding checklists, change records, runbooks, incident and problem reviews-automatically leave behind the evidence an auditor will ask for.
If you centralise those artefacts in ISMS.online and link them explicitly to Annex A controls and relevant risks, you can answer audit questions and customer questionnaires quickly by filtering and exporting from one place. Over time, that reduces audit stress, shortens sales cycles and helps your team be recognised for running a well‑governed ICT supply chain rather than scrambling each year to reassemble the same storey from scratch.
How can an MSP use ISMS.online to embed Annex A.5.21 into normal supply chain work instead of treating it as a one‑off compliance project?
Annex A.5.21 becomes manageable when it is wired into how you buy, deliver and review services, not when it is treated as a stand‑alone standard to “tick off”. ISMS.online supports that shift by giving you a single environment to connect suppliers, services, customers, risks, controls and evidence, so that everyday actions naturally keep Annex A.5.21 in good shape.
What does it look like when Annex A.5.21 is genuinely operationalised in ISMS.online?
A realistic pattern for many MSPs looks like this:
- You maintain a live supplier register in ISMS.online, classifying ICT vendors by impact and linking each one to the managed services and Annex A.5.19–A.5.22 controls it supports.
- You capture due diligence, onboarding, monitoring and exit activities as normal work items or tasks, so the evidence you need for Annex A.5.21 builds up automatically as your team works with suppliers.
- You store and reuse shared responsibility models as structured content, mapping them to service families and customer groups so contract language, runbooks and risk entries stay aligned.
- You link risks to both upstream suppliers and downstream customers, so a change in one part of the chain immediately adjusts your view of overall supply chain exposure.
A low‑risk way to start is to pick one important service, one critical upstream platform and one representative customer, model that chain end‑to‑end in ISMS.online and then run a real change or incident through the system. If your teams and your auditor find it easier to see dependencies, explain obligations and gather evidence from that one example, you will have a strong internal case for extending the same approach across more of your ICT supply chain.
Over time this way of working helps your business be seen not just as “keeping systems running”, but as running a traceable, well‑governed ICT supply chain that stands up to customer questionnaires and ISO 27001 audits with far less disruption to your day‑to‑day work. When you are ready to show that storey to a customer or auditor, ISMS.online gives you everything you need in one place, rather than leaving you to piece it together under pressure.
