Maximize your SOC reports with these 3 questions

1. Are the organization’s controls sufficiently managing risk and addressing stakeholders’ concerns?

Once a company issues its first SOC report, the risk of a “set it and forget it” mentality arises related to the key controls identified and the accompanying control information included in the SOC description. After the care and effort that went into initial development of that content, service organizations might perform only a cursory review with the default assumption that nothing has changed. Instead, service organizations should review their controls annually as part of SOC planning activities. In addition to identifying any changes to controls, this review should look for opportunities to enhance the existing content and to reflect on:

• The evolution and maturation of key enterprise programs (such as information security, risk management, and compliance)
• The automation of control processes, resulting in efficiency and increased assurance
• The implementation of additional technical safeguards and control processes

SOC 1 reports. The demand for and use of SOC 1 reports focuses on internal controls over financial reporting (ICFR) for report users. SOC 1 reports provide assurance over the completeness and accuracy of financial information. The reports achieve this through a combination of information technology general controls (ITGCs) for the key systems used to process and store that financial information and key activities performed by the service organization on behalf of its customers.

In addition to these foundational control areas, SOC 1 reports are evolving to address more specific financial reporting risks for report users. Organizations should review existing SOC 1s and consider whether the following areas are sufficiently addressed:

• Key reports provided by the service organization. Where service organizations generate and provide key financial reports to their customers (such as monthly account statements), report users and their external auditors lack firsthand knowledge and access to the information they need to obtain assurance over the completeness and accuracy of those reports. As a result, service organizations are now expected to deliver that assurance through their own SOC 1 reports to address these customer needs. To do so, service organizations should include information on their controls over the underlying source systems, calculations, and automated processes used to generate and deliver those reports.
• Key system calculations and configurations. Like key reports, any setting or calculation that cannot directly be viewed by customers and their auditors is now an unknown internal control aspect that needs to be addressed through the SOC 1. In addition to confirming the existence of a setting or calculation (which often is observed by an auditor as of one point in time), customers also expect SOC 1 reports to include controls over configuration and change management – such as who has access to change the setting or calculation, and whether monitoring is in place to detect if a change occurs. Service organizations should apply a financial audit lens to identify key settings and calculations and should incorporate additional SOC controls to address accordingly. 

• In-scope SOC 2 categories. In addition to the required common criteria (also known as the security category), organizations can choose to include one or more additional categories: confidentiality, availability, processing integrity, or privacy. When considering additional SOC 2 categories, organizations first should consider if the category (and the risk it addresses) is applicable to the services provided. Availability and confidentiality can be applicable to most service organizations; however, processing integrity and privacy might not be. After determining which SOC 2 categories are applicable, organizations should consider the significance of the underlying risks – such as how much value the additional categories will provide to report users – which then should be weighed against factors such as the additional examination effort to identify the in-scope SOC 2 categories.
• Inclusion of a second framework (that is, SOC 2+). Organizations can consider whether inclusion of another security framework (such as from the National Institute of Standards and Technology or the International Organization for Standardization (ISO)) would be beneficial. A second framework can help demonstrate more specificity and depth within the organization’s control environment. In addition, through a single examination process and report deliverable, the organization can demonstrate how it addresses both SOC 2 and the second framework. Organizations should consider their industry and customer base when selecting their second framework. For example, companies within healthcare or that serve the healthcare industry commonly choose the HIPAA Security Rule. Technology companies that have a global customer base familiar with the international security framework might choose ISO 27001.

2. Should the organization include more detail and context in its description?

While some report users might still perform a cursory review of SOC reports, most customers want to use the detail within a SOC report to replace or reduce more manual and cumbersome activities, such as ad hoc on-site audits or detailed vendor questionnaires. Within the description section of a SOC report (typically Section 3), service organizations are required to include content that addresses a defined set of description criteria. These criteria include a description of the in-scope products or services, the boundaries of the in-scope IT environment, and the key controls that are tested by the SOC auditor. Including additional detail beyond the minimum required, especially related to the service organization’s control environment, will help customers and other report users understand and evaluate the control environment of key service organizations.

In order to evaluate whether the SOC description includes a sufficient level of detail, organizations should read the current content from the perspective of someone external to the organization (someone without built-in knowledge of the company’s operations and environment). The description should include enough context for the control environment that it mimics an audit interview. The description details should address the who, what, when, where, why, and how so that report users can understand the full story. In addition, organizations should identify any instances where internal acronyms, terminology, or branding are used and either reword or include explanatory detail to avoid leaving readers with more questions.

When thinking about the level of detail to include as a report issuer, or the level of detail to look for as a report user, here are a few considerations:

• Does it feel like a control walk-through meeting? Service organizations aren’t going to give away trade secrets, but the SOC report should provide enough detail to replace a customer’s own on-site audit.
• Does the SOC report identify key customer control responsibilities as complementary user entity controls? Delineating service organization and customer (user entity) responsibilities in a prescriptive and specific way allows both parties to check for any holes in the process.
• Are subservice organizations (fourth parties) clearly identified?  If the service organization, in turn, outsources aspects of its operations or IT environment to other service providers (such as colocation services or IT-managed services), those subservice organizations must be clearly identified within the SOC report. In addition, service organizations should clearly delineate the aspects of the control environment managed by the subservice organizations. This enables report users to make informed decisions about whether those downstream service providers should be considered significant and if any additional activities are required to sufficiently address third-party risks (such as obtaining the subservice organization’s SOC report).

3. Are the organization and its SOC auditor following the best practice of “assess once, report many”?

Many organizations issue multiple SOC reports, so it can be easy for details to get lost in the shuffle. When report issuers plan and execute the work only once, it allows them to better manage risk across the organization and address stakeholder concerns. For both report issuers and report users, the focus on assessing once means everyone can see the bigger picture.

From the perspective of the service organization, not having to provide the same information for the same control numerous times makes the entire SOC reporting process seem much less cumbersome and frees up internal resources to focus on other critical business activities.