Ready to get started with your SOC 2 audit? That’s great. But now you’re probably wondering what the process looks like and what steps you’ll need to take as you go through the audit. 

You’ll start off by defining the scope of your audit and establishing which of the trust services criteria (TSC) you want to include. Remember, the security TSC is a must-have for any SOC 2 audit, but you may also want to audit controls for availability or confidentiality. Then, you’ll have to set the time period for the audit, which can span anywhere from six months to a year. 

Once those two important steps are completed, this is when you can start documenting all the systems and controls that will be reviewed as part of the audit. In this blog we’re sharing details on how to do that effectively and efficiently so that you can start your audit with the right foundation.

Policies and procedures

One of the core elements a SOC 2 audit will look at is your policy library. Whether you have one or you need to start from scratch, your policies should outline all the things you and your team members do to protect customer data, including policies around accessing that data or managing vendors. Meanwhile, your procedures will articulate how those things get done. 

Beyond the actual creation of your policies, you also need to have all of your new and existing employees review and accept the policies. This can be done with the support of a compliance tool like Drata.

In terms of the policies that will be audited in your SOC 2 audit, these typically include: 

• Acceptable use policy: Outlines the ways in which a network, website, or system can be used. 
• Access control policy: Establishes who has access to the company’s systems and how often those permissions are reviewed. 
• Business continuity policy: Defines how to respond to a disruption in order to keep the business running smoothly.
• Change management policy: Sets rules around how your organization documents and communicates systems changes. 
• Confidentiality policy: Establishes how the organization handles confidential information regarding clients, partners, or the company itself. 
• Code of conduct: Sets policies that employees and employers should adhere to while conducting business. 
• Data classification policy: Outlines how to categorize sensitive data depending on the type of risk it poses to the company. 
• Disaster recovery policy: Defines how the company recovers from a disastrous event in order to continue operations.
• Encryption policy: Determines the type of data that should be encrypted and how.
• Incident response policy: Clarifies roles and responsibilities in the case of a data breach and an ensuing investigation.
• Information security policy: Establishes an approach for information security.
• Information, software, and system backup policy: Defines how information from various business applications is stored to ensure recoverability as needed.
• Logging and monitoring policy: Outlines which logs are collected and monitored, and the type of data that can be captured in those logs.
• Physical security policy: Sets parameters around how to monitor and secure physical access to the company.
• Password policy: Determines the requirements for password hygiene at the organization.
• Remote access policy: Outlines the type of connectivity that can be used to work remotely.
• Risk management and mitigation policy: Defines the action plan to be taken in the case of security incidents. 
• Software development lifecycle policy: Sets guidelines and requirements for building secure, compliant software that’s tested regularly. 
• Vendor management policy: Outlines which vendors could pose risks, and recommends controls for managing those risks. 
• Workstation security policy: Determines how employee workstations are secured to reduce the risk of data loss and unauthorized access.

Which of these policies you need in place will depend on the type of business you run and the type of data you manage.

When it comes to proving compliance within the audit, you’ll need to gather evidence that these policies exist and that they have been reviewed and agreed to by all employees. 

Additional SOC 2 documentation

In addition to your policies, there are three other types of documentation that you’ll need to share with your SOC 2 auditor: the management assertion, system description, and control matrix.

Your management assertion is a written claim describing your systems that’s delivered to your auditor at the beginning of the audit. In other words, it explains how your system is designed to meet the service commitments your company has made to customers. It also provides an overview of how the systems meet the TSCs selected for the audit. The auditor then uses this insight to test your controls. Your auditor will then deliver the SOC 2 report as a response to the management assertion, determining whether everything works as it should to be SOC 2 compliant.

The system description outlines which parts of the organization’s infrastructure are included in the SOC 2 audit. In reviewing the system description, the auditor should be able to understand the types of risk your organization is open to and how they’re mitigated. Typically, a system description includes the following: 

• A company overview that summarizes the company’s products and services
• A system overview that outlines the services provided to customers
• Principal service commitments and system requirements 
• Components of the system, including infrastructure, software, data, processes, and people
• Incident disclosure that speaks to whether any incidents have affected controls or service commitments
• Criteria disclosure that details which TSCs are under review
• Relevant aspects of the control environment, including the controls that have been implemented to meet each TSC
• A review of the controls that are under the purview of your customers or vendors
• Criteria exceptions
• Changes to the system during the audit period

The control matrix is typically a spreadsheet that outlines the specific controls that sit under each SOC 2 criteria. The matrix includes details for each control including a criteria reference, control number, control activity, control owner, and risk level. 

Take a proactive approach to preparing your documentation

As you get ready for your audit, the best thing you can do is take a proactive approach to your documentation. Take the time to identify what documentation you need and start putting it together. If there are gaps in your policy library, for instance, hire someone to write up those policies. Pull in the right people to craft your system description and control matrix. Getting a head start on these tasks — and working with advisors that steer you away from any mistakes — will make the audit process much smoother.

‍Need help getting started with your SOC 2 audit? We can help. Get in touch to learn how.