ISO 27001 A.5.20 - Addressing Information Security Within Supplier Agreements

Requirement

“Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship.”

Plain-language meaning

The organization must put the right security requirements into supplier contracts or agreements before the supplier receives access to information, systems, facilities, or services.

A.5.19 says supplier security risks must be managed. A.5.20 makes the agreement part explicit: the supplier must know, accept, and be bound by the security requirements that match the relationship.

Why this matters

Supplier personnel may need the same level of security discipline as internal staff, but the organization does not directly manage the supplier’s people, infrastructure, policies, or risk appetite.

Without agreement terms, security expectations become informal requests. Informal requests are weak when there is a breach, service failure, dispute, audit finding, subcontractor issue, or termination.

Implementation guidance

1. Start from supplier risk and relationship type

Do not use the same contract language for every supplier. Define requirements based on:

The agreement should reflect the risk assessment, not generic procurement wording.

2. Define security requirements before access

Supplier access should not begin until required controls are agreed and implemented.

Typical agreement requirements include:

• confidentiality and non-disclosure;
• acceptable use;
• access control and identity requirements;
• MFA or privileged access requirements;
• information classification and handling;
• secure transfer methods;
• incident notification timeframes;
• logging and monitoring expectations;
• vulnerability and patch expectations;
• service availability and continuity requirements;
• audit, assurance, and right-to-review clauses;
• subcontractor restrictions and flow-down obligations;
• data return, deletion, or transfer at termination;
• liability, breach handling, and non-performance consequences.

3. Identify who is responsible for each control

Supplier agreements should not say “security will be maintained” without assigning responsibility.

Use a control responsibility matrix:

The point is not the exact split. The point is that both parties understand it.

4. Confirm authorized signatories

The agreement should be approved by people who have authority to bind each party. Security requirements can fail if agreed informally by operational staff without legal, procurement, supplier owner, or management approval.

5. Document deviations

If a supplier cannot meet a required security term, record:

• the deviation;
• risk impact;
• compensating controls;
• approval;
• review date;
• whether the Statement of Applicability or risk treatment plan is affected.

Audit guidance

Auditors should sample supplier relationships and verify that security requirements are established, agreed, approved, and appropriate to the relationship.

Audit tests:

• compare supplier risk assessments to contract requirements;
• verify that access was not granted before required terms were in place;
• check whether supplier staff with access are subject to equivalent controls;
• review whether responsibilities are assigned between parties;
• verify signatory authority;
• check how deviations are approved and tracked;
• test whether termination and change clauses exist;
• confirm that security terms cover non-performance, incidents, liability, and disruption.

Evidence examples

Strong evidence

• Agreement terms map directly to supplier risk and information exposure.
• Access is blocked until agreement requirements are approved.
• Security responsibilities are explicit.
• Subcontractor obligations flow down.
• Incident notification and termination requirements are clear.
• Deviations are documented, justified, approved, and reviewed.

Weak evidence

• Standard procurement contract with no security schedule.
• Security expectations sent by email but not agreed.
• Supplier access starts before contract completion.
• No evidence that signatories were authorized.
• Supplier staff have access but no equivalent security obligations.
• Exceptions exist but are not risk-assessed.

Common failures

Exam traps

• A.5.20 is not just “have a contract”; the contract must include relevant security requirements.
• Requirements should depend on the supplier relationship and risk.
• Supplier personnel with access may need controls equivalent to internal personnel.
• Do not grant access before agreed controls are implemented.
• Certification can be useful evidence, but it does not replace relationship-specific requirements.
• Deviations from required supplier controls should be justified and documented.

Related controls and concepts

• A.5.19 Information Security in Supplier Relationships
• A.5.21 Managing Information Security in the ICT Supply Chain
• A.5.22 Monitoring, Review and Change Management of Supplier Services
• Risk Assessment
• Statement of Applicability
• A.5.14 Information Transfer
• A.5.15 Access Control
• A.5.18 Access Rights
• Supplier Security Register
• Supplier Security Risk Assessment

KB-ready summary

A.5.20 requires security requirements to be established and agreed with suppliers based on the supplier relationship. Practical implementation means risk-based contract clauses, clear control responsibilities, authorized approval, access only after requirements are in place, and documented deviations.

Templates and checklists

• Supplier Security Agreement Requirements Checklist
• Supplier Security Responsibility Matrix
• A.5.20 Audit Checklist