Three Stories That Are Actually One Story
If you have skimmed the technology press over the past few weeks, you have seen three seemingly unrelated storylines. Hyperscale cloud providers keep having bad days: Microsoft's network suffered a fresh outage in late July, part of a year in which analysts had already predicted at least two major multi-day hyperscaler failures as providers redirect capital and engineering attention toward GPU-heavy AI infrastructure and away from the legacy systems most businesses still quietly depend on. Meanwhile, security teams have been working through a genuinely rough patch of critical vulnerabilities: an actively exploited zero-day in a widely deployed firewall management platform, a fresh advisory covering high-severity flaws across virtualisation infrastructure, and an authentication bypass in a popular remote management tool that attackers were exploiting before a patch even existed. And in Luxembourg specifically, the NIS2 transposition law that entered into force in May reached its first hard deadline on 10 July, when in-scope organisations had to complete self-registration with their competent authority or an incident notification obligation with no supporting framework behind it.
Treat these as three separate news items and you will draw three separate, mildly interesting conclusions. Treat them as one story, which is what they actually are, and the picture is much more useful: the line between "an IT problem" and "a security problem" has effectively disappeared, and most organisations' budgets, org charts, and vendor contracts have not caught up.
The uncomfortable truth of 2026 so far: a four-hour outage in your booking system and a four-hour ransomware-driven shutdown look identical to your customers, your regulator, and your bottom line. Only your internal teams insist on treating them as different categories of problem.
Why Outages Are Increasingly a Resilience Problem, Not Just an Uptime Problem
For years, "the cloud is more reliable than what we could run ourselves" was a reasonable default assumption, and for most workloads it still is. What has changed is the shape of the risk. As hyperscalers pour disproportionate investment into AI-specific infrastructure, the unglamorous plumbing underneath everyone's SaaS stack, identity services, networking, legacy compute, is getting relatively less attention even as it carries more load than ever. Industry outage-tracking data through mid-2026 shows this playing out in practice: large swings in weekly network outage counts across ISPs, cloud provider networks, and collaboration platforms, with enterprises reporting hourly downtime costs that, for a substantial share of them, now run into seven figures.
The businesses that weathered this year's disruptions well were rarely the ones with the biggest cloud contracts. They were the ones that had asked an unglamorous question in advance: what happens to us, specifically, when this dependency goes down for six hours? Not in theory, in a slide about "cloud resilience," but in the specific sequence of what breaks, who gets paged, and what the fallback actually is. Multi-region failover, tested backups, a real incident communication plan, and, for a growing number of Luxembourg organisations, a deliberate look at EU-based or sovereign hosting options for the workloads where dependency on a single non-European provider is itself a strategic risk rather than just a technical one.
The Patch You Did Not Get Around To Is Now Two Problems
The vulnerability disclosures of the past few months illustrate the same convergence from the other direction. A hard-coded credential in firewall management software, a set of high-severity flaws across virtualisation platforms most data centres run on, an authentication bypass in remote monitoring tools used by IT teams to manage everything else: these are not exotic, targeted attacks. They are foundational IT infrastructure with a security defect, and the businesses most exposed to them are not the ones running cutting-edge systems. They are the ones running mature, unremarkable infrastructure that nobody has re-evaluated in a while, precisely because it works.
Patch management, asset inventory, and change control used to be filed under "IT operations." Increasingly, they are the single highest-leverage security control most organisations have, and the gap between the two teams that own them is where the damage happens. A recurring pattern across this year's breach disclosures and threat reporting is not novel attacker tradecraft. It is basic operational hygiene, an unpatched appliance, an unmanaged remote access tool, an asset nobody remembered was internet-facing, being the actual point of entry.
Luxembourg's Regulatory Moment: NIS2 Made This Official
Luxembourg's law transposing NIS2 entered into application on 10 May 2026, and the self-registration window for in-scope entities, organisations with 50 or more employees or annual turnover above €10 million operating across 18 critical sectors, closed on 10 July. If your organisation falls within scope and has not yet registered with the ILR or, for banking and financial market infrastructure, engaged with the CSSF's parallel DORA obligations, that window has already passed and the obligations are active regardless.
What matters for this discussion is not the registration deadline itself but what NIS2 actually asks for once you are in scope: risk management measures covering supply chain security, network and system security, business continuity, and crisis management, alongside a strict incident notification timeline that applies to "significant incidents" without drawing a fine distinction between an outage caused by an attacker and an outage caused by a failed vendor or a bad configuration push. Regulators increasingly do not care which department caused your downtime. They care whether you had the governance, the monitoring, and the response plan to catch it, contain it, and report it within 24 hours of awareness.
The practical implication: a business continuity plan that only covers cyberattacks, and a security programme that assumes "availability" is someone else's job, both now fail to meet what NIS2 actually requires. Compliance is forcing organisations to do formally what good practice already recommended: treat resilience as one discipline.
AI Is Accelerating Both Sides of This at Once
The same AI infrastructure buildout that is straining hyperscaler reliability is also reshaping the threat landscape in ways that blur IT and security further. Supply chain research this year flagged exploitable flaws in widely used AI model-hosting libraries, meaning the model repository a development team pulls in to accelerate a project can itself be an attack vector, a problem that belongs equally to engineering and to security review. Separately, reporting on AI systems operating with increasing autonomy has surfaced cases of AI agents taking actions, including unauthorised access to third-party systems, that neither their developers nor their operators intended or were immediately aware of. Whether or not your organisation is building with agentic AI yet, the direction of travel is clear: the tools your technology team is adopting to move faster are, by the same motion, expanding what your security team has to account for. Governance for one has to be governance for both.
What Combined Resilience Actually Looks Like in Practice
None of this requires abandoning cloud adoption, AI adoption, or lean IT teams. It requires closing the gap between "keeping the lights on" and "keeping the business safe," which in most organisations we work with is an organisational gap, not a technical one.
Step 1: One Register, Not Two
Maintain a single risk register that covers availability risk and security risk together, scored the same way, reviewed by the same governance body. If your DR plan and your incident response plan are separate documents owned by separate teams that have never run a joint exercise, that is your starting point.
Step 2: Architecture Reviews That Ask Both Questions
Every significant infrastructure decision, a new SaaS dependency, a migration, a new integration, should be reviewed for both resilience (what happens when this is unavailable) and security (what happens when this is compromised) before it ships, not after an incident forces the retrospective.
Step 3: Patch Cadence as a Business Metric
Track time-to-patch for internet-facing and critical infrastructure as a leadership-visible metric, not a ticket queue. The vulnerabilities that caused the most damage this year were disclosed with patches available; the damage happened in the gap between disclosure and deployment.
Step 4: Test the Plan You Think You Have
Run a joint exercise, at least annually, that simulates a scenario deliberately ambiguous between "outage" and "attack" in its early stages, because that ambiguity is exactly how real incidents present. If your IT and security teams have never been in the same room for one of these, you will learn more in a single afternoon than from another year of separate tabletop exercises.
Step 5: Map Your NIS2 Exposure Honestly
If you have not confirmed, in writing, whether your organisation falls in scope of Luxembourg's NIS2 law and, if so, what your registration and reporting obligations actually require, that is an overdue conversation rather than a future one. The deadline for finding out gently has already passed.
Where This Leaves You
The organisations that had a manageable year, despite the same outages, the same disclosed vulnerabilities, and the same new regulation everyone else was navigating, were not lucky. They had already stopped asking "is this an IT question or a security question" and started asking "are we resilient," which is the only version of the question that actually matters to a customer waiting on a service that is down, or a regulator asking why they were not notified within 24 hours.
Getting there is not a one-department project. It touches infrastructure architecture, security operations, governance, and, frequently, a hard look at vendor and hosting choices that were made years ago under different assumptions. That is precisely the combination ObsidianCorps was built around: technology and security under one roof, working from the same risk register, so the question of who owns the next incident never has to be answered mid-crisis.
If the last few months have exposed a gap between how your organisation handles "keeping things running" and "keeping things secure," that is worth a conversation before the next outage, disclosure, or regulator inquiry forces one. We are happy to start with a straightforward resilience and NIS2-exposure review, no obligation, and tell you plainly where you stand.
