Compliance Framework Alignment
ISO/IEC 27001:2022 — A.8.20 (Networks security) ISO/IEC 27001:2022 — A.8.21 (Security of network services) ISO/IEC 27001:2022 — A.8.22 (Segregation of networks) ISO/IEC 27001:2022 — A.8.23 (Web filtering) SOC 2 — CC6.6 (boundary protection against threats from outside the system boundaries) PCI DSS v4.0.1 — Requirement 1 (install and maintain network security controls / NSCs) PCI DSS v4.0.1 — 1.2.7 (NSC configurations reviewed at least once every six months) This policy operationalises the network-security controls of the frameworks above. It is a template and not legal or compliance advice; the network architecture, segmentation boundaries and rulesets must be validated against a current risk assessment and, where applicable, a QSA assessment before an audit.
ACME TECHNOLOGIES PVT LTD NETWORK SECURITY POLICY
Effective Date [Effective Date]
Policy Owner Chief Information Security Officer (CISO / Head of Infrastructure )
Review Cycle Annually, and NSC configurations at least every six months
Classification Internal — Controlled Document 1. Purpose and Scope
This policy establishes the mandatory rules for securing the networks of Acme Technologies Pvt Ltd ("the Organisation") in accordance with ISO/IEC 27001:2022 Annex A controls 8.20 (networks security), 8.21 (security of network services), 8.22 (segregation of networks) and 8.23 (web filtering). It applies to all wired, wireless, cloud and virtual networks, to every device and service that connects to them, and to all employees, contractors and third parties who design, operate or use the Organisation's network infrastructure. Where the Organisation stores, processes or transmits cardholder data, this policy additionally governs the network security control (NSC) obligations of PCI DSS v4.0.1 Requirement 1 for the cardholder data environment (CDE) and every system connected to it.
2. Network Trust Zones and Segmentation
The network is divided into segregated trust zones separated by network security controls so that a compromise in one zone cannot spread freely to another (ISO/IEC 27001:2022 A.8.22). At minimum the Organisation maintains a production zone (systems serving live services and sensitive data), a development / test zone (which must never hold live production data or share credentials with production), a corporate / user zone (employee endpoints and office services), a management zone (out-of-band administration of network and security devices) and a demilitarised zone (DMZ) for internet-facing services. Traffic between zones of differing trust levels is permitted only where an explicit business need exists, is mediated by an NSC, and is denied by default. The following table summarises the standard zones and the traffic permitted to cross into each.
Trust zone Contents Permitted inbound traffic DMZ (internet-facing) Reverse proxies, WAF, public web / API endpoints Only published services, protocols and ports from the internet Production Live application and data-tier systems; the CDE is isolated within a dedicated segment Only from the DMZ and management zone, on approved ports Development / test Build, staging and QA systems (no live data) From the corporate zone; never from or to production on shared credentials Corporate / user Employee endpoints, print and office services User-initiated egress via filtering; no inbound from the internet Management (out-of-band) Admin interfaces of firewalls, switches, hypervisors Only from the bastion / jump host with MFA
3. Network Security Controls, Firewalls and Default-Deny Rulesets
Network security controls (NSCs) — firewalls, virtual firewalls, router access-control lists, security groups and equivalent enforcement points — are deployed between every trusted and untrusted network and between zones of differing trust. All NSCs operate on a default-deny (deny-all) posture: only traffic that is explicitly required and authorised for a documented business purpose is permitted, and all other inbound and outbound traffic is denied. In satisfaction of PCI DSS v4.0.1 Requirements 1.2.1 and 1.4, configuration standards for NSC rulesets are defined and implemented, NSCs are installed between the CDE and all untrusted networks, inbound traffic from untrusted networks is restricted to only that which is necessary, and all other traffic is specifically denied.
4. Documented Rulesets and Six-Monthly Review
Current network diagrams and data-flow diagrams are maintained showing all connections between the Organisation's networks, and each NSC ruleset is documented with the business justification, the requesting owner and the approval for every permitted service, protocol and port. NSC configurations and rulesets are reviewed at least once every six (6) months to confirm they remain necessary, effective and correctly configured; the review, its participants, findings, remediation and any rule removals are recorded. This satisfies PCI DSS v4.0.1 Requirement 1.2.7 (review of NSC configurations at least once every six months). Networks with a high rate of change are reviewed more frequently.
5. DMZ and Internet-Facing Services
All systems that must be reachable from the internet are placed in a demilitarised zone (DMZ) that separates them from internal networks. The DMZ accepts only the specific published services, protocols and ports required, and no direct inbound connection from the internet to an internal or production system is permitted. In satisfaction of PCI DSS v4.0.1 Requirement 1.3, inbound traffic to the CDE is limited to system components that provide authorised publicly-accessible services, outbound traffic from the CDE is explicitly authorised, anti-spoofing measures reject forged source addresses, and system components that store cardholder data (such as databases) are placed in an internal network segregated from the DMZ and other untrusted networks. Reverse proxies and a web application firewall front public application traffic.
6. Security of Network Services
The security mechanisms, service levels and management requirements of all network services — whether provided internally or by a third party — are identified, documented and included in network-service agreements, in accordance with ISO/IEC 27001:2022 A.8.21. For each service the Organisation records the security features applied (such as authentication, encryption and connection controls), the rules governing its use, and the monitoring in place to confirm the agreed controls are delivered. Service providers' compliance with these requirements is monitored, and the right to audit or to receive assurance evidence is retained for critical network services.
7. Secure Remote Access and VPN
Remote access to internal networks is granted only through an encrypted IPsec or TLS VPN that enforces multi-factor authentication before any internal network access is granted. All remote sessions are encrypted using strong, current protocols (IPsec/IKEv2 or TLS 1.2 or higher), require multi-factor authentication, and grant least-privilege access limited to the resources the user needs. Split tunnelling is disabled for sessions that reach sensitive systems. Third-party and vendor access is enabled only for the duration required, is uniquely attributable to a named individual, is logged, and is disabled immediately when no longer needed. Administrative access to network and security devices is performed from the management zone via the bastion / jump host.
8. Wireless Network Security
Wireless networks are treated as untrusted at the point of connection and are segregated from production and sensitive internal segments by an NSC. Corporate wireless uses WPA2-Enterprise or WPA3 with 802.1X authentication; pre-shared keys are not used for access to sensitive networks. Guest wireless is isolated on a separate SSID and VLAN with internet-only egress and no route to internal resources. Default administrative credentials, SNMP community strings and encryption keys on wireless devices and access points are changed before deployment, vendor defaults are removed, and the environment is scanned periodically for unauthorised (rogue) access points, which are investigated and removed. Where wireless is present in or connected to the CDE, wireless access points, configurations and the presence of rogue devices are tested at least quarterly and wireless traffic to the CDE is restricted in line with PCI DSS Requirement 1.
9. Web and DNS Filtering
Access from the corporate network to external websites is managed to reduce exposure to malicious content and to enforce acceptable use, in accordance with ISO/IEC 27001:2022 A.8.23. A web / DNS filtering solution blocks known-malicious, phishing, command-and-control and high-risk categories of website, and blocks or inspects downloads of prohibited file types. Attempts to reach blocked destinations are logged. DNS resolution is directed through controlled, filtered resolvers; the use of unauthorised DNS servers, anonymising proxies and unsanctioned VPNs to bypass filtering is prohibited. Exceptions are risk-assessed and time-limited.
10. Intrusion Detection and Prevention (IDS/IPS)
Intrusion detection and prevention systems (IDS/IPS) are deployed to monitor traffic at the perimeter and at critical internal boundaries, including in front of the DMZ and the production zone. Signatures and detection logic are kept current, and the systems are configured to alert on, and where appropriate block, intrusions, anomalies and known attack patterns. In line with PCI DSS v4.0.1, intrusion-detection and/or intrusion-prevention techniques monitor traffic at the perimeter of, and at critical points within, the CDE, alerts are responded to, and detection engines and baselines are kept up to date. Alerts are triaged by the security team and are handled through the incident-response process.
11. Network Monitoring, Logging and Time
Network devices, NSCs and remote-access gateways generate security-relevant logs that are forwarded to a centralised, access-controlled logging platform, retained in line with the Organisation's retention schedule, and protected from tampering. Clocks across network infrastructure are synchronised to an authoritative time source so that events can be correlated across zones. Logs are reviewed for signs of compromise, unauthorised connections and ruleset drift, and monitoring covers both inbound and outbound traffic for anomalies and data exfiltration.
12. Network Device Hardening and Change Management
All network and security devices are deployed from an approved hardened baseline: vendor-default accounts, passwords and SNMP strings are changed or disabled, unused services and ports are turned off, management interfaces are restricted to the management zone, and administrative access uses encrypted protocols and multi-factor authentication. Firmware and security patches are applied within defined timeframes according to severity. Every addition, change or removal of a network connection or NSC rule is raised, risk-assessed, approved and recorded through the change-management process before implementation. Cloud virtual networks, security groups and network access-control lists are governed by this policy on an equivalent basis, managed as code where possible, and reviewed on the same cycle as physical NSCs.
13. Roles, Compliance, Exceptions and Review
The CISO / Head of Infrastructure owns this policy and the network architecture standards; network and infrastructure teams are responsible for implementing and maintaining conformant controls; and system owners are responsible for the rules governing traffic to their services. Compliance is verified through the six-monthly ruleset reviews, logging, vulnerability scanning and periodic penetration testing of the network perimeter. Any exception must be risk-assessed, time-bound, documented and approved in writing by the CISO / Head of Infrastructure before implementation and is tracked to remediation. This policy is reviewed at least annually, and after any significant network change or security incident. Violations may result in disciplinary action up to and including termination and, where applicable, legal action.
Approved by
Chief Information Security Officer
______________________
Title
CISO / Head of Infrastructure
______________________
Date
[Effective Date]
______________________