IT Governance’s research found the following for December 2023:
- 1,351 publicly disclosed security incidents
- 2,241,916,765 records known to be breached
The most breached sectors by number of incidents were:
- Finance with 179 incidents
- Manufacturing with 113 incidents
The most breached sectors by number of records were:
- Construction and real estate with 1,524,857,965 records
- IT services and software with 181,695,450 records
In this new monthly sector report, we’ll be taking a closer look at these sectors. At the bottom of this blog, we’ve outlined our research methodology.
Note: Technically, the incident type leading to most records breached was ‘unknown’, at 33,029,530 records, but we excluded it from the Dashboard to make it as informative as possible.
Construction and real estate
IT services and software
Responding to and recovering from an incident
When you suffer a cyber attack or a data breach, the speed of your response makes a significant difference to your recovery – and the associated costs.
The sooner you act, the quicker, easier and cheaper it’ll be to restore affected systems and return to business as usual.
We understand how cyber incidents can affect your organisation, as well as the challenges you’ll face when dealing with them.
We identify incidents from a range of publicly available sources (listed in our weekly round-ups), including news articles, PR statements and feeds by security researchers. We record these incidents, along with quantifiable data points for each, in a spreadsheet. Note that we only record incidents where we have a reasonable degree of confidence that it’s genuine, e.g. because the report is coming from a reputable source, or because samples have been provided.
We do 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.
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 annual report will reflect, but this causes some discrepancies between our weekly and monthly reports, and our annual one.
Region and country
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.
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.
Where the confidentiality, integrity and/or availability of data records have been compromised. 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 still record only the number of individuals affected, because we can only record the numbers publicly disclosed. Moreover, where there is any doubt, we always err on the side of caution by reporting the lower figure.
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.
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.
‘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.