Firewall Governance Under ISO 27001: Rules, Evidence and Review

Govern firewalls as risk-based ISO 27001 controls through clear ownership, approved rules, logging, periodic review and evidence of effective operation.

A firewall is only as dependable as the decisions encoded in its rules. An appliance can be installed, licensed and available while permitting unnecessary traffic, retaining obsolete exceptions or producing logs that nobody reviews.

ISO/IEC 27001 does not universally require a specific firewall product or architecture. It requires an organisation to assess information-security risk, select appropriate treatment and evaluate effectiveness. ISO/IEC 27002 provides guidance for network security, network-service security, segregation, logging, configuration and change. The organisation must translate those themes into controls suited to its environment.

Direct answer: ISO 27001 firewall governance should connect every material rule to a business need, accountable owner, risk decision, narrow technical configuration, logging requirement and review or expiry. Evidence should prove both the current design and how changes and exceptions operated during the audit period.

Define the control objective

Start with the boundary and risk, not the device. A useful objective identifies:

the networks, workloads or services being separated;
the information and business processes being protected;
the threat or unwanted communication being controlled;
the direction of traffic;
the permitted business service;
the expected monitoring; and
the owner who accepts residual exposure.

For example, “restrict administrative access to production from approved management paths and alert on denied attempts” is auditable. “Use firewalls to secure the network” is not.

Firewalls may operate at internet edges, between internal zones, on cloud networks, around applications, on endpoints or as managed service capabilities. Record the complete enforcement population. Otherwise, a central network diagram can hide cloud security groups, host rules and application gateways that carry equal risk.

Establish ownership

Separate four decisions:

Business need: The service owner explains why communication is required.
Risk approval: The information or risk owner accepts the exposure and conditions.
Technical design: Network or cloud security defines the narrowest workable rule.
Implementation: An authorised administrator applies and verifies the change.

The same person may perform more than one role in a small organisation, but approval and implementation should still be visible. High-risk or privileged rules may justify independent review.

Use the ISO 27001 RACI guide to distinguish accountability from operational work.

Build a rule standard

Each rule should contain enough information to explain its purpose without reverse-engineering an address table. Record:

rule identifier;
source and destination;
service, protocol and port;
action;
direction and enforcement point;
business purpose;
owner and approver;
request or change reference;
start and expiry date where temporary;
logging requirement;
related application or asset; and
exception or risk reference.

Prefer explicitly permitted traffic over broad acceptance. Avoid unrestricted sources, destinations or services unless a documented requirement and compensating controls justify them. Name objects consistently so reviewers can interpret the rule base.

Rule order matters where the platform evaluates entries sequentially. A narrow deny can be defeated by an earlier broad allow. Review effective policy, not only individual rows.

Govern change from request to verification

A controlled change should show:

a defined business request;
security and technical impact analysis;
owner approval;
implementation by an authorised person;
peer review where required;
testing of permitted and denied paths;
confirmation that logging works;
rollback readiness;
update of records and diagrams; and
closure with evidence.

Emergency changes need an accelerated path, not the absence of control. Capture the reason, authorisation, implementation, test result and retrospective review. Track temporary emergency access to expiry.

The evidence register guide explains how to retain traceable proof without turning the ISMS into a file dump.

Manage the whole firewall lifecycle

Architecture and deployment

Identify trust zones, information flows, remote administration, high-availability design, cloud boundaries and dependencies. Confirm that management interfaces are restricted and protected separately from normal traffic.

Secure configuration

Establish approved baselines for administrative access, authentication, encryption, services, time synchronisation, backups, logging and update management. Validate the baseline on newly deployed and restored devices.

Rule operation

Monitor policy deployment, denied traffic, abnormal connections and configuration drift. Define which events require investigation and how they enter incident handling.

Maintenance

Apply vendor-supported updates through risk-based change. Monitor end-of-support dates. Test configuration restoration and high-availability behaviour rather than assuming backup files are usable.

Retirement

Remove obsolete rules, credentials, objects, routes and monitoring dependencies. Preserve required records and dispose of configuration data securely.

Review rules using risk and use

A periodic review should answer more than “is this rule still enabled?” Give reviewers the business purpose, owner, last change, observed use, affected asset, risk, expiry and service context.

Look for:

rules without owners or justification;
expired temporary access;
unused rules;
duplicate or shadowed rules;
broad sources, destinations or services;
insecure administration paths;
rules for retired assets;
inconsistent production and recovery environments;
direct paths that bypass inspection; and
logging disabled on material flows.

