Research methodology

We identified incidents from a range of publicly available sources (listed here), including reports to regulators, news reports, security researchers’ feeds and press releases by breached organisations.

We only recorded incidents where we have a reasonable degree of confidence that the incident is genuine; for instance, because the report is coming from a reputable source, or because samples have been provided. It’s possible, however, that we inadvertently recorded incidents that didn’t occur, or dismissed incidents that did happen.

We recorded incidents we believe genuine, along with quantifiable data points for each, in a spreadsheet. We’ve done our best to present the data as accurately and objectively as possible, but inevitably deal with lots of blurry lines. There are also the inherent limitations of working with breaking news, where we often lack detail at initial disclosure, but update data points as more information becomes available.

Please also be aware that we log incidents manually in a spreadsheet, from which we analyse and quantify the numbers. While we do our utmost to avoid inputting errors, when we typically record hundreds of incidents a week, some mistakes may slip through.

Month and year recorded

We record incidents by the month and year that they came into the public domain; not when the incident took place, given that it usually takes time for the victim to become aware of the incident, and more time before publicly disclosing it.

Again, an inherent limitation of working with breaking news is that, often, more information about the incident comes to light later. We do backtrack our data in our spreadsheet in such scenarios, which our report reflects, but this causes some discrepancies between our weekly and monthly blogs, and our report.

Region, country and sector

We record the region (continent) and country as where most affected individuals are located. If we don’t have this information, we record the region and country as where the organisation is based. Where the organisation has locations in multiple countries, we record the region and country of its headquarters.

We only record the country, or region and country, as ‘unknown’ when this information about the breached/attacked organisation is not publicly available, or when we know an incident occurred but the source didn’t specify the organisation or its location.

We record the region and/or country as ‘multiple’ in situations like the MOAB, where we know for a fact that multiple organisations, in multiple countries/regions, suffered an incident.

We take the same approach to recording a sector as ‘multiple’ or ‘unknown’.

Supply chain attacks

Incidents that originated from a third party, often an IT services or software provider. Note that relatively few supply chain attacks can have a relatively big impact on the overall figures, but that doesn’t make these attacks any less serious. Successfully exploiting a vulnerability in just one IT services or software provider could impact hundreds or even thousands of organisations.

Data breached

If the confidentiality, integrity and/or availability of data records have been compromised, we consider these records ‘breached’. This can include an unsecured database, data exfiltration and even physical data breaches – for instance, lost or stolen paperwork. The hard copy data could also have been destroyed without authorisation.

Note that a ‘data record’ can include personal data as well as confidential business data.

In cases where only the number of affected data subjects is reported, but we know that multiple data types had been breached per person, we record the number of individuals affected as the number of records breached, because we can only record the numbers publicly disclosed.

In cases where a range is provided, or phrases like ‘at least’ are used, or any other type of uncertainty is expressed, we always err on the side of caution by reporting the lower figure.

Where ‘around’, ‘about’, etc. is reported, we record the rounded number. Where ‘more than’, ‘at least’, etc. is reported, we record the rounded number plus one. Where ‘up to’, etc. is reported, we record the rounded number minus one.

For incidents where we only know the file size of the data breached, we use the formula 1 MB = 1 record. Given that we can’t know the exact numbers, as it depends on the types of records included (e.g. pictures and medical histories are considerably larger files than just names and addresses), we err on the side of caution by using this formula. We believe that this underestimates the records breached in most cases, but it is more accurate than not providing a number at all.

For data breaches claimed by threat actors on dark web forums, where they provide samples or other evidence of the breach, we accept these incidents as having genuinely occurred, but don’t accept the number of records the threat actor claims to have stolen at face value. This is because we’ve noticed that these numbers – particularly in terms of unique records – are often exaggerated. We therefore log these incidents as known to have had data breached, but with either an unknown number of records, or logging only the number of samples provided (if specified), then update this when a reliable source has verified the numbers.

Remedial action

Reported remediation typically includes conducting a forensic analysis to establish exactly what happened (often by engaging a third-party specialist). It often also involves temporarily taking down systems to limit the impact of the security breach.

In the case of DoS (denial-of-service) attacks, where a website had been taken down by a threat actor and is live again at the time of writing, we assume that the attacked organisation has taken remedial action, even if that organisation hasn’t publicly acknowledged the attack or the remediation.

Notified regulator

This means that the incident involved a regulator or an equivalent authority, whether because the organisation itself became aware of the breach and reported it, or because a third party reported it, or because it was the regulator or authority that uncovered the data breach.

Notified individuals

‘Individuals’ here can mean both data subjects as well as individuals affected by a service disruption. Where the organisation made a clear statement of intent about notifying affected individuals as soon as it has completed its investigation, we count this as having notified individuals.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.