What is ISO 27001 Annex A 5.20?
ISO 27001 Annex A 5.20 focuses on ensuring that relevant information-security requirements are established and agreed with each supplier, according to the nature of the supplier relationship and the associated risks.
A supplier may have access to:
- Company information
- Customer information
- Personal data
- Source code
- Cloud infrastructure
- Applications
- Credentials
- Confidential business information
The organization should therefore make its security expectations clear through appropriate contractual or equivalent agreements.
Simple Explanation
If a supplier can affect your security, don’t leave security expectations to assumptions—put the relevant requirements into the agreement.
Why is A.5.20 Important?
A supplier may say:
“We take security seriously.”
But this is not the same as having clearly defined contractual obligations.
For example, a SaaS provider may process your customer data.
Your organization may need the supplier to:
- Protect the data
- Restrict access
- Use appropriate security controls
- Notify you of security incidents
- Protect confidentiality
- Manage subcontractors
- Return or delete data when the relationship ends
If these expectations are not properly addressed in the agreement, it can become difficult to establish what the supplier is actually required to do.
A.5.20 helps provide clarity around:
- Security responsibilities
- Confidentiality
- Data protection
- Access control
- Incident notification
- Security requirements
- Compliance obligations
- Audit or assurance
- Subcontractors
- Data return and deletion
- Business continuity
- Service termination
Simple Principle
Security requirements should be agreed before the supplier receives access to important information or systems.
A.5.19 vs A.5.20
These two controls are closely related but should not be treated as the same.
| Control | Main Question |
|---|---|
| A.5.19 Supplier Relationships | What information-security risks does this supplier relationship create? |
| A.5.20 Supplier Agreements | What information-security requirements need to be established in the agreement? |
Example
Your startup wants to use a payroll SaaS provider.
A.5.19:
Assess the supplier’s security risk because it will process employee information.
A.5.20:
Ensure the relevant security, privacy, confidentiality, incident notification, and data-handling requirements are appropriately addressed in the agreement.
Simple Flow
Identify Supplier
↓
Assess Risk – A.5.19
↓
Define Security Requirements
↓
Document Requirements in Agreement – A.5.20
↓
Manage Supplier – A.5.22
What Does A.5.20 Require?
The organization should establish and agree appropriate information-security requirements with suppliers.
The requirements should consider factors such as:
- The type of information being shared
- The sensitivity of the information
- The supplier’s access
- The criticality of the service
- Applicable legal requirements
- Business requirements
- Security risks
- The nature of the supplier relationship
The requirements do not have to be identical for every supplier.
A cloud provider hosting production data may require substantially more detailed security requirements than a supplier providing office equipment.
What Should a Supplier Agreement Cover?
The exact requirements depend on the relationship, but relevant areas can include the following.
1. Information Security Responsibilities
The agreement should clearly identify applicable security responsibilities.
For example:
- What security controls does the supplier maintain?
- What security responsibilities remain with the customer?
- Who is responsible for incident handling?
- Who is responsible for protecting credentials?
Avoid unclear statements such as:
“Supplier shall maintain appropriate security.”
Where appropriate, define the relevant expectations more clearly.
2. Confidentiality
Supplier personnel may have access to confidential information.
The agreement may address:
- Confidential information
- Permitted use
- Disclosure restrictions
- Personnel confidentiality obligations
- Information handling
- Continuing confidentiality after termination
3. Data Protection
Where the supplier processes personal or sensitive information, the agreement may need to address:
- What data is processed
- Purpose of processing
- Permitted processing
- Data protection responsibilities
- Data location where relevant
- Data retention
- Data deletion
- Subprocessors
- Assistance with data-subject or regulatory requirements where applicable
Privacy and data-protection requirements should be addressed according to the applicable laws and the nature of the relationship.
4. Access Control
Where a supplier requires access to organizational systems, the agreement may establish requirements concerning:
- Authorized users
- Individual accounts
- MFA where appropriate
- Least privilege
- Privileged access
- Access reviews
- Access logging
- Access removal
Example:
Supplier personnel shall only receive access necessary to perform the contracted services.
5. Information Security Incident Notification
Supplier agreements should address how security incidents are communicated.
For example:
- What constitutes a security incident?
- Who should be notified?
- How should notification occur?
- What information should be provided?
- What cooperation is expected?
- What escalation process applies?
The exact notification timeframe should be appropriate to the organization’s risk and contractual/legal requirements.
6. Vulnerability and Security Management
For technology suppliers, the agreement may address expectations around:
- Vulnerability management
- Security testing
- Patch management
- Malware protection
- Secure configuration
- Secure development
- Penetration testing where appropriate
Not every requirement is relevant to every supplier.
7. Encryption
Where sensitive information is involved, the agreement may establish expectations regarding:
- Encryption in transit
- Encryption at rest
- Key management
- Cryptographic controls
The requirements should reflect the sensitivity and risk of the information.
8. Security Assurance
For higher-risk suppliers, the organization may require appropriate evidence of security.
Examples include:
- ISO 27001 certification
- SOC 2 report
- Independent assessment
- Security questionnaire
- Penetration-testing summary
- Other assurance reports
The agreement may also define how such evidence is provided and reviewed.
9. Audit and Assessment Rights
Depending on the relationship, the agreement may address the organization’s ability to obtain assurance about supplier security.
This might involve:
- Security questionnaires
- Audit reports
- Certifications
- Independent assessments
- Evidence requests
- On-site assessments where justified
For many SaaS providers, direct customer audits may not be practical.
In those situations, independent assurance reports or certifications may provide an alternative form of assurance.
10. Business Continuity
For critical suppliers, agreements may address:
- Business continuity
- Disaster recovery
- Backup
- Recovery objectives
- Service availability
- Testing
- Communication during major disruptions
This is particularly relevant where supplier failure could materially affect business operations.
11. Subcontractors and Subprocessors
A supplier may use other organizations to provide the service.
For example:
Your company
↓
SaaS provider
↓
Cloud infrastructure provider
The agreement may establish requirements around:
- Use of subcontractors
- Security responsibilities
- Subprocessor notification
- Approval or objection mechanisms where appropriate
- Flow-down of relevant security requirements
12. Data Return and Deletion
When the relationship ends, the organization should consider what happens to its information.
The agreement may define:
- Data return
- Data export
- Data deletion
- Backup retention
- Confirmation of deletion where appropriate
- Retention required by law
13. Security During Contract Termination
The agreement should consider:
- Access revocation
- Credential removal
- Asset return
- Data deletion
- Confidentiality obligations
- Subcontractor access
- Transition assistance where relevant
Activities Required to Implement A.5.20
Step 1: Identify Relevant Supplier Relationships
Start with the supplier inventory created under A.5.19.
Identify suppliers that:
- Process sensitive information
- Access systems
- Access customer data
- Host production infrastructure
- Provide critical services
- Handle personal information
Step 2: Determine Security Requirements
The organization should determine what requirements are appropriate for each supplier.
For example:
| Supplier | Risk | Important Requirements |
|---|---|---|
| AWS | Critical | Security, availability, incident handling, access, data protection |
| GitHub | High | Source-code security, access, authentication, incident handling |
| Payroll SaaS | High | Confidentiality, privacy, access, incident notification |
| Marketing SaaS | Medium | Data protection, access, confidentiality |
| Office Supplier | Low | Basic confidentiality where applicable |
Step 3: Use an Appropriate Agreement
Security requirements can be addressed through different contractual mechanisms, depending on the relationship.
Examples include:
- Master Service Agreement
- Supplier Agreement
- Statement of Work
- Information Security Addendum
- Data Processing Agreement
- Confidentiality Agreement/NDA
- Security Schedule
- Cloud service agreement
The important point is that relevant requirements are formally established and agreed.
Step 4: Review the Agreement Before Access Is Provided
A practical workflow can be:
Supplier selected
↓
Security risk assessed
↓
Security requirements identified
↓
Contract reviewed
↓
Security requirements agreed
↓
Contract approved
↓
Supplier receives access
This helps prevent a situation where a supplier receives sensitive access before security requirements are established.
Step 5: Obtain Evidence
Maintain evidence such as:
- Signed agreements
- Security addendums
- DPAs
- NDAs
- Supplier questionnaires
- Security certifications
- Supplier risk assessments
Step 6: Review Agreements When Requirements Change
Supplier agreements should be reviewed when there are significant changes, such as:
- New services
- New data types
- New system access
- Significant changes in supplier architecture
- New regulatory requirements
- Major security incidents
- New subprocessors
- Contract renewal
Startup Example
Imagine a startup using an external HR platform.
The platform processes:
- Employee names
- Contact information
- Salary information
- Bank/payment information
- Employment records
A.5.19
The startup identifies the HR platform as a high-risk supplier because it processes sensitive employee information.
A.5.20
The supplier agreement addresses relevant requirements such as:
- Confidentiality
- Data protection
- Access control
- Security safeguards
- Incident notification
- Subprocessor arrangements
- Data retention
- Data deletion
- Security assurance
Result
The startup has evidence that its expectations are not merely informal—they are part of the supplier relationship.
Example Supplier Security Requirements Matrix
A startup can maintain a matrix like this:
| Requirement | Low Risk | Medium Risk | High/Critical Risk |
|---|---|---|---|
| Confidentiality | ✓ | ✓ | ✓ |
| Security responsibilities | Where applicable | ✓ | ✓ |
| Data protection | Where applicable | ✓ | ✓ |
| Access control | Where applicable | ✓ | ✓ |
| Incident notification | Where applicable | ✓ | ✓ |
| Subprocessor controls | Where applicable | Where applicable | ✓ |
| Security assurance | Optional | Where appropriate | ✓ |
| Business continuity | Optional | Where appropriate | ✓ |
| Audit/assessment rights | Optional | Where appropriate | Where appropriate |
| Data deletion | Where applicable | ✓ | ✓ |
This allows the organization to apply risk-based contractual requirements rather than using one identical contract for every supplier.
Example Supplier Agreement Checklist
Before approving a high-risk supplier, ask:
Security
- Are security responsibilities defined?
- Are appropriate security controls identified?
- Are confidentiality requirements established?
Access
- Is supplier access restricted?
- Are privileged accounts controlled?
- Is MFA required where appropriate?
- Is access removed when no longer required?
Data
- What information will the supplier process?
- Is data protection addressed?
- Are retention and deletion requirements defined?
- Are subprocessors addressed?
Incidents
- Is security incident notification addressed?
- Are escalation responsibilities defined?
- Is cooperation during investigation addressed?
Assurance
- Can the supplier provide relevant security assurance?
- Are certifications or independent reports available?
- Are assessment rights appropriate to the risk?
Continuity
- Does the supplier support a critical business process?
- Are business continuity and recovery requirements addressed?
Termination
- What happens to company data?
- How is supplier access removed?
- How are credentials revoked?
- How is data returned or deleted?
Audit Evidence
An ISO 27001 auditor may request evidence such as:
Contractual Evidence
- Supplier agreements
- Master Service Agreements
- Information Security Addendums
- Security schedules
- Data Processing Agreements
- NDAs
Assessment Evidence
- Supplier risk assessments
- Security questionnaires
- Supplier due-diligence records
- SOC 2 reports
- ISO 27001 certificates
- Security assessment reports
Operational Evidence
- Contract review records
- Supplier approval records
- Security exceptions
- Supplier incident notifications
- Contract renewal reviews
Important Audit Principle
It is not enough to have a generic supplier contract.
The auditor may look for evidence that the security requirements are appropriate to the specific supplier relationship and risk.
ISO 27001 A.5.20 Audit Checklist
Before Contracting
- Are supplier security risks assessed?
- Are security requirements identified?
- Are sensitive data and system access considered?
- Are applicable legal and regulatory requirements considered?
Contract
- Are information-security responsibilities defined?
- Are confidentiality requirements addressed?
- Are access-control requirements addressed?
- Are data-protection requirements addressed?
- Are incident notification requirements addressed?
- Are subcontractors/subprocessors addressed?
- Are security-assurance requirements addressed where appropriate?
- Are data retention and deletion addressed?
- Are termination requirements addressed?
During the Relationship
- Are supplier security requirements monitored?
- Are significant changes reviewed?
- Are security incidents managed?
- Are contract requirements updated when necessary?
Evidence
- Can the organization produce signed agreements?
- Can it demonstrate security review?
- Can it demonstrate supplier approval?
- Can it demonstrate that high-risk suppliers have appropriate security requirements?
Common Mistakes
1. Using the Same Contract for Every Supplier
A generic agreement may not adequately address the risks of a supplier hosting production data.
2. Relying Only on an NDA
An NDA addresses confidentiality.
It does not necessarily address:
- Incident notification
- Access control
- Security testing
- Business continuity
- Data deletion
- Subprocessors
- Security assurance
Additional contractual requirements may be necessary depending on the relationship.
3. Signing the Contract Before Security Review
The business may sign the agreement and only later discover that important security requirements cannot be added.
Security requirements should be considered during supplier onboarding and contracting.
4. No Incident Notification Requirement
If a supplier suffers a breach, the customer needs an appropriate mechanism to learn about it and respond.
5. Ignoring Data Deletion
A supplier may retain organizational information after the relationship ends unless deletion and retention requirements are addressed.
6. Ignoring Subprocessors
A supplier may rely on additional organizations to deliver the service.
The contractual arrangement should address this where relevant.
7. Accepting Security Certifications Without Checking Scope
A supplier may provide an ISO 27001 certificate or SOC 2 report.
The organization should consider:
- Scope
- Applicable services
- Reporting period
- Coverage
- Relevance to the service being purchased
8. Making Security Requirements Impossible to Enforce
A contract may contain broad language such as:
“Supplier will maintain industry-standard security.”
For higher-risk relationships, more specific and measurable requirements may provide greater clarity.
Practical Startup Implementation Model
A startup can implement A.5.20 using this simple sequence:
1. Identify
What supplier are we engaging?
↓
2. Assess
What information and systems will they access?
↓
3. Define
What security requirements are necessary?
↓
4. Contract
Put the relevant requirements into the agreement.
↓
5. Approve
Obtain appropriate business/security/legal approval.
↓
6. Monitor
Review compliance and significant changes.
↓
7. Update
Update contractual requirements when the relationship or risk changes.
Simple Model
Assess → Define → Contract → Approve → Monitor → Update
Policy vs Process vs Evidence
| Component | Example |
|---|---|
| Policy | Relevant supplier security requirements shall be formally established |
| Standard | High-risk suppliers require defined security clauses |
| Procedure | Supplier security review |
| Procedure | Contract security review |
| Procedure | Supplier renewal review |
| Contract | Security addendum |
| Contract | Data Processing Agreement |
| Evidence | Signed supplier agreement |
| Evidence | Supplier risk assessment |
| Evidence | Security questionnaire |
| Evidence | Security certification/report |
| Evidence | Contract review record |
The audit trail should demonstrate:
Supplier Risk → Security Requirements → Agreement → Approval → Operation → Review
Relationship With Other ISO 27001 Controls
| Control | Relationship |
|---|---|
| A.5.19 Information Security in Supplier Relationships | Identifies and manages information-security risks associated with suppliers |
| A.5.20 Supplier Agreements | Ensures relevant security requirements are established in supplier agreements |
| A.5.21 ICT Supply Chain | Addresses security risks within the broader ICT supply chain |
| A.5.22 Monitoring, Review and Change Management of Supplier Services | Addresses ongoing supplier monitoring and changes |
| A.5.23 Information Security for Use of Cloud Services | Addresses security considerations specific to cloud services |
| A.5.15 Access Control | Supports restriction of supplier access |
| A.5.18 Access Rights | Supports granting, reviewing, modifying, and removing supplier access |
| A.5.31 Legal, Statutory, Regulatory and Contractual Requirements | Helps identify applicable contractual and legal requirements |
| A.5.34 Privacy and Protection of PII | Relevant where suppliers process personally identifiable information |
Useful Documents for A.5.20
- Supplier Security Requirements Template
[Insert Draft Document Link] - Supplier Security Addendum
[Insert Draft Document Link] - Supplier Contract Security Checklist
[Insert Draft Document Link] - Supplier Risk Assessment
[Insert Draft Document Link] - Data Processing Agreement Checklist
[Insert Draft Document Link] - Supplier Due Diligence Questionnaire
[Insert Draft Document Link] - Supplier Contract Review Checklist
[Insert Draft Document Link] - Supplier Offboarding Checklist
[Insert Draft Document Link]
Final Takeaway
ISO 27001 Annex A 5.20 turns supplier-security expectations into formal, agreed requirements.
A.5.19 asks:
What security risks does this supplier relationship create?
A.5.20 follows with:
What security requirements should we establish with the supplier to address those risks?
For a startup, the practical approach is not to create complicated contracts for every vendor.
Instead:
Assess the supplier → Identify relevant security requirements → Put them into the appropriate agreement → Obtain approval → Monitor compliance → Update when circumstances change.
The goal is simple:
Don’t assume a supplier understands your security expectations. Define the expectations clearly, agree them contractually where appropriate, and maintain evidence that they are addressed.