---
title: "Supplier security policy template"
canonical: https://www.grcmana.io/vault/templates/supplier-security-policy
published: 2024-03-01
updated: 2026-10-17
author: "Harry West"
framework: "ISO 27001"
type: "Policy"
---

# Supplier security policy template

## Key takeaways

A supplier security policy sets how an organisation chooses, contracts, monitors and exits the suppliers that handle its information, in proportion to risk. ISO 27001 controls A.5.19 to A.5.22 require defined supplier processes, security requirements agreed with each supplier, ICT supply chain controls and regular supplier review. This Word template suits UK firms of 25 to 250 staff.

- **Required by** — ISO 27001:2022 controls A.5.19, A.5.20, A.5.21 and A.5.22
- **Approved by** — Top management; a named owner runs each supplier's reviews
- **Review cycle** — Policy at least annually; critical suppliers at least annually and on material change
- **Format** — Word, about 14 pages, with a tiering worksheet and contract clause checklist

The questionnaire from your largest prospect has a section called "Third-party risk". It asks for your supplier security policy, how you rank your suppliers by risk, and whether your contracts let you check their security. The deal is waiting on the answer.

A supplier security policy is how you answer with evidence. This ISO 27001 supplier security policy template gives a UK firm of 25 to 250 staff a ready-to-edit policy in Word, covering controls A.5.19 to A.5.22. It works in both directions: managing your own suppliers, and answering the regulated clients who treat you as theirs.

## What's in the template

One Word document, about 14 pages, version 1.0. It has four parts.

1. **The supplier security policy.** Purpose and scope, roles (including a named owner for every supplier), a three-tier risk model, due diligence by tier, the minimum security clauses for supplier agreements, flow-down to subcontractors and the ICT supply chain, monitoring and change, supplier incidents, offboarding and exit, the supplier register, and how exceptions are accepted.
2. **Ready-to-use appendices.** A five-question tiering worksheet, a due diligence checklist for each tier, a contract clause checklist marked by tier, the column layout for a supplier register, and a "being the supplier" guide to the evidence regulated clients ask you for.
3. **A getting-started guide and next steps.** Where to start (the supplier list), which sections to set first, and what to do once the policy is approved.
4. **A policy management checklist.** Approval, the first tiering exercise, the contract gap log and review dates: the records an auditor asks to see alongside the policy.

Every placeholder is in square brackets. You set the tier thresholds, name the owners, choose your review intervals, and the policy is ready for management approval.

A supplier you've never assessed isn't low risk. It's unknown risk.

## What is a supplier security policy?

A supplier security policy is the document in which leadership sets how the organisation manages the information security risk that comes from its suppliers: which suppliers are in scope, how they're ranked by risk, what's checked before signing, what goes in the contract, how they're monitored and how the relationship ends. It governs the supplier register and the contracts rather than containing them.

Auditors ask for it because ISO 27001 treats your suppliers as part of your own risk. Customers ask for it because, when you hold their data or run part of their service, you're the supplier in their policy.

### Two directions: your suppliers, and you as a supplier

Most supplier policies only look one way. For a firm that sells to regulated clients, the same policy has to work in both directions.

| Direction | What the policy does | Who checks it |
| --- | --- | --- |
| Your suppliers | Tiers them by risk, sets due diligence and contract clauses, monitors them and manages the exit | Your ISO 27001 auditor, under controls A.5.19 to A.5.22 |
| You as a supplier | Shows clients that the risk you carry for them is managed down your own supply chain: the cloud host, the software tools, the contractors | Your clients' procurement, security and third-party risk teams, through questionnaires, contract schedules and audits |
| Where the two meet | The terms your clients impose on you, such as audit rights, incident notice and subcontracting consent, flow down to the suppliers who help you deliver their service | Both |

### Which standards and regulators ask for one

