SOC 2 audit reports can be 100+ pages long, covering detailed information about the systems and audit results. One of the most important (and lengthy) sections of the report is the system description.

SOC 2 reports typically have five main sections: 

1. Auditor’s Report: A summary of the audit and its results. This section includes the auditor’s opinion on how well your control environment aligns with SOC 2 requirements.
2. Management Assertion: Management’s claims about its systems and internal controls
3. System Description: A detailed overview of the system under audit, including its components, procedures, and system incidents.
4. Control Tests: A description of the tests performed and the results. 
5. Other Information: Any additional information, such as management’s response to any audit exceptions. 

Sitting down to write the system description can be daunting, especially if you don’t know exactly what to include or where to start. If that sounds like you, you’ve come to the right place.

We’ll explain what goes into a SOC 2 system description, walk you through how to write it, and share real examples for you to reference.

What is a SOC 2 system description and why is it important?

Every SOC 2 audit ends with a written report that summarizes the scope and results of the audit. Some sections of the SOC 2 report are written by the auditor, and some are written by the service organization.

The SOC 2 system description is one part that’s written by the organization. It’s a detailed summary of your services and the controls you’ve implemented to satisfy the Trust Services Criteria relevant to your audit. 

Let’s put it in even simpler terms. Imagine you own a car that you rent out to people (your service). The SOC 2 system description is like a comprehensive manual for that car. It would include information like:

1. What the car should be used for (description of your services).
2. How often it's serviced and by whom (information about third-party service providers or contractors you use).
3. The various safety features of the car, like lane assistance, automatic braking, and airbags (security controls you have in place to ensure the security, confidentiality, availability, privacy, and processing integrity of data).
4. Procedures for how to use the car safely (your company’s policies and processes).

This manual (or SOC 2 system description) helps customers understand what you’ve done to ensure that your services are safe, reliable, and properly maintained. It's a crucial part of building trust with customers and partners and demonstrating that you're committed to the highest standards of information security.

What to include in a SOC 2 system description

Now let’s get into the nuts and bolts of how to write a SOC 2 system description.

A system description can be broken up into eight basic parts. We’ll walk through each part below, include some examples, and share tips and best practices from our team of SOC 2 experts and former auditors.

Part 1: Company overview and services provided

The first part of the system description gives an overview of what the organization does. 

ABC Company helps businesses attract and retain talent by making it easier to connect with the right applicants. We’ve raised $100 million from investing firms including VCFirm1 and VCFirm2 and have 10 thousand customers worldwide. 

ABC Company’s platform was developed and built by ABC Company. The platform is hosted on AWS cloud infrastructure that can be accessed through the abc.co website. 

Part 2: System boundaries

This is a description of what is covered as part of the scope of the SOC 2 audit. 

The system boundaries for consideration within the scope of this report are the production systems, infrastructure, software, people, procedures, and data supporting the XYZSystem.

Part 3: Subservice organizations

Write a paragraph that summarizes the technologies that will be discussed in the system description. This can be a simple list of the services you use and why.

ABC Company uses AWS, a subservice organization, to provide cloud infrastructure; Dropbox, a subservice organization, for cloud-based file sharing; and Slack, a subservice organization, for team communication and collaboration.

Part 4: Principal service commitments and system requirements

In the next section, you’ll need to demonstrate how your system satisfies service commitments and system requirements. 

1. Service Commitments: These are essentially the promises a service organization makes to customers, partners, and other stakeholders. These might be documented in service level agreements (SLAs), contracts, or other formal documents, and they often relate to data security, availability, processing integrity, confidentiality, and privacy.

For example, a cloud service provider might commit to a certain amount of uptime like 99.9% availability, security measures like data encryption, or timely data backup and recovery.

2. System Requirements: How does the system need to operate to meet the stated service commitments? 

System requirements can include both functional aspects (what the system does, such as processing transactions or storing data) and non-functional aspects (how the system performs, such as its availability, reliability, or level of security).

Part 5: System components

This section outlines the different components that make up the system under audit, and should cover five points:

