(and why it’s not “just compliance”)
A specter is haunting Europe: NIS2.
No, it won’t be used by anyone to found a new economic order—but we should still brace ourselves. If you work in IT—developer, sysadmin, cloud architect, DevOps, or product lead—you’ve almost certainly heard this sentence at least once in the past few months:
“We need to comply with NIS2.”
And right on cue, a reflex kicks in:
“Cool. Another regulation. Another thing to sign. Another table to fill in. Another Excel file that will quietly die in SharePoint.”
Except… this time, that mental model doesn’t really work.
Because NIS2 isn’t a bureaucratic checklist you tick once and forget. It’s a shift in mindset. It drags cybersecurity out of the “technical topic” drawer and drops it squarely into day-to-day operations: resilience, continuity, and risk management.
In short: it doesn’t just ask you to be secure.
It asks you to prove you are, to know what to do when things go wrong, and to manage risk well beyond the comforting boundaries of your own datacenter or cloud account.
Because today, the most dangerous attack rarely comes from the most obvious hole. It usually shows up via an integration, a dependency, a supplier, a SaaS tool—or that extremely efficient colleague who, “just to speed things up,” fed your entire company data lake to the latest LLM.
In this article we’ll look at what NIS2 actually is, who it affects, what really changes compared to the past, and—most importantly—what it means in practice for tech teams, without turning it into a meeting with a legal wizard.
Why Europe felt the need for NIS2
It’s tempting to describe NIS2 as “NIS1, but better,” but that undersells it.
NIS2 exists because it became painfully obvious that many organizations—even critical ones—have handled security in a fragmented way: some tools here, some processes there, a few well-run projects and a few abandoned halfway. The end result is often security that’s neither measurable nor stable—and eventually, a headline.
The problem isn’t just that attacks are increasing. It’s that entry points are multiplying. You can have a well-managed internal infrastructure and still get burned because a supplier, a SaaS service, or a software dependency introduced a risk you never really accounted for.
Security, in other words, no longer lives only inside your house.
This is where NIS2 raises the bar. It doesn’t just ask you to protect a perimeter. It asks you to think about how your organization manages risk across the entire ecosystem it depends on—which, for any digital business, is pretty much everything.
“Does this apply to us?”
The question everyone asks
One thing you see all the time: companies start the NIS2 conversation by looking for a binary answer—are we in or out?
Fair question. Nobody wants to spend months on something that “technically doesn’t apply.”
But the real answer isn’t that clean.
Because NIS2 doesn’t just have direct effects. It creates ripple effects. If a company falls under NIS2, it will start demanding higher standards and guarantees from its suppliers. And that process isn’t optional—it’s inevitable.
So even if you’re not formally in scope, you might still be involved because you work for someone who is. Or because you run a critical part of their operations. Or because you provide digital services: hosting, development, support, infrastructure, monitoring.
In short: if you help keep services, data, and processes alive, then—poetically speaking—it’s probably not a great idea to ask for whom the bell tolls.
What really changes: not the theory, the substance
The biggest practical difference compared to how many organizations handled security until yesterday is simple:
It’s no longer enough to say “we’ve done security.”
You have to show that security is managed as a system.
That leads to some very concrete consequences.
1. Security becomes transversal
Security stops being “the security team’s project” or “an IT thing.” It becomes part of governance.
That means management can’t stay on the sidelines anymore. And in many companies, this alone changes the dynamic completely. Security becomes a decision-making topic: budget, priorities, accountability, acceptable risk.
2. Incidents stop being hypothetical
NIS2 doesn’t say “you must never have incidents.” It says you must know what to do when one happens.
Because what often kills a company isn’t the attack itself—it’s the chaos around it. Hours wasted figuring out who decides what. Conflicting messages. Systems shut down at random. Premature restarts. Vendors called when it’s already too late. Meanwhile, the service is still down.
3. The supply chain becomes unavoidable
This is the heavy one.
In a hyper-connected world, “how secure is our supplier?” becomes an operational question, not a procurement checkbox. If a third party has privileged access to your environment or runs a critical part of your workflow, then their risk is your risk.
The most misunderstood part: “risk management” is not a document
Risk management is one of those terms that gets repeated so often it risks becoming meaningless. Many people immediately picture a spreadsheet with probability and impact scores from 1 to 5, colored from green to red.
But for a tech team, risk management is far more concrete. It’s about being able to answer questions we usually ignore—until someone forces us to.
Do we actually know what assets we have?
What’s in production? What’s been “temporarily in use” for six months? What was created by a team that no longer exists but still works so nobody touched it?
Do we know how many credentials exist—and where they ended up?
Do we know which accounts have way more privileges than they should?
Is patching under control, or does it depend on whichever hero remembers to update things once in a while?
Backups exist—but have we ever actually restored them, or do we just trust the fact that “the job is green”?
When a system goes down, can we recover in reasonable time, or does recovery feel like a traumatic event?
Simple questions. Massive difference between declared security and real security.
Incident reporting: stressful, uncomfortable, necessary
Among all NIS2 requirements, incident handling and reporting is usually the one that creates the most anxiety.
That’s normal. It hits a sensitive nerve: admitting something happened, documenting it, communicating it. Nobody enjoys saying “we weren’t ready.”
But here’s the truth: most companies aren’t unprepared because they’re incompetent. They’re unprepared because they never structured a response. And without structure, an incident turns into chaos.
This isn’t an “enterprise-only” exercise. It’s just the grown-up version of something we all already do: reacting when things break—only with more clarity.
Who decides this is an incident and not “just a glitch”?
Who authorizes drastic actions?
Who talks to vendors?
Who checks whether data is involved?
Who handles internal communication?
Who collects evidence while everyone else is trying to bring systems back online?
If you’ve never defined these things before, you won’t magically do it well at the worst possible moment.
The supply chain: where games are won (or lost)
You’ll often hear: “We’re secure.”
And maybe you are—inside your perimeter.
But if you use external services (and everyone does), security is no longer an internal property. It’s an ecosystem.
The problem isn’t that suppliers are evil. It’s that they’re different. Some are mature. Some are fragile. Some are excellent but terrible at communication. Others communicate beautifully and have weak practices.
NIS2 makes this unavoidable: you’ll need to identify which third parties are truly critical and what level of access they have. Because if an external service has elevated privileges in your environment, you can’t treat it as a footnote.
For many organizations, this will be the hardest part—not because it’s technically complex, but because it’s culturally uncomfortable. It means adding rules where there used to be implicit trust. Asking for evidence where “don’t worry, we’re certified” used to be enough. Governing risk that, until yesterday, was simply invisible.
NIS2 and tech teams: not a brake, a level-up
If you work in DevOps or Cloud, your first reaction might be: “Great, more rules, more constraints.”
But there’s another way to look at it.
Many things NIS2 pushes for are the same things that make your life less miserable in production. Because good security isn’t bureaucracy—it’s engineering quality.
Better observability means better troubleshooting.
Better credential management means fewer dumb incidents.
Automated hardening means more consistent environments.
Clear release and patching processes mean fewer “deploys of terror.”
NIS2 can be seen as a political push to bring organizations to a more mature operating model—to stop improvising and start building systems that actually hold.
Where to start (without turning it into an endless initiative)
When something like NIS2 hits the table, the instinct is to launch a massive project: committees, roadmaps, endless deliverables. Ironically, that’s often the fastest way to kill it.
The goal isn’t to do everything at once.
The goal is to move the organization in a coherent direction.
In many cases, it makes sense to start with two or three brutally concrete things that have outsized impact—and quickly reveal where the real problems are. For example: how privileged access is managed, whether backups are actually restorable, whether an incident plan exists beyond “call Marco, he knows.”
Once that’s done, everything else becomes progression. Because maturity doesn’t come from documents. It comes from habits, routines, automation, and repeated decisions over time.
Conclusion: NIS2 doesn’t ask you to be perfect—it asks you to be ready
Let’s clear up a common misunderstanding: NIS2 doesn’t demand zero incidents. It demands that you can face them without collapsing.
And, just for fun, it also introduces the joy of audits for organizations that provide critical services—an experience from which few emerge psychologically unscathed.
Being prepared makes a massive difference.
Being ready means knowing your likely risks, your weak points, who has access to what, and how to respond when something happens. It means not discovering during an emergency that “the backup was on the server that just got encrypted too.” It means not spending hours deciding who gets to decide.
In the end, the real promise of NIS2 isn’t “more compliance.”
It’s something far more useful: organizations that stay on their feet when things go wrong.
And in 2026, for anyone working in tech, that’s the difference between a bad day—and a disaster.
