GDPR Article 32 Web Compliance — WebAudit Check Mapping

What is GDPR Article 32?

The General Data Protection Regulation (GDPR) Article 32 requires controllers and processors to implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk of processing personal data. The article lists specific measures including:

"(a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures."

GDPR applies to any organisation processing personal data of EU/EEA residents — regardless of where the organisation is based. This includes Indian SaaS companies with EU users, e-commerce stores shipping to Europe, and any website using EU-based analytics or advertising cookies.

Fines: Maximum administrative fines under GDPR are €20 million or 4% of global annual turnover (whichever is higher). The EU-India adequacy decision remains pending; Indian companies rely on Standard Contractual Clauses (SCCs) for data transfers.

OWASP Top 10 PCI-DSS v4.0 GDPR Art. 32 ISO 27001:2022

Requirements WebAudit checks

32(1)(a) Encryption of Personal Data in Transit

Article 32(1)(a) explicitly names encryption as a required technical measure. For web applications, this means all personal data — including session tokens, form submissions, and any identifiers — must be transmitted exclusively over encrypted channels. HSTS prevents the initial unencrypted request that would expose session cookies to a network observer before the HTTPS redirect.

TLS valid HSTS present Cookies Secure flag

Fix: Enforce HTTPS on all endpoints. Deploy Strict-Transport-Security: max-age=31536000; includeSubDomains. Set the Secure flag on all cookies containing session identifiers or personal data to ensure they are never transmitted over HTTP.

32(1)(b) Ongoing Confidentiality and Integrity

Ongoing confidentiality means preventing unauthorised access to or modification of personal data. At the transport layer, this requires preventing content injection (CSP), MIME confusion (X-Content-Type-Options), and server version disclosure that aids targeted attacks. Mixed content on HTTPS pages means some resources are loaded without encryption, directly undermining confidentiality.

CSP present X-Content-Type-Options No server fingerprint No mixed content

Fix: Deploy a Content-Security-Policy to prevent content injection. Set X-Content-Type-Options: nosniff. Remove Server and X-Powered-By version strings. Ensure all subresources on HTTPS pages are also served over HTTPS.

32(1)(c) Resilience and Availability

Ability to restore availability of personal data after an incident. While full resilience is largely an infrastructure concern, DNS security directly supports this: CAA records prevent rogue certificate issuance (which could enable impersonation and data interception), and SPF/DMARC prevent email spoofing that could redirect users to phishing sites — compromising their ability to access your service and their personal data.

DNS CAA present SPF present DMARC present

Fix: Publish CAA DNS records to restrict which certificate authorities may issue certificates for your domain. Configure SPF (v=spf1 include:... -all) and DMARC (p=quarantine or p=reject) to prevent email spoofing that could be used for phishing attacks targeting your users.

32(1)(d) Regular Testing and Assessment

A process for regularly testing, assessing, and evaluating the effectiveness of security measures. At the technical level, this includes enforcing DMARC with action (not just monitoring with p=none), setting Referrer-Policy to prevent personal data leakage in HTTP referer headers to third parties, and Permissions-Policy to limit browser API access. Regular automated scanning (such as WebAudit) provides evidence of ongoing assessment.

DMARC enforced (p=quarantine/reject) Referrer-Policy Permissions-Policy

Fix: Upgrade DMARC policy from p=none to p=quarantine or p=reject to enforce email authentication. Set Referrer-Policy: strict-origin-when-cross-origin to prevent URL paths (which may contain personal data) from leaking to third parties. Set Permissions-Policy to restrict unnecessary browser APIs.

The "appropriate measures" principle

GDPR Article 32 does not prescribe specific technical standards — it uses the principle of appropriateness, considering the state of the art, costs, nature of processing, and risk. The controls WebAudit checks represent the current baseline for web applications:

DPAs (Data Protection Authorities) across the EU have consistently found that failing to implement HTTPS, HSTS, and security headers constitutes a failure to implement appropriate technical measures. The Dutch DPA, French CNIL, and German BSI have all referenced these specific controls in enforcement guidance.

Running regular security scans and retaining the results as evidence is itself a demonstration of the Article 32(1)(d) assessment process. The WebAudit compliance PDF provides a dated, domain-specific record suitable for DPA inquiries or DPA audit packages.

Get your GDPR Article 32 compliance report

Instant PDF documenting which Article 32 technical requirements your domain satisfies — suitable for DPA evidence packages and vendor security questionnaires.

Generate compliance PDF → Free scan first