What CPAs need to know about SOC
System and Organization Controls (SOC) reporting has been around for many years, but there remains some confusion about when and how to use it. Financial auditors use SOC reports to evaluate the adequacy of internal controls around financial systems. Businesses who use the services of other businesses will review SOC reports to determine how secure a vendor’s systems are, and if they can meet the processing or availability requirements of the customer. Increasingly, businesses utilizing SOC reports to better understand the risks of working with other businesses, especially around cybersecurity.
The primary purpose of SOC reports are to communicate the controls in place at a service organization to a report user. Users of an SOC report want to know what controls are in place to protect the information that they share with service organizations.
SOC reports are issued by public accountants. It is the responsibility of the service auditor to determine if the system description accurately represents the system being reported on, and evaluate the controls of that system.
Available SOC reports
The type of SOC report issued is dictated by the type of system being evaluated and the final user of the report. Below is a snapshot of the five main SOC reports.
- SOC 1: This is a report around the internal controls over financial reporting. These reports are mainly used by other auditors. It focuses on controls in place to protect financial systems and process. Organizations that are candidates for these reports are those processing financial data, such as payment processors or broker dealers. Due to the detailed nature of this report, it is recommended for limited release.
- SOC 2: These are reports on controls at service organizations, as they relate to the Trust Service Criteria (TSC). TSC includes security, availability, processing integrity, confidentiality or privacy. These reports will report on some or all of the criteria. Any organization that provides a service to another is a candidate for this report, including printing, health care, software development and system/software hosting industries. These reports are used mainly by businesses entering a vendor relationship with another business. Like SOC 1, it is recommended for limited release.
- SOC 2 + additional subject matter: This report is based on a SOC 2, but it also reports on compliance with specific security frameworks, such as the cloud security alliance (CSA), HITRUST, ISO or other. These reports are used by businesses in specific industries who are entering into a vendor relationship, and need the utmost confidence that their information will be handled in accordance with industry standards and industry specific statutes. Health insurers which exchange patient information with medical providers might need a SOC 2+HITRUST, for example. Due to the detailed nature of this report the SOC 2 + additional subject matter is a limited release report.
- SOC 3: This report is the same as a SOC 2 report, except that it does not include as much detail in the final report. This report is generally used for marketing purposes and is consequently meant for general use.
- SOC for cybersecurity: This is a newer SOC report that focuses on the effectiveness of cybersecurity risk management programs. This report provides transparent, consistent and comparable reporting, which is flexible and scalable to meet the needs of various stakeholders — both internal and external — to an organization.
- Coming soon: SOC for vendor supply chains: This report is still under development, but is slated to be released this year. This report focuses on controls in a vendor’s manufacturing process, so distributors and customers have a better understanding of security risks in their supply chains.
Types of SOC reports
Each of the five SOC reports can be a Type 1 or Type 2 report.
- Type 1: Reports on the fairness of the presentation of the system, which was designed and implemented as of a specific date. It also reports on the suitability of design of the system.
- Type 2: The same as a Type 1 with the additional requirement of reporting on operating effectiveness for a period of time. This period could be as short as six months and as many as 18 months. In this report, you will find a description of the auditor’s test and results.
As a rule, a service organization will have a Type 1 report done as its first report and a Type 2 thereafter.
Why SOC reports?
One of the main reasons that organizations request SOC reports is due to its uniformity. Although every service organization is different, every SOC report is formatted similarly into the same five sections. This consistent formatting allows for comparability between organizations.
- The independent service auditor’s report: Similar to a report letter you find in a financial statement report.
- Management’s assertion: A letter from the service organization management describing what information will be found in the report, and what methods were used in drafting the system description.
- System description: This section varies in length depending on the complexity of the system being reported on. Each system description provides information on the services being provided, components of the system, including information on subservices and complementary user entity controls. The system description is written by management of the service organization.
- Control objectives and service auditor’s test of controls and results: This part describes what controls are in place at the service organization. In a Type 2 report, it also describes the tests the service auditor performed to determine operating effectiveness, and the results of those tests.
- Other information provided by management: Sometimes, service organizations want additional information added to the report that does not fit into the above parts, such as a mapping to an industry standard. Section 5 is also where management can add information on any deficiencies the service auditor may find in section 4. This could range from a disagreement with the auditor’s findings to actions that have been taken to remediate deficiencies.
Evaluating SOC reports
When evaluating an SOC report, reviewing any deficiencies or tests that have exceptions noted is the first place to start. Comparing SOC reports of similar vendors may give insight into elements that may be missing from a system. Often, SOC reports are a replacement for customers sending auditors to a vendor to test security. If there are any concerns about deficiencies, it may be appropriate to still audit certain aspects of a system.
The standard for the future
Threats to information are constantly increasing. Understanding what vendors are doing to mitigate these risks is essential. The ability to discern the difference between vendors is critical. No business wants the bad press from a data breach, especially if the breach is caused by a vendor. SOC reports provide a glimpse into the control structure a business has in place to protect the data in its custody. In coming years data manipulation will become more automated. Understanding a system, how it operates, and the controls in place to protect its integrity will become paramount. Automation will reduce errors and human mistakes. It will also expose systems to new and more complex threats. Traditional checks and balances won’t mitigate these threats. A reliance on controls and the operating effectiveness of those controls will safeguard against these new threats.
The AICPA continues to update SOC as new threats and reporting needs emerge. The AICPA is also building alliances with security frameworks to assist in reporting uniformity. These actions will make the SOC report a standard for many years to come .
Aaron Thomas, CPA, CISM, CISA, CRISC is a partner at Copeland Buhl & Company. He has more than 15 years working with information systems and information security. You may reach him at firstname.lastname@example.org or 952-476-7183.