A.5.20 Supplier agreements: requirements and evidence

What A.5.20 requires in supplier contracts and why auditors sample it

A.5.20 asks you to establish and agree relevant information security requirements with each supplier, based on the type of supplier relationship. The control carries forward ISO/IEC 27001:2013 control A.15.1.2, Addressing security within supplier agreements, so the requirement is not new, but the 2022 edition places it in the organizational theme alongside the supplier risk controls it depends on. For a compliance lead, the practical test is simple: for each supplier that can reach personal data, production systems or confidential information, can you point to written security terms in the signed agreement that match the risk the supplier creates? If the answer depends on an email, a questionnaire response or a verbal assurance, the control is weak. ISO/IEC 27002:2022 gives implementation guidance on this control, and it is the right reference when you need to explain to an assessor what good practice looks like, though the standard itself is not a contract template.

The risk is concentrated in suppliers that touch data or systems without binding security obligations. A hosting provider, a software vendor with remote administrative access, or a contractor with a laptop on your network may each handle sensitive information while the contract covers only price, service levels and liability. Three things make the control hard to run. First, the volume of contracts is large and often spread across procurement, IT and business units. Second, relationship types differ: a commodity software license, a managed service and a outsourced development team need different clauses, and a single template rarely fits them all. Third, the wording lives with legal, while the security requirements are known to the security team, so each side assumes the other has covered the gap. Map each supplier to its relationship type, agree the security requirements that type needs, and record who approved them. Auditors commonly sample a few contracts for high-risk suppliers and check whether the clauses exist, not only whether a policy says they should.

Which suppliers and contracts fall under A.5.20

A.5.20 applies to every supplier whose work touches information, systems or services the ISMS covers, so scoping starts with the supplier inventory and the risk categories from A.5.19. The type of relationship then decides which security clauses each contract needs, from data handling to system access to exit terms.

Cloud and SaaS providers

Cloud platforms and SaaS tools often hold customer or internal data without the organization ever touching their infrastructure. Scope them by what data and functions they process, not by how small the contract looks. For each one, check whether the agreement sets out which security responsibilities sit with the provider and which stay with the organization, and whether the provider commits to notifying the organization of incidents. Ask the provider for its own independent assurance reports and confirm which of them cover the services you buy.

Outsourced development

Outside developers who write code, configure systems or handle source repositories can introduce vulnerabilities and gain access to secrets. Agreements should specify secure development expectations, code ownership, handling of credentials and test data, and who may access production. Confirm whether the developer can use subcontractors and whether those subcontractors must meet the same terms. Include return or destruction of code and data as a defined end-of-contract obligation.

Managed services and operations

Managed service providers that run systems on the organization's behalf hold privileged access, which makes their security terms more demanding than those for a simple product purchase. Contracts should define administrative access controls, logging of provider activity, and the provider's obligation to report security events within agreed timeframes. Check how the provider separates its own staff's access from other customers' environments. Right to audit clauses matter most here because the organization depends on the provider's operating practice.

Hosting and data processors

Hosting providers and data processors store or process personal and confidential information on the organization's behalf. Agreements should state the processing purposes, data location, subprocessor approval, encryption responsibilities and deletion at contract end. Where personal data is involved, align the clauses with the processing terms the privacy rules require. Confirm the incident notification window and who pays for breach response work.

Contractors with system access

Individual contractors and staffing firms may hold accounts, devices or physical badges, which makes them users of the ISMS as well as suppliers. Their agreements should require background screening where the role warrants it, acceptable use acceptance, prompt removal of access when the engagement ends, and return of equipment and information. Tie access rights to the contractor's role and review them on the same cycle as employee access. Confirm that the contract names who within the organization approves and revokes this access.

Component and hardware supply

Suppliers of hardware, firmware, software components or licensed libraries may not operate anything for the organization, yet their products can carry risk into its systems. Agreements should address vulnerability disclosure, patch timelines, component provenance and notification of end-of-support dates. Where supply chain risk is significant, A.5.21 extends these requirements to the suppliers' own suppliers. Record which components are critical so the contract terms match the risk.

How an assessor tests supplier agreements

This table sets out what an assessor requests for each step of testing A.5.20 and the findings that most often come up at each step. Read it as a checklist for your own contract review before the auditor arrives, since the same samples and documents are what the assessor will ask for.

