Firewall Rule Review for ISO 27001, NIS2, DORA, GDPR

It is 07:42 on a Monday morning. The CISO of a growing SaaS and FinTech provider is staring at three separate messages.

The first is from the SOC. A compromised developer workstation attempted to connect to an internal database subnet overnight. The traffic was blocked, but the analyst wants confirmation that the firewall rule is intentional, current and approved.

The second is from a large enterprise customer. They want evidence that production, development, corporate and support environments are segmented, that firewall rules are reviewed, and that exceptions expire.

The third is from the compliance manager. The organization has NIS2 exposure as an important digital provider, GDPR responsibilities as a processor, and financial-services customers asking for DORA-style ICT risk evidence. The board wants to know whether the same ISO/IEC 27001:2022 evidence can answer all three.

Then the post-incident review lands. A development server was nearly exposed to the internet during a late-night change. No customer data was lost, but the forensics team discovered something worse than the initial mistake: a five-year-old “temporary test” firewall rule still allowed broad movement between development and production. If an attacker had gained access, the network would have offered little resistance.

That is the moment many organizations discover a painful truth. They may have firewalls, VLANs, cloud security groups and diagrams, but they do not have governance over segmentation zones, rule ownership, temporary access, change approvals, recertification and audit evidence.

In 2026, “we have a firewall” is not a defensible answer. Auditors, regulators, customers and insurers want proof that networks are intentionally separated, traffic is controlled by business need, risky exceptions are governed, and logs show the controls are operating.

Why firewall governance is now a board-level issue

Network segmentation used to be treated as a technical engineering topic. Infrastructure teams owned VLANs, firewall administrators maintained rule sets, cloud teams managed security groups, and compliance saw only a diagram during audits.

That operating model no longer works.

The NIS2 Directive requires essential and important entities to implement appropriate and proportionate technical, operational and organisational measures to manage risks to network and information systems. Article 21 includes policies on risk analysis, incident handling, business continuity, supply chain security, security in acquisition and maintenance, effectiveness assessment, basic cyber hygiene, access control and asset management. Management bodies must approve and oversee those cybersecurity risk-management measures.

DORA applies from 17 January 2025 to many financial entities and makes ICT risk management a governed, documented discipline. Articles 5, 6 and 8 require governance, an ICT risk management framework, and identification of ICT-supported business functions, information assets, ICT assets, dependencies, critical assets and interconnections. Articles 9, 10 and 11 address protection, prevention, detection, response and recovery. Articles 24 to 27 require digital operational resilience testing, including advanced testing for certain entities. That makes segmentation a resilience issue, not just a firewall issue.

GDPR adds the privacy accountability layer. Article 32 requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including confidentiality, integrity, availability and resilience. Article 5(1)(f) requires integrity and confidentiality, and Article 5(2) requires accountability. If personal data systems are reachable from compromised endpoints, guest networks or unmanaged third-party paths, a supervisory authority may ask why those paths existed.

ISO/IEC 27001:2022 provides the management-system foundation that connects these obligations. It requires scope, interested-party requirements, risk assessment, risk treatment, a Statement of Applicability, operational planning and control, leadership accountability, measurable objectives, documented information and continual improvement. Annex A, supported by ISO/IEC 27002:2022 guidance, includes the control areas needed for supplier risk, cloud services, logging, monitoring, secure architecture, environment separation and change management.

The point is simple: network segmentation and firewall rule review are now evidence of governance.

The Clarysec operating pattern: 8.20, 8.22 and 8.32

Clarysec treats segmentation and firewall review as one operating pattern across ISO/IEC 27002:2022 controls, not as isolated technical tasks.

The three primary controls are:

In Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB], Clarysec places network security in the Controls in Action phase, Step 20: Controls 8.18 to 8.26. The guide frames the core audit question clearly:

“At its core, this control requires organizations to ensure that networks are secure by architecture, not just by adding firewalls or antivirus later. That means thinking strategically about network segmentation, access control, encryption in transit, monitoring, and defense in depth. It begins with a simple question: Who and what are communicating, and should they be?”

That question, “who and what are communicating, and should they be?”, is the best practical starting point for firewall rule review. It moves the conversation away from thousands of cryptic ACL entries and toward business-justified flows.

The same Zenith Blueprint tells teams to assess network architecture by verifying that firewall rules, IPS/IDS and remote access configurations are current and hardened, and to confirm that cloud security groups, routing and VPC or subnet rules match the intended architecture. It also tells auditors to expect a Network Security Architecture Diagram that shows firewalls, VPN gateways, DMZ zones, VLAN separation and trust boundaries.

