SOC 220 June 2026 7 min read

SOC 2 System Description: How to Write Section III

The system description is the most important narrative section of your SOC 2 report. How to write Section III accurately, completely, and in a way that supports audit testing.

Key Takeaways

The system description (Section III) describes your service, infrastructure, and controls in enough detail for report users to understand your system.
It must cover: service description, principal service commitments, system components, and the five system description criteria.
The system description is what management asserts and what the auditor tests — accuracy is critical.
Too generic is a problem: a one-paragraph description does not satisfy the criteria. Too detailed is also a problem: excessive detail creates audit testing obligations for every described element.
Your auditor will review and may revise the system description — expect collaborative refinement.

In this guide

What Is the System Description?
Five Required Description Criteria
Writing the Service Description
Infrastructure and Technology Components
People and Process Controls
Subservice Organisations
Common Issues

What Is the System Description?

Section III of a SOC 2 report is the system description — a comprehensive description of the service organisation's system as it relates to the Trust Services Criteria in scope. It provides the context within which the controls described in Section IV operate.

The system description is your narrative. Management writes it (with auditor review and refinement). It appears in every SOC 2 report and is part of what management asserts (Section II) and what the auditor evaluates.

Five Required Description Criteria

AICPA DC1 — The types of services provided: What does your product do? Who are your customers? What are the key service capabilities? DC2 — The principal service commitments and system requirements: What SLAs, security commitments, and privacy commitments have you made to customers?

DC3 — The components of the system: What are the infrastructure components (cloud regions, server types), software (application stack, databases), people (team structure, roles), procedures (key operational processes), and data elements (types of data processed)? DC4 — Boundaries of the system: What is in scope and what is out of scope? What does the system interface with externally? DC5 — How the system captures, processes, stores, and communicates information: Data flow description.

Writing the Service Description

Start with a clear, non-marketing description of your service: "[Company] provides [product name], a cloud-based [SaaS category] platform that enables [customer type] to [primary function]." Follow with the key capabilities and user types.

Describe your customer base: the industries you serve, the typical customer size, and how customers use your service. This context helps report users understand the risk profile of your system.

Describe your principal service commitments: data security (encrypted at rest and in transit), availability (uptime SLA), confidentiality (data is not shared without authorisation), and privacy (personal data is handled in accordance with your privacy policy).

Infrastructure and Technology Components

Infrastructure components: list your AWS regions (or other cloud providers), key services used (EC2, RDS, S3, Lambda, CloudFront), and high-level network architecture (VPC, subnets, load balancers). A network diagram is often included as an appendix.

Software components: your application stack (programming languages, frameworks), database technology (PostgreSQL, MySQL, Redis), deployment infrastructure (Docker, Kubernetes, ECS, Lambda), and key third-party integrations.

Data: describe the types of data your system stores (customer account data, transaction records, usage logs), where it is stored (production database, S3, CloudWatch logs), and how long it is retained. Reference your data classification policy.

People and Process Controls

People: describe your team structure as it relates to system security. Roles responsible for: infrastructure and security (DevOps/Security team), application development (Engineering team), customer support (who has production access and why), and compliance (programme owner).

Process: key operational processes that affect the Trust Services Criteria. Access provisioning and review process, change management process, incident response process, and vendor management process. Keep these high-level — detailed procedures are in your supporting policies.

Subservice Organisations

Identify all subservice organisations and the method applied (carve-out or inclusive). For each: name the organisation, describe what services they provide, identify which controls are included in or carved out of the report scope, and reference their own SOC 2 report availability.

Example for AWS: "Amazon Web Services (AWS) provides infrastructure-as-a-service (IaaS) hosting for [Company]'s production environment. [Company] applies the carve-out method for AWS's physical, environmental, and virtualisation controls. AWS maintains a SOC 2 Type II report available through AWS Artifact."

Common Issues

Too generic: a system description that describes your product in one paragraph without infrastructure details, data flows, or people/process descriptions is insufficient. Auditors and report users cannot assess controls without understanding the system.

Too specific: describing every server configuration, every script, and every database table creates an unmanageable audit scope. Keep descriptions at the architectural and process level, not the implementation detail level.

Inaccurate: the most serious issue — descriptions that do not match the actual system (wrong infrastructure, deprecated components listed, processes that do not operate as described). The system description must be accurate as of the report date.

Frequently Asked Questions

Who writes the system description?

Management (typically the programme owner with input from the engineering lead). Your auditor reviews and may suggest additions or corrections for accuracy and completeness. The system description is management's document — the auditor does not write it.

How long should the system description be?

Typically 5–15 pages for a B2B SaaS company. Larger, more complex systems with multiple products and teams may require 15–30 pages. A one-page description is almost certainly insufficient. Include a network diagram as an appendix to supplement the narrative.

Should the system description change between Type I and Type II?

The system description should reflect your system as it exists at the report date (Type I) or throughout the observation period (Type II). If your system changed significantly during the Type II observation period, the description should note the change and when it occurred.

Can we reuse our Type I system description for Type II?

Update it rather than reuse verbatim. Your system may have changed since the Type I report. Review every component listed in the Type I description for accuracy, update infrastructure and software components as needed, and update the principal service commitments if they've changed.

Does the system description need to mention exceptions or control failures?

No — exceptions are in the auditor's opinion section. The system description presents the system as management describes it. If there were exceptions, they are described in the auditor's testing results and management response, not in Section III.