A.8.20 Networks security: requirements and evidence

What A.8.20 networks security asks for and why it is hard to evidence

When an audit or a customer questionnaire asks how your network is protected, the honest answer has to name the devices, the boundaries and the people who change them. A.8.20 Networks security requires that networks and network devices are secured, managed and controlled to protect information in systems and applications. It is the network control in the 2022 edition of ISO/IEC 27001, and the 2022 correspondence table in ISO/IEC 27002 traces it to A.13.1.1 Network controls in the 2013 edition. Its purpose is simple to state: if a network is unmanaged, nobody can say which paths carry customer data, which devices can reach them, or who changed a rule last.

The risk of an unmanaged network is usually not a single dramatic gap. It is an undocumented firewall rule left over from a project, a cloud subnet that peers with a test environment, a wireless network that bridges to a server segment, or a management interface reachable from a user network. Each of these is a device or path that someone configured and nobody recorded. Evidence is hard because the control spans firewalls, cloud security groups and routing, wireless access points, VPN gateways and the administration paths used to change all of them, and these are rarely documented in one place. Before you prepare for an assessment, confirm with your assessor which of these components they will sample, and build one inventory of network devices, segments and administrative access paths that the sample can be drawn from.

NIST's crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022 relates A.8.20 to six controls in the AC (Access Control) and SC (System and Communications Protection) families, including AC-3, AC-18, AC-20, SC-7, SC-8 and SC-10. That mapping is useful for finding existing evidence, since many of those SP 800-53 controls are already tested in US federal and contractor environments. NIST cautions, however, that mapped controls are not always equivalent. An SC-7 boundary protection control does not automatically satisfy an ISO auditor's question about how your organization manages network devices across their life cycle. Treat the crosswalk as a starting point for gathering evidence, and confirm with your certification body how it reads the requirement in your scope.

Which networks and devices fall under A.8.20 in your scope

A.8.20 applies to every network and network device that carries information inside your ISMS boundary, so the first job is deciding what the boundary contains. The cards below cover the decisions that most often change the evidence you must produce. Confirm each choice with your certification body or assessor before you finalize the scope and Statement of Applicability.

Production and corporate networks

Production networks carry customer data, application traffic and processing workloads, while corporate networks carry office users, email and collaboration tools. Both usually fall inside scope because they carry information in the ISMS. Record each network's purpose, address ranges, the systems it reaches and who owns it. An assessor will ask whether the diagram you show matches what runs in practice, so check it against live configuration rather than an old drawing.

Cloud virtual networks and gateways

Virtual private clouds, subnets, security groups, peering links, NAT gateways and load balancers hold the same kinds of rules as physical networks, but they are often created by infrastructure code or by teams outside IT. Decide whether each account, subscription or project is in scope and whether the cloud provider's shared responsibility split is documented for the controls you rely on. Keep exported rule sets as evidence and confirm the cloud provider's own certifications cover the services you use.

Network devices and their configurations

Firewalls, routers, switches, VPN concentrators and wireless controllers are the devices that enforce network controls, so they sit at the center of A.8.20. Inventory each device with its model, firmware version, administrators and configuration owner. Confirm that hardening baselines, change records and backup copies of configurations exist for every device, including those managed by a vendor or service provider.

Management networks used for administration

Management networks carry administrative sessions to firewalls, hypervisors, directory services and backup consoles, and a compromise there can reach almost everything else. Many assessors expect these networks to be separated from user and production traffic and to be reachable only through controlled paths. Decide whether out-of-band management interfaces are in scope and document how administrators reach them.

Third-party and outsourced network services

Internet service providers, managed firewall operators, colocation facilities, SD-WAN providers and managed security monitoring vendors may run parts of your network. A.8.20 requires you to control these services, so list each one, its contract terms, its security obligations and the evidence it returns to you. Ask suppliers for their own assurance reports or certificates, and confirm which of their controls you can test.

Scoping choices that change the work

