Why Third-Party Scripts Are Your Biggest Compliance Blind Spot
Most websites load between 10 and 30 third-party scripts. Each one can set cookies, access browser storage, and transmit visitor data to external servers - often before your cookie banner has even rendered.
The CNIL made this point sharply in September 2025 when it fined SHEIN 150 million euros for, among other violations, loading cookies before users gave consent. That same month, Google received a 325 million euro fine for consent designs that steered users toward personalised advertising. Both cases involved third-party tracking mechanisms firing without proper authorisation. These enforcement actions confirm a pattern: data protection authorities hold the website operator responsible for every script running on the page, regardless of who wrote the code.
Under GDPR Article 28, a controller may only use processors providing "sufficient guarantees" of appropriate technical and organisational measures. That obligation extends to every analytics tag, advertising pixel, chat widget, and embedded video player on your site.
Step 1: Build a Complete Script Inventory
Before assessing risk, you need visibility. Open your browser's developer tools, load your website with cache cleared, and document every script that fires. Pay attention to the Network tab - many scripts load additional sub-resources that set their own cookies.
A cookie audit is the starting point. Automated scanning tools catch most scripts, but manual verification remains necessary for dynamically injected tags, especially those loaded through tag management containers.
Record these details for each script:
- Script source domain and provider name
- Cookies set (names, durations, purposes)
- Data transmitted (check request payloads in the Network tab)
- Whether the script loads additional sub-resources
- The lawful basis claimed for processing
Do not overlook scripts loaded through Google Tag Manager containers. A single GTM container can inject dozens of tags, each with its own data collection behaviour.
Step 2: Classify Each Vendor by Risk Level
Not all third-party scripts carry equal risk. A font loader that sets no cookies is fundamentally different from an advertising pixel that profiles visitors across the web. Classify each vendor into risk tiers to prioritise your assessment effort.
| Risk Tier | Script Type | Examples | Assessment Depth |
|---|---|---|---|
| High | Advertising, retargeting, social tracking | _fbp, _gcl_au, TikTok Pixel | Full DPA review, sub-processor audit |
| Medium | Analytics, session recording, A/B testing | _ga, _gid, Hotjar, Optimizely | DPA review, data flow mapping |
| Low | Functional, CDN, fonts, CAPTCHAs | Google Fonts, jQuery CDN, hCaptcha | Basic due diligence, privacy policy review |
| Essential | Payment, authentication, security | PHPSESSID, Stripe fraud cookies | DPA review, PCI compliance check |
High-risk vendors demand the most rigorous assessment. If a Meta Pixel or TikTok Pixel is transmitting visitor data to servers outside the EU, you need to verify that adequate transfer safeguards exist.
Step 3: Check Data Processing Agreements
Article 28 of the GDPR requires a binding contract between controller and processor. For third-party script vendors, this means a Data Processing Agreement (DPA) must be in place before the script goes live on your site.
Review each vendor's DPA for these minimum requirements:
- Subject matter, duration, nature, and purpose of processing are clearly defined
- The vendor processes data only on your documented instructions
- Confidentiality obligations bind all personnel with access to the data
- Technical and organisational security measures are specified
- Sub-processor engagement requires your prior written authorisation (specific or general)
- The vendor assists you with data subject rights requests
- Data deletion or return procedures at contract end are documented
- Audit rights are granted to the controller
Many large vendors publish standard DPAs on their websites. Google, Meta, and Microsoft all offer them. The problem is that website operators often never actually sign or accept these agreements. An unsigned DPA is the same as no DPA at all.
Step 4: Verify Sub-Processor Chains
A vendor rarely operates in isolation. Your analytics provider may use a cloud hosting service, a CDN, and a support platform - each one a sub-processor handling personal data from your visitors.
Under GDPR Article 28(2), processors must obtain your authorisation before engaging sub-processors. In practice, most vendors use "general written authorisation" with a notification mechanism: they maintain a sub-processor list and notify you before adding new ones.
Check whether each high-risk vendor publishes a sub-processor list, provides a notification mechanism for changes, and specifies the geographic locations where data is processed. Cross-border data transfers to countries without adequacy decisions require additional safeguards such as Standard Contractual Clauses.
Step 5: Validate Script Blocking Before Consent
A vendor may have a perfect DPA and robust security - but if their script fires before the visitor consents, none of that matters under the ePrivacy Directive. Article 5(3) of the ePrivacy Directive requires prior consent for storing or accessing information on a user's device, with narrow exceptions for strictly necessary processing.
For each non-essential script, verify that:
- The script is blocked by default until consent is granted
- Consent is granular - visitors can accept analytics without accepting advertising
- Rejecting consent actually prevents the script from loading (not just from setting cookies)
- Withdrawing consent removes existing cookies and stops future script execution
Test this rigorously. The CNIL's SHEIN enforcement action specifically cited cookies loading before consent as a violation. Use the browser's Network tab with cookies cleared to confirm that no non-essential requests fire before the visitor interacts with the banner.
The Vendor Risk Assessment Checklist
Use this checklist for each third-party script vendor. A "no" answer to any item in the high-risk category warrants immediate remediation or removal of the script.
| Category | Check | Pass/Fail |
|---|---|---|
| Inventory | Script purpose and all cookies documented | |
| Inventory | Data flow mapped (what data goes where) | |
| Legal | Signed DPA in place | |
| Legal | DPA covers all Article 28 requirements | |
| Legal | Sub-processor list available and reviewed | |
| Legal | International transfer safeguards verified | |
| Technical | Script blocked before consent by CMP | |
| Technical | Consent withdrawal stops script and clears cookies | |
| Technical | No data leakage before consent (verified in DevTools) | |
| Organisational | Vendor has a published privacy and security policy | |
| Organisational | Vendor breach notification process documented | |
| Organisational | Review schedule set (annual minimum) |
Ongoing Monitoring: Assessment Is Not a One-Off Task
Vendors update their scripts constantly. A tag that collected minimal data last quarter may now include new tracking parameters. Scheduled cookie scans catch these changes before regulators do.
Set a review cadence. High-risk vendors deserve quarterly reviews. Medium-risk vendors should be reviewed every six months. Low-risk vendors can be assessed annually, unless you receive a sub-processor change notification.
Document every assessment. If a data protection authority investigates your cookie practices, you will need to demonstrate that vendor due diligence is an ongoing process, not a box-ticking exercise completed once and forgotten. The evidence you prepare for a DPA investigation should include dated vendor assessment records alongside consent logs and banner screenshots.
Frequently Asked Questions
Do I need a data processing agreement for every third-party script?
If the script processes personal data on your behalf, yes. GDPR Article 28 requires a binding contract between controller and processor. Even scripts that only read cookie identifiers are processing personal data under GDPR definitions.
Who is responsible when a third-party script violates cookie consent rules?
The website operator bears primary responsibility. As the data controller, you chose to embed the script and must ensure it respects visitor consent choices. The CNIL's 2025 enforcement actions confirm that regulators fine the site operator, not the script vendor.
How often should I reassess third-party script vendors?
High-risk vendors (advertising, retargeting) should be reviewed quarterly. Medium-risk vendors (analytics, session recording) every six months. Low-risk vendors annually. Any sub-processor change notification from a vendor should trigger an immediate review.
What happens if a vendor refuses to provide a DPA?
Remove the script. Operating without a DPA for a processor that handles personal data is a direct violation of GDPR Article 28. Alternatives almost always exist - if your chat widget vendor will not sign a DPA, find one that will.
Can I rely on Google Tag Manager to block scripts before consent?
GTM provides consent initialisation triggers, but you must configure them correctly. A misconfigured GTM container can fire tags before consent. Test thoroughly by checking the Network tab in browser developer tools with cookies cleared.
Are essential cookies exempt from vendor risk assessment?
Essential cookies are exempt from consent requirements under the ePrivacy Directive, but they are not exempt from GDPR obligations. You still need a DPA with the vendor, and the processing must align with the purposes stated in your privacy policy.
Take Control of Your Cookie Compliance
If you are not sure which cookies your site sets, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie - so your visitors get a clear choice, and you stay on the right side of the law.
