UK Software Supply Chain and AI Security Rules: A 90-Day Plan

Organisations in the United Kingdom secure their software supply chain under a set of separate regimes rather than one law. Operators of essential services answer to the NIS Regulations 2018, which the Cyber Security and Resilience Bill will widen to managed service providers, data centres and designated critical suppliers once it passes. Banks and insurers answer to PRA and FCA outsourcing and operational resilience rules, and since 13 July 2026 four large cloud providers to the financial sector have been overseen directly under the Critical Third Parties regime. Connectable consumer products must meet the PSTI security requirements, government suppliers meet Cyber Essentials, anyone handling personal data answers to UK GDPR, and two voluntary codes of practice now set the government's expectations for software vendors and AI systems.

This guide maps each regime to its regulator, its status in late October 2026 and what it asks of the software you build and buy, then gives each owner a 30/60/90-day plan that works with the tools you already have. This is not legal advice; read the rules with your counsel.

Key takeaways

• The Cyber Security and Resilience Bill is not law yet. Introduced on 12 November 2025, it passed the Commons on 16 June 2026 and reached Lords report stage on 26 October 2026. It adds a 24-hour initial incident notice and a 72-hour full report.
• The NIS Regulations 2018 apply today, with a 72-hour report to the competent authority for significant incidents.
• The Software Security Code of Practice is voluntary but specific. Published on 7 May 2025, it sets 14 principles across four themes, including understanding the composition of your software (principle 1.2), protecting the build environment (2.1 and 2.2) and at least one year's notice before support ends (4.2).
• Financial services has its own chain of rules. PRA SS2/21 on outsourcing and third party risk management, the PRA and FCA operational resilience rules (firms had until 31 March 2025 to be able to stay within impact tolerances), and the Critical Third Parties regime, whose first designations took effect on 13 July 2026. DORA is an EU regulation; it reaches a UK firm only through its EU operations.
• PSTI has applied to consumer connectable products since 29 April 2024: no universal default passwords, a published way to report vulnerabilities, and a stated security update period.
• AI security is guided, not legislated. The AI Cyber Security Code of Practice (31 January 2025) is voluntary, with 13 principles. There is no horizontal UK AI statute, and no government AI bill is before Parliament.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, autonomous remediation (ships switched off), TPRM with SBOM requests and vendor monitoring, CSAF and VEX upload, the compliance and GRC suite with UK Cyber Essentials, NCSC CAF and UK GDPR frameworks, Trust Center, AI-BOM discovery, AI Gateway, MCP Guardrail, Package Firewall, the Safeguard CLI and local runner, and on-prem, air-gapped and Zero AI deployment options.

Who this applies to in the United Kingdom

UK rules attach to what an organisation does, not to the technology it uses. The same SaaS product can be outside every statute when sold to a retailer and inside two when sold to a water company or a bank.

Two scoping points trip up international teams. The UK left the EU, so NIS2, the Cyber Resilience Act and DORA do not apply to the UK as such; a UK group meets them only through its EU business. And several UK regimes reach suppliers based abroad: a relevant managed service provider is one providing managed services in the UK "whether or not the person is established in the UK", and PSTI applies to products made available to UK consumers wherever the maker sits.

The rules, regulator by regulator

Every status in this section was checked on the primary source on 25 and 26 October 2026. Where a regime is still a bill or a voluntary code, it is described as one.

Cyber Security and Resilience (Network and Information Systems) Bill

Status: a bill before Parliament. The Parliament bills site records Commons first reading on 12 November 2025, a carry-over into the new session (reintroduced 14 May 2026), Commons third reading on 16 June 2026, Lords committee in September 2026 and Lords report stage from 26 October 2026. It has not received Royal Assent, and much detail will follow in secondary legislation.

It amends the NIS Regulations 2018. The government's factsheets, last updated on 30 June 2026, describe the main changes:

