SOC 2 System Description & Boundary Workbook
The core narrative of your SOC 2 audit. Define your system boundary, infrastructure, and controls for auditors.
Define your system boundary in one document.
System overview, infrastructure diagrams, access controls, vendor lists, and Trust Services Criteria mapping — all in one auditor-ready template.
Download System Description (.docx)SOC 2 system description template — This workbook is the core narrative of your SOC 2 audit. It defines your system boundary, infrastructure, and operational controls for the auditor. Unlike a marketing document, this is a technical artifact written for auditors, enterprise security reviewers, and internal compliance stakeholders.
Recommended Owner: CTO, Head of Engineering, or Compliance Lead | Estimated Time: 2–4 hours for early-stage startups; 1–2 days for mature organizations.
Section 1
Getting Started
- Enable Editing: Click “Enable Editing” if prompted by Word.
- Who Owns What?
- System Overview: Founder / CTO
- Infrastructure: DevOps / Engineering
- Access Management: Security Lead
- Vendor List: Operations / Compliance
Version Control: Update this document whenever major infrastructure changes, new vendors are added, or scope changes.
Section 2
Understanding Placeholders & Detail Level
This document uses two types of placeholders:
-
Bold Black Brackets [Insert Company Name] Mandatory fields. Replace with your specific data.
-
Gray Regular Brackets [AWS EC2] Examples. Delete these and write your own description.
How much detail do I need?
- Aim for 2–5 detailed sentences per narrative section.
- Clarity > Length: Auditors prefer concise, accurate operational details over long marketing paragraphs.
- Plain English: Avoid jargon unless necessary. Define acronyms if used.
Section 3
Defining the Audit Scope (Section 1.1)
The most common audit delay is an unclear scope. Use Section 1.1 to explicitly define what is IN and OUT of the audit.
“The scope of this SOC 2 examination includes the [Company Name] production SaaS platform hosted in [AWS/Azure], supporting infrastructure, production databases, and employees with privileged access to those systems.”
Scope Reduction Tip: Smaller scope = lower audit cost. Exclude anything not required for customer commitments:
- Internal prototypes or sandboxes
- Marketing websites
- Personal projects
- Staging/Dev environments*
*Unless they hold real customer data.
Section 4
Completing the Operational Sections
Move through sections 2–6 to describe your system components.
Common Mistakes to Avoid:
- Listing future/planned controls as if they already exist.
- Copy-pasting vendor marketing language (“AWS is secure”). Instead, say “We use AWS IAM to restrict access…”
- Forgetting critical third-party vendors (GitHub, Stripe, Cloudflare, Okta, Datadog).
- Leaving example text in the final document.
What Auditors Scrutinize:
- Production access controls (MFA, SSO)
- Change management process (Code reviews, CI/CD)
- Backup and recovery procedures
- Vendor/subservice oversight
- Customer data flow & encryption
Section 5
Mapping Trust Services Criteria (Section 1.2)
Confirm which TSCs apply to your audit:
-
Security Always included in every SOC 2 audit.
-
Availability / Confidentiality / Privacy Only include if you have specific SLAs or regulatory requirements. Adding unnecessary criteria increases audit cost.
Section 6
Defining Customer Responsibilities (Section 8)
Section 8 lists Complementary User Entity Controls (CUECs). These are security tasks your customers must handle (e.g., keeping their passwords safe).
Ensure these match your Terms of Service. If you require customers to enable MFA, state it here.
Section 7
Final Auditor Readiness Checklist
Before sharing this document with an auditor, verify:
- All gray placeholder text removed.
- All bold bracketed fields filled in.
- Scope clearly defined (In vs. Out).
- Architecture diagram inserted (Section 2.2).
- Vendor list completed (Section 7).
- TSC selections confirmed (Section 1.2).
- Document reviewed by Engineering Lead for technical accuracy.
Pro Tips
Pro Tips for Success
- Early-Stage Note: Auditors do not expect enterprise-scale processes from startups. They want controls that are consistent, documented, and actually followed. Be honest about your current maturity.
- Evidence Examples: When referencing controls, think about what evidence you can provide:
- Access: Okta/AWS screenshot
- Logging: Datadog/Splunk export
- Changes: GitHub PR history
- Backups: AWS Backup logs
Keep It Living: Your system changes. Update this document quarterly or after major launches.
FAQ
Frequently Asked Questions
Generally, no. Most startups exclude staging/dev environments from the SOC 2 scope to reduce audit complexity. Just ensure you clearly state this exclusion in Section 1.1.
You should create one. It doesn’t need to be perfect. A simple box-and-arrow diagram showing your Web App → API → Database → Backup flow is sufficient for most early-stage audits.
This template is tailored for SOC 2. While the structure is similar, HIPAA and ISO have specific documentation requirements that differ from AICPA standards. Use dedicated templates for those frameworks.
Share the Word document during the “Planning” phase so they can review your scope. Once finalized, you will likely convert it to PDF for the final report inclusion.