As more organizations trade in-house IT applications, systems and related processes for third-party services to enhance capabilities, simplify operations and lower costs, it is critical to demonstrate that data and systems are well-controlled, regardless of where the data resides. While the COSO Internal Control – Integrated Framework clearly states that management is responsible for the design and operation of its controls over IT risk (including the controls that are outsourced to service providers), the burden of organizing the necessary assurance activities directed to the controls in place for outsourced processes and systems falls on service providers. For many, the service organization control report (SOC 2), issued by a service auditor, has become the assurance standard of choice — to the point that many organizations now contractually require vendors to provide annual SOC 2 reports.
A SOC 2 is an attestation report that provides control assurance over a defined set of the service provider’s systems. Each report covers a defined period of time (usually nine months), agreed to between the auditor and the service provider. The report encompasses between one and five trust services principles (TSPs), depending on the needs of the service organization. The five TSPs include security, availability, processing integrity, confidentiality and privacy. The security principle is one of the most commonly selected and is used to determine whether relevant systems are protected against unauthorized access, use or modification.
Deciding to obtain a SOC 2 report is not a one-time event; it requires an ongoing commitment of both management time and financial resources. Consistent execution of controls is critical and often requires significant remediation before an organization is ready to submit to the service auditor’s testing. Most service organizations have yet to develop the control frameworks and tools required to meet the rigorous SOC 2 audit standards. To assist in that process, Protiviti recently published a white paper — On the Road to SOC 2 Readiness, What Service Organizations Need to Know — available for free download from our website.
Getting ready for an initial SOC 2 audit can be an arduous process. It begins with developing an understanding of what is driving the need for a SOC 2 audit and what are the systems relevant to those drivers. It continues through a gap assessment and an iterative cycle of remediation and readiness testing, correcting control and process design gaps along the way until results fall consistently within an acceptable range of outcomes.
The scope of a SOC 2 report depends on the type of service a vendor provides, as well as the needs of its customer base. A thorough scoping should seek to determine for which TSP(s) customers will require assurance and which systems and components must be assessed to achieve the objective. A service organization can select any number and combination of TSPs for inclusion in the report, based on customer need and relevant contractual requirements.
In some cases, organizations may deem two or more TSPs to be relevant to their customers’ needs. In our experience, and depending on process maturity and culture, it is sometimes best to follow a staged approach, focusing on the most important TSP first and increasing the scope of the report over time. Organizations that attempt to address multiple TSPs as part of their first SOC 2 project increase the risk of disruption to normal operations, missed target dates and, potentially, a qualified initial report.
Given the critical importance of a positive report, and the potential reputational and economic consequences of a negative one, service organizations are turning to outside consultants to help them prepare. Service organizations should work with their advisers to determine the best approach that fits the needs of their customers, as well as their own organization.
More than just an IT exercise, SOC 2 readiness should be viewed as a company-wide opportunity for service providers to gain competitive advantage through risk management maturity.