• Managed service providers. Medium and large providers that meet the definition of a relevant managed service provider come into scope. Small and micro enterprises are excluded. The Information Commission will regulate them.
• Data centres. Data infrastructure becomes a NIS sector, with data centres at or above 1 MW of rated IT load in scope (enterprise data centres have a higher threshold), and Ofcom as regulator.
• Designated critical suppliers. A regulator can designate a supplier to an operator of essential services, a relevant digital service provider or a relevant managed service provider when disruption to that supplier's systems could significantly affect the economy or daily life in any part of the UK, and the goods or services could not realistically be sourced elsewhere.
• Incident reporting. A light-touch initial notification within 24 hours of becoming aware of an incident, sent to the regulator with the NCSC sighted at the same time, followed by a fuller report within 72 hours. More incident types become reportable, including ransomware and pre-positioning that could have a significant impact even before it causes disruption. Data centres, relevant managed service providers and relevant digital service providers must also tell customers who are likely to have been affected.
• Enforcement. The current three penalty bands, with a top fine of 17 million pounds, become two: up to 17 million pounds or 4% of worldwide turnover, whichever is higher, for the more serious breaches, and up to 10 million pounds or 2% for the rest.

For a software team, the message is that customers in scope will ask harder questions sooner, and a 24-hour clock rewards anyone who can answer "do we run the affected component?" in minutes.

The NIS Regulations 2018, as they apply today

Status: in force since 2018 (SI 2018/506). The government's summary factsheet describes the current scope: operators of essential services in energy, transport, health, drinking water and digital infrastructure, plus online marketplaces, online search engines and cloud computing services. In-scope organisations must take appropriate and proportionate measures to secure the network and information systems their service relies on and report incidents that significantly disrupt the service to their competent authority within 72 hours. Today's top penalty is 17 million pounds.

The regulations do not mention SBOMs or open source. The duty is outcome based, and the NCSC Cyber Assessment Framework is where supply chain and asset expectations become concrete.

Software Security Code of Practice

Status: voluntary, published 7 May 2025, page updated 15 January 2026. The code was published by the Department for Science, Innovation and Technology with the NCSC. It applies to vendors of software and software services, and it asks a Senior Responsible Owner at senior leadership level to gain assurance that the organisation meets 14 principles across four themes:

1. Secure design and development. Follow an established secure development framework (1.1). Understand the composition of the software and assess risks from ingesting and maintaining third-party components throughout the lifecycle (1.2). Test software and updates before distribution (1.3). Follow secure by design and secure by default principles (1.4).
2. Build environment security. Protect the build environment against unauthorised access (2.1). Control and log changes to it (2.2).
3. Secure deployment and maintenance. Distribute software securely (3.1). Implement and publish an effective vulnerability disclosure process (3.2). Have processes and documentation for proactively detecting, prioritising and managing vulnerabilities in software components (3.3). Report vulnerabilities to relevant parties where appropriate (3.4). Provide timely security updates, patches and notifications (3.5).
4. Communication with customers. State the level of support and maintenance provided (4.1). Give at least one year's notice before software stops being supported (4.2). Make information available about notable incidents that may significantly affect customers (4.3).

The government provides a self-assessment form, built on the NCSC's principles based assurance approach, that a vendor can share with customers. No law requires the code, but buyers paste its 14 principles into questionnaires.

Financial services: operational resilience, PRA SS2/21 and the Critical Third Parties regime

UK financial firms meet software supply chain risk through three layers of rules, none of them DORA. DORA (EU Regulation 2022/2554) reaches a UK group only through its EU subsidiaries or branches.

Operational resilience. The PRA and the FCA (FCA policy statement PS21/3) published their final rules in March 2021. By 31 March 2022 firms had to identify their important business services, set impact tolerances for the maximum tolerable disruption, and map and test to the level needed to do so. By no later than 31 March 2025 they had to have completed the mapping and testing that lets them remain within impact tolerance for each important business service. Third-party software and the open source inside your own applications are part of that mapping.

Outsourcing and third party risk management. PRA Supervisory Statement SS2/21 was first published on 29 March 2021 and took effect on 31 March 2022. It applies to UK banks, building societies, PRA-designated investment firms, Solvency II insurers and UK branches of overseas banks and insurers. It implements the EBA outsourcing guidelines and relevant parts of the EBA ICT and security risk management guidelines, with its own chapters on data security (chapter 7) and business continuity and exit plans (chapter 10). The current version took effect on 31 December 2024, and a further revised version published on 18 March 2026 (PS7/26) takes effect on 18 March 2027, so check which text your next review is against. FCA solo-regulated firms work to the FCA's outsourcing rules.

