ISO 27001 Control 5.20: Addressing Information Security Within Supplier Agreements

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

Control 5.19 is where you decide which suppliers matter and check them out. Control 5.20 is where that decision gets written down in something both sides have agreed to. If 5.19 is the assessment, 5.20 is the contract.

In my experience the problem with 5.20 is rarely that there is no contract. There nearly always is. The problem is that nobody at the customer end has read it with security in mind, so nobody knows where their data is held, who restores it if it is lost, or what happens to it when the relationship ends. Those three questions are where this control is won or lost, and they are what this page is mostly about.

I will also cover the question everybody asks next: what do you do about the large platforms whose terms you cannot negotiate? The short answer is that you accept them, but you understand them first, and that has become a great deal easier than it used to be.

What control 5.20 actually asks for

The requirement is that relevant information security requirements are established and agreed with each supplier, based on the type of supplier relationship. In practice that means:

• Deciding what you need from each supplier, in proportion to what they hold or can reach. Your 5.19 tiering does most of this work for you.
• Getting it agreed. In a negotiated contract, a data processing agreement, an addendum, or by accepting published terms you have actually read.
• Covering the things that matter to you and to your own customers: where data is held, who may access it, how incidents are reported, who is responsible for backup and recovery, and what happens at exit.
• Being able to show it. An auditor will pick a supplier and ask where the security obligations are written down.

Note the phrase “based on the type of supplier relationship”. The window cleaner does not need an information security schedule. Your IT support company, with administrative access to everything you own, very much does. The standard expects the depth of the agreement to follow the risk.

In the 2013 edition this was control A.15.1.2. The intent is unchanged.

Where 5.20 sits among the supplier controls

Five controls in the 2022 edition deal with suppliers. It helps to know which one an auditor is testing when they ask you something.

5.19 decides what you need; 5.20 is where it is agreed. If your supplier assessment says a supplier is Tier 1 because it holds client data, this control is where you show the contract reflects that. And the clauses you agree here are what control 5.22 later monitors them against.

Data sovereignty: does your supplier match your customers’ expectations?

If I had to pick the single most important thing to get right in supplier agreements today, it is this one. Data sovereignty: where your data is stored and processed, and under which country’s laws.

Here is how it goes wrong. Your own customers have expectations about where their data lives, and often they are written into your contract with them. Financial services clients in particular will commonly forbid any transfer of their data outside the current zone, the UK or the EU for example. Then, separately and without anyone connecting the two, the business signs up suppliers whose data centres, support teams or sub-processors sit somewhere else entirely.

Nobody did anything wrong in isolation. Sales agreed sensible terms with a customer. Operations chose a sensible supplier. But put the two side by side and the business is in breach of its own customer contract, and probably does not know it.

The fix is to work from the outside in:

• Know what you have promised. Pull the data location and transfer commitments out of your customer contracts and put them somewhere visible. If your largest client says UK only, that is now a requirement on every supplier that touches their data.
• Check each Tier 1 supplier against it. Where is the data stored? Where is it processed, including by support staff? Can it move without telling you?
• Write the answer into the agreement, or confirm it in the published terms and the platform settings. Many large platforms let you choose a data region; choosing it is part of meeting this control.
• Record it. The contract checklist below has a column for exactly this, because “we think it’s in Europe” will not survive an auditor, or a customer due diligence questionnaire.

If you process personal data, UK GDPR rules on international transfers apply on top of all this. But the commercial risk usually bites first: it is your customer, not the regulator, who is most likely to ask.

Backup is not disaster recovery

The second thing I see time and again is an assumption that backup and disaster recovery are the same thing, and that the supplier is doing both.

Take Microsoft 365. The platform as a whole is extraordinarily resilient: redundant data centres, failover, the lot. If a Microsoft data centre goes down, you probably will not notice. That is disaster recovery, and it protects Microsoft’s service.

What it does not do is protect you from yourself. If your data is corrupted, deleted by a user, wiped by a disgruntled leaver, or encrypted by ransomware that synchronises happily into OneDrive, the platform will faithfully keep the damaged version. There are recycle bins and retention features, and they help, but they are not a backup you control, they have time limits, and they are not designed for the kind of large-scale recovery you need after a serious incident. Under the shared responsibility model, protecting your data is largely your job.

That is why so many organisations buy a separate backup service for Microsoft 365, Google Workspace, Salesforce and similar platforms. It is not belt and braces; it is filling a gap the platform was never meant to fill.

