ISO 27001 A.8.20: Network Security

ISO 27001 A.8.20 requires that the networks carrying an organization's information are secured, managed, and controlled to protect the systems and data that run across them. It is a Technological control (A.8), and the thing teams often get flagged on is the absence of evidence that anyone reviews the rules on a schedule, rather than the firewall configuration itself.

What is ISO 27001 A.8.20?

ISO 27001 A.8.20 Network security governs the protection of information as it moves across and between networks. ISO/IEC 27001:2022, Annex A frames the control around securing networks and network devices so that the information in systems and applications is protected from compromise that arrives over the network. In the 2022 revision it consolidates several older 2013 controls (the A.13 network security family) into one technological control.

In practice, A.8.20 covers the network layer of defense: how traffic is filtered at the perimeter and between internal zones, how network devices are hardened and managed, and how the design of the network limits what a compromised host or account can reach. The control is deliberately technology-neutral. It does not name a firewall vendor or a segmentation model. What it asks is that network security decisions are deliberate, documented, and maintained rather than configured once and left alone.

How do you implement A.8.20?

Implementing ISO 27001 A.8.20 comes down to a sequence a team can follow regardless of where the infrastructure lives:

1. Document the network. Produce a current network architecture diagram showing zones, trust boundaries, ingress and egress points, and the security controls at each. This diagram is the reference every later step and every auditor works from, and it is one of the core artifacts of a documented security architecture.
2. Enforce default-deny at every boundary. Perimeter and inter-zone traffic should be blocked unless a documented rule permits it. Default-deny is typically the first design decision checked in a network security review.
3. Segment the network by trust level. Separate production from non-production, and isolate management and administrative traffic from general workloads so a compromise in one zone cannot move freely into another.
4. Control egress as well as ingress. Restrict outbound traffic to known destinations. Egress control is the part teams often skip, and it is what limits data exfiltration and command-and-control traffic.
5. Harden and manage network devices. Firewalls, switches, load balancers, and gateways get baseline configurations, restricted management access, and a change process for every rule modification.
6. Review the rules on a schedule. A quarterly review of firewall and network rules, with a documented sign-off, converts a static configuration into an operating control. This is the step that produces the evidence A.8.20 turns on.

Steps 2 through 5 implement meaningfully differently in cloud and on-prem environments. The two subsections below cover each.

In cloud environments

Cloud environments implement A.8.20 through the provider's native network primitives, configured deliberately and evidenced through configuration exports:

• Security groups and network ACLs enforce default-deny at the instance and subnet level. Security groups are the stateful, workload-level control; NACLs are the stateless subnet boundary.
• VPC and account segmentation separate production from non-production and isolate east-west traffic. The account or project boundary is the primary blast-radius control.
• A managed WAF in front of public-facing applications filters common application-layer attacks and gives a rule set that can be evidenced and version-controlled.
• TLS everywhere in transit, with provider-managed certificates and load-balancer termination, secures data as it crosses the network.
• Egress control through NAT gateways, egress firewalls, or provider egress rules restricts outbound destinations rather than allowing open internet access from production.
• Managed DDoS protection at the network edge absorbs volumetric attacks against public endpoints.

Defining these rules as infrastructure-as-code, for example in Terraform, makes the network configuration exportable and version-controlled, and drift detection through AWS Config or CSPM tooling flags rules that change outside the change process.

On-prem / self-hosted

On-prem environments implement A.8.20 with the same outcomes through physical and virtual appliances that produce their own evidence. The SOC 2 network security on-prem guide covers the full implementation; the shape is:

• Firewall appliances with a default-deny ruleset, where a rule export showing default-deny at the bottom of the chain with specific allow rules above it is clean, auditor-friendly evidence.
• VLAN segmentation on managed switches to isolate production, management, staging, and testing zones, enforced at the hardware level rather than by convention.
• An intrusion detection or prevention system monitoring critical traffic paths, with signature-based detection and a documented response process for alerts.
• Network device hardening against a documented baseline, with management protocols such as SSH and RDP restricted to authorized networks only.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.20?

Evidence for ISO 27001 A.8.20 is paired: a configuration artifact showing the control exists, plus a review or change record showing it is maintained. Teams that export rule sets and review sign-offs automatically from their tooling, rather than assembling screenshots each audit, spend far less time here; that evidence-automation approach is what GRC engineering covers.

How does A.8.20 map to SOC 2?

ISO 27001 A.8.20 is a Full overlap with SOC 2 CC6.6. Organizations with an existing SOC 2 program can reuse the same network security evidence for the ISO 27001 certification audit with no adaptation.

The SOC 2 to ISO 27001 control mapping covers the full crosswalk, including how much of an existing SOC 2 program transfers.

Related controls

ISO 27001 A.8.20 anchors the network security family in the Technological theme. A.8.21 Security of network services extends it to the security mechanisms and service levels of the specific network services in use, and A.8.22 Segregation of networks covers the zoning and segmentation A.8.20 relies on in depth. A.8.23 Web filtering addresses control of outbound access to external websites. The ISO 27001 certification guide is the hub for how these controls fit into a full ISMS.

Part of Truvo's control-by-control ISO 27001 Annex A reference series. Start from the ISO 27001 certification guide for the full picture. If you are implementing A.8.20 as part of an effective security program and want a second set of eyes on the design, Truvo offers scoping calls.

Frequently Asked Questions

What is ISO 27001 A.8.20?

ISO 27001 A.8.20 Network security is a Technological control in Annex A of ISO/IEC 27001:2022. It requires that networks and network devices are secured, managed, and controlled to protect the information in systems and applications that runs across them. It covers perimeter filtering, segmentation, egress control, device hardening, and network monitoring, and it consolidates the 2013 A.13 network security controls into one control.

What evidence satisfies A.8.20?

A.8.20 evidence is paired: a configuration artifact plus a maintenance record. Auditors expect a network architecture diagram, firewall or security group configuration exports, quarterly firewall rule review sign-offs, change records for rule modifications, egress control configuration, and IDS, IPS, or WAF alert logs with documented responses. The review sign-off is what demonstrates the control operates over time rather than existing only on paper.

How do you implement A.8.20 in the cloud versus on-prem?

Cloud implementations use provider primitives: security groups and network ACLs for default-deny, VPC and account boundaries for segmentation, a managed WAF, provider-managed TLS, egress controls through NAT or egress firewalls, and managed DDoS protection. On-prem implementations reach the same outcomes with firewall appliances, VLAN segmentation on managed switches, intrusion detection systems, and hardened network devices. The controls are equivalent; the evidence looks different.

Is A.8.20 a new control in ISO 27001:2022?

No. A.8.20 is not new to the 2022 revision. It consolidates several network security controls from the 2013 version of the standard (the A.13 communications security family) into a single Technological control. The consolidation reduced the total control count without removing the underlying network security expectations.

How does A.8.20 map to SOC 2 CC6.6?

A.8.20 maps to SOC 2 CC6.6 as a Full overlap. Both address restricting external access and securing data in transmission across network boundaries. Evidence produced for CC6.6, including network security group configurations, firewall rules, VPN configurations, and MFA for remote access records, is reusable for the ISO 27001 A.8.20 requirement without adaptation.

How often should firewall rules be reviewed for A.8.20?

Quarterly is the cadence auditors expect. Each review should export the full ruleset, confirm default-deny is in place, verify every allow rule has a documented business justification, remove temporary rules that are no longer needed, and record the review in a signed-off ticket. Rule changes made outside the quarterly cycle should go through a separate documented change process with justification.