Firewall Requirements for ISO 27001 Compliance
An ISO 27001 firewall approach should follow the organization’s network risks, information flows, and selected controls. Define who approves rules, reviews changes, monitors activity, and retains evidence. A firewall product alone does not establish that the management system addresses network security; the configuration and operating processes need accountable owners.
Key Takeaways
- •For the next operating decision, compare ISO 27001 for startups with Statement of Applicability definition.
- •ISO 27001:2022 addresses network security through several Annex A controls.
- •This is the primary control for firewall requirements.
For the next operating decision, compare ISO 27001 for startups with Statement of Applicability definition. Confirm the work included, the evidence you need, and who will own implementation before committing to a provider.
Which Annex A controls are relevant to network security?
ISO 27001:2022 addresses network security through several Annex A controls. What we tell clients is that firewall implementation spans multiple controls, and your documentation and evidence must address each one.
A.8.20 — Network Security
This is the primary control for firewall requirements. A.8.20 requires that networks and network devices are secured, managed, and controlled to protect information in systems and applications. For firewalls, this means:
| A.8.20 Requirement | Firewall Implementation |
|---|---|
| Networks are managed and controlled | Firewall rules define what traffic is permitted and denied across network boundaries |
| Information in transit is protected | Firewalls enforce encryption requirements for traffic crossing network boundaries |
| Network devices are secured | Firewall devices themselves are hardened, patched, and access-controlled |
| Appropriate authentication for connections | Firewalls enforce authentication requirements for inbound connections |
A.8.21 — Security of Network Services
A.8.21 requires that security mechanisms, service levels, and service requirements for network services are identified, implemented, and monitored. This applies to firewall services whether self-managed or provided by a cloud platform.
What we recommend is documenting how your firewall services (whether cloud-native security groups, managed firewall appliances, or WAF services) are configured, who is responsible for them, and how they are monitored. If you use a managed firewall service, the service level agreement and security responsibilities should be documented.
A.8.22 — Segregation of Networks
A.8.22 requires that groups of information services, users, and information systems are segregated in the organization's networks. Firewalls are the primary mechanism for network segregation, and this control directly addresses the architecture of your firewall rules.
| Segregation Requirement | Firewall Implementation |
|---|---|
| Production separated from development | Firewall rules prevent direct access between production and development environments |
| Internal services separated from public-facing | WAF and network firewalls create boundary between public internet and internal services |
| Sensitive data zones isolated | Firewall rules restrict access to databases and sensitive data stores to authorized services only |
| Management networks separated | Administrative access to infrastructure is restricted to management networks or VPN |
Additional Relevant Controls
| Control | Firewall Relevance |
|---|---|
| A.8.9 — Configuration management | Firewall configurations must be managed, documented, and controlled |
| A.8.16 — Monitoring activities | Firewall logs must be monitored for security events |
| A.8.15 — Logging | Firewall events must be logged with sufficient detail |
| A.5.1 — Policies for information security | Network security policy must include firewall governance |
| A.8.32 — Change management | Changes to firewall rules must follow a defined change management process |
How do firewall types affect your implementation?
Network Firewalls
Network firewalls control traffic at the network layer based on IP addresses, ports, and protocols.
| Platform | Network Firewall | How It Works |
|---|---|---|
| AWS | Security Groups + Network ACLs | Security Groups are stateful, instance-level firewalls; NACLs are stateless, subnet-level firewalls |
| Azure | Network Security Groups (NSGs) | Stateful, can be applied to subnets or individual network interfaces |
| GCP | VPC Firewall Rules | Stateful rules applied at the VPC network level; can target instances by tags or service accounts |
| On-premises | Hardware firewalls (Palo Alto, Fortinet, Cisco) | Physical or virtual appliances deployed at network boundaries |
What we tell clients is that cloud-native firewalls satisfy ISO 27001 requirements when they are properly configured, documented, and governed. You do not need to deploy third-party firewall appliances in a cloud environment unless your risk assessment identifies a specific need.
Web Application Firewalls (WAF)
WAFs operate at the application layer (Layer 7) and protect web applications from attacks like SQL injection, cross-site scripting, and other OWASP Top 10 vulnerabilities. In our experience, WAF is increasingly expected by ISO 27001 auditors for organizations with public-facing web applications.
| WAF Solution | Platform | Key Capabilities |
|---|---|---|
| AWS WAF | AWS | Managed rules, custom rules, rate limiting, bot control; integrates with CloudFront, ALB, API Gateway |
| Azure WAF | Azure | Managed rule sets (OWASP), custom rules; integrates with Application Gateway, Front Door |
| Cloudflare WAF | Multi-cloud | Managed rules, custom rules, rate limiting, bot management; operates at the CDN/edge layer |
| GCP Cloud Armor | GCP | DDoS protection, WAF rules, adaptive protection; integrates with Cloud Load Balancing |
Cloud-Native Firewalls
Cloud-native firewalls are the advanced network security services offered by cloud providers that go beyond basic security groups.
| Service | Provider | Use Case |
|---|---|---|
| AWS Network Firewall | AWS | Stateful and stateless traffic inspection for VPCs; IDS/IPS capabilities |
| Azure Firewall | Azure | Managed, stateful firewall with built-in high availability; threat intelligence-based filtering |
| GCP Cloud NGFW | GCP | Next-generation firewall with threat detection and TLS inspection |
What we recommend is matching your firewall architecture to your actual risk profile. For most SaaS companies, cloud-native security groups plus a WAF provide adequate network security. For organizations handling highly sensitive data or subject to additional regulatory requirements, cloud-native advanced firewalls or third-party solutions may be appropriate.
Firewall Rule Management
The Principle of Least Privilege
What we tell clients is that ISO 27001 expects your firewall rules to follow the principle of least privilege: deny all traffic by default and permit only what is explicitly required. This seems straightforward, but in our experience, firewall rule sets accumulate exceptions over time and gradually drift from least-privilege to permissive.
Rule Documentation Requirements
ISO 27001 auditors expect firewall rules to be documented and justified. Every rule should be traceable to a business or technical requirement.
| Rule Documentation Element | What It Contains | Why Auditors Need It |
|---|---|---|
| Rule purpose | Business or technical justification for the rule | Validates that the rule is necessary |
| Source and destination | Specific IP ranges, security groups, or tags | Validates that the rule follows least privilege |
| Ports and protocols | Specific ports and protocols permitted | Validates that the rule is not overly permissive |
| Rule owner | Person or team responsible for the rule | Establishes accountability for rule review |
| Creation date | When the rule was created | Supports periodic review and identifies stale rules |
| Review date | When the rule was last reviewed | Validates that periodic review is occurring |
| Expiration date | When the rule should be reconsidered or removed | Prevents permanent exceptions from accumulating |
Periodic Rule Review
What we recommend is a quarterly firewall rule review where each rule is evaluated for continued necessity. In our experience, organizations that do not conduct periodic reviews end up with firewall configurations that include rules for decommissioned services, overly broad temporary rules that were never tightened, and rules that no one can explain.
| Review Activity | Frequency | Responsible Party |
|---|---|---|
| Review all firewall rules for continued necessity | Quarterly | Network security team or infrastructure lead |
| Identify and remove stale rules | Quarterly | Network security team with rule owners |
| Verify least-privilege alignment | Quarterly | Security team |
| Full firewall architecture review | Annually | Security team with management review |
| Review after significant infrastructure changes | As needed | Change management process |
Change Control for Firewall Rules
Why Change Control Matters
ISO 27001 control A.8.32 requires that changes to information processing facilities and systems are subject to change management procedures. Firewall rule changes directly affect your security posture, and uncontrolled changes are one of the most common sources of security incidents.
Change Control Process
What we recommend for firewall rule changes:
| Step | Action | Evidence Generated |
|---|---|---|
| 1. Change request | Requester submits a change request documenting the rule change, business justification, and risk assessment | Change request ticket in your change management system |
| 2. Security review | Security team reviews the proposed rule change for compliance with firewall policy and least-privilege principle | Security review approval in the change request |
| 3. Approval | Change approved by authorized personnel (typically security lead or infrastructure manager) | Approval record in the change management system |
| 4. Implementation | Rule change is implemented in a controlled manner, ideally through infrastructure-as-code | Implementation record; IaC commit in version control |
| 5. Verification | Verify the rule change works as intended and does not create unintended access | Test results documented in the change request |
| 6. Documentation | Update firewall rule documentation with the new or modified rule | Updated rule documentation |
Infrastructure as Code for Firewall Rules
In our experience, the most effective approach to firewall change control is managing firewall rules through infrastructure-as-code (IaC) tools like Terraform, CloudFormation, or Pulumi. This provides:
- Version control. Every firewall rule change is a tracked commit in your code repository.
- Review process. Pull request reviews serve as the security review step.
- Audit trail. Complete change history with who changed what and when.
- Rollback capability. Previous configurations can be restored quickly.
- Drift detection. Automated checks identify when deployed rules differ from defined configuration.
Logging and Monitoring
Logging Requirements
ISO 27001 control A.8.15 requires that logs recording activities, exceptions, faults, and other relevant events are produced, stored, protected, and analyzed. For firewalls, this means capturing sufficient log data to detect security events and support incident investigation.
| Log Type | What to Capture | Retention |
|---|---|---|
| Allowed traffic logs | Source, destination, port, protocol, timestamp for permitted connections | Depends on scope and readiness |
| Denied traffic logs | Source, destination, port, protocol, timestamp for blocked connections | Depends on scope and readiness |
| Rule change logs | Who changed what rule, when, and from what source | Depends on scope and readiness |
| Administrative access logs | Who accessed firewall management, what actions they took | Depends on scope and readiness |
| Alert logs | Security alerts generated by firewall or IDS/IPS | Depends on scope and readiness |
Monitoring Requirements
ISO 27001 control A.8.16 requires that networks, systems, and applications are monitored for anomalous behavior and appropriate actions taken to evaluate potential information security incidents. For firewalls, this means actively monitoring firewall logs, not just storing them.
| Monitoring Activity | Purpose | Implementation |
|---|---|---|
| Denied traffic analysis | Detect scanning, brute force, or reconnaissance activity | SIEM rules alerting on high volumes of denied traffic from single sources |
| Unusual permitted traffic | Detect data exfiltration or lateral movement | SIEM rules for unusual traffic volumes or connections to unexpected destinations |
| Rule change monitoring | Detect unauthorized firewall modifications | Alert on firewall rule changes outside of change management windows |
| Firewall health monitoring | Ensure firewall services are operational | Uptime monitoring for firewall services; alert on service degradation |
What we recommend is centralizing firewall logs in a SIEM or log management platform (AWS CloudWatch, Datadog, Splunk, or similar) and configuring alert rules for the monitoring activities above. In our experience, auditors specifically ask whether firewall logs are monitored, not just stored.
Which evidence should you retain for the auditor?
What to Have Ready
In our experience, ISO 27001 auditors evaluating firewall controls ask for the following evidence:
| Evidence | Source | Format |
|---|---|---|
| Network security policy | Policy management system | PDF with approval date and version |
| Firewall architecture diagram | Network documentation | Diagram showing firewall placement, network zones, and trust boundaries |
| Current firewall rule set | Cloud console, IaC repository, or firewall management platform | Export of current rules with documentation |
| Rule review records | Change management system or review log | Records of quarterly rule reviews with findings and actions |
| Change management records | Ticketing system or IaC commit history | Sample of firewall change requests with approval chain |
| Firewall logs | SIEM or log management platform | Log samples and retention configuration |
| Monitoring alert configuration | SIEM or monitoring platform | Alert rules and escalation procedures |
| Incident records | Incident management system | Records of firewall-related security events and response |
Demonstrating Continuous Improvement
What we tell clients is that ISO 27001 auditors appreciate evidence of continuous improvement in firewall management. This includes:
- Metrics showing reduction in stale firewall rules over time
- Records of firewall rules tightened during periodic reviews
- Evidence that findings from previous audits have been remediated
- Documentation of firewall architecture improvements aligned with risk assessment updates
Common Audit Findings
What We See Most Frequently
In our experience working with ISO 27001 clients, these are the firewall-related findings that auditors raise most often:
| Finding | Root Cause | How to Prevent |
|---|---|---|
| Overly permissive rules (0.0.0.0/0 inbound) | Convenience during development; rules never tightened for production | Review all rules before going to production; flag any rule permitting traffic from all sources |
| No periodic rule review | Rule review not scheduled or treated as a priority | Schedule quarterly reviews; assign ownership; track completion |
| Firewall changes without change control | Rules modified directly in console without documentation or approval | Enforce IaC for firewall rules; restrict console access; require pull request reviews |
| Insufficient logging | Default logging disabled or set to minimal; logs not centralized | Enable comprehensive logging; centralize in SIEM; verify log retention meets policy |
| Missing network segregation | Flat network architecture where all services can communicate directly | Implement network segmentation; use separate subnets/VPCs for different trust zones |
| Stale rules for decommissioned services | Services removed but firewall rules remain | Include firewall rule cleanup in service decommissioning checklists |
| No WAF for public-facing applications | WAF not deployed or not properly configured | Deploy WAF for all public-facing web applications; configure managed rule sets |
| Undocumented firewall rules | Rules exist without business justification or documentation | Require documentation for every rule; enforce through IaC and pull request templates |
Severity of Findings
What we tell clients is that not all firewall findings carry the same weight in an ISO 27001 audit:
| Severity | Examples | Impact on Certification |
|---|---|---|
| Major nonconformity | No firewall in place; no change control for network security changes; no logging of firewall events | Can prevent certification until remediated |
| Minor nonconformity | Incomplete rule documentation; periodic review not consistently performed; some stale rules present | Must be addressed with a corrective action plan; does not prevent certification |
| Observation / opportunity for improvement | WAF not deployed for all applications; logging retention below recommended period; IaC not yet adopted | Noted for future improvement; no immediate action required |
ISO’s description of ISO 27001 defines an information security management system standard. Use the standard for requirements and the organization’s risk assessment for implementation decisions.
Frequently Asked Questions
Which Annex A controls cover firewalls?
How should firewall rules be structured for ISO 27001?
Do firewall changes need change management under ISO 27001?
Tyler Carbone
Managing Director and Cofounder
Tyler Carbone is a Managing Director and Cofounder of Agency and one of the industry's leading voices on governance, risk, and compliance. He holds degrees from Harvard and a JD/MBA from the University of Virginia, and previously worked in cybersecurity at Deloitte. Tyler has helped hundreds of companies operate SOC 2, ISO 27001, HIPAA, and GDPR programs.
LinkedIn
