SOC 2 System Description (Section 3): What It Must Cover and How to Write It

What Is the SOC 2 System Description?

Section 3 of a SOC 2 report — called the System Description — is management's written description of the system that was audited. It is management's representation, not the auditor's. The auditor tests whether the description is fairly presented. Enterprise customers read it to understand your security posture. It is often the most-read part of the report.

The System Description must meet the criteria in AICPA DC Section 200 (Description Criteria for a Description of a Service Organization's System in a SOC 2 Report). Published alongside SSAE 18, DC Section 200 defines the nine required description elements. If any are missing, the auditor will require revisions before issuing the report.

The Nine DC Section 200 Required Elements

DC 200 Element	What to Include	Common Mistake
1. Types of services provided	What the system does and how customers use it. Include deployment model (SaaS, PaaS, API).	Too vague — "provides software solutions." Be specific about the product and use case.
2. Principal service commitments and system requirements	The commitments made to user entities — availability SLA, confidentiality requirements, security commitments. These must align with what your contracts promise.	Commitments stated in the description don't match SLA or contracts. Auditor flags inconsistency.
3. Infrastructure components	Cloud providers, data centres, networks, hardware. Named providers (AWS, GCP, Azure) and regions.	Listing "cloud infrastructure" without naming the provider. Auditors need the actual component.
4. Software	Applications, databases, middleware material to the Trust Service Criteria. Include third-party software.	Missing key database or identity provider that's material to access control testing.
5. People	Roles involved in operating and securing the system. Include org structure, key responsibilities, background check programme.	Just listing job titles without describing responsibilities. Auditors need to understand who does what.
6. Data	Types of data processed, where stored, data flows, retention approach. Classification levels.	Describing data in abstract terms. Be specific: customer PII, financial data (tokenised), logs.
7. Procedures	Key operational and security procedures: change management, access provisioning, incident response, backup/recovery.	Referencing policy documents without describing the actual process. The description must be self-contained.
8. Relevant aspects of control environment	COSO 5 components: control environment, risk assessment, control activities, information & communication, monitoring.	Skipping the monitoring component. Auditors specifically look for how management monitors that controls are operating.
9. Subservice organisations	Third-party providers whose services are relevant to the Trust Service Criteria. Carve-out or inclusive approach. CUECs and CSOCs.	Not naming AWS, GCP, or Azure as subservice organisations. These are material and must be disclosed.

Carve-Out vs. Inclusive Method

The System Description must state how subservice organisations are handled:

Carve-out (most common): The description notes that subservice organisations exist but their controls are excluded from scope. The auditor does not test the subservice org's controls. Instead, the description explains Complementary Subservice Organisation Controls (CSOCs) — controls the subservice org must have — and Complementary User Entity Controls (CUECs) — controls customers must implement. AWS, GCP, and Azure are almost always carved out.
Inclusive: The description includes the subservice org's controls in scope, and the auditor tests them. Requires the subservice org's cooperation and is rarely used unless the relationship is exceptionally close (e.g., wholly owned subsidiary).

For most SaaS companies: carve-out all cloud providers, include a table naming each subservice org (AWS, Stripe, Sendgrid, etc.), the services they provide, and the data involved. Reference their own SOC 2 reports as available.

Complementary User Entity Controls (CUECs)

CUECs are controls that user entities (your customers) must implement for the system to meet its security commitments. This is one of the most commonly overlooked sections. Examples:

User entities are responsible for managing their own user accounts, including timely deprovisioning of departed employees
User entities are responsible for enforcing MFA for their own administrator users accessing the platform
User entities are responsible for reviewing and acting on security notifications sent by [Company]
User entities are responsible for the integrity and accuracy of data they input into the system
User entities are responsible for maintaining the confidentiality of their API keys and integration credentials

CUECs shift some responsibility to the customer — which is why enterprise procurement teams read this section carefully. Keep CUECs realistic and aligned with your actual system architecture.

What the System Boundary Must Cover

The system boundary defines what's in scope for testing. For SaaS companies, the boundary typically includes:

The production application (web app, API, mobile apps if relevant)
The production database(s)
All production infrastructure (cloud accounts, VMs, containers, serverless functions)
Identity and access management systems (SSO provider, LDAP, IAM)
Monitoring and logging infrastructure
CI/CD pipeline (as it can introduce changes to the production environment)

What's typically out of scope: development and staging environments (unless they can access production data), employee laptops (unless they can directly access production), non-production SaaS tools.

Scope creep is a risk: the larger the scope, the more controls need to be tested. First-time SOC 2 engagements often scope too broadly and end up with more exceptions. Start with a tight scope — the production system — and expand in subsequent years.

Writing the Principal Service Commitments

This section is directly connected to the Trust Service Criteria (TSC) in scope. The commitments must be aligned with what you've contractually promised to customers:

Security (CC): "The system is protected against unauthorised access, use, or modification." State your specific security commitments — what you do to protect customer data.
Availability (A): State your uptime SLA (e.g., 99.9% monthly). Include what "available" means — the system is accessible to authorised users as committed.
Confidentiality (C): "Customer confidential information is protected throughout its lifecycle in the system." State what makes data confidential and how it's handled.

The auditor will compare your commitments against your actual controls. If you claim 99.9% availability but have no redundancy or failover, that's a gap. Write commitments you can actually demonstrate.

Describing the Control Environment (COSO)

The COSO control environment section is where auditors start reading when assessing the overall tone at the top. For SaaS companies, this typically covers:

Control Environment: Leadership commitment to security, organisational structure, HR security programme, onboarding/offboarding controls
Risk Assessment: How the company identifies and assesses security risks — risk register, annual risk assessment, threat intelligence
Control Activities: The specific controls implemented — access management, encryption, change management, vulnerability scanning
Information & Communication: How security-relevant information flows — policy communication, training, incident reporting
Monitoring: How management monitors that controls are working — access reviews, log reviews, audit trails, compliance platform (Vanta, Drata, etc.)

Auditors sample evidence from all five COSO components. The monitoring component is particularly important — it demonstrates that management has oversight, not just that controls exist on paper.

Common System Description Failures

Failure	Why It Happens	How to Fix
Description doesn't match reality	Description was written before controls were implemented, or after a system change	Have engineering review for technical accuracy. Update after any significant architecture change.
Vague subservice organisation disclosure	Company doesn't want to disclose which vendors they use	Disclose all material subservice orgs by name. Auditors require this. Customers expect it.
Missing CUECs	Company doesn't realise customers have compliance responsibilities too	Include 5–8 CUECs covering access management, API key management, data input, and security notification response.
Control descriptions too high-level	Management doesn't want to disclose how controls work	Controls need enough detail for the auditor to scope their testing. "We use encryption" is insufficient. "We use AES-256 at rest with AWS KMS-managed keys" is sufficient.
Commitments misaligned with contracts	Description was drafted without cross-checking customer contracts	Have legal review the service commitments section against MSA/SLA templates before audit fieldwork begins.

Type I vs. Type II: What Changes in the System Description

For a Type I (point-in-time) report, the System Description describes the system as it exists at the as-of date. Controls are described as designed. There's no examination period — just "as of [date]."

For a Type II (period-of-time) report, the System Description describes the system as it existed throughout the examination period. If significant changes occurred during the period (system migrations, major control changes, team changes), these must be disclosed. The description should note the examination period start and end dates and describe the system as it operated throughout that period.

Key Type II consideration: if you migrated from AWS to GCP during the examination period, both must be reflected. The auditor needs to know which components were in place at the start vs. end of the period.

Generate Your SOC 2 System Description

Use the SOC 2 System Description Generator to create a complete, AICPA DC Section 200-aligned Section 3 draft. The generator covers all nine required elements: infrastructure components, software, data, personnel, procedures, COSO control environment, subservice organisations (with carve-out/inclusive choice), CUECs, and management declaration placeholder.

⚠️ This guide is for informational purposes only and does not constitute legal or compliance advice. SOC 2 scoping and system descriptions must be agreed with your CPA firm. Always work with a licensed AICPA-member CPA firm for your actual audit engagement.