Buried in Wednesday’s Budget is a commitment to consult in 2027 on who should carry the cost when insecure technology leads to a cyber breach. The Record describes it as the first formal pledge by a UK government to examine breach liability, and it changes the conversation every buyer of software should be having with suppliers.
What happened
The Budget published on 28 October 2026 contains a short passage that could matter more to the security industry than any of the spending lines around it. In its section on AI and cyber resilience, the Treasury says it “will consult next year on how to tackle insecure technology at source”, building on the Law Commission’s product liability work, and will weigh up who ought to bear liability when breaches happen.
The Record, which reported the commitment, notes that the pledge occupies just one bullet point in a 166-page document. Much remains undecided: no lead department or start date has been named, and there is no hint whether ministers prefer civil liability, statutory duties on vendors, or both.
The Budget also confirms £154 million for cyber defences, much of it announced beforehand. The liability commitment is the genuinely new part.
The detail
Three strands of existing work feed into the consultation.
The first is the Law Commission of England and Wales review of the Consumer Protection Act 1987. Its consultation opened on 8 October and runs until 14 January 2027. The 1987 Act defines a product as goods or electricity, which leaves software, cloud services and AI in a grey zone. The Commission provisionally proposes that software and AI systems count as products however they are delivered, including by download or as a service, and asks whether the developer should be treated as the producer. Other proposals include a rebuttable presumption of defect in exceptionally hard evidential cases, compensation for corrupted data, and the prospect that a faulty update, or a missing one, could render a product defective. A final report is not expected until late 2027.
That regime is aimed at consumers. Claims cover death, personal injury and damage to private property, with data loss proposed as an addition. It would not, on its own, let a manufacturer recover losses from a ransomware outage traced to a supplier’s flawed code. That is why the Budget’s broader wording matters: it reaches beyond consumer redress.
The second strand is the voluntary Software Security Code of Practice backed by the NCSC. In November 2025 the Commons Business and Trade Committee urged ministers to put that code on a statutory footing with penalties, arguing that vendors face no consequence for shipping exploitable flaws. NCSC chief technology officer Ollie Whitehouse has long argued that the market does not reward secure products.
The third is the Product Security and Telecommunications Infrastructure (PSTI) Act, which has set baseline security rules for consumer connected devices since 2024. The Record reports that extending it is one option likely to be examined, and that officials want any UK rules to fit alongside the EU’s regime. That regime is now substantial: the Cyber Resilience Act carries penalties reaching €15 million or 2.5% of worldwide turnover, with its main obligations biting from December 2027, and the revised EU Product Liability Directive extends strict liability to software.
Why it matters for UK organisations
For years UK policy on insecure software has relied on encouragement: codes of practice, secure by design guidance and self-assessment. The Cyber Security and Resilience Bill, still in the Lords, regulates operators of essential services and their managed service providers, not the companies that write the code those operators run. The Budget line is the first sign that ministers are prepared to look at the upstream end of the problem.
The Jaguar Land Rover attack in 2025 is estimated to have cost the UK economy £1.9 billion, and the Business and Trade Committee pointed to the M&S and Co-op incidents as evidence that the costs of weak security routinely land on victims and the public.
Expect resistance. According to The Record, the Business Software Alliance, which counts Microsoft, Oracle and AWS as members, has lobbied against vendor liability on innovation grounds, and the biggest suppliers are American, which brings trade sensitivities. Any regime is years away: consultation in 2027, then legislation, then commencement. Organisations should not plan on the law shifting their risk any time soon.
Expert view
When we test networks, the root cause of a serious finding is very often not the client’s configuration but a product that shipped with a default credential, an unauthenticated management interface or a long-known flaw class that the vendor never designed out. Liability is the lever that changes that equation, because it puts a price on the defect at the point where it can be fixed most cheaply.
In my experience, though, the details decide whether a liability regime works. A standard of care that is too vague becomes a gift to litigators and a deterrent to small UK software houses; one that is too narrow lets the big platforms carry on as before. The sensible anchor already exists in the Software Security Code of Practice: a vendor that can show it followed recognised secure development, vulnerability handling and update practices should be in a far stronger position than one that cannot. The consultation also needs to settle end-of-life products, open source maintainers and where a vendor’s defect ends and a customer’s unapplied patch begins.
EU alignment matters too: UK vendors selling into Europe will build to the Cyber Resilience Act anyway, and a divergent UK scheme would add cost, not security.
What to do now
- Respond to the Law Commission. If you develop or buy software, the consultation closes on 14 January 2027. Its definitions of product, producer and defect will shape whatever follows.
- Ask suppliers for evidence now. Request a self-assessment against the Software Security Code of Practice, a published vulnerability disclosure policy and, where available, a software bill of materials. Record the answers in your supplier risk register.
- Tighten contracts at renewal. Agree written commitments on security update timelines, end-of-support dates, incident notification and how liability for vendor-caused breaches is capped or excluded today.
- Keep your own house in order. Cyber Essentials requires software to be licensed and supported, with high and critical updates applied within 14 days, and products configured securely with default passwords changed. Any future liability test will look hard at whether the customer patched.
- If you are a vendor, prepare. Map your secure development lifecycle to the code of practice and the Cyber Resilience Act, and document it. Evidence of good practice is likely to be your strongest defence.
- Brief the board and your broker. Recovery from suppliers may become possible one day; today’s contracts and policies still assume you absorb the loss.
Bottom line
One Treasury sentence creates no liability, and the consultation will be fiercely contested. But the UK government has now said in writing that it will consider where the cost of insecure technology should fall. Buyers should use that signal to raise expectations of suppliers today, and vendors should assume the voluntary era has a shelf life.
Sources
- HM Treasury: Budget 2026
- The Record: UK to look at making software companies liable for cyber breaches
- Lewis Silkin: Law Commission proposes major reform of product liability law for the digital age
- Pinsent Masons Out-Law: Law Commission looks to bring AI within UK product liability regime
- Infosecurity Magazine: UK Report Proposes Liability For Software Provider Insecurity
