SOC 2 Explained

What is SOC?

SOC is a reporting framework, published by the American Institute of Certified Public Accountants (AICPA), aimed at giving CPAs a framework through which to perform audits and produce reports that can be used to provide assurance on service organisations.  The SOC framework is split into 3 different reporting options:

• SOC 1:  Applicable specifically to service organisations that are involved in services or functions related to financial reporting.  SOC 1 audits / reports are almost always initiated by a client company’s financial audits, so if a client has not requested a SOC 1 report, you most likely do not need one.
• SOC 2: These reports are concerned with service organisations’ information security controls, and involve a CPA auditing against a selection of up to 5 trust service criteria or ‘TSC’ (more on this below).  It is the most common reporting option of the 3.
• SOC 3: Unlike SOC 1 and SOC 2 reports, which cannot be publicly published, a SOC 3 report is a general use report and can be provided to anyone.  They are not particularly common, but they are available as an option.  SOC 3 reports deal with a similar subject matter to SOC 2, but do not include a description of your organisation’s system, or of any tests of controls and the results of any tests that may have been performed.

In this blog, we will be focusing on SOC 2 from a service provider perspective.

‍

‍

What is SOC 2?

One of the key things to note about SOC 2 is that it is an attestation, not a certification, and there is no concept of a SOC 2 ‘pass’ or ‘fail’.  The output of the audit is a SOC 2 report, which you will receive regardless of how closely your information security controls align with the framework’s requirements.  The CPA firm performing the audit will, however, provide an opinion on this assertion; if there are significant issues and findings raised during the audit, you may receive a ‘qualified’ report, and, if there are no significant issues, you will receive an ‘unqualified’ report.

As mentioned above, SOC 2 reports are not intended to be public facing.  You can only share a SOC 2 audit report with specific interested parties, such as current clients, prospective clients, and auditors.

Who does SOC 2 apply to?

If the services provided by your organisation involve collecting, processing, transmitting, storing, organising, maintaining or disposing of client organisations’ information, you may be required to undergo a SOC 2 audit.  In URM’s experience, the need for a SOC 2 report is most commonly driven by an existing or prospective client request.  They are also a common requirement when conducting business in the US.  As such, the majority of organisations that have historically undergone a SOC 2 audit have either been organisations operating in the US, or those that have been looking to expand into the US market.  However, there is a growing number of companies outside of the US that are listing a SOC 2 report as a requirement for suppliers and service providers.  

Do you need to have a SOC 2 report to expand into the US market?

Whilst a SOC 2 report is not compulsory to operate in the US, it will often be necessary if you are looking to build a reasonably-sized presence in the US market.  Meanwhile, if you are hoping to work with larger US-based companies and/or federal government-based organisations, you will, in all likelihood, be expected to have a SOC 2 report.  

Why is SOC 2 increasing in popularity?

The fundamental reason behind the growth of SOC 2 reports’ uptake is that they quite simply provide the necessary assurances which clients require.  SOC 2 reports are immensely detailed, covering all the technical details of the services you are delivering as well as the information security controls you have in place, and all follow a very consistent structure, meaning that anyone who needs to read your SOC 2 report will know what to expect.

Meanwhile, all SOC 2 audits are conducted by a CPA firm that specialises in auditing IT and business process controls.  Such firms are very well-respected and recognised, and enhance the level of assurance provided by the framework.  Having a SOC 2 report will also help to leave prospective/existing clients with a positive impression of your organisation’s governance and ethics, and that well-managed information security controls are in place.

It is also not uncommon to see a ‘chain’ of SOC 2 reports.  If an organisation is asked to undergo a SOC 2 audit, this will very often prompt it to consider whether it should also be receiving the same assurance from its own service providers, thus exponentially increasing the number of organisations that receive requests for SOC 2 reports (to learn more about managing information security risks in relation to suppliers, read our blog on How to Conduct Effective Supplier Information Security Risk Management).

‍

What is a typical SOC 2 report scope?

Scoping is often one of the most significant challenges organisations initially face when they are considering undergoing a SOC 2 audit.  For many standards and certifications, such as ISO 27001, you are typically expected to certify your entire organisation, or a key branch of your organisation.  The scope of a SOC 2 report, however, is limited to the delivery of specific services, which involve processing, storing, and handling client data.  For example, if your organisation offers a number of services and was looking to launch a few of these in the US, but the others were only relevant to the UK/EU market, there would be no issue with you only conducting a SOC 2 audit on the services going to market in the States.  Similarly, if only one of these few services had clients requesting a SOC 2 report, you could undertake a SOC 2 audit purely on that single service, as long as you have clarity around precisely what the service is, so that you and your client are on the same page in terms of the report’s scope.

