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.