What is ISO 27001 Annex A 5.19 – Information Security in Supplier Relationships?
ISO 27001 Annex A 5.19 focuses on managing information-security risks associated with the organization’s relationships with suppliers.
Almost every modern organization depends on suppliers.
A startup may use:
- AWS or Microsoft Azure
- Google Workspace
- GitHub
- Salesforce
- Payroll providers
- HR platforms
- Payment providers
- IT support companies
- Managed security providers
- Consultants
- Software development companies
- Cloud service providers
- Data processors
- Audit and certification providers
Some of these suppliers may have access to the organization’s:
- Confidential information
- Customer information
- Personal data
- Source code
- Systems
- Infrastructure
- Credentials
- Business processes
A.5.19 requires the organization to consider and manage the information-security risks arising from those supplier relationships.
Simple Explanation
If a supplier can access your information or systems, their security can affect your security.
Why is A.5.19 Important?
An organization can have strong internal security and still be exposed through a third party.
For example:
A SaaS company uses an outsourced IT provider.
The provider has administrator access to the company’s Google Workspace and laptops.
The provider’s employee account is compromised.
The attacker uses that access to reach the startup’s environment.
The security problem originated outside the organization but affected the organization.
Supplier-related risks can include:
- Unauthorized access
- Data leakage
- Poor security practices
- Weak authentication
- Inadequate vulnerability management
- Poor incident response
- Subcontractor risks
- Data-processing risks
- Insecure cloud configurations
- Service outages
- Loss of availability
- Inadequate backup
- Supplier employee access
- Regulatory or contractual non-compliance
Simple Principle
You cannot outsource responsibility for protecting your information simply because you outsource the service.
What Does A.5.19 Require?
The organization should establish processes and criteria for managing information-security risks associated with suppliers.
This should be appropriate to:
- The type of supplier
- The information involved
- The access provided
- The criticality of the service
- The potential business impact
- Applicable legal and regulatory requirements
- The organization’s risk appetite
Not every supplier needs the same level of assessment.
For example:
A supplier providing office stationery does not normally require the same security assessment as a cloud provider hosting customer production data.
What is a Supplier?
For A.5.19 purposes, a supplier can include organizations or individuals providing products or services that may introduce information-security risk.
Examples include:
Technology Suppliers
- Cloud providers
- SaaS providers
- Hosting companies
- Software vendors
- Hardware vendors
- Database providers
- Backup providers
Professional Service Providers
- IT consultants
- Cybersecurity consultants
- Auditors
- Legal firms
- Accounting firms
- HR consultants
Outsourced Service Providers
- Managed service providers
- Managed security service providers
- Outsourced development teams
- Customer-support providers
- Data-processing providers
Other Third Parties
- Contractors
- Temporary service providers
- Maintenance providers
- Facilities providers with system/data access
Supplier vs Third Party
The terms are sometimes used interchangeably, but organizations should define their terminology clearly.
A supplier generally provides a product or service to the organization.
A third party is a broader term that may include:
- Suppliers
- Customers
- Partners
- Regulators
- External organizations
For A.5.19, the focus is specifically on supplier relationships and their information-security risks.
Supplier Risk Depends on Access and Criticality
A useful startup approach is to classify suppliers according to risk.
| Supplier | Access/Data | Potential Risk | Example |
|---|---|---|---|
| Low | No sensitive information | Low | Office stationery |
| Medium | Business information | Medium | Marketing SaaS |
| High | Sensitive information | High | HR platform |
| Critical | Production/customer data or infrastructure | Critical | Cloud provider |
This allows security effort to be proportional.
Activities Required to Implement A.5.19
Step 1: Identify Suppliers
Create a supplier inventory.
For example:
| Supplier | Service | Data/System | Criticality | Security Review |
|---|---|---|---|---|
| AWS | Cloud | Production systems | Critical | Yes |
| Google Workspace | Collaboration | Corporate information | High | Yes |
| GitHub | Source control | Source code | High | Yes |
| Payroll Provider | Payroll | Employee information | High | Yes |
| Office Supplier | Stationery | None | Low | Basic |
Start with suppliers that have access to:
- Customer data
- Personal data
- Financial data
- Source code
- Production infrastructure
- Confidential information
- Security-sensitive systems
Step 2: Classify Supplier Risk
Create a simple supplier-risk methodology.
Low Risk
Supplier:
- Does not access sensitive information
- Does not connect to internal systems
- Has limited business impact
Medium Risk
Supplier:
- Processes business information
- Provides important SaaS
- Has limited system access
High Risk
Supplier:
- Processes sensitive information
- Has privileged access
- Connects to production systems
- Processes customer data
Critical Risk
Supplier:
- Hosts core production infrastructure
- Processes highly sensitive information
- Supports critical business operations
- Could cause significant business disruption if compromised
Step 3: Perform Supplier Security Due Diligence
The level of assessment should match the supplier’s risk.
Possible assessment methods include:
- Security questionnaire
- SOC 2 report
- ISO 27001 certificate
- Penetration-testing summary
- Security policies
- Data protection documentation
- Business continuity information
- Incident response information
- Vulnerability-management information
- Privacy documentation
You do not necessarily need to perform a full audit of every supplier.
Step 4: Define Security Requirements
The organization should determine what security requirements suppliers need to meet.
Depending on the supplier, these may include:
- Confidentiality
- Access control
- MFA
- Encryption
- Data protection
- Vulnerability management
- Incident notification
- Business continuity
- Backup
- Secure development
- Logging
- Data deletion
- Subcontractor controls
The requirements should be proportionate to risk.
Step 5: Include Security Requirements in Contracts
Important security requirements should be addressed through appropriate contractual arrangements.
Depending on the relationship, contracts may address:
- Confidentiality
- Information-security requirements
- Data protection
- Access restrictions
- Security incident notification
- Breach notification
- Audit or assessment rights
- Data location
- Subcontracting
- Data retention
- Data deletion
- Business continuity
- Termination requirements
A supplier should not simply be told:
“Please maintain good security.”
The important requirements should be sufficiently clear and enforceable through the relevant contractual arrangements.
Step 6: Protect Supplier Access
If a supplier requires access to internal systems, control that access.
For example:
Supplier → Approved account → MFA → Limited permissions → Logging → Periodic review
Avoid giving suppliers unnecessary administrator privileges.
Supplier access should be:
- Individual where practical
- Authorized
- Limited
- Monitored
- Reviewed
- Removed when no longer required
Step 7: Manage Subcontractors
A supplier may itself use other suppliers.
For example:
Your company
↓
Cloud SaaS provider
↓
Hosting provider
↓
Subprocessor
This can introduce additional risks.
The organization should understand relevant subcontracting arrangements where they materially affect information-security risk.
Step 8: Monitor Supplier Security
Supplier security should not be assessed only during onboarding.
Depending on risk, the organization may periodically review:
- Security certifications
- SOC reports
- Security questionnaires
- Major incidents
- Changes in service
- Changes in ownership
- Subprocessors
- Security performance
- Contract compliance
- Business continuity
Step 9: Manage Supplier Security Incidents
The organization should know what happens if a supplier experiences a security incident.
For example:
Supplier reports incident
↓
Supplier investigates
↓
Organization assesses impact
↓
Security/legal/privacy teams notified as appropriate
↓
Customer/regulatory notification considered where required
↓
Corrective action
↓
Supplier risk reassessment
Step 10: Manage Supplier Termination
When a supplier relationship ends, consider:
- Access removal
- Credential revocation
- Data return
- Data deletion
- Asset return
- Account closure
- Contractual obligations
- Confidentiality obligations
- Subcontractor access
The objective is to prevent former suppliers from retaining unnecessary access to organizational information or systems.
Startup Example
Imagine a 40-person SaaS startup.
The company uses:
- AWS
- GitHub
- Google Workspace
- Salesforce
- Payroll SaaS
- External IT support company
The startup performs a simple risk classification.
AWS
Risk: Critical
Reason:
Hosts production infrastructure and customer data.
Security review:
- SOC 2 documentation
- ISO 27001 information
- Security documentation
- Business continuity information
- Contractual requirements
GitHub
Risk: High
Reason:
Contains source code and potentially security-sensitive information.
Security review:
- Security documentation
- MFA/SSO capabilities
- Access controls
- Incident-management information
Payroll Provider
Risk: High
Reason:
Processes employee personal and financial information.
Security review:
- Data protection controls
- Security documentation
- Access controls
- Incident notification
- Data retention/deletion
Office Stationery Supplier
Risk: Low
No access to company systems or sensitive information.
A full security questionnaire would generally not be proportionate.
This demonstrates an important principle:
Supplier security management should be risk-based, not paperwork-based.
Supplier Security Assessment
A supplier questionnaire can include questions such as:
Governance
- Do you have an information-security policy?
- Is security responsibility formally assigned?
- Do you conduct security risk assessments?
Access Control
- Do you use individual user accounts?
- Is MFA available?
- Is privileged access controlled?
- Are access rights periodically reviewed?
Data Protection
- What types of customer data do you process?
- Where is data stored?
- Is data encrypted?
- How is data deleted?
Vulnerability Management
- Do you conduct vulnerability assessments?
- Do you perform penetration testing?
- How are vulnerabilities remediated?
Incident Management
- Do you have an incident-response process?
- How quickly are customers notified of security incidents?
- Is there a defined escalation process?
Business Continuity
- Do you maintain backups?
- Do you test business-continuity arrangements?
- What happens if your service becomes unavailable?
Supplier Risk Register
A practical supplier register can look like:
| Supplier | Service | Data/Access | Risk | Owner | Assessment | Contract | Review Date |
|---|---|---|---|---|---|---|---|
| AWS | Cloud | Production/customer data | Critical | CTO | Completed | Yes | 2027 |
| GitHub | Source control | Source code | High | CTO | Completed | Yes | 2027 |
| Payroll SaaS | Payroll | Employee data | High | HR | Completed | Yes | 2027 |
| Marketing SaaS | Marketing | Business data | Medium | Marketing | Completed | Yes | 2027 |
| Office Supplier | Stationery | None | Low | Admin | Basic | Yes | 2027 |
Supplier Security Requirements Matrix
The organization can define minimum requirements based on risk.
| Requirement | Low | Medium | High/Critical |
|---|---|---|---|
| Confidentiality agreement | ✓ | ✓ | ✓ |
| Security questionnaire | Optional | ✓ | ✓ |
| Security certification/report | Optional | Where appropriate | Expected where appropriate |
| MFA | Where applicable | ✓ | ✓ |
| Incident notification | ✓ | ✓ | ✓ |
| Data protection requirements | Where applicable | ✓ | ✓ |
| Business continuity review | Optional | ✓ | ✓ |
| Subprocessor review | Optional | Where applicable | ✓ |
| Periodic reassessment | Risk-based | ✓ | ✓ |
The exact requirements should be determined by the organization’s risk assessment and contractual needs.
Audit Evidence
An auditor may ask for evidence that supplier risks are actually managed.
Governance Evidence
- Supplier Security Policy
- Third-Party Risk Management Policy
- Procurement Policy
- Information Security Policy
Supplier Inventory
- Supplier register
- Critical supplier register
- Supplier risk classifications
Due Diligence Evidence
- Security questionnaires
- SOC 2 reports
- ISO 27001 certificates
- Security assessments
- Penetration-testing evidence where relevant
- Privacy assessments
Contractual Evidence
- Supplier agreements
- NDAs
- Data Processing Agreements
- Security addendums
- Incident notification clauses
- Confidentiality clauses
Monitoring Evidence
- Supplier reassessment records
- Security certification reviews
- Supplier performance reviews
- Incident records
- Subprocessor reviews
Access Evidence
- Supplier user accounts
- Access approvals
- MFA configuration
- Access reviews
- Access removal records
ISO 27001 A.5.19 Audit Checklist
Supplier Identification
- Has the organization identified relevant suppliers?
- Are suppliers classified according to risk?
- Are critical suppliers identified?
- Are suppliers with access to sensitive information identified?
Due Diligence
- Is supplier security assessed before onboarding where appropriate?
- Is the assessment proportional to supplier risk?
- Are security certifications/reports reviewed where appropriate?
- Are security weaknesses documented?
Contracts
- Are relevant security requirements included in supplier agreements?
- Are confidentiality obligations addressed?
- Are incident notification requirements addressed?
- Are data-protection requirements addressed?
- Are subcontractors addressed where relevant?
Supplier Access
- Is supplier access authorized?
- Is access limited to business requirements?
- Is MFA used where appropriate?
- Is supplier access periodically reviewed?
- Is access removed when no longer required?
Monitoring
- Are critical suppliers periodically reassessed?
- Are security incidents monitored?
- Are significant changes to suppliers evaluated?
- Are supplier security risks tracked?
Termination
- Is supplier access removed?
- Is company data returned or deleted where required?
- Are credentials revoked?
- Are contractual termination requirements addressed?
Common Mistakes
1. Treating Every Supplier the Same
A cloud provider hosting customer data and an office stationery supplier do not present the same information-security risk.
A risk-based approach is more practical.
2. Collecting Certificates Without Reviewing Them
Having an ISO 27001 certificate or SOC 2 report does not automatically mean every relevant risk is addressed.
The organization should consider:
- Scope
- Date
- Coverage
- Relevant services
- Exceptions/findings where applicable
3. No Supplier Inventory
Companies sometimes have dozens of SaaS applications but no central record of them.
This makes third-party risk difficult to manage.
4. Security Is Not Included in Contracts
The procurement team signs a contract without addressing:
- Security requirements
- Incident notification
- Data protection
- Access
- Data deletion
Security requirements should be considered before the relationship is finalized.
5. Supplier Access Never Gets Removed
A consultant finishes a project but still has:
- VPN access
- GitHub access
- Cloud access
- Email access
Supplier access should have a defined lifecycle.
6. Ignoring Subprocessors
A supplier may depend on other organizations to deliver its service.
Material subcontracting or subprocessing arrangements should be considered based on risk and contractual requirements.
7. No Ongoing Monitoring
Supplier security should not be a one-time questionnaire.
Critical suppliers may need periodic reassessment.
8. Overengineering Supplier Assessments
A 10-person startup does not need a 100-question security questionnaire for every SaaS application.
Focus effort on suppliers that can materially affect:
- Confidentiality
- Integrity
- Availability
- Privacy
- Regulatory compliance
Practical Startup Implementation Model
A startup can implement A.5.19 using seven simple steps:
1. Identify
Who are our important suppliers?
↓
2. Classify
What information or systems can they access?
↓
3. Assess
What security risks do they introduce?
↓
4. Contract
What security requirements must they meet?
↓
5. Control
How is supplier access restricted?
↓
6. Monitor
Are supplier risks still acceptable?
↓
7. Exit
What happens when the relationship ends?
Simple Model
Identify → Classify → Assess → Contract → Control → Monitor → Exit
Policy vs Process vs Evidence
| Component | Example |
|---|---|
| Policy | Supplier relationships shall be managed according to information-security risk |
| Standard | High-risk suppliers require security due diligence |
| Procedure | Supplier onboarding process |
| Procedure | Supplier security assessment |
| Procedure | Supplier access management |
| Procedure | Supplier termination |
| Technical Control | MFA for supplier accounts |
| Evidence | Supplier risk assessment |
| Evidence | Security questionnaire |
| Evidence | SOC 2/ISO 27001 documentation |
| Evidence | Supplier contract |
| Evidence | Access review |
| Evidence | Supplier reassessment |
The audit trail should demonstrate:
Supplier → Risk → Assessment → Security Requirements → Contract → Monitoring → Exit
Relationship With Other ISO 27001 Controls
| Control | Relationship |
|---|---|
| A.5.19 Information Security in Supplier Relationships | Manages information-security risks associated with supplier relationships |
| A.5.20 Addressing Information Security Within Supplier Agreements | Establishes specific information-security requirements within supplier agreements |
| A.5.21 Managing Information Security in the ICT Supply Chain | Addresses information-security risks within the ICT supply chain |
| A.5.22 Monitoring, Review and Change Management of Supplier Services | Addresses ongoing monitoring and changes to supplier services |
| A.5.23 Information Security for Use of Cloud Services | Provides specific considerations for acquiring, using, managing, and exiting cloud services |
| A.5.15 Access Control | Supports control of supplier access to information and systems |
| A.5.18 Access Rights | Supports provisioning, reviewing, modifying, and removing supplier access |
| A.5.24 Information Security Incident Management Planning and Preparation | Supports incident-management arrangements involving suppliers |
| A.5.30 ICT Readiness for Business Continuity | Relevant when supplier availability affects business continuity |
Useful Documents for A.5.19
- Supplier Security Management Policy
[Insert Draft Document Link] - Supplier Risk Assessment Template
[Insert Draft Document Link] - Supplier Security Questionnaire
[Insert Draft Document Link] - Supplier Register
[Insert Draft Document Link] - Critical Supplier Register
[Insert Draft Document Link] - Third-Party Due Diligence Checklist
[Insert Draft Document Link] - Supplier Security Review Template
[Insert Draft Document Link] - Supplier Onboarding Checklist
[Insert Draft Document Link] - Supplier Offboarding Checklist
[Insert Draft Document Link]
Final Takeaway
ISO 27001 Annex A 5.19 is about understanding and managing the information-security risks created by supplier relationships.
A supplier should not automatically be trusted simply because the organization has signed a contract.
The organization should understand:
- Who the supplier is
- What service they provide
- What information they can access
- What systems they can access
- What security risks they introduce
- What security requirements apply
- How their security is assessed
- How their access is controlled
- How their security is monitored
- What happens when the relationship ends
The practical model is:
Identify → Classify → Assess → Contract → Control → Monitor → Exit
The goal is not to create paperwork for every supplier.
The goal is to ensure that the level of supplier-security oversight is appropriate to the risk the supplier introduces to the organization.