Location: Farringdon, London
Sector: Healthcare Technology
Reason for Surveillance: Data Loss Prevention
Background
A healthcare technology company developing patient-facing software approached us after a journalist contacted their press office with detailed knowledge of an unreleased product feature and, more worryingly, references to specific internal test data that should never have left the building. With patient data protection obligations under UK GDPR squarely in view, the company’s board treated this as a potential breach of the highest severity, and needed to establish quickly whether test data containing any identifiable patient information had actually left the organisation, and if so, how.
The call our corporate investigators received from the company’s chief technology officer came within an hour of the journalist’s enquiry landing, and the urgency in that first conversation set the tone for the entire engagement. We made clear from the outset that speed could not come at the expense of evidential rigour — a rushed investigation that missed the actual source, or drew the wrong conclusion about what data had been exposed, could be considerably more damaging than a short additional delay to get the answer right. We agreed a compressed but structured timeline that balanced both concerns.
The Brief
Our brief was twofold: to work alongside the company’s data protection officer to trace the technical path of the leak, and to identify, through investigative rather than purely technical means, who was responsible. Given the regulatory clock — a confirmed personal data breach would trigger a 72-hour notification obligation to the Information Commissioner’s Office — speed was essential.
The Investigation
Working in parallel with the company’s IT security team, we reviewed access logs for the specific test dataset and product documentation referenced by the journalist, narrowing the pool of individuals with recent access to fourteen people across product, engineering, and quality assurance functions. Cross-referencing document access timestamps against file-sharing and printing activity identified one individual — a QA contractor — who had printed the relevant documentation shortly before the journalist’s enquiry, despite there being no legitimate operational reason to do so.
We conducted open-source research on the contractor and identified a previously undisclosed personal connection to the journalist in question, established through a mutual professional networking connection and historical social media activity. With the company’s authorisation, we also reviewed the contractor’s corporate email activity for the relevant period, which showed a personal webmail account being accessed from the corporate network shortly before the documents were printed — itself a breach of the company’s acceptable use policy and a strong corroborating signal.
Given the regulatory clock running in the background, we worked in near-constant contact with the company’s data protection officer throughout, providing interim findings as they emerged rather than waiting for a single final report, so that the DPO’s own assessment of notification obligations could develop in parallel with our investigation rather than being held up waiting for us to finish. This kind of close, iterative collaboration is essential in breach-response work; a data protection officer facing a 72-hour clock cannot afford to wait for a polished final document before beginning to form a view.
We also conducted a physical review of the printed documents’ likely fate, checking the office’s confidential waste and shredding logs to establish whether the printed pages had been properly disposed of or remained at large — finding no trace of them in the confidential waste stream, which supported the working assumption that the documents, or their contents, had left the building via the contractor rather than being an internal handling failure.
Findings
Our combined technical and investigative findings identified the QA contractor as the probable source of the leak, supported by access logs, printing activity, a previously undisclosed personal connection to the journalist, and policy-breaching use of personal webmail on the corporate network. Critically, our review also confirmed that the specific test dataset in question, while sensitive from a commercial perspective, had in fact been fully anonymised in line with the company’s data minimisation protocols, meaning the incident did not constitute a personal data breach under UK GDPR — a finding that materially changed the company’s regulatory obligations and allowed the data protection officer to conclude, with confidence, that ICO notification was not required.
Outcome
The company terminated the contractor’s engagement and pursued a breach of confidentiality claim through its solicitors. Just as significantly, our finding that the leaked data was properly anonymised avoided a potentially damaging regulatory notification and the reputational fallout that would likely have followed. The company also used our recommendations to introduce printing restrictions on sensitive test environments and mandatory device management on all contractor devices accessing the corporate network. We also recommended, and the company subsequently adopted, a quarterly access review specifically for contractor accounts, given that the standard employee access review cycle had not been well suited to catching the kind of short-term, project-specific access that had proved to be the vulnerability in this case.
Lessons for Other Businesses
Data loss investigations sit at the intersection of technical forensics and old-fashioned investigative legwork, and the strongest cases combine both. It is also worth noting that not every leak is a data protection incident in the legal sense — establishing precisely what was and was not disclosed can be as valuable, from a risk management perspective, as identifying who was responsible. Companies handling sensitive data should ensure their DPO and any external investigators work in close, real-time coordination from the outset, given how tightly the regulatory clock runs once a suspected personal data breach is identified.
Investigator’s Reflection
The anonymisation finding in this case is a good example of why investigators should resist the urge to assume the worst before the evidence is in. It would have been easy, under time pressure, to advise the client to notify the ICO as a precaution while the investigation continued — and many organisations do exactly that, understandably. But a rushed, technically inaccurate notification can create its own problems, including reputational ones, if it later has to be walked back. Taking the extra day to properly verify the anonymisation status of the dataset was, in my view, the single most consequential decision in this entire investigation.
