Your policies and processes are the what and how of your security posture.

Your documentation is the evidence you’ll use to prove it to your auditor.

What kind of SOC compliance documentation is required for your audit?

It depends on the type and scope of your audit.

A Type II audit that only covers Security requires less documentation than one that includes several Trust Services Criteria.

Regardless of the type and scope of your audit, there are a few documents that you will need to provide your auditor. The management assertion, system description, and control matrix.

Management Assertion

Your management assertion is extremely important because it lays the stakes for your entire audit.

It’s a written claim describing your systems.

The management assertion explains how your system helps you fulfill the service commitments you’ve made to customers. And it explains how your system meets the Trust Services Criteria you’ve selected for your audit.

The management assertion explains to the auditor how your system is designed to operate. This way the auditor can test your controls to see whether that’s how it actually operates.

It all culminates in your auditor issuing their formal opinion (the final SOC 2 report) on whether your management assertion was an accurate presentation of the system under audit.

You’ll provide your management assertion to your auditor at the very beginning of your audit. If anything about your system changes during the course of the audit, you’ll need to provide an updated version.

A copy of your management assertion will also be included in your final SOC 2 report.

System Description

Your system description details which aspects of your infrastructure are included in your SOC 2 audit.

It’s important to put some thought into your system description. If it’s incomplete, your auditor will need to ask for more details to complete their evaluation.

The AICPA shares some helpful guidance for creating your system description.

This is what it should include:

• A Company Overview summarizes your products and services.
• A System Overview describes the key services you provide to customers
• Principal Service Commitments and System Requirements outline the commitments you’ve made to customers. Plus the systems needed to fulfill those commitments
• Components of the System includes infrastructure, software, data, processes, and people
• Incident Disclosure shares whether any incidents affected controls or service commitments
• Criteria Disclosure details which Trust Services Criteria are applicable to the audit
• Relevant Aspects of the Control Environment outlines the controls you’ve implemented to meet each TSC
• Complementary User Entity and Subservice Organization Controls disclose which controls your customers and vendors are responsible for, if any. (For example, a SaaS company’s customers are typically responsible for granting and revoking their own employee access.)
• Criteria Exceptions explain which Trust Services Criteria are not applicable to the audit.
• Changes to the System During the Period shares any changes to the system of internal controls that occurred during the audit period. (Applicable to SOC 2 Type II Reports) 

You can use visuals like flowcharts, tables, graphs, and diagrams to illustrate your system description.

Your system description doesn't need to include every single aspect of your infrastructure. You only need to include what’s relevant to your SOC 2 audit and the Trust Services Criteria you selected.

How detailed should your system description be?

It should be thorough enough that a reader can understand the risks facing your organization and what you’re doing to counteract them.

It’s not expected to be so detailed that it exposes your company to risk or shares security vulnerabilities that could be exploited.

Control Matrix

A Control Matrix is a spreadsheet that details the specific controls that relate to SOC 2 criteria.

It typically includes:

• Criteria reference: the specific Trust Service Criteria that the control fulfills
• Control Number: these reference numbers correspond to the individual controls you’ve put in place
• Control Activity: a description of what that specific control does
• Control Owner: the individual responsible for performing or overseeing the control. This is the person the auditor will meet with to test that control
• Risk level: a gauge of the business impact and likelihood of a control failure (low, moderate, high). While this is optional, it helps organizations understand control health and security responsibility. It's is also a typical evidence request from auditors. 

SOC 2 Compliance Documentation Examples

A typical SOC 2 audit will require documentation for:

Business Operations Documentation 

• Diagram of your physical office
• Corporate governance manual
• Company Code of Conduct
• Risk Management Plan
• Compliance program budget
• Vendor agreements
• Business continuity and incident response plans

HR Documentation 

• Organizational chart, plus outline of roles and responsibilities
• Employee handbook
• Onboarding documentation
• Termination process documentation
• Security training logs

IT & Technical Documentation

• Inventory of all devices on your network
• Equipment maintenance records
• Data retention and destruction policies
• Encryption policy
• Log management policy 
• Password requirements policy
• Access policy and logs
• System backup and update logs

Privacy Documentation

• Notice of privacy practices
• Data use agreement
• Unsubscribe and opt-out policies
• Confidentiality policy and agreements

Compliance Documentation

• Previously completed compliance reports, if applicable 
• Risk assessments
• Self-assessment questionnaires, if applicable
• Penetration testing results, if applicable

Preparing Documentation for Your Auditor

Getting your documentation organized will save headaches and help you complete your audit on time. It also allows your auditor to review documentation before they begin testing your controls.

A better understanding of your systems helps them design more effective testing mechanisms.

When gathering documentation for your audit, consider a standard reporting format that includes:

• The reason that policy was created
• The department responsible for approving and implementing the policy
• The approval and implementation dates
• The systems, processes, or applications affected by the policy
• Tracking of user policy acceptance