1. Infrastructure: What hardware and other components make up the system under audit? This can include hardware, servers, data storage, etc. Some organizations include descriptions and/or diagrams to explain the infrastructure components and how they relate to each other. 
2. Software: List the vendor software used to provide the services or products in scope for your SOC 2 audit. This can be in the form of a table where you list each vendor software and its function. 
   
3. People: What departments or teams are involved in the security, governance, operation, and management of your product or service? This will likely take the form of an organizational chart or a listed description of departments and/or teams. 
4. Data: What types of data come into your systems, and how are they safeguarded? List the types of data used by your databases, storage, and files and diagram how it flows through your systems and processes. 
5. Policies, Processes, and Procedures: In this section, you’ll explain how you’ve designed a control environment relevant to information security. Detail your policies, processes, or procedures for access controls, monitoring and logging procedures, change management and business continuity processes, cybersecurity awareness training, etc.

Part 6: Internal controls

Here you’ll detail the steps you’ve taken to design and build effective information security controls within your organization.

• Control environment: Explain how company leadership approaches information security and security controls. What principles do you use to define your approach to information security? What involvement or responsibilities does the Board of Directors have in guiding or supporting strong information security practices? What hiring and onboarding practices do you have in place to ensure a strong security culture across the organization?
• Risk management and risk assessment processes: Describe how your organization identifies, evaluates, and mitigates risk. This section should cover how often you conduct risk assessments (should be at least annually). It should also explain your approach to identifying, analyzing, prioritizing, and treating risks, as well as how you communicate and monitor risks within your organization.
• Information and communication systems: Describe of how your organization communicates with both employees and customers about business goals, operating performance, and/or the internal control environment. 
• Monitoring controls: Explain how your organization monitors controls to ensure they are operating as intended. Do you use vulnerability scanning or penetration testing services? Conduct regular internal security audits? Use continuous monitoring services?
• Control activities: Detail the internal controls you’ve implemented relevant to information security, including policies, procedures, and processes. For example:
  undefinedundefinedundefinedundefinedundefinedundefinedundefined

Part 7: Complementary Subservice Organization Controls 

List any security controls that subservice organizations are responsible for implementing, along with their corresponding Trust Services Criteria. 

Subservice Organization Name: AWS

Complementary Subservice Organization Controls: Controls are in place and operating effectively to ensure data backup and recovery processes meet recovery objectives. 

Applicable Criteria: CC 9.1

Part 8: Complementary User Entity Controls

List any controls that end users of your service/platform/system are responsible for relevant to the scope of your SOC 2. 

For example, your customers may be responsible for ensuring only authorized individuals are granted access to your platform. 

Complementary User Entity Controls: Controls should be implemented to ensure that data is sent to [Organization] through a secure connection. 

Applicable Criteria: CC 6.6

Tips & best practices from SOC 2 auditors

Avoid marketing jargon. The American Institute of Certified Public Accountants (AICPA) specifically warns against using “advertising puffery” in the language you use to write your system description. Keep your description concise and to the point. 

Be as accurate as possible. As part of your SOC 2 audit, the auditor will state their opinion on whether your system description is accurate, complete, and meets SOC 2 attestation standards. Misstatements or inaccuracies can result in the auditor giving a qualified opinion in your final report. 

Be comprehensive, but not overly detailed. When writing your system description, you may wonder how much detail to provide. Offer enough information to prove that you’ve satisfied TSC requirements without divulging any trade secrets, intellectual property, or other sensitive business information. 

More free resources for SOC 2 Type I and Type II compliance

Getting SOC 2 compliant can be a daunting and complex process. At Secureframe, it’s our mission to demystify and streamline security compliance for all organizations. 

Our compliance automation platform monitors your cloud infrastructure for compliance, simplifies vendor and personnel management, and automatically collects audit evidence. We also built a SOC 2 Compliance Hub to walk you through the audit process, and a library of free SOC 2 policy templates, readiness checklists, and evidence spreadsheets to save you hours of manual audit prep.