The ICO cyber caseload: the published outcome of 956 closed cyber investigations, 2021 to 2026

One in 96 pooled, one in 45 once the first published quarter is set aside, one in 21 from 2022

What these figures are, and what they are not

• This is a FLOW of cases the ICO closed and published each quarter, not a STOCK of every cyber case the regulator has ever handled. It cannot tell you how many cyber cases are open.
• Say 'published caseload', not 'caseload'. These quarterly data sets are a publication, and what goes into them is a choice the regulator makes. The ICO does not usually announce individual decisions to take no further action.
• 502 of the 956 closures - 52.51% - fall in one quarter, Jan-Mar 2021, and 788 of the 956 - 82.43% - fall in calendar 2021 as a whole.
• The headline roughly doubles when the first published quarter, Jan-Mar 2021, is removed (1.05% of 956 to 2.2% of 454) and roughly quadruples when all of calendar 2021 is removed (4.76% of 168). All three are published together for that reason.
• Descriptive, not a criticism of the regulator. This page counts published outcome strings; it makes no claim about why any case ended where it did, and no claim about whether the pattern is or is not in line with the ICO’s Regulatory Action Policy. Nothing here is an argument that the regulator should fine more often, and nothing here is an argument for buying anything.
• Small n. From 2024 the yearly denominators fall to double and single figures. Any year with n below 50 is too small to rank and any year with n below 10 is reported as a count only. A single case moves those rates by tens of percentage points.
• 'Penalty track' is a definition, not a field in the data. It means the published outcome records a monetary penalty issued, pursued, under appeal, or issued and not recovered. Four defensible codings were computed and they give between 8 and 11 cases out of 956; the published figure is 10. The headline does not turn on the coding.
• The penalty grouping is Bristows', extended by one outcome string. They published the grouping in April 2023; we add 'Not recoverable', which they place in their Closed/Other group. On their grouping unchanged the figure is 9 of 956 rather than 10, and both are printed. Nothing here is a first.
• NOT a measure of how often UK organisations are fined for cyber attacks in general. It measures what happened to the cases the ICO itself closed and published in these two data sets.
• NOT a measure of security. A case closed with no action is not a finding that the organisation was secure, and a reprimand is not a finding that it was not.
• Population is UK-jurisdiction, not UK-domiciled. Non-UK entities appear because the ICO regulates controllers processing UK personal data. The right phrase is 'organisations reported to the UK regulator', not 'UK organisations'.
• No organisation is named anywhere in the dataset. Counted as distinct strings, the organisation and controller columns of the source files carry 921 values in the 21 investigations files and 1688 across all 41 - upper bounds on the number of organisations, because the column is not a clean register. None of those strings appears in any published file here, and the emitter refuses to write a row containing one.
• The source's controller column is a case-title field, not a clean organisation register: it carries entries such as an ICO case title rather than a company name, a bare initialism, and a group name where the ICO's published action names a subsidiary. Any organisation named in the page text must be taken from the ICO's published enforcement or reprimand page, never from this column.

The remaining 9 limits are printed in full in the method section, alongside the dropped-row register and the points where our figures depart from the study brief. All 22 are also in the machine-readable file.

The denominator the fine trackers do not carry

Trackers of ICO enforcement count actions taken. The ICO's own enforcement register lists penalties, enforcement notices, reprimands and prosecutions; the published trackers built on it count the same things. None of the ones we could read carries the published caseload those actions came out of, because the register does not contain it. Bristows computed a caseload denominator from these same ICO data sets in 2023, for one calendar year and with civil and cyber investigations pooled; it is credited in full below. The ICO publishes the caseload separately, as quarterly CSV files of closed cyber cases. This study is a census of those files: 956 closed cyber investigations across 21 consecutive quarterly publications, with the outcome recorded on every one of them.

Scroll the table sideways to see every column →

Every figure on this page is a count of all 956 closed cyber investigations published by the ICO over 21 quarters, except where a different denominator is printed beside it. “Penalty track” is our label, not a field in the source: Our label for the published outcome strings that record a monetary penalty issued, pursued, under appeal, or issued and not recovered: 'appeal', 'civil monetary penalty pursued', 'fine - higher tier', 'not recoverable', 'paid in full'. The grouping is Bristows', extended by one string.

What the 956 closed investigations ended in

Every one of the 956 cases carries a published outcome - coverage is 100.0%. Just under four fifths of the published caseload - 756 of 956, 79.08% - ends in one of two strings: 'No action for DC' and 'Advice provided'.

Scroll the table sideways to see every column →