For change management, the Zenith Blueprint places ISO/IEC 27002:2022 control 8.32 in the Controls in Action phase, Step 21: Controls 8.27 to 8.34, and highlights why firewall governance fails when change control is weak:

“This control recognizes a hard truth in IT: many incidents are not caused by attacks, but by mismanaged change. A firewall rule opened too wide. A debug setting left enabled. A forgotten dependency after a migration.”

That is exactly how temporary firewall openings become permanent attack paths.

What good network segmentation looks like

A mature segmentation program has four layers.

First, it has a zoning model. Zones are not arbitrary subnets. They are trust boundaries aligned to business function and data sensitivity, such as internet-facing DMZ, production application tier, production database tier, corporate user network, privileged management network, development environment, test environment, backup network, guest Wi-Fi, OT or IoT zone and third-party access zone.

Second, it has a flow matrix. For each zone pair, the organization documents allowed source, destination, protocol, port, application, business owner, system owner, data type, justification and logging requirement.

Third, it has rule ownership. Every firewall rule, cloud security group rule or software-defined perimeter policy has an owner, expiry or recertification date, linked change ticket and business justification. “Any to any” should be treated as a finding unless it is formally risk accepted, time-bound and supported by compensating controls.

Fourth, it has recurring review. Review means more than exporting a firewall rule base once per year. It includes owner recertification, comparison against observed traffic, detection of unused rules, validation of temporary exceptions, review of internet exposure, segmentation testing and reconciliation against asset inventory.

Clarysec’s Network Security Policy [P-NS] sets the enterprise expectation clearly:

“All inter-zone traffic must be controlled by firewalls or software-defined perimeter solutions, with explicit deny-by-default configurations.”

From Enterprise Policy, Network Security Policy, section “Governance Requirements,” clause 5.2.

The same policy connects firewall changes directly to change management:

“Any change to firewall rule sets, routing tables, or security group configurations must follow the organization’s Change Management Policy (P5), including rollback plans and audit logging.”

From Enterprise Policy, Network Security Policy, section “Governance Requirements,” clause 5.4.

For SMEs, Clarysec’s Network Security Policy-sme [P-NS-SME] provides the same principle in operational terms:

“Default-deny rules must be enforced for all inbound connections unless explicitly required and approved”

From SME Policy, Network Security Policy-sme, section “Policy Implementation Requirements,” clause 6.1.2.

And for segmentation specifically:

“Traffic between segments must be filtered, and inter-segment access must follow the principle of least privilege”

From SME Policy, Network Security Policy-sme, section “Policy Implementation Requirements,” clause 6.2.3.

These policy clauses allow an auditor to trace from risk to control, from control to rule, from rule to approval, and from approval to logs.

One evidence pack for ISO 27001, NIS2, DORA and GDPR

The mistake many teams make is building separate evidence packs: one for ISO/IEC 27001:2022, one for NIS2, one for GDPR, one for DORA customers, and one for cyber insurance.

A better approach is to build a single segmentation and firewall governance evidence pack that maps across frameworks.

Zenith Controls: The Cross-Compliance Guide [ZC] maps ISO/IEC 27002:2022 control 8.22 Segregation of Networks as a preventive control supporting confidentiality, integrity and availability, aligned to the Protect cybersecurity concept and the operational capability of system and network security. It ties 8.22 to 8.20 Network Security, 8.21 Security of Network Services, 8.7 Protection Against Malware, 8.27 Secure System Architecture and Engineering Principles, and 8.31 Separation of Development, Test and Production Environments.

The guide explains the NIS2 relevance of segmentation this way:

“Segregation of networks is a direct response to these obligations, reducing attack surfaces and preventing lateral movement across networked systems.”

That sentence describes why NIS2 cyber hygiene programs should not treat segmentation as optional. Ransomware containment is not only about endpoint protection. It is about limiting lateral movement when prevention fails.

For GDPR, Zenith Controls maps 8.22 to Article 32 and Recital 49, noting that network diagrams and zoning policies become key evidence of compliance. For DORA, Zenith Controls maps network security and segregation to ICT risk management and incident containment. Segmentation tests can support ICT resilience evidence, especially when they prove that a compromise in one zone cannot move freely into critical financial services, personal data repositories or privileged management systems.

This table is not only a compliance mapping. It is a roadmap for evidence collection.

The firewall rule review that actually works

