ISO 27001 Annex A 5.22: monitoring and changes to supplier services

The questionnaire asks when you last reviewed your cloud hosting provider. You have the onboarding assessment from three years ago and nothing dated after it. ISO 27001 Annex A 5.22 is the control that turns that gap into a routine. Reviews are tiered, assurance is checked for scope and expiry, and supplier changes are risk-assessed as they happen.

This guide is for operations leads, CISOs and compliance managers at regulated UK firms of 25–250 staff who run on dozens of SaaS and cloud suppliers. It covers what the control requires, review cadences, hyperscalers, change triggers, supplier access, automation and what an auditor samples.

What does ISO 27001 Annex A monitoring and review and change management of supplier services require?

ISO 27001 Annex A 5.22 requires you to keep overseeing suppliers for the whole life of the relationship. You check that they deliver what the agreement promises, and you spot and risk-assess changes on their side. Supplier incidents go through an agreed route, and a named, resourced owner acts when shortfalls appear.

Supplier security decays silently. Certifications lapse, sub-contractors change, hosting moves, and the vendor you assessed at onboarding becomes a different company without telling you.

Onboarding diligence describes the supplier you chose, not the one you now have.

The control, titled Monitoring, review and change management of supplier services, closes the loop the neighbouring supplier controls open. Annex A 5.19 classifies the relationship, Annex A 5.20 fixes the obligations, and Annex A 5.21 reaches down the ICT chain. Annex A 5.22 then checks reality against all three, month after month.

The ICO echoes the principle in its ICO AI contracts and third parties guidance. It expects routine in-life compliance checks and a documented process for managing the ongoing relationship. The guidance is written for AI contracts, but the in-life logic is the one this control applies to every supplier.

We class the control as preventive: it exists to catch supplier drift before it becomes an incident. An unwatched supplier can hurt confidentiality, integrity or availability, and availability is usually hit first.

Regulation points the same way for firms running on cloud platforms and SaaS. DORA makes ongoing oversight of ICT providers an explicit duty for financial entities, and NIS2 pushes the same expectation across sectors. UK GDPR holds you accountable for processors you failed to watch.

How should ISO 27001 Annex A 5.22 reviews be tiered, and how often?

Let the tier from Annex A 5.19 set the effort. Critical suppliers get an annual full review plus quarterly service check-ins, important suppliers an annual pass, and commodity vendors a register entry with a renewal-time glance. Each critical supplier needs a named internal owner, and a short minuted agenda keeps reviews sustainable.

Tiering stops the process collapsing. A flat approach either drowns the team or under-covers the suppliers that matter, so cadence should trace back to your tier, not to habit. A critical-supplier review rests on five pieces:

• A named internal owner. Someone close enough to the service to read its reports and dashboards properly, not a distant title. Auditors ask the owner, not the org chart.
• A one-page agenda. Delivery against agreed service levels, incidents and how notification worked, assurance status, changes on their side, and open issues from last time.
• A calendar-based assurance refresh. Certificates and independent reports carry expiry dates and scopes, so recheck both yearly and read the exceptions.
• A rehearsed incident route. Who the supplier calls, who owns it internally and where it is logged, with supplier-caused disruptions recorded as carefully as your own.
• A live exit plan. Where the data sits, how it comes back and what handover looks like, reviewed before renewal rather than drafted mid-divorce.

The quarterly check-in is twenty minutes against that agenda, minuted. Contracts may set lighter check-ins monthly, and a supplier's notice of a material change triggers an event-driven review outside the calendar. A twenty-minute meeting people actually book beats an annual half-day nobody does.

How do you oversee AWS, Microsoft and other hyperscalers you can't audit?

You don't audit AWS or Microsoft; you rely on what they publish. Review their independent assurance reports, certifications, trust-centre attestations and service-health history each year, check scope against the services you consume, and document that reliance. The NCSC notes on-site audit rights may not always be possible or desirable for cloud services.

The NCSC supply chain security guidance asks organisations to build assurance activities and upward reporting of security performance into supply chain management. Documented reliance on published assurance is how that works for a provider who will never let you through the door. Auditors expect it.

Run this review once a year for each hyperscaler or major SaaS supplier:

1. Collect current assurance. Download the latest SOC 2 Type II report or equivalent, plus certifications, from the provider's trust centre.
2. Check dates. Confirm the report period and certificate expiry are current, and put the next refresh in the diary.
3. Check scope. Match the services named in the report against the services you consume. A report covering a provider's core platform may say nothing about a product you adopted later.
4. Read the exceptions. Note qualified opinions, exceptions and the controls the report expects customers to operate themselves.
5. Scan service history. Review status-page history for outages that touched your workloads.
6. Record the conclusion. Date it, name the reviewer and file it against the supplier record.

The common waste is demanding on-site audits of hyperscalers, an argument you lose while real risks go unwatched. Those risks are usually mundane: a service outside the report's scope, or a status history nobody reads.

Which supplier changes must trigger a re-assessment under A.5.22?

Supplier-side changes that should trigger a fresh risk look are new sub-processors, hosting or data-residency moves, and major architecture or platform changes. Changed incident or support arrangements count too, as does anything altering who can touch your data. Route them into your change control, using the notification rights negotiated under Annex A 5.20 as the trigger.

The test is simple: would this change have altered your onboarding decision? If yes, it warrants a look now. A new sub-processor in another country would have changed it; a refreshed logo would not.

The quick risk look is a short routine, not a reassessment project:

