Control Definition
The organization must regularly monitor, review, and evaluate how its suppliers deliver their services and uphold their security practices, and must manage changes to those services — new sub-processors, altered architectures, revised terms — so the agreed level of security holds for the life of the relationship.
Control Objective
To keep the assurance gained at supplier onboarding true over time, by verifying on a defined rhythm that service delivery, security practices, and the agreement itself still match what was assessed and contracted.
What This Really Means
Due diligence has a shelf life. The SOC 2 report you reviewed at onboarding describes a past audit window; the ISO certificate can lapse or shrink in scope; the security-minded engineering lead who answered your questionnaire may have left; and the supplier may since have re-platformed, swapped sub-processors, or been acquired by someone with different priorities. A.5.19 and A.5.20 buy you a true picture and a binding contract on day one — A.5.22 is the control that stops both from quietly expiring.
In practice the control runs on a review rhythm scaled by tier. Critical suppliers get scheduled service reviews — quarterly or semiannual — with security standing on the agenda: incidents since the last review, SLA and security KPI performance, open findings, planned changes. Annual re-verification keeps the assurance evidence current: collect the new certificate, check scope and the issuing body, read the fresh SOC 2 Type II including exceptions and the user entity controls assigned to you, and record a dated conclusion. Lower tiers get proportionally lighter treatment — an annual check that the supplier still exists in the form you assessed is legitimate for the bottom of the register.
The second half of the control is change management, and it is where most programs leak. Suppliers change constantly: a new sub-processor announced in an email nobody reads, data migrated to a new region, a feature rebuilt on a different architecture, an acquisition that changes ownership and jurisdiction. The control asks that material changes reach a named owner, get assessed against your requirements before they take effect where the contract gives you an objection window, and update the register and chain map (A.5.21). The mirror duty is managing changes on your side — telling suppliers when your requirements change and re-papering where needed. Exit discipline closes the loop: defined triggers for escalation or termination, and a current exit plan for critical suppliers so leaving is a procedure, not a hostage negotiation.
Auditors test this control with one move: pick a critical supplier and ask for the last twelve months. The minutes of the most recent service review, the current certificate with your documented conclusion, the last sub-processor change you assessed, the open findings and their owners. Evidence frozen at onboarding two years ago is the defining failure here — a register column of next-review dates that are all in the past is one of the most commonly written supplier nonconformities.
Why It Matters
Supplier security posture decays silently. Cost pressure trims their security team, growth outruns their controls, an acquirer consolidates infrastructure — and nothing about your integration changes, so nothing alerts you. Most third-party incidents do not strike organizations that skipped due diligence; they strike organizations whose due diligence was accurate years ago. The review rhythm is the only mechanism that converts "we checked once" into "we know now", and the change-management half is the only way you discover that your data quietly moved to a new fourth party or jurisdiction.
This control is also what gives the rest of the supplier suite consequences. A.5.19's tiering and A.5.20's clauses produce obligations — certificate maintenance, notification duties, SLA commitments — that are worthless if nothing verifies them. Customers and regulators increasingly judge the ongoing oversight, not the onboarding paperwork: financial supervisors expect periodic review and tested exit strategies for material outsourcing, and a fiduciary's accountability for its processors runs for the life of the processing, not the day of signature.
Without ongoing supplier monitoring and change management, organizations face:
- •Expired assurance – the certificate checked at onboarding lapsed or lost the relevant scope, and the first person to notice is your auditor — or your attacker
- •Silent sub-processor swaps – your data lands with a fourth party in a new jurisdiction via a notification email that went to a leaver's inbox
- •Degrading service security – staff churn and cost-cutting erode the supplier's controls, and with no review rhythm the first signal is the incident itself
- •Acquisition surprises – ownership, jurisdiction, and infrastructure change overnight while your risk assessment still describes the old company
- •Hostage exits – with no exit triggers or plan, a failing critical supplier keeps your data and your dependency long after the trust is gone
Regional Compliance Context
India's financial regulators treat ongoing oversight as the substance of outsourcing control: RBI's directions expect regulated entities to monitor material service providers continuously, review them periodically, and maintain tested exit strategies — onboarding diligence alone does not satisfy supervision, and SEBI's CSCRF sets equivalent expectations for market intermediaries. Under the DPDP Act 2023, a fiduciary's responsibility for its processors is continuous, so sub-processor changes and data-location moves at your suppliers are compliance events to assess, not newsletters to archive — a discipline worth building well before full obligations land on 13 May 2027.
Implementation Guidance
Set a Review Cadence by Tier and Calendar It
Define the rhythm in the supplier security policy: critical suppliers quarterly or semiannually, medium tier annually, low tier at contract renewal. Assign each review to a named relationship owner, put the schedule in the same tracking system as internal audits, and report completion — overdue supplier reviews should surface in management review like any other overdue program item.
Fix the Security Agenda of a Service Review
Standardize what every review covers: incidents and near-misses since the last review, performance against SLAs and security KPIs (patching posture, availability, support responsiveness to security requests), status of open findings, upcoming changes the supplier plans, and any shifts in your own requirements. Minute the review and file it against the supplier record — the minutes are the audit evidence.
Re-Verify Certificates and Assurance Reports Annually
Calendar a re-verification task per significant supplier driven by certificate expiry and report cycles: confirm the ISO 27001 certificate is current, accredited, and scoped to the service you buy; obtain the new SOC 2 Type II each period and read the opinion, exceptions, and complementary user entity controls; record a dated conclusion and chase gaps. An expired certificate in the file is worse than none — it proves the process stopped.
Route Supplier Change Notifications to a Named Owner
Register a role-based address (not an individual's inbox) for sub-processor and service-change notices, feed it into a ticket queue, and define what counts as material: new sub-processors touching your data, data-location moves, ownership changes, major architecture or terms revisions. Assess material changes before the objection window closes where A.5.20 clauses provide one, and update the register and A.5.21 chain map with the outcome.
Monitor Between Reviews
For critical services, watch the signals that arrive without asking: status pages and incident histories, security advisories, breach news, trust-center updates. Security rating services can add continuous external posture data across a large estate, though they supplement rather than replace the review rhythm. Pipe anything significant into the next review — or trigger an immediate one for serious events.
Manage Findings Like Internal Nonconformities
Log issues from reviews, re-verifications, and incidents in a findings register with owners, due dates, and severity. Escalate per the contract when remediation stalls — the A.5.20 clauses define your levers — and track closure evidence. A findings list that only ever grows tells an auditor the reviews are theater.
Define Exit Triggers and Keep Offboarding Ready
Document what justifies escalation or termination: lost or lapsed certification, repeated security SLA breaches, an unremediated critical finding, a breach handled in bad faith. Maintain a current exit plan for each critical supplier — data return and verified destruction, transition arrangements, dependency unwind — and execute the A.5.19 offboarding checklist at every exit, with the register updated to closed.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.22:
Documentation
- Supplier review schedule by tier with completion tracking, and minutes of recent service reviews showing security agenda items
- Current certificates and assurance reports for critical suppliers, each with a dated review conclusion (scope, exceptions, user entity controls)
- Sub-processor and service change notifications with assessment records, decisions, and register updates
- Findings register from supplier reviews showing owners, due dates, escalations, and closure evidence
- Exit plans for critical suppliers, and offboarding records for ended relationships including data return or destruction confirmation
Interviews
- The relationship owner of a critical supplier on the last review — what was discussed, what changed, what is open
- CISO or security manager on how annual re-verification works and what happens when a certificate lapses or a SOC 2 carries exceptions
- Procurement or vendor management lead on how change notifications arrive, who assesses them, and when the objection window was last used
Observations
- Trace of one critical supplier across twelve months: review minutes, current assurance conclusion, last change assessed, open findings
- Inspection of the change-notification queue or mailbox, checking notices are triaged into tickets rather than archived unread
- Walkthrough of one closed finding from a supplier review through to its closure evidence
Practitioner Insights
The sampled question in this control is never "did you assess them at onboarding" — it is "show me the last twelve months." A register whose next-review-date column is entirely in the past is among the most frequent supplier nonconformities I write, and it is pure calendar discipline, not skill: collect the new report, read it, conclude, date it, file it. The subtler miss is the user entity controls section of a SOC 2 — suppliers assign you homework in those reports, and organizations that never read the section are failing controls they do not know they own.
Small teams hear "monitor your suppliers" and imagine dashboards and rating platforms they cannot afford. The honest minimum is a recurring calendar task per critical supplier: pull the current certificate or report, skim the status page and incident history, write five dated lines, file them — an hour per supplier per cycle. The failure I see most is structural, not effort: sub-processor notices going to whoever created the vendor account years ago, who has since left. A shared alias feeding a ticket queue fixes in an afternoon what otherwise becomes an unexplainable gap at audit.
Common Challenges & Solutions
Challenge
Reviews are scheduled but never happen because operational work always wins.
Solution
Stop creating standalone security meetings — attach the security agenda to the commercial QBRs and vendor check-ins that already occur, with the relationship owner accountable for covering it and filing minutes. Track completion in the same dashboard as internal audit actions and report overdue reviews to management review. Visibility, not enthusiasm, is what sustains the rhythm.
Challenge
Certificates and SOC 2 reports are collected annually but filed unread, including expired ones.
Solution
Make the unit of work a conclusion, not a collection: the re-verification task is complete only when someone has checked currency, accreditation, and scope, read exceptions and user entity controls, and written a dated verdict. Drive the calendar from certificate expiry dates rather than a generic annual sweep. Ten minutes of reading per supplier converts a dead PDF archive into audit evidence.
Challenge
Sub-processor change notices are missed because they go to an individual who left the company.
Solution
Move all supplier notices to a role-based alias feeding a ticket queue with a named triage owner, and update the contact registered with each critical supplier — the A.5.20 clause should require notices to a role address. Quarterly, spot-check the published sub-processor pages of your top suppliers against the register to catch anything the inbox missed.
Challenge
Suppliers will not attend reviews or share security metrics, especially large SaaS vendors on standard terms.
Solution
Set the expectation contractually where you have leverage — A.5.20 review and reporting obligations for critical custom-service suppliers. Where you do not, review what they publish: trust center, status and incident history, annual assurance reports, change logs. A documented conclusion drawn from published evidence is a legitimate review for a standard-terms SaaS; the discipline is writing it down on schedule.
Challenge
A deteriorating critical supplier lingers for years because nothing defines when enough is enough.
Solution
Pre-agree objective exit triggers — lapsed certification, repeated security SLA breaches, an unremediated critical finding past its deadline, a breach handled in bad faith — and an escalation ladder leading to them. Keep the exit plan current and rehearse the data-return mechanics for the most critical dependency. Decisions written in calm weather actually get executed in bad weather; improvised ones get deferred indefinitely.
