When Vulnerability Research Exposes Personal Data: Evidence, GDPR and the Point to Stop

An access-control flaw may create a technical path to thousands of personal records.

That does not mean a researcher needs to view thousands of records.

There are several distinct stages:

1. the system technically appears capable of exposing personal data;
2. a minimal fragment of personal data is actually displayed;
3. that data is captured in a screenshot, HTTP response, video or other evidence;
4. the data is copied, enumerated, analysed, retained or transmitted.

GDPR defines processing broadly. Article 4(2) includes collection, consultation, retrieval, storage, use, disclosure and erasure.1

Security research therefore benefits from thinking about the lifecycle of personal-data processing, not one abstract moment called “access”.

Each additional stage can increase both evidential value and privacy risk.

One of the most useful parts of the DVI response was its refusal to assign one GDPR role to every security researcher.

Where a researcher tests a system on behalf of its controller and acts within that controller's authority and instructions, DVI said that the researcher would be considered a processor, bringing Article 28 requirements into the picture.2

Where a researcher acts independently, chooses the target and determines the purpose and means of processing, the researcher may instead be a controller for that processing.2

That is consistent with the European Data Protection Board's guidance: controller and processor roles are functional concepts determined by the factual allocation of decision-making, not simply by contractual labels or what a party calls itself.3

“Security researcher” is therefore not a GDPR role.

Neither is “bug bounty hunter”.

The useful question is who actually determines why the personal data are processed and the essential means by which that happens.

This distinction matters enough to state plainly.

A researcher may be extremely careful: inspect one field, redact the name, encrypt the evidence and delete it after disclosure.

Those are sensible controls.

They do not answer the separate Article 6 question: what makes the processing lawful in the first place?

GDPR Article 5 includes data minimisation among the core processing principles. Article 6 separately requires a lawful basis for processing.1

DVI noted that an independent researcher acting on their own initiative may have difficulty identifying the applicable lawful basis for personal-data processing during vulnerability research. The issue becomes even more difficult where Article 9 special-category data are involved.2

Two questions therefore have to remain separate:

Is the processing lawful?

and, if so,

What is the minimum amount of data objectively necessary for the purpose?

Minimisation reduces processing. It does not manufacture legal authority.

Consider a broken object-level authorisation vulnerability.

The researcher controls account object 1001.

Requesting 1002 returns another user's object.

That single response may already establish the core technical fact: the server is failing to enforce object-level authorisation.

Should the researcher try 1003, 1004 and 1005?

Sometimes one additional test may have a real technical purpose — for example, distinguishing an isolated misassigned test record from a general access-control defect.

The reason should be technical rather than curiosity-driven.

A useful question before the next request is:

What new security fact will this request establish that I do not already know?

If the answer is merely “it will show that more people's data are accessible”, the vulnerability may already be sufficiently demonstrated.

There is no universal PoC format, but evidence can often be approached from less invasive to more invasive.

This is not a hierarchy created by GDPR.

It is an operational method for asking whether the next, more invasive step is actually necessary.

CERT.LV's current vulnerability-reporting FAQ follows the same underlying logic: researchers are not permitted to retrieve, retain or otherwise process data obtained during vulnerability research beyond what is necessary to demonstrate the identified vulnerability as a proof of concept.6

A common mental shortcut treats storage as the line where GDPR begins.

It is not.

If personal data are displayed and actually consulted or retrieved, processing may already have occurred even if the researcher never saves a screenshot.1

That does not make temporary viewing equivalent in risk to downloading a database extract and retaining it for a week.

This is why context matters.

A useful research record can distinguish:

• data appeared incidentally;
• data were intentionally viewed;
• a copy was created;
• the number of affected records observed;
• categories of data exposed;
• retention period;
• recipients of the evidence.

Later, these facts may matter more than a binary field saying only “personal data: yes”.

Screenshots are convenient, so they become default PoC material.

They also capture whatever happens to be on the screen:

