What is sub-processor monitoring?

Sub-processor monitoring is the practice of watching a vendor's published sub-processor list for additions, removals, and changes to existing entries, so you learn about a new party in your data chain when it is announced rather than at your next annual review. GDPR Article 28(2) gives controllers the opportunity to object to such changes, which only has value if you see them in time.

Do vendors have to tell me when they add a sub-processor?

Under GDPR Article 28(2), a processor operating under general written authorisation must inform the controller of intended changes concerning the addition or replacement of other processors, and give the controller the opportunity to object. In practice most vendors satisfy this by publishing a sub-processor page and offering a subscription, which puts the burden of noticing on you.

How often should vendor documentation be checked?

Daily for vendors that process personal data or sit in a revenue path. Sub-processor notice periods are usually measured in weeks, so a daily check preserves your window to object without generating noise. Lower tier vendors are fine on a weekly check.

Can this replace a vendor questionnaire or a cyber rating?

No. Questionnaires capture what a vendor asserts at a point in time and cyber ratings measure external attack surface. Documentation monitoring covers a third thing neither of them sees: whether the commitments you assessed are still the commitments in force. The three are complementary layers.

All guides

31 July 20269 min read

How to monitor vendor sub-processor and DPA changes

Q: What should trigger an alert on a DPA?

Set the trigger on the clauses your assessment relied on rather than the whole agreement: the transfer mechanism and standard contractual clauses, the security measures annex, breach notification timelines, audit rights, and retention terms. Watching the entire document means a fixed typo or a renumbered clause fires the same alert as a reworded notification window.

Alexandra SwanCustomer Operations Lead

The short answer

Monitor vendor sub-processor and DPA changes by watching each vendor's sub-processor page, DPA, trust center, and status page as separate tracked pages, with an alert set on the part of the page that carries the commitment rather than the whole document. When a processor is added, a certification lapses, or a clause is reworded, you get the before and after text and a timestamped snapshot you can attach to the vendor file.

The gap between annual reviews

Most third-party risk programmes run on a cycle. A questionnaire at onboarding, a cyber rating that refreshes on its own, and a reassessment once a year. That covers the vendor you assessed. It does not cover the vendor you have now.

Between those reviews the vendor keeps shipping. It adds a sub-processor in a new country. It updates its DPA. Its SOC 2 report expires and the replacement is late. Its trust center quietly drops a certification. None of that fires a notification, because vendor documentation pages are published, not sent. The only thing standing between your risk register and reality is whoever remembers to open the tab.

The question a monitoring setup answers is narrow and worth asking every day: is this still the vendor we assessed?

What GDPR actually requires of your vendors

The sub-processor problem is not a best-practice concern. It sits directly in Article 28 of the GDPR, and it is written as a right you hold rather than a courtesy the vendor extends.

Article 28(2) states that a processor "shall not engage another processor without prior specific or general written authorisation of the controller". Where that authorisation is general, the same paragraph requires the processor to inform the controller "of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes".

Two things follow from that wording. First, you have a right to object, and a right to object is worth nothing if you find out after the fact. Second, most vendors discharge the duty to inform by publishing a sub-processor page and asking you to subscribe to it, which moves the operational burden onto you.

Article 28(4) is the reason this matters commercially rather than just procedurally. If a sub-processor fails to meet its data protection obligations, "the initial processor shall remain fully liable to the controller for the performance of that other processor's obligations". Your vendor stays liable to you. You, in turn, stay accountable to your own regulator and customers for a chain you are supposed to have visibility into.

The four pages worth watching per vendor

Vendor documentation is scattered across several URLs that change at different rates and for different reasons. Watching them as one blob produces noise. Watching them separately produces a usable signal, because the page that changed tells you what kind of change it was before you read a word.

The sub-processor list

The highest-value page and the one most likely to move. You are watching for three distinct events: a party added, a party removed, and a change to an existing entry, usually the processing location or the service description. A new sub-processor in a jurisdiction you have no transfer mechanism for is a finding. A removed one may end a data flow you documented.

