The ultimate guide to SOC 2 compliance

SOC 2 compliance is an increasingly common framework and applies to many businesses today. Specifically, SOC 2 applies to any service provider that stores customer data in the cloud. It is quite relevant to SaaS businesses, but also to many others who store their customers’ data in this way. SaaS vendors in particular need to be SOC 2 compliant in many instances, especially when they sell to the enterprise. Enterprises are often beholden to a wide variety of security and compliance controls, and being demonstrably SOC 2 compliant as a vendor gives those enterprise customers the peace of mind they need to do business with you.

A SOC 2 overview

SOC 2 isn't a set of hard and fast rules. Rather, it is a framework that sends a strong signal that an organization prioritizes key attributes: security, availability, processing integrity, confidentiality, and privacy. Completing a SOC 2 certification on its own is generally not enough to prove that you are 100% secure as an organization, but it’s a very good start and will go a long way toward instilling trust in your customers.

The history of SOC 2 in brief

Before SOC 2, the original standard for auditing service organizations was known as a SAS 70 (Statement of Auditing Standards No. 70). SAS 70 audits were performed by Certified Public Accountants (CPAs) with the original intent to report on the effectiveness of internal financial controls. These were introduced in the early 1990’s. Over time, the audit started to be used as a way to report on the effectiveness of a company’s internal controls around information security more broadly. Around 2010, SOC 1 and SOC 2 reports were introduced by the AICPA (The American Institute of Certified Public Accountants) with the explicit purpose of addressing the growing need of companies to externally validate and communicate their state of security. Today, SOC 1 reports are centered around controls impacting financial reports, similar the original SAS 70. SOC 2 reports, on the other hand, are written on audits against the Trust Services Criteria (TSC) standard, which we’ll explain below. This standard is ideal if you’re looking for a way to simultaneously improve your company’s maturity around business processes and security.

SOC 2 trust principles

SOC audits are organized around five "Trust Principles." When you are audited, you will choose which principles you want the auditor to attest to. This is a business decision based on what is most important to your customers.

The Trust Principles are:

‍Security

The foundational security principle, common to all audits.

‍Confidentiality

Protection from unauthorized disclosure of sensitive data.

‍Availability

Protection that systems or data will be available as agreed or required.

‍Integrity

Protection that systems or data are not changed in an unauthorized manner.

‍Privacy

The use, collection, retention, disclosure, and disposal of personal information is protected.

‍

‍All SOC 2 audits include “Common Criteria”. This is the biggest section of the audit and touches on every aspect of information security controls. Companies can start with a Common Criteria audit if they’re looking to keep the scope small. Common Criteria includes aspects of all principles noted below. In addition to Common Criteria, mature SaaS companies tend to add on Confidentiality and Availability. The Integrity principle is typically chosen by companies processing a lot of transactions, as well as financial institutions. Privacy is seldom included as part of a SOC 2 audit. While it has value, most organizations tend to focus their privacy efforts around compliance with HIPAA or EU regulations (like GDPR). This is because European companies generally want audits against their own standards, rather than SOC 2, and they tend to have more stringent requirements. If you need to uphold GDPR, for example, then you’ll be focusing on privacy when you go through that process.

SOC 2 common criteria

The SOC 2 audit process

The SOC 2 reporting standard is defined by the AICPA. All SOC 2 audits are signed by licensed CPAs . To achieve SOC 2 compliance, most companies spend anywhere from six months to a year on focused preparation. This includes identifying which systems are in scope for the audit, developing policies and procedures, and implementing new security controls to reduce risks. When ready, an organization will hire a licensed CPA auditor to conduct the audit. The actual process involves scoping, artifact document collection, and an on-site visit. The time commitment is typically several hours of introductory phone conversations and two days in-person at your office. While in your office, the auditor will conduct interviews and review submitted material. When starting to scope a SOC 2 audit, there a few key decisions that will need to be made up front. First, do you want a Type I or Type II audit? This terminology can be confusing to newbies because of the mix of numbers and Roman numerals. Here's an easy way to remember: S = SCOPE, T = TIME. i.e. SOC 1 = Financial Scope. SOC 2 = Information Security Scope. Type I = At a single point in time. Type II = Over the past 6 months.

SOC 2 Type I vs Type II explained

SOC 2 Type I

An audit conducted against the Trust Services Criteria standard at a single point in time. This audit answers: Are all the security controls that are in place today designed properly?

SOC 2 Type II

