03 March 2026

Chad Richts, Director of Product Strategy, JupiterOne

Klarna's response transformed how they think about infrastructure governance. They created over 100 "target specifications" covering nearly every aspect of configuration management — from database operations and tagging to logs and encryption. These target specifications define expected states as code and continuously validate against actual infrastructure. The results: violations are detected immediately rather than periodically, and teams can self-correct before issues compound. The example at Klarna provides a window into infrastructure at scale.

The velocity gap

Platform engineering teams deploy infrastructure changes 50+ times per day as standard practice. Infrastructure-as-code has transformed network configurations into software, creating environments filled with ephemeral resources spanning multiple clouds and automated pipelines. Each deployment can modify firewall rules, network segmentation, IAM policies, or encryption configurations.

A central European bank might have 100+ engineering teams operating across five cloud regions. Periodic validation cycles cannot keep up with thousands of daily configuration changes. The gap between "approved state" and "actual state" grows wider by the day, posing a dangerous challenge. As your organisation passes compliance audits, the actual security posture steadily degrades.

DORA requirements demand proof of operational resilience, not just the existence of a policy. NIS2 has expanded its scope to cover critical infrastructure, supply chain visibility, and incident reporting requirements. The penalty structure reaches up to 2% of global revenue for non-compliance — high stakes that demand attention.

What regulators demand represents a fundamental shift in how organisations must demonstrate compliance. The requirement has evolved from "we have a firewall policy" to "we can prove every firewall configuration matches policy right now." Organisations must prove those controls work continuously. Networking teams are on the hook because they implement these controls in practice.

First audit cycles under these new frameworks will reveal an uncomfortable truth: their validation approaches are fundamentally insufficient.

Traditional validation is broken — the truth of what continuous really means

Point-in-time audits are snapshots that age like milk. Manual evidence collection — network diagrams, screenshots, interview notes, spreadsheet exports — documents what existed at a specific moment, not what exists now.

Hybrid complexity compounds the problem exponentially. Organisations run on-premises infrastructure alongside AWS, Azure, GCP, and numerous third-party services. Consider a common requirement: MFA must be enabled and enforced for all privileged access. Multiple control tests are needed to validate this properly — verifying MFA is enabled across identity providers, checking enforcement policies for administrative roles, and confirming exception processes are documented and approved. Each of these elements can drift independently, across different systems, modified by various teams. Security teams physically cannot manually review every infrastructure change. When validation cycles can't keep pace with deployment velocity, configuration drift becomes inevitable.

Continuous validation isn't about conducting more frequent audits. It's about embedding validation directly into operations, treating infrastructure testing like software testing rather than as a separate compliance exercise. Rather than validating controls after deployment, organisations now catch misconfigurations at commit time — before infrastructure even reaches production. Automated monitoring continuously detects drift in real-time: a firewall rule no longer matches the approved baseline, 15 S3 buckets suddenly lack encryption, or a new service violates zero-trust boundaries. This shift from reactive auditing to proactive validation means issues surface immediately across multi-cloud environments, network configurations, and encryption standards, allowing policy violations to be caught before they become operational problems.

The "shift-left" principle catches control violations before they reach production environments. Real-time evidence collection means every validation automatically generates an audit trail. By integrating validation into CI/CD pipelines, validation becomes part of the deployment process rather than a separate activity. The key difference: validation happens continuously in the background, not as a scheduled event that disrupts operations.

From quarterly audits to continuous confidence

Start with the highest-risk controls: encryption standards, network segmentation, privileged access. Define control tests as code alongside infrastructure definitions, integrating them into existing CI/CD pipelines rather than creating parallel processes. Build automated evidence collection directly into change workflows.

The cultural challenge is significant. Engineering teams must accept validation as inherent to deployment, not an obstacle. Start small — pick one critical control, automate its validation, and prove the value. Then scale gradually, adding controls as teams adapt to the continuous validation model and build confidence in the approach.

Security validation must become part of infrastructure operations, not a separate compliance exercise. This isn't about slowing down — it's about moving fast with confidence.

The tools exist. The barrier is organisational will. DORA and NIS2 are forcing this conversation, but the real driver is balancing business velocity with regulatory reality in increasingly complex environments.

Teams that figure out continuous validation turn compliance into a competitive advantage. Those still operating on quarterly cycles will struggle when regulators arrive, demanding continuous proof.