Regulation
UK may make software vendors liable for breaches
The UK budget commits to a 2027 consultation on who pays when insecure software causes a breach. What is proposed, what is not, and what to change in contracts now.
The UK budget published on October 28, 2026 contains one sentence that matters to anyone who buys or ships software: "Building on the Law Commission's product liability consultation, the government will consult next year on how to tackle insecure technology at source and consider where liability for cyber breaches should sit." It sits in the AI and cyber section of the budget document, alongside new money for the National Cyber Security Centre (NCSC).
This is a promise to consult, nothing more. There is no draft law, no start date and no named lead department. The Record describes it as a shift away from years of relying on voluntary codes. For buyers, the contract terms that would matter under any version of the rule can be negotiated today.
What the budget actually commits to
The liability line is a single bullet. According to The Record, HM Treasury declined to comment, and it is still open whether ministers want a civil liability regime (customers suing vendors for damage), statutory duties on vendors enforced by a regulator, or both. The Record also reports that one option likely to be considered is widening the Product Security and Telecommunications Infrastructure (PSTI) Act, which since 2024 has set basic security rules for consumer smart devices, and that officials expect to keep any UK rules compatible with the EU's.
The same section funds the defensive side. The budget lists £154 million for cyber defences: £70 million for a National Exposure and Real-Time Vulnerability (NERV) Centre at the NCSC to find vulnerabilities across critical infrastructure and the wider economy, £60 million for the first phase of a national Cyber Shield built on agentic AI (including a £25 million challenge fund), and £24 million to harden public sector systems in councils, hospitals and schools. A separate £40 million goes to a National Agentic Security Unit to detect and respond to rogue AI agents.
The backdrop is the 2025 Jaguar Land Rover attack. The Cyber Monitoring Centre estimated it cost the UK economy about £1.9 billion and affected more than 5,000 UK organisations, after production stopped on September 1, 2025 for around five weeks.
How liability could reach software
Three tracks already in motion show what the 2027 consultation will build on.
The Law Commission review. The Law Commission of England and Wales opened its product liability consultation on October 8, 2026, and it closes on January 14, 2027. Today the Consumer Protection Act 1987 makes producers strictly liable for defective products, meaning a consumer does not have to prove fault. The Commission proposes that "product" should include software and AI systems however they are supplied, by download or remote access included. It also proposes compensation for destruction or corruption of data and for property used for both private and work purposes, a rebuttable presumption of defect where proving one is exceptionally hard, and a reset of the ten-year long-stop when a producer substantially modifies a product after supply. Online marketplaces and UK authorised representatives could also be liable. A final report is expected in late 2027, and any change to the 1987 Act would then need legislation.
The EU product liability rules. Directive (EU) 2024/2853 must be in member states' national law by December 9, 2026. It treats software as a product, can make a product defective when the manufacturer fails to supply security updates that are within its control, and does not let that liability be excluded by contract. Any UK vendor selling into the EU meets this first. The EU Cyber Resilience Act adds product security duties from December 11, 2027; its vulnerability reporting rules are already live, which we covered in our CRA reporting post.
What is not covered yet. The Cyber Security and Resilience Bill, now in the House of Lords, extends the UK's network and information systems rules to managed service providers and data centres. It regulates operators and their suppliers, not software developers as such, which leaves the gap the budget pledge points at.
What buyers can put in contracts now
The voluntary Software Security Code of Practice, published by the Department for Science, Innovation and Technology (DSIT) and the NCSC in May 2025, gives buyers a ready-made yardstick. It has 14 principles in four themes, and the government explicitly says customers may use them in negotiations and contracts. A vendor can fill in a self-assessment form against it, and a certification scheme is in development.
At renewal or in a new deal, ask for:
- The vendor's completed self-assessment against the code, and the name of the senior responsible owner it requires.
- A software bill of materials (SBOM), a machine-readable list of the third-party components in the product. Principle 1.2 expects vendors to understand their software's composition, so the list should exist.
- Patch timelines by severity written into the service levels, with a clock that starts at the vendor's awareness and covers actively exploited flaws separately. Principle 3.5 asks for "timely" updates, which is too vague to enforce.
- A security warranty: the product follows a named secure development framework and ships with secure defaults (principles 1.1 and 1.4), with the remedy for breach of that warranty stated.
- An indemnity for losses caused by a vendor security defect, with its cap set apart from the general liability cap. Check whether the vendor's standard terms cap or exclude it today.
- At least one year's notice before end of support (principle 4.2) and notice of notable incidents that may affect you (principle 4.3), with a named contact and a deadline.
What to document if you ship software
If the UK follows the Law Commission and the EU directive, a claim will turn on whether your product was defective and whether you kept it secure after release. Where the proposed presumption of defect applies, your records are the answer to it. Keep:
- The secure development framework you follow, with threat models and code review records per release.
- An SBOM generated at build time for every shipped version, and a record of how you triaged vulnerable components.
- Test results for each release and each update, including security tests.
- A published vulnerability disclosure policy, the reports received and the time from report to fix.
- Your update history: what was fixed, when it was released, how customers were told.
- The support period you promised for each version, and when you announced end of support.
What is not yet known
Nobody yet knows whether a UK rule would let businesses recover their own breach losses from a vendor, or only consumers. The Law Commission paper reforms the Consumer Protection Act, a regime built to protect consumers, and the budget line does not say. How open source would be treated, whether a regulator would get fining powers, and which department leads are all left to the 2027 consultation. Treat any vendor claim that the question is settled with suspicion.
If you want help testing what your suppliers tell you, or building the evidence trail for your own product, see our compliance and audit readiness and code review work. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: HM Treasury: Budget 2026, The Record, Law Commission: Product liability, Pinsent Masons on the Law Commission consultation, DSIT and NCSC: Software Security Code of Practice, Reed Smith on the EU Product Liability Directive, Covington: EU member states roll out new product liability rules, Compliance Hub on the Cyber Security and Resilience Bill, Express and Star on the Cyber Monitoring Centre JLR estimate, NBC News on the JLR attack.