How to Use SOC 2 Reports from Vendors and Suppliers

SOC 2 reports can simplify your third-party risk management program. Here are 7 FAQs to get you started!

By:

Thomas Humphreys

Prevalent Compliance Expert

August 17, 2022

What is a SOC report, and how is it used?

System and Organization Controls (SOC) is a set of IT controls standards developed by the American Institute of Certified Public Accountants (AICPA). SOC audits are performed by certified auditors, and reports are used to demonstrate how IT controls have been implemented to secure a company’s systems and information.

SOC audits are built to assess controls in five key areas, called Trust Services Criteria:

Security
Confidentiality
Processing Integrity
Availability
Privacy

SOC reports provide detailed assessments of an organization’s operations and systems, and their effectiveness. There are two types of SOC reports:

SOC 2 Type 1 Reports

Type 1 reports review the design of security controls, including procedures and processes. Type 1 audits are conducted at a single point in time.

SOC 2 Type 2 Reports

Type 2 reports review the operational effectiveness of the controls identified in Type 1 reports. Type 2 audits look at controls in depth and are conducted by auditors over a longer period of time – sometimes as long as six months.

This post focuses on SOC 2 Type 2 reports.

What do SOC 2 reports contain?

While SOC 2 reports can look different based on the auditor conducting the assessment, they generally include the following areas meant to identify the scope of the assessment and non-conformities, known as control exceptions.

Executive or auditor summary: Includes an overview of audit results, how the auditor conducted the audit, and some level of guidance indicating whether findings are more or less relevant.
Overview of organizational operations, processes and systems: Reviews the organization and its audit objectives.
Scope of the report: Examines the five Trust Services Criteria and supporting controls in scope for the audit. Sometimes, organizations choose to only focus on one or two Trust Services Criteria instead of all five, especially if some of the criteria don’t apply to them.
Control activities and auditor evaluation: Provides a deep dive into the itemized listing of controls, including testing conducted and test results.
Management response: Notes exceptions and provides a response detailing how the organization plans to manage exceptions.

The SOC 2 TPRM Toolkit

Get instant access to 3 essential resources, including a quick-reference eBook, an on-demand webinar on decoding SOC 2 reports, and a SOC 2 compliance checklist!

Access Now

What’s included in the Trust Services Criteria?

In a SOC 2 report, the Security Trust Services Criteria is always applicable, but most SOC 2 reports include just one or two additional criteria.

Security: Controls to protect against unauthorized access, disclosure of information, and damage to systems. Seeks to understand whether the company has a security framework in place and controls over logical and physical access.
Confidentiality: Controls to identify, manage, and dispose of / destroy confidential information (not personal information).
Processing Integrity: Controls to ensure that system processing is accurate, timely and valid.
Availability: Controls to ensure information and systems are made available and accessible at all times.
Privacy: Controls to protect personally identifiable information (PII).

Why use a SOC 2 report?

Companies use SOC 2 reports when they:

Are unwilling or unable to complete comprehensive IT controls assessments, such as for NIST or ISO, for themselves but still have to demonstrate control effectiveness
Use a standard that is well-understood and comprehensive
Have the flexibility to focus on a complete set of controls or just a subset

How do you interpret risks in a SOC 2 report?

A typical SOC 2 report will identify risks as “test results.” A typical SOC 2 Exceptions table looks like this:

Control # is a code for tracking each control throughout its lifecycle.
Criteria are descriptions of the controls as tested.
Control activity explains how the company currently addresses that control.
Test of operating effectiveness explains how the auditor inspected the control and what procedures were followed.
Test results specify if there was an exception and what the deviation was.

There is no grading of risks in a SOC 2 report, such as red/amber/green indicators of risk failures. This is where a third-party risk management platform can help!

How do you map SOC 2 control exceptions so you can centrally manage associated risks?

Translating SOC 2 control exceptions or test results to risks can be tricky without a way to centrally track third-party risks.

We recommending applying a “likelihood and impact” methodology to assign risk scores to any identified exceptions.

Likelihood estimates the probability of a third party’s control failure impacting your organization’s operations.
Impact estimates the level of disruption a control failure would have on your organization’s operations.

Using simple 0 to 5 scale, where 0 means no likelihood or impact and 5 means high likelihood or impact, you can create a heat map to quickly score and categorize risks.

Once risks are categorized into the heat map, you can define risk ownership, assign tasks, and engage with the third party for risk treatment and remediation.*

*Remember that the third party may have already addressed findings in the SOC 2 report Management Response section.

How can you simplify the process of tracking and remediating SOC 2 risks?

Start by developing a playbook for remediating SOC 2 exceptions based on:

Minimum/mandatory requirements: Identify what is absolutely required of third parties. If there is an exception in an area, then the third party is compelled to remediate it.
Best practices: Incorporate your firm’s expectation of how a risk or control exception should be remediated based on industry best practices.
Timelines: Set timeframes based on the severity of risks.
Decisions or resulting actions: Define what happens to remediated risks. Will you accept the remediation and lower the risk score based on your firm’s risk appetite, or will you close down the risk with no further action required?

Clearly state the requirement. If you expect further evidence, then specify when you need it. Also, confirm whether you require ongoing monitoring or remediation.

Leverage existing risk registers to map these control exceptions into what you already have. This approach helps you cross-map findings for compliance reporting against other frameworks.

Managing third-party risks – regardless of whether or not they were discovered via a SOC 2 report – is impossible without a central platform that automates risk identification, assessment, triage, monitoring and remediation. That’s where Prevalent can help!

Getting Started with SOC 2 Third-Party Risk Management

Prevalent can help simplify SOC 2 third-party risk management using solutions and professionals with SOC 2 compliance expertise. Prevalent SOC 2 Report Review Services:

Translate identified control deficiencies from SOC 2 reports into risks in the Prevalent Platform for ongoing management, reporting and remediation.
Transform complete SOC 2 reports into a standard format and provide summary contextual analysis to enable coordinated action on risks.
Interview auditors, third parties and internal stakeholders to pinpoint what is required to remediate risks and advise on next steps.

Ready to get started?

For more on Prevalent’s SOC 2 Report Review Services, download the data sheet or request a demo to schedule a strategy discussion today!

Tags: Compliance