For control 5.20, the point is simply to know which side of the line each responsibility falls. For every Tier 1 supplier, the agreement or terms should make clear who backs up your data, how far back you can restore, and how quickly. If the answer is “not them”, the answer has to be “us”, and that becomes a decision you make deliberately rather than discover during an incident.

Exit: the clause nobody reads until they need it

The third gap is what happens at the end. Contracts are signed with optimism, and almost nobody reads the termination section until the relationship is already going wrong.

Before you need it, you should know:

• How you get your data back, in what format, and within what timescale. A proprietary export nobody else can read is not much of a return.
• What the supplier does with their copies afterwards, including backups, and how they confirm deletion. A written confirmation is the evidence you want.
• How their access is removed, particularly for suppliers with access into your systems rather than the other way round.
• What notice either side must give, and what happens to service during the notice period.

This matters for security, not just commercially. A supplier you left three years ago that still holds a full copy of your client database is a data breach waiting for a date.

Terms you cannot negotiate

For the large platforms, AWS, Microsoft, Google, Salesforce and the rest, you are not going to change the terms. Nobody expects you to, and an auditor will not either. Accepting standard terms is a perfectly defensible position for 5.20.

What is not defensible is accepting them blind. You still need to understand what you have agreed to: where your data goes, what they will tell you about incidents, what they are and are not responsible for, and what happens at exit. Those are the answers you record against the supplier.

This has become far easier than it was. Before you sign up to a major platform, you can give its terms to an AI assistant and ask it to summarise the data location, incident notification, liability, backup and exit provisions, and to flag anything unusual or anything a business in your position should be aware of. It takes minutes rather than an afternoon with a lawyer, and it gets you to the parts that matter quickly.

Two cautions. Read the sections it flags yourself, because the summary is a starting point and not legal advice. And for a contract that is genuinely high stakes, a lawyer still earns their fee. But for understanding the standard terms of a platform you were always going to accept, it is a sensible, proportionate way to meet the control, and to be able to say honestly that you know what you signed.

What a good supplier agreement covers

For a Tier 1 supplier, these are the clauses I would expect to find, either in the contract itself or in published terms you have read and recorded:

• Data location, and whether it can change without your agreement.
• Sub-processors, who they are and how you are told about changes. That is your window into control 5.21.
• Incident notification, with a timescale. If they are not obliged to tell you, you will hear last.
• Backup and recovery responsibility, stated plainly.
• Data return and deletion at exit, with format, timescale and confirmation.
• Access and confidentiality, covering who at the supplier can see your data and on what terms.
• Assurance, either a right to audit or, more realistically, an obligation to provide current certificates or reports.
• A security standard, such as maintaining ISO 27001, SOC 2 or Cyber Essentials for the life of the contract.

Where personal data is involved, a data processing agreement under UK GDPR will cover several of these, and it is worth checking it actually does rather than assuming. For Tier 2 suppliers, the availability and continuity commitments matter most. For Tier 3, you need nothing beyond normal commercial terms.

The checklist below turns that list into one row per supplier, with Unknown counted as a gap until someone has read the terms.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call

What auditors will look for

As a Lead Auditor, this is broadly how I would work through 5.20.

1. One Tier 1 supplier, contract in hand. Show me where the security obligations are written. I am looking for the clauses above, not just a confidentiality paragraph.
2. Data location. Where is the data held, how do you know, and does it match what you have promised your own customers? This is increasingly the first question a customer audit asks, too.
3. Backup responsibility. For your main platform, who restores your data after a ransomware attack? If the answer is the platform provider, I will ask you to show me where it says so.
4. Exit. For a supplier you have left, what happened to your data, and can you show confirmation it was returned or deleted?
5. A platform you could not negotiate. I will accept published terms. I will want to see that somebody read them and recorded what they mean for you.
6. Consistency with 5.19. The suppliers your register says are Tier 1 should have the strongest agreements. If the window cleaner has a security schedule and the IT support company does not, the logic has gone wrong somewhere.

Common issues

• Contracts that exist but say nothing about security beyond a generic confidentiality clause.
• Data stored or supported outside the UK or EU, in breach of what the business has promised its own customers, and nobody has noticed.
• An assumption that the platform backs up your data, discovered to be wrong in the middle of an incident.
• No exit terms, or exit terms nobody has read. Former suppliers still holding complete copies of company data.
• Published terms accepted without anyone knowing what they say.
• No incident notification obligation, so the supplier tells you about a breach after the press does.
• Data processing agreements signed but never compared with the services actually being used.
• Security schedules applied to every supplier regardless of risk, so the important ones are buried among the trivial.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• For your three most important suppliers, where is your data stored, and does that match what your largest customer expects?
• If ransomware encrypted your Microsoft 365 or Google Workspace data tomorrow, who would restore it, and from what?
• For a supplier you stopped using in the last two years, what happened to your data?
• For your main cloud platform, could you summarise in a sentence what its terms say about incident notification?
• Which of your Tier 1 suppliers has no security obligations written down anywhere?

