SOC 2 considerations for software as a service (SaaS) providers can be a hard decision. On one hand, it has oftentimes become a contractual requirement but on the other hand, if that client or clients requesting the report do not provide enough revenue to offset that expense, the business case to move forward may not be there. But frequently Companies still grapple with whether or not taking on that expense is worth it for the next big customer who requires the SOC 2 audit. In this post we will discuss when SaaS companies should undergo SOC 2, SaaS compliance options (and what those compliance options are), and whether SOC 2 compliance is mandatory.
Note: Video Update Correction 1: At 1:14 in the video, we state that the security trust services criteria includes the common criteria. In reality, the common criteria actually includes security.
Video Update Correction 2: At 2:06 in the video, we state that the SOC 2 came as a result of the SAS 70 report. The pre-courser to SOC 2 was actually the trust services principles associated with the WebTrust and SysTrust examinations which were an outgrowth of SAS 70, which itself has a long history.
Is SOC 2 Required for SaaS Companies?
While a simple yes or no answer would be nice, unfortunately, it doesn’t always pan out that way. This answer is oftentimes related to contractual obligations first and foremost. In general, there is no requirement from an industry perspective. That is because not all SaaS companies maintain information that is considered sensitive, or they may have implemented technology that relies on an application programming interface (API) to display data instead of housing the data internally. Because of these variables, the requirement for a SOC 2 also varies.
There are times when compliance is considered to be ‘required’. For example, HIPAA requirements. And while this post is not about electronic protected health information (ePHI), the health industry, which is regulated more so by the U.S Department of Health and Human Services (HHS), does require that ePHI is protected and should be in compliance with HIPAA requirements that are considered required and addressable. Check out our article to learn more about the differences between SOC 2 and HIPAA reports.
When Do SaaS Companies Need a SOC 2?
As mentioned above, there are many reasons why a company may be a good candidate or not when considering a SOC 2 examination. Below are questions I generally go through with potential clients.
- Do you have clients inquiring about a SOC 2 report?
- How many clients are inquiring about a SOC 2 report?
- Is this type of examination provided by other similar types of SaaS companies in the space the company operates?
- Is customer data maintained within the production environment?
- If yes, what type of data is being stored? [i.e. sensitive (SSNs, names, could be used to identify a person), sole proprietor, vulnerability details, etc]
- If the information maintained was somehow accessed by an unauthorized individual, would the company’s reputation be at risk?
Read here for expert tips on audit preparedness for small businesses and start-ups.
Using these questions, I am often able to give a company considering SOC 2 an idea of whether or not a SOC 2 makes sense and if a SOC 2 is required, the timeline that would best meet their needs. For example, suppose it is determined that a SOC 2 is required but there is no specific timeline. In that case, it is possible that they could go through a readiness assessment to identify the design of the controls required to meet the SOC 2 criteria and then allow six months to occur before testing the operational effectiveness. This will allow a company to receive a Type II SOC 2 report and skip the Type I. This is discussed in more detail below in the next section.
On the other hand, if these questions are asked and generally answered as no, a SOC 2 examination may not be required. And I believe knowing when a SOC 2 is not required and why is especially important when discussing compliance requirements with potential and current clients. There will be times when a SOC report is required but there are questions on how the criteria actually apply to the organization. In those instances, it can be helpful to talk with a CPA firm to fully understand why a SOC 2 may not be applicable and how to communicate that back to the company asking for it.
What are SaaS Compliance Options?
SaaS compliance is not only specific to the organization but the options are many and ever-changing. It can vary depending on the nature and industry a SaaS company is serving. While receiving a SOC 2 report is certainly requested among a wide variety of industries, other types of compliance requirements exist. For example, when working with federal or state information, FedRAMP or StateRAMP is generally required. When working with ePHI there is often a requirement to follow HIPAA compliance considerations for SaaS or even HITRUST. And when working with CJIS information, CJIS compliance may be requested. And this list goes on.
However, if SOC 2 compliance is required there are additional compliance options available. This includes SOC type (I or II) reports and even the criteria included. The general cadence of SOC 2 is to start out with a type I which focuses on the design of controls and then the following report will be a type II report. A type II report not only looks at the design of the controls but also the operational effectiveness.
As mentioned above, if time permits, the Type I can be skipped – but generally a minimum of nine months is required to allow for implementation requirements, and six months is required to allow controls to operate for testing. Additionally, there are five criteria, known as the TSCs, to select from.
All SOC 2 reports include the security criteria, but the others can be added on as required. Knowing which criteria to select can generally be decided upon when in discussions with the client and further validated when deciding on the CPA firm to complete the examination. CPA firms should know when to say a certain area should not be in scope because in most cases, not all of them will be.
Is SOC 2 Compliance Mandatory?
Thankfully, SOC 2 compliance is not mandatory in the way that taxes are required. If no client is requiring a SOC 2, or a SOC 2 report is generally not seen among competitors in the space, it is possible that it will not be a mandatory requirement for an organization. However, when SOC 2 compliance is generally considered mandatory, it is because it has been included in one or many agreements as part of the client acceptance process.
Overall, a SOC 2 report can certainly open the door to possible clients as assurance that information technology (IT) general controls are designed and operating effectively before entertaining the use of a third-party vendor. The SOC 2 criteria was created in such a way as to provide this type of assurance to clients. In most cases, SaaS companies and cloud services providers will receive audit requests and most of the time, SOC 2 compliance does make sense. However, to have a good SOC 2 examination experience that meets the needs of the company, it is important to engage a firm that will perform the following steps:
- Provide informed guidance on control processes that need to be in place to meet the criteria.
- The ability and experience to explain which criteria to add and when it is necessary.
- Guidance for when a SOC 2 does not make sense at all.
At Linford & Company, our team of audit professionals has assisted clients in preparing for a variety of audits, and certification processes, and provided guidance for maintaining compliance. If you would like to learn more about our many audit services, please contact us.
Jaclyn Finney started her career as an auditor in 2009. She started with Linford & Co., LLP. in 2016 and is a partner with the firm. She is a CISA with a special focus on SOC, HITRUST, FedRAMP and royalty examinations. Jaclyn works with her clients to provide a process that meets the needs of each customer and generates a tailored report that is useful to the client and the users of the report.