SOC 2 Network Diagram Requirements: What Auditors Actually Look For

If you are preparing for a SOC 2 audit, you have probably seen network diagrams mentioned in multiple places across the Trust Service Criteria. That is because network architecture documentation is not a nice-to-have — it is a core piece of evidence that auditors use to evaluate whether your organization has implemented logical access controls, defined system boundaries, and established monitoring over your production environment. A missing or outdated network diagram is one of the fastest ways to trigger follow-up questions, extended evidence requests, or outright exceptions in your audit report.

The challenge is that SOC 2 does not hand you a checklist of exactly what a network diagram must contain. The Trust Service Criteria are principles-based, which means your auditor has discretion in what they consider sufficient. That said, after enough audits, clear patterns emerge. This guide covers what auditors actually evaluate, the specific elements your diagrams need, the mistakes that cause failures, and how to keep your documentation current without burning engineering hours.

SOC 2 Trust Service Criteria That Require Network Diagrams

Three Trust Service Criteria directly relate to network diagram documentation. Each one addresses a different dimension of your infrastructure security, and your diagram needs to provide evidence for all of them.

CC6.1 — Logical Access Security

CC6.1 requires that your organization implements logical access security over information assets. In practice, this means demonstrating that you control who and what can communicate with your production systems. Your network diagram serves as the visual evidence that these controls exist.

Auditors reviewing CC6.1 want to see that your network is segmented into logical zones with explicit access rules between them. For AWS environments, this translates directly to VPC architecture, subnet design, security group rules, and network ACLs. The diagram should make it immediately clear which resources are internet-facing, which sit in private subnets, and what the allowed communication paths are between tiers.

CC6.6 — System Boundaries

CC6.6 addresses the boundaries of your system — specifically, how you restrict access at the perimeter and manage connections between trusted and untrusted networks. Your network diagram is the primary artifact that demonstrates where those boundaries are drawn.

For this criterion, auditors look at how traffic enters your environment (internet gateways, load balancers, API gateways), how it moves between components, and where it exits (NAT gateways, VPC endpoints, peering connections). They want to verify that ingress points are intentional and controlled, not accidental. A diagram that shows an EC2 instance in a public subnet with a wide-open security group is going to generate immediate questions.

CC7.1 — Monitoring and Detection

CC7.1 covers your ability to detect anomalies, vulnerabilities, and security events. While monitoring itself is demonstrated through tool configurations and alert policies, the network diagram provides context for where monitoring is applied. Auditors use it to verify that monitoring covers all critical network segments and data flow paths.

If your diagram shows three distinct VPCs but your monitoring evidence only covers one, that is a gap the auditor will flag. The diagram effectively becomes the map against which they validate your monitoring coverage.

Required Elements in a SOC 2 Network Diagram

While the exact requirements vary by auditor, the following elements are consistently expected when your infrastructure runs on AWS. Missing any of these will likely result in follow-up requests or findings.

VPCs and Region Boundaries

Every VPC in your environment should be represented with its CIDR range and the AWS region it resides in. If you operate across multiple regions, the diagram needs to show each region distinctly and illustrate any cross-region connectivity such as VPC peering or Transit Gateway attachments. Auditors need to understand the full scope of your network footprint.

Subnets: Public and Private

Subnets should be clearly labeled as public or private, with their CIDR ranges and availability zones indicated. The distinction between public and private subnets is fundamental to demonstrating network segmentation. Auditors specifically check whether databases and application servers are isolated in private subnets, with only load balancers and bastion hosts (if any) in public subnets.

Security Groups and Network ACLs

Security groups are where most of the access control story lives. Your diagram should show which security groups are attached to which resources, and the key rules that define allowed traffic. You do not need to list every single rule on the diagram — that would make it unreadable — but the diagram should convey the logical groupings and the direction of allowed traffic between them.

Network ACLs add a second layer of control at the subnet level. If you use custom NACLs (beyond the default allow-all), those should appear on the diagram as they represent an explicit security boundary.

Internet Gateways and NAT Gateways

Internet gateways represent the entry point for inbound traffic from the public internet. NAT gateways allow private subnet resources to make outbound connections without being directly reachable. Both should be clearly positioned on the diagram with arrows showing traffic direction. Auditors use these to verify that only intentional paths exist between your internal resources and the internet.

Load Balancers

Application Load Balancers and Network Load Balancers serve as critical control points in your architecture. The diagram should show which load balancers exist, whether they are internet-facing or internal, which subnets they span, and which target groups they route to. Load balancers are often where TLS termination occurs, which is relevant to data-in-transit encryption evidence.

DNS and Domain Configuration

Route 53 hosted zones, domain names, and DNS routing policies should be represented, particularly if you use DNS-based routing for failover or geographic distribution. This helps auditors understand how traffic reaches your environment in the first place and validates that your publicly documented endpoints match your actual architecture.

Data Flow Arrows

Static topology is not enough. Auditors want to see how data actually moves through your system. Arrows should indicate the direction of traffic flow between components: client to load balancer, load balancer to application tier, application tier to database, application to external APIs. Each arrow implicitly represents a security group rule or network path that can be validated.

Common Audit Failures Related to Network Diagrams

Having a network diagram is necessary but not sufficient. These are the issues that most frequently lead to audit findings or extended evidence requests.

Missing Network Segmentation