An audit conducted against the Trust Service Criteria standard over a period of time. This period typically covers six months the first time, and then a year thereafter. In other words, this audit answers: Did the security controls that were in place from January 1 through July 31st operate effectively? This means you’ll need a system of record. Type I reports are, as you might imagine, quicker to prepare for and conduct because you don’t have to wait for historical data over six months. However, while Type II reports take more time, they are also that much more valuable in the hands of customers, prospects, board members, partners, insurance companies, and so on. They report on what you’re actually doing, rather than what you aspire to do. Because of this added value, my general recommendation is to get started early and work directly toward the Type II report. This approach emphasizes immediate action taken toward improving your security, and because Type II also covers Type I, there are financial savings in the long term if you start with Type II from day one.

Typical SOC 2 timeline

Why SOC 2 compliance?

Companies of all sizes can benefit from establishing an elevated level of trust with customers, prospects, and partners. If you process or store data on behalf of a customer, you should be concerned with how it’s protected. The news is full of stories of large companies admitting to massive security incidents such as 500,000 leaked passwords, or millions of stolen credit card numbers. The recovery and cleanup of these incidents can cost in the tens of millions of dollars, including the clean-up and forensics process, implementation of new controls, and lagging sales due to lack of customer confidence. Large companies can often recover from a security incident like this because they have the financial resources and brand recognition to move past a single slip-up. Small companies and startups aren’t always so lucky. Loss of a single large customer due a security compromise, or reputational damage that impacts a company’s ability to raise additional rounds of VC funding can be devastating for a small or young business. While there is no way to absolutely guarantee security, the SOC 2 report and Trust Services framework give companies external validation that they are managing risks appropriately. Utilizing compliance management software can further help companies ensure they're aligned with SOC 2 principles.

The value of SOC 2 as a vendor

If you don’t have SOC 2 compliance as a vendor, you will probably have to fill out more than a few security questionnaires before you can work with any enterprise-scale customers. While that might sound easier than a SOC 2 audit on the surface, the questionnaires can be quite detailed and overwhelming, and they are often hard to fill out if you don’t already know the security lingo, have tooling in place, and know how to document processes. In other words, if you haven’t already gone through the process of setting up and enforcing policies as you would for SOC 2, you may find yourself stuck when the questionnaires arrive. In a nutshell, being SOC 2 compliant will both help you sell to the enterprise, and force you to follow a set of strong best practices when it comes to keeping your company’s and customers’ data safe. Security is (or at least should be) a major concern for all technology-focused companies today. Achieving SOC 2 compliance is a good way to demonstrate that you do indeed have security at heart in all you do as an organization.

Four good reasons to pursue SOC 2 compliance

Regardless of whether customers or prospects are knocking down your door for a SOC 2 report, it’s crucial to start SOC 2 preparation as early as possible. Even if don’t plan to have an audit conducted for a while, starting early will set your company up for success in many arenas.

It improves security

The formulaic approach necessitated by SOC 2 will improve your overall security. This process will mitigate potential attacks while building a strong security process that will help you win new business by better answering risk questionnaires. Security and compliance should be approached as an ongoing process, rather than a single event, and SOC 2 pushes organizations to build sustainable programs.

It bolsters company culture

Implementing new security controls can be tough. People may complain about the extra time it takes to log in to services using multi-factor authentication. However, the minor annoyances are worth the ultimate outcome. When it comes to building a secure and compliant company culture, the smaller and younger you are as an organization when new processes are put in place, the easier it will be to scale. Companies as small as three employees have gone through SOC 2 audits. It is also helpful to automate these processes as much as possible, baking them deep into your company culture.

It provides documentation

It’s never too early to get your documentation in order. Do you have policies and procedures? Do you have internal standards documentation? Having these processes well-documented will improve internal communication and consistency, which in turn enables you to meet legal and compliance challenges, close more sales, and prepare for financial changes like a merger or acquisition or a new round of VC funding.

It helps with risk management

Finally, preparing for a SOC 2 audit will give you a framework for acknowledging and mitigating risks. Many organizations who have not undergone a formal compliance audit are either unaware of security risks or addressing them in an ad hoc way. Approaching compliance systematically instead will ensure that even risks that aren’t top of mind receive attention and can be mitigated in a timely manner.

When to consider SOC 2 compliance

It’s a good idea to consider becoming SOC 2 compliant early in your company’s journey if you know you are going to be selling technological services to enterprises and will be storing and/or accessing sensitive customer data of any sort. While it can be challenging to undertake a SOC 2 compliance exercise while you are small and under-resourced, it can actually be even harder to do once you grow larger. The larger your company is and the further along you are in your growth, the harder it is to change culture, processes, tools, and more. When you are smaller, you may not have an IT or security owner, but as soon as you do hire someone in a role like that, you may want to begin thinking about preparing for SOC 2 compliance. Sooner is better, since it will help you integrate the processes and controls into your team’s culture from the get-go.

Our SOC 2 philosophy

SOC 2 is a framework to build processes around. Use this guide and the SOC 2 criteria to embed security and compliance into your core culture and business processes. Developing processes around the common criteria and trust principles will give you a foundation that you can build and scale from, rather than as a once-per-year scramble for evidence.

