A new bill, the UK Cyber Security and Resilience Bill, has been in the works for a long time; now it is out, and the UK has just moved from talking about regulating cyber risk to putting real teeth behind it.
The Cyber Security and Resilience (Network and Information Systems) Bill is not your common refresh of the 2018 NIS Regulations (not to be confused with EU NIS2-check the blog below). It establishes who is in scope, how fast you must report, and how hard regulators can hit you if you treat vulnerability management as a box-ticking exercise instead of an operational discipline.
Check out the previous blog and book on NIS2: https://phoenix.security/whitepapers-resources/whitepaper-nis2-risk/
I want to walk you through this as a practitioner, not a lawyer, and translate it into: what this changes for DevSecOps, Vulnerability Management, ASPM, Attack Surface Management, and application security and vulnerability management, and what you should be putting in front of your board.
1. The UK now runs a stack of cyber laws, not a single framework
Let’s take a look at what the state of regulation in the UK.
The UK has multiple cybersecurity laws, each with a distinct focus. The Network and Information Systems (NIS) Regulations cover essential service operators and digital service providers. The Product Security and Telecommunications Infrastructure (PSTI) Act regulates internet-connected consumer products. UK GDPR mandates the security of personal data. Recently, the Cyber Security and Resilience Bill aims to replace the NIS regulations and expand their scope to new sectors like managed service providers, and tighten supply chain requirements.
That paragraph captures the spine of the regime, and it is accurate.
NIS Regulations 2018
NIS 2018 created a legal framework that forces operators of essential services and certain digital service providers to “put in place adequate measures to improve the security of their network and information systems” and to ensure that serious incidents are reported promptly.
PSTI Act 2022
The PSTI Act establishes a security regime for consumer-connectable products, so smart cameras, doorbells, routers, and other IoT devices finally have minimum security requirements backed by law rather than voluntary codes.
UK GDPR
The UK GDPR and the Data Protection Act 2018 focus on the confidentiality, integrity, and availability of personal data, breach notification, and the role of the ICO.
To Consider EU NIS2
The EU NIS2 Legislation establishes similar rules to the UK Cyber Security and Resilience Bill, but those need to be embedded in local regulations.
The new Cyber Security and Resilience Bill sits next to PSTI and UK GDPR but directly on top of NIS. It upgrades and extends NIS rather than creating a parallel universe.
For a CISO or head of application security, that matters because:
- You do not get to pick your regime.
- Different parts of your stack are pulled under different laws.
- Leadership cannot claim “we are covered by GDPR” and ignore operational resilience and vulnerability management.
Download the latest Whitepaper on NIS2
2. What the Cyber Security and Resilience Bill actually does
2.1 Extends NIS into your suppliers
The Bill’s full title makes it explicit: it amends the Network and Information Systems Regulations 2018 and covers “network and information systems used or relied on” to carry out essential activities.
Key structural changes
- Scope broadens from just operators of essential services and a narrow set of digital service providers to include
a. Managed service providers with access to customer environments
b. Data centre operators, now treated as critical national infrastructure
c. Other digital infrastructure that critical sectors rely on - Regulators gain stronger powers to
a. Investigate proactively, not only after a breach
b. Recover costs for supervision and investigations
c. Levy fines up to 4 percent of global annual turnover or 17 million pounds, whichever is higher, for serious failures to prepare or report. - Incident reporting becomes much more aggressive
a. Significant cyberattacks must be reported to the NCSC within 24 hours, with a full report within 72 hours
b. The intent is to use the NCSC Cyber Assessment Framework as the benchmark for what “good” looks like.
This is not just compliance plumbing. Instead, it changes the threat model for MSSPs, cloud and hosting providers and any organisation that leans heavily on third parties for application security testing, monitoring or runtime protection.
If you are building DevSecOps and ASPM workflows, your supplier architecture is now a regulated risk surface, not just a procurement decision.
3. Ransomware, supply chain attacks, and why this Bill exists
The government is very clear on the political driver.
The policy statement and official communications point directly at high-profile ransomware incidents against UK hospitals, government bodies, and essential services and frame them as national resilience failures, not just isolated breaches.
A few important themes jump out
- Systemic risk through suppliers
Managed service providers, SOCs, hosting providers, and SaaS platforms can deliver a blast radius across dozens of essential operators through one compromise. The Bill responds by bringing those entities into scope and giving regulators reach into the supply chain. - Reporting and visibility
Additionally, lawmakers want an early signal on ransomware and extortion cases, not retrospective summaries months later. The 24-hour and 72-hour reporting times force you to industrialise incident response, log retention, and forensic readiness. - Economic framing
Ministers are openly saying that poorly managed cyber risk jeopardises growth and investment. The FT reports government estimates of roughly 14.7 billion pounds per year in economic damage from serious cyberattacks in the UK.
If you lead application security or DevSecOps, that means your work is now firmly in the “protect the business model” bucket, not just “protect the data”.
4. What changes for DevSecOps, ASPM and vulnerability management
Here is the brutal part: you cannot answer this Bill with another policy PDF. You need measurable, defensible evidence that:
- You know where your critical applications and services are
- You know which vulnerabilities matter in context
- You have a credible path from detection to remediation, tied to ownership
4.1 From raw findings to actionable risk
Traditionally, vulnerability management throws CVSS scores and long lists of issues at teams and calls it a day. Under this Bill, that approach is not just inefficient, it does not demonstrate practical approach and due diligence
A modern AST and ASPM style approach should:
- Aggregate vulnerabilities across SAST, DAST, SCA, container scanning, cloud security tools and runtime sensors into a single backlog per team
- Attribute ownership to the right individual
- Enrich each finding with context
a. Reachability from real traffic and code paths
b. Exposure data such as internet-facing, DMZ, internal-only
c. Threat intelligence and exploit signals
d. Business criticality of the asset - Deduplicate across code, image, and runtime views so the same flaw does not appear as three different tickets
- Trace and demonstrate clear ownership, SLAs, and campaign-style remediation plans
And increasingly, boards will start asking not “how many criticals do we have” but “how many exploitable criticals remain on systems that matter, how long do we live with them, and who is making progress or not making progress towards this risk reduction exercise”.
If you are a CISO and your DevSecOps pipeline cannot answer that in two clicks, you have work to do.
4.2 Metrics that actually help you survive regulator scrutiny
To that end, you need metrics that you can defend in front of a regulator and your own board.
Examples that align with the spirit of the Bill
- Coverage
a. Percentage of business-critical applications onboarded into your ASPM or centralised application security programme
b. Percentage of critical suppliers integrated into your security monitoring and incident processes - Quality of prioritisation
a. Number of reachable, internet exposed critical and high vulnerabilities older than 30, 60 and 90 days
b. Median time to remediate for exploitable issues on essential services - Execution discipline
a. Percentage of incidents where 24 hour notification and 72 hour full report thresholds are met in dry runs
b. Completion rate on remediation campaigns tied to specific ransomware class threats or CISA KEV items or similar KEV
c. Which critical (and high) were addressed and how many survived during last remediation sprint
- Supply chain insight
a. List of managed service providers and data centres with access to production, mapped to contracts, technical controls and who owns the relationship
b. Evidence of tabletop exercises involving those suppliers
These numbers are much more useful than vanity counts of “vulnerabilities closed this quarter”.
5. How to brief your board without sugar-coating
Boards will struggle with execution, not with the headlines. Everyone can nod along to “we should be more resilient”. Fewer directors are ready to approve the structural changes this Bill implies.
The message I would take to a board is blunt
- Regulatory risk has gone up
a. Fines up to 4 percent of global turnover or 17 million pounds are now tied to cyber preparedness and reporting, not just data privacy. - Scope is wider than they think
a. It is not just the energy grid and NHS trusts
b. It includes the managed service providers and data centres you quietly depend on for core application security, hosting, and operations - Ransomware plans must change
a. Public and essential operators will see growing pressure and likely formal restrictions on ransom payments
b. Recovery must be based on tested backups, segmentation and proven playbooks, not wire transfers to criminals - Application security is a resilience function
a. Poor DevSecOps and vulnerability management practices are now a direct route to regulatory and business failure
b. ASPM and similar platforms are not “nice dashboards” but the control plane that shows whether the organisation can withstand targeted attacks on its software supply chain
Then translate that into a concrete ask: funding and mandate for a unified application security and vulnerability management programme, not another siloed tool.
6. What to do next: practical steps for security leaders
If you run security, DevSecOps or application security, I would treat the Bill as a forcing function and push through the following steps.
- Map your exposure
a. Identify whether your organisation is in scope as an operator of essential services or critical supplier under NIS
b. Build a single, owned inventory of business-critical applications, services, environments and the suppliers that support them - Stand up or harden your ASPM capability
a. Aggregate all your scanners and cloud signals into a central view
b. Enforce one backlog of vulnerabilities per team with consistent risk scoring and SLAs
c. Embed this into your CI/CD pipelines so security gates are part of delivery, not afterthoughts - Industrialise incident reporting and ransomware playbooks
a. Run timed drills against the 24 hour and 72 hour reporting thresholds
b. Validate logging, forensics, and communications workflows from security up to legal and PR
c. Stress test your no ransom stance for critical scenarios and align it with the board - Use PSTI and UK GDPR as leverage, not distractions
a. PSTI should push your product and IoT lines to treat secure default configuration and patchability as non-negotiable on connected products
b. UK GDPR keeps the spotlight on personal data breaches; the Cyber Security and Resilience Bill extends that pressure to operational disruption - Shift conversations from tool buying to outcome delivery
a. For example, ask your teams: can we show a regulator, in writing, why we accepted a high-risk vulnerability on a critical system for 90 days
b. If the answer is “no”, that is your first transformation programme
7. Questions security leaders should ask inside the organisation
Use these questions to turn the Bill into concrete conversations with your UK business units, suppliers and board.
Scope and responsibility
- Which of our services and suppliers fall under UK NIS and the Cyber Security and Resilience Bill, and who owns that mapping?
- Do we understand how EU NIS2, UK NIS and domestic rules in other regions overlap for our platforms?
- For every essential service we provide into the UK, can we name the accountable executive and the primary engineering owner?
DevSecOps, ASPM and vulnerability management
- Do our DevSecOps pipelines and ASPM platform provide a single, prioritised backlog per team for critical services?
- How many exploitable, internet facing critical vulnerabilities older than ninety days exist on UK essential services?
- Can we prove that vulnerability data is enriched with reachability, exposure, exploit intelligence and business criticality, not just CVSS?
Incident response and ransomware
- When did we last run a timed incident drill against the UK twenty-four-hour and seventy-two-hour reporting thresholds?
- In a realistic ransomware scenario affecting a UK service, how quickly can we restore from backups, and has that been tested end to end?
- Are our ransomware playbooks aligned with likely UK restrictions on ransom payments for public and essential operators?
Supply chain and GEO exposure
- Which managed service providers and data centres are critical for our UK operations, and do they meet NIS class security expectations?
- Do our contracts with MSPs and SaaS providers include explicit obligations on security controls, incident reporting timing and joint exercises?
- How often do we run joint incident simulations with those suppliers, including at least one UK-focused supply chain attack?
Board reporting and accountability
- Can the board see a simple, consistent set of metrics that link UK legal obligations to DevSecOps and vulnerability management outcomes?
- Is there a clear budget and roadmap for ASPM and unified vulnerability management across UK and other high-risk geographies?
- If a UK regulator walked in tomorrow and asked why we accepted a specific risk on an essential service, could we show a documented decision?
Conclusions
This Bill is not perfect and details will evolve in Parliament, but the direction is clear: security and resilience for essential services and their supply chains are now regulated outcomes, not optional hygiene.
The organisations that will survive audits and serious attacks are the ones that already treat DevSecOps, ASPM and vulnerability management as core operational capabilities, backed by data, owned by engineering and sponsored at board level.
How Phoenix Security Can Help
Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.
Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis and an innovative Threat Centric approach. This innovative approach correlates runtime data with code analysis and leverages the threats that are more likely to lead to zero day attacks and ransomware to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues. Why do people talk about Phoenix
• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.
• Contextual Deduplication: Utilizing canary token-based traceability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.
• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerability’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.
By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.
