Why security SaaS has a harder GDPR problem than most SaaS
Security tooling processes a specific category of data that most SaaS does not: information about vulnerabilities in customer systems. When AssurePort runs a Web Pentest, the scan output contains findings about the customer’s production infrastructure, authentication flows, and data handling patterns. This is not employee names and email addresses — it is a map of exploitable weaknesses in a system that processes its own users’ personal data.
Under GDPR, this creates a layered data processing relationship. AssurePort is a data processor for the customer (processing scan metadata and results). The customer is a data controller for their end users. The security findings we generate describe technical characteristics of systems that handle personal data — which means the findings themselves may be considered sensitive business information subject to confidentiality obligations, even if they are not “personal data” in the Article 4(1) sense.
EU procurement teams, especially in financial services, healthcare, and public sector, have started treating this complexity seriously. Here is what they are now consistently asking for.
The seven things EU enterprise customers ask for in 2026
GDPR compliance checklist for security SaaS vendors
- Article 30 Record of Processing Activities (RoPA). A documented record of what personal data you process, for what purpose, under what legal basis, with what retention period. Procurement teams ask to see it or ask you to confirm its existence in a questionnaire.
- Data Processing Addendum (DPA) — both directions. You need a DPA as a data processor (from the customer). You also need DPAs with every sub-processor you use (Cloudflare, Fly.io, Anthropic, Resend, Polar.sh). Customers ask for your sub-processor list and evidence that DPAs are in place.
- Article 13/14 transparency notice. A privacy notice that accurately describes what you collect at account creation (name, email, company), what you collect during scans (target URLs, scan results, IP addresses contacted), and how long you retain each category. “We collect minimal data” is not sufficient.
- Article 32 technical measures documentation. Encryption in transit and at rest, access controls, audit logging, vulnerability management process, incident response capability. Not just a statement that you have them — a description of what they are.
- Article 35 DPIA for high-risk processing. If your product processes personal data at scale or in a novel way, a Data Protection Impact Assessment may be required. Security tooling that processes scan targets may qualify as high-risk processing under Article 35(3) because it systematically evaluates aspects of systems that handle personal data.
- 72-hour breach notification runbook. GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. Customers want to know you have a documented process, not just an intent to comply.
- International transfer mechanism. If any personal data transfers outside the EEA (for example, to an AI model provider with US infrastructure), you need either SCCs, adequacy decision, or binding corporate rules. Customers ask which mechanism applies to each sub-processor.
Article 32: the technical measures question in practice
Article 32 requires “appropriate technical and organisational measures” proportionate to the risk. For security SaaS, this is where the technical architecture directly feeds the compliance case. The measures that matter:
- Encryption at rest: Cloudflare D1 and R2 encrypt data at rest by default. This is a documented Cloudflare commitment, auditable via their security documentation.
- Encryption in transit: All AssurePort endpoints enforce HTTPS with TLS 1.2+. Cloudflare handles certificate management and HSTS for the API surface.
- Access controls: Multi-tenant isolation enforced at the D1 query layer (tenant_id filter on all data access queries). OTP + optional TOTP 2FA for authentication.
- Audit logging: All scan events, billing events, and auth events are logged with timestamps in D1. Logs are append-only (no UPDATE operations on ledger tables).
- Vulnerability management: Self-pentest cycle (described in our transparency post). Findings tracked and remediated with documented timelines.
The AI Act shadow: The EU AI Act (fully applicable August 2026) introduces additional obligations for AI systems used in security-sensitive contexts. Systems that make automated decisions affecting individuals may qualify as high-risk AI. AssurePort’s pentest pipeline produces findings that humans review and act on — it is not an automated decision-making system under Article 22 GDPR. But the AI Act’s transparency and documentation requirements will affect how we describe the AI layer to enterprise customers. We are monitoring this actively.
What a DPIA looks like for a security scanning product
Article 35 requires a DPIA when processing is “likely to result in a high risk to the rights and freedoms of natural persons.” The three categories that trigger mandatory DPIA are:
- Systematic and extensive evaluation of personal aspects of natural persons (profiling)
- Processing of special category data at large scale
- Systematic monitoring of a publicly accessible area at large scale
AssurePort does not profile natural persons. We scan URLs and API endpoints that our customers authorise us to test. The scan results describe technical characteristics of systems, not attributes of individuals. On a strict reading of Article 35, mandatory DPIA may not apply. However, we have conducted a voluntary DPIA because:
- Our scans interact with systems that process personal data
- The scan output may reveal information about how personal data is protected (or not) in customer systems
- Enterprise customers increasingly ask for DPIA documentation as part of procurement
The DPIA is available to customers under NDA through the Trust Center.
The AssurePort compliance stack (what we can show you)
For customers going through security questionnaires, here is what is available:
- DPA: Available at /legal/dpa.html, GDPR Article 28 compliant, includes SCCs for international transfers
- Sub-processor list: Published at /trust, updated after any change to the sub-processor chain
- Privacy notice: /legal/privacy.html, Article 13/14 compliant
- Security controls: /trust (Trust Center security controls page)
- Self-pentest findings: Published on the security disclosure page after each cycle
- DPIA: Available to enterprise customers under NDA on request
- Incident response runbook: Available at Trust Center (authenticated access)
For questions not covered by the public documentation, the fastest path is security@assureport.com or the feedback form.
Why 2026 raised the stakes on GDPR paperwork
Procurement teams did not tighten their questionnaires by accident. Enforcement has climbed sharply. Public data from the GDPR Enforcement Tracker shows cumulative fines passing 7.1 billion euros since 2018, with roughly 1.2 billion euros issued in 2025 alone. The two largest categories of violation are unlawful processing under Article 6 and inadequate technical and organisational measures under Article 32 — the exact areas a security-tooling vendor touches.
The enforcement pattern also punctures a common assumption. Regulators do not only pursue large technology firms; a meaningful share of penalties lands on regional providers and smaller SaaS companies. A vendor that cannot produce a DPA, a RoPA or a clear Article 32 description is not merely losing a deal on paperwork — it is carrying real regulatory exposure. Treat the checklist above as risk reduction, not sales friction.
Frequently Asked Questions
Does a SaaS company need a Data Processing Agreement under GDPR?
Yes. GDPR Article 28 requires a data processing agreement whenever one party processes personal data on behalf of another. A SaaS vendor acts as a processor for its customers and must sign a DPA with each customer, and it must also hold DPAs with every sub-processor it relies on, such as its cloud, email and AI providers.
What technical measures does GDPR Article 32 require?
Article 32 requires technical and organisational measures appropriate to the risk. In practice that means encryption in transit and at rest, access controls with tenant isolation, append-only audit logging, a vulnerability management process and a tested incident response capability. Procurement teams want a description of each control, not just a statement that they exist.
When is a DPIA mandatory for a SaaS product?
Article 35 makes a Data Protection Impact Assessment mandatory when processing is likely to result in a high risk to individuals, including large-scale profiling, large-scale processing of special category data, or systematic monitoring of a public area. Many vendors also run a voluntary DPIA because enterprise buyers increasingly request the documentation during procurement.
How large are GDPR fines in practice?
Cumulative GDPR fines have exceeded 7.1 billion euros since 2018, with roughly 1.2 billion euros issued in 2025 alone according to public enforcement trackers. The top tier reaches 20 million euros or 4% of global annual turnover, and a meaningful share of fines lands on smaller service providers, not only large technology firms.
Does GDPR apply to the vulnerability findings a security scanner produces?
Findings describe technical characteristics of systems rather than attributes of individuals, so they are often not personal data in the Article 4(1) sense. They still describe systems that handle personal data, which is why buyers treat them as confidential and expect a DPA, EU data residency and clear retention terms for the scan metadata and results.