ISO 27001 A.5.20: Agree Supplier Security Requirements

What A.5.20 requires in practice

Control A.5.20 asks the organisation to establish relevant information security requirements and agree them with each supplier, according to the type of relationship. The key phrase is the type of relationship: a cloud host, a cleaning contractor and a software reseller need very different terms. The control has three practical parts: deciding what security requirements apply for that supplier, putting them in an agreement or equivalent arrangement the supplier accepts, and making sure both sides understand who does what.

The control statement stops short of listing clauses to include. What the agreement covers depends on the information handled, applicable law and the risk found during assessment. A standard contract schedule can be a convenient method, but the requirement is agreed, relevant terms, not a particular document.

Describe the service boundary accurately

Identify the information, systems and activities covered by the arrangement. Explain what the supplier may access or process and which responsibilities remain with your organisation. If a contract describes only the commercial deliverable, important assumptions about administration, storage or support access may remain untested.

Connect each consequential risk with a requirement that can be understood operationally. A requirement to remove access at the end of an assignment should identify who receives the instruction and how completion is confirmed. A recovery commitment should relate to the service and information the business actually needs, rather than a broad marketing statement.

Avoid promising more than either party can implement. If a supplier’s standard service does not support a proposed restriction, resolve the gap before representing it as agreed. The authorised decision may change the service, narrow its use or accept a justified limitation with other treatment.

Make incidents and changes actionable

Agree the route for security concerns and the information each party needs to cooperate during an incident. Consider how contacts remain current and what happens outside normal business hours when relevant. Do not insert an arbitrary notification period and present it as universally required by ISO 27001; applicable obligations and the relationship determine the detail.

Changes can alter the original risk decision. A new subcontractor, hosting arrangement or support location may require notification, assessment or approval depending on the agreed terms. Connect those terms with supplier service monitoring and change management. A notification right is ineffective if no one receives or evaluates the notice.

Why agreed supplier terms matter to the business

Without agreed security terms, you depend on goodwill when something goes wrong. Who must tell you about a breach, who may use your data, who can see it and what happens when the service ends are all questions that are cheap to answer in a contract and expensive to argue about afterwards. Clear terms also protect the supplier, because expectations are written down. For clients and regulators, agreed requirements show that your organisation has passed its own obligations down the chain. During an audit, a sample of contracts that match the risk found in assessment is persuasive evidence of control.

How to implement A.5.20

Treat agreements as the point where assessment results become obligations. One sequence that works well is set out below. Agreements are negotiated between people with different priorities, so decide in advance which security requirements are essential for each supplier type and where there is room to compromise. Where a supplier refuses a term, record the decision and any compensating measure rather than leaving the gap unrecorded. Sales, legal and the service owner should see the same version, so nobody relies on an outdated draft.

1. Use the supplier assessment to list the concerns that need contractual cover.
2. Decide which requirements apply to each type of relationship, such as data handling, access, incident notice and subcontracting.
3. Involve legal and the service owner so terms are enforceable and workable.
4. Agree the requirements with the supplier and keep the accepted version on file.
5. Make the split of responsibilities explicit where the supplier runs a platform and you configure it.
6. Cover what happens to information when the relationship ends.
7. Revisit terms when the service or risk changes.

Illustrative software example: support access hidden in the service

Illustrative manufacturing example: maintenance records at exit

A hypothetical manufacturer changes the provider supporting a production monitoring system. Historic configuration and maintenance records are needed to operate safely and reliably, but their return format and timing were never agreed. The outgoing provider offers screenshots that cannot support the planned handover.

For the replacement arrangement, the manufacturer defines the records needed, acceptable delivery format and responsibilities at transition. It checks a sample export during service operation. Exit becomes a tested capability rather than a dispute left until the final invoice, while retention and confidentiality obligations remain appropriately addressed.

Agree evidence that can answer your questions

Keep agreements current and usable

Maintain access to the applicable versions and identify which terms govern each relationship. Agreements can consist of related documents, but contradictions must be resolved. Operational teams should receive the commitments they need to implement without having to interpret a large legal pack unaided.

Useful evidence includes approved requirements, agreed terms, identified deviations and actions showing implementation. No particular contract-register format is universally prescribed by A.5.20. Common failures include unsigned security schedules, conflicting renewal terms and requirements copied from a different service without checking feasibility. Link sensitive exchanges with information-transfer controls.

Common nonconformities with A.5.20

Findings tend to arise when agreements were signed before security was considered. Findings tend to arise when agreements were signed before security was considered. An auditor will often take a sample of contracts and compare their terms with what the assessment said the supplier needed.

• Contracts with suppliers holding sensitive data that say nothing about incident notification or confidentiality.
• A single generic clause applied to every supplier regardless of what each one handles.
• Suppliers using subcontractors with no agreed position on onward sharing.
• Verbal arrangements for services that were never put into an agreement.