Is your software provider following best practices in keeping their data, and by extension your data, safe? A System and Organization Controls (SOC) report can help you determine how closely a third-party organization is adhering to federal guidelines on cybersecurity. This article will highlight why SOC reports exist and why you should request them from your software vendors.
Third-Party Software Systems Come with Risk
While powerful technology tools have become more streamlined and available, keeping your data safe is still an uphill battle. Today, the capability to breach a system far outpaces the industry’s ability to develop secure code. This is because learning how to write secure code is most-often accomplished through on-the-job coaching and online self-learning. The issue is further compounded by the legacy code found in many software programs; this is code that was once accepted as high quality and secure but no longer is. In the meantime, hackers have gotten smarter and faster, leveraging this low-quality and insecure code to breach systems and access your data.
How Do Software Providers Keep Your Data Secure?
To better address these security risks, software companies, academia, and even the federal government have partnered to develop good management tools and practices to release high-quality code. For example, processes were built to ensure that smaller chunks of code are written at faster rates. These snippets are then reviewed and scanned for quality and security gaps. Third-party tools were also developed that alert users when a potential breach has occurred, removing the need to painfully review endless logs of complicated data.
Today, these leading practices are organized as security frameworks that third-party software providers can adopt. The question is, are they adopting these leading practices and how do you know if they are? The better question is, if they aren’t, should you trust them with your data? Should you maintain a relationship with them?
What is a SOC Report?
The AICPA recognized this problem a few decades ago and built an auditable framework to communicate these practices to end-user organizations (e.g., you). This framework became what’s called the System and Organization Controls (SOC) report, issued by the software provider and assessed by a third-party auditor, such as Clark Nuber PS. The SOC report includes information such as:
- The independent auditor’s opinion on whether your software provider has the right controls and processes (design and operating effectiveness of controls).
- An inventory of all the third party’s internal controls and processes and the results of their testing, including any deficiencies in these controls.
- An inventory of responsibilities that your organization is responsible for–not the software provider.
The last bullet point above warrants a discussion. Many organizations believe that the software provider is responsible for everything. This couldn’t be further from the truth. For example, a payroll processing provider ensures that payroll gets processed timely and accurately. The user organization is responsible to ensure that appropriate compensation data is recorded and that only relevant Human Resources personnel have access. A SOC report lays out this division of labor.
The Different Types of Reports: SOC 1 vs. SOC 2
|SOC 1||SOC 2
|What is it?||Discloses the effectiveness of controls, processes, and practices over financial processes. ||Discloses the effectiveness of controls, processes, and practices over security.
In addition to security, a SOC 2 report can also disclose controls, processes, and practices over availability, confidentiality, and privacy.
|What data is in-scope?||Your financial data may be stored and/or processed in the service provider’s system.||Business-critical data or sensitive data (i.e., private information, health information, etc.,) is stored and/or processed in the service provider’s system.
|Who’s the audience?||Your accounting and finance departments; and your external financial auditors.||Your compliance, IT, and security departments; and your external IT auditors.
What is a “Type 1” and a “Type 2”?
Both SOC 1 and SOC 2 reports can come in two varieties, a “Type 1” or a “Type 2”:
- Type 1: This is a “point-in-time” report. It does not guarantee that your software providers had good controls, processes, and practices over a “period of time.”
- Type 2: This is a “period of time” report. This is the stricter report, and the independent auditor will test various samples through a certain period, typically nine months.
Do All Software Providers Have a SOC Report?
There are many ways to monitor a software provider and hold them accountable for their obligations. For example, it’s common practice for user organizations to send a questionnaire with inquiries ranging from financial health to implemented security controls. Another option is to audit the software provider, but considering the time and cost, that is rarely the most sensible approach. The better option is to directly request a SOC report.
However, not all software providers have a SOC report. This might be because they’re still relatively young and are in the process of implementing good controls. They could also have failed their audit and are in the process of remediation. Whatever the reason is, a software provider that can produce a passing SOC report demonstrates that they’ve established a level of leading practices.
If your third-party software provider is a strategic partner, and they don’t have a SOC report, you have every right as a user/customer to require they comply with the standards–this is a common request.
How to Request and Review SOC Reports
Though many organizations are not aware they can request to see a SOC report from their software provider, it is considered a best practice. End-user organizations have every right to see and understand how a third-party manages their data.
SOC reports are usually lengthy documents and can appear daunting for the untrained eye. The report should be reviewed by someone with sufficient knowledge of accounting and IT processes for the entire organization, such as the controller or the IT Director (often times, both), depending on the size and complexity of the organization.
The following is a rubric on how to read a SOC report and evaluate software providers:
1. Read the Auditor’s Opinion
- Is this a clean, “unqualified” opinion? (Is this a passing SOC report?)
- If not, have you (the user) assessed risk? (See Section 4 in the report for details.)
Many SOC reports have a “qualified” opinion, which means that certain controls are deficient, as tested by the auditor. These controls are identified in detail at Section 4.
2. Read Section 4 (The Results of Auditor’s Testing)
- Were there any control deficiencies?
- If yes, have you (the user) assessed risk?
This section contains an inventory of all the controls in place by the software provider and a summary of the auditor’s testing and results. It’s also common to have an optional Section 5, which is a summary of all control deficiencies. Either way, these deficiencies may have an impact on the user organization.
For example, consider the following deficiency for a vendor that makes financial software:
|Access privileges to release code changes for the cash management module are restricted to appropriate personnel. ||Production was not secured for the cash management module; inspected that all IT employees had access. ||We noted that access was not secured. We subsequently reviewed all code and noted no changes that could have impacted the processing integrity of transactions.
In this example, the auditor identified that the entire IT department had access to code. This increased the risk that the code could have been inappropriately modified, resulting in the likelihood that cash transactions may not have been processed completely.
To compensate for this risk, an end-user organization may opt to rely on its month-end bank statement reconciliations to ensure that all cash transactions have been properly recorded. This assessment process may reveal that while a deficiency was identified, it has a limited impact on the end-user organization.
3. Read Section “User Responsibilities” (Your Responsibilities)
- Does your organization have controls implemented that are recommended by the software provider?
- If not, why not? Should you?
As previously discussed, SOC reports also communicate what you’re responsible for (instead of the software provider). These are called user responsibilities and are often too tactical to be listed in contractual agreements and can therefore “fall through the cracks.”
Common user responsibilities include:
- Reviewing and approving transactions to ensure accuracy
- Reviewing that users have the correct access permissions within the system to ensure segregation of duties
- Performing a review or reconciliation of key reports
A review of these user responsibilities may reveal the need to improve internal processes because certain risks are not reduced.
Always Trust but Verify
In today’s world, the relationship with software providers has transformed from a mere business-to-consumer relationship to a more strategic one. Well-crafted technologies enable organizations to better meet their mission and vision. As such, third-party software providers should be a part of the team and understand the role their product plays within the organization.
However, success measures must be defined and progress must be monitored. If a software provider has a breach due to ineffective internal controls, they are responsible for the data compromised, depending on contractual agreements, such as compensation, etc., However, your organization is ultimately accountable to address the risk of any compromise; these risks could be your reputation, chance of litigation, or financial costs. As such, you have every right, and even an obligation, to monitor whether your software provider is keeping your data safe and secure. You can best accomplish this by requesting a SOC report from them.
If you have any questions regarding SOC reports, or wish to obtain one for your technology company, contact the Clark Nuber IT team.
© Clark Nuber PS, 2020. All Rights Reserved
This article or blog contains general information only and should not be construed as accounting, business, financial, investment, legal, tax, or other professional advice or services. Before making any decision or taking any action, you should engage a qualified professional advisor.