Critical Third Parties. The Financial Services and Markets Act 2023 gave HM Treasury power to designate a third party as critical when disruption to the services it provides to the financial sector could threaten UK financial stability or confidence. The Bank of England, the PRA and the FCA each published rules for the regime in November 2024 (the PRA's is PS16/24), but the rules bite only on designated firms. The Critical Third Parties (Designation) Regulations 2026 (SI 2026/777) designated four large cloud service providers with effect from 13 July 2026, and the Bank of England updated its CTP page on 10 July 2026. The regulators oversee the services those firms provide to the sector. The regime does not remove a bank's own outsourcing duties: the firm still owns its risk.

Product Security and Telecommunications Infrastructure Act 2022

Status: product security regime in force since 29 April 2024. Part 1 of the Act, with the Product Security (Security Requirements for Relevant Connectable Products) Regulations 2023, requires manufacturers of consumer connectable products to meet three requirements: no universal default passwords; a published point of contact for reporting security issues, with acknowledgement and status updates for reporters; and a published minimum period during which security updates will be provided. Importers and distributors have duties too. The Office for Product Safety and Standards has enforced the regime since 29 April 2024.

A support period promise is only credible if you know which third-party components ship in the firmware and companion app, and whether each will still get fixes until that date.

Cyber Essentials and government contracts

Status: a government-backed certification scheme, required in in-scope government contracts. Cyber Essentials covers firewalls, secure configuration, security update management, user access control and malware protection. Its requirements for IT infrastructure, as cited on Safeguard's framework page, say in-scope software must be licensed and supported, with high and critical security updates applied within 14 days of release.

Since 2014 the government has required suppliers bidding for certain types of public contracts to hold Cyber Essentials or Cyber Essentials Plus, or show equivalent controls. The current note is PPN 014, updated in February 2025 for the Procurement Act 2023, which applies to procurements commenced on or after 24 February 2025. It replaces PPN 09/14 and PPN 09/23 and applies to central government departments, their executive agencies and non-departmental public bodies, and NHS bodies. The update changed terminology, not policy.

For the software supply chain, security update management is the control that hurts: the 14-day window cannot be shown without a current inventory of versions.

NCSC Cyber Assessment Framework

Status: NCSC guidance, used to assess NIS entities and adopted voluntarily elsewhere. The CAF has four objectives (A governance and risk, B protection, C detection, D response and recovery) and 14 principles. The ones that matter most here are A3 asset management, A4 supply chain, B4 system security, C1 security monitoring and D1 response and recovery planning. The current version is 4.0, released on 6 August 2025.

UK GDPR, the Data Protection Act 2018 and the Data (Use and Access) Act 2025

Status: in force; the 2025 Act is being commenced in stages. UK GDPR is the retained version of the EU GDPR, read with the Data Protection Act 2018. The articles that touch software are Article 25 (data protection by design and by default), Article 28 (processors must give sufficient guarantees), Article 30 (records of processing), Article 32 (security of processing appropriate to the risk) and Article 33 (notify the regulator of a personal data breach without undue delay and, where feasible, within 72 hours).

The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025 and has been commenced in four stages. Most of the Part 5 data protection changes, which the government says simplify aspects of UK GDPR and modernise enforcement powers, commenced on 5 February 2026. From 30 September 2026 the office of the Information Commissioner was abolished and its functions moved to the new Information Commission. The Act amends UK GDPR and the DPA 2018 rather than replacing them; Article 32 security and Article 33 breach notification still apply.

AI: the AI Cyber Security Code of Practice and the state of AI regulation

Status: voluntary code, published 31 January 2025. The Code of Practice for the Cyber Security of AI sets 13 principles across the AI lifecycle, from secure design to disposal, and was written to feed a global standard at ETSI. Several principles map directly to supply chain work: principle 5 (identify, track and protect your assets, including models, data and prompts), principle 7 (secure your supply chain), principle 8 (document your data, models and prompts), principle 9 (conduct appropriate testing and evaluation) and principle 11 (maintain regular security updates, patches and mitigations). An implementation guide accompanies it.

There is no horizontal AI statute in the UK. The AI bills listed on the Parliament bills site for the current session are private members' bills, not government bills. In practice existing law applies to AI systems, such as UK GDPR for personal data in training and inference, and sector rules for finance and health. A UK company that places AI systems on the EU market meets the EU AI Act through that market.

Status at a glance

What the rules ask of software and open source

Read side by side, the UK regimes ask for the same handful of things, phrased differently. None of them names a specific SBOM format, and only the voluntary software code speaks directly about component composition. The work is the same either way.

Know what you run, to the component

CAF principle A3, the Cyber Essentials inventory, Software Security Code principle 1.2 and UK GDPR Articles 30 and 32 all presuppose that you know what software processes your data and runs your service. An SBOM per product and release, kept current and with pinned versions, answers all four. A floating version range makes the 14-day patch rule unprovable.

Handle vulnerabilities on a clock

Cyber Essentials gives 14 days for high and critical updates. The Software Security Code asks for a published disclosure process (3.2), a process for detecting and prioritising component vulnerabilities (3.3) and timely updates (3.5). PSTI requires a reporting route with acknowledgement and status updates. Prioritising by known exploitation (CISA KEV, EPSS) and by reachability is how teams keep the clock without patching everything at once.

Manage third parties and report on time

PRA SS2/21, the FCA outsourcing rules, CAF principle A4 and UK GDPR Article 28 hold you responsible for your suppliers. Expect to request SBOMs or component disclosures, hold vulnerability and incident notice terms, and keep exit plans. Today's clocks are 72 hours to the NIS competent authority and, where feasible, 72 hours to the Information Commission for a personal data breach; the Bill adds a 24-hour initial NIS notice. One compromised dependency can start more than one clock.

Build securely, keep data where it must stay, and cover AI

The build environment theme (2.1 and 2.2) and CAF B4 ask that what you ship is what you built: access control and change logging on CI, pinned third-party build steps and signed outputs. UK GDPR Chapter V governs transfers of personal data abroad, so security tools that send code or findings overseas need a processor and transfer assessment. The AI Cyber Security Code adds an AI inventory: models, datasets, prompts, agent tools and model providers, plus testing before release and patching after.

Requirement to evidence

Real public incidents in or affecting the UK, 2023 to 2026

These come from official reporting. They show how supply chain exposure has played out in the UK; they are not a judgement on the organisations involved.

Synnovis pathology services, June 2024

A cyber attack on Synnovis, a pathology provider to the NHS, disrupted services across several London hospitals. The government's critical suppliers factsheet records that a critical incident was declared, over 11,000 appointments and operations were disrupted, an urgent call for blood donors followed, and the company estimated losses of 32.7 million pounds. The government cites it as the reason regulators need power to designate critical suppliers.

Ministry of Defence payroll through a managed service provider, May 2024

The managed service providers factsheet records that in May 2024 an incident involving a managed service provider let attackers target the Ministry of Defence payroll, putting at high risk the personal data of around 270,000 serving personnel, reservists and veterans. It is the government's main example for bringing managed service providers into the NIS regime.

Capita, March 2023, fined in October 2025

Capita, a large outsourcing provider whose services include pension administration, was attacked in March 2023; the ICO says the initial malicious file was downloaded on 22 March 2023 and that 6.6 million people were affected. On 15 October 2025 the ICO fined Capita plc and Capita Pension Solutions Limited a combined 14 million pounds, finding that Capita had failed to ensure the security of processing of personal data. For the organisations that outsourced to Capita, the incident was a supplier incident.

The personas who own the problem

CISO

Answers to the board and, in a NIS entity or regulated firm, to a regulator. Needs a defensible account of third-party and open source exposure: where it is, how it is ranked and how fast it is fixed. Triggers: a CAF assessment cycle, a PRA or FCA question about an important business service, a board question after a public incident and, once the Bill passes, the first 24-hour notice. Should be able to say within an hour of a critical advisory whether the organisation runs the affected component.

Head of AppSec or product security

Owns the vulnerability backlog in first-party code and dependencies and, for a vendor, the evidence behind Software Security Code principles 1.2, 3.2 and 3.3. The bad week starts when a customer questionnaire arrives with the 14 principles pasted in, or a critical CVE lands in a transitive dependency on a Friday. Needs prioritisation that survives scrutiny and fixes that arrive as pull requests.

VP Engineering or Platform

Wants one pipeline gate instead of four review processes. The build environment theme (2.1 and 2.2) lands here: who can change CI, how changes are logged, how third-party build steps are pinned. Usual trigger: a customer audit or an incident in a build tool.

GRC and regulatory affairs

Maps controls to regimes and keeps evidence current between assessments: Cyber Essentials renewal each year, the CAF self-assessment, the operational resilience self-assessment and PRA outsourcing questions. Needs evidence by clause, with dates, that does not have to be rebuilt every cycle.

Procurement and vendor risk

Runs SS2/21 due diligence, CAF A4 supplier mapping and Article 28 processor checks. Needs a tiered vendor register, contract clauses for vulnerability and incident notice, and a standard SBOM ask. Triggers: renewal, a new material outsourcing, a supplier incident in the news.

DPO

Owns the 72-hour clock to the Information Commission and the Article 28 terms. In a supply chain incident needs to know fast which systems processing personal data use the affected component or vendor.

A practical 30/60/90-day plan

This plan works with spreadsheets and open source tools as well as with a platform. Scale each step to your size.

Days 1 to 30: scope, inventory and clocks

1. Decide which regimes apply, using the table above, and record why you judged others out of scope. Check whether your customers will fall under the Bill as managed service providers or critical suppliers.
2. List products and important services: the essential service for a NIS entity, important business services for a financial firm, products sold into the UK for a vendor.
3. Generate an SBOM per product in CycloneDX or SPDX, covering transitive dependencies and container base images, with versions pinned.
4. Write every incident clock on one page (NIS, the Bill's 24 and 72 hours, UK GDPR, PRA and FCA, customer contracts) and name who starts each.
5. Publish or check your vulnerability disclosure policy, and inventory AI: models, providers, datasets and agent tools.

Days 31 to 60: suppliers, gates and prioritisation

1. Tier vendors by the services and data they touch; check audit, information, vulnerability notice and exit terms; request SBOMs and advisory feeds from material suppliers.
2. Add a CI gate for new critical vulnerabilities and unaccepted licences, with an exception route that records approver and expiry.
3. Prioritise the backlog by KEV, EPSS and reachability, with a 14-day target for high and critical items.
4. Lock down the build: CI access review, change logging, third-party steps pinned to digests, signed outputs.
5. Run a tabletop on a compromised dependency or a breached managed service provider, starting each clock.

Days 61 to 90: evidence and the next review

1. Map evidence to clauses for each regime: SBOMs, gate results, fix records, vendor files, disclosure logs.
2. Complete the Software Security Code self-assessment if you sell software.
3. Test one exit plan for a material supplier.
4. Report to the board or SRO on exposure, time to fix, supplier coverage and open gaps, then set the cadence: monthly SBOM refresh at least, quarterly vendor reviews, annual Cyber Essentials renewal.

Decision table: the vendor will not provide an SBOM

How Safeguard does this

Safeguard keeps the inventory, vendor intake, gates, fixes and evidence in one place. Commands and YAML below are copied from docs.safeguard.sh as of 25 October 2026 and were not run for this post.

1. Inventory every product. In the web app, open Integrations and connect repositories, container registries or a manifest. SBOM generation and analysis (GA) and software composition analysis (GA) produce an SBOM per project across the full transitive dependency tree, in CycloneDX or SPDX.

2. Scan where code cannot leave your environment. The Safeguard CLI (GA) includes a local runner (GA). The docs say the runner polls the platform over outbound HTTPS, nothing connects to it, and it uploads only the resulting SBOM and findings, never your source code. Install and sign in as the docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash
safeguard

Then type /login and approve the session in your browser. For a one-off scan of a directory or an existing SBOM:

safeguard scan --dir .
safeguard scan --sbom sbom.json

3. Validate SBOMs from suppliers. The CLI checks CycloneDX and SPDX SBOMs against their specifications:

safeguard validate sbom.json --strict -o report.json

4. Run vendor intake in TPRM. In TPRM (GA), choose Request SBOM on a vendor, select products and a template, set a deadline and send, or bulk request from the Vendors list. TPRM monitoring flags new vulnerabilities in vendor SBOMs, severity changes, exploit availability and CISA KEV additions, which supports the monitoring SS2/21 and CAF A4 expect.

5. Load vendor advisories. With CSAF and VEX upload (GA), go to Integrations, filter by Upload and choose Upload CSAF/VEX.

6. Map evidence to UK frameworks. The compliance and GRC suite (GA) has framework pages for UK Cyber Essentials, UK NCSC CAF and UK GDPR with DPA 2018. Each framework runs scan requirements against a product's SBOM. For Cyber Essentials the docs list checks such as UK-CE-INV (in-scope software inventory), UK-CE-PATCH (security update management against the 14-day rule) and UK-CE-VERS (determinable versions). For the CAF they include UK-CAF-A3 asset management, UK-CAF-A4 supply chain understanding and UK-CAF-B4 build integrity. For UK GDPR they include checks tied to Articles 25, 28, 30, 32 and 33. Each also carries catalogue controls and policy templates. There is no framework page for the Software Security Code, PRA SS2/21 or PSTI in the docs today; map those yourself.

7. Gate what you ship. With policies and gates (GA), create a policy with conditions such as severity, CVSS, EPSS or licence. The docs define three actions: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification is sent). A justified exception goes through the exception workflow with approver notification. In GitHub Actions, the docs show:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs add that --fail-on-gate all fails the job on a policy gate instead of a severity threshold.

8. Rank by real exposure. Vulnerability management (GA) adds EPSS and CISA KEV. Reachability analysis (GA) labels each finding reachable, conditionally reachable, unreachable or unknown, and treats unknown as potentially reachable.

9. Fix with pull requests. Autonomous remediation (GA) uses Griffin to open tested, policy gated pull requests that move a vulnerable dependency to a fixed version, singly or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on.

10. Stop bad packages at install time. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a developer machine or a build.

11. Cover AI assets. AI-BOM discovery (GA) inventories AI assets across code, cloud and SaaS and produces an ML-BOM, which supports principles 5 and 8 of the AI Cyber Security Code. The AI Gateway (GA) is a runtime guardrail proxy for prompt injection, jailbreak and PII egress, and MCP Guardrail (GA) generates guardrail proxy URLs that govern agent tool traffic to MCP servers.

12. Share assurance. Trust Center (GA) publishes a security page with documents released through access requests you approve, for example a Software Security Code self-assessment.

13. Choose where it runs. SaaS runs in multiple regions (US, EU and Gov); there is no UK-hosted region. For UK residency needs, the options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped with the AI models running inside your environment (all GA), the local runner described above, and Zero AI mode (GA), which runs the platform deterministically with no LLM in the loop.

Safeguard becomes one of your suppliers once you adopt it, so assess it under the same SS2/21, CAF A4 or Article 28 process as any other. Its SOC 2 Type II audit is in progress.

What Safeguard does not do

• It does not make you compliant or certified. It produces inventories, findings, gates and evidence. Your Cyber Essentials assessor, competent authority, the PRA, the FCA or the Information Commission judges compliance.
• It is not certified under any UK scheme itself. Safeguard does not hold Cyber Essentials or any other UK certification, and its SOC 2 Type II audit is in progress.
• It has no framework page for the Software Security Code of Practice, PRA SS2/21, the CTP regime or PSTI. The UK Cyber Essentials, NCSC CAF and UK GDPR frameworks are there; the rest is your mapping.
• It does not file incident notices. Deciding whether an incident is significant or a breach is notifiable, and notifying the regulator, stays with you and your counsel.
• It does not fix vendor code or negotiate contracts. Remediation opens pull requests in repositories you own; clauses and fixes inside a supplier's service stay with the supplier.
• It does not host in the UK. SaaS regions are US, EU and Gov. If UK hosting is a requirement, use on-prem, air-gapped or private VPC deployment.

Common mistakes

• Treating DORA as the UK regime. It is EU law. UK firms meet operational resilience through the PRA and FCA rules, SS2/21 and, for designated suppliers, the CTP regime.
• Waiting for the Bill to pass. The 72-hour NIS reporting duty, CAF assessment and Cyber Essentials patch window apply now, and the Bill's 24-hour notice rewards preparation done before commencement.
• An inventory without versions. Floating ranges and "latest" tags make the 14-day patch rule unprovable.
• Using one vendor list. Procurement, IT and engineering each see part of the supplier base. Build the register from spend, data flows and code.
• Assuming a voluntary code will not be asked for. Buyers paste the Software Security Code principles into questionnaires.

FAQ

Is the Cyber Security and Resilience Bill law yet?

No. As of 26 October 2026 it had passed the House of Commons and was at report stage in the House of Lords. It needs to complete its Lords stages and receive Royal Assent, and many details will follow in secondary legislation.

Does the Cyber Security and Resilience Bill require SBOMs?

The bill and its factsheets do not mention SBOMs. They require appropriate and proportionate security measures, supply chain risk management by in-scope entities and faster incident reporting. An SBOM is a practical way to show you know what you run.

What is the incident reporting deadline under UK NIS?

Today, 72 hours to the competent authority for an incident that significantly disrupts the service. Under the Bill, a light-touch notice within 24 hours and a full report within 72 hours, with the NCSC informed at the same time.

Is the Software Security Code of Practice mandatory?

No, it is voluntary. It sets 14 principles across four themes, and the government provides a self-assessment form that vendors can share with customers.

Does DORA apply to UK banks?

Only to their EU operations. In the UK, banks meet operational resilience through the PRA and FCA rules, PRA SS2/21 on outsourcing and third party risk management and, for designated suppliers, the Critical Third Parties regime.

What is the UK Critical Third Parties regime?

A regime added to the Financial Services and Markets Act 2000 by the 2023 Act that lets HM Treasury designate suppliers whose failure could threaten UK financial stability. The Bank of England, the PRA and the FCA oversee designated firms under rules published in November 2024. The first four designations took effect on 13 July 2026.

Does the UK have an AI law?

There is no horizontal AI statute, and the AI bills before Parliament are private members' bills. The AI Cyber Security Code of Practice is voluntary, and existing law such as UK GDPR and sector rules applies.

What changed with the Data (Use and Access) Act 2025?

It amends UK GDPR and the DPA 2018 in stages, with most data protection changes commenced on 5 February 2026, and from 30 September 2026 the Information Commission replaced the ICO. Article 32 security and Article 33 breach notice duties remain.

These rules all come down to knowing what you run and fixing it faster than an attacker can use it. The block below covers that second half for the open source and containers you build, including what to do when upstream has no fix yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For a UK bank or NIS operator that will not connect sensitive repositories to an outside service, this is the route, because only the SBOM and findings leave the machine.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow is how a team keeps a high or critical fix inside the Cyber Essentials 14-day window.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• The UK Cyber Security and Resilience Bill at introduction, November 2025
• The Cyber Security and Resilience Bill at report stage
• The UK Software Security Code of Practice: the 14 principles
• NCSC software supply chain guidance update
• Cyber Essentials and software supply chain controls
• UK PSTI Act: year one review

Sources

• UK Parliament, Cyber Security and Resilience (Network and Information Systems) Bill, bill 4035
• GOV.UK, Cyber Security and Resilience Bill collection
• GOV.UK, Bill factsheets
• GOV.UK, factsheet: incident reporting
• GOV.UK, factsheet: relevant managed service providers
• GOV.UK, factsheet: designating critical suppliers
• GOV.UK, factsheet: data centres
• GOV.UK, factsheet: enforcement
• GOV.UK, factsheet: summary of the Bill
• GOV.UK, Software Security Code of Practice
• GOV.UK, Code of Practice for the Cyber Security of AI
• UK Parliament bills API, bill 4035 stages
• GOV.UK, PPN 014: Cyber Essentials scheme
• GOV.UK, the PSTI product security regime
• GOV.UK, Data (Use and Access) Act 2025: plans for commencement
• NCSC, Cyber Assessment Framework
• Bank of England, Critical third parties
• PRA, SS2/21 Outsourcing and third party risk management
• FCA, PS21/3 Building operational resilience
• ICO, Capita fined 14 million pounds
• Safeguard docs, UK Cyber Essentials framework
• Safeguard docs, UK NCSC CAF framework
• Safeguard docs, UK GDPR and DPA 2018 framework
• Safeguard docs, Local Runner
• Safeguard docs, CLI usage
• Safeguard docs, GitHub Actions
• Safeguard docs, Policies and Gates
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, TPRM Monitoring
• Safeguard docs, CSAF/VEX Upload
• Safeguard docs, Reachability Analysis
• Safeguard docs, AI Remediate
• Safeguard docs, Generate SBOM
• Safeguard docs, Trust Center
• Safeguard docs, Air-Gapped Deployment

Start with the free tier at safeguard.sh/download and read the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.