Network Security Standard Template (ISO/IEC 27001 A.8.20 to A.8.23)

Network Security Standard: [Organization name]

Organization-wide standard for protecting networks and the information that crosses them: network zones and segmentation, rule management for firewalls and cloud security groups, remote and administrative access, wireless, DNS and web filtering, agreements for network services, and network monitoring. It supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A controls A.8.20 (network security), A.8.21 (security of network services), A.8.22 (network segregation) and A.8.23 (web filtering, new in 2022), with implementation guidance from ISO/IEC 27002:2022 and the network security series ISO/IEC 27033. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose and scope
2. Control mapping
3. Roles and responsibilities
4. Standard statements
5. Network zones and segregation
6. Rule management for network security controls
7. Remote and administrative access
8. Wireless networks
9. DNS, web filtering and egress control
10. Network services and suppliers
11. Device hardening and network monitoring
12. Exceptions
13. Size tiers
14. Records and evidence
15. References
16. Standard and licence note

1. Purpose and scope

This standard sets the minimum requirements for designing, operating and monitoring the networks that carry [Organization name] information. Its aims are to:

• keep untrusted traffic out of trusted zones and limit how far an attacker can move after an initial compromise;
• make every permitted flow deliberate, owned, justified and reviewed;
• protect the confidentiality and integrity of information in transit and the availability of network services that the business depends on;
• reduce exposure to malicious and unwanted web content;
• give the security monitoring function the network telemetry it needs.

The standard applies to every network inside the ISMS scope (DOC-ISMS-002): office local area networks, wireless networks, data centre and colocation networks, public cloud virtual networks and their security groups, software-defined WAN links, remote access services, and operational technology (OT) networks where present. It applies to employees, contractors and suppliers who design, change or operate those networks.

Out of scope: networks of customers and suppliers that [Organization name] does not control, except where a contract gives it responsibilities (section 10), and home networks of remote workers, which are covered by the remote working policy (DOC-ISMS-054) through device-level controls.

2. Control mapping

Related controls that this standard relies on but does not own: A.5.14 information transfer (DOC-ISMS-043), A.8.2 privileged access rights (security/privileged-access-standard), A.8.9 configuration management (DOC-ISMS-060), A.8.15 logging and A.8.16 monitoring (DOC-ISMS-064), A.8.24 use of cryptography (security/cryptography-standard) and A.8.32 change management (ops/change-enablement-policy).

3. Roles and responsibilities

4. Standard statements

5. Network zones and segregation

5.1 Zone model

Rules for the zone model:

1. Separate production from non-production at the account or subscription level where the platform allows it, not only by subnet.
2. Place systems that store or process information classified Confidential or above in Z3 or behind Z3 controls.
3. Treat OT as its own family of zones. Traffic between IT and OT passes through an industrial DMZ; no direct route from Z5 to Z8 is allowed.
4. Use micro-segmentation (security groups per service, Kubernetes network policies) inside Z2 and Z3 where the platform supports it.
5. Payment card environments, if any, follow the scoping and segmentation method in compliance/pci-dss-scoping-segmentation in addition to this standard.

The diagram shows every permitted flow in the matrix in 5.2, in the direction in which connections are initiated. Return traffic of an allowed session is permitted by stateful inspection; no other flow exists unless listed in 5.2.

5.2 Inter-zone flow matrix

Read the matrix as "source row may initiate to destination column". "Rule" means allowed only by a specific owned rule; "No" means denied.

Z3 initiates nothing to other zones: backups are pulled by the backup service from Z4. Database replication between the primary and DR regions stays inside Z3, runs over provider private links and is recorded as intra-zone rules owned by the database team.

6. Rule management for network security controls

6.1 Rule requirements

Every rule records: rule ID, source, destination, service and port, action, owner, business justification, data classification of the flow, change reference, date created, expiry date (if temporary) and date last reviewed. Rules are written as narrowly as the service allows: named hosts or groups, named ports, and logging enabled on deny rules and on allow rules between zones.

6.2 Rule lifecycle

1. The rule owner raises a change request (ops/change-request) with the fields in 6.1.
2. A network engineer checks the request against the flow matrix. Flows that the matrix marks "No" are rejected or go to the exception process (section 12).
3. The security team reviews requests that open inbound access from Z0, reach Z3, Z4 or Z8, or use broad ranges.
4. The change approver approves; the engineer implements, preferably as code through a reviewed pull request.
5. The engineer tests the rule and records the change reference on it.
6. Temporary rules are removed automatically or by ticket on expiry.
7. Rules are confirmed or removed at each periodic review.

6.3 Review cadence

Set the frequency from risk and from any contract or regulation that demands a shorter interval (for example PCI DSS for card environments). Rules with no hits in the review period are flagged for removal unless the owner documents a reason, such as a disaster recovery path.

7. Remote and administrative access

User remote access. Staff reach internal applications through [zero trust network access (ZTNA) / an identity-aware proxy / a VPN gateway] that enforces single sign-on with multi-factor authentication and checks device compliance (managed, encrypted, EDR running, operating system supported) before each session. Access is per application, not to whole subnets, where the service supports it. The design principles follow security/zero-trust-architecture.

Administrative access. Administrators reach Z2, Z3, Z4 and network device management only through the privileged access path: a privileged access workstation or bastion in Z4, with phishing-resistant MFA, just in time elevation and session recording as set in security/privileged-access-standard. Cloud console and API access to network resources uses the same identity controls.