| Standard or regulator | What it asks for |
| --- | --- |
| ISO 27001:2022, control A.5.19 | Define and implement processes and procedures to manage the information security risks of using suppliers' products or services. |
| ISO 27001:2022, control A.5.20 | Establish the relevant information security requirements and agree them with each supplier, based on the type of supplier relationship. |
| ISO 27001:2022, control A.5.21 | Define and implement processes and procedures to manage the information security risks of the ICT products and services supply chain. |
| ISO 27001:2022, control A.5.22 | Regularly monitor, review, evaluate and manage change in suppliers' information security practices and service delivery. |
| UK GDPR, Article 28 | Use only processors that give sufficient guarantees of appropriate technical and organisational measures, under a binding contract covering, among other things, documented instructions, confidentiality, security, authorisation of sub-processors, deletion or return of data at the end, and audits. |
| DORA (EU financial entities) | Manage ICT third-party risk as part of the ICT risk management framework, keep a register of information on all contractual arrangements for ICT services, and include set provisions in those contracts, with more for services that support critical or important functions. |
| FCA (UK authorised firms) | A firm that outsources critical or important operational functions remains fully responsible for its regulatory obligations (SYSC 8.1.6R, or SYSC 8.1.6-AR for common platform firms). For common platform firms, SYSC 8.1.8R sets conditions on the service provider, including effective access to data and premises for the firm, its auditors and the regulator. |
| PRA (banks, building societies, PRA-designated investment firms and insurers) | Supervisory Statement SS2/21, Outsourcing and third party risk management, sets the PRA's expectations for managing outsourcing and other third-party arrangements. |
| Customer due diligence | Security questionnaires commonly ask for the policy, how suppliers are tiered, which suppliers hold client data, and evidence that critical suppliers are reviewed. |