These elements are termed the system in SOC reporting, and your SOC 2 report is aimed at assuring the system that delivers your service.  The system comprises everything you do and utilise to support the delivery of the in-scope service(s), e.g., how the service is developed, how it is technically secured, the back-office functions that support the service, the personnel who develop, deliver and secure the service, etc.  However, as well as these service-specific aspects, the system will also include wider, governance-related elements, for example, information about HR processes, how risk is managed, and how communications are managed.  

Are your own suppliers and service providers in scope of your SOC 2 audit?

You will need to consider and discuss with your SOC 2 auditor all of the aspects that are supporting your service, and this includes those you have outsourced to a third party.  Any third parties you utilise as part of the delivery of your service that are either fully or partially responsible for your information security controls will be termed a ‘subservice organisation’ in a SOC 2 context.  These subservice organisations will need to be identified within your SOC 2 report, along with the SOC 2 criteria and the information security controls they are responsible for.

When you are looking to determine exactly what controls a subservice organisation is responsible for and how it fulfills your requirements for those controls, the most straightforward scenario will be if they have their own SOC 2 report, which can be used as evidence.  However, this is not compulsory, and if the subservice organisation in question has an ISO 27001 certification, for example, you can utilise information around this certification and the controls they have in place to maintain it for your SOC 2 report.  Ultimately, you will be looking to specify how the subservice organisation fulfills the relevant requirements from the SOC 2 framework.

What are SOC 2 Type 1 and Type 2 reports and which do you need?

This is another element of SOC 2 that can present challenges and lead to confusion, particularly for organisations that are in the process of obtaining their first SOC 2 report.  If you are going to receive a SOC 2 Type 2 report, the auditor will be assessing your information security processes and controls, and how they have operated, over a specified period of time.  It is not enough to simply demonstrate that you have a strong set of policies and processes; you will also need to demonstrate that these policies and processes have been operating consistently and effectively over a defined time period.  When the SOC 2 Type 2 report is produced, there will be a large section specifying how the auditor has validated the operational effectiveness of your controls and processes.

A Type 1 report, on the other hand, covers the same areas as a Type 2 report (the same scope, and the same processes and controls), but won’t test the operating effectiveness over a specified period of time, and will instead consider the controls and processes at a specific point in time.  A useful example to illustrate the difference between these 2 report types is change management.  In a Type 1 report, the auditor will look at your change management policy and process, and some examples of change requests that you have provided to them.  In a Type 2 report, the auditor will look at the same documentation as they would for a Type 1 report, but will also request a list of all the change numbers you have actioned within the reporting period.  They will then take a sample from that list and validate that each of the items in the sample conform to the policies and processes you have defined.

‍

‍

It is a common misconception that a Type 1 report can be used as a ‘stepping stone’ to a Type 2 report if an organisation wants to gradually introduce SOC 2.  This is not the case, and a Type 1 report should only to be used in 2 very specific circumstances.  If you have only had your information security control framework in place for a short period of time, or if your organisation has fundamentally changed in some way (e.g., it has experienced a restructure), a Type 1 report will be appropriate as you will not be able to demonstrate operating effectiveness over a significant time period.  So, if you have a specific date by which you need a SOC 2 report, but you will not be able to demonstrate operating effectiveness by that time, then you will need a Type 1 report.  However, it is quite likely that the client requesting the SOC 2 report will ask why you are unable to demonstrate operating effectiveness, and a desire to ‘ease into’ SOC 2 will not be a sufficient response.

How long is the SOC 2 Type 2 reporting period?

For an initial SOC 2 audit, there is a degree of flexibility in the reporting period.  The reporting period does, of course, need to be long enough that operating effectiveness can be demonstrated and validated.  Typically with audit organisations, 3 months is the shortest time period that they will accept for an initial report, and a 6-month reporting period is also common.  The ideal reporting period for your initial report will be 12 months, as a longer reporting period provides greater assurance.  However, if you do not have 12 months’ worth of evidence to provide to your auditor, it is very common for organisations to have a 3 or 6-month reporting period for their initial report.  

Generally, SOC 2 auditing is an annual process.  As such, once you have your initial report in place, subsequent reports will need to be produced 12 months afterwards covering the 12 months since your previous report, and clients will expect there to be no gaps between reports.

