Annex A 8.20: Network Security

To meet the annex a 8.20: network security requirement, you must define, implement, and maintain network security controls that protect information in networks and supporting services, then prove those controls operate consistently. Operationalize it by documenting your network security standard, mapping controls to network zones and data flows, and retaining recurring technical evidence (configs, logs, reviews) tied to risks and assets.

Key takeaways:

• Document your network security approach in a standard that maps to real network segments, trust boundaries, and owners.
• Implement technical controls (segmentation, secure configuration, traffic filtering, monitoring) and make them auditable with repeatable evidence capture.
• Treat “evidence of operation” as a deliverable: configs, change records, reviews, alerts, and exceptions with approvals.

Annex A 8.20 focuses on one operational reality: most security failures become incidents through the network path. For ISO 27001:2022, “network security” is not a single device or tool; it is the set of documented rules and technical controls that govern how systems connect, how traffic is allowed, how networks are managed, and how you detect abnormal behavior.

A CCO, GRC lead, or compliance owner usually gets pulled into this control late, during audit prep, and finds two gaps: (1) the network team has strong engineering practices but weak traceable evidence, or (2) there is documentation but it does not match the actual architecture (cloud networks, SaaS connectivity, remote access, third-party links, and production-to-corporate pathways).

This page gives requirement-level implementation guidance you can execute quickly: who owns what, what “good” looks like, what auditors ask, and what artifacts to retain. It also reflects a recurring ISO reality: you will pass or fail 8.20 based on whether you can show consistent operation over time, not whether you can describe an ideal design on paper. ¹

Regulatory text

Excerpt (provided): “ISO/IEC 27001:2022 Annex A control 8.20 implementation expectation (Network Security).” ¹

Operator interpretation (what you must do):

• Establish network security controls that are appropriate for your environment (on-prem, cloud, hybrid, remote access, and third-party connectivity).
• Ensure controls are defined (documented), implemented (technical enforcement), and maintained (reviewed, updated, and monitored).
• Be able to demonstrate the control is working through repeatable evidence capture aligned to your ISMS. ¹

Plain-English interpretation of the requirement

Annex A 8.20 expects you to prevent unauthorized network access, restrict unnecessary connectivity, and detect suspicious network activity. Practically, that means you define network zones and trust boundaries, control traffic between them, secure the management plane (how networks are administered), and monitor the environment so you can respond to misuse.

For auditors, “network security” will be tested at boundaries:

• Internet ↔ public services
• Corporate IT ↔ production environments
• Production ↔ production (east-west traffic)
• Remote user ↔ internal resources
• Your environment ↔ third parties (VPNs, dedicated links, integrations)
• Cloud VPC/VNet ↔ SaaS and identity providers

Who it applies to

Entity scope: Any organization implementing ISO/IEC 27001 with networks that store, process, or transmit information, including service organizations. ²

Operational scope (where this control shows up):

• Cloud networks (AWS/Azure/GCP security groups, NACLs, route tables, private endpoints)
• On-prem network infrastructure (firewalls, routers, switches, wireless controllers)
• Remote access (VPN/ZTNA, bastions, admin access paths)
• Kubernetes and container networking (network policies, ingress/egress)
• Third-party connections (support vendors, data processors, managed services, payment providers)
• Network management tooling (SIEM, NDR, firewall managers, DNS filtering)

Typical owners to assign (avoid shared accountability):

• Network Engineering: design, configuration standards, firewall rules
• Security Engineering/SecOps: monitoring, detection, logging, response
• IT Operations: endpoint and remote access enforcement
• GRC/Compliance: policy/standard governance, evidence mapping, exceptions register

What you actually need to do (step-by-step)

1) Define the control in an auditable “Network Security Standard”

Write a short, enforceable standard (not a whitepaper) that answers:

• What are your network zones and trust boundaries (prod, corp, dev, management, DMZ, restricted)?
• What traffic is allowed between zones and why (business justification)?
• What is the baseline for perimeter and internal segmentation controls?
• How do you secure administrative access to network devices and cloud networking?
• What is logged, where, and who reviews it?
• How are rule changes requested, approved, tested, and rolled back?

