Network controls

ISO/IEC 27017 Clause 13.1.1 requires you to manage and control networks that support cloud systems and applications so they protect information, including in virtual network configurations. Operationally, you must define secure network architecture, segment and restrict traffic, monitor network activity, and retain evidence that these controls are designed, implemented, and reviewed. ¹

Key takeaways:

• Treat “network controls” as an end-to-end program: architecture, segmentation, access control, monitoring, and change management.
• Cover both physical networks and cloud-native virtual networks (VPC/VNet, security groups, route tables, gateways).
• Evidence matters: network diagrams, configuration baselines, firewall rulesets, monitoring logs, and change/approval records.

“Network controls requirement” in ISO/IEC 27017 Clause 13.1.1 is a straightforward expectation with a broad operational footprint: you must run your networks in a controlled way that reduces unauthorized access, limits lateral movement, and detects suspicious activity across cloud systems and applications, including virtual networks. ¹

For a CCO, GRC lead, or compliance owner, the fastest path to operationalizing this requirement is to translate it into a small set of auditable outcomes: (1) you know what networks exist and what they connect to, (2) you can prove segmentation and traffic restrictions are intentional and reviewed, (3) you monitor for security-relevant events, and (4) changes to network configurations follow a controlled process with approvals and rollback capability. This page gives you requirement-level implementation guidance you can hand to engineering and security teams, plus the exact artifacts and audit questions you should expect.

Regulatory text

Requirement (Clause 13.1.1): “Networks shall be managed and controlled to protect information in cloud systems and applications, including virtual network configurations.” ¹

What the operator must do

You must implement governance and technical controls so that networks supporting cloud workloads are:

• Designed intentionally (documented architecture and trust boundaries)
• Restricted by default (segmentation and traffic filtering)
• Observed continuously (monitoring/logging for network events)
• Changed safely (controlled changes for virtual networking and network security devices)

The explicit callout to “virtual network configurations” means auditors will look beyond on-prem firewalls and switches. They will examine cloud constructs such as VPC/VNet topology, subnets, route tables, security groups/NSGs, peering, private endpoints, load balancers, gateways, and managed firewall policies. ¹

Plain-English interpretation

Network controls means you can answer, with evidence:

1. Where can traffic flow? (Ingress, egress, east-west)
2. Who can change it? (Permissions and approvals)
3. How do you know it’s working? (Monitoring, alerts, reviews)
4. What happens when something changes or breaks? (Change control, rollback, incident response hooks)

A practical way to frame the requirement for implementation is: reduce the blast radius, minimize exposed services, and detect abnormal network behavior quickly for both physical and cloud-virtual networks. ¹

Who it applies to (entity and operational context)

ISO/IEC 27017 Clause 13.1.1 applies to:

• Cloud Service Providers (CSP role): If you operate cloud services for customers, you must manage the underlying network and the virtual networking features you expose. ¹
• Cloud Service Customers: If you deploy workloads into a public cloud or hosted environment, you are responsible for configuring your virtual networks, security groups, routing, and monitoring for your tenant. ¹

Operational contexts where this requirement is commonly tested:

• Internet-facing applications and APIs
• Private connectivity to third parties (partners, processors, MSSPs) and customer environments
• Admin planes (bastions, VPNs, zero trust access brokers)
• Multi-account/subscription environments with shared networking
• Hybrid networks (on-prem to cloud via VPN/Direct Connect/ExpressRoute equivalents)

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

1) Define your network security standard (one page, enforceable)

Write a short standard that states:

• Approved network zones (public, private app, data, admin, management)
• Default-deny expectations for inbound and internal traffic
• Allowed egress patterns and where outbound filtering applies
• Required network logging sources and retention ownership
• Change control requirements for network policy and routing changes Tie the standard directly to Clause 13.1.1 language so it is clearly in scope. ¹

2) Inventory networks and create “current-state” diagrams

Build and maintain:

• A list of network instances (VPC/VNet, projects, accounts/subscriptions)
• A map of subnets, route tables, gateways, peering, private endpoints
• Identification of internet ingress points (CDN/WAF/LB/public IP ranges)
• Identification of administrative access paths A common audit failure is having diagrams that exist but are stale. Add an owner and a refresh trigger (for example, refresh on material changes).

