The specific personal data processed during a penetration test largely depends on the target of the test. In general, the following categories can be distinguished:
1. Customer Points of Contact
There’s no way around it: the pentester needs contact persons. Typically, this involves processing names, job titles, business email addresses, and phone numbers — stored in emails, calendar entries, or the final report. These details are usually public anyway (e.g., in the imprint or on LinkedIn) and are solely used for communication. They are always processed but are generally considered low risk.
2. Other Employees of the Organization
As soon as the target system includes an internal network — especially one with Active Directory — it’s almost impossible to avoid encountering other personal data. Names, usernames, and often password hashes or even cleartext passwords may temporarily reside on the pentester’s system. This isn’t accidental; it’s part of the job — privilege escalation, lateral movement, domain takeovers.
What’s important here: there is no need to store personal data permanently or transfer it to the service provider’s infrastructure. All data is processed locally and remains local. Only relevant excerpts are included in the report — and even then, only as much as necessary. Identities can and should be anonymized or pseudonymized.
3. Customer Data of the Client
When production systems are tested — such as an online shop — it’s possible that real customer data may briefly become visible. The aim is not to store this data but to identify vulnerabilities. For example, can unauthorized users view other customers’ orders? If so, some records may be momentarily processed. This is unavoidable but kept as non-invasive as possible.
Recommendation: Data Processing Agreement (DPA) for Production Data
As soon as internal or production environments are involved, a DPA should be signed. The key principle is data minimization. A penetration test is not about collecting data — it’s about uncovering weaknesses. And that can be done without copying entire databases.