A firewall rule review fails when it asks only, “Is this rule still needed?” Rule owners often say yes because they are afraid of breaking something.

A better review asks six questions:

1. What business service does this rule support?
2. Which asset owner and data owner approved the flow?
3. Is the destination in the correct zone for the data and function?
4. Is the rule more permissive than observed traffic requires?
5. Is logging enabled for high-risk flows?
6. Does the rule have a review date, expiry date or exception record?

The Network Security Policy-sme requires periodic review:

“The IT Support Provider must conduct an annual review of firewall rules, network architecture, and wireless configurations”

From SME Policy, Network Security Policy-sme, section “Governance Requirements,” clause 5.6.1.

Annual review is the baseline, not the ceiling. High-risk rules need more frequent recertification.

The Network Security Policy is explicit about exceptions:

“The request must be reviewed and approved by the ISMS Manager or the CISO and recorded in the ISMS Exception Register, with a maximum approval period of 90 days, renewable upon reassessment.”

From Enterprise Policy, Network Security Policy, section “Risk Treatment and Exceptions,” clause 7.3.

For SMEs, the Network Security Policy-sme requires exception requests to include the right minimum facts:

“The request must include the justification, scope, duration, and compensating controls (e.g., IP allowlisting, logging)”

From SME Policy, Network Security Policy-sme, section “Risk Treatment and Exceptions,” clause 7.3.3.

That clause turns exception handling from informal chat into auditable risk treatment.

Practical example: removing a risky production database rule

Assume a company finds the following rule during review:

This is a classic audit finding. It violates least privilege, has no clear owner, no expiry, no current justification and no logging. It also creates a GDPR Article 32 exposure if the production database contains customer personal data.

The remediation process should create evidence, not just remove a bad rule.

Clarysec’s Logging and Monitoring Policy [P-LM] includes external communications and firewall rule triggers as log-relevant events:

“External communications and firewall rule triggers”

From Enterprise Policy, Logging and Monitoring Policy, section “Policy Implementation Requirements,” clause 6.1.1.6.

For high-risk inter-zone rules, firewall triggers should feed the SIEM or monitoring platform, with alerts for unusual source hosts, volumes or time windows.

The SME policy also requires change discipline:

“All changes to network configurations (firewall rules, switch ACLs, routing tables) must follow a documented change management process”

From SME Policy, Network Security Policy-sme, section “Policy Implementation Requirements,” clause 6.9.1.

A single cleanup of this rule creates evidence for ISO/IEC 27001:2022 operational control, ISO/IEC 27002:2022 8.20, 8.22 and 8.32, NIS2 cyber hygiene, GDPR Article 32 and DORA-style ICT risk management.

Cloud, SaaS and hybrid networks must be included

Modern segmentation is not only VLANs and physical firewalls. It includes AWS security groups, Azure network security groups, Kubernetes network policies, cloud routing tables, SaaS admin allowlists, private endpoints, VPNs, SD-WAN, identity-aware proxies and software-defined perimeter controls.

For a SaaS provider or regulated digital service, the firewall rule review should include at least:

• Internet-facing load balancers and application gateways
• Cloud security groups and network ACLs
• Private subnet routing tables
• Peering and transit gateway paths
• VPN and remote administration paths
• Admin interfaces and management planes
• Kubernetes ingress and network policies
• CI/CD runner access into production
• Logging coverage for denied and allowed high-risk flows
• Third-party support access and break-glass paths

If a cloud security group allows inbound database traffic from a broad corporate IP range, treat it like a firewall rule. It needs ownership, justification, approval, review, logging and expiry.

This is also where supporting ISO standards strengthen the story. ISO/IEC 27017 supports clarity over cloud security responsibilities. ISO/IEC 27033 provides deeper guidance on network security architecture, DMZs, segmentation zones, traffic filtering and secure inter-network communications. ISO/IEC 27701 reinforces privacy governance where personally identifiable information moves across networks. ISO/IEC 27035 supports incident containment, and ISO/IEC 27005 supports selecting segmentation as a risk treatment for unauthorized access, malware spread and lateral movement.

How auditors test the same control differently

One of the strengths of Zenith Controls is that it explains how different audit methodologies examine the same control. The evidence can be reused, but the questions differ.

A DORA-focused assessor may ask whether a compromise in a payments gateway can pivot into customer databases. A NIS2 competent authority may ask whether ransomware on an administrative workstation can reach core service delivery systems. A GDPR authority may ask what network-level restrictions protected systems processing personal data. An ISO auditor may simply ask for the risk assessment, SoA, policy, procedure and evidence that reviews happened.