Watch the table or list itself rather than the page. Sub-processor pages usually sit inside a marketing or legal template with navigation, a cookie banner, and a footer date that all move on their own.

The DPA and its annexes

The agreement text changes less often and matters more when it does. The clauses worth isolating are the ones your legal team negotiated or relied on: the transfer mechanism and standard contractual clauses, the security measures annex, breach notification timelines, audit rights, and retention and deletion terms.

A reworded notification window, for example from 72 hours to "without undue delay", is the kind of edit that never appears in a changelog and changes your own regulatory exposure.

The trust center and certification status

Trust centers are where certifications appear, expire, and quietly vanish. SOC 2 Type II reports cover a defined observation window, so a report that was current at onboarding stops being current on a fixed date whether or not anyone updates the vendor file.

Watch the certification list and the report dates. An expired report with no replacement is a finding you want to raise before your auditor does.

The status and incident page

Status pages carry incident history and postmortems. Most vendors publish these and few customers read them. For risk work the value is not the live outage, which you will hear about anyway, but the pattern: repeated incidents in the same subsystem, or a postmortem that discloses something your questionnaire asked about.

How often vendor documentation actually changes

Visualping, which sells a competing product into this market, published sampling figures on its third-party risk page: it reports that 67% of sampled sub-processor pages saw a listed-party change within 90 days, and that 41% of sampled privacy policies updated during the same 90-day window.

Treat those as directional rather than as a benchmark, since the sampling method is not published and the company selling the monitoring has an interest in the number being high. Even discounted heavily, they describe something a quarterly manual check cannot keep up with. A page that changes inside 90 days more often than not is a page that needs watching rather than visiting.

Setting up monitoring for a vendor portfolio

The setup below takes a few minutes per vendor and scales to a portfolio because nothing about it is per-vendor bespoke.

List your vendors in tiers. Tier one is anything processing personal data, holding production credentials, or sitting in a revenue path. Start there and leave the long tail for later, because a monitoring programme nobody reads is worse than none.
For each tier one vendor, collect the four URLs: sub-processor list, DPA, trust center, status page. Some vendors combine them. Some hide the sub-processor list behind the DPA, in which case watch the DPA and set the trigger on the annex.
Add each URL as its own tracked page. Keep them separate so the alert itself tells you which document moved.
Set the trigger on the part that carries the commitment. Select the sub-processor table, the security annex, the certification list. Everything outside the selection stops being able to fire an alert.
Choose daily checks for tier one. Sub-processor notice periods are usually measured in weeks, so daily is fast enough to preserve a right to object and slow enough to stay quiet.
Route alerts where the work happens. Send them to the risk or GRC channel rather than an individual inbox, so the review does not stall when one person is away.

The output you want from each alert is the old text and the new text next to each other, plus a timestamp. That is what turns a notification into a record: months later, the question is rarely "did it change" but "what did it say on the day we signed".

Why whole-page diffs fail on vendor documentation

Vendor legal pages are among the worst possible candidates for whole-page change detection, which is what most free monitoring tools do.

A "last updated" line in the footer changes on republish even when the substance did not.
Trust centers are increasingly rendered from a component library, so a redesign rewrites the entire DOM and reports as a total change.
Cookie banners, region notices, and support widgets inject and remove themselves per visit.
Long legal pages accumulate small non-substantive edits: a fixed typo, a renumbered clause, a changed hyperlink.

Each of those produces an alert that turns out to be nothing. Three or four of them and the alert stops being read, which is the actual failure mode. Monitoring that is ignored is indistinguishable from monitoring that does not exist, and it is worse because it appears in your programme documentation as a control.

Narrowing the trigger to the clause or the table is what keeps the false positive rate low enough that the alert keeps its authority.

Making the output audit ready

Continuous monitoring is only useful to a risk programme if it produces evidence. An email that says a page changed is an event. A timestamped snapshot of what the page said before and after is a record.

Keep the snapshot history attached to the vendor file rather than in an inbox. When an auditor asks how you knew a sub-processor was added in March, the answer is a dated diff, not a recollection. The same record answers the harder question of when you knew, which is what determines whether you exercised a right to object in time.