Test step	Evidence requested	Common findings
Sample suppliers by risk	Supplier register with service type, data access and criticality ratings, plus the sample the assessor selects from it	Register lists suppliers but gives no risk rating, so the sample cannot be justified
Check requirements match relationship type	Requirement set per supplier category, such as cloud hosting, managed service, software licence or professional services	One generic clause set applied to every supplier regardless of the data or access involved
Read contracts for security clauses	Signed master agreements, order forms and data processing terms for each sampled supplier	Security terms missing from older agreements or buried in a web policy the supplier can change
Confirm right to audit	Clause text giving the organization audit or assessment rights, or accepted independent reports where the clause allows them	Audit right exists on paper but no exercise, questionnaire or report review has ever been recorded
Confirm incident notification terms	Notification window, contact route and the supplier's obligation to share details, with the matching supplier escalation contacts	Notification clause refers to a period that differs from the internal incident procedure
Confirm end-of-contract obligations	Clauses covering return or deletion of data, transition support and certification of disposal	No exit terms, or deletion depends on a request the team has never actually made
Compare contract to actual handling	Sample of supplier reports, security reviews, support tickets and records showing the agreed terms were enforced	Clauses that nobody monitors: no owner, no review date and no record of supplier performance against them
Check timing against the policy	Contract dates, policy approval dates and records showing when supplier requirements were introduced	Contracts signed before the supplier security policy existed, with no addendum or review since

Writing security requirements into supplier contracts step by step

This sequence turns A.5.20 from a policy statement into signed agreements that match each supplier's relationship type and risk, with a record an auditor can sample. Each step produces a named output that the next step depends on.

Classify suppliers by relationship type
The organization, usually through its procurement and security owners, sorts every supplier into relationship types such as cloud and hosting providers, software vendors, outsourced operators with access to systems, professional services with on-site or remote access, and suppliers that handle personal data. The type decides which security requirements apply, so the classes must be written down with a short rule for each. The output is a supplier classification scheme, approved by the owner of the ISMS, and an initial list of suppliers assigned to a class. The step is done when every supplier on the inventory has exactly one class and the scheme names who may reclassify a supplier.
Define a baseline clause set per type
For each relationship type, the security owner drafts a standard set of clauses that the contract must contain, covering security responsibilities, handling of confidential information, access and authentication for supplier staff, subcontracting, security incident notification, right to audit or receive assurance evidence, and what happens to data at the end of the contract. Legal counsel reviews the wording so it can be enforced under the organization's contract templates. The output is a clause library with one baseline per type and a note on which clauses are mandatory and which are negotiable. Confirm with counsel which local requirements the clauses must reflect, since A.5.31 requires the organization to track its legal and contractual obligations.
Map clauses to the supplier risk assessment
Each supplier's risk assessment, which A.5.19 expects before engagement, decides which baseline clauses are required and whether any need stronger wording. A supplier that hosts regulated data or has privileged access to production systems typically needs the fullest set, while a supplier that only provides a public information service may need less. The assessor records the clause selection and any additional requirements in the assessment file, with a reason for each change. The output is a completed clause selection for that supplier. The step is done when each high-impact supplier has a documented reason for every clause it omits from the baseline.
Negotiate, agree and sign the terms
The procurement lead sends the selected clauses to the supplier, records each requested change, and escalates any clause the supplier refuses to the risk owner, who decides whether to accept the residual risk, add compensating controls or choose another supplier. Once terms are agreed, the contract is signed by an authorized signatory on each side. The output is a signed agreement with its security schedule attached and a short negotiation log showing which clauses were changed or waived and who approved each decision. Keep the signed version, not the draft, as the evidence an assessor will sample.
Record the agreed terms in a supplier register
The organization enters each signed agreement into a supplier register that holds the supplier's classification, the clauses in force, the contract dates, the named business owner, the security contact at the supplier, and links to the signed documents and the latest assessment. Records should be kept in a system with version history and access control so that changes can be traced. The output is a register entry for each supplier. The step is done when a sample of contracts can be traced from the register to the signed document and the risk assessment without manual searching.
Monitor against the agreed terms
The business owner and security owner check, at intervals set by the supplier's class, that the supplier is meeting the clauses it agreed to, using the reports, certificates or audit results the contract entitles the organization to receive. Findings that fall short are logged and tracked to closure, and the outcome feeds the supplier review controlled under A.5.22. The output is a dated review record per supplier with any findings and their status. Confirm the review frequency for each class in the organization's own supplier policy, because the standard does not fix one.
Handle renewals, changes and exit
When a contract renews, when the service changes materially, or when a supplier is ended, the register entry is updated and the clauses are checked again against the current risk assessment. Renewal is the natural point to add clauses that were missing, and exit triggers the end-of-contract obligations, such as return or deletion of information and removal of supplier access, with written confirmation from the supplier. The output is an updated register entry and, at exit, a closure record showing that data was returned or destroyed and access was revoked. The step is complete when no supplier retains access or data after its contract has ended without a recorded reason.