‍

The SOC 2 pyramid

We developed the SOC 2 Pyramid to give you a visual representation of the SOC 2 Compliance process. It consists of three levels, the foundation are your policies, these document what you do. i.e. governing the behavior of employees, vendors, contractors, etc. to meet security requirements. Above policies are your procedures, these demonstrate how your policies work operationally, i.e. what steps you take in response to key events to manage data. Finally, the top of the pyramid is proof, supporting documentation that demonstrates adherence to policies and procedures. The SOC 2 Pyramid is an excellent way to understand the audit preparation process and to visualize it in such a way that it seems less overwhelming. In this playbook, we will also explain what documentation you will need to stay in compliance across each of the three categories. We will also provide a bevy of recommended tools to manage the audit process and ongoing maintenance. By following this playbook, you can begin to build your SOC 2 strategy and start to form your project management teams.

Policies

All SOC 2 examinations include an auditor review of organizational policies. These policies must be documented and formally accepted. Each policy is related to a piece of your overall security of company and customer data. These are the general policies related to a SOC 2 exam that you must comply with:

• Information Security Policy
• Access Control Policy
• Password Policy
• Change Management Policy
• Risk Assessment and Mitigation Policy
• Incident Response Policy
• Logging and Monitoring Policy
• Vendor Management Policy
• Data Classification Policy
• Acceptable Use Policy
• Information, Software and System Backup Policy
• Business Continuity and Disaster Recovery Plan

Procedures

These documents describe how the business adheres to the policies. Security procedures must be meticulously written so that any change to the existing workflows in the future can be tested and verified to remain in compliance. These procedures will serve as the basis for future audits and include the day to day implementation of your key policies. For example, your Access Control Policy procedures include requirements for authenticating users, reviewing user access, using role-based access control and authorizing, modifying, and removing users. These procedures also include how access to privileged accounts is controlled, and the type of access or systems that require two-factor authentication.

Proof (supporting documentation)

The day-to-day implementation of your key policies must be documented consistently. Standard tools that help with this can be Google Docs and Notion to manually document changes and the procedures surrounding them. This can be a time-consuming task if your records from the past aren't well-organized. Workflow management software, which automatically records and stores, can make evidence gathering a one-step process. Just export your saved workflows.

The right approach for each common criteria

The Common Criteria for Information Technology Security Evaluation, referred to as Common Criteria, is an internationally recognized standard for computer security certification. Common Criteria is a framework that assures that the process of specification, implementation, and evaluation of a computer security product has been rigorously tested in a repeatable manner. The goal of Common Criteria is for vendors to make claims about the security of their products and that independently run testing laboratories can determine if they meet those claims. Below are the nine Common Criteria that are typically associated with SOC 2 compliance for SaaS providers and vendors.

CC1 - Control environment

Framework: Management and Communications

‍Goal: Assure that management and the Board of Directors place a high value on integrity and security.

‍Details: Management is committed to the security of customer data and takes this into account when hiring personnel, evaluating processes and reporting compliance. The Board of Directors has independent oversight of the management team.

‍Activities and Deliverables: Ensure management understands SOC 2 and security and that they manage accordingly. CC1 is accomplished through onboarding procedures and ongoing training.

‍Additional Considerations: CC1.4 is to ensure your employees are competent and trained in security. This is accomplished through your onboarding plan and company workflows.

‍Software Recommended: HRIS such as BambooHR or Workday, and Vendr (Blissfully)

CC2 - Communications and information

Framework: Management and Communications

‍Goal: Create quality policies and procedures to ensure customer data and operational security. Establish consistently reliable communications, both internally and externally.

‍Details: Your organization must generate and use quality information and documentation to ensure secure workflows and controls. It must also mandate proper communications across all departments and to external sources like vendors and customers.

‍Activities and Deliverables: Produce high-quality policies and procedures that are available through online documentation that is easily accessible to staff. Establish internal tools that will validate secure communication, both internally and externally.

‍Software Recommended: Notion, Google Docs, or other communication systems with audit functionality, but email also works.

CC3 - Risk assessment

Framework: Risk Assessment, Monitoring, and Control

‍Goal: Create clear objectives, analyze risks to achieve objectives, and monitoring how procedural changes impact risk.

‍Details: Specify organizational objectives enough so that personnel and management assess current and potential risks, including fraud. Develop procedures to update risk assessment when fundamental changes to internal systems take place.

‍Activities and Deliverables: Risk assessment processes that have corresponding documentation that is readily available to stake-holders. This includes regular updates and audits to both the risk assessment and the outcome of the evaluation.

‍Key Documents: Risk Assessment Tracking

‍Software Recommended: Notion, Google Docs, or other