Two decisions shift the workload most. First, whether network monitoring sensors and log collectors sit inside the ISMS boundary, since placing them outside can leave their output unevidenced. Second, whether a network segment that holds regulated data is listed in the Statement of Applicability with its own justification. Record each choice in writing so the boundary and the SoA agree, and ask your certification body how it expects these choices to be documented.

How an assessor tests network security controls

This table compares what an assessor does, what evidence they request and where organizations usually fall short for each part of A.8.20. Because assessors sample, read each row as a question about whether the control operated across the whole assessment period, not only on the day of the visit.

Test approach	Evidence requested	Common findings
Interview network, infrastructure and security staff about how network devices are administered, changed and monitored	Named owners for each network segment and device class, and a description of who can change firewall rules	Staff describe a process that differs from the written procedure, or cannot name who approves changes
Review network diagrams and the device inventory against the live environment	Current diagrams with dated revisions, an inventory of routers, firewalls, switches, wireless controllers and cloud network constructs	Diagrams omit cloud VPCs, remote access paths or vendor-managed devices, so the inventory is incomplete
Sample firewall and access rules and trace each back to a business reason and an approval	Change tickets, rule justifications, owner sign-off and expiry or review dates for sampled rules	Rules with no owner or purpose, 'any-any' rules left after a project ends, or rules added without approval
Review device configuration against the organization's hardening baseline	Baseline documents, configuration exports or scan results, and records of exceptions with approval	Default administrative accounts or unused services left enabled, management interfaces reachable from user networks, and no record of exceptions
Check that network monitoring and logging produce records and that someone reviews them	Samples of log exports or alerts for a set of dates, review records, and evidence of follow-up on flagged events	Logging is configured but not retained long enough, reviews are not recorded, or alerts are sent to a mailbox nobody reads
Confirm the controls operated across the period, not just at the assessment date	Evidence dated throughout the audit period, such as periodic rule reviews, configuration checks and monitoring reports	Evidence exists only for the weeks before the audit, which assessors read as a snapshot rather than operation

Implementing network security controls in the right order

The sequence below moves from knowing what networks and devices exist, to setting the rules, then to enforcing and checking them, so every filtering rule and monitoring decision can be traced back to an inventory and a stated standard. Each step closes with a record an assessor can read.

Build the network and device inventory
Start by listing every network segment, firewall, switch, router, wireless access point, VPN gateway, load balancer and cloud virtual network that carries information in scope, with its owner, purpose and the systems it connects. Pair the list with network diagrams showing trust boundaries, internet edges and links to cloud accounts or data centers. The output is a dated diagram version and an inventory register that the network team signs off. The step is done when someone outside the team can trace any in-scope system to the segment it sits on.
Define the network security standard and hardening baseline
Write a network security standard that states what each segment type may contain, which protocols are permitted, how remote access is handled and how changes are approved. Then produce a device hardening baseline for each device class in the inventory, covering default credentials, unused services, management interfaces, logging settings and firmware currency. The output is a versioned standard and baseline documents approved by the control owner. The step is done when each inventory entry maps to a baseline it must meet.
Set up administration paths and segregated management access
Place device management interfaces on a dedicated management network that ordinary user and application traffic cannot reach. Route administrator sessions through named, individually accountable accounts and controlled jump points, and keep the configuration backups of network devices protected. The output is an administration access design, a list of who holds device access and a record of configuration backups. The step is done when a test from a user segment fails to reach a management interface and the access list matches the approved roster.
Implement filtering rules with a rule register
Translate the baseline into firewall and gateway rules, one rule at a time, each tied to a business purpose and an owner. Use aliases for address groups where the platform supports them, default to deny between segments and record the reason for every allowed flow. Tools such as OPNsense can log rule matches, which lets the team confirm that the rules behave as written. The output is a rule register with owners, justifications and review dates, plus exported rule configurations. The step is done when every allowed flow in the register traces to an inventory entry and a business reason.
Deploy monitoring and log collection
Enable network monitoring at the boundaries and between segments that matter most, for example with Suricata for alert and protocol records and Zeek for connection and protocol logs. Forward the output to a central log store with retention and access controls, and confirm that clock sources are consistent so events can be correlated. Define which alerts go to a person and who is responsible for acting on them. The output is a monitoring scope document, a sample of collected records and an alert routing table. The step is done when a test event appears in the central store with a correct timestamp and reaches the named responder.
Run the first review cycle and record the results
Compare the live configuration with the inventory, the baseline and the rule register, then list every drift, unused rule, unowned device and unexplained alert. Assign each finding to an owner with a corrective action and a closure check, and feed the results into the risk treatment and the Statement of Applicability. The output is a first review record with findings, actions and sign-off, which becomes the starting evidence trail for an assessor. The step is done when every finding is closed or formally accepted by the risk owner.

