GDPR Article 32 requires organizations processing personal data to implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk. For websites that collect personal data — which includes virtually any site with a contact form, user account, newsletter signup, or analytics — this has direct implications for how the site is built and maintained. This guide explains what Article 32 means concretely for web applications.
What Article 32 Requires
The regulation lists four specific measures that must be considered:
- Pseudonymisation and encryption of personal data — for web applications, this means HTTPS/TLS for data in transit and encrypted storage for data at rest
- Ongoing confidentiality, integrity, availability and resilience of processing systems — the website and its data must be protected against unauthorized access, modification, and loss
- Ability to restore availability and access in the event of a physical or technical incident — backup and recovery capabilities
- Process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures — this is the requirement that makes vulnerability scanning directly relevant
The phrase "appropriate to the risk" is key: a children's health platform has higher obligations than a hobby blog, because the risk to data subjects (the people whose data is processed) is higher.
What "Appropriate Technical Measures" Means for Web Applications
Encryption in Transit (TLS/HTTPS)
Any personal data transmitted between the user's browser and your server must be encrypted. This means HTTPS with a valid TLS certificate is not optional — it is an Article 32 requirement for any site that collects personal data. This includes login pages, contact forms, newsletter signups, and any page where personal data is entered.
Protection Against Injection and XSS
A SQL injection vulnerability that allows an attacker to extract your user database is a direct Article 32 failure — the confidentiality and integrity of personal data was not protected. Similarly, an XSS vulnerability that allows an attacker to steal session cookies (and thereby impersonate users) is an Article 32 violation. These are not abstract risks: they are the most common root causes of breaches that trigger GDPR notifications.
Access Control
Personal data should only be accessible to users and systems authorized to access it. Insecure Direct Object References (IDOR) — where a user can access another user's data by modifying a URL parameter — is a direct Article 32 failure. Admin interfaces must require authentication and must not be exposed without protection.
Session Security
Session cookies without the Secure flag can be transmitted over HTTP and intercepted. Cookies without HttpOnly can be stolen via XSS. Weak session management directly undermines the confidentiality requirement of Article 32.
Regular Testing and Assessment
Article 32(1)(d) specifically requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures." This is the direct mandate for vulnerability scanning as a compliance activity — not just as a security best practice, but as a GDPR requirement.
The GDPR Breach Notification Context
Under Article 33, a personal data breach must be notified to your supervisory authority within 72 hours. Under Article 34, affected individuals must be notified if the breach is likely to result in high risk to their rights and freedoms. When a Data Protection Authority (DPA) investigates a breach, they examine what technical measures were in place and whether they were "appropriate to the risk."
Organizations that can demonstrate: (a) they conducted regular vulnerability scans, (b) they remediated findings, and (c) the breach occurred despite those measures — are in a significantly stronger position than organizations that took no documented security steps. Documented, timestamped scan reports are evidence of proactive security measures.
How Shieldome Checks This
Shieldome's checks map directly to Article 32's requirements for web applications:
| Article 32 Requirement | Shieldome Check |
|---|---|
| Encryption in transit (Art. 32(1)(a)) | HTTPS enforcement, TLS version (flags 1.0/1.1), certificate validity and expiry, HSTS header |
| Confidentiality of personal data | SQL injection indicators, XSS reflection detection, sensitive file exposure (could expose user data) |
| Access control | Probes for unprotected admin paths, checks CORS configuration that could allow unauthorized cross-origin data access |
| Session security | HttpOnly and Secure flags on session cookies, SameSite attribute |
| Regular testing (Art. 32(1)(d)) | Timestamped PDF scan reports serve as documented evidence of the testing process |
| Server component security | Server version disclosure detection — helps identify when components need updating |
A Shieldome PDF report, with its scan timestamp and domain, is evidence of an Article 32(1)(d) technical measure. When stored and dated regularly, a history of Shieldome scans demonstrates an ongoing testing process — exactly what GDPR requires and what DPAs look for in breach investigations.
Special Considerations for European Organizations
The GDPR applies to any organization that processes personal data of EU residents — regardless of where the organization is located. A US company with European customers falls under GDPR. Key national regulators (CNIL in France, ICO in the UK post-Brexit, BfDI in Germany, Datatilsynet in Denmark/Norway) all enforce similar standards, with fines up to 4% of global annual turnover or €20 million, whichever is higher.
NIS2 (Network and Information Systems Directive 2.0), effective from October 2024, adds additional security requirements for organizations in critical sectors and digital infrastructure. NIS2 Article 21 explicitly requires vulnerability scanning and patch management as part of cybersecurity risk management measures.
Frequently Asked Questions
Does GDPR require a specific security standard like ISO 27001?
No — GDPR is principles-based, not prescriptive. Article 32 says "appropriate measures" rather than mandating a specific certification. However, ISO 27001 certification and documented vulnerability scanning programs serve as strong evidence of compliance with Article 32's requirements.
What counts as a personal data breach under GDPR?
Any breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. This includes: a hacked database, a SQL injection that exposed user records, an XSS attack that stole session tokens, or a misconfigured cloud storage bucket exposing user files.
Do I need to notify users after every vulnerability discovery?
No — vulnerability discovery is not a breach. A breach occurs when personal data is actually accessed, disclosed, or lost. Discovering and fixing a vulnerability before it is exploited is exactly the right outcome and requires no notification. This is another reason to scan regularly: find issues before attackers do.
Is a contact form enough to trigger GDPR obligations?
Yes. A contact form collects a name and email address — both personal data under GDPR. If you process EU residents' data via that form, GDPR applies. Your website must have a Privacy Policy, a lawful basis for processing, appropriate security measures (Article 32), and a process for responding to data subject requests.
How do I demonstrate GDPR compliance to a DPA?
Documentation is key: Privacy Policy, Records of Processing Activities (ROPA), Data Processing Agreements with third parties, and evidence of technical measures including vulnerability scan reports. A DPA investigation following a breach will ask for exactly these documents.
What is the GDPR fine for a website security breach?
Fines for Article 32 violations (failure to implement appropriate technical measures) can reach €10 million or 2% of global annual turnover, whichever is higher. In practice, DPAs consider factors including the severity of the breach, cooperation with the investigation, and the measures in place at the time of the breach.
GDPR compliance starts with knowing your technical security posture. Run a free Shieldome scan and get a timestamped, PDF-exportable report that serves as direct evidence of your Article 32 technical measures — and identifies what needs to be fixed before it becomes a breach.