SOC 2 System Description Example for SaaS Startups (2026)
What to include, what to skip, and how to draft an auditor-approved narrative
The System Description is the foundational narrative of your SOC 2 report. It defines what your application does, how it secures customer data, which infrastructure components fall inside your audit boundary, and which third-party vendors process or store data on your behalf.
Startups frequently overcomplicate this document by copying enterprise templates, scoping too broadly, or using vague architectural language. This triggers unnecessary evidence requests, extends fieldwork, and delays report issuance. This guide provides a sanitized, auditor-accepted System Description excerpt optimized for modern SaaS architectures, explains what to include versus what to skip, and details how to adapt it for AWS, GCP, Azure, or PaaS deployments. For a complete readiness plan, see our SOC 2 Readiness Checklist for Startups (2026).
• System Descriptions typically run 3–6 pages for lean SaaS startups.
• Auditors expect explicit infrastructure boundaries, accurate subprocessor disclosure, and clear shared-responsibility mapping.
• Overclaiming controls or including out-of-scope systems is the primary cause of extended audit timelines.
What Auditors Expect in a Startup System Description
AICPA guidance requires five core narrative components. Your description should address each without unnecessary enterprise jargon:
- Services Provided: What your SaaS does, who uses it, and what data it processes.
- System Boundaries: Explicit inclusion/exclusion of environments, applications, and endpoints.
- Infrastructure & Architecture: Cloud provider, region, networking, and data storage model.
- People & Processes: Roles responsible for security, access management, and incident response.
- Subprocessors & Third Parties: Vendors hosting infrastructure, processing payments, or accessing customer data.
Example SOC 2 Audit Boundary (Startup SaaS)
Most startups unintentionally scope too much infrastructure into their SOC 2 assessment. The goal is to define the minimum environment necessary to support production customer data processing.
In-Scope Systems
- Production cloud infrastructure (AWS, GCP, or Azure)
- Production databases and object storage
- Identity provider (Okta / Google Workspace)
- CI/CD pipeline (GitHub Actions, CircleCI)
- Logging and monitoring stack
- Customer support systems with production data access
Out-of-Scope Systems
- Personal founder devices (unless used administratively)
- Marketing website
- Sandbox and staging environments
- Experimental projects
- Internal finance tooling
- Non-production analytics environments
A narrower, well-defined scope reduces audit complexity, evidence volume, and remediation burden. Use SOC-002 to formally document your boundary decisions.
Annotated Example (Sanitized for Startup Context)
Below is a representative excerpt from an actual startup SOC 2 Type I report. Annotations explain why each section passes auditor review.
1. Services Provided
[Company] provides a cloud-based project management platform enabling teams to track tasks, share documents, and automate workflows. The service is delivered via web browser and mobile applications. Customer data includes user profiles, project metadata, uploaded files, and audit logs. The platform operates on a multi-tenant SaaS architecture with logical data separation.
2. System Boundaries & Infrastructure
The SOC 2 audit boundary includes the production environment hosted in AWS (us-east-1), the application layer (React frontend, Node.js APIs), managed PostgreSQL databases (Amazon RDS), object storage (Amazon S3), and the CI/CD pipeline (GitHub Actions). Staging, development, marketing websites, internal HR systems, and employee endpoints are explicitly excluded from scope.
3. Subprocessors & Third-Party Dependencies
[Company] utilizes the following subprocessors to deliver and secure the platform: AWS (infrastructure hosting), Stripe (payment processing), Okta (identity management), and Intercom (customer support). Each subprocessor undergoes annual vendor risk assessment. Customer data is encrypted in transit (TLS 1.2+) and at rest (AES-256). Access to subprocessor consoles is restricted via role-based permissions and MFA.
4. Security & Operational Responsibilities
Security operations are managed by the engineering leadership team. The CTO maintains ultimate responsibility for control design, policy approval, and incident escalation. System access is provisioned via Okta with enforced MFA. Code deployments require peer review and automated security scanning prior to production release. Backups are automated daily and retained for 30 days.
Common Startup Architectures Auditors See
Modern SOC 2 startup environments often include combinations such as:
- Vercel + Supabase
- AWS + ECS/Fargate or Lambda
- Next.js + PostgreSQL
- Cloudflare + Workers
- GitHub Actions CI/CD
- Okta or Google Workspace SSO
- Stripe + Intercom as subprocessors
Auditors are generally familiar with these architectures and focus primarily on access control, deployment governance, encryption, and monitoring practices rather than the specific framework choices themselves. Whether you use Vanta, Drata, or manual templates for compliance tracking does not affect the System Description requirements.
What Auditors Actually Review During Fieldwork
SOC 2 auditors do not perform penetration testing on your infrastructure or inspect source code line-by-line. Their objective is to evaluate whether documented controls exist, are appropriately designed, and operated consistently.
| Control Area | Evidence Examples |
|---|---|
| Access Management | MFA screenshots, user access exports, termination records |
| Change Management | GitHub pull requests, deployment approvals, branch protection rules |
| Vendor Management | DPAs, vendor SOC 2 reports, risk assessments |
| Incident Response | Incident policy, escalation procedures, tabletop exercises |
| Security Awareness | Employee training acknowledgements |
| Backup & Recovery | Backup configuration screenshots, restore test evidence |
| Logging & Monitoring | Alerting configuration, retention settings, audit logs |
Most startup SOC 2 delays are caused by disorganized evidence collection—not failed technical controls. Use SOC-003 to map controls to evidence.
What to Include vs. What to Skip
Include in Description
- Explicit cloud provider, region, and core services
- Logical tenant separation model (multi vs. single tenant)
- Named subprocessors with function mapping
- Actual deployment pipeline (GitHub Actions, Vercel, etc.)
- Explicit exclusion of dev/staging/marketing systems
Skip (Triggers Auditor Flags)
- Vague statements like “industry-standard infrastructure”
- Physical data center descriptions (irrelevant for cloud-native)
- Listing every marketing or analytics tool
- Enterprise SIEM, SOC, or on-prem network diagrams
- Implied scope boundaries without written exclusion
Adapting for Your Cloud Deployment
Your System Description must reflect the shared responsibility model of your hosting environment. Adjust the following elements based on your stack:
AWS / GCP / Azure (IaaS & Managed PaaS)
- Specify the exact region(s) and compliance certifications held by the provider (e.g., “Hosted in AWS us-east-1 (SOC 2 Type II, ISO 27001 certified)”)
- Clarify what the cloud provider secures (physical, hypervisor, managed database patching) vs. what you secure (IAM, application code, encryption keys, backup configuration)
- If using KMS, CloudTrail, or Security Groups, name them explicitly in the infrastructure section
Modern PaaS / Serverless (Vercel, Supabase, Render, Railway)
- Emphasize logical separation and platform-managed security controls
- State clearly that underlying infrastructure, OS patching, and network hardening are platform responsibilities
- Focus your narrative on what you control: application secrets, environment variables, deployment approvals, database access roles, and API authentication
Practical Drafting Workflow for Founders
Most early-stage startups can draft an initial System Description in 1–3 working sessions:
- Export your infrastructure inventory from AWS/GCP/Vercel console
- List all vendors processing customer data (Stripe, SendGrid, etc.)
- Define which systems are production vs. non-production
- Document authentication, deployment, and backup workflows
- Map shared responsibility between your company and providers
- Have engineering leadership validate technical accuracy before auditor review
A strong first draft significantly reduces CPA revision cycles.
Common Drafting Mistakes & How to Fix Them
- Scoping too broadly: Including marketing sites, internal wikis, or sales tools in the audit boundary. Fix: Explicitly exclude systems that do not process, store, or transmit customer data.
- Overclaiming vendor controls: Stating “we perform penetration testing on AWS infrastructure.” Fix: Reference AWS’s shared responsibility documentation and limit claims to your application layer and configuration.
- Vague subprocessor lists: Writing “we use various third-party vendors.” Fix: Name critical vendors, their function, and confirm they maintain SOC 2 or equivalent certifications.
- Inconsistent terminology: Calling a system “production” in the description but referencing “staging” in evidence. Fix: Ensure exact naming consistency between the System Description, policies, and evidence folder structure.
Type I vs. Type II: Description Differences
The System Description structure remains identical between audit types, with two key adjustments:
- SOC 2 Type I (Point-in-Time): Language focuses on control design as of the audit date. Use phrases like “controls are designed to…” and “systems are configured to…”
- SOC 2 Type II (Period of Time): Language must reflect sustained operation. Add coverage of monitoring cadences, quarterly access reviews, and exception handling over the observation period. Use phrases like “controls operated consistently over…” and “exceptions were documented and remediated within…”
Startup System Description Drafting Checklist
- Production environment explicitly identified
- Non-production systems excluded
- All subprocessors named and mapped
- Encryption methods documented (TLS, AES-256)
- MFA and access controls described
- CI/CD workflow explained
- Backup cadence documented
- Shared responsibility model acknowledged
- Terminology consistent across policies and evidence
Frequently Asked Questions
Who writes the System Description?
Management (typically CTO or technical founder) drafts it. The CPA firm reviews, edits for AICPA alignment, and incorporates it into the final SOC 2 report. You retain ownership of the narrative.
How long should it be?
3–6 pages for early-stage SaaS startups. Enterprise companies often run 15–30+ pages due to multiple business units, on-prem data centers, and complex vendor ecosystems.
Do we need to update it for Type II?
Only if your architecture, subprocessors, or control design changes during the observation period. Minor operational adjustments are noted in the auditor’s report, not the System Description.
Can we use a PaaS like Vercel or Supabase and still pass?
Yes. SOC 2 applies to your application layer, data handling, and access controls. Platform-managed infrastructure is acknowledged via shared responsibility mapping, not audited by your CPA firm.
What if our subprocessor lacks SOC 2?
Document it. The System Description should state the vendor name, function, and your alternative risk mitigation (security questionnaire, contractual DPA, or internal review).
How does SOC-004 relate to other templates?
SOC-004 (System Description) works with SOC-002 (Scoping Questionnaire) and SOC-003 (Control Scoping Worksheet) as your foundation package. Core policies such as COR-001 (Information Security Policy) and the Phase 1 Starter Kit cover the rest.
System Description Workbook
- SOC-004: System Description Workbook (guided template + fill-out guide)