A claim is not a breach
Many posted claims are recycled from older incidents, assembled from public sources, or invented to pressure an organisation into paying. Some are real. The task is to tell these apart quickly, and to say so with a stated level of confidence.
Work from what is public
Claimants usually publish a description, a file listing or a small extract to support their claim. We capture the post as an ordinary visitor would see it, hash the capture, and work only from what is publicly shown. We do not download full datasets, join closed groups or contact the claimant.
Compare structure, not people
The useful questions are structural. Do the field names, formats and identifier patterns match your systems? Do record dates fit the claimed time of access? Does the posted extract contain values your systems would never produce? These checks run against your data structures, without anyone handling the personal data in the extract.
Three possible answers
A verification ends in one of three statements: consistent with your data, inconsistent with your data, or cannot yet be assessed. Each comes with the reasons, the sources and the limits of what was checked. A consistent result does not prove a breach, and an inconsistent one does not prove the claim false.
What happens next
If the claim is consistent, your incident-response and legal teams decide what to do, including any notification duties. We keep the hashed captures so the analysis can be checked later. We never announce a breach publicly; findings go to the affected organisation first, and to authorities where required.