Auditing ISO 27001 Annex A 5.19 Information Security in Supplier Relationships is the critical verification of third-party risk management. This process validates the Primary Implementation Requirement of embedding security clauses into contracts and rigorously monitoring supplier performance. The Business Benefit shields the organization from supply chain attacks, ensuring that vendors maintain the same high security standards as the hiring entity.
This technical verification tool is designed for lead auditors to confirm the integrity of information security within supplier relationships. Use this checklist to validate compliance with ISO 27001 Annex A 5.19 (Information security in supplier relationships) by ensuring that risks are mitigated through formalised agreements and technical requirements.
1. Supplier Information Security Policy Formalisation Verified
Verification Criteria: A documented policy exists defining the security requirements for mitigating risks associated with supplier access to organisational assets.
Required Evidence: Approved Supplier Security Policy or integrated Procurement Policy with specific security clauses.
Pass/Fail Test: If the organisation lacks a formal policy defining the security criteria for selecting and managing suppliers, mark as Non-Compliant.
2. Supplier Risk Categorisation and Assessment Validated
Verification Criteria: All suppliers with access to sensitive data are categorised by risk level and have undergone a formal security impact assessment.
Required Evidence: Supplier Risk Register or completed Security Due Diligence Questionnaires (DDQs) for a sample of high-risk vendors.
Pass/Fail Test: If a critical SaaS vendor or managed service provider has been onboarded without a documented risk assessment, mark as Non-Compliant.
3. Security Clauses in Legal Agreements Confirmed
Verification Criteria: Contracts and Service Level Agreements (SLAs) include specific information security requirements, including right-to-audit and breach notification obligations.
Required Evidence: Signed Master Service Agreements (MSAs) or Data Processing Agreements (DPAs) containing mandatory security annexes.
Pass/Fail Test: If a supplier contract lacks a “Right to Audit” clause or a defined timeframe for security incident reporting, mark as Non-Compliant.
4. Supplier Access Principle of Least Privilege Verified
Verification Criteria: Supplier access to organisational systems is restricted to the minimum necessary assets required to perform their contracted service.
Required Evidence: Identity and Access Management (IAM) logs or Firewall rules showing restricted “Guest” or “VPN” access for specific vendor accounts.
Pass/Fail Test: If a third-party contractor is found to have broad “Domain Admin” or unrestricted network access by default, mark as Non-Compliant.
5. Supply Chain Integrity and Sub-contractor Controls Validated
Verification Criteria: Agreements require suppliers to flow down information security requirements to their own sub-contractors (the “n-th” party risk).
Required Evidence: Flow-down clauses within the sampled supplier contracts or evidence of “Sub-processor” lists in the DPA.
Pass/Fail Test: If the supplier agreement does not prohibit or regulate the use of unvetted sub-contractors for processing sensitive data, mark as Non-Compliant.
6. Supplier Incident Response Integration Confirmed
Verification Criteria: The organisation’s incident management procedure includes clear instructions for coordinating with suppliers during a security event.
Required Evidence: Incident Response Plan (IRP) showing a “Third-Party Escalation” path and contact details for critical supplier SOC teams.
Pass/Fail Test: If an incident involving a supplier occurred but no joint post-incident review or communication log exists, mark as Non-Compliant.
7. Secure Information Transfer Methods to Suppliers Verified
Verification Criteria: Technical controls are in place to ensure that data shared with suppliers is protected during transit and at rest.
Required Evidence: Managed File Transfer (MFT) logs, enforced TLS settings for vendor portals, or evidence of PGP/AES encryption for manual exports.
Pass/Fail Test: If sensitive information is transferred to a vendor via unencrypted standard email, mark as Non-Compliant.
8. Supplier Performance Monitoring and Audit Execution Evidenced
Verification Criteria: The organisation periodically monitors, reviews, and audits supplier security performance against the agreed contract terms.
Required Evidence: Annual supplier audit reports, SOC2 Type II report reviews, or “Supplier Scorecards” identifying security non-conformities.
Pass/Fail Test: If the organisation has not reviewed a critical supplier’s security credentials (e.g. ISO 27001 certificate or SOC2) within the last 12 months, mark as Non-Compliant.
9. Termination of Supplier Access Records Present
Verification Criteria: A formal process ensures that all logical and physical access is revoked, and assets are returned or destroyed upon termination of the supplier relationship.
Required Evidence: Offboarding checklists or account deletion logs corresponding to a recently terminated vendor contract.
Pass/Fail Test: If a terminated vendor still possesses active VPN credentials or unreturned physical hardware, mark as Non-Compliant.
10. Protection of Shared Technical Assets Verified
Verification Criteria: Security requirements are defined and implemented for the use of any technical assets (software, hardware, or cloud instances) shared between the organisation and the supplier.
Required Evidence: Hardening standards for “Jump Boxes” or shared VPCs used by vendor support teams.
Pass/Fail Test: If a shared support environment lacks multi-factor authentication (MFA) or session recording, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Supplier Assessment | GRC tool shows a “Green Tick” because a vendor uploaded an expired ISO certificate. | Verify the *scope* of the certificate; an ISO 27001 for a vendor’s “Head Office” is irrelevant if their “Dev Center” isn’t covered. |
| Contractual Compliance | Tool records that an “NDA” is signed and marks the step as complete. | An NDA is not a security annex. Verify specific technical requirements like MFA enforcement and data residency are in the contract. |
| Supply Chain Risk | GRC platform checks if the “Direct Supplier” has been reviewed. | Demand evidence of where the supplier hosts *your* data. If they use a sub-processor (e.g. AWS), verify the supplier’s oversight of that host. |
| Monitoring & Review | Automated GRC emails sent to vendors are counted as “Monitoring”. | Verify qualitative feedback. If a vendor answers “No” to a security question, show the internal ticket where that risk was treated or accepted. |
| Access Management | Tool assumes vendor access is managed by the “Vendor Management Office”. | Manually inspect the IAM console for “Orphaned Accounts” belonging to individual contractors from a vendor no longer in use. |
| Incident Reporting | Platform stores a generic “Incident Policy” that mentions suppliers. | Check for *contact names*. A policy is useless if it doesn’t contain a 24/7 phone number for the supplier’s emergency security lead. |
| Decommissioning | Tool logs the contract as “Expired” in the GRC database. | Demand a “Certificate of Destruction” for data held by the supplier once the contract expired. |
About the author