3) Implement segmentation and traffic restrictions

Minimum expectations auditors typically infer from the clause’s “managed and controlled” language:

• Separate trust zones: isolate production from non-production; isolate admin from application traffic.
• Restrict east-west movement: security groups/NSGs or microsegmentation so only required ports between tiers are allowed.
• Harden ingress: only required ports exposed; prefer WAF/reverse proxy patterns for web apps where applicable.
• Control egress: define outbound rules; block obviously unnecessary destinations; route through inspection points where required. Document the rationale for exceptions (legacy services, third-party constraints) and how you compensate (extra monitoring, tighter IAM, shorter exposure windows). ¹

4) Lock down who can change network configurations

Implement access control for network changes:

• Limit creation/changes to security groups/NSGs, route tables, peering, and gateways to a small role set.
• Require strong authentication for privileged actions.
• Separate duties where feasible (request vs. approve vs. implement). In cloud environments, this is mostly IAM. Your evidence must show the policy and the effective permissions. ¹

5) Turn on network monitoring and make it actionable

Enable and centralize:

• Flow logs (network flows between endpoints)
• Firewall/WAF logs (allowed/blocked requests and rule matches)
• Load balancer access logs (where relevant)
• DNS logs (where feasible) to detect anomalous lookups Then define:
• Alert thresholds/use cases (unexpected inbound exposure, new public IPs, high-risk ports opened, unusual egress destinations, spikes in denied traffic)
• Ownership (who triages, who remediates)
• Escalation paths to incident response The clause does not prescribe tooling, but it does require “managed and controlled.” Monitoring is the easiest way to demonstrate control over time. ¹

6) Put network changes under change management with traceability

Network changes cause outages and exposures. Require:

• Ticketed requests (why, scope, risk, rollback plan)
• Peer review for ruleset changes and routing
• Emergency change procedure with after-action review
• Configuration-as-code where possible (security groups, firewall policies, routes) so you have version history and approvals A practical audit-ready approach is “no direct production changes without an artifact.” Your artifact can be a change ticket tied to a pull request.

7) Validate regularly: reviews, testing, and drift detection

Run periodic checks that prove ongoing control:

• Ruleset review (inbound/outbound and east-west)
• Public exposure review (internet-facing endpoints and ports)
• Drift checks against approved baselines
• Vulnerability and configuration findings triage tied back to network owners If you need one high-signal metric for executives: “open ports and paths that violate standard,” tracked to closure.

8) Extend the control to third parties and shared responsibility

Where third parties provide connectivity or managed network services:

• Require documentation of network boundaries and responsibilities in contracts/SOWs.
• Request evidence of their network control practices if they manage infrastructure that touches your data. For cloud providers, document the shared responsibility model and show which network controls are customer-configured vs provider-managed. ¹

Practical note: If you manage many third parties with connectivity paths, Daydream can help you standardize due diligence requests and map evidence (diagrams, change records, logging attestations) to this requirement so renewals do not restart from scratch.

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and operation:

Governance

• Network security standard (approved, versioned)
• Shared responsibility statement for cloud networking (who owns what)

Architecture

• Network diagrams (current-state + target-state if in progress)
• Data flow diagrams for sensitive systems (show ingress/egress points)

Configuration and access

• Firewall policies and rulesets (export/snapshots)
• Cloud security group/NSG baselines and exception register
• IAM role list for network admins and evidence of access reviews

Monitoring and operations

• Evidence that flow logs/WAF/firewall logs are enabled (settings screenshots/exports)
• Sample log events in central logging system
• Alert runbooks and incident escalation procedures

Change management

• Change tickets for network changes (normal and emergency)
• Code review records (pull requests) for network-as-code
• Post-change validation notes (tests, scans, rollback results)

Common exam/audit questions and hangups

Expect auditors to ask:

