Articles / Privacy Law

1045 words

  • uk-law
  • uk-gdpr
  • penetration-testing
  • data-protection
  • security-reporting
  • ico

Is Your Pentest Report Personal Data Under UK GDPR?

Often, yes. Nobody sets out to write personal data into a pentest report, but screenshots, evidence logs and "proof of access" snippets are full of it. The report is a document about a company's security, yet it is routinely stuffed with real people's details.

The test is not the document's purpose. It is what is in it. This post covers when the report falls under UK GDPR, who is responsible for it, and how to write findings that prove the point without hoarding data.

The test is about the content, not the genre

Under Article 4(1) of the UK GDPR, personal data is any information relating to an identified or identifiable living person. That is legislation, and it does not care whether the file is called "Penetration Test Report v2 FINAL".

Things that commonly end up in one:

  • usernames and email addresses from an enumeration finding
  • password hashes, and worse, cracked passwords tied to named accounts
  • screenshots of an admin panel showing customer records
  • staff names and responses from a phishing or social engineering exercise
  • IP addresses and device identifiers in captured traffic
  • database rows pasted in to prove SQL injection

If a person can be identified from it, directly or by combining it with other information, it counts. A bare hash with no account name is the awkward middle case; a hash next to [email protected] is not awkward at all.

A report with none of that is a different story

A report that only says "the login form lacks rate limiting" and lists hostnames is mostly not personal data. Hostnames of company servers relate to a business, not a person.

Mostly, though. Sole traders, small firms and self-hosted setups blur this: a server named after its owner, on a fixed IP, can relate to a person. Whether it does depends on the facts, and that is my reading rather than a settled rule.

Quick detour: why a cracked password counts even without a name

Hang on, this one is interesting. A recovered password alone looks anonymous, but in a report it sits in a row next to the account it unlocks. The row is the personal data, not the string.

It is also a special kind of nasty because people reuse passwords. Your report may be holding a credential that works on their bank. That is a security risk before it is a legal one, and the legal duty (Article 32, appropriate security) follows from it.

Who is the controller of your report?

This is where it gets less tidy. When a tester accesses the client's systems on the client's instructions, the usual picture is that the client is the controller and the tester acts as a processor for that data. A processor needs a written contract with the Article 28 terms: act on documented instructions, keep it confidential, secure it, delete or return it at the end.

But the tester also decides things for themselves: what to keep as evidence, for how long, and how to word findings. To the extent they decide the purposes and means of that retention, they look more like a controller for that part. The ICO's controller and processor guidance is the place to check how it applies to your arrangement.

Settle the roles in the contract before testing starts, not after something leaks. The statement of work already covers authorisation and scope; add data handling to the same paperwork.

What the rest of the law asks of you

Once the report counts as personal data, the ordinary principles apply. In plain terms:

  • Minimisation (Article 5(1)(c)): include only what the finding needs.
  • Storage limitation (Article 5(1)(e)): agree a deletion date for raw evidence.
  • Security (Article 32): encrypt the report at rest and in transit.
  • Breach notification (Articles 33 and 34): a lost or misdirected report can be a personal data breach.

Irony worth noting: Article 32(1)(d) lists regularly testing the effectiveness of security measures as part of the security duty. So the test is something the law encourages, and the test's output is itself something the law protects.

Individuals can ask to see it

A person named in the report can make a subject access request to whoever is the controller, and the report may be in scope. Exemptions exist, but you cannot assume the document is untouchable because it is "security sensitive". That is a case-by-case call, so write as though someone named in it might one day read their own line.

Writing findings that prove the point with less data

The fix is mostly editorial. You rarely need the full record to show a flaw.

  • Mask or truncate identifiers in screenshots and tables.
  • Show one or two sample rows, not the dump.
  • Report counts ("14,203 records readable") instead of contents.
  • Never print cracked passwords in the report; say how many fell and how fast.
  • Keep raw evidence in a separate encrypted store with its own deletion date.

A tiny helper makes the masking habit cheap. This is deliberately simple and keeps only the first character of the local part:

package report

import "strings"

// MaskEmail keeps enough to tell findings apart without exposing the address.
func MaskEmail(s string) string {
	local, domain, ok := strings.Cut(s, "@")
	r := []rune(local)
	if !ok || len(r) == 0 {
		return "[redacted]"
	}
	return string(r[:1]) + "***@" + domain
}

The domain stays because it is usually the useful bit for the client. If the domain itself identifies a person, mask that too.

Criminal offence data and other special cases

If a test stumbles on something nasty, such as evidence of illegal content or a special category like health records, stop and escalate per the rules of engagement. Special category data needs an additional Article 9 condition and criminal offence data is handled under Article 10 with Data Protection Act 2018 provisions. Do not screenshot it "for the report".

The rule I would follow: record that access was possible, where, and when, and leave the content where it is.

Where the lines blur

None of this is legal advice, and several answers turn on the contract and the facts: who decided what to keep, what the data was, and who can identify whom. The legislation and the ICO's guidance on UK GDPR are the primary sources; this post is my interpretation of how they sit on a pentest.

The practical habit survives any of those answers: write the report as if it will leak, because the best-protected personal data is the data you never put in it.

← All articles