NIS2 is often discussed as a compliance project policies, governance, reporting lines, and risk registers. And yes, those pieces matter. But when you strip it down to what actually reduces risk fast, one control sits at the centre of almost every organisation’s security posture:
the firewall.
If you want a practical way to move from “we’re working on NIS2” to “we’re measurably safer,” start by making sure your firewall is doing what it should: enforcing least privilege, supporting segmentation, producing usable evidence, and enabling rapid response when something goes wrong.
This is why, in real environments, NIS2 starts at the firewall.
Why the firewall matters under NIS2
Whether your business runs cloud services, multiple sites, remote access, or a hybrid environment, the firewall is typically the control point for:
-
Perimeter exposure (what can reach you from the internet)
-
Remote access (who can get in and to what)
-
Segmentation (what can talk to what internally)
-
Visibility and evidence (logs that prove what happened)
-
Governance (how changes are approved, tracked, and reviewed)
NIS2 pushes organisations toward stronger cyber risk management and operational resilience. In practice, that means you need controls that are not only configured well, but also provable. A firewall is one of the easiest places to demonstrate that.
1) Least privilege: stop “temporary” rules becoming permanent risk
One of the most common weaknesses we see is rules that were added “just for now” and never removed. Over time, this becomes a policy sprawl problem: too many rules, unclear intent, and overly permissive access.
What good looks like:
-
Inbound access is explicit and minimal
-
Admin interfaces are not exposed publicly
-
Exceptions have an owner, a reason, and an expiry date
-
Rules are reviewed periodically and cleaned up
This is not about perfection. It’s about eliminating the easy paths attackers love.
2) Change control: if you can’t explain it, you can’t defend it
Under pressure—an outage, a new vendor integration, a “we need this live today” firewall changes happen fast. The risk is not the change itself, but the absence of discipline around it.
What good looks like:
-
Every change has who / what / why / when
-
Changes are approved and recorded (even if lightweight)
-
Critical changes are tested and reversible
-
There is a clear separation between requester, implementer, and approver (where possible)
If you ever face an incident or audit, the ability to show controlled changes is a major credibility point.
3) Logging and retention: incident response starts here
A firewall that blocks traffic is useful. A firewall that also provides high-quality logs is what makes investigations possible.
When an incident happens, you need to answer quickly:
-
What was accessed?
-
From where?
-
By whom?
-
For how long?
-
Did anything move laterally?
What good looks like:
-
Logs are centralised (not trapped on a box)
-
Retention is defined and aligned to operational needs
-
Alerts exist for high-risk events (admin logins, config changes, suspicious outbound, repeated failed access)
Without logs, you don’t have visibility. Without retention, you don’t have evidence.
4) Remote access: reduce the blast radius
Remote access is one of the most common entry points in real-world incidents. NIS2 readiness means remote access must be hardened and controlled.
What good looks like:
-
MFA everywhere (no exceptions for admin access)
-
Access is role-based, not “one VPN for everything”
-
Privileged access is restricted and monitored
-
Segmentation ensures remote users can only reach what they actually need
Remote access should be treated as a business function—not a convenience setting.
5) Segmentation: the difference between an incident and a catastrophe
Many environments still operate as a flat network. That makes life easy for attackers and expensive for the business.
Segmentation is one of the most practical controls to reduce impact:
-
Corporate devices separated from guest networks
-
IoT separated from business systems
-
OT/ICS separated from IT (where applicable)
-
Sensitive systems isolated with strict policy controls
Segmentation doesn’t have to be complex to be effective. A small number of well-defined zones is often enough to dramatically reduce risk.
A simple NIS2 firewall readiness checklist
If you want a fast starting point, ask these questions:
- Do we have a clear view of internet-exposed services?
- Are inbound rules strictly least privilege?
- Do “temporary exceptions” have expiry dates and owners?
- Is admin access protected with MFA and restricted sources?
- Do we have centralised logging?
- Is log retention defined and adequate for investigation?
- Do we alert on key events (admin login, config change, suspicious outbound)?
- Is segmentation implemented (corp/guest/IoT/OT)?
- Are firewall changes managed through change control?
- Do we review the policy regularly (quarterly/biannually)?
If you can’t confidently answer several of these, the good news is: the fixes are usually straightforward—and they deliver immediate risk reduction.
Final thought
NIS2 becomes overwhelming when treated as paperwork. It becomes achievable when treated as engineering: measurable improvements, clear evidence, and controlled operations.
That’s why the most practical place to start is the control that enforces and records your security posture every day.
NIS2 starts at the firewall.
If you’d like, Pablosec can run a firewall readiness review and provide a short, prioritised hardening plan with quick wins and evidence-focused improvements.