CC4 - Monitoring activities

Framework: Risk assessment, monitoring, and control

‍Goal: Continually monitor, evaluate, and communicate the effectiveness of internal controls to accomplish the overall mission of securing data.

‍Details: Creating ongoing evaluations of controls that communicate deficiencies, both internally and externally, when appropriate. Activities and Deliverables: Evidence that shows risk control activities and defined risk management procedures.

‍Policies and Procedures: Notion, Google Docs, or other.

‍Software Recommended: Company workflows (usually department-specific) to easily export evidence (e.g., JIRA or Clubhouse for engineering, Github for infrastructure, AWS, etc.)

CC5 - Control activities

Framework: Risk assessment, monitoring, and control

‍Goal: Develop precise process controls and using technology to achieve company objectives while mitigating risk.

‍Details: The company develops controls for both workflow processes and technology tools to mitigate risk while still achieving pre-defined objectives. Also, defining transparent policies to establish expectations and procedures to ensure compliance.

‍Activities and Deliverables: Provide documentation showing risk control activities and proving risk management procedures were followed.

‍Key Documents: Risk Management Procedures Software Recommended: Technology Management that includes vendor management and related workflows to track employee activity, e.g., Vendr (Blissfully), plus HRIS/Employee Tracking such as BambooHR, Workday, or Checkr to maintain physical access records.

CC6 - Logical and physical address

Framework: The security of the physical premises where the organization houses data is the most important and in-depth.

‍Goal: Ensure only the right people have access to critical data, secure and encrypt data at all times, and physically protect servers storing data.

‍Activities and Deliverables: Providing sound security practices for physical servers, workstations, and employees, and evidence that these practices are working.

‍Software Recommended: Employee Access Control and On/Off-boarding procedures (Vendr (Blissfully) + Okta + HR Department)

CC7 - System operations

Framework: Robust Servers and Infrastructure

‍Goal: Ensure compliance systems are working; includes ongoing monitoring, incident response and evaluation, and disaster recovery.

‍Activities and Deliverables: Evidence showing Business Continuity and Disaster Recovery plans, and documentation showing that they work.

‍Key Documents: Business Continuity and Disaster Recovery Plan and Incident Reporting.

‍Software Recommended: Infrastructure systems such as AWS, Google Cloud, or Microsoft Azure

CC8 - Change management

Framework: Infrastructure Change Management

‍Goal: Changes to technical infrastructure are well tested and approved before going live.

‍Details: The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to any infrastructure, data, software, and procedures to meet its objectives.

‍Activities and Deliverables: Clear controls for how technical infrastructure (The System) changes, and evidence the changes were tested before going into production.

‍Software Recommended: Github for pull requests and a task manager such as Clubhouse or JIRA for engineering workflows.

CC9 - Risk mitigation

Framework: Risk Mitigation and Vendor Management

‍Goal: Mitigate risk through defined business processes and vendor management.

‍Activities and Deliverables: Business Continuity, business insurance, vendor management, including vendor due diligence and management, especially for cloud-hosted vendors.

‍Key Documents: Vendor processes, assessments, and approval from key management personnel.

‍Recommended Software: SaaS Management Software such as Vendr (Blissfully) can help mitigate risk across the organization.

‍

How SaaS management helps with SOC 2 compliance

Internal workflows

SOC 2 CC1: Control Environment Workflows are at the heart of every organization. As an organization grows from two people to five to ten, and so on, these workflows can introduce security loopholes. SOC 2 CC1 addresses your control environment, of which workflows are a component. Most workflow suites includes predetermined workflows for the most common business tasks, including employee onboarding, offboarding, vendor requests, approvals, renewals, and terminations. It also includes the ability to build, save, and repeat your own customized workflows to match your particular internal processes. When you use Blissfully for SOC 2 compliance, all your workflows are documented as exportable logs. When you decide to undertake a SOC 2 audit, you can easily pull these logs and present them as evidence to your auditors.

Vendor management

SOC 2 CC5: Control Activities As mentioned earlier, the average mid-sized company uses 120 SaaS tools. That’s a lot of vendors. Lack of visibility into who all these vendors are and how they interact with your company can be grounds for SOC 2 noncompliance. Maintaining unwieldy spreadsheets, while a common standard, fails to capture crucial real-time data regarding your vendors. Vendor management provides four essential tools to help you meet your compliance objectives:

Vendor management workflows

Under SOC 2, the control activities CC includes how you manage the entire vendor lifecycle. Our vendor management workflows tool gives you visibility on your entire vendor network. It also gives you the tools to delegate purchasing, downgrade, and upgrade rights to selected roles while maintaining an audit trail.

Document management

The vendor workflows module creates an audit trail using an intuitive document management system. As you consume SaaS resources, we l