UK GDPR for Penetration Testing Firms: A Practical Guide

For the testing itself, a penetration testing firm is usually a processor under UK GDPR: it handles personal data in the client's systems on the client's instructions, so it needs an Article 28 contract, security that matches what it holds and a plan for the personal data it meets during a test. It is a controller for its own business data, and it becomes a controller of client data the moment it uses that data for a purpose of its own.

Processor, controller, or both

The ICO's guidance draws the line at decisions. The controller decides why personal data is processed and takes the overarching decisions about it, while a processor working under contract may still choose the IT systems, methods and security details it uses. The client decides that its systems will be tested, which ones and why; you decide which tools to run and in what order, which is exactly the technical freedom the guidance allows a processor.

The same guidance says a processor that handles personal data outside the controller's instructions becomes a controller for that processing. In testing firms that usually happens by accident.

Some firms call themselves independent controllers to avoid signing client data processing agreements (DPAs). We think that is a mistake: it does not shrink the obligations, it makes them yours, including a lawful basis and a privacy notice for people whose data you never wanted.

What the data processing agreement should say

Article 28(3) lists what the contract between controller and processor must contain. On a penetration test it looks like this.

Two terms are not on that list and cause most of the negotiation. The first is the breach notification deadline: the law says without undue delay, while client DPAs usually name a number of hours. Agree one you can meet at two in the morning on a Sunday. The second is location: name the country and provider where findings and evidence are stored, not "secure cloud storage". This is not legal advice; have a solicitor review your own template DPA once, then negotiate from it.

Personal data found during a test

Most tests touch personal data and some go straight through it. An access control flaw that returns another customer's orders, a file share full of HR documents, a database reachable from the internet: proving the finding means showing data, and the only question is how much.

Our rule is to prove, not harvest. Show that access exists with the least data that will convince a sceptical developer: a record count, the field names, one record with everything identifying redacted. Where you can demonstrate the flaw between two test accounts you control, do that instead of touching a real customer. Never take a bulk copy to prove scale; the count proves scale.

Call the client the same day when the data is special category (health, biometric or ethnicity data and the rest), when it concerns children, or when it looks as though someone other than you has already reached it. Signs that someone got there first may mean the client has a reportable breach, and its 72-hour clock runs from when it becomes aware, so tell it quickly and in writing. Our post on finding signs of a prior compromise covers that call.

Evidence and minimisation

The data you meant to keep is rarely the problem. The copies you did not notice are.

• Proxy history. A web testing proxy's project file holds every response it saw, including every customer record your requests returned. Treat it as evidence: encrypted, kept with the engagement and deleted on the same schedule.
• Recovered passwords. Plaintext passwords recovered from hashes are some of the most sensitive data a test produces. Report patterns and counts, not the list.
• Screenshots. Redact at capture, because every later copy of the report inherits whatever the first one showed.

The report and the evidence behind it have different lives, and the evidence should have the shorter one. We set out a defensible schedule in how long a testing firm should keep client findings, and day-to-day handling in handling evidence and client credentials safely.

Where findings are stored

If your reporting platform keeps client data on its own infrastructure, its provider is your sub-processor, and Article 28(2) requires the client's prior written authorisation, specific or general, before you use it. The same goes for cloud storage and for any AI service that sees evidence: pasting a client's screenshot into a consumer chat assistant hands it to a sub-processor the client never approved.

UK GDPR does not require data to stay in the UK, but sending it or making it accessible to an organisation outside the UK is a restricted transfer that needs adequacy regulations, an approved safeguard such as the IDTA, or an exception. Since 5 February 2026, the Data (Use and Access) Act 2025 has framed the test for adequacy and safeguards as whether protection abroad is "not materially lower" than in the UK. For clients in the EU the flow runs the other way: the European Commission renewed its adequacy decision for the UK on 19 December 2025, so their data can come to you without extra safeguards.

When the breach is yours

Article 33 sets the clocks: 72 hours from becoming aware for a controller to notify the regulator, and without undue delay for a processor to tell the controller. Since 30 September 2026 the regulator has been the Information Commission, which replaced the Information Commissioner's Office. Rehearse the middle row. Handled slowly, it is the one that ends client relationships.

Your own duties as a controller

• The data protection fee. Unless exempt, a firm that processes personal data as a controller pays it every year: £52 for a micro organisation, or £47 by direct debit.
• A complaints process. Since 19 June 2026, controllers must make it easy to complain about how they use personal data, acknowledge complaints within 30 days and respond without undue delay. The Act gives an electronic complaint form as an example; it can be simple, but it has to exist.
• Legitimate interests for security. Since 5 February 2026, UK GDPR names processing necessary to ensure the security of network and information systems as an example of processing that can rest on legitimate interests. It supports your own logging and monitoring, and gives clients a clearer footing for authorising a test; the lawful basis remains theirs to record.
• Records and a privacy notice. Keep records of processing as controller and as processor, and a notice covering client contacts.

Answering a client's DPA questions

Write the answers once and keep them current.

Our guide to answering a security questionnaire about your platform covers the questionnaire that usually arrives alongside the DPA.