System Boundary Diagram for SOC 2: A Complete Guide
If you're preparing for a SOC 2 audit, there's one artifact that will come up before anything else: the system boundary diagram. It is the foundational document that auditors use to understand what they're evaluating. Without a clear, accurate system boundary diagram, the entire audit process stalls. Auditors cannot assess your controls if they don't know what's in scope, and your team cannot implement meaningful controls without a shared understanding of where your system begins and ends. This guide walks through what system boundary diagrams are, what they need to contain, and how to produce them without losing weeks of engineering time.
What Is a System Boundary Diagram?
A system boundary diagram is a visual representation of the components, services, and data flows that make up your in-scope system for a SOC 2 examination. It draws a clear line between what is part of your service—and therefore subject to audit—and what falls outside the boundary.
At its core, the diagram answers three questions: What infrastructure and services does the organization operate? Where does data enter and leave the system? Which third-party services interact with the system and in what capacity?
A system boundary diagram is not an exhaustive architecture diagram. It does not need to show every internal function call or microservice endpoint. Instead, it focuses on the trust boundaries—the points where data, access, or control passes from one domain to another. Think of it as a map drawn at the altitude where you can see the borders between countries, not the streets within cities.
In the SOC 2 framework, the system boundary diagram is part of the system description required under the AICPA's Trust Services Criteria. It typically appears in Section III of a SOC 2 Type II report and is referenced throughout the auditor's testing of controls.
Why Auditors Ask for System Boundary Diagrams First
Auditors begin with the system boundary diagram because everything else depends on it. Before they can evaluate whether your access controls are sufficient, they need to know which systems require access controls. Before they can assess your encryption practices, they need to know where data flows and where it crosses trust boundaries.
The system boundary diagram serves three critical functions in the audit process:
- Scoping the engagement. The boundary diagram defines what is in scope for the audit. Services inside the boundary will be examined. Services outside are excluded. If the boundary is wrong, the entire audit is either too broad (wasting time and money) or too narrow (leaving gaps that could result in qualifications or exceptions).
- Identifying trust boundaries. Auditors need to understand where your system interfaces with external parties, whether that's end users, third-party APIs, cloud providers, or partner systems. Every trust boundary is a potential risk point, and controls must exist at each one.
- Mapping controls to components. Each control in your SOC 2 control matrix should trace back to one or more components in the boundary diagram. If a component appears in the diagram but has no corresponding controls, that's a gap. If a control references a component not in the diagram, that's a scope issue.
In practice, auditors use the boundary diagram as their navigation tool for the entire engagement. They will refer back to it repeatedly as they walk through your controls, request evidence, and assess risks.
Key Elements of a System Boundary Diagram
A well-constructed system boundary diagram includes several categories of information. Missing any of these typically results in follow-up questions from auditors and delays in the engagement.
In-Scope Services and Infrastructure
List every service, database, compute resource, and storage system that processes, stores, or transmits customer data. For AWS environments, this typically includes EC2 instances, ECS or EKS clusters, Lambda functions, RDS databases, DynamoDB tables, S3 buckets, and any other resource that handles data within the scope of your service. Group these logically by function—for example, application tier, data tier, and networking—rather than listing them alphabetically.
Network Boundaries and Segmentation
Show your VPCs, subnets, security groups, and any network-level segmentation. Auditors want to see that production environments are isolated from development and staging environments. If you use multiple AWS accounts as an isolation boundary, the diagram should reflect that account structure clearly.
Data Flows Crossing Boundaries
Every arrow in the diagram should represent a data flow, and each data flow that crosses the system boundary deserves particular attention. Label these flows with the type of data being transmitted and the protocol or mechanism used. For example: "Customer PII via HTTPS from web client to API Gateway" or "Encrypted backups to S3 cross-region replication." Auditors will ask about encryption in transit and at rest for every one of these flows.
Third-Party Integrations
Any external service your system depends on must appear on the diagram. This includes identity providers, payment processors, email delivery services, monitoring platforms, CI/CD pipelines, and logging services. For each third party, indicate what data flows to or from them and whether they are considered subservice organizations under the AICPA framework. Subservice organizations may need their own SOC 2 reports, or you will need to implement complementary user entity controls.
User Access Points
Show how different categories of users interact with the system. End users accessing a web application through a browser are one access point. Administrators using SSH or a management console are another. API consumers connecting via programmatic credentials are a third. Each access point implies a set of authentication and authorization controls that auditors will want to verify.
Defining Your SOC 2 Scope
Getting the scope right is one of the most consequential decisions in your SOC 2 process. The system boundary diagram is the visual expression of that scope, and mistakes here cascade through the entire audit.
Start with the Data
The most reliable way to define scope is to follow the data. Identify every type of customer data your service handles, then trace the path that data takes through your infrastructure—from ingestion to processing to storage to deletion. Every resource that touches customer data is in scope. This approach avoids both over-scoping (including internal tools that never see customer data) and under-scoping (missing a database that stores customer records).
Common Scoping Mistakes
The two most frequent mistakes organizations make when defining their SOC 2 scope are drawing the boundary too broadly and drawing it too narrowly.
Too broad: Including every service in your AWS account, including development environments, internal tools, and experimental projects. This dramatically increases the number of controls you need to implement and the evidence you need to collect, often without any corresponding benefit. It also makes the audit more expensive and time-consuming.
Too narrow: Excluding services that do handle customer data, such as logging systems that capture request payloads, analytics pipelines that process usage data, or backup systems that store copies of production databases. Auditors will identify these gaps, and discovering them mid-audit forces rushed remediation.
How Boundaries Relate to Controls
Each component inside the boundary needs corresponding controls. A database in scope requires access controls, encryption at rest, backup and recovery procedures, and monitoring. A serverless function in scope requires code review processes, deployment controls, and logging. Before finalizing your boundary, walk through each component and verify that you either have controls in place or have a realistic plan to implement them before the audit observation period begins.
It is also worth noting that the boundary diagram should evolve with your infrastructure. If you add a new service in production, it needs to be assessed for scope inclusion. If you decommission a service, it should be removed from the diagram. A boundary diagram that does not match your actual infrastructure is worse than not having one at all, because it gives both your team and your auditor a false picture of reality.
The Manual Effort Problem
In theory, producing a system boundary diagram is straightforward: list your services, draw the connections, label the data flows, and hand it to your auditor. In practice, the process is anything but simple.
It takes weeks, not hours. For most organizations, no single person understands the full architecture. Producing an accurate diagram requires interviewing engineers across multiple teams, reviewing infrastructure-as-code files, inspecting cloud console configurations, and reconciling conflicting information. A typical mid-size SaaS company reports spending two to four weeks producing their initial system boundary diagram.
It depends on tribal knowledge. Critical details about why certain services exist, what data they handle, and how they connect to other systems often live only in the heads of senior engineers. When those engineers leave or change teams, that knowledge goes with them. The next time the diagram needs updating, the team is starting from an incomplete picture.
It goes stale immediately. Cloud infrastructure changes constantly. New services get deployed, old ones get decommissioned, configurations get updated. A diagram that was accurate on Monday may be missing a new Lambda function by Friday. Most organizations update their boundary diagrams quarterly at best, which means they are operating with an outdated picture of their scope for most of the year.
It requires multiple stakeholders. The compliance team owns the audit process but lacks the technical depth to produce the diagram independently. The engineering team has the technical knowledge but views diagram creation as low-priority overhead. Security teams may have their own perspective on boundaries that differs from engineering's. Aligning these stakeholders around a single, accurate diagram is a coordination challenge that repeats every audit cycle.
The cumulative cost of this manual process is significant. Beyond the direct engineering hours, there is the opportunity cost of pulling engineers away from product work, the risk of errors in manually produced diagrams, and the ongoing burden of keeping the diagram current.
Generating System Boundary Diagrams with Fegura
Fegura takes a different approach to system boundary diagrams. Instead of relying on manual documentation and interviews, Fegura connects directly to your AWS account and auto-discovers the infrastructure that makes up your system.
Automatic resource discovery. Fegura scans your AWS environment and identifies the services, databases, storage, networking components, and compute resources that are actively deployed. This eliminates the need to manually inventory your infrastructure and removes the risk of missing resources that handle customer data but aren't well-documented internally.
Boundary mapping from account and network structure. Your VPC configurations, subnet layouts, security groups, and AWS account boundaries provide natural trust boundaries that Fegura uses to construct the system boundary diagram. Rather than asking engineers to recall which services are in scope, Fegura derives scope from the actual infrastructure topology.
Diagrams that stay current. Because Fegura reads directly from your AWS environment, diagrams reflect the current state of your infrastructure. When services are added or removed, the diagram updates accordingly. This means your compliance team always has an accurate picture of the system boundary, not a snapshot from the last time someone manually updated a Visio file.
Audit-ready output. The diagrams Fegura generates are structured for SOC 2 auditors. They include the elements auditors expect to see—in-scope services, data flows, trust boundaries, external integrations, and access points—presented in a format that aligns with the system description requirements of the AICPA Trust Services Criteria.
The practical benefit is straightforward: what previously required weeks of cross-functional effort can be produced in minutes. Engineering teams are not pulled away from product work, compliance teams are not waiting on engineering availability, and the resulting diagram is based on actual infrastructure rather than recollection and documentation that may be outdated.
System boundary diagrams are not optional for SOC 2—they are foundational. Getting them right determines whether the rest of your audit runs smoothly or gets bogged down in scope disputes and missing documentation. Whether you produce them manually or use tooling to automate the process, the important thing is that they accurately represent your system as it exists today, not as it existed when someone last had time to update a diagram. The organizations that treat system boundary diagrams as living documents rather than one-time audit artifacts are the ones that move through SOC 2 examinations with the least friction.