For the depth on each control, see the guides to [A.5.19: supplier security across the full lifecycle](https://www.grcmana.io/vault/iso-27001/annex-a-5-19-information-security-in-supplier-relationships), [A.5.20: supplier agreements that hold up](https://www.grcmana.io/vault/iso-27001/annex-a-5-20-addressing-information-security-within-supplier-agreements), [A.5.21: the ICT supply chain](https://www.grcmana.io/vault/iso-27001/annex-a-5-21-information-security-in-the-supply-chain) and [A.5.22: monitoring and changes to supplier services](https://www.grcmana.io/vault/iso-27001/annex-a-5-22-change-management-of-supplier-services). Cloud services have a control of their own, covered in the [A.5.23 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-23-information-security-for-use-of-cloud-services).

### What regulated clients will ask of you

If your clients are banks, insurers or investment managers, their regulators expect them to manage you, and that reaches you as a contract schedule and a questionnaire. Expect questions on six things.

- **Your own supplier management.** Your policy, your tiers, and which suppliers will touch their data.
- **Audit and access rights.** Whether they, their auditors and their regulator can get at the information and premises relevant to the service.
- **Incident notification.** How quickly you'll tell them about an incident affecting their service, and how you'll help them respond.
- **Subcontracting.** Whether you'll ask their consent, or give notice, before handing part of their service to someone else, and whether their terms flow down.
- **Data location.** Where their data is processed and stored, including by your sub-processors.
- **Continuity and exit.** Your tested continuity plans, and how you'd support an orderly handover if they leave or you fail.

The template's "being the supplier" appendix lists each of these against the evidence to have ready.

Your client's regulator never signs your contract. Its expectations arrive in it anyway.

## How to create your supplier security policy with this template

With a supplier list to hand, this takes about a day of drafting and one management meeting, then an hour or two for each critical supplier's due diligence. Without the list, start there: a policy can't tier suppliers you haven't found.

### Before you start

Your policy is only as complete as your view of who you rely on. Check you have:

- **A list of suppliers.** Pull it from accounts payable, card statements and your single sign-on, so you catch the software nobody formally bought. No list yet? Treat it as part of your asset inventory: see the [A.5.9 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-9-inventory-of-information-and-other-associated-assets).
- **A way to score risk.** Tiering is risk assessment applied to suppliers, so it should use the same scales as your risk method. No method yet? Start with the [clause 6.1 guide](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities).
- **Your clients' requirements.** The contract schedules and questionnaires your regulated clients send you are interested-party requirements, and they set the floor for your own supplier clauses. Collect them: see the [clause 4.2 guide](https://www.grcmana.io/vault/iso-27001/clause-4-2-understanding-the-needs-and-expectations-of-interested-parties).
- **Your standard contract terms and data processing agreement.** Know what you already ask suppliers to sign, and who can approve a change to it. No standard terms yet? Use the template's contract clause checklist as your starting list, and ask your legal adviser to turn it into terms. The [A.5.31 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-31-legal-statutory-regulatory-and-contractual-requirements) covers legal, regulatory and contractual requirements.

If none of these exist yet, the job is bigger than one policy. That's the point where most firms bring in help.

**1. Build the supplier list and name an owner for each** *(2 to 4 hours)*

- **Do this:** list every supplier that stores, processes or accesses your information, or provides a service your clients depend on. Put a named internal owner against each one: the person who uses the service and would notice first if it went wrong.
- **The template:** has a supplier register layout with the fields an auditor samples (owner, service, data held, tier, assurance, contract date and next review), and a role description for supplier owners.
- **Watch for:** the free and card-paid tools. A file converter or AI note-taker that someone signed up to with a work email can hold more client data than your accountant does.

**2. Tier every supplier by risk** *(1 to 2 hours)*

Next, put each supplier into one of three tiers by asking the same five questions: what data it holds, what access it has to your systems, how much of your service depends on it, how hard it would be to replace, and whether it supports something a regulated client has told you is critical. The template gives you the tiering worksheet and suggested thresholds for Critical, High and Low. Most firms of this size end up with a handful of critical suppliers.

> **Where most firms get stuck:** tiering by spend, or calling everything critical. The £200-a-month platform that hosts client data can matter more than the £50,000 office lease, and a register where everything is critical gets the same thin review across the board. Let data, access and dependency set the tier, so the effort goes where the risk is.

**3. Set due diligence in proportion to the tier** *(about an hour, then 1 to 2 hours per critical supplier)*

- **Do this:** decide what you'll check before signing at each tier. For critical suppliers: current independent assurance (an ISO 27001 certificate whose scope covers the service, or a SOC 2 Type 2 report), a short questionnaire on whatever the assurance doesn't cover, and where your data will sit. For low-tier suppliers: a basic check that they're legitimate, and terms that cover confidentiality.
- **The template:** includes a due diligence checklist for each tier, so a low-risk tool takes minutes and a critical one gets a proper look.
- **Watch for:** sending a 200-question questionnaire to every supplier. Large providers won't answer it and small ones answer it badly.

> **Where most firms get stuck:** accepting a certificate without reading it. An ISO 27001 certificate whose scope covers only the supplier's head office, or a SOC 2 report that ended last year, says little about the service you're buying. Check the scope, the dates and, for SOC 2, the exceptions and the controls the report expects you to run yourself.

**4. Set the contract clauses** *(about 2 hours, plus legal review)*

Then set the minimum security clauses each tier needs in its agreement: confidentiality, the data processing terms UK GDPR Article 28 requires where the supplier processes personal data for you, incident notification within a set time, control of sub-processors and subcontractors, the right to assurance or audit, continuity, and the return or destruction of data at exit. The template gives you a clause checklist marked by tier, so you can hold an existing contract against it and log the gaps. Where terms can't be negotiated, as with the large cloud platforms, record the gaps and how you've covered or accepted them. Where a regulated client has imposed terms on you, check that the suppliers delivering that client's service carry matching ones. Have your legal adviser review the clauses before you rely on them.

**5. Monitor, manage change and plan the exit, then approve** *(one management meeting, then a review cycle)*

- **Do this:** set review intervals by tier (critical suppliers at least annually, with their assurance checked before it expires), send supplier changes such as new sub-processors or hosting moves through your change process, and write an exit plan for each critical supplier. Then take the policy to top management for approval and set its review date.
- **The template:** has monitoring cadences by tier, the triggers for an unscheduled review, an offboarding section covering access removal and data return, and a policy management checklist for the approval and review records.
- **Watch for:** suppliers that leave but never lose access. The records that prove offboarding works are covered in [How to use it so it holds up at audit](#how-to-use-it-so-it-holds-up-at-audit).

A contract ends on a date. Access ends only when someone removes it.

### Do it yourself, or have us do it with you

|  | Do it yourself with the template | Do it with GRCMANA |
| --- | --- | --- |
| What you end up with | An approved supplier security policy, a tiered supplier register and a log of contract gaps | This policy plus a tiered register, due diligence on your critical suppliers, a contract gap review and the evidence your clients' third-party questionnaires ask for, all consistent with each other |
| Your time | About a day plus a management meeting, then 1 to 2 hours per critical supplier, if the groundwork is in place. Considerably more if it isn't | Depends on how much of the groundwork exists. We agree it with you at the start |
| Best if | You have a supplier list, a handful of critical suppliers and someone comfortable reading assurance reports | A client questionnaire or contract schedule is waiting, you don't know which suppliers hold client data, the audit date is fixed, or a deal depends on it |

Prefer the second column? [Talk to us about supplier assurance and ISO 27001 readiness](https://www.grcmana.io/contact).

## What does a good supplier security policy look like?

Most supplier security policies list the right topics. Fewer say who does what, for which supplier, by when. Here is the difference.

### Weak and strong, side by side

| Section | Weak | Strong | Why the strong one passes |
| --- | --- | --- | --- |
| Scope | "This policy applies to all third parties." | "This policy applies to every supplier that stores, processes or accesses \[Organisation\] information, or provides a service supporting \[client services\], including cloud services, software tools and contractors." | It names what brings a supplier into scope, so the register can be checked against it. |
| Tiering | "Suppliers will be assessed according to risk." | "Suppliers are tiered Critical, High or Low using the worksheet in Appendix A. Any supplier holding client data, or supporting a service a client has designated critical, is at least High." | Written criteria make tiers repeatable, and A.5.19 expects a defined process. |
| Due diligence | "Suppliers must demonstrate appropriate security." | "Before contract, Critical suppliers provide current independent assurance (an ISO 27001 certificate covering the service, or a SOC 2 Type 2 report less than \[12\] months old), reviewed by \[role\]." | It says what evidence, how recent, and who reviews it. |
| Agreements | "Contracts will include appropriate security clauses." | "Agreements with Critical and High suppliers include, as a minimum, the clauses in Appendix C, including incident notification within \[24\] hours and \[prior written consent\] for subcontracting." | A.5.20 needs requirements agreed with each supplier. A checklist can be tested against a contract. |
| Review and exit | "Suppliers will be reviewed regularly." | "Critical suppliers are reviewed every \[12\] months and whenever they notify a material change. On exit, \[owner\] removes access within \[5\] working days and obtains confirmation that data has been returned or destroyed." | A.5.22 needs regular review. Named timescales give the auditor something to sample. |

### What an auditor checks in the first five minutes

Before reading the detail, most auditors check that:

1. **It's current.** It has a version, top-management approval and a review date that hasn't passed.
2. **The register matches it.** Every supplier has an owner and a tier, set using the policy's criteria.
3. **Critical suppliers have evidence.** Assurance is on file, in date, and covers the service you buy.
4. **Contracts carry the clauses.** A sampled critical contract contains the minimum clauses, or the gap is recorded and accepted.
5. **Reviews happened.** The last review of each critical supplier is dated and within the interval.
6. **Leavers left.** A supplier whose contract ended recently has no remaining accounts or integrations.

If one fails, expect the auditor to look harder at every supplier.

### What good looks like at 25 staff and at 250

| Feature | Around 25 staff | Around 250 staff |
| --- | --- | --- |
| Register | A spreadsheet of 30 to 60 suppliers, each with an owner and a tier | A procurement or GRC tool, with tiers and review dates driving reminders |
| Critical suppliers | A handful: cloud hosting, core software and managed IT | Many more, with their own key sub-processors mapped |
| Due diligence | Certificates and SOC 2 reports read by the policy owner | A standard questionnaire, with security reviewing critical and high suppliers before contract |
| Contracts | Your standard terms plus the supplier's data processing agreement, with gaps logged | A clause library and a security schedule, negotiated for critical suppliers |
| Monitoring | An annual review of critical suppliers at a management meeting | Regular reviews of critical suppliers, assurance expiry tracked, and a supplier risk report to management |
| Exit | An offboarding checklist used whenever a supplier ends | Exit plans for critical suppliers, tested where a regulated client depends on them |

The common mistake at 25 staff is a policy written for a bank: on-site audits of every supplier that the firm will never carry out. The common mistake at 250 is a register that stops at procurement, so every tool bought on a card or through a free trial sits outside it.

## How to use it so it holds up at audit

The policy is only half the evidence. An auditor tests whether it operates, and these are the records they usually ask for:

- **The approval record:** who in top management approved this version, and when.
- **The supplier register:** each supplier with its owner, tier, service and data, and the date of its last review.
- **Due diligence records:** the assurance reviewed for each critical and high supplier, with dates and the reviewer's name.
- **Contracts and the gap log:** signed agreements for sampled suppliers, and a record of any missing clauses and who accepted the gap.
- **Review records:** dated reviews of critical suppliers, including notified changes and what you decided.
- **Offboarding records:** access removal, and confirmation that data was returned or destroyed, for suppliers that ended.

**The most common reasons this policy fails audit:**

- The register misses suppliers the auditor finds in the finance ledger or the single sign-on logs.
- Tiers exist, but critical suppliers get the same light check as everyone else.
- The assurance on file has expired, or its scope doesn't cover the service bought.
- Contracts pre-date the policy, and nobody has checked them against it.
- A supplier that ended still has active accounts or an API key.
- It was copied from a template and names a procurement team, tool or committee the firm doesn't have.

Each of these is cheaper to fix now than to explain in the audit room, or on a client's due diligence call.

## Supplier security policy questions

### What should a supplier security policy include?

Its scope, roles, risk tiers, due diligence by tier, the minimum security clauses for agreements, flow-down to subcontractors, monitoring, offboarding and exit, and the supplier register. It should also say how exceptions are accepted and how the policy is approved and reviewed.

### How do you tier suppliers by risk?

Ask the same questions of each supplier: what data it holds, what access it has, how much of your service depends on it, how hard it is to replace, and whether a client relies on it. Sort the answers into three tiers, and let the tier set the checks, the clauses and the review interval.

### Do small suppliers need a full security assessment?

No. Proportion is the point. A low-risk supplier with no access to your data or systems may need only a legitimacy check and confidentiality terms. Save independent assurance and questionnaires for the suppliers whose failure would hurt you or your clients.

### What is the difference between a supplier security policy and a data processing agreement?

The supplier security policy is your internal rulebook for all suppliers. A data processing agreement is a contract with one supplier that processes personal data on your behalf, covering the terms UK GDPR Article 28 requires. The policy says when a data processing agreement is needed and what it must contain.

### How often should suppliers be reviewed?

By tier. Review critical suppliers at least annually and whenever they notify a material change, high-risk suppliers on a longer cycle, and low-risk suppliers at renewal. Track assurance expiry dates too, so a lapsed certificate is caught before an auditor or a client finds it.

## Get the template

Start from a policy that already sets out the tiers, checks and clauses an auditor and a regulated client look for. Download the Word template, build your supplier list, and take it to your next management meeting.

*This template is a starting point to adapt to your organisation, not legal advice.*