Evidence that passes an A.8.20 audit

An assessor testing A.8.20 looks for a current picture of the network, a documented way devices are hardened and changed, and proof that someone reviews what the network does. The cards below cover the artifacts that usually carry that proof, and how to keep each one current between audits. No single artifact is sufficient on its own; assessors read them together to see whether they agree.

Network diagrams and device register

Keep current diagrams of network zones, trust boundaries, gateways and cloud network paths, paired with an asset register listing every network device, its owner, its firmware version and its management address. Assessors compare the diagram against the register and against live configuration, so mismatches are the first thing they look for. Confirm that the register is reconciled after each change window, not only at audit time. Diagrams that no longer match the running network are a common finding. Automated discovery exports can feed the register, but someone must still review what they show.

Hardening baseline with proof

Document a hardening baseline for each device class, such as firewalls, switches, routers, VPN gateways and load balancers, covering management access, unused services, logging, time sources and encryption of management sessions. The evidence is not the document alone but proof that the baseline was applied: configuration exports, configuration compliance scan results, or a dated record of the deviations accepted for each device. Check that exceptions have an owner and an expiry date. Your configuration management process should own the baseline.

Firewall rule register

Maintain a register of every firewall and filtering rule with its business justification, source, destination, port and protocol, the business owner who requested it, the approver, and the dates of creation and last review. Rules without an owner or review date are the usual gap, especially old rules for decommissioned services. Export the live rule set on a schedule and compare it to the register, so that rules added directly on the device show up as discrepancies. Review rules that have not matched traffic for a long period and record the decision.

Network change records

Keep a change record for each network change, covering the request, impact assessment, approval, the window in which it was made, the test performed, the rollback plan and the person who verified the result. Assessors sample changes and trace them to the device configuration and the rule register. Changes made outside the change process, including emergency changes, should still be recorded and reviewed afterward. Ask your change system to export its records monthly so that the sample is always available.

Monitoring and log samples with review

Retain logs from firewalls, intrusion detection, DNS and VPN services, and show that someone reviewed them. Useful evidence includes dated samples of alerts or flow records, the reviewer's notes, and the tickets raised from findings. Open-source sensors such as Suricata can write alert and protocol records in JSON, and Zeek writes connection and protocol logs that link through a unique connection identifier. Confirm that retention covers the audit period and that log integrity is protected, because an assessor will ask how you know the records were not altered.

Documented administrator access paths

Document how administrators reach network devices: the jump hosts or bastions, the management networks, the accounts used, and the authentication method for each path. Show that management interfaces are not reachable from user or internet segments, and that administrator sessions are logged. Keep a current list of who holds each access path and review it on a set schedule, removing access when people change roles. An assessor will test whether a path described on paper is the only way in, so compare the documentation against the firewall rules that permit management traffic.

What meeting A.8.20 costs in money and effort

This table compares the main cost components of meeting A.8.20 Networks security, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for a fixed-scope written quote that prices each component separately. No prices or durations are given here because none have been researched for this control.

