Implementing ISO 27001 Annex A 5.22 is the governance process of verifying that third-party vendors adhere to security obligations. The primary implementation requirement involves manual log audits and formal quarterly reviews, which provides the business benefit of continuous risk oversight and technical assurance across the supply chain ecosystem.
ISO 27001 Annex A 5.22 Monitoring, Review and Change Management of Supplier Services Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 5.22. Effective governance happens through rigorous manual inspection of logs and physical performance reviews, not via automated ‘health check’ icons in a GRC dashboard.
1. Establish a Manual Supplier Performance Log
Control Requirement: Regularly monitor supplier service performance against the security requirements in the agreement.
Required Implementation Step: Create a local spreadsheet or database to track monthly performance. Manually input data from supplier service reports, focusing on actual downtime and security incident response times rather than marketing-led uptime percentages.
Minimum Requirement: A 12-month trailing log of service levels for every critical ICT supplier.
2. Conduct Scheduled Quarterly Service Reviews
Control Requirement: Review supplier service reports and conduct regular meetings to address security performance.
Required Implementation Step: Schedule and hold a formal meeting with the supplier’s account manager. Document the minutes, specifically noting any security deviations, and ensure these are signed off by your internal Technical Lead to prove oversight.
Minimum Requirement: Minutes from at least four quarterly reviews per year for ‘High Risk’ suppliers.
3. Verify Supplier Independent Audit Reports (Manual Validation)
Control Requirement: Review supplier audit reports and security assessments to ensure compliance with security obligations.
Required Implementation Step: Do not just collect a SOC2 or ISO 27001 certificate. Open the full report, read the ‘Observations’ or ‘Exceptions’ section, and manually verify how the supplier addressed those specific failures in relation to your data.
Minimum Requirement: A stored PDF of the supplier’s latest full audit report with internal notes on identified exceptions.
4. Implement a Formal Supplier Change Request Procedure
Control Requirement: Changes to the provision of supplier services must be managed, taking account of the criticality of business information.
Required Implementation Step: Require all suppliers to submit a formal Change Request (CR) document before modifying any system architecture or data handling process. Manually review the security impact of the change before granting written authorisation.
Minimum Requirement: A documented history of approved and rejected change requests for critical supplier systems.
5. Perform Regular Vulnerability Scans on Supplier Interfaces
Control Requirement: Monitor supplier services to identify and manage security vulnerabilities.
Required Implementation Step: Use your own internal scanning tools (e.g., Nessus or OpenVAS) to probe the public-facing interfaces provided by the supplier. Do not rely on their ‘self-certification’—manually verify that their endpoints are hardened to your standards.
Minimum Requirement: Quarterly vulnerability scan reports showing zero ‘High’ or ‘Critical’ risks on supplier-managed gateways.
6. Review Supplier Business Continuity (BCP) Test Results
Control Requirement: Monitor and review changes to supplier business continuity and disaster recovery plans.
Required Implementation Step: Demand a copy of the supplier’s latest BCP test ‘After Action Report’. Manually verify that the recovery time objectives (RTO) achieved during their test align with the requirements in your contract.
Minimum Requirement: Evidence of a reviewed BCP test result from the supplier within the last 14 months.
7. Audit Supplier Access Logs and Identity Management
Control Requirement: Monitor supplier access to organisational information and assets.
Required Implementation Step: Manually extract and review the logs of supplier account activity within your systems every month. Cross-reference these logs against your internal ‘Authorised Access List’ to ensure no retired supplier personnel still have active credentials.
Minimum Requirement: A signed-off monthly log review showing that supplier access remains necessary and appropriate.
8. Update the Supplier Risk Assessment Post-Change
Control Requirement: Re-evaluate supplier risk following significant changes to the service or the supplier’s environment.
Required Implementation Step: Whenever a supplier changes their data centre location, sub-processor, or core software stack, manually re-run your internal Risk Assessment. Document the new risk score and update your treatment plan accordingly.
Minimum Requirement: Updated risk assessment documentation following any major supplier service modification.
9. Enforce Manual Notification of Supplier Infrastructure Changes
Control Requirement: Ensure the supplier notifies the organisation of changes to their service that could affect information security.
Required Implementation Step: Insert a clause in your operational handbook requiring the supplier to provide a 30-day notice period for infrastructure changes. Manually check your ‘Inbox’ for these notifications and log them in your internal Change Management system.
Minimum Requirement: A log of all major supplier infrastructure notifications received and reviewed by IT.
10. Maintain a Local Physical Audit Trail
Control Requirement: Maintain records of supplier service monitoring and review activities.
Required Implementation Step: Collate all performance reports, meeting minutes, and audit validations into a local, encrypted folder structure. Do not leave this data in a GRC platform; ensure it is available offline to present to an auditor during a site visit.
Minimum Requirement: A structured local directory containing all evidence for Annex A 5.22 for the current audit cycle.
ISO 27001 Annex A 5.22 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Service Monitoring | Uses an API to show a “Green” status light from the vendor’s public status page. | Public status pages often hide minor security incidents; only manual log review reveals the truth. |
| Audit Review | Stores an ISO certificate and marks the task as ‘Complete’. | An ISO certificate is a marketing tool; the Statement of Applicability (SoA) and audit findings contain the actual risk. |
| Change Management | Sends an automated email to the vendor asking “Have you changed anything?” | Vendors often ignore automated emails or give ‘Standard’ answers; you must legally mandate Change Requests. |
| Risk Re-assessment | Calculates risk using a generic algorithm based on vendor size. | Algorithms don’t know your specific data flow; only a human-led impact assessment is valid for ISO 27001. |
| Access Monitoring | Assumes the vendor is managing their own user lifecycle correctly. | Vendors frequently fail to offboard staff; you must manually audit their active sessions in your environment. |
| BCP Validation | Accepts a ‘BCP Policy’ document as proof of recovery capability. | A policy is a wish list; only a physical test result proves they can actually restore your data. |
| Vulnerability Management | Relies on the vendor’s ‘Self-Attestation’ of security scanning. | Self-attestation is biased; independent verification via manual scanning is the only way to confirm hardening. |
| Evidence Integrity | Keeps all monitoring records in a cloud-based GRC dashboard. | If the GRC provider has an outage, you have zero evidence for your auditor; local storage is mandatory. |
About the author