• full names;
• addresses;
• phone numbers;
• emails;
• financial information;
• health data;
• session identifiers;
• authentication tokens;
• unrelated records belonging to other people.

Before taking the screenshot, ask whether the technical fact can be shown without those details.

Often it can.

A researcher may be able to use the mismatch between authenticated identity and object ID, a redacted response fragment, synthetic test data or precise reproduction steps that the affected organisation can execute internally.

If a screenshot is needed, the retained copy can often be redacted. Keeping an unredacted original is a separate decision that should have a reason.

Pseudonymisation is not the same as anonymisation. Data remain personal where an individual can still be identified using additional information.1

Not all personal data create the same risk.

Article 9 GDPR creates a specific regime for special categories such as health data, biometric data used for identification, political opinions, religious beliefs and data concerning sex life or sexual orientation.1

Article 10 separately governs personal data relating to criminal convictions and offences.1

DVI specifically noted that the lawful-basis problem for independent researchers becomes particularly difficult where special-category data are involved.2

In practical research, this should change the default behaviour.

Where the flaw is already demonstrated and unexpected high-risk data appear, a cautious approach is to:

• avoid increasing the volume;
• capture no more than the technical evidence requires;
• avoid publishing the real data;
• move quickly into secure coordination with the asset owner or CVD coordinator;
• perform deeper validation only with clearer authority and a controlled testing arrangement.

That is not a universal statutory “stop rule”.

It is a much safer operating default than continuing simply because the system allows it.

This boundary is easily missed.

CERT.LV's Vulnerability Reporting Platform privacy notice states that CERT.LV, as controller of the platform processing, relies on its statutory tasks under the National Cybersecurity Law and Article 6(1)(e) GDPR for processing within the coordinated vulnerability-disclosure workflow.5

That explains CERT.LV's processing once the information enters its coordination process.

It does not automatically answer a different question:

What is the independent researcher's lawful basis at the earlier moment when the researcher technically encounters another person's data?

This distinction was central to my submission to DVI. The Inspectorate's response linked the answer to the researcher's actual role, the purpose, the necessary acts and the amount and type of data processed.2

It would therefore be incorrect to reason:

“CERT.LV can lawfully process the report, therefore the researcher automatically has legal authority to obtain whatever data may be useful for that report.”

Those are separate processing contexts.

Once a minimum personal-data fragment has been captured, another set of risks begins.

Reduce it

Remove everything that is not needed to explain the vulnerability.

If one field proves the issue, do not retain the full profile.

Redact it

Where identity is not part of the technical proof, redact names, email addresses, account numbers and other identifiers.

Store it deliberately

A PoC containing personal data should not casually live in a Downloads directory, public issue tracker, personal photo library or broadly synchronised notes application.

Storage controls should reflect the content.

Limit copies

Every copy in email, Slack, ticketing, chat or a second laptop creates another access and deletion problem.

Transmit only what is necessary

The recipient may not need the unredacted evidence. A redacted extract plus exact reproduction steps can sometimes be sufficient.

Revisit retention

“Maybe useful later” is not a good indefinite retention rule.

After acknowledgement, remediation or closure, the researcher should reconsider whether identifiable evidence is still needed for the purpose.

In some cases a researcher may need evidence for a later dispute or legal defence. That would be a different purpose that needs to be considered explicitly rather than assumed.

A vulnerability and a personal-data breach can overlap.

They are not synonyms.

Article 4(12) GDPR defines a personal-data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.1

The existence of a vulnerability therefore does not automatically establish that a personal-data breach has occurred.

If the research reveals actual unauthorised access or disclosure, however, the controller may need to conduct a separate breach assessment.

Article 33 requires notification to the supervisory authority in qualifying cases without undue delay and, where feasible, within 72 hours. Article 34 addresses communication to data subjects where the breach is likely to result in a high risk to their rights and freedoms.1 EDPB's breach-notification examples emphasise that the response depends on the actual incident and its risks rather than the label attached to the security problem.4

A CVD report does not replace a GDPR breach assessment.

