Introduction
Network segmentation evidence shows an auditor how your company separates systems, networks, and trust zones so that a compromise in one area is less likely to reach sensitive data or production services. This guide covers which records to keep for segmentation controls and how those records connect to SOC 2 testing.
Segmentation is a common practice for reducing blast radius. It is not a named SOC 2 product requirement on its own. Auditors usually evaluate it under related Trust Services Criteria themes such as logical access, system boundaries, and protective controls around sensitive information.
Where Network Segmentation Fits in SOC 2
SOC 2 focuses on controls that support security and, when in scope, availability, processing integrity, confidentiality, and privacy. Network segmentation often supports:
- Limiting logical access between environments and roles
- Protecting production from lower-trust networks
- Containing incident impact
- Showing clear system boundaries in your system description
Related reading: Configuration Management and Hardening Evidence for SOC 2, Logging and Monitoring Evidence for SOC 2, and Mapping Zero Trust Controls to SOC 2 Evidence.
What Auditors Usually Want to Understand
Practices vary by firm, but auditors commonly ask:
- What network zones exist, and what runs in each one?
- Which rules allow traffic between zones?
- Who can change those rules, and how are changes approved?
- How do you know the live configuration still matches the intended design?
- What evidence covers the audit period, not only a single screenshot day?
Core Evidence Categories
1. Architecture and zone inventory
Keep a current diagram or written description of network zones, for example:
- Corporate user network
- Development and staging
- Production application tier
- Data stores and backups
- Management or jump hosts
- Third-party connectivity and VPN paths
Tie the diagram to the in-scope system boundary in your system description. If the diagram is outdated, update it before fieldwork.
2. Intended segmentation policy
Record the rules your company intends to enforce, such as:
- Production is not reachable directly from employee laptops
- Staging cannot reach production data stores
- Administrative access requires a bastion or approved path
- East-west traffic between services is limited to known ports
A short policy or standard is enough when it is specific. Vague statements like "we use segmentation" are weak evidence.
3. Enforcing configuration exports
Export the live controls that enforce the design. Examples include:
- Cloud security group or firewall rule exports
- Network ACL or route table exports
- Kubernetes network policy exports
- VPN and private connectivity configurations
- WAF or API gateway rules that limit exposure
Prefer machine-generated exports with timestamps over manually rebuilt spreadsheets.
4. Change records for segmentation rules
When rules change, retain the ticket, approval, and resulting configuration change. Auditors often sample changes the same way they sample other change management events. Link each change to the person who requested it and the person who approved it.
5. Periodic review evidence
Many teams review firewall and security group rules on a schedule. Keep:
- The review date and reviewer
- The population of rules reviewed
- Decisions (keep, tighten, remove)
- Follow-up tickets for risky rules
A review with no decisions recorded is hard to defend.
6. Monitoring and exception handling
Retain alerts or tickets for unexpected open paths, policy violations, or failed connection attempts that matter to your control. When a rule was too open, keep the exception management or remediation record that closed the gap.
Example Evidence Matrix
| Control intent | Example evidence |
|---|---|
| Environments are separated | Dated architecture diagram plus cloud VPC or project layout export |
| Production data is not exposed to lower-trust zones | Security group or firewall export showing denied or absent paths |
| Admin paths are controlled | Bastion or VPN config plus access request records |
| Rule changes are approved | Ticket, approval, and before/after rule export |
| Rules are reviewed | Scheduled review record with decisions and owners |
| Drift is detected | Monitoring alert and linked remediation ticket |
These are examples. Your auditor defines what they will test based on your controls and environment.
How Auditors Commonly Test Segmentation
Auditors may:
- Inspect the system description and ask for a walkthrough of network zones
- Request configuration exports for key security groups or firewalls
- Select a sample of rule changes from the period and trace approvals
- Compare a prior export to a current export for unexpected openings
- Ask how you verify that staging cannot reach production data
- Review related vulnerability management or penetration test findings that mention network exposure
Ask your auditor what they plan to sample rather than producing every possible artifact on speculation.
Point-in-Time Screenshots vs Period Evidence
A single screenshot of a firewall rule proves little about the rest of the year. For Type 2 examinations, stronger packages usually include:
- Exports retained across the period or generated on a repeatable schedule
- Change tickets for material rule updates
- Review records with dates
- Incident or exception records when segmentation failed
If you only capture evidence during audit week, expect harder questions about the months before.
Common Gaps
- Architecture diagrams that do not match live cloud accounts
- Broad "allow all" rules with no owner or expiry
- Rule changes made in the console with no ticket
- Reviews that only say "completed" with no findings or sign-off detail
- No link between a penetration test finding and a segmentation fix
- Treating Zero Trust marketing language as a substitute for enforceable rules
A Practical Preparation Checklist
- Document zones and trust boundaries in language your engineers and auditor can share
- Export enforcing configurations with timestamps before fieldwork
- Require tickets and approvals for material segmentation changes
- Review high-risk rules on a defined cadence and record decisions
- Close open paths found by scanners or tests through tracked remediation
- Align the system description with the real network layout
- Store evidence where you can retrieve a period package quickly
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
When segmentation changes and reviews live in tickets and linked exports, that history can make period evidence easier to assemble. AuditFlo.co does not configure your network, does not validate firewall rules for you, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Final Thoughts
Good network segmentation evidence tells a clear story: which zones exist, which rules enforce the boundaries, who can change those rules, and how you know the live network still matches the design across the audit period. Keep that story in dated diagrams, exports, tickets, and reviews.
FAQ
Does SOC 2 require network segmentation?
SOC 2 does not prescribe a specific segmentation product or topology. Auditors evaluate whether your controls adequately protect the in-scope system. Segmentation is a common way to support that goal.
Is a diagram enough evidence?
Usually no. A diagram helps explain intent. Auditors typically also want enforcing configuration, change history, and period support.
Do microsegmentation and classic VLAN segmentation count the same?
Both can support the control intent if they are enforced and evidenced. What matters is whether traffic restrictions operate as described, not the marketing label.
What if we are mostly serverless?
You still have trust boundaries, identity paths, and service-to-service permissions. Evidence may focus more on cloud account boundaries, security groups, identity policies, and private networking than on traditional VLANs.
How often should we review firewall rules?
Pick a cadence that matches risk and stick to it. Many teams review high-risk rules quarterly or after major architecture changes. Record the review and the decisions.
Can penetration test results replace segmentation evidence?
No. A penetration test can validate exposure at a point in time. It does not replace ongoing configuration, change, and review evidence for the period.