The reason we have auditors today is simply because people do not trust one another. Let’s say financial statements reveal $1 million in net profit. If you are a shareholder, do you believe this? Is it less, or is it more? Do we trust the chief financial officer?
So, if an organization uses a Software as a Service (SaaS) provider or outsources elements of IT, the organization (being the client) would often raise the concern, “Is our information secure?” This is often followed by a more difficult question, “How do you know?”
SaaS and IaaS (Infrastructure as a Service) or cloud solutions have matured over the years. Economic conditions have resulted in many organizations seeking to increase efficiencies and decrease costs through outsourcing some of their services. So, the above two questions require answers, and if an organization is competing on a global scale or has plans to grow into a global competitor, these questions will need to be answered from a compliance point of view.
Why do you need a SOC 2 report?
SOC 2 compliance has increasingly become a “must-have” for organizations. Organizations may be more familiar with the SOC 1 report (also called ISAE 3402, SSAE 16, or formerly SAS 70). This is a report on controls that impact the user entity’s internal controls over financial reporting and are typically used in support of the audit of a client’s financial statements. The SOC 2 report, however, follows the same approach but is focused on the controls over IT or more, specific, controls over the SaaS or IaaS.[1]
The SOC 2 reporting standard is an audit opinion report over internal controls related to information technology. It is based on the AICPA’s Trust Service Principles of security, availability, process integrity, confidentiality, and privacy.[2]
It is key to note that the organization cannot outsource the risks around IT. The organization should protect the information of their business and customers, even when using a service organization. A SOC 2 report will assist by assuring the controls are in place at the service organization. The organization may want to make a positive SOC 2 report part of the contractual agreement between their organization and the service organization, demonstrating information security compliance.
The benefits of a SOC 2 audit include:
-
An edge over competitors, as demonstrating an official SOC 2 report confirms just how serious an organization is about protecting customer data and the security of its systems and procedures.
-
An organization can break into new markets, especially with United States customers, as SOC 2 is highly recognized in this region.
-
The service organization can undergo one audit and distribute the report to multiple customers, reducing the time spent with individual auditors.
-
The Trust Service Principles relate directly to the core service obligations and commitments of IT, cloud, and hosting providers, including SaaS services.
-
Staff throughout the service organization gain improved insight into risk, governance, and internal control.
-
Independent assurance over the controls operated by third-party service organizations.
-
A comprehensive report of the processes and controls in place at the service organization.
-
Clearly articulated controls that need to be performed by your organization when working with the service organization.
-
Insight into control gaps as highlighted in the report or rather areas of improvement.
You are probably thinking to yourself now, “How do we do it?” There are a lot of stages in a SOC 2 process, but they can generally be broken down into the following six steps:
-
Consider finding a SOC 2 consultant or partner
-
Identify your scope
-
Perform the gap analysis
-
Gather evidence for each control
-
Perform the audit
-
Review the SOC 2 report
Consider finding a SOC 2 consultant
This step is optional but affects time and money spent. Making this decision comes down to two points: How mature is my control environment? What is my level of understanding of SOC 2?
A SOC 2 consultant can assist with obtaining a SOC 2 certification and maturing the control environment in the following manner:
-
Identifying and documenting controls or where controls are lacking
-
Designing and implementing the required controls
-
Analyzing the effectiveness of controls
-
Helping identify process and technology weaknesses
-
Identifying opportunities for improvement throughout audited operational areas
-
Determining the consistency with which controls are applied throughout the organization
-
Standardizing the processes among multiple services
-
Assessing the strength of management oversight
Identify your scope
Identifying your scope is a very important step to get right; it will be your blueprint for your SOC 2 project. The process by which an organization obtains a SOC 2 certification can be very flexible. As long as the specific criteria are achieved, the controls you “map” to each criterion are up to you as long as the control addresses the relevant criteria. More on the control mapping will be explained in the gap analysis step, but take into consideration these three steps, which are a great starting point to establish your scope:
The foundation of a SOC 2 audit is built on the five “Trust Services Principles”:
-
Security
-
Privacy
-
Process integrity
-
Confidentiality
-
Availability
Getting the foundation right for a SOC 2 audit is very valuable, so the first question is: which principles apply to our product/service?
That question might seem obvious, or some might want to include all principles just to be safe.
Let us consider what is at stake. If you include too few principles (or the wrong ones), your enterprise is in a state of under-assurance—not enough controls for the security risks your vendors pose. Conversely, if you include too many principles, the enterprise is in a state of over-assurance—too much mitigation (and wasted resources) for risks you do not actually have.
For example, let us look at assessing a cloud-based data storage vendor. If you are not storing any personal identifiable information with that vendor, you have no privacy risks. That means you can keep privacy out of scope. On the other hand, if you will be storing confidential product plans, your security risks are high.
So, the foundation of any SOC 2 audit is to understand what principles apply to your particular product.
Scoping partners
Another crucial step is to know who else in your enterprise should be involved in scoping a SOC 2 audit. Compiling that list is becoming more complicated because vendors increasingly provide more mission-critical services.
First, you will need to consult with the business process owners in the first or second lines of defense who will actually use that vendor. What service will the vendor provide? What company information will it touch? How do the employees want that relationship to work?
You will also need to consult with the IT security function because they are the subject-matter experts. They have insights about methods of attack, controls to test, and assurances that should be included in any final SOC 2 report.
As the experts on security and privacy obligations, compliance identifies the consequences of getting information security wrong—the regulatory fines, litigation liability, or regulatory measures.
For example, if you use a vendor to analyze consumers’ purchasing habits, and some of your customers are European citizens, then the European Union General Data Protection Rule (EU GDPR) applies. In that case, the GDPR principles of availability (to see all data upon request) and process integrity (to be sure “delete all” does delete everything) become crucial parts of your SOC 2 audit.
The type of the audit and the audit period
There are two types of audits to consider in a SOC 2 report: Type 1 and Type 2.
The different types of SOC 2 audits speak to the audit period. A Type 1 audit shows the design of the control at a point in time. Type 1 audits are often used if (1) the control environment is still immature and/or the controls have not been implemented for some time or (2) there are budget constraints.
A Type 2 audit looks at controls operating effectively over a period of time. This period can be anywhere from three to 12 months. A Type 2 audit expands more on the evidence but is usually more expensive.
Perform the gap analysis
Once we have the right foundation, we can now look if there are any cracks in the foundation. How do you know if you have any cracks? It’s simple. Gaps can be identified as controls that are not in place or are unable to satisfy a criterion. The SOC 2 framework gives you a couple of criteria, backed up by points of focus to help you get the right controls in place to satisfy the mandatory criterion.
For example: when one builds a house, the plan will read, “Insert a door here at X.” So, we insert a door here at “X.” Same concept. One of the SOC 2 criteria is logical access. A point of focus will be “Restrict logical access to unauthorized individuals.” How do we do that? Well, there are multiple ways to restrict access to unauthorized individuals. For example, consider implementing multi-factor authentication on all endpoints.
It is important to note that when performing a gap analysis for SOC 2, the organization should identify any gaps based on the relevant Trust Service Criteria for the scoping criteria relevant to the audit in particular. To successfully achieve this, identify all controls and processes relevant to the organization (based on the Trust Service Criteria scope relevant to the audit) and then perform a line-by-line review of this to identify any relevant gaps. Successfully executing the gap analysis process will set the organization for SOC 2 success.
Gaps identified can be regarded in three ways:
-
The control is designed but not implemented, i.e., the control is noted in a policy but is not working/being followed in practice.
-
The control is designed and implemented but lacks operating effectiveness, i.e., the control was not operating effectively during the period of review. For example: out of 100 changes, only 80 have code reviews.
-
A control was not in place, i.e., there was not a control in place to address the relevant SOC 2 criteria. For instance, SOC 2 requires a user access review to be performed—this is not done by the organization.
The typical organization can expect to see several gaps in their information security procedures in places that they may not have expected. Learn about the most common SOC 2 gaps and assess your organization’s policies and procedures against them. Some of the most common SOC 2 gaps are:
-
User access reviews
-
Security awareness training
-
Risk assessment
-
Third party penetration testing
-
IT assets mapping and classification
-
Company policies
Conclusion
For Part 1 of our beginner’s guide to SOC 2, we have broken down the first three key steps of the compliance process: finding a suitable SOC 2 partner to provide expert advice; identifying your audit scope specific to your organization’s operations; and performing a thorough gap analysis and remediation. In Part 2, the remaining steps of SOC 2 compliance will be explained.
Takeaways
-
Organizations cannot outsource the risks around IT.
-
An official SOC 2 report can give an edge over competitors by demonstrating how serious your organization is about protecting customer data.
-
The process for SOC 2 certification can be very flexible, so it is essential to properly identify your scope.
-
A Type 1 audit shows the design of the control at a point in time; a Type 2 audit looks at controls operating effectively over a period of time.
-
Identify all controls and processes relevant to the organization and perform a line-by-line review to identify any relevant gaps.