Which security clauses a supplier agreement should contain

A.5.20 asks the organization to agree relevant information security requirements with each supplier, and the agreement is where those requirements become enforceable. The clause areas that usually matter are security requirements and the standards the supplier must meet, the organization's right to audit or to obtain independent assurance reports, incident notification timing and the supplier's duty to cooperate in investigations, subcontractor controls, where data may be stored and processed, confidentiality terms, and what happens to information when the contract ends. Which of these carry weight depends on the relationship. A cloud hosting provider holding customer records needs strong data location and deletion terms, while a supplier that only provides office consumables needs far less. Start by classifying each supplier by the information and access it will hold, then select the clauses that match that risk.

Right to audit and incident notification are the clauses most often left vague. For audit, ask whether the contract gives the organization a route to review controls directly, or only a right to receive the supplier's independent assurance report, and confirm which reports the supplier actually issues and how current they are. For incidents, the contract should set a notification window, a named contact, the information the supplier must provide, and its duty to support investigation and evidence preservation. Subcontractor clauses should require disclosure of material sub-suppliers, flow-down of equivalent security terms and notice before changes. Confidentiality terms should align with the non-disclosure controls under A.6.6, and end-of-contract terms should cover return or secure deletion of information with written confirmation.

Before signing, have counsel review the wording, since legal and contractual obligations also feed A.5.31. Confirm what each clause requires in practice with the supplier's security and legal teams, record the agreed positions in a register that links each supplier to its clauses, and schedule a review when the contract renews or the service changes. Clauses that cannot be enforced or evidenced will not help an assessor who samples supplier agreements, so keep the register current with the contracts it describes.

Evidence that satisfies A.5.20

A.5.20 is tested through documents and records, not through a single policy statement. The artifacts below show that supplier security requirements were chosen by relationship type, written into contracts, and kept current as suppliers and services changed. An assessor will usually start from the supplier register and sample back into the signed agreements.

Clause library

A controlled set of standard security clauses the organization approves for reuse, such as confidentiality, audit rights, incident notification, subcontracting and data return. Each clause is tagged with the supplier relationship types it applies to, so procurement starts from approved wording rather than drafting from scratch. Check that the library has an owner, a version number and a record of which clauses legal approved.

Supplier register with relationship types

A register that lists every supplier, the contract that governs it, the relationship type, and the information security requirements that apply. This is the artifact that proves requirements were set *according to the type of relationship*, which is what the control asks for. Check that no active supplier is missing and that each entry points to a signed document rather than an email thread.

Signed agreements and security schedules

The executed contracts and their security schedules, showing the requirements agreed with each supplier. An assessor will compare the schedule against the risk level recorded for that supplier and ask who signed for both parties. Confirm that schedules are attached to the signed version, not kept as a separate draft.

Incident notification terms

Contract wording that sets how and when a supplier must report a security incident affecting the organization's information, along with the named contacts on each side. Pair the clause with evidence that the notice period was tested or reflected in the organization's own incident response plan. Check that notification duties reach subcontractors where the supplier relies on them.

Exit and return-of-data provisions

Clauses covering how information is returned, transferred or deleted when the contract ends, and the timeframe for doing so. The evidence is the clause itself plus any exit plan or deletion confirmation from a past termination. Ask suppliers to confirm in writing how data held on their systems, including backups, is removed.

Renewal review and version history

Records showing each agreement was reviewed at renewal or after a material change in the service, with the outcome and the approver. Keep document versions with dates and change summaries so an assessor can see what changed and when. Each record should carry an owner sign-off, and the register should show when the next review falls due.

