Why MSP contracts are an ISO 27001:2022 hotspot
MSP contracts are an ISO 27001:2022 hotspot because auditors now treat supplier agreements as primary evidence of how your controls extend into the supply chain. They expect written obligations, roles and incident processes that show your ISMS reaches into the services you buy and provide, not just internal diagrams or policies. Commentaries and implementation guidance for ISO/IEC 27001:2022 emphasise that organisations must demonstrate how controls apply to relevant suppliers, and certification bodies commonly use contracts as part of that evidence set. For managed service providers, everyday commercial contracts now double as security artefacts that can strengthen or weaken certification and customer trust.
MSP agreements are no longer just commercial tools; they are part of your security posture. ISO 27001:2022 expects security obligations, responsibilities and incident handling to be reflected in contracts and related documents, which in many organisations will include master service agreements (MSAs), statements of work (SoWs), service level agreements (SLAs), data processing agreements (DPAs) and security schedules, even though the standard does not prescribe specific document labels. If those elements are missing or vague, auditors will struggle to see how your Annex A controls operate in the real world.
Information here is general and does not constitute legal advice; contractual decisions require input from qualified counsel.
How ISO 27001:2022 pulls MSP contracts into scope
ISO 27001:2022 pulls MSP contracts into scope by treating supplier security as a contractual responsibility that must be defined and agreed in writing. The standard expects you to show, in your agreements, how information security responsibilities, data handling rules and incident processes are allocated across customer, MSP and upstream providers. That shift places direct audit attention on the contracts your business relies on.
In the 2025 ISMS.online State of Information Security survey, about 41% of organisations named managing third-party risk and tracking supplier compliance as a top information-security challenge.
Managed service providers sit in the middle of long supply chains. You depend on cloud platforms, data centres, security tools and specialist SaaS, and your customers depend on you. When incidents have cascaded through these chains, investigators have repeatedly seen the same pattern: commercial terms were detailed, but security roles, data handling, incident response and oversight were vague or missing from contracts. Reviews of supply‑chain attacks in cloud and outsourcing contexts often highlight that contractual attention focused on price and service features while security responsibilities were left implied, which significantly limited leverage when failures occurred. If expectations are implied rather than written, you have little leverage when something goes wrong.
The 2025 State of Information Security survey found that a majority of organisations had been impacted by at least one third-party or vendor-related security incident in the previous year.
Regulators and customers have responded by asking much sharper questions. It is no longer enough to say “we are ISO aligned” or “our suppliers follow industry standards.” Buyers want to know how responsibilities are shared, how quickly you will inform them of problems, how sub‑processors are controlled and what happens to data when a relationship ends. Supervisory guidance in many sectors now explicitly references written outsourcing arrangements and expects firms to evidence how they oversee third parties, so auditors routinely sample those arrangements when assessing control effectiveness. In areas such as financial‑services operational resilience and outsourcing, for example, prudential rules spell out the need for documented responsibilities, notification duties and exit provisions in outsourcing contracts, and that thinking is increasingly reflected in broader third‑party‑risk practice.
For MSPs, that means contracts are now part of the attack surface and part of the evidence set. If security requirements, service levels, incident processes and audit rights are not documented, auditors will doubt whether Annex A controls really extend into the supply chain. More importantly, you may lose the ability to insist on remediation or cooperation when an upstream provider fails or resists scrutiny.
A platform such as ISMS.online can help by linking supplier records, risk assessments and contract evidence in one place, but your starting point is a clear view of what Annex A.5.20 expects your agreements to contain.
Clear contracts turn assumed security into enforceable responsibility.
What ISO 27001:2022 A.5.20 actually requires
ISO 27001:2022 A.5.20 requires you to identify information security requirements for each supplier relationship and embed them in enforceable agreements. Wherever a supplier can affect the confidentiality, integrity or availability of your information or services, you must define what you expect of them in contracts or equivalent documents that both sides understand and can act on. This aligns with the wording of Annex A.5.20 in ISO/IEC 27001:2022, which calls for information security requirements to be identified for supplier relationships and implemented in agreements, so those written expectations then form part of your audit evidence.
In practice, Annex A.5.20 moves security requirements out of internal documents alone and into the agreements that govern how services are delivered. For MSPs, that means customer contracts and upstream supplier contracts should show how security responsibilities are shared, how data is handled and how incidents are managed. Auditors will look for that traceable link between supplier risks, internal controls and contract wording.
Distinguishing A.5.20 from other supplier controls
A.5.20 differs from neighbouring supplier controls because it focuses on what is written into contracts rather than how suppliers are selected or monitored. Understanding this distinction helps you design the right evidence for each control and avoid treating everything as a single, blurred requirement.
A.5.19, “Information security in supplier relationships”, focuses on the overall lifecycle: selecting suppliers, assessing risk, monitoring performance and managing change. A.5.21, “Managing information security in the ICT supply chain”, emphasises complex chains, sub‑suppliers and privacy or personal data risk, especially where multiple providers combine to deliver a service. Overviews of ISO/IEC 27001:2022 and related guidance consistently present A.5.19 as the lifecycle governance control and A.5.21 as the specific ICT supply‑chain control, which supports using them alongside A.5.20 rather than treating them as duplicates. Together, they describe how you govern third‑party risk over time.
Annex A.5.20, “Addressing information security within supplier agreements”, concentrates on content: what appears in contracts, schedules and terms. Auditors often see solid work on A.5.19 (supplier registers, risk assessments, due‑diligence questionnaires) but weak execution on A.5.20, where contracts still say little more than “the supplier will comply with applicable laws and industry standards.” That kind of language rarely shows that specific risks have been translated into obligations that can be enforced and tested.
Core obligations A.5.20 places on MSP agreements
A.5.20 places several core obligations on MSP agreements, centred on documenting clear responsibilities and minimum security expectations. For each supplier that affects your ISMS, you should be able to show where roles, data handling rules, incident processes, regulatory duties and oversight mechanisms are defined and accepted by both parties.
In concrete terms, A.5.20 expects you to:
- Define security‑relevant roles and responsibilities between you and each supplier in plain language.
- Specify how information may be accessed, processed, stored, transmitted and deleted by that supplier.
- Capture incident notification and cooperation requirements, including timing and communication channels.
- Reflect relevant regulatory obligations, especially around personal data and outsourcing rules.
- Provide for monitoring, review and, where appropriate, audit or independent assurance mechanisms.
For MSPs, “supplier” should be interpreted broadly. Cloud platforms, connectivity providers, ticketing tools, remote monitoring software, SOC partners, subcontracted engineers and some strategic consultants may all fall in scope if they can affect customer services or handle sensitive information. The standard does not assume that only large, obvious outsourcers matter.
The key is traceability. For each important supplier risk you record in your ISMS, an auditor will want to know where it is addressed: in technical controls, in operational processes and in contract clauses. A.5.20 is where your internal expectations become external commitments that customers, regulators and auditors can see.
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.
Translating A.5.20 into concrete MSP contract topics
Translating A.5.20 into concrete MSP contract topics means turning broad security expectations into a short, repeatable list of clause areas. If every significant supplier agreement covers these areas at an appropriate level of detail, you meet most of the control’s intent and make audits and renewals easier to manage.
For MSPs, the advantage of a topic‑based approach is consistency. Once you decide which themes must appear in almost every contract, your legal, security and commercial teams can work from a shared checklist rather than improvising wording case by case. That makes it easier to compare agreements, spot gaps and explain your approach to auditors and customers.
Baseline topics every MSP supplier contract should cover
Baseline contract topics are the recurring themes you want to see in almost every supplier agreement that touches your ISMS. They give your teams a pragmatic review checklist and help you show auditors that specific risks have been addressed in consistent, understandable language rather than scattered, one‑off clauses.
A practical baseline usually includes at least the following:
- Scope and use of information: – authorised data and systems, permitted uses, prohibited uses.
- Access control expectations: – authentication methods, least‑privilege access, remote access and account lifecycle rules.
- Logging and monitoring: – required logs, retention periods and availability of records during investigations.
- Vulnerability management and patching: – ownership of discovery, assessment and remediation, with timeframes for high‑risk issues.
- Incident detection and notification: – what counts as a security incident, how quickly you are informed and how you collaborate.
- Business continuity and disaster recovery: – minimum availability, recovery targets and participation in tests where relevant.
- Subcontractors and sub‑processors: – when they may be used, how you are informed or approve, and how obligations flow down.
- Data protection and privacy: – conditions for processing personal data, locations, transfer mechanisms, confidentiality and subject rights support.
- Data retention, return and deletion: – retention periods, return formats at exit, and how secure deletion is evidenced.
- Assurance and oversight: – reports, certifications, questionnaires or agreed audits you can rely on, and when they are provided.
These topics do not all need long clauses, but they should be recognisable in your standard positions and high‑risk contracts. After reviewing a sample of agreements, you should be able to answer with confidence: “Where do we cover each of these points, and how does that change by supplier tier?”
For MSPs handling personal data on behalf of customers, privacy terms must align with these security clauses. Processing instructions, confidentiality undertakings, rules on sub‑processors and audit rights should support, not conflict with, your broader security requirements. That avoids a situation where the data processing agreement says one thing, the security schedule says another, and neither matches the controls described in your ISMS.
Linking contract topics to internal ISMS questions
Linking contract topics to internal ISMS questions means making sure every clause family answers a clear risk question you already track. When your risk registers, controls and contracts use the same mental model, it becomes much easier to explain to auditors how you manage suppliers end to end.
A short table can help you align these topics with the questions you ask internally:
| Contract topic | Key question to answer | Typical document location |
|---|---|---|
| Access control | Who can access what, and how is access granted or removed? | Security schedule / statement of work |
| Incident notification | When and how will you hear about incidents? | Security schedule / service level agreement |
| Sub‑processors | Who else is involved and who approves them? | Data processing agreement / subcontracting clause |
| Data return and deletion | What happens to data when the relationship ends? | Exit or termination provisions |
| Audit and assurance | How can you verify security is working as agreed? | Audit rights or assurance section |
Once those links are clear, you can document, for each important supplier, where specific risks are addressed. That gives auditors confidence that you are not relying on generic wording and gives customers a consistent storey when they ask how you manage outsourcing risk.
Designing a reusable MSP contract baseline
Designing a reusable MSP contract baseline means creating a standard structure and clause set that works across many deals with risk‑based variations. Instead of reinventing wording each time, you maintain one controlled baseline and adjust depth and strength depending on the supplier’s impact on your services and customers.
A reusable baseline turns a long list of topics into a practical contract structure that you can roll out across your portfolio. The aim is to stop drafting from scratch on every deal and to maintain a single set of positions that you can tighten or relax in a risk‑based way, while keeping overall consistency.
Building a modular contract structure for MSPs
A modular contract structure lets you maintain one coherent baseline while giving legal, commercial and technical teams clear ownership of their sections. By separating service descriptions, legal boilerplate and security content, you make updates easier and reduce the risk that a change in one area accidentally weakens another.
Most MSPs find a modular structure works best because it lets you update individual parts without rewriting everything. Clear separation between legal boilerplate, service descriptions and security expectations also helps different teams own their sections.
Typical components include:
- A Master Service Agreement (MSA) containing core legal terms and high‑level responsibilities.
- One or more Statements of Work (SoWs) describing specific services, assets and locations.
- A service level annex defining availability, response and resolution targets, reporting and service credits.
- A security schedule concentrating the information‑security and privacy obligations required by A.5.19–A.5.21.
- Where personal data is processed, a data processing agreement (DPA) aligned with the security schedule.
Within that structure, the security schedule becomes the primary vehicle for A.5.20. It does not need to be long, but it should systematically cover the core topics from the previous section. Using short, numbered paragraphs or tables, rather than scattered references, makes it easier for both sides to understand and maintain the content over time.
Turning your baseline into a living clause library
Turning your baseline into a living clause library means capturing reusable wording, tying it to controls and making it easy for teams to apply the right variant. Your aim is to avoid one‑off phrases buried in old contracts and instead maintain a curated set of clauses that evolves with your risk appetite and regulatory context.
To move from theory to daily use, you need wording that is technology‑agnostic, traceable to controls and easy to adapt for different risk levels. That way, you can apply the same core positions across hosting, SOC, SaaS and professional services, while still reflecting their different risk profiles.
To build a baseline, you can:
Step 1 – Start from your ISMS
Start by identifying the controls and policies that suppliers must respect, such as password standards, encryption expectations, logging and incident response timeframes, so you know which requirements must appear in contracts.
Step 2 – Group requirements into contract topics
Group each expectation into a clause area like access control, incident management, continuity or data handling, so you reduce duplication and can quickly see where gaps exist in draught agreements.
Step 3 – Draught neutral, outcome‑based wording
Write clauses that describe responsibilities and outcomes, not specific tools or configurations, so that your wording survives technology changes and remains relevant across different types of supplier.
Step 4 – Tag clauses to ISO controls internally
In your internal documentation, record which ISO 27001 and related controls each clause supports to simplify audit explanations, support control testing and highlight any overlaps or conflicts.
Step 5 – Define standard and enhanced variants
Create a default clause plus stricter versions for higher‑risk situations, such as shorter incident timelines or stronger audit rights for critical services, so negotiators know which positions to start from and when to escalate.
Rolling the baseline out is a change programme in itself. A common approach is to apply the baseline to all new customer and supplier deals, use renewals and significant changes to upgrade existing high‑risk contracts, and maintain a register of exceptions where you accept weaker terms with documented reasons and compensating controls.
ISMS.online can support this by storing your clause library, linking each clause to controls and suppliers, and recording which version of the baseline each contract uses. That reduces administrative overhead and makes it easier to answer questions such as “Which hosting providers are still on the older breach‑notification standard?”
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.
Unifying A.5.19, A.5.20 and A.5.21 into “always‑on” clauses
Unifying A.5.19, A.5.20 and A.5.21 into “always‑on” clauses means designing a small set of clause families that jointly cover supplier lifecycle governance, contract content and ICT supply‑chain risks. Instead of treating three controls as separate projects, you use repeatable wording that satisfies them together wherever the risk profile demands it.
If you treat A.5.19, A.5.20 and A.5.21 as three disconnected checklists, supplier management quickly becomes complex and hard to explain. Prudential and operational‑risk standards in sectors such as financial services have moved towards integrated outsourcing and third‑party frameworks rather than fragmented lists of requirements, and the same logic applies when you design controls for ISO 27001 supplier clauses. Designing clause families that follow suppliers from onboarding to exit gives you one narrative: how you choose suppliers, how you contract with them and how you oversee their security throughout the relationship.
Most organisations in the 2025 State of Information Security survey reported that they had already strengthened third-party risk management and planned to invest further in it.
Clause families that satisfy A.5.19, A.5.20 and A.5.21 together
Clause families are groups of related obligations that run across supplier selection, contracting and ongoing oversight. By defining these once and applying them throughout the lifecycle, you make your approach easier to explain, easier to negotiate and more resilient when staff or suppliers change.
Useful families include:
- Onboarding and due diligence: – disclosure of key security information during selection, acceptance of your baseline and confirmation of relevant certifications or reports.
- Performance and security review: – regular meetings, metrics, reporting of incidents and vulnerabilities, and the right to request remediation plans.
- Change management: – notification of material changes to infrastructure, sub‑processors, locations or security controls before they happen, plus a right to object or reassess risk.
- Sub‑supplier governance: – transparency over the supplier’s own chain, prior approval for new sub‑processors and flow‑down of minimum obligations.
- Exit and transition: – security‑aware termination clauses ensuring controlled handover, data return or destruction and withdrawal of access.
These families allow you to implement A.5.19’s lifecycle governance (selection, monitoring, change, termination), A.5.20’s contract content and A.5.21’s focus on complex ICT supply chains without writing three different sets of clauses. You describe the lifecycle once, then tailor intensity by supplier tier rather than reinventing structure each time.
Risk‑based tiering for supplier contracts
Risk‑based tiering for supplier contracts means applying your clause families at different strengths depending on how much harm a failure at that supplier could cause. By defining tiers and corresponding expectations up front, you avoid case‑by‑case improvisation and can explain to auditors why some contracts are stricter than others.
Risk‑based tiering refines clause families so that critical suppliers carry stronger obligations while routine providers still meet a minimum baseline. This helps you explain to auditors and customers why security expectations vary and shows that the variation is intentional, not random.
For example, you might define:
- Tier 1 – Critical suppliers: such as primary hosting or SOC partners, with on‑site audit rights, tighter incident‑notification times, stronger continuity obligations and more detailed reporting.
- Tier 2 – Important suppliers: such as line‑of‑business SaaS providers, relying on independent assurance reports plus targeted questionnaires and standard notification times.
- Tier 3 – Standard suppliers: such as minor tools, using a simplified baseline with non‑negotiable clauses on confidentiality, incident notification and subcontractors.
Across all tiers, some expectations should be “always on”: confidentiality, defined scope of processing, minimum incident cooperation, and obligations to respect your classification and handling rules for sensitive information. Tiering then becomes a matter of strengthening, not removing, those foundations.
By designing clauses this way, you can show auditors and customers that supplier oversight is structured rather than ad‑hoc and that contractual expectations grow in strength with risk. It also makes it easier to decide where to focus remediation efforts when you discover weaknesses in existing agreements.
Common audit gaps in MSP contracts and their consequences
Common audit gaps in MSP contracts appear when key security topics are missing, vague or inconsistent across agreements. Auditors and customers quickly notice patterns such as weak incident timelines, absent subcontractor provisions and inadequate audit rights, and those gaps often escalate into findings, remediation plans or lost opportunities.
When certification bodies and customers review MSP contracts against A.5.20, they repeatedly find similar weaknesses. Regulatory guidance on cloud and outsourcing arrangements also documents recurring issues such as vague security terms, subcontractor opacity and weak audit rights, which mirrors what many auditors report when they sample MSP contracts. Recognising these patterns early makes it easier to address them before they turn into nonconformities, regulatory questions or contractual disputes.
Patterns auditors and customers flag in MSP agreements
Patterns auditors and customers flag in MSP agreements tend to cluster around vague wording in a few recurrent areas. When sampled contracts show the same soft language for incidents, subcontractors, audit rights and regulatory duties, reviewers quickly question whether your supplier baseline is strong enough for the risks you face.
Auditors usually start by sampling a small number of contracts to see how your baseline is applied in practice. If those samples show vague obligations and missing topics, they can quickly escalate concerns about your supplier oversight more generally. Conformity‑assessment and internal‑audit standards typically distinguish between minor and major findings based on severity and the extent of coverage, so weak clauses can be graded differently depending on how widespread they are and how much harm they could allow.
Typical gaps include:
- Vague security promises: where phrases such as “industry‑standard security” lack detail on access control, logging or incident response.
- Undefined incident timelines: where suppliers promise to report “without undue delay” but no timeframe for initial notification or updates is set.
- No mention of subcontractors: so you cannot see whether the supplier may use sub‑processors or how obligations are flowed down.
- Missing or weak audit rights: which leave you with no reliable way to verify that controls operate as expected.
- Misaligned regulatory duties: where contracts omit sector‑specific outsourcing or data‑protection requirements that apply to you.
When auditors spot these patterns, they may classify them as minor or major nonconformities depending on severity and coverage. Customers, particularly in regulated sectors, may treat similar gaps as grounds for demanding remediation plans, tighter terms or, in some cases, a change of provider.
How weak clauses turn into findings, disputes and lost trust
Weak clauses turn into findings, disputes and lost trust when incidents or disagreements expose the gaps in your contractual expectations. Without clear responsibilities, timelines and escalation routes, you risk slow responses, contested obligations and a narrative that undermines confidence with customers and regulators.
A simple comparison illustrates why detail matters:
| Area | Weak clause example | Strong clause example |
|---|---|---|
| Incident notification | “Notify without undue delay.” | “Notify within four hours of detection, then daily updates.” |
| Sub‑processors | No mention. | “Identify, seek approval for and bind all sub‑processors.” |
| Audit and assurance | “Provide reports as requested where feasible.” | “Provide annual assurance reports and cooperate with reviews.” |
Delayed or incomplete notifications mean you may discover an incident via the press or your customers rather than your supplier, reducing your ability to respond and communicate credibly. Third‑party‑risk guidance in regulated sectors has documented instances where weak notification obligations left organisations learning about problems from external sources rather than their providers, which is exactly the scenario you want to avoid. Ambiguous responsibilities lead to finger‑pointing at the worst possible time. Lack of audit rights makes it harder to push for remediation or to validate fixes, especially if regulators or customers are watching.
The positive side is that findings in this area are usually fixable. Turning them into a structured improvement programme-updating baseline templates, retraining negotiators and targeting remediation at the highest‑risk contracts first-gives you a clear storey of progress at the next audit or customer review. ISMS.online can help you prioritise that programme by showing where older clauses or weaker positions still exist and how they map to supplier risk tiers.
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.
Governance: keeping your baseline aligned and auditable
Governance keeps your A.5.20 baseline aligned and auditable by defining ownership, review cycles and evidence for supplier security clauses. Without clear governance, even a well‑designed clause library can drift over time, creating silent gaps between your stated risk appetite, your contracts and your operational reality.
In the 2025 State of Information Security report, roughly two-thirds of organisations said that the speed and volume of regulatory change are making compliance harder to sustain.
A contract baseline only delivers value if it is maintained and applied consistently. Governance is the layer that connects your clause library to daily decisions, supplier relationships and audit evidence, and it is often the difference between a one‑off clean‑up and a sustainable A.5.20 implementation.
Assigning ownership for supplier security contracts
Assigning ownership for supplier security contracts means being explicit about who defines expectations, who negotiates wording, who monitors performance and who tests alignment. When those responsibilities are clear, it is far less likely that important clauses will be watered down or bypassed in side arrangements.
A simple model often starts with:
- Information security: defining control expectations, risk appetite and non‑negotiable positions.
- Legal and contracts teams: translating these into enforceable wording and managing negotiations.
- Service and supplier managers: monitoring performance, overseeing obligations and capturing evidence.
- Internal audit or an equivalent function: periodically testing whether contracts and practices align.
Linking reviews of the baseline to your ISMS processes keeps it current. When risk assessments highlight new threats, when major incidents occur or when regulations change, those triggers should feed into scheduled template reviews. Management reviews can then consider whether contract clauses still match the organisation’s risk posture and whether further changes are needed.
Tools and reviews that keep A.5.20 evidence current
Tools and reviews keep A.5.20 evidence current by giving you visibility of which contracts use which clauses and where deviations exist. With that view, you can prioritise updates, support negotiations and give auditors a clear explanation of how supplier expectations are maintained over time.
Governance is easier when you can see, at a glance, which contracts use which clauses and where exceptions sit. That visibility supports both operational decision‑making and audit preparation, particularly in MSP environments with many customers and suppliers. Practices from version‑control and change‑management disciplines show that tracking which document versions apply in which contexts is a key part of demonstrating control, and the same principle applies to contract baselines and deviations.
A practical governance toolkit often includes:
- A contract and supplier register showing which baseline version each relationship uses, the risk tier, key dates and any approved deviations.
- A deviation process documenting who can approve exceptions to the baseline, on what grounds and with what compensating controls.
- Training and guidance: for sales, procurement and legal teams so they understand which security positions are non‑negotiable and how to explain them.
- Sample testing: by internal audit, comparing a selection of contracts against the baseline and A.5.20 requirements, and checking whether operational reality matches the agreements.
Using a system rather than spreadsheets makes this much smoother. An ISMS platform can hold supplier inventories, link them to contracts and controls, and track reviews and approvals. ISMS.online, for example, can record which suppliers fall under which risk tier, which clause sets apply and where exceptions have been authorised. That provides a clear audit trail and reduces the chance that a quiet contract change undermines your security posture.
With governance in place, your A.5.20 implementation stops being a one‑off remediation exercise and becomes a sustainable part of how you manage third‑party risk and demonstrate assurance to customers and auditors.
Book a Demo With ISMS.online Today
ISMS.online helps you turn ISO 27001 A.5.20 into a repeatable MSP contract baseline that keeps your supplier agreements secure, consistent and auditable. By centralising supplier records, clause libraries, control mappings and evidence, the platform makes it easier to show that information security requirements are addressed in agreements and supported by day‑to‑day practice.
Seeing your A.5.20 baseline working in a real ISMS
Seeing your A.5.20 baseline working in a real ISMS means being able to trace suppliers, risks, contracts and controls in a single environment. When you can do that, conversations with auditors and customers shift from hunting for documents to explaining how your supplier governance works and how exceptions are managed.
When you can link suppliers, risks, contracts and Annex A controls in one place, conversations with auditors and customers become simpler and more confident. Instead of searching through file shares and inboxes, you can point to a single view that shows which baseline version applies to each relationship, what exceptions exist and how those decisions were justified.
Within a single environment, ISMS.online can help you connect suppliers to risk assessments, contracts and control sets so it becomes easier to see which agreements support which parts of your ISMS. Workflows support reviews, approvals and renewals, helping you ensure that new deals adopt the baseline and that high‑risk contracts are prioritised for upgrades. Dashboards give leadership a concise view of supplier coverage, outstanding actions and upcoming renewal windows.
What to expect when you explore ISMS.online
When you explore ISMS.online, you can see how structured supplier management and A.5.20 contract baselines work in a live ISMS rather than in theory. The focus is on how your existing contracts, risks and controls could be organised into a single, auditable picture that reduces manual effort and increases confidence.
Exploring ISMS.online is about seeing how your current supplier management can evolve into a structured, auditable system rather than adding another tool to maintain. You can review example A.5.20 clause sets, mappings and reports tailored to managed service providers and test how they would fit your existing contracts and processes.
For information security leads, legal teams and MSP owners, that combination of structure and visibility shortens audit preparation, reduces negotiation friction and strengthens assurance. Choosing ISMS.online makes sense when you want your supplier agreements to support your ISO 27001 certification, demonstrate control to customers and reduce third‑party risk without adding unnecessary complexity. If those outcomes matter to you, seeing the platform in action is a natural next step.
Book a demoFrequently Asked Questions
How should an MSP interpret ISO 27001:2022 A.5.20 in everyday supplier and customer contracts?
You should treat A.5.20 as a requirement for specific, testable security obligations in your contracts, not reassuring but vague statements about “robust” or “industry‑standard” security.
When an auditor, major customer or regulator reads your agreements, they should be able to see who is responsible for which controls, what “good” looks like, and how you check that it actually happens.
What does “clear and auditable security clauses” look like in practice?
For an MSP, A.5.20 is met when supplier and customer contracts consistently:
- Allocate security responsibilities:
Spell out who runs patching, endpoint protection, backups, identity and access management, monitoring and incident triage – including any shared responsibilities.
- Describe how information is handled:
Cover how in‑scope data is accessed, processed, stored, transmitted, backed up, retained and deleted, in language a non‑technical reviewer can follow.
- Define incident notification and cooperation rules:
Use concrete triggers (“confirmed compromise of customer data”, “service outage > X minutes”), timelines (“initial alert within X hours”), named contact routes and expectations for joint investigations and communications.
- Reflect applicable regulations and sector rules:
Pull privacy, outsourcing, resilience or sector‑specific obligations into the agreement, instead of relying on policies or informal assurances alone.
- Include usable assurance and oversight mechanisms:
Give you rights to see evidence (ISO 27001 certificates, SOC 2 reports, pen‑test summaries, focused questionnaires) on an agreed rhythm, and to follow up where needed.
A quick self‑check that resonates with auditors is:
If we only had this contract on the table, could we show that our information security requirements are defined, risk‑based and enforceable – or would we be filling the gaps with ‘what everyone knows we meant’?
If the answer is closer to the latter, your ISMS should log that as a weakness and drive a change in wording, templates or approval rules.
A platform like ISMS.online makes that far easier to demonstrate. You can link each contract clause back to the risks and controls it supports, and show how A.5.20 is implemented through real agreements rather than relying on memory or informal notes.
How does A.5.20 fit alongside A.5.19 and A.5.21 for an MSP?
The three controls form a single third‑party security lifecycle: who you work with, what you require on paper, and how you manage the layered supply chain that delivers your services.
How should an MSP view the A.5.19–A.5.21 chain?
For most MSPs, the pattern looks like this:
- A.5.19 – supplier lifecycle:
How you select, assess, approve, onboard, monitor and, when needed, exit suppliers – including criteria, due diligence and periodic reviews.
- A.5.20 – contractual information security:
Where those expectations are turned into binding obligations in master service agreements (MSAs), statements of work (SoWs), SLAs, DPAs and security schedules.
- A.5.21 – ICT supply‑chain and privacy risk:
How you control and oversee layered providers – cloud platforms, specialist tools, subcontractors – and the way they handle personal and sensitive data.
In daily operations, A.5.20 is the bridge between your risk view and your legal position:
- Your supplier register and risk assessments (A.5.19) describe the risk and the controls you want to rely on.
- Your contracts (A.5.20) formalise who must deliver those controls and what happens when they do not.
- Your supply‑chain oversight (A.5.21) checks that reality matches both the ISMS and the contract, including data flows and sub‑suppliers.
Auditors and large customers will naturally line these up. If your risk register says a cloud provider is “critical, high‑risk” but the contract has only generic language about “reasonable security”, they will call that out.
ISMS.online lets you join those dots in one place: supplier records linked to risks, controls and specific contract clauses. That means when someone asks “How do you manage your sub‑processors under A.5.21?” you can show the suppliers, contracts, controls and review cycle together rather than answering from memory.
How can you turn ISO 27001 A.5.20 into a practical set of MSP contract clause topics?
You make A.5.20 practical by agreeing a short, non‑negotiable checklist of security topics that must always be considered, then deciding where each topic usually lives in your contract pack.
That turns every new deal or renewal into an exercise in applying a pattern instead of inventing wording under deadline pressure.
What belongs on an MSP’s default A.5.20 checklist?
Most MSPs end up with a core list along these lines:
- Scope and permitted use: – what services, systems and data are in scope; what the other party may and may not do; any geographic or regulatory boundaries.
- Access control: – how identities and accounts are created, approved, reviewed and removed; handling of privileged access; MFA expectations.
- Logging and monitoring: – minimum logging expectations, retention periods, and how you can obtain logs for investigations or audit.
- Vulnerability and change management: – patching and vulnerability disclosure expectations; advance notice of material changes that can impact security or availability.
- Incident management: – what counts as an incident, notification triggers and timescales, required content for notifications, escalation paths, and joint investigation expectations.
- Business continuity and disaster recovery: – applicable RTO/RPOs, backup frequency and testing, failover expectations where availability really matters.
- Sub‑suppliers: – when further providers may be used, what must be disclosed or approved, and how they must inherit your security and privacy requirements.
- Data protection and privacy: – processing instructions, categories of data, locations and transfers, support for subject rights and breach notifications.
- Data retention, return and deletion: – how long data is held, what happens at exit, how secure deletion is carried out and evidenced.
- Assurance and oversight: – the evidence you can actually request and rely on (certifications, reports, attestation letters, answers to targeted questionnaires) and how frequently.
It helps to capture a simple view of where these usually live:
| Topic area | Typical contractual home for an MSP |
|---|---|
| Scope, permitted use | MSA / SoW |
| Access, logging, monitoring | Security schedule / technical annex |
| Vulnerability, change, incidents | Security schedule / SLA |
| Continuity, DR | Security schedule / SLA |
| Sub‑suppliers, data protection | Security schedule + DPA |
| Retention, return, deletion | Security schedule + exit provisions in MSA |
| Assurance and oversight | Security schedule / governance sections |
Once that pattern is set, you can build internal checklists and review steps around it. ISMS.online can then connect each topic to the relevant suppliers, risks and controls, so that, for example, an incident‑notification risk automatically leads you back to the relevant clauses and affected contracts.
How can an MSP design a reusable A.5.20 contract baseline that still holds up in real‑world negotiations?
A workable approach is to build a modular contract structure and maintain a tagged clause library that sits alongside your ISMS, with clear rules about when and how you can vary wording.
The goal is to be able to explain, consistently, why your contracts look the way they do and how they support your risk posture, even after tough negotiations.
What does a modular A.5.20 baseline look like for MSPs?
Many MSPs converge on a structure like this:
- A master service agreement (MSA) for overarching legal terms, liability, ownership and high‑level responsibilities.
- Statements of work (SoWs): that define services, in‑scope systems and data, locations, and any customer‑specific requirements or variations.
- A service level annex setting out availability, response and resolution targets, including where these support security (for example, incident response times).
- A dedicated security schedule that brings A.5.19–A.5.21 themes into one place with outcome‑based language, so you can update expectations without rewriting the entire MSA.
- Where personal data is processed, a data processing agreement (DPA) that references and aligns with the security schedule rather than duplicating or contradicting it.
Behind that structure, you maintain an internal clause library where each clause is tagged with:
- The security topic it addresses (e.g. access reviews, incident timelines, sub‑supplier disclosure).
- The ISO 27001 and related controls it supports, especially A.5.19, A.5.20 and A.5.21.
- One or more risk tiers – for example, standard, important and critical services or customers.
This gives you three key levers:
- A set of minimum baseline positions that you rarely move below (for instance, maximum incident notification delays).
- A set of enhanced variants ready for higher‑risk situations, so you can strengthen contracts for critical services without improvising.
- A set of exception rules, including who can approve deviations from baseline, what compensating measures you expect, and when those decisions will be reviewed.
If that clause library and approval trail live inside a platform such as ISMS.online, linked to your risk register and supplier records, you can show that updates to your A.5.20 baseline follow from real changes – new threats, incidents, regulatory guidance – instead of ad hoc redlines.
In negotiations, this structure also makes conversations less personal. Rather than arguing over drafting style, you and your counterpart can choose from clearly defined variants tied to an agreed risk profile, and you can document exactly why a stronger or weaker option was selected.
Which information security requirements should almost always appear in MSP supplier agreements under A.5.20?
Some requirements are so fundamental that they belong in almost every in‑scope supplier agreement, regardless of contract value or service category. These “always‑on” elements form the floor of your A.5.20 implementation.
What typically belongs in an MSP’s “always‑on” A.5.20 layer?
Most MSPs settle on a concise list that is only varied by exception and with clear justification:
- Confidentiality and acceptable use:
Duties to protect your information and customer information, plus illustrative examples of prohibited behaviour such as unauthorised copying, disclosure or data mining.
- Alignment with your key policies:
A requirement to follow specified information security, acceptable‑use and, where relevant, secure development policies that you publish and maintain through your ISMS.
- Access and identity control:
Expectations for using strong authentication, enforcing least privilege, reviewing access on a defined cadence and revoking it promptly when it is no longer needed.
- Incident notification and cooperation:
Clear criteria for what must be reported, timeframes for initial and follow‑up notifications, minimum content (timeline, impact, affected data, containment actions) and how joint investigations and external communications are handled.
- Sub‑supplier transparency:
Obligations to disclose material sub‑suppliers, give advance notice of significant changes and flow down materially similar security and privacy terms to those parties.
- Data protection terms:
Where personal data is involved, terms that align with your statutory responsibilities (for example under GDPR or CCPA) and with your own privacy and retention policies.
- Data return and secure deletion:
Instructions for how data will be returned, transferred or securely deleted at the end of the relationship or service, and a reasonable expectation of evidence that deletion has occurred.
- Assurance mechanisms:
Agreed ways for you to monitor security posture – such as ISO 27001 certificates, SOC 2 reports, short questionnaires or formal attestations – and how often you will receive them.
A useful question to keep in mind is:
If this supplier experienced a serious incident tonight, do we have enough in this contract to act quickly, insist on appropriate remediation and explain our oversight to customers or regulators?
If you hesitate, one of these always‑on areas may be missing or too weak. Capturing them as part of your baseline and embedding them in standard templates reduces reliance on individual negotiators’ instincts and gives auditors and customers a clear storey.
ISMS.online can strengthen this further by linking these baseline clauses to supplier entries, risks and management reviews, so you can show that the foundational layer exists, is being applied and is reviewed when circumstances change.
How can an MSP keep its A.5.20 contract baseline aligned with the ISMS and easy to evidence over time?
You keep A.5.20 aligned by treating contract wording as part of your security governance, with named owners, planned reviews and clear links to supplier management and risk treatment, rather than a separate legal exercise that drifts over time.
What does sustainable A.5.20 governance look like for an MSP?
Even in smaller MSPs, a simple governance model makes a big difference:
- Information security:
Defines security expectations, always‑on elements and non‑negotiable positions in plain language, mapped to ISO 27001 controls and other frameworks you rely on.
- Legal or contracts team:
Owns the actual phrasing, advises during negotiations, and records where baselines are exceeded or relaxed, including rationale and any compensating safeguards.
- Supplier managers or service owners:
Monitor whether suppliers meet their obligations in practice, collect evidence (certificates, reports, responses) and raise issues when expectations are not met.
- Internal audit or equivalent:
Periodically samples a set of contracts, compares them with your baseline, supplier register and risk records, and recommends improvements.
These roles then follow a predictable rhythm:
- Contract templates and clause libraries are reviewed as part of your risk assessment and management review cycles, so incidents, near‑misses and regulatory changes lead to measured updates in wording.
- A central register shows which contracts use which baseline version, which suppliers sit in which risk tier and where you have accepted deviations, including a record of who approved them and why.
- Short playbooks and checklists help sales, procurement and account teams understand which terms are mandatory, where they have flexibility and when they need to bring in security or legal specialists.
At very small scale, you can hold much of this together with documents and shared folders. As your customer base, supplier list and framework coverage grow, that quickly becomes fragile.
ISMS.online lets you pull supplier inventories, contract baselines, controls, risks, audits and management reviews into a single view, so when someone asks:
- “How do you ensure A.5.20 is consistently applied to critical suppliers?”
- “Where do you record exceptions to your standard positions?”
- “How do contract changes feed back into your risk register?”
you can answer with current, linked evidence rather than a patchwork of files.
That level of structure signals to customers, auditors and regulators that you run supplier and customer security as a managed discipline. It shows that your contracts, your ISMS and your daily behaviour all align, which in turn makes it easier to win and keep the kind of customers who care most about third‑party risk.