Outcome strings are counted as the ICO published them. Only spelling, wording and encoding variants of one outcome are folded together: the family “Closed after intervention - in line with RAP” is “Closed after intervention–in line with RAP” (6), “Closed after intervention and in line with RAP” (1), “Closed after intervention–in line with RAP” (3). Each raw string and its count is preserved in the dataset beside the family. Shares are rounded to two decimals, so the column sums to 99.98% rather than exactly 100%.

The three tracks, and how sensitive they are to the definition

10 of 956 closed investigations (1.05%) reached the penalty track, 23 (2.41%) ended in a reprimand, and 923 (96.55%) in neither. Every rate in this section is pooled across all 956 closures: outside Jan–Mar 2021 the same 10 penalty-track cases are 2.20% of 454, and the 8 closed from January 2022 onwards are 4.76% of 168. 'Penalty track' is our label for a group of published outcome strings, not a field in the data. Four defensible codings were computed. Across all four, the count moves between 8 and 11 cases out of 956, so the pooled figure does not turn on which one a reader prefers.

Scroll the table sideways to see every column →

And the denominator, tested the other way. The four codings stress-test the numerator. The denominator is stress-tested once, the other way: 81 of the 956 rows (8.47%) carry an outcome that records an administrative closure rather than a worked case. Removing them raises the penalty rate from 1.05% of 956 to 1.14% (10 of 875, one in 88), so the headline does not turn on whether they are counted. The cut that does move it is the period: 2.20% of the 454 closures outside Jan-Mar 2021, and 4.76% of the 168 from January 2022 onwards. The 81 are 'Closed - Documents pasted into existing case', 'Closed - duplicate', 'NFA - Created in error', 'No Personal Data'.

The weakness, stated up front: this describes 2021

52.51% of the closures in this population - 502 of 956 - fall in one quarter, Jan-Mar 2021, the first quarter the ICO published, and 788 of 956 - 82.43% - fall in calendar 2021 as a whole. That quarter contains no penalty-track case and no reprimand at all. The pooled rate is therefore dominated by a single quarter, and every cut is published rather than one. Why that quarter is so large is not something the published data answers, and no explanation is asserted here.

Scroll the table sideways to see every column →

502 of the 956 closures (52.51%) fall in Jan–Mar 2021, the first quarter the ICO published, and that quarter contains 0 penalty-track cases and 0 reprimands. Only 31 closures (3.24%) fall in the nine most recent published quarters. The pooled rate is therefore a description of 2021 with a thin tail attached, which is why all five populations are printed rather than one.

Why that quarter is large is not something this page claims to know. The nearest thing to evidence about that quarter, published rather than left out: 287 of its 502 closures (57.17%) carry a case reference whose four-digit year is earlier than the year the case closed, against 25 of 231 (10.82%) in the next quarter. The ICO does not publish what that year means, so this is a description of the reference strings. It is consistent with the first published quarter clearing older cases and is not proof of it, and the quarter is named by its date everywhere on this page rather than labelled a backlog.

By year of closure, with each year’s own denominator

From 2024 the yearly denominators fall below 50 and then below 10. Years with n below 10 are reported as counts with no percentage. No year in this table is a trend.

Scroll the table sideways to see every column →

n is below 10, so counts only are reported: a single case would move any percentage by more than ten points. No year in this table is a trend, and no year is ranked against another.

Closures per quarter

A bare sourced count of cases closed and published per quarter, with no trend read into it. The published data cannot distinguish the ICO closing fewer cases from the ICO publishing fewer, so no such claim is made.

No trend is read into this shape. 502 of the 956closures land in Jan–Mar 2021, the first quarter published, and the published data cannot separate the regulator closing fewer cases from the regulator publishing fewer of them.

The incidents file, as context only

The ICO publishes a second quarterly series, of closed cyber incidents: 796 cases across 20 files. It is shown here for scale and is not part of the denominator.

Scroll the table sideways to see every column →

Why no escalation rate. Dividing 956 closed investigations by 796 closed incidents would produce something that looks like an escalation rate. It is not one, and it is not published here. The two are separate publications with different inclusion rules; the incidents series has no Jan-Mar 2021 file at all; and neither file records whether a given incident later became an investigation. The ICO states that the cases on the incidents data sets "are those which were considered but not progressed to a full Investigation", so the two files are the two outcomes of one triage step rather than a pool and the share of it that escalated. The ratio would measure ICO publication practice, not case escalation. Bristows published an escalation rate for 2022 (9% of the cyber incidents in their 2022 population); we do not repeat it, for these reasons.