The second question is the one that tends to cause a sharp intake of breath. It is much better to have that moment now than during an incident.

A worked example

The figures below are typical rather than drawn from a single engagement. This is a composite of what a first contract review turns up in a business of this size.

A 30-person software company selling to banks and insurers, on Microsoft 365 and AWS, with an outsourced IT support company, a payroll bureau and a handful of SaaS tools. Its largest customer contract requires all customer data to remain within the UK.

What the review found

• The customer data in AWS was in a UK region, as required. But the support desk tool the team used for customer tickets, which routinely contained customer data, stored everything in the United States.
• Nobody had a backup of Microsoft 365. Everyone assumed Microsoft “had it covered”.
• The IT support company’s contract covered response times and nothing about security: no incident notification, no exit terms, no sub-processor list.
• AWS and Microsoft terms had been accepted, reasonably, but nobody could say what either said about incident notification or data location.
• A former marketing agency still had a live login to the CRM, eighteen months after the contract ended.

What changed

• The support desk tool was reconfigured to an EU data region, and the customer was told proactively, which went down well.
• A third-party backup service was bought for Microsoft 365, with 12 months’ retention and a tested restore.
• An addendum was agreed with the IT support company covering 24-hour incident notification, sub-processors and data return at exit.
• The AWS and Microsoft terms were summarised with an AI assistant, the flagged sections read in full, and a short note of the key provisions filed against each supplier.
• The agency’s access was removed the same day, and an exit step added to the supplier procedure.

About two days of effort, most of it on the support desk migration. The data location issue alone was worth it: it would have been a straightforward finding in the bank’s next supplier audit.

How control 5.20 links to other clauses and controls

• Control 5.19, Information security in supplier relationships. Your assessment and tiering decide what each agreement needs to cover.
• Control 5.21, Managing information security in the ICT supply chain. The sub-processor clause is how you find out who your suppliers rely on.
• Control 5.22, Monitoring, review and change management of supplier services. What you agree here is what you later review the supplier against.
• Control 5.23, Information security for use of cloud services. Most of your Tier 1 agreements will be cloud terms, and the data location and exit questions apply with particular force.
• Control 5.31, Legal, statutory, regulatory and contractual requirements. Your obligations to your own customers are contractual requirements, and your supplier agreements have to respect them.
• Control 5.34, Privacy and protection of PII. Data processing agreements and international transfer rules sit alongside this control wherever personal data is involved.
• Control 8.13, Information backup. Where the agreement says backup is your responsibility, this is the control that makes sure it happens.

Frequently asked questions

Can I just accept a cloud provider’s standard terms?

Yes. For large platforms you cannot negotiate, accepting the published terms is a perfectly defensible position. What you need to show is that you understood them: where your data is held, what they will tell you about incidents, what they are responsible for, and what happens at exit. Record those answers against the supplier.

Does every supplier need a security schedule?

No. The standard says requirements should be based on the type of supplier relationship. Suppliers who hold your information or can reach your systems need security obligations agreed. Suppliers with no access to anything need nothing beyond normal commercial terms.

Is a data processing agreement enough for control 5.20?

It covers a good deal, particularly confidentiality, sub-processors and data return, but not necessarily everything. Check it against what you actually need: incident notification timescales, data location, backup responsibility and assurance. Where it falls short, an addendum or a recorded understanding of the supplier’s other terms fills the gap.

Does Microsoft back up my Microsoft 365 data?

Microsoft protects the platform with redundancy and failover, and provides retention and recycle bin features with time limits. Restoring your own data after corruption, mass deletion or ransomware is largely your responsibility under the shared responsibility model, which is why many organisations add a third-party backup service. Check the current terms for your own subscription and record what they say.

What should happen to our data when a supplier contract ends?

It should be returned in a usable format within an agreed timescale, and the supplier’s copies, including backups, deleted with written confirmation. Their access to your systems should be removed on the same day the relationship ends. Agree this at the start, because it is much harder to negotiate once the relationship has soured.

Can I use AI to review supplier terms and conditions?

Yes, as a first pass. Ask it to summarise the data location, incident notification, liability, backup and exit provisions and to flag anything unusual. Then read the flagged sections yourself. It is a quick, proportionate way to understand terms you cannot change, but it is not legal advice, and a high-stakes contract still deserves a lawyer.