GDPR and Web Application Security: What EU SaaS Companies Actually Need

GDPR has been in force since 2018. Most European SaaS companies have a privacy policy, a cookie banner, and some kind of data processing agreement template. Many of them have never tested whether their web application is actually secure.

That's a compliance gap — and increasingly, it's an enforcement gap. Data protection authorities across the EU have made clear that Article 32 (security of processing) is not satisfied by documentation alone. If you process personal data through a web application, you need to demonstrate that the application is technically secure.

This guide covers what GDPR actually requires for web application security, how regulators have interpreted those requirements in enforcement actions, and what a practical compliance program looks like.

What GDPR Actually Says About Security

The core obligation is Article 32:

"The controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk."

Article 32 then lists examples of such measures:

• Pseudonymisation and encryption of personal data
• Ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems
• Ability to restore availability and access to personal data in a timely manner after an incident
• "A process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures for ensuring the security of processing"

That fourth bullet is the one most SaaS companies overlook. GDPR doesn't just require you to implement security controls — it requires you to have a process to regularly test whether those controls are working.

What "Appropriate" Means in Practice

GDPR doesn't specify which controls are required. "Appropriate to the risk" means the measures must be proportional to:

• The nature of the personal data being processed (health data carries higher risk than email addresses)
• The number of data subjects affected
• The likelihood and severity of risks to individuals
• The state of the art — what current best practice looks like

For a web application processing personal data, "state of the art" is generally interpreted to include at minimum:

How Regulators Have Interpreted Security Requirements

Enforcement actions provide the clearest signal of regulatory expectations. Several cases are instructive:

British Airways (ICO, 2020, £20 million)

British Airways was breached through a Magecart-style attack: attackers injected skimming code into their booking website, harvesting approximately 400,000 customers' payment card details. The ICO found that BA had failed to implement appropriate technical measures — specifically, the attack could have been prevented or detected with basic security controls that were "well understood within the industry."

Lesson: The standard is not perfection. It's whether you implemented controls that a reasonable operator in your sector would have in place. Failing to have those basics is itself a GDPR violation.

Marriott International (ICO, 2020, £18.4 million)

Marriott's breach stemmed from the Starwood acquisition — attackers had been inside Starwood's systems for years before the acquisition, and Marriott failed to perform adequate due diligence on the acquired systems' security posture. The ICO found that Marriott should have done more to verify the security of Starwood's systems.

Lesson: You're responsible for the security of systems you operate, even if the initial compromise preceded your ownership.

Dutch AP enforcement (2021-2023)

The Dutch Data Protection Authority (Autoriteit Persoonsgegevens) has issued several fines for inadequate security of web portals handling personal data, including cases where:

• Authentication systems didn't enforce multi-factor authentication for access to sensitive data
• Old, unpatched web application frameworks were still serving production traffic
• Security testing hadn't been conducted in over two years

Lesson for Dutch companies: The AP has demonstrated it will act on technical security gaps, not just process failures.

The Web Application Security Controls You Need

Working backwards from enforcement patterns and Article 32 requirements, here's what a GDPR-appropriate web application security program looks like for a SaaS company processing personal data:

1. Encryption in Transit

All communication between users and your application must use HTTPS. Not some pages — all pages, all endpoints, all APIs.

• TLS 1.2 minimum; TLS 1.3 preferred. Disable TLS 1.0 and 1.1.
• HSTS (Strict-Transport-Security) header with a minimum max-age of one year
• Valid certificate with proper chain — let it expire and you're both technically non-compliant and operationally embarrassing
• Strong cipher suites — no RC4, no export ciphers, no CBC with MD5/SHA-1 in TLS 1.2

2. Authentication Security

Weak authentication is one of the most common routes to personal data exposure.

• Multi-factor authentication for any access to administrative functions or sensitive personal data
• Passwords stored with a modern hashing algorithm: bcrypt, scrypt, or Argon2 — never MD5 or SHA-1
• Rate limiting on login endpoints to prevent brute-force and credential stuffing
• Session invalidation on logout — sessions should not remain valid after a user logs out
• Session tokens must be cryptographically random and have appropriate expiry

3. Input Validation and Injection Prevention

SQL injection and cross-site scripting vulnerabilities have directly led to GDPR enforcement actions — they're the technical mechanism through which personal data gets exposed.

• Parameterized queries for all database operations — never concatenate user input into SQL strings
• Output encoding to prevent XSS — treat all user-controlled data as untrusted when rendering it
• Content Security Policy headers to limit XSS impact
• Validation of all input at the server side — client-side validation is convenience, not security

4. Security Headers

HTTP security headers are low-effort, high-signal security controls. Their absence is easily detected by automated tools and regulators.

• Strict-Transport-Security — force HTTPS
• Content-Security-Policy — restrict which resources can load
• X-Content-Type-Options: nosniff — prevent MIME-type sniffing
• X-Frame-Options: DENY or SAMEORIGIN — prevent clickjacking
• Referrer-Policy — control what URL information is sent in Referer headers (prevent leaking personal data in URLs)
• Permissions-Policy — restrict browser features (camera, microphone, geolocation)

5. Dependency Management

Outdated software with known vulnerabilities is a consistent factor in breaches. GDPR's requirement to implement "state of the art" security includes keeping software current.

• Regular updates for web frameworks, CMS platforms, and libraries
• Monitoring CVE feeds for the technologies you use
• A documented process for applying security patches — ideally within days of critical CVE disclosure, not months

6. Regular Security Testing

This is the one most often missing. Article 32(1)(d) explicitly requires "a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures." Having a security policy document doesn't satisfy this — you need evidence of actual testing.

A defensible testing program includes:

• Continuous automated scanning — regular automated scans that catch new vulnerabilities as code changes
• Annual penetration testing — by an external professional, with a written report documenting findings and remediation
• Evidence of remediation — test reports showing findings were addressed, not just identified

What to Prepare for a Data Protection Authority Audit

If your organization is audited by a DPA for security compliance, the documentation they typically request includes:

1. Records of Processing Activities (RoPA) — required under Article 30; should include the security measures in place for each processing activity
2. Security policy documentation — what controls you have and how they're managed
3. Penetration test reports — ideally with remediation documentation showing findings were addressed
4. Vulnerability scan records — evidence of ongoing monitoring, not just point-in-time assessments
5. Incident log — record of any security incidents, how they were handled, and whether they triggered Article 33 breach notification
6. DPO correspondence (if applicable) — documentation that security concerns raised by the DPO were addressed

The consistent theme across DPA audit guidance is that you need to be able to show that security is an ongoing practice, not something you did once and forgot about.

The Gap Most EU SaaS Companies Have

Privacy programs at European SaaS companies typically look like this: legal and compliance teams have built solid documentation — privacy notices, DPA templates, cookie policies, RoPA entries. The process side is covered.

The technical side is where gaps appear. Engineering teams know they should be doing regular security testing but haven't built a consistent program. They run a pentest when they're asked to by an enterprise customer, then file the report and move on. Automated security scanning gets added to a backlog and never prioritized.

The result is a compliance posture that looks fine on paper — policies, documentation, a pentest report from 18 months ago — but wouldn't survive scrutiny if a breach occurred and a DPA asked to see the testing records for the past year.

The practical fix is straightforward: implement continuous automated security scanning as the baseline, supplement with annual manual penetration testing, and keep records. The scanning gives you ongoing evidence of a testing process; the pentest provides the expert review that automated tools can't replicate.