A System and Organizational Controls (SOC) report can offer insights into the financial (SOC 1 reports) and operational strength (SOC 2 reports) of a third-party vendor to help your institution assess the risks of working with that vendor. There is also SOC for Cybersecurity, which covers a company’s enterprise-wide cybersecurity risk management program.
A SOC 2 covers five key areas:
Each area includes a list of common criteria that must be met in order for a financial institution to say it’s certified or compliant in that area.
Not all SOC 2 Reports are the same, so read them carefully. Glancing at a SOC 2 report isn’t due diligence. The report requires a thorough read so you can understand the operational risks your institution faces by working with a specific vendor.
You don’t need to be certified or compliant in all five areas to say you’re compliant. As we mentioned, SOCs cover five areas (security, availability, processing integrity, confidentiality, and privacy), but a company doesn’t have to include all five areas in its audit.
A company can choose which areas it wants to test itself against—even if it’s just one area—and say it’s SOC compliant.
There is nothing inherently wrong with choosing to be audited in just one, two, three, or four areas. In fact, a narrower scope might be more appropriate for the types of product and services the vendor offers. A closer look is necessary to ascertain if the audit areas are sufficient.
The criteria for an audit can be vague. One SOC question is: Do you train your employees when hiring them? It’s a simple question, but it’s also open to interpretation.
There are no specific criteria for a SOC 2 audit. That leaves it up to the vendor to build the controls and up to the auditor to certify whether those controls are in place and meet the criteria. Does an automated system walk employees through training and log the results? Does a supervisor sign off that training took place? Does HR hand each new employee a handbook and call it a day?
These controls are not equally effective.
The same goes for network controls. Unlike PCI Security Standards, which dictate standards for what type of network segmentation and passwords must be used, a SOC report focuses on the risk of not having controls in place. The controls put in place might meet PCI standards (which are considered best practices), they might not.
The lack of specificity isn’t necessarily bad. It gives FIs the flexibility to put in controls that are appropriate for their size and complexity. Sometimes a control area just doesn’t make sense for the organization.
For example, a control might be ensuring that all sensitive data locations are protected. If all the company’s data is stored on the cloud and doesn’t exist in the company’s office (except for maybe a few sheets of paper), a company might not feel the need to install a physical security system in its office to protect data because there is no data to protect.
Other times, a company might not audit an area because it knows it can’t pass muster. We’ve seen companies that have no controls protecting data that leaves their data center. Anyone who could get on the server could upload data anywhere in the world.
The way to find out whether a missing area poses increased risk to your financial institution is to ask about it during the due diligence process. Extra documentation beyond the SOC can help your institution understand the reasoning and the risk.
Who is the auditor? Make sure the auditor has a solid reputation. Companies pay auditors, so there can be temptation on an auditor’s part to please a client, especially if requirements are fluid. A SOC is more valuable when it’s conducted by an audit firm with a reputation for ethical behavior.
Even if you have no findings, that doesn’t mean you’re in the clear. You can’t just look at the summary page, see there are no findings and move on. Someone needs to look at the report to understand potential weaknesses. What areas were audited? What kind of controls were in place? Who was the auditor? The more experienced with SOC reports the reader is, the better they’ll be at finding issues.
Remember, a SOC report is just the start of your third-party due diligence. Don’t get caught up in misconceptions, and you’ll be able to use this tool for more effective vendor management.