How to Monitor Vendor Sub-Processor Changes and Privacy Policies for GDPR Compliance

In 2025, the Polish data protection authority (UODO) fined McDonald’s Polska €4,022,773 — with an additional €43,680 levied directly against the processor, 24/7 Communication Sp. z o.o. — after a processor misconfiguration exposed sensitive employee data. The breakdown of the controller’s fine is the part most coverage misses: €387,738 specifically for Article 28(1) (failure to verify the processor provided sufficient guarantees), €3,231,143 for Articles 24/25/32 (security measures), and €403,892 for Article 38(1) (DPO involvement). UODO’s reasoning was pointed: McDonald’s had selected the processor based on prior PR work without evaluating data protection capabilities, retained no administrative access, and never performed audits or inspections.

This wasn’t a contract failure or a due diligence failure at onboarding. It was a monitoring failure — the controller didn’t know the processor’s security posture had changed until the breach happened. And UODO carved out the Article 28 piece as its own distinct violation, separate from the security failings themselves.

This is the continuous monitoring obligation most compliance teams underestimate. GDPR Article 28 doesn’t require you to vet your processors once and file the DPA. It requires you to continuously verify that “sufficient guarantees” remain in place throughout the relationship. DORA Article 28, effective January 17, 2025 for EU financial entities, adds a parallel requirement for ICT third-party providers. Both regulations explicitly reject the “set and forget” approach.

This guide covers what compliance teams should actually monitor on vendor websites, why existing approaches (Google Alerts, manual reviews, trust portals) fall short, and how to automate this with a general-purpose monitoring tool.

What continuous processor monitoring actually requires

Article 28(1) GDPR requires controllers to use only processors providing “sufficient guarantees.” The European Data Protection Board has repeatedly clarified that this obligation extends through the entire relationship, not just at onboarding. The Article 29 Working Party Opinion 1/2010 and subsequent EDPB guidance make the controller’s ongoing accountability explicit: you must detect changes in the processor’s security posture, identify new sub-processors, and assess emerging risks.

In practice, this means monitoring for:

Sub-processor changes. When your vendor adds, removes, or substitutes a sub-processor, you need to know. GDPR requires written authorization — either specific (per sub-processor) or general (with the right to object). Most vendors operate under general authorization, which means they must notify you of changes. But “notify” in a DPA often means “update our sub-processor page” — and if you don’t check the page, you don’t know.

DPA and Terms of Service updates. Vendors amend their data processing agreements more often than compliance teams realize. A new sub-processor category, a changed international transfer mechanism, a modified security annex — any of these can affect your compliance posture. Most vendors don’t email customers about DPA changes; they update the public version and notify you in the next contract renewal cycle.

Privacy policy revisions. When a vendor changes what data they collect, how they use it, or who they share it with, your own privacy notices may need to reflect this if you’re a data controller relying on their processing.

Security certification changes. ISO 27001, SOC 2, and industry-specific certifications have expiration dates and re-certification cycles. A vendor whose SOC 2 Type II report lapsed six months ago no longer provides the same guarantees you relied on during due diligence.

Incident disclosures. Some vendors publish breach notifications, service disruptions, or security advisories on their trust center or status pages. Sub-processor incidents can become your incident under GDPR’s 72-hour notification requirement.

Jurisdiction changes. When a vendor opens a new data center, changes their default data residency, or modifies their list of hosting locations, international transfer analysis may need to be redone.

Why existing approaches fail

Google Alerts. Frequently recommended, almost uniformly inadequate. Google indexes the public web, but sub-processor lists, DPA pages, and trust portals are often excluded from indexing (via robots.txt) or rendered via JavaScript that Google’s crawler may not execute reliably. Alerts fire on press coverage and blog mentions, not on the vendor page itself changing. You’ll hear about the Stripe breach from TechCrunch before you hear about it from the page you’re supposed to be monitoring.

Vendor notification emails. Some vendors genuinely do email customers about DPA changes. Many don’t. Even the ones that do typically only email the original signatory — who may have left the company two years ago. Relying on inbound notifications means relying on the vendor’s internal comms discipline and your own org’s email routing, both of which fail.

Trust portals (Vanta, Drata, SafeBase). Useful for vendors who publish there, but coverage is fragmented. Your critical SaaS vendors are probably on three different trust portal platforms, plus a few that publish their own static pages. There’s no unified view.