Repeated references on this side. The zero-duplicates figure on the denominator is a statement about the 956 investigations. The incidents side carries 2 repeated references out of 796 rows and they are reported rather than removed: IC/0018/2024 appears in 4030363__cyber-crimson-incidents-q4-2023-24.csv; IC/0028/2024 appears in 4031244__cyber-incidents-2024-25-q1-closed-datasets.csv and pwghpy4r__cyber-incidents-q2-2025-26.csv. One is an exact duplicate row inside a single ICO file; the other is the same reference closed twice, in two different files, with two different outcomes. Both are left in the dataset as published.

What was already known, and what this adds

Bristows published the adjacent analysis in April 2023: Marc Dautlich, 'The ICO's complaints and concerns data sets', covering calendar 2022 only, with civil and cyber investigations pooled, n = 311. They reported 2% monetary penalty, 14% reprimand, 17% advice, 67% no action. They also built the penalty grouping this study extends, and they excluded the 2021 data sets on purpose, because in their words those files "suggested a marked change in approach to Cyber Investigations between 2021 and 2022".

What this study adds

• 21 consecutive quarters rather than one calendar year.
• Cyber only, rather than cyber and civil investigations pooled.
• The complete outcome distribution - every published outcome string with its count - rather than four summary percentages.
• The sensitivity analysis: pooled, excluding the first published quarter and excluding all of 2021 side by side, plus a by-year table with its small-n warning.
• A published, per-row dataset with the source file, URL and hash on every row.

What it does not claim. Not a first. Bristows published an adjacent headline three years earlier, on a population that overlaps this one for 2022, and the penalty grouping is theirs, extended here by one outcome string ('Not recoverable'). On their grouping unchanged the figure is 9 of 956 rather than 10, and both are printed in the codings table above.

Two halves, and both are stated. Our cyber-only 2022 reprimand rate is 6 of 40 (15.0%) against their 14% on 311 mixed cases - close enough to be worth a sentence as a consistency check, and no more than that. The penalty rates do not agree: 4 of 40 (10.0%) here against their 2%, and 4 cases in 40 is not a stable estimate of anything.

The published fine trackers all count actions, not cases: Bridewell (58 monetary penalties, 49 enforcement notices, 65 reprimands and 3 prosecutions published between 2023 and 2026, extracted from the ICO Enforcement Register on 11 May 2026), URM Consulting for 2024 and for 2025, BDO's rolling action counts, and the GDPR Enforcement Tracker operated by CMS, whose stated scope is that only GDPR fines are listed. None publishes a denominator, because the enforcement register does not contain one. All four are listed in the sources table below, cited and not reused.

Practical Law (Thomson Reuters) publishes an 'ICO civil penalties: tracker'. It returned HTTP 403 to an identified bot and is subscription-only, so it is not quoted, not counted and not replaced with a weaker source. Prior art in full: Bristows LLP (Inquisitive Minds) - 'The ICO's complaints and concerns data sets', Marc Dautlich, 26 April 2023.

What was measured, when, and how

What was deliberately not computed

• An escalation rate from incidents to investigations - an unbounded publication artefact. Reason on the page.
• Any sector league table - sector is present on only 11.72% of investigations.
• Any duration or 'the ICO took N days' metric - the Crimson start date is present on only 17.57% of investigations. The closure date is present on 100.0%; the drop is about start-date coverage.
• Any pound figure - 'Final Value' is 0 or blank on 956 of 956 investigations and on all 10 penalty-track rows.
• Any claim that the ICO is investigating more or less than before.
• Any naming of an organisation that suffered a cyber attack.

Limits

• It measures a publication. What the ICO chooses to publish in these files is a regulatory decision, and the files' coverage can change without the underlying caseload changing.
• It is heavily weighted to 2021. See the concentration figures above.
• It is cyber only. Civil investigations are published separately and are not included.
• It is a flow of closures, not a stock of cases.

The remaining caveats, in full

Every caveat this study wrote is on this page. These are the 9 that are about how the files are built rather than about what the figures mean; the other 13 are in Read this first.

