How to Use SOC 2 Reports from Vendors and Suppliers

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.

1. 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.
2. Confidentiality: Controls to identify, manage, and dispose of / destroy confidential information (not personal information).
3. Processing Integrity: Controls to ensure that system processing is accurate, timely, and valid.
4. Availability: Controls to ensure information and systems are made available and accessible at all times.
5. 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 recommend 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 a 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's SOC 2 Exception Analysis Service:

• Reviews a complete SOC 2 report submitted by your vendor in lieu of an assessment. This saves time from your team needing to review the lengthy auditor’s report for each vendor.
• Conducts a brief contextual interview to understand the needs of the business owner relative to the SOC 2 report submitted by the vendor.
• Summarizes key findings and recommendations based on the scope of the service, the SOC 2 report, and each domain area in a consistent and easy-to-consume format. This empowers your team to have the right guidance at the right time from IT security and risk management experts.
• Identifies any missing control criteria considered appropriate. As part of the exception analysis, our experts identify any controls that should be included within the SOC 2 report that currently are not. This will help you close control gaps.
• Advises on the suitability of SOC 2 and guides any remedial actions. Remediation and suitability guidance improves security and helps to protect against third-party security risks.
• Maps SOC 2 control criteria to SIG Lite or the Prevalent Compliance Framework (PCF), to enable your vendor risk management team with a consistent approach to assessing the security risk of doing business with the vendor.

Ready to get started?

For more on Prevalent’s SOC 2 Exception Analysis Service, download the datasheet or request a demo to schedule a strategy discussion today!