Providing insight into an organization's risk
Explore Exposure CommandA service organization controls (SOC) report (not to be confused with the other SOC acronym, security operations center) is a way to verify that an organization is following some specific best practices before you outsource a business function to that organization. These best practices are related to finances, security, processing integrity, privacy, and availability. The reports, which are created and validated by third-party auditors, are built to provide independent assurance and to help potential customers/partners understand any potential risks involved in working with the organization that was evaluated.
SOC reports communicate the checks and balances a company is enforcing to root out inconsistencies and send a strong message to customers that you're paying attention to how policies and procedures are followed. No decision is ever completely risk-proof, but a SOC report will give you the context needed to determine the amount of risk involved.
SOC reports are important because they provide thorough business overviews delivered in a common and consistent framework, canvassing the organization’s in-scope systems in a logical way. Whether entering a new partnership or reviewing your current inventory of business relationships, this unbiased report provides valuable information that will be relevant in many stages of the vendor lifecycle.
Depending on the information needed and the types of organizations involved, there are several versions of SOC reports.
SOC 1:
Reports on controls that have an immediate or downstream effect on a user entity’s financial statements. Based on the SSAE 16 reporting standard.
|
Type I ● Shows how well the internal controls are designed to prevent mistakes regarding financial transaction/statement data. ● Testing is done at one point in time; does not test the operating effectiveness of the control set. |
Type II ● Tests the operating effectiveness of the internal controls (business process and IT general controls); designed to mitigate the risk of a financial inaccuracy of the user entity. ● Testing is conducted over a period of time, and a sampling methodology is used for an accurate portrayal of operating effectiveness. |
SOC 2:
Reports on controls related to security, availability, processing integrity, confidentiality, privacy. Security controls testing is mandatory, while the rest (availability, processing integrity, confidentiality, and privacy) are optional. Based on the AT 101 reporting standard.
|
Type I ● Tests the design of these controls. ● Testing is done at one point in time; does not test the operating effectiveness of the control set. |
Type II ● Tests the operating effectiveness of these controls; designed to mitigate the risk of mishandling customer data. ● Testing is conducted over a period of time, and sampling methodology is used for an accurate portrayal of operating effectiveness. |
SOC 3:
|
● A public-facing version of a SOC 2 Type II that does not include confidential information. ● Provides a high-level summary for general customers without compromising or revealing details on the internal controls. ● Usually only utilized by organizations that have conducted many SOC reports in the past and have a robust and mature control environment. |
Every Security Operations Control report will contain the auditor’s opinion, which covers whether the service organization’s description of controls is presented fairly and designed effectively. If a report is unqualified, it means the auditor found that the company represented its design and operating efficiency in a fair manner, while a qualified opinion means that they found significant discrepancies between the company's statements and reality. The opinion is considered adverse if multiple controls failed, causing an entire objective not to be met.
The report will also include the service organization’s assertion that all the controls being tested were active during the auditor's checks, a description of the system itself, and what the auditor saw while the system was in use. Essentially, the reader should see a story about what the system was purported to do and what it actually did. It should show the scope and purpose of the testing performed, including data on the management structure, communications policies, information security risk management, system monitoring, documentation procedures, system operations, and physical access of controls.
When receiving a service organization controls report from another organization, you should read all information with a critical eye. Just because you receive an unqualified report does not mean there aren't exceptions that may ultimately present red flags for your organization—unqualified only means that an objective did not fail completely. Review the management responses to any controls that failed to determine whether there are any compensating controls in place and what remediation occurred (if any).
Consider any exceptions/deviations the auditor found to see if you can accept any related risk. Ensure you understand everything and feel you have a thorough grasp on how all the controls work. Discuss concerns you have with the company, and find out if they've taken steps to fix any potential problems since the time of the report. Use the information to fuel internal discussions about any potential risks that may arise as a result of outsourcing a business function to the service organization.
While it’s true that no decision will ever be risk-proof, SOC reports exist to help organizations get a better idea of the level of risk involved with important business and security decisions. The best offense truly is a great defense, and that’s where planning and preparation—and the insights SOC reports provide—will come into play.