Cybersecurity companies occupy an unusual position under GDPR. Your job is to protect personal data — but doing that job often requires accessing, processing, and sometimes exfiltrating it. Penetration testers access live production systems. Incident responders triage breached databases full of customer records. Threat intelligence analysts process email addresses, IP addresses, and personal identifiers as indicators of compromise.
This creates compliance obligations that standard GDPR guides completely miss. Most privacy checklists are written for SaaS companies or e-commerce stores. They don't address what happens when your security work routinely touches third-party personal data as part of the service.
Why Cybersecurity Companies Face Unique GDPR Challenges
The core tension is this: GDPR requires a lawful basis for processing personal data, but security work often involves processing personal data without the direct consent of the individuals whose data is involved. When you're hired to test a client's systems, the employees whose accounts you're targeting didn't consent to your penetration test. When you're responding to an incident, the customers whose records were breached didn't agree to your forensic analysis.
This doesn't make the work illegal under GDPR — but it does mean the legal basis, documentation, and data handling obligations need careful thought.
Cybersecurity companies typically act as data processors when working on behalf of clients (you're processing their data on their instructions), and as data controllers for their own internal systems. Some engagements create joint controller relationships. Many firms operate across all three simultaneously.
Penetration Testing and GDPR
Penetration testing is the area where GDPR compliance gaps are most common. A typical pen test engagement involves accessing client systems that contain employee records, customer data, and financial information; attempting to exfiltrate data to demonstrate real-world attack scenarios; and generating reports that may include screenshots of personal data.
Data Processing Agreement (DPA) Requirements
Before starting any engagement that involves accessing systems containing personal data, you need a Data Processing Agreement in place with your client. Under Article 28 GDPR, any organisation that processes personal data on behalf of a controller must have a written DPA.
For a pen test firm, this means:
- The DPA must specify the subject matter, duration, nature, and purpose of the processing
- It must specify the type of personal data and categories of data subjects involved
- It must set out your obligations and rights as processor
- It must include sub-processor provisions if you use third-party tools or cloud services during the engagement
A standard pen test scope document or statement of work is not a DPA. You need a separate, GDPR-compliant data processing agreement.
Scope Limitations and Data Minimisation
GDPR's data minimisation principle requires you to process only what is necessary for the purpose. For pen testing, this means:
- Scoping engagements carefully: The engagement scope should define which systems are in-scope. Processing data from out-of-scope systems — even if you accidentally access them — creates compliance exposure.
- Handling exfiltrated data: Data you extract to demonstrate a vulnerability should be kept to the minimum necessary to prove the point.
- Report content: Anonymise or pseudonymise personal data in penetration test reports wherever possible.
- Post-engagement deletion: Define how long you retain client data from the engagement and ensure deletion occurs within the agreed period.
Incident Response and Article 33/34
When you're called in after a breach, the data processing situation changes significantly. Under GDPR:
- Article 33 requires controllers to notify their supervisory authority within 72 hours of becoming aware of a breach
- Article 34 requires controllers to notify affected individuals directly when there's a high risk to their rights and freedoms
As the incident response firm, your forensic analysis feeds directly into both obligations.
Processor Obligations During Incident Response
Under Article 33(2), processors must notify controllers "without undue delay" after becoming aware of a breach. If you discover additional compromised data the client wasn't aware of, you have a direct obligation to notify your client immediately — not just document it in your final report.
Threat Intelligence and Personal Data in IOC Feeds
Indicators of compromise (IOCs) often include personal data: email addresses used in phishing campaigns, IP addresses (particularly residential IPs attributable to individuals under GDPR), domain registration data, and usernames associated with threat actor groups.
Processing personal data for threat intelligence purposes typically relies on legitimate interests. This requires a documented legitimate interests assessment (LIA) covering the legitimate interest itself, necessity, and balancing.
Managed Security Services: SOC and SIEM Operations
Every managed security service agreement should include a comprehensive DPA covering:
- Which categories of personal data you'll process and for which systems
- Sub-processor provisions for your SIEM platform and cloud infrastructure
- Data retention — how long you retain log data in your SIEM
- Data subject rights — the process for responding to DSARs requiring access to your systems
- International transfers — if your SOC team or SIEM infrastructure is outside the EEA
Security Tools as Data Processors
Cybersecurity companies are often also buyers of security tools — SIEM platforms, EDR solutions, vulnerability scanners. Each of these tools processes data on your behalf and may require a DPA. If you're using these tools to process your clients' data, the tool vendor is your sub-processor.
Employee Security Training and Phishing Simulations
Phishing simulation results (which employees clicked, which submitted credentials) are personal data. The lawful basis for internal security training is typically legitimate interests or legal obligation, and this needs to be disclosed in your employee privacy notice.
Background Checks for Security-Cleared Staff
Background checks process special category data under GDPR Article 9 — criminal record information, health information, and financial vulnerability checks. The legal basis typically relies on national legislation or substantial public interest grounds, and must be documented in your Record of Processing Activities.
Compliance Checklist by Company Type
Security Consultancy (Pen Testing, Incident Response, Audit)
- DPA template signed before every engagement involving personal data
- Engagement scoping process that identifies personal data in-scope systems
- Post-engagement data deletion process with documented timelines
- Sub-processor list covering tools used during engagements
- Incident response notification process for Article 33(2) obligations
- Record of Processing Activities (RoPA)
Managed Security Service Provider (SOC / SIEM / MDR)
- Comprehensive DPA template with sub-processor provisions and DSAR procedures
- Sub-processor management process with change notification procedures
- Data retention policy for SIEM data with client-specific configuration options
- International transfer mechanisms documented if team or infrastructure is outside EEA
Security Product Company (EDR, SIEM Platform, Vulnerability Management)
- Product privacy notices covering telemetry and usage data collection
- DPA template for customer agreements
- Data retention and deletion capabilities built into the product
- Privacy by design documentation for new features
Getting Started: Audit Your Own Position First
Cybersecurity companies are usually excellent at auditing others — and often neglectful of their own compliance posture. Start with your own website. What trackers are you running? Is your cookie consent valid? Does your privacy policy accurately describe what data you collect?
Custodia scans your website and identifies trackers, cookies, and compliance gaps in 60 seconds — no account required. It's a useful baseline before you tackle the more complex processor and engagement-level compliance work described above.
This guide is for informational purposes and does not constitute legal advice. Engage a qualified privacy lawyer for advice specific to your situation.
Top comments (0)