The reverse is also true: starting a data-breach process does not remove the need to remediate the vulnerability.

This is a particularly dangerous point of confusion.

The affected organisation may need to establish how many records were exposed or whether the vulnerability has already been exploited.

That does not mean an independent researcher should enumerate thousands of records to calculate the answer.

The researcher's PoC and the controller's incident investigation are different jobs.

The organisation may have server logs, database records, SIEM data, audit trails and other internal evidence that can establish impact without creating a new bulk exposure.

A strong researcher report can say:

“A controlled request returned an object belonging to another account.”

It does not necessarily need to say:

“I enumerated 5,000 IDs and retrieved 4,387 individuals.”

The second statement may add impact detail while also creating a significantly larger data-protection problem.

Evidence that was necessary in a confidential report is not automatically necessary in a blog post, conference talk or public advisory.

Publication creates a new audience, purpose and risk.

Public technical material can usually use:

• synthetic records;
• reconstructed examples;
• redacted screenshots;
• request/response structure without real content;
• PoC against researcher-controlled accounts.

A real person's name rarely makes an IDOR, SQL injection or broken-access-control explanation technically better.

If the real data are not necessary to understand the finding, they should not be in the public explanation.

Multi-party vulnerabilities can involve an asset owner, national CSIRT, software vendor, cloud provider and researchers in several countries.

That does not mean every participant needs an identical copy of all personal-data evidence.

Where data are made available outside the EU/EEA, GDPR Chapter V transfer rules may also become relevant depending on the roles and transfer situation.1

Two questions are useful before forwarding evidence:

Does this recipient actually need the identifiable data to perform its role in remediation?

Can the same coordination objective be met with redacted or synthetic evidence?

Coordination should reduce risk, not distribute it.

This is not a legal safe-harbour formula.

It is a research discipline designed to stop a good PoC from becoming a second incident.

Researchers cannot carry the entire burden.

An organisation inviting external vulnerability research should say how personal data must be handled.

A practical policy can require:

• researcher-controlled test accounts where possible;
• no extraction beyond the minimum required for PoC;
• no bulk copying of user lists to “prove impact”;
• immediate cessation of unnecessary access when special-category or authentication data appear;
• a defined secure evidence-submission channel;
• clear expectations about how long researchers should retain local evidence;
• prohibition on public disclosure of real personal data;
• an escalation path when the vulnerability cannot be understood safely without deeper testing.

CERT.LV's current platform terms and FAQ already provide an important baseline by limiting data retrieval to what is necessary to demonstrate the vulnerability.6 Organisation-specific policies can make the boundary more operational.

The Inspectorate did not create one universal researcher exception.

It did not declare every security researcher a controller.

It did not declare every researcher a processor.

It did not identify one Article 6 basis that automatically covers all independent vulnerability research.

It did not treat CVD as outside GDPR.

Instead, DVI anchored the analysis in the facts: the researcher's role, purpose, data type and volume, objective necessity and what happens to the data after discovery.2

That is a sound direction for European practice more broadly.

The legal and operational boundary should not be built around the job title “security researcher”.

It should be built around the specific processing act and why it is necessary.

Personal data often appear in vulnerability research because exposure of those data is the vulnerability.

That does not suspend data-protection law.

Good research tries to prove the security defect with the smallest amount of real personal data that is genuinely necessary, and stops expanding the dataset once additional records no longer establish a new technical fact.

A good CVD process should also do more than ask for a screenshot. It should tell researchers what evidence is needed, how to transmit it safely, who needs to receive it and what happens to retained copies afterwards.

The principle is simple even when the legal analysis is not:

prove the vulnerability; do not collect people simply because the vulnerability makes them collectible.

Legal and institutional sources were checked on 25 September 2026. The DVI response is a specific institutional reply to the author's submission of 10 August 2026; it is not presented as generally binding legislation. The minimum-evidence ladder and stop-and-escalate model are the author's practical methods.

This article analyses security-research and data-protection practice. It is not individual legal advice.