The most common failure is a diagram that shows a flat network — all resources in a single subnet or VPC with no logical separation between tiers. Even if your security groups enforce segmentation at the instance level, auditors expect to see subnet-level separation between public-facing components, application servers, and data stores. If your actual architecture is flat, the diagram is accurately reflecting a real security gap that needs to be addressed before the audit, not papered over.

Outdated Diagrams

A diagram created six months ago that does not reflect recent infrastructure changes is a red flag. Auditors will cross-reference your diagram against other evidence — CloudTrail logs, security group configurations, VPC flow logs — and discrepancies undermine confidence in your documentation practices. If the diagram shows three subnets but your AWS console shows five, you will spend time explaining the gap instead of moving through the audit.

No Security Group Detail

A diagram that shows boxes and lines but gives no indication of what traffic is allowed between components fails to address CC6.1. Auditors need to see that access is restricted by default and opened only where necessary. The diagram should convey that your security groups follow a least-privilege model, even if the full rule sets are provided as supplementary evidence.

Missing Data Flow Representation

A topology diagram without data flow arrows is incomplete. Auditors evaluate not just what exists in your network but how information moves through it. Without directional arrows showing traffic patterns, the diagram does not demonstrate that you understand and control data movement within your environment. This is particularly important for CC6.6, where the boundary between trusted and untrusted zones must be clearly delineated.

Orphaned or Unaccounted Resources

If your AWS account contains resources — EC2 instances, RDS databases, Lambda functions — that do not appear on the diagram, auditors may question whether you have full visibility into your environment. Shadow infrastructure that exists outside your documented architecture is a control weakness, and the network diagram is where it becomes visible.

How to Build a Complete Network Diagram

There are several approaches to creating network diagrams for SOC 2, each with different trade-offs around accuracy, maintenance burden, and level of detail.

Manual Diagramming

The traditional approach is to manually create diagrams using tools like Lucidchart, draw.io, or Visio. An engineer opens the AWS console, reviews each VPC, subnet, security group, and resource, then translates that into a visual diagram. This works for small environments but has significant drawbacks.

Manual diagrams are labor-intensive to create — a moderately complex AWS environment with multiple VPCs, dozens of subnets, and hundreds of security group rules can take days to diagram accurately. More importantly, they become stale the moment infrastructure changes. Every Terraform apply, CloudFormation update, or console change potentially invalidates the diagram, and there is no mechanism to detect the drift.

Infrastructure-as-Code Exports

Some teams attempt to generate diagrams from their Terraform state or CloudFormation templates. This is closer to the source of truth but still has gaps. IaC tools describe intended state, not necessarily actual state. Resources created outside of IaC — manually provisioned instances, ad-hoc security group changes — will not appear. Additionally, IaC definitions do not always map cleanly to the visual representation auditors expect.

Level of Detail

A common question is how much detail the diagram needs. The answer depends on your environment complexity, but a good rule of thumb is: the diagram should be detailed enough that someone unfamiliar with your infrastructure could identify every network boundary, access control point, and data flow path without needing to reference additional documentation. If an auditor has to ask “what sits between the internet and this database?” the diagram is not detailed enough.

For larger environments, it is acceptable to create multiple diagrams at different levels of abstraction — a high-level overview showing VPCs and major components, then detailed diagrams for each VPC showing subnets, security groups, and individual resources. The key is that every level should be accurate and consistent.

Automating Network Diagrams with Fegura

The fundamental problem with manual or semi-automated approaches is the gap between your actual AWS environment and your documented architecture. Every time someone modifies a security group, spins up a new subnet, or changes a routing table, your diagram drifts further from reality. For SOC 2, this drift is not just inconvenient — it is a control weakness.

Fegura eliminates this gap by reading directly from your live AWS environment. When you connect your AWS account, Fegura discovers your VPCs, subnets, security groups, NAT gateways, internet gateways, load balancers, and routing configurations automatically. It maps the relationships between these resources — which security groups are attached to which resources, which subnets route through which gateways, which load balancers distribute traffic to which targets — and generates a network diagram that reflects your actual infrastructure state.

Because the diagram is generated from live AWS APIs rather than manual observation, it captures everything in your account, including resources that might have been missed in a manual audit. Security group rules are mapped to show allowed traffic between components, subnets are labeled with their public or private designation based on actual route table configurations, and data flow paths are derived from real network connectivity rather than assumptions.

The diagrams stay current because they can be regenerated at any time. Before an audit, during an audit, or as part of a regular review cycle — the diagram always reflects what is actually deployed. This addresses one of the most common audit findings (outdated documentation) structurally rather than through process discipline alone.

For teams operating across multiple AWS accounts or regions, Fegura maps each environment independently and shows cross-account or cross-region connectivity where it exists. This is particularly valuable for organizations with separate staging and production accounts, where auditors need to verify that the production environment matches the documented architecture.

SOC 2 network diagrams are not just a compliance checkbox. They are a reflection of how well you understand and control your own infrastructure. Auditors use them to assess whether your security controls are real or theoretical, whether your monitoring covers your actual attack surface, and whether your team maintains accurate operational documentation. Getting the diagram right — and keeping it right — is one of the highest-leverage activities you can invest in during audit preparation. The question is whether you want to rebuild that understanding manually every quarter, or let your infrastructure document itself.