Annual vendor reviews. The dominant pattern in compliance programs: review each vendor once a year, check their current documentation, renew or revoke. The problem is obvious: for 11 months of the year, you have no visibility into changes. A Polish DPA fine-worthy incident can happen in month 3, and you won’t know until month 12.

GRC platforms (OneTrust, Vanta, Drata). These excel at workflow, documentation, and audit trail, but most rely on vendor self-attestation through questionnaires. They don’t actively monitor the vendor’s public compliance pages for changes.

What to monitor on each vendor

The practical monitoring set for a B2B SaaS company using 20–40 processors typically looks like this:

High-priority (monitor daily or every 4 hours):

• Sub-processor lists (almost always at /subprocessors, /sub-processors, or /trust/subprocessors)
• DPA page (usually /dpa, /data-processing-agreement, or linked from legal)
• Privacy policy (obvious)
• Security overview or trust center landing page
• Status page (for incident detection)

Medium-priority (monitor daily):

• Terms of Service
• Pricing page (material changes often signal business model shifts affecting data handling)
• Data residency or regional availability pages
• Security certification pages (SOC 2, ISO 27001 badges and reports)

Lower-priority (monitor weekly):

• General Terms or MSA page
• Acceptable Use Policy
• Cookie policy

For most SaaS vendors, the first three high-priority pages are where the material changes happen. A focused compliance monitoring program covers those three pages per critical vendor and expands from there.

Concrete examples of vendor pages to monitor

The largest SaaS vendors publish stable URLs for these pages, though they do move occasionally — always verify a URL resolves before adding it to your monitor set. A starter list for common infrastructure:

• Google Cloud: cloud.google.com/terms/subprocessors
• AWS: aws.amazon.com/compliance/sub-processors/
• Microsoft Azure: servicetrust.microsoft.com/ViewPage/TrustDocumentsV3
• Stripe: stripe.com/legal/service-providers
• HubSpot: legal.hubspot.com/sub-processors-page
• Salesforce: compliance.salesforce.com (list is published as a downloadable PDF — monitor the compliance portal page or the PDF URL directly)
• Slack: slack.com/trust/compliance (Slack consolidated the per-page sub-processor URL into the compliance hub)
• Zoom: explore.zoom.us/en/trust/subprocessors
• Mailchimp: mailchimp.com/legal/subprocessors/
• OpenAI: openai.com/policies/sub-processor-list/
• Anthropic: trust.anthropic.com/subprocessors

For each, the monitoring prompt should be specific: “Alert me when any sub-processor is added, removed, or substituted. Report the name of the changed sub-processor, their stated processing purpose, and their location. Ignore formatting changes, footer updates, and navigation changes.”

This level of focus means you get one alert when AWS adds a new sub-processor, not twenty alerts when they restructure their trust portal.

Setting up vendor compliance monitoring

Step 1: Build your processor inventory.

List every vendor that processes personal data on your behalf. For each one, find and document:

• The URL of their sub-processor list
• The URL of their current DPA
• The URL of their privacy policy
• The URL of their trust center or security overview

If any of these don’t exist for a critical vendor, that’s itself a compliance finding worth documenting.

Step 2: Create focused monitors.

For each URL, create a monitor with a compliance-specific prompt. Generic prompts produce noisy alerts. Specific prompts produce actionable ones:

For sub-processor pages:

“Monitor this sub-processor list. Alert me when: (1) any sub-processor is added, (2) any sub-processor is removed, (3) a sub-processor’s location or processing purpose changes. Report the specific sub-processor name and what changed. Ignore cookie banners, navigation, and formatting updates.”

For DPA pages:

“Monitor this Data Processing Agreement. Alert me when: (1) the list of authorized sub-processors changes, (2) security measures in the technical and organizational measures annex are modified, (3) international transfer mechanisms change, (4) the retention period or data deletion procedures change. Summarize the specific contractual changes. Ignore version numbers and date stamps if the substantive content is unchanged.”

For privacy policies:

“Monitor this privacy policy. Alert me when: (1) new categories of personal data are collected, (2) new data sharing arrangements are added, (3) new third-country transfers are introduced, (4) data retention periods change, (5) new automated decision-making is disclosed. Ignore purely editorial changes.”

Step 3: Route alerts to the people who can act on them.

Compliance changes are only useful if they reach the right people. The practical routing pattern:

