Auditing ISO 27001 Annex A 5.21 Managing Information Security in the ICT Supply Chain involves the continuous verification of third-party service delivery and security integrity. This process validates the Primary Implementation Requirement of monitoring supplier performance, security obligations, and sub-tier risks against agreed service levels. The Business Benefit ensures supply chain resilience by identifying vulnerabilities early and enforcing contractual security standards to prevent disruptions.
This technical verification tool is designed for lead auditors to establish the ongoing integrity of third-party service delivery. Use this checklist to validate compliance with ISO 27001 Annex A 5.21 (Managing information security in the ICT supply chain) by ensuring that supplier performance and security obligations are systematically monitored and reviewed.
1. Supplier Service Level Monitoring Records Verified
Verification Criteria: Management maintains a continuous process to monitor supplier service delivery and security performance against agreed-upon contract requirements.
Required Evidence: Monthly or quarterly service performance reports, uptime logs, and security KPI dashboards provided by the supplier.
Pass/Fail Test: If the organisation cannot produce evidence of service performance reviews conducted within the last 6 months for critical suppliers, mark as Non-Compliant.
2. Supplier Security Audit Execution Confirmed
Verification Criteria: The organisation exercises its right to audit or reviews independent third-party audit reports for high-risk ICT suppliers.
Required Evidence: Signed supplier audit reports, SOC2 Type II reviews, or ISO 27001 certification validation records (including scope verification).
Pass/Fail Test: If a critical ICT supplier has not provided an updated audit report or certificate within the last 12 months, and no internal audit was performed, mark as Non-Compliant.
3. Supplier Incident Notification Adherence Validated
Verification Criteria: Records demonstrate that the supplier notifies the organisation of security incidents within the contractually mandated timeframes.
Required Evidence: Incident logs or email archives showing timestamped notifications from the supplier regarding security events or breaches.
Pass/Fail Test: If a known supplier-side breach occurred but no formal notification was received by the organisation’s security lead, mark as Non-Compliant.
4. Supplier Vulnerability Management Tracking Verified
Verification Criteria: The organisation monitors the supplier’s response to identified vulnerabilities in the provided ICT services or products.
Required Evidence: Vulnerability disclosure logs, patch management reports from the supplier, or tickets showing the organisation tracking supplier remediation status.
Pass/Fail Test: If critical vulnerabilities in a supplier’s platform remained unpatched beyond the agreed SLA without a documented risk waiver, mark as Non-Compliant.
5. Supplier Change Management Oversight Confirmed
Verification Criteria: Any significant changes to the supplier’s services, technical architecture, or security controls are reviewed for impact on the organisation’s security posture.
Required Evidence: Change notification records from the supplier and corresponding internal impact assessment notes or approval logs.
Pass/Fail Test: If a supplier made a significant architectural change (e.g., data residency migration) without formal notification or internal impact review, mark as Non-Compliant.
6. Supplier Risk Profile Update Consistency Validated
Verification Criteria: The risk profile for each critical supplier is periodically updated based on performance, security posture changes, or new threat intelligence.
Required Evidence: Updated Supplier Risk Register or vendor risk management platform history showing re-assessment scores.
Pass/Fail Test: If the supplier’s risk score has not been reviewed following a major security incident or change in service scope, mark as Non-Compliant.
7. Supply Chain Transparency and 4th-Party Oversight Verified
Verification Criteria: The organisation monitors the supplier’s management of their own sub-contractors (4th parties) that have access to the organisation’s data.
Required Evidence: Sub-processor lists provided by the supplier and evidence of the organisation’s review of these sub-processors’ security credentials.
Pass/Fail Test: If the supplier added a new sub-processor with access to sensitive data without the organisation’s knowledge or consent, mark as Non-Compliant.
8. Supplier Security Performance Remediation Records Present
Verification Criteria: Remediation actions are formally tracked when a supplier fails to meet security requirements or audit criteria.
Required Evidence: Corrective Action Plans (CAPs) or Service Improvement Plans (SIPs) issued to the supplier with evidence of follow-up on completion.
Pass/Fail Test: If a supplier failed an audit or missed a security KPI and no documented corrective action plan was initiated, mark as Non-Compliant.
9. Business Continuity and Disaster Recovery Readiness Validated
Verification Criteria: The organisation verifies the supplier’s capability to maintain security and availability during a disruptive event through testing or evidence of successful drills.
Required Evidence: Supplier BC/DR test summaries or attestation letters confirming successful testing within the current audit cycle.
Pass/Fail Test: If a critical supplier cannot provide evidence of a successful disaster recovery test within the last 12 months, mark as Non-Compliant.
10. Supplier Termination and Offboarding Logs Verified
Verification Criteria: Upon contract termination, a formalised process ensures the revocation of all access and the secure return or destruction of data.
Required Evidence: Offboarding checklists, account revocation logs, and Certificates of Destruction for terminated supplier contracts.
Pass/Fail Test: If a terminated ICT supplier retains active logical access (VPN/SSO) or physical hardware 48 hours after contract end, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Service Monitoring | GRC tool marks “Complete” because a PDF named “SLA” was uploaded. | An auditor must demand the *actual* performance metrics (uptime/logs) for the current month, not the contract itself. |
| Audit Reviews | Tool records that an ISO 27001 certificate is “On File”. | Verify the *Statement of Applicability* (SoA) of the vendor’s certificate. Does it actually cover the specific service you use? |
| Incident Notification | Platform assumes the vendor will notify them because “it’s in the contract”. | Check for the *technical* integration. Do you have a shared Slack channel or a direct API for incident webhooks? |
| Change Management | GRC tool identifies that the vendor’s website hasn’t changed. | Examine “Product Update” emails from the vendor. Where is the internal record of a security team reviewing these changes? |
| Sub-processor Risk | Tool identifies the vendor uses “AWS” and marks it safe. | Verify the *Data Residency*. Even if they use AWS, has the vendor moved your data from a UK region to a US region without notice? |
| Remediation Tracking | Platform marks “Follow-up” as done once an email is sent. | Demand evidence of the *fix*. An email asking for a patch is not evidence that the supplier actually applied the patch. |
| Offboarding Integrity | Tool logs the vendor as “Inactive” in the GRC database. | Manually check the IAM console for “Orphaned Accounts”. GRC tools often miss accounts created outside of SSO. |
About the author