• Series break, explained by the publisher. From Q4 2022-23 the ICO joins its two case systems - ICE360 for complaints and breach reports, Crimson for cyber investigations - so files from that quarter carry ICE_ and CRIMSON_ prefixes while earlier files use a flat 4-6 column schema. That is the main reason there are 19 distinct header shapes as published (18 once trailing whitespace in header names is trimmed).
• Encoding. Three of the 41 files are not valid UTF-8 and need a cp1252 fallback. One of them is genuinely mixed - UTF-8 byte sequences inside an otherwise cp1252 file - so a whole-file cp1252 read mangles an en-dash that is not damaged at source. Repair is done per field, and the string as read is preserved in the dataset beside the repaired one.
• Quarters with a file and no cases. 21 quarterly investigation files were published but only 20 quarters contain a closure; Jan-Mar 2025 (Q1) is annotation-only. It stays in the series as an explicit zero, because dropping it shortens the series and inflates the recent-quarters share.
• The incidents data set has no Jan-Mar 2021 file at all: the ICO states on the landing page that no relevant cases were held for that period. The two series do not cover the same span.
• Coverage of the fields we do not use: sector is present on 11.72% of investigations and the Crimson start date on 17.57%. The closure date is present on 100.0%. Those coverage figures are why the sector breakdown and every duration metric are dropped - the drop is about start-date coverage, not closure-date coverage.
• No pound figure is derivable. 'Final Value' is 0 or blank on 956 of 956 investigations, including all 10 penalty-track rows.
• Denominator sensitivity. 81 of the 956 rows (8.47%) record an administrative closure rather than a worked case - no personal data, a duplicate record, documents pasted into an existing case, or a record created in error. Excluding all four the penalty rate is 10 of 875 (1.14%) rather than 1.05%, so the headline does not turn on whether they are counted.
• No escalation rate. Dividing closed investigations by closed incidents would look like one and is not: the two are separate publications with different inclusion rules, the incidents series is missing its first quarter entirely, and neither file records whether a given incident later became an investigation. Any such ratio measures ICO publication practice, not case escalation. Bristows published one (9% of 2022 cyber incidents); we do not repeat it, and this is why.
• No trend claim. The published data cannot distinguish the ICO handling fewer cases from the ICO publishing fewer cases, so no statement about enforcement rising or falling is made here.

Rows dropped, listed one by one

A row counts as a case only where its case-reference column holds an ICO case reference. That rule removed 4 rows from all 41 files, and every one of them is printed here rather than summarised.

Scroll the table sideways to see every column →

From Q4 2022-23 the ICO joins ICE360 and Crimson, so the file schema changes. 19 distinct header shapes as published, 18 trimmed. The outcome column is named 'Investigation Outcome Desc', 'CRIMSON_InvestigationOutcome' or 'CRIMSON Investigation Outcome' depending on the quarter. 3 files decoded as cp1252; 38 files decoded as utf-8-sig. Repair is per field, not per file: 3 rows carry one mojibaked outcome string, read as “Closed after intervention–in line with RAP” and repaired to “Closed after intervention–in line with RAP”, with both kept in the dataset. The ICO's quarterly files are static once published. Every row of the published dataset carries the sha256 of the file it came from, so a revision is detectable rather than silent. If a hash stops matching, the study is re-run and re-dated rather than patched.

Where this page departs from what we set out to publish, reported rather than reconciled

The “study brief” and the working notes below are Servnet’s own unpublished planning documents for this study, written before the files were parsed. They are not a source and are not published; they are named here only so that the changes made after the data came back are on the record rather than quietly absorbed.

Scroll the table sideways to see every column →

Sources

Scroll the table sideways to see every column →

Attribution, as required by the licence: “Information Commissioner's Office, Cyber investigations and Cyber incidents quarterly data sets, published January 2021 to March 2026, licensed under the Open Government Licence.” The ICO's grant covers text content and refuses image re-use. No ICO image, chart or screenshot is reproduced. The Open Government Licence deed itself was linked and never fetched, because The National Archives publishes a signal asking that its pages are not used as AI input. Downloads: CSV, 1,752 rows · README and attribution · JSON. The dataset contains no organisation names, individual names, contact details or any other personal data.

Questions about the ICO cyber caseload

Cases, not reports

This study counts cases the regulator worked and closed. For the other side of the same pipeline - the personal data breach reports organisations made to the ICO - see our study of the ICO's data security incident trends. The two count different things - reports received against cases closed - but they are not disjoint sets, and we do not claim they are. The ICO says of the cyber files that "cyber investigations usually originate from a data protection complaint or self-reported data breach case", and that from Q4 2022-23 those files carry the originating ICE360 record alongside the Crimson one, so a case counted here may also sit inside the breach reports counted there, and we have not measured how often. The ICO separately says of the breach-report data that "under specific circumstances some cases are transferred to a separate system for review" and "are not included within this data". It does not name that system in the same place; treating it as Crimson, the system these cyber files come from, is our reading and not an ICO statement.

More Servnet research · Corrections and takedown policy