Your business relies on third-party APIs to operate. Sometimes they enhance your capabilities, and other times they bridge the gap between your business and where your customers are through integrations. Either way, the intermingling of data and services between your business and these third-party vendors can put your business at risk.
When it comes to ensuring these providers are handling data securely, SOC 2 has become one of the most common security frameworks for tech companies. If you aren’t offering data services directly to customers, you may never be asked for a SOC report. That doesn’t mean you shouldn’t look for them from your SaaS providers.
What is a SOC report?
System and Organization Control (SOC) is a framework developed by the American Institute of CPAs (AICPA) for dealing with financial data. It has evolved to be useful outside the accounting industry as a way to address system-level controls and security guidance for any company—service organization—that offers services to handle, manage, or manipulate sensitive information and customer data.
SOC audits are conducted by third-parties to ensure standards defined in each audit type are met, and to ensure companies are meeting the expectations they promise to customers with regard to security and data management. The resulting report is produced and acts as a source of record for any customers interested in confirming the practices of a vendor—like a third-party API provider—when they choose to do business with them.
SOC 1, SOC 2, and SOC3 reports
While the most requested report is SOC 2, there are three SOC reports.
A SOC 1 report deals with the internal control over financial reporting (ICFR) and—as the name suggests—has a focus toward financial firms and companies that deal with payments, payroll processing, and similar activities. It is sometimes known as the SSAE 18, or Statement on Standards for Attestation Engagements No. 18. It is the evolution of the AICPA auditing standards that started with SAS 70 in 1992. SSAE 18 was most recently put into effect in May 2017, and you may see SOC 1 reports listed as SSAE 16 SOC 1, an older version of the standards from 2010.
From an accounting perspective, a SOC 1 report is an assessment of how well a company keeps their financial data up-to-date and accurate.
A SOC 2 report has a more broad target, which makes it the ideal report for most organizations. It was created to avoid the misuse of the SOC 1 standards—or the bending of them—to fit organizations that don’t deal primarily with financial data. It is broken down into a set of “Trust Services Criteria” (TSCs) that include security, availability, confidentiality, processing integrity, and privacy. These five criteria allow auditors to render an opinion on how effective, and accurate, a company’s security and data practices are.
As SOC 2 reports may contain sensitive information about how a company operates, they may be available by request only and require the requesting company to sign a non-disclosure agreement.
SOC 3 reports are less-technical and summarized versions of the SOC 2 report. Their brevity and lack of specific details make them great marketing tools—as they can be freely distributed, they show details about the audit without revealing the internal workings of a company’s security and data management strategy.
SOC Report Types
In addition to the three reports, there are also two main report types.
Type I is a snapshot of the security and data practices from a specific point in time. Many organizations will complete a Type I report while they await the completion of their longer Type II audit.
Type II assesses the same details as Type I, but over an extended period of time. Generally this is 6-12 months. As a side effect of the longer assessment, a Type II report can also measure how effective the system is at securing the data—as it has greater insight into the operations over time.
Both SOC 1 and SOC 2 can have Type I and Type II reports. SOC 3 however is always Type II and does not have a Type I option.
Which report should you look for when choosing a provider?
As we mentioned earlier, SOC 2 is the most commonly requested report. When assessing vendors for your API and SaaS needs, start by seeing if they have a SOC 2 Type II available. This information and any other certifications can often be found on a company’s Security and Compliance pages of their website. If they don’t have either, reach out to their sales department to request a report.
This will give you not only the assurance they are putting security at the forefront of their offerings, but it also allows you to learn more about the specific controls tested by the auditor during the audit process. If a SOC 2 Type II report has yet to be completed, the vendor may offer a SOC 2 Type I as they await completion of the Type II audit.
If your company deals with financial data that may be moving through the API provider’s services, you may want to request a SOC 1 report as well. This could include organizations that deal with things like payroll processing, credit or loan services, and FinTech in general.
How do you benefit from using a SOC audited API provider?
A SOC report is a competitive advantage for many companies. As a customer, it tells you the API or SaaS service provider has taken the steps to ensure their security and data infrastructure are well established. Furthermore, it says they are confident enough in their systems they are willing to have a third party come in and audit their processes.
The greatest benefit is in assurance. An audit normally asserts that anything they say in their privacy policy and terms is accurate. You can take them at their word that data is handled in the way it is described. No more hoping a provider’s privacy policy isn’t copy-pasted from a past startup.
Further steps to keep your API risks low
Whether you limit your API provider choices to those with certain compliance minimums—or simply start paying closer attention to the certifications each provider has—keeping track of your APIs and how they manage data is an important part of keeping your business risks low. Each new API you add has the potential to become a shadow API. By governing and monitoring the APIs your teams use, you can avoid downtimes, performance problems, and even your own compliance and regulatory issues.
At Bearer, we’re building solutions to help with this. Schedule a Demo to see how we can bring confidence to your API usage.
