GDPR-ready hosting
for data controllers.
Data protection by design isn’t a checkbox — it’s an infrastructure decision. Our technical measures satisfy Article 32 obligations so your DPA documentation writes itself.
What the GDPR
actually demands.
The General Data Protection Regulation (EU 2016/679) imposes obligations on any organization processing personal data of EU residents. For infrastructure hosting, the critical articles are Article 25 (data protection by design and by default), Article 32 (security of processing), Article 33 (breach notification), and Article 28 (processor obligations).
Article 32(1) requires controllers and processors to implement “appropriate technical and organisational measures” including: (a) pseudonymisation and encryption of personal data, (b) ongoing confidentiality, integrity, availability and resilience of processing systems, (c) the ability to restore access to data in a timely manner, and (d) a process for regularly testing and evaluating effectiveness of measures.
Supervisory authorities have consistently held that “appropriate” means proportionate to the risk — and that organizations must demonstrate they’ve actually assessed what’s appropriate, not merely asserted it. Fines under Article 83(4) reach €10 million or 2% of global turnover for security failures.
PrismWeb’s sixteen checks provide the technical measures that Article 32 requires, continuously verify they’re operating (satisfying Article 32(1)(d)), and produce the documentation your Data Protection Officer needs for accountability under Article 5(2).
How PrismWeb maps to
GDPR requirements.
| Check | GDPR Article | Obligation |
|---|---|---|
| DNSSEC | Art. 32(1)(b) | Integrity of processing systems |
| SSL/TLS | Art. 32(1)(a), Art. 25(1) | Encryption, Data protection by design |
| Enhanced HTTPS | Art. 32(1)(a), Art. 25(1) | Encryption, Data protection by design |
| Enhanced TLS | Art. 32(1)(a) | Encryption of personal data |
| Certificate Validation | Art. 32(1)(a), Art. 32(1)(b) | Encryption integrity, Confidentiality |
| Security Headers | Art. 25(1), Art. 32(1)(b) | Data protection by design, Integrity |
| SPF | Art. 32(1)(b) | Integrity of communications |
| DKIM | Art. 32(1)(b) | Integrity of communications |
| DMARC | Art. 32(1)(b), Art. 32(1)(d) | Integrity, Testing effectiveness |
| MTA-STS | Art. 32(1)(a) | Encryption of personal data in transit |
| TLS-RPT | Art. 32(1)(d) | Testing and evaluating effectiveness |
| IP Abuse | Art. 32(1)(b), Art. 33 | Resilience, Breach detection |
| WordPress Detection | Art. 32(1)(b), Art. 32(1)(d) | Resilience, Testing effectiveness |
| Website Scanning | Art. 25(2), Art. 32(1)(d) | Data protection by default, Testing |
| IPv6 | Art. 32(1)(b) | Availability and resilience |
| RPKI | Art. 32(1)(b) | Integrity of network routing |
What your DPO
can document.
A complete inventory of technical measures implemented, mapped to each Article 32(1) sub-requirement. Ready for inclusion in your ROPA (Record of Processing Activities) and DPA annexes.
Pre-written technical and organizational measures (TOMs) for DPA Annex II, describing how we protect personal data as a processor under Article 28.
Continuous check results demonstrating that Article 32(1)(d) — regularly testing and evaluating the effectiveness of technical measures — is happening automatically, not annually.
Continuous monitoring enables rapid breach detection, supporting the 72-hour notification requirement under Article 33. You can’t notify within 72 hours if you don’t detect within 72 hours.
Evidence demonstrating compliance with Article 5(2) accountability principle. Not just what measures you have, but proof they’re operating — which is what supervisory authorities actually request.
Data protection by design
not by declaration.
Supervisory authorities don’t accept “we have a policy.” They want evidence of implementation. Our infrastructure produces it continuously.