Audit tip: Tie each section to real technologies in your environment. If you say “all inbound traffic is blocked by default,” show the default-deny policy at the edge and in cloud security groups.

2) Map networks to assets, systems, and data flows

Create (or update) three simple maps:

• Network inventory: key network components and their owners (firewalls, gateways, VNets/VPCs, VPN, WAF, DNS)
• Zone diagram: segments and trust boundaries
• Data flow summary: how sensitive data moves (customer data, credentials, regulated data)

Keep it maintainable. One-page visuals beat a 40-page diagram nobody updates.

3) Implement minimum technical control set (baseline)

A practical baseline that satisfies most ISO expectations for 8.20 includes:

Traffic control

• Default-deny inbound at the perimeter; explicitly allow required ports/services.
• Restrict outbound traffic where feasible for high-sensitivity segments.
• Segment production from corporate and from development/test.
• Apply internal filtering for admin protocols and management interfaces.

Secure configuration

• Standard configurations for firewalls/security groups (naming, tagging, logging on, time sync).
• Remove “any/any” rules or document approved exceptions with expiry.

Secure management plane

• Administrative access through controlled paths (bastion, privileged access, or dedicated admin networks).
• Central identity for admin actions where possible; log admin activity.

Monitoring and detection

• Log firewall/security group activity appropriate to risk.
• Route critical network logs to a centralized logging/SIEM destination for retention and review.

Choose controls that match your architecture. Cloud-only environments still need segmentation and monitoring; they just look like security groups, route controls, and cloud-native logging.

4) Put a change-control workflow around network rules

Auditors will probe firewall/security group changes because that’s where “policy” diverges from “practice.”

Minimum workflow elements:

• Ticket or request record for each material rule change
• Business justification (what system, what need)
• Risk check (exposure created, data classification impacted)
• Approval (named approver with authority)
• Implementation record (who changed what, when)
• Validation (test, monitoring, rollback plan if needed)

5) Establish recurring reviews that produce evidence

Define recurring reviews that a small team can actually complete:

• Review perimeter rulebase for stale/overbroad rules
• Review third-party connections and remote access pathways
• Review high-risk segments (prod management plane, database subnets)
• Review logging coverage and alerting for key network events

A review that produces a signed output and tracked remediation is stronger than an informal “we look at it.”

6) Manage exceptions explicitly

You will have exceptions (legacy apps, vendor requirements, emergency access). Make them auditable:

• Exception statement, scope, compensating controls
• Expiry date and re-approval requirement
• Owner and risk acceptance approver
• Plan to remediate or redesign

7) Make evidence capture automatic where possible

The fastest way to operationalize 8.20 is to treat evidence as a byproduct of operations:

• Export firewall rulebase snapshots on a schedule
• Save change tickets with approvals
• Centralize logs and keep review notes
• Store architecture diagrams with version history

Where Daydream fits naturally: If your teams already run good network security but struggle to assemble audit-ready proof, Daydream helps you map 8.20 to control statements, assign owners, and collect recurring evidence (config exports, review attestations, change records) in one place so audits stop turning into a scavenger hunt.

Required evidence and artifacts to retain

Use this as your 8.20 evidence checklist.

Evidence item	What “good” looks like	Owner
Network Security Standard	Approved, versioned, mapped to zones and technologies	GRC + Network Eng
Network/zone diagram	Current, shows trust boundaries and key ingress/egress	Network Eng
Asset inventory (network components)	Owners, environment, purpose, criticality	IT/Network Eng
Firewall/security group rule review output	Dated review, findings list, remediation tickets	Network Eng + Security
Change records for network rules	Tickets with approval, implementation notes, validation	Network Eng
Logging/monitoring proof	Central log routing, sample events, review notes	SecOps
Third-party connectivity register	List of external connections, purpose, controls, review	Security + Procurement/TPRM
Exceptions register	Approved exceptions with expiry and compensating controls	GRC

Common exam/audit questions and hangups

Expect these questions, and prepare the artifacts above to answer them quickly:

1. “Show me your network segmentation.”
   Hangup: diagrams are outdated or don’t reflect cloud networks.

