1 Project Description
Data Controller: Find The Breach LLC, Bothell, WA, United States
Processing Activity: Automated vulnerability scanning, penetration testing, and security assessment of web applications, networks, APIs, and cloud infrastructure provided as a Software-as-a-Service platform.
Purpose: To identify security vulnerabilities, misconfigurations, and compliance gaps in systems owned or authorized by the data controller's customers, enabling proactive security remediation and regulatory compliance.
Data Subjects: Users of the Find The Breach platform (account holders), authorized system administrators of target systems, and incidentally, end-users whose data may be referenced in scan findings (e.g., exposed email addresses, usernames, or URLs).
Data Categories Processed:
- Account data: email, name, company, hashed password, TOTP secrets (encrypted)
- Scan targets: domain names, IP addresses, URLs, port numbers
- Scan results: vulnerability findings, HTTP responses, server banners, SSL certificates, DNS records, technology fingerprints
- Technical metadata: scan duration, scanner outputs, evidence artifacts
- Incidental data: any personal data discovered during scanning (exposed credentials, email addresses in source code, etc.)
2 Necessity and Proportionality
Legal Basis: Legitimate interest (GDPR Art. 6(1)(f)) — the security of information systems is a recognized legitimate interest per Recital 49. Additionally, processing is based on the explicit consent of the platform user (Art. 6(1)(a)) who initiates scanning only on systems they own or have written authorization to test.
Necessity: Vulnerability scanning is the minimum viable technical measure to identify security weaknesses. The scanning process requires access to target system responses (including headers, HTML, API responses) to accurately identify vulnerabilities. Less invasive alternatives (e.g., configuration-only reviews) would miss runtime vulnerabilities, dynamic misconfigurations, and exposed data.
Proportionality:
- Scanning is limited to explicitly authorized targets only
- Users must confirm ownership or authorization before scanning
- Raw scanner output is sanitized to redact credentials and API keys (output_sanitizer.py)
- Scan data is retained for 90 days and then automatically purged
- Data minimization: only security-relevant data is stored; personal data discovered incidentally is flagged but not indexed
3 Risk Assessment
| Risk | Likelihood | Severity | Mitigation |
|---|---|---|---|
| Unauthorized scanning of third-party systems | Medium | High | Authorization checkbox, acceptable use policy, IP verification, audit logging |
| Exposure of discovered personal data in scan results | Medium | Medium | Output sanitization, credential redaction, AES-256-GCM encryption for secrets, 90-day retention |
| Database compromise exposing vulnerability data | Low | High | PostgreSQL access controls, encrypted backups, WAF, rate limiting, MFA for admin |
| Scan results used to exploit target systems | Low | High | Role-based access, JWT auth, account lockout, scan results scoped to owner |
| Incidental processing of special category data | Low | Medium | Data minimization, no active collection of Art. 9 data, sanitization filters |
4 Safeguards and Mitigation Measures
🔐 Access Controls
- • JWT-based authentication with token revocation
- • Role-based access control (admin/client)
- • MFA/TOTP enforced for admin accounts
- • Account lockout after 5 failed attempts
- • Session idle timeout (30 minutes)
🛡️ Data Protection
- • AES-256-GCM encryption for TOTP secrets
- • bcrypt password hashing (12 rounds)
- • Output sanitization for credentials/keys
- • TLS 1.3 in transit via Cloudflare
- • HSTS, CSP, X-Frame-Options headers
📊 Monitoring & Logging
- • Structured JSON audit logging
- • Scan correlation IDs for traceability
- • DB-backed rate limiting on all endpoints
- • Real-time health monitoring (/status page)
- • Webhook delivery with retry and dead-letter
📋 Data Subject Rights
- • GDPR Art. 15 — Self-service data inventory
- • GDPR Art. 17 — Automated deletion request
- • GDPR Art. 20 — Full data export (JSON)
- • Privacy policy with contact details
- • DPO contact: privacy@findthebreach.com
5 Data Retention Schedule
| Data Category | Retention Period | Deletion Method |
|---|---|---|
| Scan results & findings | 90 days | Automated daily purge (03:00 UTC) |
| Vulnerability records | Until fixed + 90 days | Automated cleanup task |
| User accounts | Until deletion requested | 30-day soft delete, then hard purge |
| Audit logs | 1 year | Automated archival |
| Rate limit entries | 10 minutes | Periodic cleanup task |
6 Consultation and Review
DPO Consultation: This DPIA was prepared in consultation with the Data Protection Officer at privacy@findthebreach.com.
Review Schedule: This assessment is reviewed every 6 months or whenever a significant change to processing activities occurs (e.g., new scanner types, new data categories, new third-party integrations).
Supervisory Authority: If residual risk remains high after mitigation measures, prior consultation with the relevant supervisory authority will be sought per GDPR Art. 36.
Conclusion: Based on this assessment, the residual risk to data subjects from Find The Breach's processing activities is assessed as LOW given the technical safeguards, access controls, data minimization, and retention policies implemented. The processing may proceed without prior consultation with a supervisory authority.