‍

What are the SOC 2 Trust Service Criteria?

As mentioned above, SOC 2 is structured around 5 Trust Service Criteria (TSC), and within these TSC there are sub-criteria and points of focus.  Of the 5 TSC (security, availability, processing integrity, confidentiality, and privacy), the only mandatory one is security.  This is the largest TSC, and covers a number of aspects including governance, risk management, access management, and how you secure and validate the security of your services.  In many ways, it is quite similar to an information security management system (ISMS) and the key control areas from ISO 27001.

The other 4 TSC are optional and can be selected by your organisation based on the type of service being audited, and on the expectations of your clients.  

‍

‍

Availability looks to assure that you are able to fulfil your commitments around the up time and availability of your service(s).  If you are delivering SaaS to your clients, for example, it is very likely that those clients will have expectations around how the appropriate availability of that service is ensured, and availability would therefore be a valid TSC for you.

Processing integrity will be relevant if you are delivering a service that involves processing a client’s data, i.e., client data is input into your service and an output is produced from that processing.  Processing integrity covers areas such as data flow and how you are validating inputs and outputs, and is concerned with how accurate, complete, valid, timely and authorised your system processing is.

Confidentiality is concerned with the controls you have in place to manage the confidentiality and availability of information, and is often based on contractual obligations around managing the confidentiality of your client’s data.  It will relate to aspects such as your information classification and handling policy.

Privacy fundamentally relates to services where personally identifiable information (PII) is being handled, i.e., individuals’ personal data.  For this TSC, your privacy policy, and your controls around access to PII will be relevant.

What is the structure of a SOC 2 Type 2 report?

As stated previously, SOC 2 reports follow a very specific and consistent structure.  Type 2 reports are broken down into 4 key elements, the first of which is the auditor’s report.  Here, the auditor will detail what they have done and their opinion of your system and service(s).  Following this, there will be an attestation letter from your senior management, confirming that all the information provided during the audit is accurate reflection of what you have been doing, what you are currently doing, and what you will do in the future.  The third element is a description of your ‘system’, and the final element is the auditor’s tests of the operating effectiveness of the controls.  

What is included in the ‘system description’ of a SOC 2 report?

The ‘system description’ element of a SOC 2 report is divided into 2 sections:

Overview of Operations

• Company Background
• Description of Services Provided
• Principal Service Commitments and System Requirements
• System Components
• System Boundaries

The Control Environment

• Control Environment
• Risk Assessment Process
• Information and Communications Systems
• Monitoring Controls
• System Changes Since Last Review
• Incidents Since Last Review
• Subservice Organisations
• Complementary User Entity Controls.

These 2 halves of the system description reflect the 2 aspects of the SOC 2 audit and report.  On the one hand, SOC 2 looks at the detail of your information security processes and controls, and how you are maintaining the security, availability, processing integrity etc. of your service(s), which aligns with the Overview of Operations.   However, SOC 2 also looks at your organisation more broadly, which is reflected in the Control Environment section.  For example, the ‘Control Environment’ point within the wider Control Environment section of the description references the ethics of the organisation, such as whether you have a code of conduct and code of ethics within your organisation, how you implement these codes and ensure that personnel follow them, and how you manage your employees in terms of training and performance reviews.

‍

If you have developed an ISMS which fully conforms to the requirements of ISO 27001:2002, you will find this an excellent starting point for a SOC 2 report as there is a lot of overlap between the 2 frameworks.  As a very rough ‘rule of thumb’, having a fully ISO 27001-conformant ISMS represents 75% of what you will need to achieve a successful SOC 2 audit.  Where extra effort will be required will be in ensuring that you are able to fully evidence the effective operation of your information security controls over the required reporting period, and in ensuring that you have appropriate processes and controls in place for the areas of people management, organisational governance and communication that are not included in ISO 27001.  To learn more about the relationship between SOC 2 and ISO 27001, read our blog on ISO 27001 vs SOC 2 – Part 2.

A SOC 2 Type 2 report is an incredibly valuable asset, particularly for organisations looking to work with clients that operate in the US.   Whilst there is often a fairly significant amount of preparation required for a successful SOC 2 audit (although less so for those with an ISO 27001-conformant ISMS already in place), an unqualified SOC 2 Type 2 report is the ultimate form of information security assurance for prospective and existing clients due to its level of detail and focus on operating effectiveness.  As such, a SOC 2 report will allow you to fully meet client information security requirements, making an annual SOC 2 audit a wholly worthwhile exercise.