SOC 2 Architecture Diagrams: Documenting Controls & Trust Service Criteria (2026)

SOC 2 architecture diagrams are among the most scrutinized technical artifacts your company will produce. During a SOC 2 audit, your auditor will compare your diagrams against your actual infrastructure to verify that every control you've claimed — encryption at rest, access logging, network segmentation — is reflected in your architecture and substantiated by evidence. A diagram that contradicts your infrastructure is worse than no diagram at all. This guide explains what SOC 2 auditors look for in architecture documentation, which Trust Service Criteria (TSC) each diagram layer maps to, and how to use AI to generate accurate, audit-ready diagrams quickly.

SOC 2 Trust Service Criteria and what diagrams cover

SOC 2 Type II audits evaluate five Trust Service Criteria. Architecture diagrams are most directly relevant to three of them:

• Security (CC): The core criterion — every SaaS company pursuing SOC 2 must include it. Diagrams must show logical access controls, network segmentation (VPCs, security groups, WAF), encryption layers, and monitoring infrastructure. Common Controls (CC6, CC7, CC8, CC9) address logical access, system monitoring, change management, and risk mitigation.
• Availability (A): Diagrams should document redundancy (multi-AZ deployments, read replicas, load balancers), backup schedules, RTO/RPO targets, and auto-scaling configurations. Relevant for any SaaS with uptime SLAs.
• Confidentiality (C): Data classification tiers must be visible — show which datastores hold confidential data, which encryption keys protect them (KMS key IDs or HSM references), and how data is masked or tokenized before reaching less-trusted services.
• Processing Integrity (PI): Relevant for financial or transactional systems. Show input validation, idempotency mechanisms, and reconciliation processes.
• Privacy (P): Required if you process personal data under SOC 2. Show PII data flows, consent management, anonymization steps, and retention/deletion pipelines.

Core architecture diagrams auditors expect

• System overview / network topology: Shows all environment tiers (production, staging, dev), VPC boundaries, subnet segmentation (public/private), NAT gateways, VPN or Direct Connect links, and the DMZ or WAF layer facing the internet. This is the first diagram auditors request.
• Data flow diagram (DFD): Traces confidential and PII data from ingestion through processing to storage and egress. Each flow should be labeled with the transport encryption (TLS 1.3), and each datastore should be annotated with encryption-at-rest status and key management.
• Identity and access management (IAM) diagram: Shows your identity provider (Okta, AWS SSO, Azure AD), MFA enforcement, privilege tiers (least-privilege IAM roles, RBAC groups), and how service accounts authenticate to internal services (IRSA, Workload Identity, Vault agent).
• Monitoring and incident response flow: Shows your SIEM or log aggregation stack (Datadog, Splunk, CloudTrail → S3), alerting pipelines, on-call routing (PagerDuty), and the incident response runbook trigger points. Auditors check CC7 (system monitoring) against this diagram.
• Change management pipeline: A CI/CD diagram that shows code review gates, automated security scans (SAST, dependency audit), staging environment promotion, and production deployment approvals. Auditors verify CC8 (change management) with this.
• Backup and recovery architecture: Shows automated backup schedules, cross-region replication, restore testing cadence, and RTO/RPO annotations for each tier. Maps to Availability criteria.

Prompt examples for SOC 2 architecture diagrams

Network topology with security controls

Data flow diagram with encryption annotations

IAM and access control diagram

CI/CD change management pipeline

SOC 2 vs other compliance frameworks: diagram scope

Annotation checklist for SOC 2 diagrams

• TSC control references: Annotate each component or boundary with the specific TSC controls it supports (e.g., “CC6.6 — network segmentation”). Auditors cross-reference diagrams against your control matrix.
• Encryption status: Every datastore and data-in-transit link should be explicitly labeled — never assume reviewers know it's encrypted. Include key management references (KMS alias, HSM slot).
• Audit log destinations: Show where audit trails land (CloudTrail → S3, application logs → SIEM) and their retention period. Auditors look for evidence that logs can't be tampered with.
• Environment boundaries: Clearly delineate production from staging from development. Auditors check that developer access to production is restricted and logged.
• Third-party integrations: Any vendor or SaaS integration should be shown with its data scope and whether it holds customer data. Auditors check vendor management controls (CC9.2).
• Diagram version and date: Include a version, owner, and last-reviewed date in the diagram footer. Auditors verify that documentation is kept current.

Related guides: zero-trust architecture, HIPAA-compliant architecture diagrams, fintech architecture diagrams, DevSecOps architecture diagrams, and authentication architecture diagrams.