Why paperwork alone does not protect you
Many companies treat GDPR compliance as a folder. Get the DPA signed by every provider, file it, done. The folder is real and you do need it, but it is not what stops an attack.
Article 32 of GDPR asks for “appropriate technical and organisational measures”. The wording matters. Technical measures means actual configuration on your site, not contracts about configuration. If your provider has a signed DPA but a hacked script on your checkout page reads your customers’ card numbers, the contract does not undo what happened.
A useful way to think about it: the DPA is your legal cover if everyone did their job. The configuration of your site is what stops the bad day from happening in the first place.
What auditors actually look at now
Recent rulings show data protection agencies have stopped accepting “we did not know this could be hacked”. When they audit, they ask three questions:
- Did you check your provider before integrating them, or just sign the contract?
- Are basic browser-side protections turned on (CSP, security headers)?
- Would you notice if data started leaking right now?
If the answer to any of those is no, the DPA does not save you.
Supply chain attacks: the real threat in 2026
Your servers can be perfect. Your own code can be reviewed line by line. And you can still get hit by a supply chain attack.
Here is how it works. You load a script from an analytics tool, a chat widget, an A/B testing library. That script runs in your users’ browsers with the same access as your own code. If someone compromises the script’s source (the company that ships it, their CDN, their build pipeline), they can change what runs on your site without touching your servers.
The classic example is Magecart. Attackers swapped a payment-form script with a version that quietly copied card numbers to a server they controlled. British Airways, Ticketmaster, Newegg. Same pattern, different victims.
What can a hacked third-party script do?
- Read keystrokes in your forms
- Steal session cookies and tokens
- Send any DOM content to an attacker server
- Inject hidden iframes for further attacks
If this happens, the question from the supervisory authority will be: what did you do to prevent the third-party script from reading your users’ data? “We trusted the vendor” is not an answer that helps.
Two practical defences: SRI and CSP
You do not need a security team to apply these. You need an afternoon.
Subresource Integrity (SRI)
SRI is a hash check the browser does for you. When you load an external script, you give the browser the expected hash of the file. If the file has changed even by one byte, the browser refuses to run it.
<script
src="https://cdn.example.com/widget.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>The catch: the vendor has to give you a stable file. Many CDN scripts change frequently, which breaks SRI on purpose. For those, you self-host a known version, generate the hash, and update on your own schedule.
Content Security Policy (CSP)
CSP is a header that tells the browser where scripts are allowed to come from and, more importantly, where they are allowed to send data. Even if a script is compromised and tries to exfiltrate to attacker.com, a strict CSP blocks the request.
A starting point looks like this:
Content-Security-Policy:
default-src 'self';
script-src 'self' https://cdn.trusted-vendor.com;
connect-src 'self' https://api.trusted-vendor.com;
frame-ancestors 'none';Start in report-only mode (Content-Security-Policy-Report-Only), watch what breaks for a week, then enforce. Going straight to enforcement on a live site usually breaks something visible.
What recent fines actually punish
There is a real €3.2 million fine against a retailer in 2025 that gets cited a lot. Reading the resolution, the fine was not for “having a breach”. It was for the pattern around the breach:
- Attackers were inside for weeks before anyone noticed
- Admin panels had no MFA, only passwords
- Known vulnerabilities sat unpatched for months
- No log review, no alerting on unusual traffic
The lesson is not “fines are scary”. The lesson is that an audit looks at process, not just outcomes. A company that detects an incident in two hours and contains it gets very different treatment from one that finds out from a journalist three months later.
A short list of habits that actually move the needle
Forget the four-step methodology for a moment. If you do these things you are ahead of most sites:
- Inventory your third-party scripts. Know what runs on your pages and why. Remove what you do not use.
- Pin versions and use SRI for anything you can self-host or whose vendor publishes stable files.
- Run a CSP, even a basic one. Start with report-only.
- Turn on MFA for every admin panel, hosting account, DNS provider, and CI/CD system.
- Read your access logs at least weekly, or set up basic alerting (Cloudflare and most CDNs have free tools for this).
- Patch on a schedule, not “when we get to it”. Security updates within a week, others monthly.
You can read related practical guides on this site: Cookie Banner Best Practices and Global Privacy Control (GPC).
Frequently asked questions
Is HTTPS enough to comply with Article 32? No. HTTPS encrypts the connection between browser and server. It does nothing about what happens inside the browser, where most modern attacks live. You still need CSP, SRI, MFA, monitoring, and a properly configured HSTS header to prevent SSL stripping.
Are external analytics scripts dangerous? They can be. Anything you load from a third party runs with full access to the page. The risk is not the vendor being malicious, it is the vendor being compromised. CSP limits where their script can send data, which is the main defence.
Why use SRI if the vendor seems reliable? SRI is not a comment on the vendor. It is a check that the file you got is the file you expected. Compromises happen at the CDN level, at the build pipeline, sometimes through a single developer’s stolen credentials. SRI catches the change without you having to spot it.