Cost component	One-time or recurring, and who is paid	What drives it up or down	How to keep it down
Tooling and licenses	Mostly recurring if commercial firewall, IDS or log platforms are used. Open-source tools such as OPNsense, Suricata and Zeek carry no license fee but still need hosting and staff time.	Number of network segments, sensors and log volume, plus vendor support tiers and per-node pricing models.	Confirm license terms before choosing a platform. Self-hosted open-source options remove license spend but shift cost into hosting and staff time.
Engineering time for design and hardening	One-time for the initial network design, documentation and device hardening. Paid to internal staff or an implementation partner under a fixed scope.	Number of network devices, sites, cloud accounts, VPNs and wireless networks, plus how much legacy configuration must be remediated.	Start with an accurate network inventory and reuse hardened baseline configurations across devices of the same type.
Network documentation and evidence upkeep	Recurring. Paid to internal network or security staff, and to any partner who maintains the documentation.	Frequency of topology and rule changes, change volume, and how much evidence is generated automatically versus collected by hand.	Generate configuration exports and log records automatically, and tie rule changes to the change management process.
Monitoring and log management	Recurring. Covers storage, analyst time for reviewing alerts, and hosting for sensors and log stores.	Traffic volume, number of sensors, retention period, and the number of alerts that need human triage.	Tune rules to reduce false positives, set retention to what policy requires, and split high-volume outputs into separate files.
External testing or review	Periodic. Paid to an independent tester or reviewer who examines firewall rules, segmentation and exposed services.	Scope of the network, number of external-facing services, and whether testing covers internal segments and cloud networks.	Limit scope to documented boundaries, fix known exposures before testing, and agree the scope in writing.
Auditor sampling and assessment	Recurring with each audit cycle. Paid to the accredited certification body, which decides what it samples.	Number of sites and networks in the certificate scope, the volume of evidence the auditor requests, and the quality of records.	Keep one consistent evidence set for network rules, diagrams and reviews, and ask the certification body to confirm its sampling approach before the audit.
Written quote	Ask the implementation partner for a fixed-scope quote that lists each component above as a separate line with its one-time or recurring status.	Clarity of scope, deliverables and responsibilities agreed before work starts.	Require the quote to state which items the organization owns and which items the partner prepares.

Self-hosted open-source tools that produce network evidence

Each tool below covers a different layer of the network: the perimeter, the traffic on the wire, the connection record and the web application. Together they can produce the rule sets, logs and detections an assessor asks to see for A.8.20, but each one needs to be configured, retained and reviewed by the organization that owns the control.

OPNsense packet filtering

OPNsense is a stateful packet filter where each rule passes, blocks or rejects traffic by source, destination, port and protocol. Aliases group addresses so that rules stay readable as the network grows, and enabling per-rule logging lets reviewers see rule matches in the live log view. For A.8.20, the rule base itself is the evidence: export it, version it and confirm that every change has an approval record. Confirm that your firewall hardware and HA design match your availability needs. License: BSD-2-Clause.

Suricata network threat detection

Suricata inspects network traffic against rule sets and writes its output in EVE JSON, covering alerts, anomalies, flows, and protocol transactions such as HTTP, DNS, TLS, SSH and SMB. The EVE output can be split into separate files, which makes it easier to route alerts and flow records into a log management tool. Its records give an assessor a way to see that network activity is monitored, but the sensor must sit where the traffic you need to see actually passes. Confirm sensor placement and rule update procedures for your environment. License: GPL-2.0-only.

Zeek connection and protocol logs

Zeek writes dozens of logs by default. The conn.log records who communicated with whom, for how long, how much data moved and over which protocol for TCP and UDP traffic. Protocol logs such as dns.log and http.log add detail, and weird.log captures anomalous events. All of these share a unique connection identifier, so an investigator can trace one session across logs. For A.8.20, this supports network documentation and review of communication paths. Confirm storage sizing and retention periods with your log platform team. License: BSD-3-Clause.

Coraza web application firewall

Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It defends against attacks such as SQL injection, cross-site scripting and code injection, and it integrates with Caddy, HAProxy, Traefik and Nginx. Placing it in front of published applications gives you an enforced, reviewable control point and a log of blocked requests. Confirm that your rule set is tuned to your applications, that exceptions are approved and documented, and that your reverse proxy is supported in your stack. License: Apache-2.0.

Who owns network controls, who can help and what the auditor checks

The organization owns its network controls. Your team decides which networks exist, which segments need separation, which firewall rules are allowed and which residual risks are acceptable. A partner or auditor can inform those decisions, but neither can make them on your behalf. The people who approve the Statement of Applicability and answer for network incidents must belong to the organization.

