Updated: Sep 20
What is SOC Reporting, Who Needs It and How Does It Work?
If you’ve read movie reviews, you know the writer will give a high-level overview of the plot, characters and general production quality of the film…but not delve into the details about how the director created every shot.
This post is intended to provide that introduction for SOC2 reporting. It deliberately avoids the technical aspects and focuses on the practical side to answer the types of questions raised by non-SOC2 practitioners. Leave your comments, questions or criticisms in the comments section below.
What Is SOC Reporting?
Service Organisation Control (SOC) reporting is the process of using established standards to report on the appropriateness and effectiveness of a service organisation’s internal controls. The purpose? To provide that report to third parties who rely on that organisation.
A key difference between SOC and many other optional reporting standards is that SOC reporting requires an independent audit. A service auditor must sign off on the report to confirm it is fairly presented, and that controls are in place and designed effectively. For Type 2 reports (explained below), the auditor must also confirm these controls have operated effectively over a period of time.
There are three types of SOC reports you’ll hear about:
• SOC 1 reports: Focused on financial reporting objectives, and primarily used by third-party auditors to be able to sign off the end users' financial statements.
• SOC 2 reports: Focused on Principles for the controlled use of technology and protecting customer data.
• SOC 3 reports: A redacted version of the SOC 2 report that can be made public.
What Are the SOC 2 Trust Services Principles?
A new approach in the SOC 2 standard that wasn’t used in SOC1 reports is the concept of “Principles”. These Trust Service Principles act in a similar manner to the “control objectives” in SOC 1 reports, which determine the scope and focus of the report.
The Principles/control objectives are the areas that will be assessed to provide the third party assurance. (Remember, this assurance is the entire point of SOC reporting in the first place). The Security Principle, which is required for all reports, is included to provide third parties with comfort that the service organisation has controls to secure its system and data from unauthorised access.
The minimum-level SOC 2 report includes a set of common criteria applicable to all organisations, as well as the Security Principle. Beyond this, there are optional Principles that can be added depending on the service organisation’s requirements. These include Availability, Processing Integrity, Confidentiality and Privacy.
Within each Principle is a set of criteria, which are like a qualitative set of internal control requirements that are expected in all organisations. For example: Does the organisation have defined and communicated roles and responsibilities?
The AICPA SOC 2 guide provides a corresponding set of “risks” and “illustrative controls” against each criteria to clarify what is expected and why. Criteria are designed to adapt to the specific nature of the service organisation, and can be excluded if they are not applicable or immaterial. The five Trust Service Principles are explained well by Kirkpatrick Price.
Who Is SOC 2 Reporting Relevant For?
SOC 2 reporting is optional. However, in the following circumstances, the benefits of SOC 2 reporting usually outweigh the costs:
1. Customer reliance on Security, Availability, Processing Integrity, Confidentiality and/or Privacy by many customers:
Where there is a high-level of reliance on these areas, customers are likely to require assurances over the service organisation’s controls and risk management practices. The more customers this applies to, the greater the benefit of SOC 2 reporting — it's designed to meet all end users' assurance requirements in a single report.
2. Large institutional and highly-regulated financial services customers:
Organisations with these customers are usually subject to increased scrutiny from their customers, who have rigorous compliance and vendor risk management programs. It's common for a company's pursuit of these clients to be the trigger point for commencing SOC 2 reporting.
3. Building trust with current and prospective customers:
For software as a service ("SaaS") and other tech organisations, SOC 2 is widely seen as industry best practice or the "Gold Standard". Thus, achieving SOC 2 builds trust that can assist in sales, onboarding and ongoing account maintenance.
4. Past failures:
Past failures that have attracted regulator and/or customer focus commonly trigger the start of SOC 2 reporting. In these cases, the organisation needs to demonstrate improvements that will prevent further occurrences, and a SOC 2 initiative can help.
5. Internal control improvements:
Unfortunately, this is rarely the primary driver of SOC 2 reporting. Still, the internal organisation can reap potentially huge benefits from undergoing SOC 2 reporting. An independent service auditor brings broad industry insights, challenges the design and operation of processes, and provides transparency of internal operations and controls. This leads to both process improvements and internal controls assurance for management and the Directors.
What’s the Difference Between Type 1 and Type 2 Reports?
Put simply, Type 1 is like a photo and Type 2 is like a movie. Type 1 reports over the controls at a single point in time, to attest that the controls are in place and designed appropriately to meet the SOC 2 standards. This is similar in nature to an ISO 27001 certification.
Type 1 usually forms the starting point of a Type 2 report, which covers a period of time and attests that the controls were in place, designed appropriately, AND operated consistently at a SOC 2 standard level throughout the period. The Type 2 report captures changes to processes and controls during the period, and is often held in much higher regard than Type 1 by end users. Typically a Type 1 report is issued first at a date which forms the starting point for the Type 2 report period, which then follows 6-12 months later.
How Do You Determine the Scope of a SOC2 Report?
The scope of a report is defined by:
• Principles selected and the corresponding criteria
• Business units, products, services and clients (the service organisation selects the relevant areas to be in-scope based on the end users’ requirements)
• IT systems and infrastructure relevant to the principles and areas in scope
There are requirements in the standards to prevent “cherry-picking” areas of scope. However, products, services and client types can be excluded from scope where determined reasonable by the service organisation and auditor. The main consideration of "cherry-picking" is whether the exclusion would be considered deceptive or unfairly presented to an end user. Read more in our post focused on SOC2 Scope.
What’s the Typical Approach and Timeline to Get a SOC 2 Report?
SOC 2 can be a long journey for some organisations. Starting early with a longer timeline allows for less business impact and a natural evolution of processes and controls. It can become increasingly difficult for organisations that have grown to a large scale without focus on their internal controls.
On the other hand, with a well-managed approach, buy-in from senior management and the right expertise involved, firms can also achieve SOC 2 in very little time. Within one calendar year, Qstream went through all four of the below phases to deliver a successful (unqualified) Type 2 report.
A typical approach can include:
1. SOC 2 Workshop: Starting with a high-level focus, identifying the scope and looking at the key areas and themes that need work. Addressing these first will help other parts fall into place and avoid the unnecessary costs of prematurely diving in.
2. Readiness Review & Remediation: Reviewing business functions within the SOC 2 scope to identify existing controls. Performing a mapping exercise to the AICPA criteria and identifying and remediating any control gaps that don't meet the criteria.
3. Type 1 Reporting: A service auditor performs an independent review to attest to the appropriateness of the controls at a specified reporting date. Management should be comfortable the controls are embedded at this point, as this often forms the starting point for Type 2 reporting.
4. Type 2 Reporting: A service auditor performs an independent review to attest to the appropriateness and ongoing effectiveness of the controls over a period of 6 months or more.
What Are the Main Areas Needing Work to Obtain a SOC 2?
The areas most prone to SOC 2 issues are:
1. Lack of documentation: The controls often exist, but there’s no documentation to demonstrate it to the service auditor.
2. Lack of established process: Different business areas and/or team members have the same objectives, but operate in different ways with no established “correct way".
3. Lack of consistency: This can include phrases like “we do X…most of the time”, “We would usually look at Y”, “It sometimes works like Z”. A control is only considered effective if it operates consistently in accordance with its design. Controls can be designed with variations or flexibility based on particular circumstances or decision making that fits the controls purpose, but that needs to be defined.
4. Conflict between SOC 2 requirements and what makes sense in practice for the organisation (cost vs. benefit and materiality considerations): This can lead to a lot of debate between the organisation and the service auditor to agree on an appropriate middle ground. The SOC 2 standard is flexible and in theory adaptable to what makes sense for the organisation, but the language barrier between auditors and tech firms can cause challenges here.
How Do You Choose a Service Auditor?
There are a broad range of service auditors for SOC 2 reports that can perform the attestation and sign the reports. As SOC 2 is a growing area which typically leads to long-term customers, the service auditors will often heavily discount their usual fees to "get a foot in the door". It is a requirement of the SOC 2 standard that they be a licensed CPA firm.
Having worked in the industry for most of my career, below is my view of the different categories of providers. This view is what led me to partner with A-LIGN, but it's obviously just my view.
There’s more variance between individual team members within these firms than between the firms themselves, so it's important to know exactly who you'll be working with and ensure it's a good fit.
• Big4 firms (PwC, Deloitte, EY, KPMG): Higher price, stronger brand, high quality requirements across all areas. Work is usually done by more junior staff who are not specialists in SOC2. Bigger firm size can allow more responsive and flexible resourcing.
• Mid-tier firms (BDO, Mazars, etc.): Similar to Big4 but likely lower price, less known brand, slightly lower quality requirements. The smaller size may provide a more personalised and responsive service than Big4.
• Specialist technology certification firms (A-LIGN, Coalfire, etc.): Lowest price, less known brand, risk-based approach to quality. Often ex-Big4 consultants who are more focused and specialised in SOC 2.
Thanks for reading, and I hope this introduction to the SOC 2 reporting and processes has left you with more knowledge about the SOC 2 area and how we work. For any further information, feel free to contact us through the website or request a free consultation.