Who owns the contract language, the controls and the audit

The organization owns the supplier agreements, the security requirements written into them and the decision to accept each residual risk. Legal, procurement and information security share this work. Legal confirms that clauses are enforceable under the governing law, procurement applies them during negotiation, and security decides which requirements a given supplier must meet based on what that supplier can access or do. Management signs off the clause library, and the organization keeps the signed contracts as evidence.

Clause library ownership: Legal and security approve a standard set of security clauses, with named owners and a review date for each.
Risk-based tiers: Security assigns each supplier relationship to a tier that determines which clauses apply, such as data access, hosting or privileged administration.
Negotiation and exceptions: Procurement records every deviation from the standard clauses, with a named approver and a reason.
Signed record: The organization stores executed agreements, their version history and any side letters where auditors can sample them.
Accountability: Leadership accepts responsibility for supplier security terms even when a partner drafted them.

Before relying on any template, confirm with your legal team that each clause fits your jurisdiction and your existing supplier contracts.

Where supplier agreements usually fall short

Most supplier contracts were signed for commercial reasons and never revisited for security. The gaps below recur across organizations of every size, and each one weakens the evidence an assessor will ask for under A.5.20. Each card names the gap and the one action that closes it.

No supplier register

Without a maintained list of suppliers that hold data, run systems or touch operations, nobody can say which agreements need security clauses at all. Start with a register that records each supplier, the information it handles, the type of relationship, the contract owner and the date security terms were last agreed. Ask the procurement team and each business unit to confirm the list against accounts payable and cloud billing, because the first gap is usually a tool bought on a corporate card.

Contracts without security schedules

Many agreements contain confidentiality language and nothing about how the supplier protects the organization's information. A security schedule sets out the minimum controls, the locations where data is processed, the personnel screening expected and the certifications or reports the supplier must provide. Check each high-risk contract for a schedule that matches the supplier's access, and add one at renewal if it is missing.

Audit rights never exercised

A right to audit that appears in a contract but has never been used is weak evidence. Assessors look for a documented decision on whether to audit each critical supplier, the scope of that review and the findings that followed. Confirm which suppliers have an audit right, decide the review method for each (questionnaire, report review or on-site assessment), and file the outcome with the supplier record.

Incident notification timelines missing

When a supplier suffers a breach, the organization often learns about it from the press. The agreement should state how quickly the supplier must notify the organization, who receives the notice, what information it must contain and how the supplier supports investigation. Check that the notification period is shorter than the organization's own reporting deadlines, and confirm the named contact is still employed in that role.

No exit and data return terms

Agreements that end without instructions leave data with a former supplier and access open. The contract should require return or secure deletion of information at termination, confirm the format of data return and the timeline, and remove access credentials. Test the process in a tabletop or small pilot before a switch is forced, because the supplier controls the data until then.

Subcontractors outside the contract

Suppliers often rely on their own providers for hosting, support or processing, and the main agreement may say nothing about them. Require the supplier to disclose material subcontractors, to flow down equivalent security obligations and to notify the organization before a material change. Ask each critical supplier for its current subprocessor list and record the date it was reviewed.

Questions buyers ask about A.5.20 cost, effort and outside help

How much effort does it take to re-paper existing supplier contracts for A.5.20?

The effort depends on how many supplier agreements need changes and how much each one already contains. Start by sorting suppliers by the type of relationship and the data or systems they touch, because A.5.20 asks for requirements that match each relationship. Most organizations find that a small group of critical suppliers needs full clause sets, while low-risk suppliers need only a short security schedule or a standard addendum. Count the contracts in each group, check which already have security terms, and estimate the negotiation rounds for the rest. No public figure for this effort was supplied, so ask your own contract owners to size the work before you commit to a timeline.

Can our team write and apply supplier security clauses without a partner?

Yes, many teams do this in-house, provided they have the right people in the room. The security team drafts the technical requirements, legal reviews the wording and remedies, and procurement manages the negotiation and renewal dates. The gap that usually slows teams down is the absence of a standard clause library and a tracking register, so every contract ends up different. An outside implementation partner can help build that library, the register and the evidence templates, but the organization still owns the supplier relationships, the decisions and the signed agreements. Only an independent auditor can later test whether the clauses work in practice.