Rule ownership: Named engineers approve each firewall, routing and gateway rule and record the business reason for it.
Risk acceptance: An accountable manager accepts in writing any residual network risk, such as a legacy protocol that cannot yet be removed or an exception to a segregation boundary.
Ongoing review: Your team sets the review schedule for rule sets, device configurations and monitoring coverage, and routes every change through change management.
Alert handling: Your staff triage alerts from network sensors and decide which ones count as security events.
Evidence custody: Logs, diagrams and review records are kept under your retention rules and stay available to the auditor.

Confirm that each of these responsibilities has a named owner, a deputy and a dated record of the most recent review.

Where network security evidence usually falls short

Network controls under A.8.20 are rarely missing outright. They fail on evidence: diagrams that drift from the live network, rules nobody reviews, and changes that bypass the process the organization says it follows. The six gaps below are the ones assessors most often trace back to a document that no longer matches reality.

Diagrams that drift from the network

A network diagram dated from the last migration is weak evidence once segments, cloud VPCs and VPN tunnels have been added. Assessors compare the diagram with device configurations and flow data, and a mismatch undermines every other network record. Close it this month by exporting the current firewall interfaces, routing tables and cloud subnet lists, then marking each difference on the diagram with a named reviewer and a date.

Firewall rules without owners

Rules that allow traffic with no business justification, no owner and no review date are a common finding. Each rule should trace to a documented service and an accountable team, and unused rules should be removed rather than left in place. Close it this month by adding a description, owner and review date to every rule that allows traffic from outside the trusted zones, starting with the broadest sources and destinations.

Administrative access on production networks

When administrators reach firewalls, hypervisors and databases over the same network that carries customer traffic, a compromise of one workstation can reach the management plane. Segregation under A.8.22 and the network controls under A.8.20 both depend on separating these paths. Close it this month by listing every management interface and confirming which network it sits on, then moving at least the firewall and hypervisor administration to a dedicated management segment with restricted source addresses.

Logs that nobody reviews

Firewalls and intrusion detection systems can produce large volumes of records that are stored but never read. Assessors ask who reviews network logs, how often, and what happens when a rule match looks wrong. OPNsense can log each rule match, and Suricata writes EVE JSON alerts that can be split for a log management tool. Close it this month by naming a reviewer for denied and alerted traffic and recording the date of each review.

Cloud network rules changed outside change control

Security group, network ACL and route table edits made directly in a cloud console often bypass the change process that A.8.32 requires. The resulting configuration cannot be reconstructed from a ticket, and the audit trail depends on the provider's logs. Close it this month by pulling the last 90 days of cloud network change events, matching each to a change record, and flagging the unmatched ones for review. Confirm with your provider which change events are retained and for how long.

Undocumented vendor exceptions

Vendors often need inbound access, a standing VPN or an exception to a segmentation rule to support a product. When these exceptions are granted by email and never recorded, they become the path an auditor finds first. Relevant supplier obligations also sit under A.5.19 and A.5.21. Close it this month by listing every vendor connection, its business reason, the approver, the source addresses and the date it must be reviewed, and removing any connection with no current contract.

Questions buyers ask about A.8.20 before hiring outside help

Is A.8.20 more work than the rest of Annex A?

No single control is reliably heavier than another, but A.8.20 tends to need more technical depth because it covers physical and virtual network devices, their configuration and their traffic. The effort depends on how many network segments, firewalls, switches, load balancers, VPN gateways and cloud network constructs are in scope, and on how much of that is already documented. Organizations with few network changes and clear diagrams usually find it lighter than controls that depend on people and policy across the whole company. Ask any partner to show how they will size the network inventory before agreeing a scope.

Can a small team run A.8.20 without outside help?

A small team can usually run A.8.20 alone if one or two engineers already administer the network and can keep a current inventory, a hardening baseline and a change record. The harder part is producing evidence that the controls operated over time, such as rule reviews, monitoring records and change approvals, because that work competes with daily operations. Outside help makes sense when nobody has the time to write the baseline, when the environment spans several clouds or sites, or when the team has never prepared for an assessment. Decide which parts the team will own before requesting a quote.

