Five Years Of Attacks Put Police Data At Risk. None Was A Direct Attack On A Police System.
His Majesty's Inspectorate of Constabulary and Fire & Rescue Services published its cybersecurity inspection on 27 October 2026. Section 5 contains the sentence that should travel furthest outside policing. The Police Digital Service and the National Police Chiefs' Council gave inspectors information on multiple cyberattacks between 2021 and 2025 in which police data was at risk. None of them involved a direct attack on a police ICT system. It was the third-party ICT supply chains holding police information that had been compromised. Separately, inspectors examined supplier contracts across the organisations they inspected and found that most third-party contractual arrangements contained no ongoing cybersecurity assurance at all. Read together, this is not a policing story. It is a public audit of the assurance model that most UK organisations are quietly running.
What happened
On 27 October 2026 His Majesty's Inspectorate of Constabulary and Fire & Rescue Services published "Cybersecurity in police forces and fire and rescue services". The inspection ran from January to May 2026, with fieldwork in three police forces and three fire and rescue services, over 30 interviews, more than 260 documents scrutinised and over 1,250 pieces of evidence assessed. The report makes 13 recommendations. Michelle Skeer, His Majesty's Inspector of Constabulary, framed it plainly: "The cyber threat to police forces and fire and rescue services is significant and expanding rapidly."
Most of the coverage has led on legacy systems, weak password management and senior leaders who do not treat cybersecurity as part of daily operational decisions. All of that is in the report and all of it is familiar. The passage worth reading twice sits in section 5. The inspectorate records that the Police Digital Service and the National Police Chiefs' Council "shared information on multiple cyberattacks that happened between 2021 and 2025 in which police data was at risk". It then states: "None involved a direct attack on police ICT systems. Worryingly, it was the third-party ICT supply chains which held police information that had been compromised."
Be precise about what that does and does not say. It does not say how many attacks there were, does not name a single supplier or force, and does not confirm that data was stolen, only that it was at risk; the inspectorate says it removed operational detail unsuitable for the public domain. What survives that redaction is a direction of travel, and the direction is unambiguous. Over a five year window, the attacks that reached police information did not arrive through the front door of policing. They arrived through organisations policing pays.
- 2021 to 2025The window in which the Police Digital Service and the National Police Chiefs' Council say multiple cyberattacks put police data at risk. None involved a direct attack on police ICT systems; the compromised systems were third-party ICT supply chains holding police information. The police handled these as critical incidents under the national "Defend as one" co-ordination plan.
- January to May 2026HMICFRS carries out the inspection: fieldwork in three police forces and three fire and rescue services, over 30 interviews and over 1,250 pieces of evidence assessed.
- January to March 2026Police Digital Service data records 252 cybersecurity incidents affecting policing and 796 near misses in the same quarter. The report defines a near miss as an incident in which there was "no harmful data or ICT systems breach". It does not break either figure down by data loss.
- 27 October 2026The report is published with 13 recommendations. Most are directed at the National Police Chiefs' Council, the National Fire Chiefs Council, chief constables, chief fire officers and the Ministry of Housing, Communities and Local Government.
- By May 2027Recommendation 10 requires each chief constable in England and Wales to "review existing police ICT contracts and procurement processes, and improve those that don't include adequate cybersecurity assurance", and to adopt Secure by Design and the Police Digital Service's Third-Party Assurance for Policing standards. Recommendation 9 requires chief fire officers in England to ensure new or renewed contracts with public sector partners or private sector third-party suppliers meet Cyber Essentials and Secure by Design.
- By September 2028Recommendation 3 requires each chief constable in England and Wales to make sure their force achieves and then maintains a Security Assessment for Policing framework maturity level of at least 3.0.
Why this one is different
The usual supply chain briefing has a named vendor, a CVE and a patch. This one has none of those, and that is why it is more useful. The inspectorate was not investigating an incident. It was auditing how an entire sector decides whether its suppliers are secure, and it published the answer. That answer describes a control failure rather than a technical one, which means it transfers cleanly to any organisation that buys ICT.
Start with the structural point, because most boards have never been shown it. The Police Digital Service told inspectors that police data held on third-party suppliers' ICT systems "was one of the most significant cybersecurity risks to policing". Its stated reason is not that suppliers are careless. It is that "this data and the systems that hold it aren't included in the PDS's protective monitoring". Policing runs a national security operations centre, and one of the risks it names as most significant is data that centre cannot see. The exposure is not a gap in capability. It is a boundary.
That boundary produced a consistent set of findings. Inspectors found examples where organisations lacked full visibility of hosting arrangements; where suppliers controlled critical parts of the ICT infrastructure; where logging of user activity for third-party systems was incomplete or outdated; where monitoring coverage was inconsistent; where responsibility for resilience and recovery was not clearly understood; and where assurance "relied heavily on supplier self-certification". Each item is mundane in isolation. Together they describe an organisation that has outsourced a system and, without deciding to, outsourced the knowledge of whether it is safe.
The inspectorate draws the conclusion that most internal security programmes are built to avoid drawing: "Even if the organisation has strong internal controls, it may still be vulnerable to compromise if a supplier's network is breached." Maturity in your own environment does not reduce the exposure sitting in someone else's. The five year record in section 5 is what that looks like when it runs long enough.
Commercial exposure for UK organisations
The regulatory position is the easiest part to state and the most frequently misunderstood. When a supplier processes personal data on your behalf, you remain the controller and the breach is yours to notify. The ICO's guidance is direct: you "must report a notifiable breach to the ICO without undue delay, but not later than 72 hours after becoming aware of it", and if you take longer you must give reasons for the delay. Your processor, under Article 33(2), "must inform you without undue delay as soon as it becomes aware". That clause is the whole dependency. If your supplier is slow, ambiguous or contractually unbound, the clock still runs against you and you are the one explaining the delay.
Which makes the inspectorate's contractual findings more than administrative tidiness. When inspectors examined supplier contracts across the organisations they inspected, they found significant variation in seven areas: reporting timescales for cybersecurity breaches, audit and inspection rights, data retention requirements, incident notification obligations, access to logs and monitoring information, allocation of monitoring and detection responsibilities, and liability for cybersecurity incidents. The ICO is clear that "the requirements on breach reporting should be detailed in the contract between you and your processor, as required under Article 28". Those seven headings are where an organisation discovers, mid-incident, what it actually bought.
Worse, inspectors found organisations that could not locate the original contract documentation for systems provided through shared services or national arrangements. Personnel could not confirm what security obligations applied, what access control standards had been agreed, or whether the supplier was required to notify them promptly of an incident. This, the inspectorate says, "left forces and services unable to determine whether suppliers were meeting minimum expectations for detection, reporting and resilience. Or whether the contractual terms provided the influence needed to demand improvement." Influence is the commercially important word. A contract you cannot find is a contract you cannot enforce.
Then there is the certificate problem, which is replicated far outside policing. Inspectors found "widespread reliance on supplier self-certification without independent verification, such as accepting the CE/CE+ government cybersecurity standards and ISO 27001 certification without checking how recently they had been achieved or awarded". Organisations also relied on supplier assurances about patching, accepted data protection impact assessments at face value, and did not request annual confirmation of controls. The inspectorate's verdict runs to three words: "This isn't satisfactory." It adds that self-certification has value but "can't be relied on as the sole form of assurance". A certificate evidences a point in time and a defined scope. Treated as a standing guarantee, it becomes a way of not asking.
There is a second commercial reading, and it points the other way. If you sell ICT, software or managed services into UK policing or the English fire and rescue sector, these recommendations are a procurement signal with dates attached. By May 2027 chief constables are to have improved contracts lacking adequate cybersecurity assurance and adopted the Third-Party Assurance for Policing standards, and chief fire officers are to ensure new or renewed contracts with public sector partners or private sector suppliers meet Cyber Essentials and Secure by Design. Suppliers who can evidence current certification, named notification timescales, log access and a recovery commitment will clear those gates. Suppliers relying on a certificate issued three years ago will find the renewal conversation has changed shape. Assurance maturity is becoming a qualifier for revenue, not an overhead against it.
What leaders should do now
None of what follows needs a vendor, a patch or a procurement cycle, and all of it is cheaper this quarter than during a notification decision taken against a 72 hour clock.
- Action 1 · List the suppliers holding your sensitive data, not the ones you pay the mostInspectors found organisations lacking full visibility of their own hosting arrangements. Spend is a poor proxy for exposure. Rank by what the supplier holds and by whether a compromise there would stop you operating.
- Action 2 · Find the incident notification clause in each of those contracts and read itInspectors found personnel who could not confirm whether a supplier was required to notify them promptly. You need the trigger, the timescale and the named recipient. Article 33(2) obliges the processor to inform you without undue delay; your contract is what makes that operational.
- Action 3 · Put a date and a scope against every supplier certificate you holdCyber Essentials, Cyber Essentials Plus and ISO 27001 were being accepted with no check on how recently they had been achieved. Record the award date, what the scope statement covers and the next renewal beside each supplier name. It takes an afternoon and usually surfaces a surprise.
- Action 4 · Establish whose monitoring covers the supplier's systemThe Police Digital Service named supplier-held data as one of its most significant risks precisely because it sits outside its protective monitoring, and inspectors found logging of user activity for third-party systems incomplete or outdated. If nobody can name the monitoring and the log retention period, assume there is none.
- Action 5 · Name in writing who restores what, and how quicklyInspectors found responsibility for resilience and recovery was not clearly understood, and some organisations were uncertain how soon a hosted system would return after an attack. A recovery time you have never tested or contractually fixed is an assumption, not a plan.
- Action 6 · Attach ongoing assurance to the renewal, not the procurementMost third-party contractual arrangements carried no ongoing cybersecurity assurance at all. Due diligence performed once, at signature, decays from that day. Your renewal calendar is the only place in the business where this change is close to free.
The ordering matters. One to three are an inventory exercise needing a spreadsheet, a contracts folder and an afternoon, and they are what reveals the size of the problem. Four and five are the most likely to be skipped and the most likely to matter on the day, because they establish who would notice an intrusion and who would end it. Six is the only one that changes anything permanently, and it costs nothing attached to renewals you were processing anyway.
Three questions for the board
Which suppliers hold our sensitive data, and when did we last verify their security independently rather than accept their certificate? If the answer is procurement, and procurement was over twelve months ago, you are running the model the inspectorate called unsatisfactory.
If a supplier is breached on a Friday afternoon, what in the contract obliges them to tell us, by when, and what happens if they do not? The 72 hour clock starts when you become aware. Everything upstream of that moment is governed by a clause somebody signed.
Whose monitoring covers the systems our data sits on, and can we see the logs? Policing runs a national monitoring capability and still named supplier-held data a top risk, because that data sits outside it. Ask whether your own answer is better.
Strategic takeaway
Supply chain risk is usually sold to boards as a story about attackers getting cleverer. The inspectorate's version is less dramatic and more useful. Over five years, every attack it was told about that put police data at risk reached that data through a supplier, and the governing contracts mostly required nobody to check that the supplier was still secure. No single bad decision was taken. A series of reasonable ones, made at procurement and never revisited, produced an estate where the most sensitive data sat furthest from the monitoring.
The repair is contractual rather than technical, which is why it keeps being deferred. It has no launch, no product and no obvious owner, and it competes with work that produces a demonstration. But organisations that do it acquire what no security tool provides: the ability to answer, on the day it matters, what a supplier was obliged to do and when. The inspectorate has now put dates against that work for one sector. Every other UK board is free to set its own, and it is considerably cheaper to do so before a regulator or a client sets one for them.
Confidence note
Written to separate what is established from what is assessed, with the primary report read in full in its HTML edition. Confirmed findings: HMICFRS published "Cybersecurity in police forces and fire and rescue services" on 27 October 2026 with 13 recommendations, following an inspection conducted between January and May 2026 involving fieldwork in three police forces and three fire and rescue services, over 30 interviews, over 70 further consultees, more than 260 documents and over 1,250 pieces of evidence; section 5 states that the Police Digital Service and the National Police Chiefs' Council shared information on multiple cyberattacks between 2021 and 2025 in which police data was at risk, that "None involved a direct attack on police ICT systems", and that it was the third-party ICT supply chains holding police information that had been compromised; that most third-party contractual arrangements did not include any ongoing cybersecurity assurance arrangements; that there was widespread reliance on supplier self-certification without independent verification, including acceptance of CE, CE+ and ISO 27001 without checking recency; that the Police Digital Service identified supplier-held police data as one of the most significant risks to policing because it falls outside its protective monitoring; the list of seven contractual areas found to vary significantly; and Police Digital Service data, reported in section 1, showing 252 cybersecurity incidents and 796 near misses affecting policing between January and March 2026. Recommendation numbering, wording and deadlines are quoted from the report. Scope qualifications: the figure of zero direct attacks is the report's word "none" expressed numerically and is scoped only to the cases the two bodies shared with inspectors; the report does not state how many attacks there were, does not name any supplier or force, does not confirm that data was exfiltrated as opposed to put at risk, and states that operational detail was removed before publication. The report does not use the words "every case" or "all"; where this briefing and its graphics set NONE against the supply chain finding, that contrast is a summary of the report's own two-sentence construction and is GCS's framing, not a quoted finding. The 252 and 796 figures are not broken down by data loss. Recommendation 9, which requires Cyber Essentials in new and renewed supplier contracts, applies to chief fire officers in England and not to police forces; some secondary coverage presented it as a general supplier recommendation and it is not one. Deliberately excluded: the global aggregates supplied to inspectors by the National Police Chiefs' Council and the Police Digital Service, such as a cyberattack every 11 seconds, which carry no stated method; the "Wild West" characterisation of third-party suppliers in section 5, which is the recorded view of one interviewed cybersecurity company director rather than an inspectorate finding; and any claim about the current parliamentary stage of the Cyber Security and Resilience Bill, which could not be confirmed against a reliable current source during drafting. On that Bill, this briefing repeats only the report's own position, which is that it was before Parliament at the time of the inspection and that the inspectorate considers it "concerning that the cybersecurity risk facing these sectors isn't mentioned in any of these initiatives". That is a statement about prominence and priority, not a statement that these sectors fall outside the Bill's legal scope, and nothing here should be read as the latter. GCS's own contribution: the reading of the report as a general assurance finding rather than a policing finding, the six actions, the three board questions and the commercial framing throughout are ours, and are not attributed to the inspectorate.
Which of your suppliers hold your sensitive data, and when did anyone last verify their security rather than accept their certificate?
Garzon Cyber Solutions was built around the argument that security, compliance and the people who sustain them are one capability rather than three cost lines. Producing a ranked inventory of the suppliers holding your sensitive data, reading what their contracts actually oblige them to tell you, and putting a date and a scope against every certificate on file are short pieces of work with a long shelf life. All three are considerably cheaper done this quarter than during a client audit or a notification decision taken against a 72 hour clock. If you would like a view on where your data currently sits and what your contracts commit your suppliers to, start a conversation.
Start the Conversation →The inspectorate's wording is quoted directly wherever the distinction between a finding and an assessment matters. Statutory obligations are quoted from the ICO's own guidance rather than paraphrased from memory. Where a figure is the report's word expressed as a number, this briefing says so.
HMICFRS, "Cybersecurity in police forces and fire and rescue services", published 27 October 2026. The primary source throughout, read in full in its HTML edition. Section 5, "Third-party ICT suppliers", is the source for the statement that the Police Digital Service and the National Police Chiefs' Council "shared information on multiple cyberattacks that happened between 2021 and 2025 in which police data was at risk", that "None involved a direct attack on police ICT systems. Worryingly, it was the third-party ICT supply chains which held police information that had been compromised", that police data held on third-party suppliers' systems "was one of the most significant cybersecurity risks to policing" because "this data and the systems that hold it aren't included in the PDS's protective monitoring", that "most of these third-party contractual arrangements didn't include any ongoing cybersecurity assurance arrangements", the six examples of incomplete visibility, logging, monitoring, recovery responsibility and self-certification, the seven areas of significant contractual variation, the finding of "widespread reliance on supplier self-certification without independent verification, such as accepting the CE/CE+ government cybersecurity standards and ISO 27001 certification without checking how recently they had been achieved or awarded", the verdict "This isn't satisfactory", the statement that self-certification "can't be relied on as the sole form of assurance", and the observation that "Even if the organisation has strong internal controls, it may still be vulnerable to compromise if a supplier's network is breached". Section 9 is the source for the Police Digital Service figures of 252 cybersecurity incidents and 796 near misses between January and March 2026 and for the definition of a near miss as an incident with "no harmful data or ICT systems breach". The foreword and section 1 are the source for the inspectorate's concern that "it is concerning that the cybersecurity risk facing these sectors isn't mentioned in any of these initiatives" and that "the risks to police forces and fire and rescue services aren't properly represented or given a high enough priority". Recommendations 3, 9 and 10 are quoted from the recommendations sections, and the methodology figures from the Methodology section · The Record, Alexander Martin, "Hackers repeatedly breached suppliers holding UK police data, watchdog finds", 27 October 2026, for the first detailed English language report drawing out the supply chain finding, for the note that the inspectorate removed operational details it considered unsuitable for the public domain, and for the record that the Home Office and the National Police Chiefs' Council did not respond to questions about whether police data was compromised in supplier attacks · Infosecurity Magazine, "Watchdog Warns Police and Fire Service Must Urgently Improve Cybersecurity", 27 October 2026, for corroboration of the inspection scope and the recommendation themes. Note that its summary presents mandatory Cyber Essentials certification for ICT suppliers as a general recommendation; in the report this is Recommendation 9, directed at chief fire officers in England, and this briefing follows the report · Emergency Services Times, Catherine Levin, "Blue light readiness for cyber attacks in doubt, says watchdog", 28 October 2026, for the report length, the distribution of the 13 recommendations between the National Police Chiefs' Council and the National Fire Chiefs Council, and for the Police Digital Service's own response to the report · Deeside.com, 27 October 2026, for corroboration of the Police Digital Service figures of 252 incidents and 796 near misses for January to March 2026, for the Security Assessment for Policing scale running from 1.0 to 5.0 with a current minimum of 2.0, and for the September 2028 deadline attaching to maturity level 3.0 · ICO, "Personal data breaches: a guide", quoted for the controller's duty to "report a notifiable breach to the ICO without undue delay, but not later than 72 hours after becoming aware of it", for the requirement to give reasons where that is exceeded, for the processor's duty under Article 33(2) to "inform you without undue delay as soon as it becomes aware", and for the statement that "the requirements on breach reporting should be detailed in the contract between you and your processor, as required under Article 28"
Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and beyond.