2. “How do you ensure only required traffic is allowed?”
   Hangup: “temporary” rules never removed; no periodic review evidence.

3. “Who can change firewall/security group rules, and how is it approved?”
   Hangup: emergency changes bypass workflow with no after-the-fact review.

4. “How do you monitor the network for suspicious activity?”
   Hangup: logs exist but no defined review cadence, alert handling, or ticket linkage.

5. “How are third-party connections controlled?”
   Hangup: unmanaged vendor VPNs or support tunnels without documented risk acceptance.

Frequent implementation mistakes (and how to avoid them)

• Mistake: policy says “default deny,” engineering reality includes broad allow rules.
  Avoid it: run a perimeter and internal rule review, document exceptions with expiry, and align the standard to what you enforce.

• Mistake: cloud networking is treated as “application-owned,” so nobody owns the control.
  Avoid it: assign named owners for VPC/VNet governance and require tagging plus review evidence.

• Mistake: logging exists but isn’t tied to operational review.
  Avoid it: define which events are reviewed, who reviews them, and store the review output.

• Mistake: third-party connectivity is invisible to GRC.
  Avoid it: maintain a register of external connections and tie it to third-party due diligence and periodic access reviews.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this control. Practically, weak network security increases the likelihood and blast radius of unauthorized access, data exfiltration, ransomware propagation, and service disruption. For ISO audits, the most common risk is not “no firewall,” it’s inability to demonstrate consistent control operation and governance over time. ¹

Practical execution plan (30/60/90)

Use this as an operator’s rollout sequence; adjust scope to your environment size and change velocity.

First 30 days (stabilize scope and evidence)

• Publish the Network Security Standard and name control owners.
• Build/update zone diagram and external connectivity list (internet edges, VPN/ZTNA, third-party links).
• Identify high-risk segments and crown-jewel systems, then confirm ingress/egress control points.
• Stand up an evidence folder structure (or Daydream collection) for configs, reviews, and tickets.

Next 60 days (control operation and repeatability)

• Implement or tighten segmentation between corp and production; restrict management-plane access paths.
• Establish firewall/security group rule change workflow with required approvals.
• Configure central logging for key network control points and document review procedures.
• Run the first formal rulebase review; open remediation tickets and track to closure.

By 90 days (audit-ready, sustained operations)

• Complete a second review cycle (even if limited scope) to prove repeatability.
• Mature exceptions: add expiries, compensating controls, and re-approval triggers.
• Verify third-party connectivity controls align with contracts and access requirements.
• Prepare an audit packet: standard, diagrams, inventories, review outputs, sample change records, and logging evidence.

Frequently Asked Questions

What counts as “network security” in a cloud-only company?

Your network controls are still network controls; they show up as security groups, route controls, private connectivity, and identity-controlled administration. Auditors will expect the same governance: segmentation, controlled ingress/egress, change control, and monitoring evidence. ¹

Do we need a separate firewall rule review process if we only use security groups?

You need a review of whatever enforces network traffic decisions. If security groups are your control point, review their rules, ownership, change history, and exceptions with the same rigor you would apply to a firewall.

How detailed do network diagrams need to be for ISO 27001 audits?

Make them accurate enough to show trust boundaries, critical ingress/egress points, and production versus corporate separation. Overly detailed diagrams become stale quickly; auditors prefer correctness, ownership, and update history over exhaustive topology.

What evidence is strongest for proving 8.20 is operating?

Dated artifacts that show repeatable operation: rule reviews with findings, change tickets with approvals, configuration exports, and monitoring review records. A well-written policy without operational outputs usually fails under sampling.

How should we handle vendor-required “any/any” connectivity?

Treat it as an exception with a business justification, compensating controls (time-bound access, source IP restrictions, monitoring), an explicit approver, and an expiry. Track remediation options, such as narrowing ports or moving to a controlled access path.

We have good network engineering but weak audit packaging. What’s the fastest fix?

Keep engineering workflows intact and add an evidence layer: standardize rule review output, export configurations on a schedule, and link changes to tickets with approvals. A system like Daydream helps you map 8.20 to these recurring artifacts so you can answer auditor samples quickly.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview