Segregation in networks

ISO/IEC 27017 Clause 13.1.3 requires you to segregate groups of information services, users, and information systems on your networks, including virtual segmentation in cloud environments. Operationally, you must define segmentation boundaries, implement technical controls (VPC/VNet separation, subnets, VLANs, security groups), and prove enforcement with architecture evidence, rule reviews, and access pathways that match your risk model. ¹

Key takeaways:

• You need documented segmentation intent (what is separated and why) plus enforced network controls that match it.
• “Cloud segregation” means virtual boundaries with explicit allow-lists, not informal conventions or naming.
• Audits fail on drift: rules change faster than diagrams, so you need review, monitoring, and evidence.

“Segregation in networks” is a requirement about limiting blast radius. If different services, user groups, or system tiers can freely communicate, a single compromised workload or credential can become an environment-wide incident. ISO/IEC 27017 Clause 13.1.3 is explicit that segregation must exist on networks and that cloud environments are in scope through virtual network segregation. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize this requirement is to treat it as a traceable chain: (1) define segregation groups and permitted flows, (2) implement cloud and on-prem controls that enforce those flows, (3) continuously validate that reality matches design, and (4) retain evidence that an auditor can follow without tribal knowledge.

This page focuses on requirement-level execution: who must comply, what “good” looks like in common architectures, how to implement step-by-step, what artifacts to retain, and where audits get stuck. It also includes a practical execution plan and operator-grade FAQs.

Regulatory text

ISO/IEC 27017:2015 Clause 13.1.3: “Groups of information services, users and information systems shall be segregated on networks, including virtual network segregation in cloud environments.” ¹

What the operator must do

• Identify “groups” that require separation (examples: production vs. non-production, regulated data environments, admin users vs. standard users, shared services vs. customer workloads).
• Implement network controls that enforce separation in your actual environment, including virtual segmentation in cloud (examples: separate VPCs/VNets, subnets, VLANs, security groups/NSGs, routing controls).
• Restrict communication to explicit, approved pathways (allow-lists) between segregated groups, and make exceptions visible and governed.
• Maintain evidence that segregation exists, is enforced, and is reviewed over time.

Plain-English interpretation (what this requirement means)

You must prevent “everything can talk to everything” networking. Services, systems, and user communities that should not freely interact must be placed into separate network zones, and the only traffic allowed across zones must be intentional, documented, and controlled. In cloud environments, segregation must be implemented with cloud-native virtual network boundaries and policy constructs, not just diagrams or account naming conventions. ¹

A practical way to interpret “segregated”:

• Default deny across zones (or “deny by absence” through narrowly scoped allow rules).
• Separate control planes where appropriate (for example, admin access paths separated from application data paths).
• Prove the path: for any sensitive system, you can show exactly how traffic enters, where it can go next, and what stops lateral movement.

Who it applies to (entity and operational context)

ISO/IEC 27017 applies to both:

• Cloud Service Providers (CSP-like operators) delivering cloud services to customers.
• Cloud Service Customers building and operating workloads in cloud environments. ¹

Operationally, this requirement is relevant anywhere you have:

• Multi-environment estates (dev/test/stage/prod) with shared networks.
• Mixed criticality systems (public web tier next to sensitive databases).
• Multi-tenant or customer-separated workloads, even if tenancy is “soft” (separate schemas, separate namespaces).
• Administrative access (jump hosts, bastions, management APIs) that could become a universal lateral movement path.
• Third party connectivity (partners, MSPs, contractors, managed databases, SaaS-to-cloud integration) that introduces external ingress into internal networks.

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

Step 1: Define segregation groups and the reason for each boundary

Create a short, auditable list of network segregation groups. Keep it simple, then get stricter over time. Typical first-pass groups:

• Production workloads
• Non-production workloads
• Shared services (logging, monitoring, CI/CD runners)
• Management plane (bastion/jump hosts, admin tooling)
• Restricted data zone (systems handling sensitive data)

