Security: the need for a regulation reset

For years, IT leaders have had to balance strong security practices against delivery speed, feature demands, and finite resources, often making difficult trade-offs rather than simple choices. That balance is about to change. Across the UK and the EU, a wave of new regulations is turning software security from a technical best practice into a legal and operational obligation. And for DevOps teams, that represents a fundamental shift in responsibility.

 

From the EU’s Cyber Resilience Act (CRA) and Product Liability Directive to the UK’s upcoming Cyber Security and Resilience Bill, policymakers are sending a clear message: if you build and ship software, you are accountable for the security of products you place on the market throughout their lifecycle. Compliance will no longer be something handled after release or delegated to a central team. It must be baked into how software is designed, built, released, and operated every day.

 

 

Clearer rules, tighter timelines, higher stakes

The proposed UK Cyber Security and Resilience Bill, expected to come into force in 2026, expands and modernises the existing NIS Regulations. Its scope is significantly broader, covering not just operators of essential services like healthcare, energy, and transport, but also digital infrastructure providers, cloud platforms, managed service providers, and a wider range of suppliers in the digital supply chain.

 

For DevOps teams supporting these organisations, the implications are immediate. Incident reporting timelines are expected to be significantly shortened. Regulators will also have stronger audit powers aligned to frameworks such as the Cyber Assessment Framework, as well as greater authority to issue improvement notices and penalties.

 

In parallel, the EU’s Cyber Resilience Act introduces horizontal security requirements for products with digital elements, including software. It applies across the entire product lifecycle, from secure-by-design principles to vulnerability handling and update obligations. While most provisions apply from December 2027, key reporting duties will kick in as early as autumn 2026.

 

Add to that the new Product Liability Directive, which modernises liability rules to explicitly include software and AI systems, broadens the definition of damage, and makes it easier for claimants to bring cases. Together, these regulations change the risk profile of software delivery across the region.

 

 

A new level of responsibility for DevOps teams

In practice, this shifts more responsibility onto DevOps teams as they are responsible for proving that software is secure, resilient, and responsibly managed over time.

 

Security failures won’t just be technical incidents; in many cases, they’ll also become regulatory events with legal, financial, and reputational consequences. Late-stage security reviews, manual controls, or reactive patching simply won’t hold up under scrutiny when regulators expect demonstrable, repeatable processes embedded into delivery pipelines.

 

This is why 2026 is shaping up to be a reset moment. Security can’t be something added at the end of the process or bolted on before release. It needs to be part of every step of delivery, from design and development through deployment, monitoring, and incident response.

 

 

Why security must become everyday work

The only sustainable way to meet these expectations is to make security part of everyday DevOps workflows. That means automation over manual checks, continuous controls instead of point-in-time audits, and real-time visibility rather than retrospective reporting.

 

Practically, this looks like progressive delivery practices that reduce blast radius when things go wrong, automated rollouts and rollbacks that limit exposure, and observability that allows teams to detect, investigate, and respond to issues quickly. It also means clearer ownership, so teams know who is accountable for security decisions at each stage of delivery.

 

Crucially, this approach doesn’t slow teams down. In fact, it does the opposite. By embedding security into delivery, teams avoid last-minute surprises, reduce rework, and gain confidence to move faster within clearly defined guardrails.

 

 

What leaders should do now

For engineering and technology leaders, the window between now and regulation deadlines at the end of 2026 is a preparation period, not a grace period. For boards and executive teams, this also raises the stakes around oversight, assurance and risk ownership. Waiting until regulations are fully enforced will be too late.

 

The first step is recognising that compliance is not a side project. It’s an outcome of how software is built and operated. Leaders should invest now in modern delivery practices that support secure releases.

 

Second, organisations need to map regulatory expectations onto delivery pipelines. That means understanding where evidence will be required, how incidents will be detected and reported, and how updates and mitigations will be deployed under pressure.

 

Finally, leaders should focus on culture as much as tooling. Security ownership must sit with the teams shipping software, supported by clear governance and shared standards. When teams understand that security is part of their day-to-day responsibility, not an external hurdle, they’re far better equipped to meet regulatory demands.

 

The teams that succeed under this new regulatory landscape will be those that treat security as an integral part of software delivery, not a compliance exercise. As regulation tightens and scrutiny increases, the margin for reactive approaches is disappearing.  Those that continue to see compliance as an afterthought risk falling behind, facing penalties, and losing customer trust. The shift is already underway, and 2026 will be the moment it becomes impossible to ignore.

 

---

 

Joe Byrne is Global Field CTO at LaunchDarkly

 

Main image courtesy of iStockPhoto.com and sankai