When preparing for a SOC 2 audit, one of the key deliverables is your System Description (Section III of the SOC 2 report). This document explains your product, infrastructure, security commitments, and control environment in detail.
Start Here
To make this process easier, we’ve created a Google Doc template you can duplicate and edit as you follow these guidelines:
Below, we break down each section of a sample description and explain how you should customize it for your own company and application.
3.1 Types of Services Provided
This section introduces your company and defines the scope of the SOC 2 report.
What to include:
Your company’s legal name.
The in-scope SaaS product/application.
A statement clarifying that other services/products are out of scope.
3.2 Principal Service Commitments and System Requirements
This section describes the security, confidentiality, and availability commitments you make to customers.
How to customize:
List your security principles (e.g., role-based access, restricted production access, monitoring).
Define your confidentiality commitments (e.g., encryption at rest/in transit, NDAs, use limitations).
Document your availability commitments (e.g., uptime monitoring, timely support, DR/BCP testing).
Reference your policies and agreements where these commitments are documented.
3.3 Components of the System
Infrastructure & Network Architecture
Explain where and how your system is hosted and secured.
What to include:
Hosting provider (e.g., AWS, GCP, Azure) and regions.
Virtual Private Cloud, firewalling, traffic filtering.
HTTPS/TLS encryption for customer data in transit.
Software
Provide a table of your core system components.
What to include:
Your SaaS application (runtime, database, storage).
Cloud services (e.g., IAM, Firewalls).
Supporting tools (e.g., GitHub for source code, Google Workspace for identity/email).
People
List the roles and responsibilities in your organization.
Examples:
Senior Management – overall responsibility, risk oversight.
Information Security Officer – manages the security program, identifies risks, implements controls.
Compliance Program Manager – ensures controls function across departments.
System Users – staff accessing IT systems, trained annually on security awareness.
Procedures and Policies
List the formal policies that support your system (Access Control, Change Management, Incident Response, Encryption, DR/BCP, etc.).
Only include policies you have in place and keep them aligned with your internal policy documents.
Data
Describe the types of data your system processes and your Data Classification Policy.
What to include:
Types: Transaction data, logs, reports, system files.
Classification levels: Customer Confidential, Company Confidential, Public.
Examples under each classification.
Note that all customer data is treated as confidential and encrypted.
3.4 Control Environment, Risk Assessment, Information & Monitoring
This section maps your internal control environment to SOC 2 trust services criteria.
Control Environment
Integrity & Ethics – Code of Conduct, background checks, policy acknowledgments.
Commitment to Competence – training, evaluations, defined roles.
Management Philosophy – oversight meetings, annual reviews.
Organizational Structure – reporting lines, updated org charts.
HR Practices – background checks, training, sanctions for violations.
Risk Assessment
How you identify and manage risks (internal/external).
Risk assessment principles (management commitment, reporting, analysis, remediation).
Vendor Risk Assessment – how you assess cloud providers, critical third parties.
Integration with Risk Assessment – annual risk assessments and updates.
Control Activities
State that controls are implemented via documented policies and procedures.
Monitoring
Continuous monitoring, independent evaluations, corrective actions.
Information & Communication
Information Security Policy, access/change/authentication procedures.
Staff access via intranet or policy repository.
Significant Events
How you capture, monitor, and escalate significant events and conditions.
3.5 Complementary Customer Controls
Controls that customers must perform to support your SOC 2 system.
Examples:
Customers manage their own application users and administrators.
Customers report unauthorized access or breaches.
Customers control and maintain their own uploaded data.
List these in a table with the applicable trust services criteria (CC5.1, CC6.3, etc.).
3.6 Complementary Subservice Organization Controls
Controls that your vendors (cloud providers, IDPs, etc.) are responsible for.
Examples:
AWS physical security, environmental protections, access restrictions.
Encryption at rest and in transit by subservice providers.
Business continuity and DR planning at the vendor level.
How to Use This Guide
Open the Google Doc Template.
Replace
<Company>placeholders with your details.Update each section based on your actual infrastructure, policies, and commitments.