ISO 27001 Annex A 5.22 – Monitoring, Review and Change Management of Supplier Services

Control 5.22 governs the phase most supplier-risk programmes underinvest in: the period after a contract is signed. The security posture you assessed during due diligence is a snapshot. Suppliers rotate subprocessors, move data to new regions, let certifications lapse, get acquired, and quietly edit their data-processing terms. The control requires you to monitor, review, evaluate and manage change — so that the level of security agreed in the supplier agreement (control 5.20, under the overall approach set by 5.19) is actually sustained over the life of the relationship.

Monitoring in practice

Monitoring is the continuous, low-latency activity: watching service delivery and the supplier's security posture between formal reviews. In practice it means tracking performance against agreed service levels, reviewing the supplier's service reports and incident and breach notifications, following up independent audit reports, and keeping eyes on the supplier's publicly stated commitments — their subprocessor list, DPA, privacy and security policies. The purpose of monitoring is to shorten the gap between a change happening at the supplier and you knowing about it.

What a review must produce

A review is the periodic, deliberate assessment — and in an audit what counts is the record it produces, not the meeting. A defensible supplier review record captures the date it was performed and who performed it; the evidence examined (service reports, current certifications, audit or penetration-test summaries, incident history); the findings and any gaps against the agreement; actions raised with owners and due dates; and a residual-risk decision. Without that dated record, you cannot later prove the review happened.

What "change management of supplier services" covers

This is often where gaps show, because it is about detecting drift. The guidance lists changes made by the supplier (new services or systems, revised policies, new controls) and changes in the service (networks, new technologies or versions, a moved service facility, a change of sub-suppliers, new subcontracting). In practice that also means a new subprocessor or region, an edited DPA, a lapsed certification or an acquisition. Each can alter your risk exposure without your own configuration changing, so manage each as it happens.

Auditors rarely stop at your supplier policy. They commonly sample some suppliers and ask for records showing the control operated. Records worth having ready for each:

• The supplier review record — a dated artefact showing the last review, what was examined, and what was decided. A named owner and a next-review date raise its credibility.
• The change log — a chronological record of changes to that supplier's service, subprocessors, data locations, certifications and agreements, each with the date you became aware of it and what you did in response.
• The trigger — evidence of what started a given review. Scheduled cadence is one trigger; a detected change is the stronger one, because it shows monitoring is live rather than calendar-driven.

The hard part is the change log. It is straightforward to show you reviewed a supplier on a schedule. It is much harder to prove that when a supplier added a subprocessor or moved data to a new region, you detected it on a specific date. A change log with no entry for a change the supplier announced on its own website is a gap, however polished your review minutes look.

This is where an external detection layer earns its place in the evidence pack. Venpo monitors each vendor's published legal documents on a schedule — Terms, Privacy Policy, DPA, cookie policy and subprocessor list — and turns every detected change into a dated, versioned redline showing exactly what text changed and when. That timestamped record is corroborating evidence that you detected a supplier-side change on a date, which is precisely what the change log an auditor samples is meant to contain. It complements your own supplier-review process; it does not replace it.

The standard says only “regularly”, with no fixed frequency, so tie cadence to the risk each supplier carries. Set the tier from the data the supplier handles and how central it is to your service, then attach a cadence to each tier.

• Critical suppliers (hold regulated or large-volume personal data, or underpin a core service): a formal review at least annually, often semi-annually, with continuous monitoring of their public posture in between and a review triggered on any material change.
• Important but non-critical suppliers: a formal review annually, with monitoring of certification status and major disclosures.
• Low-risk suppliers (little or no access to sensitive data): a lighter periodic check, often every 12 to 24 months, is usually proportionate.

Keep the two activities distinct. Continuous monitoring is always-on detection between reviews — its job is to catch a change the day it appears, not months later. Periodic review is the scheduled, documented assessment that produces the review artefact. A programme with only periodic review has long blind windows between assessments; a programme with only monitoring generates signals but never the decision record an auditor samples. Good practice uses both, and cadence should tighten as monitoring surfaces more change at a supplier.

The dominant failure mode is not missing due diligence — it is due diligence that stops. Most organisations assess a supplier thoroughly at onboarding: they collect the SOC 2, check the ISO certificate, read the DPA, record a risk rating in a spreadsheet, and sign. Then nothing detects what changes afterward. The certificate expires and no one notices until the next annual review a full year later; a subprocessor is added and the DPA is never re-read; data quietly moves region. The onboarding assessment ages into a document that describes a supplier who no longer exists.

This is the decaying-spreadsheet problem, and auditors may look for it. The row says "SOC 2 reviewed" against a date eighteen months old, while the report it refers to lapsed eight months ago. The subprocessor list in the file is three versions behind the one live on the supplier's site. The control fails not because the review was bad, but because there was no mechanism to detect drift between reviews — so the change log has gaps that exactly match the periods when something changed.

Closing the gap means treating detection as a running process rather than an annual task: a live watch on each supplier's public posture that timestamps changes as they happen, feeding a change log that stays current between reviews. That is the specific, narrow slice Venpo automates for the publicly observable surface — a new subprocessor, an edited DPA clause, a data location that changes in a published document, a rewritten privacy or security policy — so the record an auditor samples reflects the supplier as they are today, not as they were at signing.