Welcome to our guide on SOC 2 compliance! We’ll cover everything you need to know about SOC 2, including its key principles, types of reports, the preparation & audit processes, costs, and best practices. Let’s get started!
The Basics of SOC 2
Before diving into the details of SOC 2 compliance, it’s important to establish a foundation of knowledge about the framework and its key concepts. In this section, we’ll cover the basics of SOC 2, including its purpose, principles, and two types. We’ll also explore the different types of SOC 2 reports and their intended audiences. Whether you’re new to SOC 2 or just need a refresher, this section will help you understand the fundamentals of this important framework.
What is SOC 2?
SOC 2 is the most widely-adopted and requested compliance framework for SaaS vendors in the United States. It’s applicable to those who store any kind of client data in the cloud or on-prem.
The framework outlines a number of Trust Service Criteria, grouped into five overarching categories with corresponding common criteria, for evaluation and reporting on the robustness of an organization’s systems (like your tech and business stack) and policies.
*In a SOC 2 audit, you are only required to show proof of adherence to the Security category.
Trust Service Criteria, or the Five Categories of SOC 2
- Security: Required. Demonstrates to an auditor that your systems are protected against unauthorized access and other risks that could impact your organization’s ability to provide services to your clients.
- Availability: Optional. Applicable when service organizations need to demonstrate that their systems meet a certain standard of high-availability.
- Confidentiality: Optional. Applicable to organizations that need to demonstrate that data classified as confidential is protected.
- Processing integrity: Optional. Applicable to organizations that must demonstrate that system processing is occurring accurately and in a timely manner.
- Privacy: Optional. Included when a service organization is in possession of personal information, to demonstrate this information is protected and handled appropriately.
At the end of the day, each individual business must choose which category, along with their corresponding set of common criteria, they would like an auditor to evaluate. There isn’t a one-size-fits-all approach, and you will need to decide what aspects of your business you would like observed and audited as part of this process, based on the commitments you have communicated to your customers and other stakeholders.
The Common Criteria, or CC-series
Security Criteria is designed to protect information and systems. The criteria used to test the Security Criteria are called the common criteria.
- CC1: Control Environment
- CC2: Communication and Information
- CC3: Risk Assessment
- CC4: Monitoring Activities
- CC5: Control Activities
- CC6: Logical and Physical Access Controls
- CC7: System Operations
- CC8: Change Management
- CC9: Risk Mitigation
To see the definition of each Common Criteria, their examples of controls, and the other additional specific criteria for availability, processing integrity, confidentiality, and privacy categories, click here.
How to Choose Between SOC 2 Type I vs. SOC 2 Type II
This is the question we get asked most frequently here at TrustCloud. It’s important to understand that there are valid reasons to choose either type of audit, and that you don’t have to have both; many organizations pick one or the other.
While Type II is the more popular of the two — it’s more comprehensive, and cheaper in the long run — a Type I audit can be the right choice for you depending on the stage and maturity of your organization.
A Type I audit can be the right choice for you if:
- You’re pursuing a SOC 2 audit for the first time, and don’t have the requisite organizational maturity to pass all of the required controls
- You need a report quickly
- You’re going after small-to-medium-sized enterprise deals
- Before preparing for a full audit, you want to show that you understand the necessary procedures to achieve the SOC 2 standard
- SOC 2 Type II Report: SOC 2 Type II reports assess the efficacy of an entity’s security and other applicable criteria since the last SOC 2 audit. Most SOC 2 reports are renewed annually. However, it is up to the company to decide to go under audit earlier if there is a necessity.
You will need a Type II attestation if:
- You have mature information security programs, systems, and processes, and can prove that you’re consistently adhering to controls over a long period
- You have other compliance frameworks in the mature state that can contribute to your SOC 2 controls
- You are planning a major funding round or exit
- You’re pursuing enterprise-level deals
In Type I, your controls are verified only once. In contrast, the SOC 2 Type II audit process involves a typical three-to-six month (though it can range up to 12 months) observation period, during which a third-party auditor verifies the effectiveness of your continued adherence to controls throughout the observation period.
Choosing between SOC 2 Type I or SOC 2 Type II doesn’t have to be hard, but there are some key differences between the two, so be sure to ask the question, “Why are we pursuing this, and do we have the resources to do it right?”
Starting your SOC 2 Journey
Now that you have a basic understanding of the framework and its requirements, it’s time to begin your compliance journey. In this section, we’ll provide guidance on how to best prepare for the audit, auditor selection, and share what auditors look for.
How to Prepare for a SOC 2 Audit
Preparing for a SOC 2 audit can seem like a challenge, but with the right approach, it can be broken down into five manageable steps.
1. Define your Audit Objectives
Before you throw yourself and your team into the bottomless pit known as audit preparation, you may want to take a few minutes (or days) to get aligned around why you’re pursuing a SOC 2 attestation in the first place. Do you have a regulatory reason to become SOC 2 compliant, and are there specific requirements you are aiming to satisfy? Was this requested by a customer? If so, what information is your customer hoping to learn from the audit, and by what date are they expecting to see a report?
2. Determine the Scope of your Audit
Once you’ve defined your audit objectives, you will need to determine scope. As you may expect, the bigger the scope, the more time-consuming the process. Unless you’ve got unlimited resources, you will need to tightly manage the scope of your audit.
3. Conduct a Readiness Assessment
When first considering a SOC 2 audit, conducting a readiness assessment lets you quickly identify your gaps and better plan how to allocate your resources. There are quite a number of criteria for you to map your business stack to, and it may seem overwhelming, but you don’t have to do it by yourself.
4. Document Policies and Procedures
Now that you have a good sense of what you want to accomplish, what controls you need to adopt, and where your gaps are, the next step is to start creating the plethora of documentation needed to meet your audit requirements. This documentation usually takes the form of a set of policies and procedures.
5. Evidence Collection
Written policies must be supported by evidence. Anything mentioned in your policy has to be backed by clear, verifiable supporting documentation.
Your team should prepare by gathering all relevant documentation and materials needed to add credibility to your policies and procedures. At the end of the day, passing an audit doesn’t simply require that you tell an auditor what you’re doing — you must show them tangible proof.
Choosing Your Auditor
Going through an audit can be a nerve-racking process. When it comes to SOC 2, the one thing you have to remember is that at its core, an audit is an auditor’s informed opinion on how well your organization’s controls meet the relevant TSCs.
There are a few things you should consider when selecting an auditor, such as accreditation, experience, and fit.
What Do Auditors Look For?
Auditors are looking for evidence that proves you’re adhering to the policies and procedures you have selected.
Auditors are guided by the IIA standard Code of Ethics, which tasks auditors with being independent and objective. The documentation you developed as evidence is seen by an auditor as proof that a particular control exists, and helps them evaluate operational effectiveness (whether or not the control is performing as it should).
In order to satisfy the auditor’s needs, it’s imperative that documentation is both complete and accurate. The source of the information in the document has to be identified and verified, the content of the document must be written with integrity, and the documentation has to be easily accessible and retrievable for audit purposes. At the end of the day, you want your auditor to come to the same conclusion about the state and health of your information security program as you would. It’s your job to help them come to that conclusion.
At the end of this long journey, once an auditor has reviewed your work and determined that your controls, policies, and procedures meet all requirements, they will give you their stamp of approval. You can now shout from the rooftops (or post on your website) that you are SOC 2 compliant… for now. And then you can start planning for next year’s audit.
SOC 2 Checklist & Terminology
Now that you have a good understanding of SOC 2 and its importance for businesses that store or process sensitive data, you may still be a little lost, and that’s okay. In this section, we’ll provide you with a checklist of key items to consider and tasks to complete when preparing for a SOC 2 audit.
Additionally, we’ll define some important terminology that you may come across during the audit process. By following this checklist and understanding the key terms, you’ll be well-prepared to navigate the SOC 2 audit and ensure that your business is compliant with the SOC 2 standards.
SOC 2 Audit Checklist (with a downloadable PDF)
Here are the different areas covered by our SOC 2 checklist:
- Scope
- Type
- Gap Analysis
- Control Implementation
- Audit Ready
- Maintenance
SOC 2 Simplified Glossary
Here are some of the terms and acronyms you may come across:
- AICPA: stands for the American Institute of Certified Public Accountants. SOC audit and reporting standards that define the criteria for managing customer information were designed by this member association.
- SOC 2: “Service Organization Control” 2 is a comprehensive framework applicable to any service provider that stores any kind of client data in the cloud or on-prem. This includes the vast majority of SaaS start-ups. The SOC 2 framework is built on the concept of Trust Service Criteria (TSC), which are grouped into five overarching categories. Each TSC is further divided into corresponding common criteria (often described as CC 1.1, CC 2.0, etc.). The individual common criteria are used for evaluating and reporting on the robustness of an organization’s systems (this usually means your technology and business stack) and policies.
- SOC 2 Audit Firm: SOC 2 audit firms are regulated by the AICPA, and they are required to be independent CPAs. The SOC 2 auditor you choose to work with will examine your controls (which will include evidence collection) to determine whether they are functioning properly. Documents that the auditor may review include:
- Organizational chart
- Inventory of assets
- Processes for onboarding and offboarding
- Processes for managing change
- SOC 2 Report: A SOC report is an audit report done by an objective, third-party firm that would be responsible for assessing your cybersecurity practices. All companies that hold customer information throughout their operation should consider scheduling and go through an audit. Depending on the maturity of the company, the intended audience for the report, and the scope, there are two types of SOC 2 reports to choose from: SOC 2 Type 1 and SOC 2 Type 2.
- SOC 2 Type I Report: A SOC 2 Type I report examines the controls that govern an entity’s security and other applicable criteria at a point in time. This involves an auditor performing a walkthrough of your processes to understand and attest to the design of your internal controls. Therefore, it would usually be the first-ever SOC 2 report for a company.
- SOC Trust Services Criteria: There are five Trust Service Criteria (TSC) or Trust Service Principles (TSP) within the SOC 2 framework. All organizations, independent of size, industry, or customer needs pursuing a SOC 2 have to include the Security Criteria. The others are optional and guided by the business and customer requirements. The five Trust Services Criteria (or Trust Service Principles) are:
- Security: Organizations are assessed on their ability to protect against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality of customer data.
- Availability: Information and systems are available for operation and use to meet the demands of its customers. If your organization is responsible for hosting the data that your customers need as a part of utilizing your services, you may consider including this criterion.
- Processing Integrity: Consider this criterion if you are in a transaction-based business. This principle verifies that system processing is complete, valid, accurate, timely, and authorized to meet the objectives.
- Confidentiality: Information designated as confidential is protected to meet the entity’s objectives. To achieve organizational success, sensitive information must be appropriately safeguarded from unwanted access.
- Privacy: Personal information is collected, used, retained, disclosed, and disposed of to meet the entity’s objectives. If you collect the personal information of customers to provide services, this may be a consideration.