• Email digest to the compliance officer or DPO for all changes
• Slack channel (#compliance-alerts or similar) for real-time visibility
• Webhook into your GRC platform to auto-create a review task tagged to the relevant vendor
• Quarterly review meeting with the accumulated change log

Step 4: Maintain a change log.

Every alert gets logged with date, vendor, what changed, assessment, and response. Over 12 months, this log becomes your audit evidence of continuous monitoring — exactly what supervisory authorities look for when investigating whether your oversight was adequate.

A simple format:

DORA-specific considerations for financial entities

DORA (Regulation 2022/2554) applies to banks, insurance companies, investment firms, payment institutions, and other financial entities in the EU. Article 28 requires financial entities to maintain a register of ICT third-party service providers and conduct continuous monitoring of contractual arrangements, particularly for providers supporting critical or important functions.

The monitoring expectations under DORA are stricter than GDPR in three respects:

1. Concentration risk assessment. DORA expects you to evaluate dependencies on specific providers. Monitoring vendor announcements about acquisitions, regional expansions, or capacity changes helps maintain this assessment.

2. Subcontracting chain visibility. Article 30 requires visibility into the subcontracting chain for critical functions. This means monitoring not just your direct vendor’s sub-processor list but tracking how deep the chain goes.

3. Exit strategy triggers. DORA Article 28(8) lists specific circumstances that can require contract termination, including “material changes that affect the arrangement or the situation of the ICT third-party service provider.” Continuous monitoring is how you detect these material changes.

For EU financial entities, a vendor compliance monitoring program isn’t optional — it’s the mechanism by which you satisfy the Article 28 ongoing oversight obligation.

What a reasonable compliance monitoring program costs

A mid-sized SaaS company using 30 processors, monitoring 3 pages per processor (sub-processors, DPA, privacy policy), produces 90 monitors. Most compliance platforms charge per-monitor or per-vendor pricing that makes this expensive quickly.

The practical approach: use a general-purpose monitoring tool for the 20–25 most critical vendors (60–75 monitors), and handle the long tail of low-risk vendors through quarterly manual reviews. A tool like CheckSite Pro supports 20 monitors at $9.99/month. For a compliance program, that covers 6–7 critical vendors comprehensively. Higher-tier plans or stacking multiple accounts cover larger processor inventories.

This is substantially cheaper than dedicated vendor risk platforms (OneTrust, Drata, Vanta) which start at several hundred dollars per month for vendor monitoring modules. For compliance teams at startups and SMBs, the trade-off is clear: dedicated platforms give you workflow and questionnaire management; general-purpose monitoring tools give you actual change detection on vendor pages. Most teams need both, but the change detection is often the gap.

Common mistakes to avoid

Monitoring the wrong page. Vendors sometimes publish a “current sub-processor list” and a “notification of changes” page separately. Monitor the list itself, not the announcement page — some vendors update the list silently without announcing.

Alerting on every change. Focus prompts eliminate noise. If you’re getting more than 2–3 compliance alerts per vendor per month, your prompts aren’t focused enough.

Not monitoring your own vendors’ vendors. Sub-processor changes cascade. When your vendor adds a new sub-processor, that sub-processor may itself add sub-sub-processors that affect your compliance chain. For truly critical processing (health data, financial data), monitoring one level down is worth the effort.

Treating certifications as permanent. SOC 2 Type II reports cover a specific audit period. A SOC 2 from 2024 doesn’t guarantee current compliance. Monitor certification pages for version and date changes.

Skipping the log. Monitoring without documentation isn’t defensible in a regulatory investigation. The log is the evidence that you actually received alerts and acted on them.

Getting started

For compliance teams currently handling vendor oversight through annual reviews, automated page monitoring is a significant upgrade for minimal investment. The setup takes 30–60 minutes for your top 10 vendors, and the first useful alert typically arrives within the first two weeks.

Start monitoring vendor compliance pages free →

CheckSite’s free tier includes 3 monitors with daily checks and AI-powered change summaries (capped at 15 summaries per month — sub-processor pages change rarely enough that the cap rarely bites in practice). Pro at $9.99/month covers 20 monitors with hourly checks and routing to Slack, Discord, email, Telegram, or webhook for integration with your GRC platform.

For related compliance monitoring scenarios, see our guide on monitoring regulatory and government websites and how to get notified when any website changes.