A complete SOC 2 report contains four primary sections. While the auditor signs the opinion (Section 1) and details the test results (Section 4), Section 3: The System Description is a narrative written and owned by the service organization’s management.

The system description outlines the boundaries of your technology platform, the infrastructure and software components utilized, the personnel involved, and the specific control activities designed to protect customer data.

Writing a clear, compliant system description is essential. Here is a guide on how to structure Section 3 for your SOC 2 audit.

The Core Elements of Section 3

According to the AICPA Description Criteria (DC 200), a standard system description must include these five primary sections:

1. Types of Services Provided

Describe what your business does and how your software application works. Focus on how data is ingested, processed, stored, and sent back to users.

  • Audit Tip: Avoid marketing jargon. Write a clear, functional summary of your SaaS platform, specifying target user roles and primary data exchange mechanisms.

2. Components of the System

This is a catalog of the assets that comprise your operational environment:

  • Infrastructure: The cloud server hosting environments (e.g., AWS EC2, S3, RDS), virtualization tools, and network boundaries.
  • Software: The core codebase, databases, and third-party monitoring/operating tools.
  • People: The organizational structure, key departments (Engineering, HR, Security, DevOps), and roles responsible for managing controls.
  • Data: A classification map of client records, detailing how they are structured and segregated in production databases.

3. Boundaries of the System

Clearly define what is in scope and what is excluded from the audit. For example, if you sell three software products but only one processes enterprise customer PII, you can choose to scope the audit exclusively to that single product.

  • Audit Tip: Document all critical third-party integrations (e.g. Stripe for payments, Twilio for SMS) as subservice organizations or vendor boundaries.

4. Applicable Trust Services Criteria

Detail the specific criteria (Security, Availability, Confidentiality, etc.) you selected, explaining the operational controls mapped to each criterion.

5. Management Assertions

A signed declaration by your executives stating that the description is presented fairly and that the mapped controls were designed and operating effectively during the review period.

Common System Description Pitfalls to Avoid

  • Including Out-of-Scope Assets: Documenting internal tools (like corporate HR portals or payroll systems) in the same depth as production application servers. If an asset doesn’t touch client data, keep it out of the system description.
  • Mismatching Reality: Stating that security patches are applied within 7 days, while your ticketing logs show patches regularly take 30 days. The narrative must match your actual operations.
  • Forgetting Third-Parties: Failing to list critical cloud providers (e.g. AWS) or customer-support ticketing tools that process customer data.

Strategic CTA for Compliance Teams

Drafting Section 3 is a collaborative exercise between security, engineering, and legal teams. Establishing clear boundaries during readiness prevents having to rewrite description documents during the audit fieldwork.

Learn how we assist with scoping, policy drafting, and system description alignment: Expert Insights SOC 2 Compliance Services.