What makes the work to meet A.5.20 cost more or take longer?

Several factors push the work up. The main ones are a large number of suppliers with access to sensitive information, suppliers that resist standard terms, contracts with long renewal cycles, and multiple legal entities or jurisdictions that each have their own templates. Cloud and software vendors often refuse to change their standard terms, so the organization must decide what it accepts, what it compensates for with other controls, and what it documents. Gaps in the supplier inventory also add work, because you cannot agree requirements with suppliers you have not identified. Ask any provider to price each of these factors separately in the written scope.

How long does it take to agree supplier security requirements?

No researched duration for this work was supplied, so treat any timeline as something to confirm with your own contract owners and suppliers. The duration is driven by the number of agreements in scope, the supplier response times, and internal approval cycles. A realistic plan separates the work into three steps: defining the clause set by relationship type, agreeing the terms with a first wave of critical suppliers, and then moving through renewals. Ask any implementation partner to base its timeline on the written list of contracts in scope, with named milestones, rather than on a generic promise.

What do legal and procurement teams need to contribute to A.5.20?

Legal and procurement own much of the contract work. Legal needs to draft or approve the security clause language, define the right to audit, set incident notification windows that match internal reporting duties, and agree how data is returned or deleted when a contract ends. Procurement needs to build security requirements into request-for-proposal templates, schedule reviews at renewal, and track which suppliers have signed the updated terms. Both teams should also agree on an escalation route for suppliers that refuse a clause, so the security team can record the risk decision. Ask for these responsibilities to be listed in the scope document so each role is clear from the start.

Can an ISO 27001 auditor write our supplier clauses for us?

No. An auditor is independent of the organization and must not design the controls it tests, so it cannot write the clauses. The auditor's role is to check whether the agreed requirements exist, whether they are in the signed contracts, and whether the organization monitors suppliers against them. Writing the clauses is the organization's responsibility, sometimes supported by legal counsel or an implementation partner. If you want outside help with drafting, engage a consultant or implementer separately, and keep the certification body independent of that work so the audit remains credible.

What evidence should we keep to show A.5.20 is met?

Auditors usually look for a supplier register that links each supplier to its relationship type, the signed agreements with the agreed security requirements, and records of any exceptions with the risk decision behind them. They also expect a standard clause library, the approval history for changes, and renewal records showing that terms were reviewed. Keep these in a controlled location with version history, so you can show what was agreed and when. Self-hosted wiki and documentation tools with version control can hold these documents, and a GRC tool can track the register, but confirm each product's features in your own environment before relying on them.

What should we ask a provider for in a written quote?

Ask for a written scope that lists the supplier categories and contracts in scope, the deliverables such as the clause library, register and templates, and the roles each party carries out. The quote should separate one-time work, such as drafting and initial negotiation, from recurring work, such as renewals and annual reviews. Ask who attends negotiations, what happens when a supplier rejects a clause, and how changes to scope are priced. DeployOpen plans and prepares these systems and documents under a fixed scope agreed in writing before work starts, and it does not issue audit reports or certificates.

How DeployOpen prepares supplier agreement evidence

DeployOpen helps organizations prepare the systems, records and evidence behind A.5.20 Addressing information security within supplier agreements. The organization still owns its supplier terms and signs its own contracts, and only an independent auditor or certification body can issue a certificate.

How we scope

Agree in writing which supplier relationships, contract templates and clause sets the engagement covers before work starts.
Confirm which supplier types need security clauses, such as hosted platforms, managed services and outsourced development.
Name the internal owners who approve contract requirements, receive incident notices and hold the evidence.

How we build

Set up a self-hosted register of supplier agreements that records security clauses, audit rights and notification terms.
Document a standard set of security requirements per supplier relationship type, for the legal team to review and adopt.
Configure the wiki and permissions so contract evidence is versioned, reviewable and limited to the people who need it.

How we hand over

Deliver the supplier requirements, register, configuration records and procedures as documents the organization owns.
Provide a walkthrough showing how an assessor can trace a sampled supplier to its signed clauses and review history.
Document open items, such as clauses legal counsel must still negotiate, so the organization can close them independently.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing of the platforms are available as a retainer.
Ask any implementation partner to confirm which steps they perform and which the organization or its auditor must perform.