Operations | Monitoring | ITSM | DevOps | Cloud

Poland’s implementation of the EU’s NIS2 Directive marks a decisive shift in how organisations think about cybersecurity, resilience, and operational risk. With amendments to the Act on the National Cybersecurity System (KSC Act) entering into force on 3 April 2026, enforcement expectations are now real, national, and significantly stricter than many organisations anticipated – including obligations for security controls, incident response, and supply‑chain governance.

The April 2026 update to UK Cyber Essentials marks an important shift. Not because it introduces radically new security concepts, but because it removes tolerance for inconsistency. With the effective date quickly approaching, many UK organizations are focused on meeting the immediate requirements. That matters. But the more durable story is what these changes reveal about how security and compliance are now expected to operate in real world environments.

Over the past few months, Puppet has partnered with Bryxx to host a series of leadership lunches across Europe, bringing together infrastructure, operations, and security leaders for candid, peer‑to‑peer conversations. These sessions weren’t marketing briefings. They were grounded discussions about what teams are facing right now: tighter regulation, rising security pressure, shifting cloud strategies, and the practical realities of automation and AI.

A sovereign cloud is a cloud environment that keeps data, infrastructure, and access under the control of a specific country or region. It lets organizations meet strict data residency and privacy laws without giving up cloud speed, automation, or modern DevOps practices. As regulations tighten and AI adoption grows, sovereign cloud is becoming the go‑to model for governments, regulated industries, and global enterprises that need both compliance and agility.

This tutorial shows how to use GitHub Copilot with the Puppet Model Context Protocol (MCP) server to generate, validate, and refine a Puppet module—even if you’re new to Puppet development.

CMMC requirements have been shifting recently, with a new version of the Cybersecurity Maturity Model Certification (CMMC 2.0) and distinct levels requiring distinct controls. Mandatory for practically any organization doing business with the US Department of Defense (DoD), CMMC is unavoidable all along the DoD’s supply chain.

It is 2:13 a.m. A mobile alert fires due to elevated error rates on a customer facing API. You jump in. Metrics show a spike in auth failures. The service was not deployed recently. The code appears unchanged. But something is different.

Thousands of organizations rely on open source community builds for infrastructure automation. But if you're tasked with certifying, maintaining, and patching those builds yourself, you know the burden firsthand. The reality is that managing open source internally consumes time, introduces risk, and diverts resources from higher-value initiatives. When critical vulnerabilities emerge, your team scrambles to assess, test, and deploy fixes, all while keeping production environments stable.

The “agent vs agentless” debate usually comes up when teams are trying to choose an infrastructure automation approach that will not compromise security, compliance, or impact day-to-day operations. You need to manage a hybrid estate, avoid creating more work for already stretched teams, and ideally do it without stitching together multiple tools. That pressure often turns the conversation into a binary choice: which approach is better?

Infrastructure as code (IaC) is the act of writing infrastructure configurations as code so they can be understood, repeated, and enforced with less manual effort. IaC is also a powerful way to convert institutional knowledge into technical knowledge. It’s a far-reaching and essential part of managing infrastructure at scale, with benefits that have expanded to platform engineering, security and compliance, network administration, and so much more.