Third-party data flows are where most GDPR surprises begin. A marketing team adds a pixel, a product squad swaps an analytics SDK, a vendor quietly sub-processes to a new host, and none of it reaches the DPO until an alert, a complaint, or a regulator does. A short monthly routine turns those surprises into routine housekeeping. Below are eight recurring checks you can run in an hour or two, plus a note on where to automate the tedious parts.
Why monthly, and why third parties
Third-party flows change faster than any register can keep up with by hand. Tags ship on release cycles you do not control, consent tools get reconfigured, and processors update their own sub-processor lists on their own schedule. A monthly cadence is frequent enough to catch drift before it compounds, and light enough that it actually gets done. The goal is not a perfect audit every month. It is a fast sweep that confirms reality still matches what you have documented, and flags the gaps that need real work.
The eight checks
1. Reconcile live tags against your vendor register
Load your highest-traffic pages (home, signup, checkout, account) and compare the third-party hosts that actually fire against your declared list of processors and their purposes. Any host you cannot name is a finding. This single check catches the most common failure: a tag added by a team that never told you.
2. Verify consent is actually gating non-essential tags
Confirm that analytics, advertising and other non-essential trackers do not load before consent, and that a genuine refusal keeps them off. Under the ePrivacy rules, storing or reading information on a user's device generally needs prior consent unless it is strictly necessary. Test the reject path, not just accept, because that is where most CMP misconfigurations hide.
3. Review changes to processor sub-processor lists
Most processors publish a sub-processor page and offer a change notification. Check for new entries since last month. A new sub-processor can mean a new data location or a new transfer that your records and your transfer assessments need to reflect.
4. Confirm transfer safeguards for non-EU flows
For any flow leaving the EEA, confirm the mechanism is still valid: an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules, backed by a transfer impact assessment where needed. Adequacy status and vendor arrangements change, so treat this as a recurring check rather than a one-time sign-off. The European Commission maintains the current list of adequacy decisions.
5. Check retention and deletion against policy
Pick two or three data sets and confirm the actual retention matches what your records of processing state. Look for logs, backups and analytics exports that quietly outlive their stated period. Over-retention is a frequent and avoidable finding.
6. Clear the data subject request backlog
Confirm access, erasure and objection requests are being handled inside the one-month statutory window, and that third-party processors are passing through erasure instructions. A rising backlog is an early warning that a process, or a vendor, has broken.
7. Reconcile your Article 30 records with reality
Records of processing activities drift as products change. Spot-check that new features, new data sets or new vendors from the last month are reflected. If engineering shipped something that processes personal data, it should appear here.
8. Scan for breach and incident signals
Review any security or vendor incidents from the month and confirm the 72-hour notification clock was assessed for each. Even incidents you judged non-notifiable should have a documented rationale. This keeps your defensibility intact if a regulator asks later.
A simple scoring habit
Rate each check green, amber or red, and only write detail for amber and red. Over a few months the pattern matters more than any single result: a check that is repeatedly amber points to a process that needs fixing at the source, not another manual sweep. Keep the log short and dated so you can show a regulator a consistent, evidenced routine.
| Check | Typical failure it catches |
|---|---|
| Tags vs register | Undeclared tracker added by a team |
| Consent gating | Trackers firing before or despite refusal |
| Sub-processor changes | New data location or transfer |
| Transfer safeguards | Lapsed or missing SCCs |
| Retention | Data kept past its stated period |
| DSR backlog | Requests slipping the one-month limit |
| Article 30 records | New processing not documented |
| Incident signals | Missed or undocumented 72-hour assessment |
Where to automate the tedious part
Checks 1 and 2 are the ones that decay fastest and are the most painful to do by hand every month. This is exactly what Seqlense GDPR is built for: it renders your live pages in a real browser, captures the full network waterfall, matches every detected host against your declared vendor register, and raises a drift alert when an undeclared tag ships. That turns a manual page-by-page sweep into a standing signal, so the tag and consent checks become a review of exceptions rather than a hunt. The remaining checks stay human judgement, which is where a DPO's time is better spent.
Run the eight, log the colours, fix what stays amber. That is what keeps surprises off your desk.