For each group, document:

• Assets included (accounts/subscriptions/projects, VPC/VNet IDs, subnets, key service names).
• Threat/risk rationale (why separation is required).
• Allowed inbound/outbound flows (source group → destination group → ports/protocols → purpose).

Deliverable: a “Segmentation Policy & Zone Model” plus a “Network Flow Matrix.”

Step 2: Translate the zone model into enforceable network controls

Implement controls in the same layer where traffic is controlled in your architecture:

Cloud (examples of control types, not a mandatory design):

• Separate VPC/VNet per environment or per trust zone.
• Separate subnets for tiers (web/app/data) with distinct route tables.
• Security groups / NSGs with tight inbound rules and constrained egress where feasible.
• Controlled peering/transit with explicit routing and filtering to prevent accidental full mesh connectivity.

On-prem / hybrid:

• VLAN separation aligned to trust zones.
• Firewall rulesets aligned to the flow matrix.
• Segmented remote access paths (admin VPN separated from user VPN, with stronger controls).

Goal state: if someone deploys a new workload into a zone, the default network posture is already correct. You should not rely on engineers “remembering” which ports to close.

Step 3: Build controlled cross-zone pathways (and treat them as exceptions)

Some connectivity is required (for example, app tier to database tier). Make those crossings:

• Explicit: rule names and ticket references that tie to approved flows.
• Minimal: smallest set of sources, destinations, ports, and protocols.
• Inspectable: log or otherwise provide traceability for cross-zone connections where practical.

Common exam focus: auditors ask, “How do you prevent dev from reaching prod?” Your answer must be architectural and enforced, not policy-only.

Step 4: Govern change and prevent segmentation drift

Segmentation fails quietly as environments grow. Put a lightweight governance loop in place:

• Pre-deployment checks: confirm new systems land in the right zone, with the right rules.
• Rule reviews: periodic review of security group/NSG/firewall changes for over-broad rules (for example, “any/any”).
• Architecture-as-evidence: update diagrams and inventories as part of change management.

If you can’t keep diagrams current manually, use a GRC workflow to require updated artifacts before closing network change requests. Daydream can help by standardizing control narratives, mapping evidence to ISO/IEC 27017 Clause 13.1.3, and keeping reviews and exceptions tied to a single control record that auditors can follow.

Step 5: Validate segregation with tests that produce auditor-friendly output

Do not rely only on “configuration exists.” Produce evidence that traffic is actually restricted:

• Attempted connections between zones should fail unless explicitly allowed.
• Validate routes do not create unintended transitive access (A peers to B, B peers to C, and now A reaches C).
• Confirm admin paths require the intended gateways and controls.

Output: test plans, results, and remediation tickets for failures.

Required evidence and artifacts to retain

Keep artifacts that let an auditor trace from requirement → design → implementation → operation:

1. Segmentation policy / zone model (approved document).
2. Network flow matrix with approved cross-zone traffic.
3. Network architecture diagrams showing zones, gateways, and interconnects.
4. Inventory mapping of systems/services to zones (include cloud IDs and tags where available).
5. Firewall/NSG/security group standards (how rules are written, naming, approvals).
6. Change records for rule changes (requests, approvals, implementation notes).
7. Periodic review records (what was reviewed, findings, remediation).
8. Validation evidence (test results, blocked traffic examples, scan outputs where applicable).
9. Exception register for any temporary cross-zone access, with expiration and compensating controls.

Common exam/audit questions and hangups

Auditors tend to probe the same gaps:

• “Show me how production is separated from non-production.” Expect to provide both architecture and enforcement (rules/routes).
• “Where is sensitive data processed, and what network zone is it in?” They want mapping, not a narrative.
• “How do you control administrative access?” Separate admin pathways are a frequent sticking point.
• “Prove that only approved ports are open between tiers.” Your flow matrix should match actual rules.
• “How do you detect and correct overly permissive rules?” Drift control and reviews matter.

