The Service Organization Control (SOC) 2 certification is a must-have certification for software as a service (SaaS) companies. SOC2 allows a business to demonstrate that their internal controls meet security best practices. In the realm of SOC2, these best practices are memorialized as the trusted services principles (TSP). The American Institute of CPAs (AICPA) defines these five TSPs as: security, availability, process integrity, confidentiality, and privacy.
While SOC2 compliance can have numerous benefits to a growing SaaS provider, obtaining SOC2 compliance has plenty of challenges. Before we get too far down the road to SOC2, let’s stop to check out the origins of SOC compliance.
SOC the SAS-70
SOC2 is a reporting regimen that comes from the SSAE 16 security control framework, which the AICPA publishes and maintains. SOC replaced the old SAS-70 reports in 2011. SOC2 is only one of 3 audit reports for service organizations. SOC 1 and SOC 3 being the other two.
A SOC 1 report only looks at the internal controls related to a business’ financial reporting. SOC 2 on the other hand, focuses on internal controls not related to financial reporting but rather on security best practices, which are the TSPs mentioned above.
SOC 3 is much like SOC 2, but the report does not list the details of what internal controls were examined. A SOC 3 report is intended to be publicly accessible for anyone who wants to confirm an organization is compliant.
Each TSP has criteria, which define all matter of controls must be in place. The criteria for the security TSP are considered a common criteria, and therefore apply to all TSPs.
It is important to note that only a CPA firm can formally certify an organization as SOC2 (or SOC1/3) compliant. Also, unlike PCI and other standards which encourage organizations to use the same firm for remediation help and certification, the AICPA has much stricter guidelines. They consider it a conflict to use the same firm for advisory services and certification.
On the Road Again
So what does it take to be SOC2 compliant? Like all compliance efforts, there is a lot to consider. The primary issues you will face include:
- Determining exactly which service offering(s) you want to make compliant
- Defining the scope of the audit (or “examination” in SOC 2 parlance)
- Deciding which Trusted Service Principles (TSPs) apply to you
- Mapping your existing controls to the TSP criteria
- Implementing any controls you do not have
- Preparing for the SOC audit
Let’s walk through each of these issues and their ramifications.
1. What Service Offerings?
The first step is to define what service offering(s) you want certified. This may seem trivial, but the ramifications of this decision are far reaching. The first big question you should ask is, who will want a SOC2 report from you? Is this report going to a client as part of a contract or SLA agreement, or is it going to a business partner who may need it as part of their audit? It is important to think about where your business is going and who may demand this certification.
Each service offering you add to your compliance efforts adds complexity and cost. And, if your customers only require one service to be compliant, then it would be unnecessary to certify the others. However, sometimes it is easier to certify everything and create uniformity across your business. However, you will have to maintain the controls moving forward.
2. Define the Scope
Once you have settled on the service offering(s), the next step is to determine what constitutes the scope of the audit. In other words, what is relevant and in scope for the services you are making compliant.
This is a good time to engage your IT/IS team to help identify the systems (networks, servers, switches, etc.) the target services use. The narrower the focus, the less systems you must make meet the criteria. You and your team must look at these systems as they are defined in the AICPA Trust Principles and Criteria documentation.
3. Decide which Trusted Service Principles (TSPs) are Applicable
After the scope is defined, the next step is to decide which TSPs are applicable to your organization’s systems. A common mistake is to assume you must comply with all five. In fact, the AICPA gives you the flexibility to decide which ones based on the scope and service offering(s). However, at a minimum, we recommend you comply with the Security trust principle. This provides a baseline assurance to your clients and partners that their information is protected from unauthorized access.
To validate your scope and TSP selection, some other considerations are:
- Are there any service level agreements or contracts made between the client(s) and the service organization, such as uptime availability and acceptable downtime? If so, then availability should be one of your TSPs.
- Are there different levels of data classification the service organization needs to consider, such as restricted, confidential, and unrestricted when dealing with a client’s data or their own? If so, then process integrity and confidentiality may be relevant.
- Will the service organization collect, use, retain, and disclose any of their client’s private information to third parties? If so, then privacy would apply.
Once you have decided on which TSPs are applicable to your systems, the next step is to dig into the details.
4. Map and Gap
The next step is to map your existing environment against the relevant TSP criteria. This is a gap assessment. Of course you can perform this yourself, or engage an experienced advisor (like Anitian) to help with this process.
The ultimately goal of the gap assessment is to determine what gaps exist, and what exactly you must to do close those gaps. This includes purchasing new equipment, hiring staff to implement those controls, writing documentation, and many other details. The ideal gap assessment lays out a road map for meeting compliance requirements.
5. Remediate Gaps
This is probably the most time-consuming of all efforts. As mentioned previously, the amount and level of efforts and resources from the gap analysis will determine the date of the SOC 2 audit. Historically, in our experience, if your organization is doing this “from the ground up,” you will need 6 to 12 months to implement all the required controls.
Of course, this is highly dependent on several factors, such as the number of gaps needed to be remediate, available personnel to do the remediation, any new equipment needed, the timeline established to remediate findings, and of course management’s ongoing support and involvement.
In our experience, this is where many companies become mired down. To keep things on track, focus on procuring and implementing the required controls first. This includes buying technologies like firewalls and SIEM solutions. Get these controls working. Second, integrate these new controls into your operational practices. Make sure you have good reporting and administration of the controls. Lastly, document the relevant policies and procedures around those controls.
6. Audit Prep
Once the remediation is nearing completion, the next step is to engage a CPA firm. Anitian strongly recommends a CPA firm where you have a strong relationship. The more involved your CPA is with your business, the more likely they will be able to understand the nuances of your implementation. Furthermore, if you work with a consulting partner to implement the controls, they too should have a relationship with the CPA firm. The closer your consultants are to the CPA, less likely the two groups will disagree. Keep in mind that a consulting partner or value added reseller (VAR) can tell you one thing, but at the end of the day, it is the CPA firm who signs the audit.
Some other key ways to prepare for the audit:
- Have the CPA firm conduct a readiness assessment? Many firms require this, to ensure you are on track.
- Compile all your relevant audit artifacts into a common repository. A SharePoint site or similar sharing tool are ideal.
- Be prepared for the audit period. SOC2, like many formal audits, requires a formal period where you must have all compliance criteria in place. For SOC2, the minimum audit period is 6 months. Which means your controls must be running and auditable for 6 months before you can get certified.
Conclusion
If you are on the road to SOC2 compliance, it may seem like a long, endless journey. However, like any compliance initiative, it is attainable if you break up the driving into more reasonable stretches. Moreover, there are many ways to share the efforts for SOC2 compliance with other frameworks, such as PCI and ISO. Lastly, when you make compliance an everyday business practice, the road will not seem as long and will be easier to drive as time passes.
Click Here for additional information on the TSPs
