If you are a SaaS or cloud software company, you have probably noticed security reviews, compliance and certification requirements like SOC 2 are getting more complex at the same time as they are becoming more commonplace.
This reflects the increasing number of security incidents and customers' concern with their vendors' security processes. The Accenture Cost of Cyber Crime Study found that an average organization was a victim to 2.5 successful cyberattacks each week in 2017. This issue isn't getting any better; security incidents increased 27.4% between 2016 and 2017.
Think about it from your customers' perspective. When they do business with a cloud provider or SaaS company, they are often sending sensitive information that they wouldn't want leaked. Once they send this information, they are fully dependent on your security controls and processes. A breach won't only affect your customer. It will also affect their customers, partners, vendors and/or employees. The stakes are high and companies are getting more sophisticated in the questions they ask of their cloud and SaaS vendors.
One of the requirements often requested, or required, is SOC 2 Compliance. Although SOC 2 may seem daunting, you can help yourself achieve it by first understanding what it is and what you should do about it.
History of SOC 2
SOC 2, which stands for Service Organization Control 2, is an audit that deals with a service organization's controls around protection and privacy of data. A "service organization" is an organization that receives data from another organization. Most cloud and SaaS companies fit into this category.
SOC 2 was created by AICPA to establish an audit standard that addresses the continued trend of cloud computing and SaaS.
Unlike predecessors SAS 70 and SSAE 16 (later renamed SOC 1), which primarily focused on financial controls, SOC 2 was created for data that is sent to service providers. SOC 2 was created partly because proceeding standards were being misused as a way to demonstrate that an audited organization had controls to protect data.
Like its predecessors, SOC 2 comes in two variants: Type 1 and Type 2. In Type 1, the auditor assesses and reports on an organization's system and the design of its controls. Type 2 adds the auditor's assessment of the operationalization of the controls.
SOC 2 is an annual audit and the AICPA updates its criteria periodically to reflect current trends in security and controls.
Why is SOC 2 important
SOC 2 is becoming the go-to audit report that many enterprise customers are expecting from their cloud and SaaS providers.
SOC 2 compliance is a significant but worthwhile investment. It could prevent you from stalling or losing that enterprise deal your team has been working on for months. It is a good external assessment to demonstrate that the controls you have in place are appropriate for protecting your customers' data. Like all audits and security reviews, it does not prove you will never have a breach or security event. However, it does help prove to your customers that you take security seriously.
What about my infrastructure provider's SOC 2 audit? Is that enough?
All of the major cloud and hosting providers do SOC 2 compliance audits that reflect their security controls. But this isn't enough, as it doesn't reflect your cloud or SaaS company's controls. As you can imagine, there is often a large difference between what you as a software company provide and what your cloud infrastructure provider, such as AWS, provides. Your cloud provider may offer a bullet proof infrastructure, but if your software development processes don't support security your software will introduce security holes.
Some enterprise customers will accept a infrastructure vendor's SOC 2 report and a summary of your security processes, but we see that trend change as more and more customers push for SOC 2 audits, or at least proof that controls that would meet a SOC 2 audit are in place.
In short, you must be able to cover not only security of the cloud (the cloud provider's infrastructure), but also security in the cloud (how you configure and use the cloud infrastructure and services, as well as your applications and data) and security outside of the cloud (your software development processes, user endpoint devices, training and awareness, etc.)
What is required for SOC 2?
SOC 2 is an audit performed by an auditor who assesses your organization against the applicable 5 trust principles and generates a report with their findings. SOC 2 is not a strict, dictated set of mandatory controls, but rather is based on the service/application and the auditor's assessment of the trust principals.
The five trust principles are:
- Security – This is probably what most people think of when they think about SOC 2 compliance. Security addresses whether systems, software and information are protected against unauthorized access, leakage or other events that would impact availability, integrity or privacy.
- Availability – Typically reflected in an SLA, this addresses the organization's ability to keep their software up and running.
- Processing Integrity – This trust principle reflects whether the systems and software produce valid and accurate results per the organization's objectives and offerings.
- Confidentiality – Confidential information the organization receives stays confidential and isn't leaked.
- Privacy – Personal information is used consistent with the organization's objectives, for example, aligned with the organization's privacy policy.
As with most reviews and audits, you will need to demonstrate that you have policies in place to support these trust principles, processes to support these policies and controls in place to measure your adherence with these policies.
It is important to remember that with SOC 2, you are not just demonstrating a point-in-time compliance. SOC 2 compliance requires you to instrument and identify controls deficiencies continuously and remediate such deficiencies in a timely manner, or risk being out of compliance. Don't fall into the trap of only thinking about SOC 2 once a year.
Getting started with SOC 2
SOC 2 compliance auditors are auditors – not consultants – so prior to starting to evaluate against the framework you should have your security policies, processes and controls in place. You will be asked to provide evidence for each, which is often more difficult than it sounds given the dynamic nature of cloud software development processes.
This is precisely the reason why we created JupiterOne. JupiterOne assists in the creation of SOC 2 compliant policies and helps you get full visibility as well as manage security across your organization so that you are always in compliance and as secure as possible.
Learn more about how JupiterOne can help you get and maintain SOC 2 and other compliances and certifications.
Join the JupiterOne community to better understand your current security state, tools you have in place, tools that may be missing and a path forward to address security issues.