Hangup patterns:

• Diagrams describe segmentation that rules do not enforce.
• Security groups allow broad ingress/egress “temporarily” with no expiration.
• Shared services become a backdoor between zones.

Frequent implementation mistakes and how to avoid them

1. Relying on naming conventions instead of isolation. A “prod-” prefix does not segregate traffic. Put prod in separate network boundaries and enforce rules.
2. Flat east-west connectivity. Internal traffic often gets a free pass. Treat lateral movement as a design constraint and require explicit app-to-app flows.
3. Transitive trust through peering/hubs. Central networks simplify routing but can erase isolation. Document intended transitive paths and block the rest.
4. No ownership for rule hygiene. Assign an accountable owner for each zone’s boundary controls, with a review cadence.
5. Exceptions without an end date. Require expirations and validate removal.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so this page does not cite specific actions. The operational risk is clear: weak segmentation increases the likelihood that a compromise spreads laterally, expands data exposure, and turns a single-system incident into a multi-system outage. Your control objective is containment: reduce reachable assets from any one foothold, including compromised third party access paths.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Confirm in-scope environments (cloud accounts/subscriptions/projects; on-prem segments).
• Draft the zone model and flow matrix for the highest-risk systems first (production, sensitive data, admin access).
• Identify “critical violations” to fix immediately (examples: public ingress to sensitive zones; broad internal allow rules without justification).
• Stand up an exceptions workflow with required fields: business justification, scope, owner, expiration, compensating controls.

Next 60 days (implement and align evidence)

• Implement or tighten segmentation for the defined zones (VPC/VNet boundaries, subnets, security groups/NSGs, routing).
• Establish standard rule patterns and naming conventions tied to the flow matrix.
• Produce and approve architecture diagrams and system-to-zone mappings.
• Run connectivity validation between zones and track remediations.

By 90 days (operationalize and make it auditable)

• Put segmentation reviews into change management (rule changes require flow-matrix alignment).
• Implement recurring rule hygiene reviews and exception expiration checks.
• Create an “audit pack” for ISO/IEC 27017 Clause 13.1.3 with: policy, diagrams, flow matrix, sample rule exports, review records, test results.
• Centralize evidence and approvals so you can answer audits quickly; Daydream is a practical place to manage the control record, exceptions, and linked artifacts without hunting across tools.

Frequently Asked Questions

Does ISO/IEC 27017 require separate VPCs/VNets for every environment?

The text requires segregation and includes virtual segregation in cloud environments, but it does not prescribe a single architecture. You can meet the requirement with separate VPCs/VNets or strong subnet and security-group boundaries, as long as separation is real and provable. ¹

What’s the minimum evidence auditors expect for “segregation in networks”?

Provide a zone model, a flow matrix, and proof that your rules and routes enforce that model. Auditors also expect evidence of review and change control because segmentation degrades over time.

How do we handle third party access (MSPs, contractors, partners) under this requirement?

Treat third party connectivity as its own zone or controlled ingress path, then restrict what it can reach with explicit allow rules. Document the approved flows and retain approvals and expiration dates for any broad access.

Is Kubernetes namespace separation enough to satisfy network segregation?

Namespace separation helps with administrative organization, but it is not network segregation by itself. You still need enforced network boundaries (for example, network policies and controlled ingress/egress paths) that align to your zone model.

Our security groups allow broad egress. Is that automatically non-compliant?

The clause requires segregation of groups on networks; broad egress can undermine that objective if it enables unintended cross-zone communication. If you allow broad egress, document why, limit destinations where feasible, and show compensating monitoring and periodic review.

Who should own this control: Security, Network Engineering, or Cloud Platform?

Assign a single accountable owner for the zone model and boundary standards, then split implementation tasks across the teams that manage the underlying infrastructure. Audits go better when ownership of rule hygiene and exception management is explicit.

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