An unused rule is not automatically safe to remove. Validate whether it supports rare events such as recovery or month-end processing. Conversely, frequent use does not prove a rule is appropriate.

Define review frequency by risk and change rate. Internet-facing, privileged and high-impact boundaries may need more frequent attention than stable low-risk segments.

Worked firewall rule-review example

Assume a temporary rule permits a support supplier to reach a production management endpoint during a migration. A useful review record would show:

Review field	Illustrative evidence	Review conclusion
Business purpose	Approved migration ticket naming the service, supplier and maintenance window	Purpose was valid for the migration only
Effective rule	Supplier VPN range to one management address over the approved administration protocol	Source and destination were narrow, but the rule remained enabled after the window
Ownership and approval	Service owner request, security approval and named network administrator	Decision rights were traceable
Observed use	Connections during the change window; no legitimate use afterwards	Continued access was no longer justified
Logging and alerts	Allowed-session events reached the logging platform; denied attempts generated an alert	Operating evidence was available and time-synchronised
Expiry and closure	Expiry date passed three days earlier; reviewer opened a removal change and confirmed the rule disappeared from effective policy	Review found a control failure and produced corrective action
Residual exposure	No post-window connection was observed; owner documented the unneeded exposure period and improvement to automated expiry	Closure addressed the rule and the process weakness

The example is not a prescribed record. Its value is the chain from purpose to effective configuration, observed traffic, decision and verified removal. A signed review sheet that never compares the approved request with the effective rule would miss the most important evidence.

Treat logs as operating evidence

Firewall logs can support detection, investigation and control testing. Define the events collected, destination, retention, access, time synchronisation and review responsibility. Protect logs from unauthorised alteration and monitor collection failures.

Evidence may include:

log-forwarding configuration;
ingestion health;
sample events from important rules;
alert cases and analyst action;
denied administrative attempts;
rule-use analysis; and
retention verification.

Logging everything without a use case can create cost and noise. Select sufficient detail to support the control objective, incident needs and applicable obligations.

The incident-management evidence guide shows how technical events become assessed, owned and closed incidents.

Audit evidence by layer

Design evidence includes network architecture, rule standards, ownership, change criteria, review frequency, logging requirements and exception rules.

Implementation evidence includes current configurations, enforcement points, administrative settings, approved rules, log forwarding and monitoring integrations.

Operating evidence includes changes across the period, rule reviews, removed access, alerts, investigation records, update history, restoration tests and corrective action.

The distinction matters. A current export can show the configuration now, but not whether unapproved rules existed for six months.

Use the Annex A control lookup to identify related control themes, then justify selection through the organisation’s risk treatment.

Audit sampling

Build populations of enforcement points, rules, changes, exceptions, reviews and alerts. Select samples by internet exposure, privilege, data sensitivity, environment, recent change and incident history.

For each sampled rule:

trace the business requirement;
verify owner and approval;
compare requested and effective configuration;
test source, destination, service and action;
confirm denied paths where safe;
inspect logging;
examine review and expiry; and
follow exceptions to risk acceptance and closure.

Include a temporary rule, a privileged path, a cloud-native rule and a removed application. This tests more than the cleanest perimeter device.

Use the risk score calculator to structure likelihood and impact discussions while applying the organisation’s approved criteria.

Pass, partial and fail examples

Pass: Enforcement points are inventoried, rules have owners and narrow purposes, changes are approved and tested, material events are monitored, and reviews remove obsolete exposure.

Partial: Central firewalls are governed, but cloud rules have inconsistent ownership. Reviews occur, yet unused-rule analysis and closure evidence are incomplete.

Fail: Administrators add rules from informal requests, broad access has no expiry, logs are not collected, and the organisation cannot reconcile the rule base to active services.

These examples illustrate evidence strength, not mandatory audit grades.

Common weaknesses

Avoid:

claiming the device itself demonstrates conformity;
treating every network boundary alike;
allowing broad rules for convenience;
omitting cloud and host enforcement points;
keeping temporary rules indefinitely;
reviewing rules without business owners;
relying on current configuration as period evidence;
collecting logs without monitoring failures; and
retiring a service while leaving its access paths active.

Practical conclusion

Firewall assurance is a governance problem expressed through technical rules. Define the boundary and risk, assign owners, approve narrow communication, verify implementation, monitor meaningful events and review exposure as systems change.

The strongest audit trail links a real business need to an approved rule, effective enforcement, observed operation and timely removal.