The best programs answer all of these with the same artifacts.

Metrics that make segmentation visible to leadership

NIS2 and DORA both push management accountability. ISO/IEC 27001:2022 requires leadership, objectives, roles, resources, reporting and continual improvement. That means segmentation needs metrics that leadership can understand.

Useful management metrics include:

• Percentage of firewall rules with assigned owner
• Percentage of rules with documented business justification
• Number of expired temporary rules
• Number of rules with “any” source, destination or service
• Number of internet-exposed services by criticality
• Percentage of high-risk inter-zone flows with logging enabled
• Number of emergency firewall changes per quarter
• Percentage of sampled rules matched to approved change tickets
• Number of segmentation test failures
• Mean time to remediate risky or unused rules
• Number of exceptions older than 90 days
• Number of third-party access rules reviewed and recertified

The Network Security Policy identifies “Firewall rule effectiveness” as a compliance and enforcement consideration in section “Enforcement and Compliance,” clause 8.2.2. That phrase matters because rule existence is not enough. Rules must be effective, reviewed and aligned with current risk.

Build the 2026 segmentation evidence pack

A practical segmentation and firewall rule review evidence pack should be ready before the auditor asks for it.

At minimum, maintain:

1. Current network architecture diagram, including cloud and hybrid zones
2. Zone classification standard, including sensitivity and trust level
3. Flow matrix for critical services and personal data systems
4. Firewall and cloud security group rule export
5. Rule owner and recertification register
6. Firewall review procedure and review calendar
7. Change records for sampled firewall modifications
8. Exception register with approvals, expiry and compensating controls
9. Segmentation test results and remediation records
10. Logging and monitoring evidence for high-risk flows
11. Incident playbooks showing containment by zone
12. Management reporting metrics and meeting minutes

Map this evidence into ISO/IEC 27001:2022 clauses and Annex A control areas. Then cross-reference it to NIS2 Article 21, GDPR Article 32, DORA ICT risk management and testing requirements, NIST CSF 2.0 outcomes such as GOVERN, PROTECT, DETECT and RESPOND, and COBIT governance practices.

NIST CSF 2.0 is especially useful as a board communication layer. Its GOVERN function focuses on legal, regulatory and contractual requirements, risk appetite, roles, policies and oversight. Its operational outcomes address configuration management, logging, monitoring, data protection, incident response and recovery. This helps leadership understand risk without reading firewall ACLs.

Common findings Clarysec sees in segmentation audits

Across SaaS, fintech, managed service providers and regulated SMEs, the same findings appear repeatedly:

• Flat network between user endpoints and production services
• Production databases reachable from development or corporate networks
• Broad cloud security groups copied from old templates
• Temporary vendor rules with no expiry
• Firewall changes made outside the change process
• Rules with no owner or business justification
• Logging disabled on high-risk allow rules
• Guest Wi-Fi not fully isolated
• Admin interfaces reachable from general networks
• Diagrams that do not match actual routing
• No evidence that rule reviews were completed
• No segmentation testing after major architecture changes
• No mapping between personal data systems and network zones
• No management reporting on network exposure

These findings are not only technical weaknesses. They undermine the organization’s ability to prove NIS2 cyber hygiene, DORA operational resilience and GDPR Article 32 accountability.

From reactive cleanup to defensible control

Network segmentation and firewall rule review are where security architecture meets audit reality. If you can show a risk-based zoning model, controlled inter-zone flows, approved firewall changes, time-bound exceptions, logging evidence and periodic validation, you can answer a wide range of ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST and COBIT questions with one coherent story.

Clarysec can help you build that story.

Use Zenith Blueprint: An Auditor’s 30-Step Roadmap to structure the implementation journey, especially Controls in Action Step 20 for network security and segmentation, and Step 21 for change management. Use Zenith Controls: The Cross-Compliance Guide to map ISO/IEC 27002:2022 controls 8.20, 8.22 and 8.32 across NIS2, DORA, GDPR, NIST and COBIT audit expectations. Anchor your operating rules in Clarysec’s Network Security Policy, Network Security Policy-sme and Logging and Monitoring Policy.

Your next step is simple and high value: select one critical service, such as customer production, payment processing or identity management, and perform a 10-rule sample review this week. For each rule, confirm owner, justification, source, destination, port, logging, change ticket and expiry. If you cannot prove those seven facts, you have the beginning of your 2026 segmentation improvement plan.