What does A.8.20 require from our own staff?

Your staff must own the controls, which means deciding how networks are segmented, who may administer network devices, which services are allowed through and how changes are approved. Engineers must be able to explain the design, review rules and respond to alerts, and management must accept the residual risk. An implementation partner can draft documentation and configure tooling, but people in your organization need to sign off on decisions and keep operating the controls after the engagement ends.

How long does A.8.20 work take?

Duration depends on scope and the written scope sets the timeline. The main drivers are the number of network zones and devices, the state of existing documentation, how many environments are involved and how quickly your team can review and approve changes. Ask the partner to break the timeline into documentation, hardening, logging and monitoring, and evidence collection, and to name which milestones depend on your staff.

Can a consultant or partner issue the A.8.20 evidence for our audit?

No. A partner can prepare network diagrams, device baselines, rule reviews, configuration exports and monitoring records, but only the independent auditor or certification body issues the report or certificate. Your organization remains responsible for its controls and for the accuracy of evidence it presents. Ask any partner to state this in writing, and ask the certification body which evidence formats it accepts before the engagement starts.

Are self-hosted open-source tools acceptable evidence for A.8.20?

Tool choice is not what an auditor tests. An auditor looks for a documented design, consistent operation and records that show it, and self-hosted tools such as a stateful firewall, an intrusion detection engine or a network metadata logger can produce those records if they are configured, retained and reviewed. For example, an OPNsense rule set exported with change history, or Suricata or Zeek logs retained under your logging policy, can support the control. Confirm with your auditor how they want exports, timestamps and access to the tooling demonstrated.

How does A.8.20 relate to NIST SP 800-53 and NIS2 point 6.7?

Mapping resources link A.8.20 to related controls, but they do not make them equivalent. NIST's crosswalk relates A.8.20 to six SP 800-53 controls in the AC and SC families, including access enforcement, remote access, transmission confidentiality and network connection controls, and NIST cautions that mapped controls are not always equivalent. ENISA's NIS2 technical guidance table links A.8.20 to point 6.7 on network security of Implementing Regulation (EU) 2024/2690. Use these mappings to reuse evidence where the requirements overlap, then check each framework's own wording and assessor expectations separately.

What should we confirm in a quote for A.8.20 work?

Ask the partner to confirm the written scope, which networks, sites, clouds and devices are included, and what is excluded. Request the deliverables in writing, such as the network inventory, diagrams, hardening baseline, rule review procedure, logging design and evidence index, and ask which of these need your sign-off. Confirm who owns the configuration after handover, what ongoing support is one-time and what recurs, how changes after scope agreement are priced, and that the partner does not issue audit reports or certificates.

How DeployOpen scopes, implements and prepares network evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so network controls for A.8.20 are built where your systems run. We prepare the systems, configurations and evidence; the organization owns the control and an independent auditor or certification body issues any report or certificate.

How we scope

Agree in writing which network segments, firewalls, gateways and monitoring points fall inside the A.8.20 scope.
Inventory network devices, administrators and management paths so the network documentation matches what is actually deployed.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts; a quote follows from that written scope.

How we build

Harden firewall rule sets such as OPNsense with documented source, destination, port and protocol rules and aliases for address groups.
Deploy inspection and logging components such as Suricata EVE JSON output and Zeek connection logs into your monitoring stack.
Configure web application protection such as Coraza with OWASP Core Rule Set rulesets where your published services need it, then test the configuration.

How we hand over

Deliver network diagrams, device baselines, rule documentation and administration procedures that your assessor can trace to the control.
Show evidence of rule match logging, log retention and review records, with the exact configuration files and versions in use.
Document open items and the owner for each, so your organization can run the controls and answer assessor questions without us.

How we support

Support, upgrades and continuous security testing of the network platform are available as a retainer after handover.
Re-test network exposure and configuration drift on a schedule agreed in the contract, and record the results as evidence.
Confirm with your auditor which evidence they expect for A.8.20 before the assessment, since certification scope and expectations vary.