GDPR Website Security: The Technical Requirements You're Missing

The General Data Protection Regulation requires "appropriate technical and organisational measures" to protect personal data. That phrase — appropriate technical measures — is deliberately vague. The regulation doesn't prescribe specific technologies, firewall rules, or encryption standards. Instead, enforcement actions and regulatory guidance have gradually defined what "appropriate" means in practice. For website operators, the bar is higher than most realise.

What "Appropriate Technical Measures" Means in Practice

GDPR Article 32 lists four categories of security measures: pseudonymisation and encryption, confidentiality and integrity, availability and resilience, and regular testing and evaluation. Regulatory enforcement has translated these into concrete website security requirements:

• Encryption in transit: TLS is mandatory for any site that processes personal data. Multiple enforcement actions have cited the absence of HTTPS as a technical measure failure. Not just any TLS — regulators expect current protocol versions (TLS 1.2 minimum, TLS 1.3 preferred) with strong cipher suites.
• Encryption at rest: Personal data stored in databases should be encrypted. This includes backups, logs, and any data export mechanisms.
• Access control: Authentication and authorisation mechanisms must ensure only authorised personnel access personal data. Default credentials, shared accounts, and overly broad access are all cited in enforcement actions.
• Security headers: While not explicitly named in the regulation, enforcement guidance references security headers as part of web application hardening. CSP, HSTS, and X-Content-Type-Options prevent attacks that lead to data breaches — which are GDPR violations.

The Enforcement Precedents

GDPR fines provide the clearest guidance on what regulators consider inadequate. Notable technical security-related fines include:

• British Airways (£20 million): Inadequate security measures allowed a Magecart-style attack that compromised 429,612 customer records. The ICO specifically cited failure to implement CSP, inadequate access controls, and insufficient monitoring.
• Marriott (£18.4 million): Insufficient security measures in the Starwood database led to exposure of 339 million guest records. The fine cited failure to implement adequate encryption, access controls, and monitoring.
• H&M (€35.3 million): Excessive data collection combined with insufficient access controls. Employees had broad access to personal information without legitimate business need.

The pattern is consistent: regulators don't just penalise data breaches — they penalise the security failures that enabled them. Insufficient technical measures that exist before any breach occurs are themselves a GDPR violation.

Data Protection Impact Assessments

Article 35 requires a Data Protection Impact Assessment (DPIA) for processing that's "likely to result in a high risk" to individuals. For websites, high-risk processing includes large-scale profiling, automated decision-making, and processing sensitive categories of data. The DPIA must describe the technical security measures implemented — and justify why they're adequate.

A DPIA that says "we use HTTPS" without addressing security headers, cookie security, email authentication, and input validation is incomplete. Regulators increasingly expect detailed technical documentation that demonstrates defence-in-depth.

The Cookie Compliance Intersection

Cookie security attributes intersect directly with GDPR requirements. Session cookies containing personal data (which session identifiers arguably are, since they link to a person's data) must be protected with appropriate technical measures. This means:

• Secure flag: Prevents transmission over unencrypted connections
• HttpOnly flag: Prevents JavaScript access, mitigating XSS-based theft
• SameSite attribute: Prevents cross-site request forgery

Missing these attributes means personal data (the session) is transmitted insecurely or accessible to malicious scripts — both failures of "appropriate technical measures."

The Right to Security

GDPR creates a legal right to security for individuals whose data you process. This isn't aspirational — it's enforceable. Individuals can lodge complaints with supervisory authorities, and authorities can audit your technical measures at any time, not just after a breach.

The practical implication is that security isn't just a technical concern — it's a legal obligation with financial penalties that can reach 4% of global annual revenue or €20 million, whichever is higher. Every missing security header, every weak TLS configuration, every insecure cookie attribute is potential evidence of non-compliance.

Documentation as Compliance

Article 5(2) establishes the accountability principle: you must be able to demonstrate compliance. This means documenting your technical security measures, regularly testing them, and maintaining records of remediation. A security scan report that shows your current posture, identifies gaps, and tracks improvements over time is direct compliance evidence.

ShieldReport generates comprehensive security reports that document your domain's technical security posture — the exact evidence regulators request when evaluating GDPR compliance, demonstrating your commitment to appropriate technical measures in a format that non-technical stakeholders understand.