• “Show me your network segmentation for production. Where are the trust boundaries?”
• “How do you prevent a developer from opening broad inbound access?”
• “How do you detect when a new internet-exposed endpoint appears?”
• “Show logs for firewall/WAF/flow logs and the process for reviewing alerts.”
• “How are route table and peering changes approved and documented?” Hangups that slow audits:
• Diagrams exist but do not match deployed reality.
• Security group sprawl with no ownership.
• Monitoring enabled but no triage process or evidence of response.

Frequent implementation mistakes and how to avoid them

• Mistake: “Flat” networks with permissive east-west rules. Fix by defining zones and explicitly allowing only required service-to-service ports.
• Mistake: Relying on one perimeter control. Fix by layering: security groups/NSGs + managed firewall/WAF where applicable + logging.
• Mistake: No egress story. Fix by documenting allowed outbound patterns and enforcing them for high-risk environments first.
• Mistake: Network changes outside change control. Fix by restricting write permissions and requiring tickets/PRs for production changes.
• Mistake: Logging without ownership. Fix by naming an on-call/queue and keeping samples of investigated alerts as evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this requirement, so this page does not cite enforcement outcomes. Practically, weak network controls increase the likelihood and impact of unauthorized access, data exposure through misconfiguration, and uncontrolled pathways to sensitive systems. The operational risk also includes outages caused by unreviewed routing and firewall changes. ¹

Practical execution plan (30/60/90)

Below is an execution plan you can run as a compliance-led program with engineering owners. Timeboxes are guidance, not guarantees.

First 30 days (stabilize and get audit-ready basics)

• Publish a network security standard mapped to Clause 13.1.1. ¹
• Create a complete inventory of cloud virtual networks and connectivity (peering, gateways, private links).
• Produce current-state diagrams for the top critical environments (production first).
• Confirm network logging sources are enabled for production (flow logs and perimeter/WAF where applicable).
• Establish a change control path for network changes (ticket + approval), even if temporary.

Next 60 days (reduce exposure and prove operational control)

• Implement segmentation standards in production (separate admin paths; restrict east-west).
• Tighten IAM for network configuration changes and document privileged roles.
• Define alert use cases and runbooks; collect evidence of triage (tickets, notes).
• Stand up drift detection or baseline checks for security groups and routes.
• Build an exception register for any broad rules, with expiry dates and compensating controls.

By 90 days (make it repeatable and scalable)

• Move key network controls to infrastructure-as-code with review gates.
• Formalize periodic reviews: ruleset review, exposure review, and access review with sign-offs.
• Extend to non-production and shared services; align patterns across accounts/subscriptions.
• Integrate third-party connectivity into your control: diagrams, approvals, and monitoring visibility.
• Centralize evidence collection so audits do not require manual exports each cycle; Daydream can be your system of record for artifacts and review workflows.

Frequently Asked Questions

Does ISO 27017 network controls require network segmentation?

The clause requires networks be “managed and controlled” to protect information, including virtual network configurations. In practice, segmentation is a common way to demonstrate controlled traffic flows and reduced blast radius for cloud systems. ¹

Are security groups and route tables in scope?

Yes. The text explicitly includes “virtual network configurations,” which covers cloud-native controls such as security groups/NSGs, routing, peering, gateways, and similar constructs. ¹

What evidence is strongest for auditors?

Versioned network standards, accurate diagrams, exported rulesets/baselines, proof of logging enabled, and change records tied to approvals are high-signal artifacts. Auditors also like to see examples of alerts investigated and remediated.

We have monitoring turned on but no one reviews alerts. Is that a problem?

Yes. “Managed and controlled” implies operational ownership. Assign a queue/owner, document triage steps, and retain a small set of completed investigations as evidence of ongoing control. ¹

How do we handle third-party connections (partners, processors, MSPs)?

Treat each third-party connection as a controlled pathway: document the network boundary, restrict traffic to required ports/destinations, monitor the link, and require change approvals. Keep contracts/SOWs and diagrams that clarify who manages which part of the network.

We’re multi-cloud. Do we need separate standards per cloud?

Keep one control standard with consistent intent (segmentation, access control, monitoring, change control), then maintain cloud-specific implementation baselines (for example, AWS security group patterns vs Azure NSGs) as appendices.

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services