When assessing a third-party, is a SOC 2 report enough?

Editor’s note: NCC Group and Privva work together to help organizations improve their third party risk management (TPRM) processes, combining Privva’s vendor risk assessment platform and NCC Group’s professional services.

Many organizations widely accept SOC 2 reports in lieu of completing security assessments of their third parties. SOC 2 reports can often be complicated and difficult to align to the products and services provided by third parties so it’s important for organizations to ensure they have the appropriate personnel in security and/or risk management have specific domain expertise in SOC 2 reports. SOC 2 audits are not all equal and in reality, they have become an unchecked commodity market.

Having a SOC 2 does not mean the organization or product is without risk. For example, a validation process is not in place to ensure SOC 2 audits are completed in alignment with AICPA (American Institute of Certified Public Accountants) requirements. Therefore, the breadth and detail of assessments completed for a SOC 2 audit range significantly. Even the cost for a SOC 2 audit can differ by more than $100,000 for the same assessment and there is not always a correlation between cost and quality.

There are several considerations which must be understood in order to determine if a SOC 2 report is sufficient for your third-party assessment. We recommend that you consider these two focus-areas when determining if the SOC 2 report is sufficient for identifying third party risks to your organization: 1) full assessment of the SOC 2 report, and 2) reviewing the CPA firm who completed the audit.

Reviewing the SOC Report

What type of SOC report is your organization accepting in lieu of a security assessment?

SOC 1 reports, which cover internal controls for financial reporting, are still being accepted as appropriate evidence, but are not very relevant to third-party security. SOC 2 audits are preferred, however organizations frequently don’t understand the difference between SOC 2 Type 1 and Type 2 reports. Type 1 audits confirm design effectiveness which demonstrate the control can operate as designed. Type 2 audits prove operating effectiveness and provide assurance that the control was operating as intended over a period of time. A SOC 2 Type 1 may be appropriate for a low risk organization or small startup, who are completing their first audit, however it is highly recommended to leverage the SOC 2 Type 2 report.

Are you even receiving the full SOC Report?

From our experience, we’ve seen many organizations simply accept a SOC 2 attestation instead of requesting the full report for review. This may acceptable if you are also receiving a completed questionnaire that outlines security controls but does not provide enough information to accept alone. The report outlines key elements of controls, time, and scope that are required to accurately understand the third-party’s security position. As part of the report, auditors grant opinions which are normally Unqualified, Qualified, Adverse, or Disclaimer of Opinion. A Qualified opinion for example indicates that the third-party mostly passed the audit but had some control gaps. Without the report, you would never be able to assess and fully understand the impact that single gap could have on the services provided to your organization.

Are you validating the scope of the SOC report against services provided?

The “Description of the System” section captures the scope of the audit however; many organizations don’t read past the first page. SOC 2 reports can have a broad scope that perhaps covers the entire organization or a scope that is too narrow and doesn’t tie to the business processes and/or products being provided to your organization. In addition, the scope could be limited by the service organization not to include the sub-service organizations. As such, it is critical to validate the scope of the SOC 2 report to verify it covers the relevant scope of products or services provided to your organization.

Part 2: Reviewing auditor, the audit quality, and overall validity

Which control framework is being used to validate your Trust Service Principles (TSP’s)?

Not every SOC 2 audit is created equal. SOC 2 is a reporting framework, and the TSP’s are audit criteria which must be applied to a control set. Some CPA firms will leverage their own, custom control framework as opposed to leveraging the industry accepted mappings provided by the AICPA. Without transparency on the control set used during the audit, the completeness of the audit may be in question. If the CPA firm does not identify the authoritative source leveraged for the control framework, then you should request this evidence from the third-party.

Who completed the readiness work for the SOC 2 audit?

The road to achieving a SOC 2 report can be long and expensive. Organizations may not have the internal expertise to prepare the organization for a SOC 2 audit. There is no issue with using a third party for readiness efforts, so long as independence requirements are met. We have observed cases where the same organization is both developing/implementing the controls that are being tested, resulting in a conflict of interest. Asking the third-party who was responsible for the readiness function and who completed the audit is important to rule out any conflict issues.

Was the auditor qualified to perform the audit?

As with any auditor, the auditor’s skill set and background/education varies. Though you are not likely able to reach out to the auditor for a CV, we have found some easy ways to check the knowledge and experience of the auditor based on the SOC 2 report. One of the easiest indicators is a focus on the risk management requirements (Common Criteria 3.0 controls, COSO principles 6 – 9). A review of these testing criteria should identify a method where inherent risks were captured utilizing threat, vulnerability, impact and likelihood, specifying risk treatment strategy and determining residual risk after the controls assessment. We have found that auditors tend to assess controls instead of risks and/or look at vulnerability and likelihood, but tend to miss threat and impact. As a more concrete example, if the auditor cannot demonstrate how fraud (CC 3.3) was taken into consideration during the risk assessment, they may not have a strong security background for assessing the controls.

Conclusion

A SOC 2 based third-party risk assessment process may be easy to deploy, however, organizations rarely take the time to fully read and understand the report. Not to mention consider its validity and ensure there was not a conflict of interest involved during the audit process. For these reasons, we highly recommend using the SOC 2 report as a supplement to a comprehensive security assessment questionnaire when assessing your third parties. This dual approach allows you to see a full picture of their technical and policy driven security controls in addition to the results in the audit report. Leverage the questionnaire to ask specific pointed questions on controls and then expand the questions to ask for details on the SOC 2 report as well. A comprehensive third-party risk assessment program should use multiple elements to build and assess the risk posed by each third-party.