December seems to be a month fixated on fancy footwear. On Christmas Eve, some of us will “hang stockings by the chimney with care.” On December 4, a few of us celebrated the fringe awareness event “National Sock Day” commemorating “those rarest of socks that manage to stick together.”
For Risk Management, the very mention of “Sock” inspires thoughts of SOC reports. What are SOC reports? And what do SOC reports mean for risk management?
Service Organization Controls (SOC) reports are issued by an American Institute of Certified Public Accountants (AICPA) assessor. SOC reports are conducted by independent, third party auditors and managed as a standard by the AICPA.
Industries such as financial services and financial technology have traditionally used SOC reports to assure they have proper controls in place to protect financial data. Increasingly, a wider set of sectors are using the SOC reporting process. SOC reporting is designed to cover the gap between your critical data and your third parties.
There are three levels of SOC reports. In TPRM, SOC 2 reports are commonly used as a tool to verify that an organization has achieved the levels of controls within that type of SOC’s scope. SOC 2 Type II Reports and Shared Assessments’ Standardized Control Assessment (SCA) Procedure Tools, when used together, give organizations a very strong vendor security assurance package.
Three Levels of SOC Reports
SOC 1 Report
SOC1 reporting focuses on outsourced services performed on behalf of an organization that are relevant to the organization’s financial reporting.
A SOC1 report illustrates the relevancy of a service organization’s internal controls over reporting. These controls are related to the accuracy of financial data and IT controls.
SOC 2 Report
SOC2 measures the effectiveness of the operational controls implemented by a service provider. Based on selected trust services criteria (TSC) are control criteria utilized to evaluate and report on the suitability of design and operating effectiveness of controls relevant to the Security, Availability, Processing Integrity, Confidentiality of an organization’s data and systems.
Similarly, SOC3 like SOC2 serves the same purpose, but not to the same depth of scope.
Left SOCK vs. Right SOCK: SOC 1 Type I vs. SOC2 Type II
A SOC 1 Type I Scope addresses the design of controls in place at a point in time. A SOC2 Type II Scope addresses the operating effectiveness of controls over a period of time.
SOC 2 Type II Reports and Third Party Risk Management
The size of your vendor portfolio and the size of your company will impact the percentage of vendors who provide SOC 2 Type II reports (or ISO 27001 reports) as artifacts for 4th party validation.
The percentage of 4th parties who provide artifacts is around 25% – fairly low. Because you have no contract with the 4th party (it is the responsibility of your vendor), you typically request that your third party assessment reference the due diligence your vendor performed on their own third party. Your vendor’s assessment of their third party may or may not include the ISO 27001 or SOC 2 type II report.
Since the vendor holds the contract, the vendor has the responsibility to you, their client, to verify that their third parties have implemented best practices, maintained regulatory compliance, and are upholding the terms of their contract.
It becomes necessary to review the 4th party artifacts when the services they provide could directly impact your organization. These tend to be higher-risk vendors that would impact your organization.
Most organizations have clauses in their contracts around the use of 4th parties and what is required for due diligence.
SOC 2 Type II Reports and Shared Assessments
If a SOC report does not include a third party risk module (a new requirement to the SOC this past year), Shared Assessments’ Standardized Control Assessment (SCA) Procedure Tools can be used to strengthen your security assurance approach with vendors.
An attestation tool, the SCA is particularly useful for virtual assessments. SCA supplies fact-based and objective testing of control attributes as part of the “trust but verify” process in third party risk governance. The control structures in the SCA include 18 critical control domains used in assessing vendor risk and corresponding controls. These are the same 18 control domains from the SIG – a mirror if you will – allowing for the building of a robust Security Assurance Package provided from the vendor to the client.
In risk management, both the SCA and the SOC shoe fit. Now, let’s get to stuffing those stockings!
Learn more about the SCA and how it can be used in virtual assessments.