Supplier remote access. Suppliers connect only through a brokered, logged session to named systems, approved per session or for a fixed period, with the account disabled between sessions. The supplier's access is recorded in the supplier register (DOC-ISMS-066).

Session controls. Idle remote sessions time out after [15 minutes] (Example). Split tunnelling is [allowed for named SaaS traffic only / not allowed]; web traffic of remote devices still passes the web filtering service (section 9) through the endpoint agent.

8. Wireless networks

Requirements:

• Change any pre-shared key when a person who knew it leaves or at least every [12 months] (Example).
• Run a rogue access point scan [quarterly] (Example) at each office and record the result.
• Manage access points centrally; disable local administrative interfaces and keep firmware within vendor support.
• Do not extend corporate wireless to production or OT zones.

9. DNS, web filtering and egress control

Protective DNS. Corporate devices and servers resolve names through the approved resolver, which blocks known malicious and newly registered domains and logs queries. Direct outbound DNS (port 53 and DNS over HTTPS to unapproved resolvers) from Z2, Z3, Z5 and Z7 is blocked at the boundary or by the endpoint agent.

Web filtering. Web traffic from Z5, and from remote corporate devices through the endpoint agent, passes a secure web gateway or filtering service with the category policy below. Filtering is applied to protect users and systems from malicious content, not to monitor individuals; the acceptable use policy (DOC-ISMS-040) tells staff that filtering and logging exist.

Users request access to a wrongly blocked site through the service desk. The security team decides within [2 business days] (Example) and records the decision. TLS inspection, if used, excludes categories such as health and banking, and its use is assessed for privacy and labour law in each country of operation.

Server egress. Z2 and Z7 reach the internet only through an egress proxy or NAT with an allow list of destinations (package repositories, supplier APIs). Z3 has no internet egress.

10. Network services and suppliers

For each network service, the supplier manager records the service in the supplier register (DOC-ISMS-066) and makes sure the agreement or service description (DOC-ISMS-068) covers:

• security features provided (encryption, DDoS protection, filtering, redundancy) and which are switched on;
• service levels for availability and incident response, with credits;
• notification of security incidents and planned changes, with time limits;
• management access: who may change the configuration, how changes are approved and logged, and whether [Organization name] can see logs;
• right to audit or to receive independent assurance reports;
• data location for any logs or traffic data the supplier keeps;
• exit support, including handover of configurations.

11. Device hardening and network monitoring

Hardening. Network devices and cloud network services follow the secure configuration baseline (DOC-ISMS-060): default credentials changed, unused services disabled, management on dedicated interfaces in Z4, SNMPv3 or equivalent, time synchronized to approved sources, and configuration backed up after every change and at least [weekly] (Example). Edge devices are patched under the vulnerability management policy (security/vulnerability-management-policy); a vulnerability in a boundary device that is listed in the CISA Known Exploited Vulnerabilities catalog is treated with the highest priority.

Monitoring. The following network sources feed the central log platform defined in DOC-ISMS-064 and the security logging standard (security/security-logging-standard):

Alert use cases for these sources, triage and escalation are defined in the security monitoring procedure (DOC-ISMS-064).

12. Exceptions

A deviation from a MUST statement requires a security exception request (security/security-exception-request, DOC-ISMS-122) that records the statement affected, the business reason, compensating controls, the risk score on the 5 x 5 scale of the risk methodology (DOC-ISMS-010), the risk owner and an expiry date. Each exception is approved at the authority the risk methodology (DOC-ISMS-010 section 2.4) sets for the residual risk: the risk owner for Low; the risk owner and department head for Medium (top management if the risk category is Averse, DOC-ISMS-015 section 9 rule 1); top management with a treatment decision for High, recorded in the risk acceptance record (DOC-ISMS-019). Critical residual risk is not approvable as an exception: treat it or stop the activity. Maximum duration is 12 months for Low or Medium and 6 months for High; at expiry the exception is reassessed, and a renewal is a new decision (DOC-ISMS-122 section 7).

13. Size tiers

14. Records and evidence

Set retention from the legal register (DOC-ISMS-014) and the retention standard (data/data-retention-deletion-standard). Report compliance metrics, such as the share of rules with an owner and the number of expired temporary rules found, through the measurement programme (isms/isms-measurement-programme).

15. References

Official pages: ISO/IEC 27001 https://www.iso.org/standard/82875.html, Amd 1 https://www.iso.org/standard/88435.html, ISO/IEC 27002 https://www.iso.org/standard/75652.html, ISO/IEC 27033-1 https://www.iso.org/standard/63461.html.

Related templates: security/firewall-rule-review, security/zero-trust-architecture, security/privileged-access-standard, security/security-logging-standard, security/cryptography-standard, isms/secure-configuration-baseline, isms/security-monitoring-procedure, isms/remote-working-policy, isms/supplier-register, isms/supplier-security-agreement-27036, isms/control-evidence-matrix, compliance/statement-of-applicability, compliance/pci-dss-scoping-segmentation.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 (including Amd 1:2024) Annex A controls A.8.20 to A.8.23 and the guidance in ISO/IEC 27002:2022. Only control numbers are used, with short labels in the style of the Statement of Applicability; the requirements, zone model, examples and guidance are original wording, and no ISO/IEC text is reproduced. ISO and IEC standards are copyrighted: obtain the official standards from ISO, IEC or your national standards body to implement and audit them (https://www.iso.org/standard/82875.html). Check the current edition and amendments before use. Certification decisions belong to the accredited certification body. Template licence: MIT.