1. Log the change as a change record against the supplier, with the notification attached.
2. Check what it touches: which of your data, services and customers sit behind it.
3. Check where it lands: new parties, new locations and new access paths.
4. Decide: accept, ask for mitigation, or escalate to a full supplier review.
5. Record the decision with the date and the owner's name.

Where a supplier gives no notification, the monitoring signals described below catch the same events from public pages. The contractual right and the signal feed give you two routes to the same record.

The pitfall is learning of changes from an invoice or a news story instead of a notification you assessed. By then the decision has been made for you.

How do technical access reviews fit alongside commercial supplier governance?

Commercial governance reads reports and minutes; technical oversight reads access. Annex A 5.22 needs both. Review supplier accounts and remote connections into your environment on a schedule, keep MFA on them, and remove them when engagements end. Guest accounts and integrations should never outlive the contract that justified them.

The identity platform is the natural home for third-party accounts. Tag each supplier account with the supplier, an internal owner and an engagement end date, and the review runs like any other access review. Microsoft 365 or Entra guest reviews are one example of the pattern, not the only form it takes.

A technical review for each supplier covers four things:

• Accounts. Named supplier users and guest accounts, checked against who is still engaged.
• Remote connections. VPNs, jump hosts and support tooling that reach into your environment.
• Integrations and tokens. API keys, service accounts and OAuth grants issued to or for the supplier.
• Authentication. MFA enforced on every supplier account.

The commercial owner of the supplier confirms when an engagement ends, and the identity team removes the access that day. That handoff is what joins the two halves of oversight.

The auditor's question is blunt: which supplier accounts can reach your environment right now, and when were they last reviewed? A register with perfect review minutes and a stale guest list answers it badly.

How do you automate supplier oversight instead of scrambling once a year?

Automation turns A.5.22 from a calendar reminder into a system. Register fields generate review tasks, and certificate expiry dates trigger collection requests. Vendor status and sub-processor pages feed alerting, supplier accounts join scheduled access reviews, and the ticketing system keeps the evidence, so the auditor's year-walk is an export.

Register fields do the scheduling. Tier and cadence on each supplier record generate review tasks, chase owners and surface overdue reviews on a dashboard. The rhythm runs itself instead of living in someone's calendar.

Expiry dates do the chasing for assurance. Certificate and report dates trigger collection requests ahead of lapse, and each returned artefact is filed against the supplier record with a scope-check task attached.

A certificate filed without a scope check is a filing exercise, not assurance.

Signals replace meetings. Vendor status pages, trust centres and breach-notification feeds ingest into your alerting, and sub-processor pages are monitored for changes. Supplier incidents and changes arrive as events to triage, not discoveries at the next quarterly review.

That alerting also delivers the point in the NCSC continuous improvement guidance: listen to and act on concerns surfaced through performance monitoring, incidents or upward reporting from suppliers.

Judgement stays human. Someone still reads the exceptions, weighs residual risk and chairs the critical-supplier reviews. The automation clears the admin around those decisions, and the table shows what each mechanism catches and leaves behind.

What will an auditor test when they sample A.5.22?

Auditors pick one or two critical suppliers from your register and walk the year: review minutes, assurance on file, incidents and changes, with dates checked against your stated cadence. They also test a recently ended supplier through exit and ask the named owner to describe the last review unprompted.

Expect five questions, and have the evidence ready for each:

• "When was the last review of your most critical supplier, and who ran it?" Answer with the register entry and the minutes, with actions traced to closure.
• "How do you know the certification is valid and covers the service you buy?" Show the in-date certificate or report with the scope check recorded.
• "This vendor added a sub-processor last year. Where did you assess it?" Produce the notification, the assessment and the decision from the change record.
• "If a supplier has an outage or breach, who owns it?" Show incident entries with notification timelines and follow-up.
• "Which supplier accounts can reach your environment today?" Hand over the access-review records for supplier accounts.

For ended relationships, the evidence is the exit itself: handover records and destruction confirmations. The register is the auditor's index into all of it. It must show tier, owner, cadence and last-review date for each supplier, and reflect who you actually use.

Here is how we read the severity. Critical suppliers with no oversight since onboarding, or a register that doesn't reflect who you use, grade major. A lapsed report awaiting renewal, one slipped review or thin minutes grades minor, and minors aggregate into a major when they form a pattern.

Four traps fail this control most often:

• Onboarding-only diligence. An impressive assessment at signature, then years of silence the audit trail can't hide.
• Uninspected assurance PDFs. Lapsed dates, mismatched scopes or unread exceptions give false comfort.
• Unrecorded reviews. The meeting happened but left no minutes, no actions and nothing to learn from.
• Fourth-party blind spots. Nobody has asked critical suppliers how they manage their own suppliers.

What does a working A.5.22 rhythm cost, and what does it give you?

A working Annex A 5.22 rhythm costs about a week to design the cadence and review pack. After that it takes a few hours per quarter at this scale, folded into an existing operations review. In return you get dated proof that supplier oversight continues, and early warning before a supplier's drift becomes your breach.

The upside is commercial, and DORA-facing clients should over-invest here first. An enterprise customer asking how you oversee your suppliers gets dated minutes, a current assurance file and a change log, not a promise. A sub-processor change or region move reaches you as an alert before it turns into a breach of what you told that customer.

If you would rather not build it alone, GRC engineering turns the register, expiry and signal automation into a working pipeline. Fractional CISO support chairs the critical-supplier reviews and makes the calls on supplier changes.

Frequently asked questions