Chances are, if you clicked on this blog, a couple of things recently happened to you:
Your boss told you that your company needs to become SOC 1 and/or 2 compliant
You googled “what are SOC audits?”
You quickly realized that you weren’t sure if your boss meant SOC 1 Type 2, SOC 2 Type 1, or something else altogether
Not to worry, we’re here to demystify and simplify this SEO mess and help you figure out which type of audit your organization needs.
So, what the heck is a SOC audit? To put it in plain English, they are independent audits, designed by the American Institute of CPAs (AICPA), that assess how service providers manage risk. Having a SOC certification tells prospective customers that an organization has the appropriate processes and safeguards in place to operate responsibly.
The difference is in what each report looks at, which broadly comes down to financial reporting (SOC 1) vs data security (SOC 2). We’ll borrow the AICPA’s own language to define them further:
SOC 1: Report on Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting (ICFR)
SOC 2: Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy
Before we look at both versions in more detail, you may have heard that each audit has two “types.” Thankfully, the idea behind Type 1 and 2 is basically the same for each audit.
Type 1 – Reports on how accurately a service organization describes its system, and how well its controls are designed to achieve its control objectives at a specific point in time.
Type 2 – Reports on all of the above plus the effectiveness of controls, over a period of time.
Most companies get a Type 1 audit first, and then get regular Type 2 follow ups to maintain their certification.
Now that we’ve gone over the basics, let’s dig into each audit and figure out whether your company may need SOC 1, SOC 2, or for those very special folks–both!
A typical SOC 1 definition goes something like this: A SOC 1 audit is a report that evaluates a service provider’s internal controls over financial reporting (ICFR) that may impact its customers’ financial statements and reports.
After wading through that sentence, let’s all let out a collective “…what?”
Time to break it down piece by piece.
First, let’s address those “internal controls” pertaining to financial reporting. They are policies and procedures designed to prevent, mitigate, and/or detect accounting errors and fraud. But what those controls look like isn’t the same for every SOC 1 report.
Let’s compare two very different examples of SOC 1 reports: Equinix’s 2019 SOC 1, Type 2 report and Ingham Retirement Group’s 2019 SOC 1, Type 2 report.
While they are the same audit and type, these businesses do not offer similar services. Equinix operates data centers from which clients can store and manage financial data, while Ingham acts as an employee benefit firm providing consulting and administrative services.
In the audit, Equinix is more concerned with the physical security of its facilities and the financial information therein, while Ingham deals more directly with the collection, distribution, and storage of financial information. Their SOC 1 control objectives reflect the distinction in services.
For Equinix, some of their control objectives - taken directly from their report - include:
- Physical Security
- Environmental Security
- Backup Management, Issues And Incident Management
- Network And System Monitoring
For Ingham, some of their control objectives - taken directly from their report - are as follows:
- Contribution and Loan Repayment Processing
- Distribution Processing, Loan Processing
You can go to each report to find out what each control objective sets out to do in great detail, but for our purposes they are plenty descriptive. Ingham’s control objectives focus on loans, trades, reconciliations, and data management, while Equinix’s emphasize physical and environmental security.
That said, when distilled, all control objectives are about the same thing: anticipating and managing risk, whatever that looks like for an individual company.
Think of it this way: if you’re going to hire a babysitter so you can enjoy a much-needed night out, you want to make sure the person you hire has a CPR certification, recognizes your children’s allergies, and knows how to get in touch with you. SOC 1 establishes the same sort of baseline, but for a service provider, so other businesses know they can trust them with what they hold dearest: their money.
Now that we’ve established a cursory understanding of what a SOC 1 audit is, the next step is figuring out whether it’s relevant to your business.
There’s really only one reason companies go through a SOC 1 audit: to show their current and prospective clients that they’re trustworthy in order to close deals faster. An audit report can speed up due diligence, but it has internal value too. The audit process forces service providers to assess and codify their own processes and identify weaknesses.
Below you will find types of businesses that might need a SOC 1 audit. They can include, but are not limited to:
- Payroll Processing
- Trust Departments (a division or an associated company of a commercial bank)
- Registered Investment Advisors
- Employee Benefit or Retirement Plan Operators
- Loan Servicers
- Financial Services
You’re halfway through the article! I know it’s a lot to absorb so this is a good moment to take a sip of whatever you’re reading this with, answer that text, or watch that TikTok. Still there? Alright, back to the show.
A SOC 2 audit has a broader scope than SOC 1. On what, you may ask. Good question. The cloud (to be read in the voice of the little green aliens from Toy Story) and the data it stores.
Here’s a thorough definition, courtesy of the AIPCA: A SOC 2 audit “provides detailed information and assurances about the service provider’s internal controls relevant to security, availability, and processing integrity of the systems used to process users’ data in the cloud and the confidentiality and privacy of the information processed by these systems.”
Once again, let’s all let out a collective “…what?” Stay the course, we’re breaking this one down as well.
First, it’s important to know that the AICPA assesses SOC 2 controls through the lens of five categories known as the Trust Service Principles. They are as follows:
Security: “…systems and data need to be protected against unauthorized access and anything that could compromise their confidentiality, integrity, availability and privacy.”
Availability: “…systems need to be available for use and operation.”
Processing integrity: “…system processing must be timely, accurate and authorized.”
Confidentiality: “…information delegated as confidential needs to have appropriate protections.”
Privacy: “…any personal information collected must be used, retained, disclosed and disposed of appropriately.”
Think of these principles as gears in a machine – if one is ignored, then the rest are liable to stop working as well. For example, if an organization’s security is lax, then they can’t fulfill their commitment to privacy, since sensitive information could be exposed in a security breach.
Kolide had to ensure that the “gears” were in motion when we were becoming SOC 2 compliant. Even though our product assists us (and our clients) with security and privacy by ensuring devices are compliant, it was only a piece to the SOC 2 puzzle. We also had to document our personnel policies, prove we had MFA enabled, and a host of other things.
Let’s take a look at ionLake’s SOC 2, Type 2 report as another example.
ionLake is a text communication tool for businesses and its audit was specifically concerned with its hosted customer service system:
Policies – Defines and documents policies for the security of its systems.
- Examples include: identifying and documenting the security requirements of authorized users; assessing risks on a periodic basis; preventing unauthorized access; assigning responsibility and accountability for system security; providing training and other resources to support its system security policies.
Communications – Communicates its defined system security policies to responsible parties and authorized users.
- Examples of these communications include: informing authorized users about breaches of the system security and submitting complaints; communicating changes to system security management and affected users.
Procedures – Operating procedures to achieve its system security objectives, in accordance with its defined policies.
- Examples of these procedures include: routinely identifying potential threats of disruption to system operation that would impair system security commitments; assessing the risks associated with the identified threats; logical access security measures to restrict access to information resources not deemed to be public. identification and authentication of users; registration and authorization of new users.
Monitoring – Monitoring the system and taking action to maintain compliance with its defined system security policies.
- An example of this policy includes: system security is periodically reviewed and compared with the defined system security policies.
As ionLake is a fully remote business, they were not observed nor tested for internal controls such as Environmental and Physical Security of data.
As you’ve probably noticed, there’s a fair amount of overlap between SOC 1 and SOC 2, especially when it comes to security, so organizations that get both audits can use some of the same documentation.
At this point, most B2B companies are collecting customer data, so interest is rising. But as Kolide’s own SOC 2 compliance consultant, Ed Garner, told us: “It’s really important to have a legitimate driver to do it, because it is an expensive and pedantic process.”
Here’s a brief list of businesses that are most likely to need a SOC 2 audit:
- Document Management
- Information Technology
- Data Center co-locations
- Software as a Service (SaaS) providers
- Cloud Service Providers
- Managed IT Services
- Digital Marketing Firms
The evolution of data collection and management alongside the evolution of breaches and cyber crime make the SOC 2 audit all the more relevant. Take a SaaS company like Salesforce. As a cloud-based CRM, Salesforce manages important data that its clients do not want to share with the world. If Salesforce did not have procedures, policies, in place to prevent and mitigate risks such as data breaches, customers (especially on the enterprise level) would balk at using their services.
But, what’s important to note is that getting a SOC 2 audit doesn’t guarantee zero chance of a data breach. As the Kolide team learned in our journey to become SOC 2 compliant, a SOC 2 audit simply proves that you have processes in place to mitigate potential risks, and that you consider the security ramifications of every decision.
If you’ve read down this far and thought to yourself: “My company fits into both categories,” then ding, ding, ding. You’re the lucky winner of getting SOC’d not once, but twice.
With the evolution of business, especially SaaS companies, there has been the creation of a special bucket of entities that reside in the inbetween of financial-related institutions and data collectors. These types of businesses can include:
- Service Providers
- Accounts Receivable
- Collections Services
- Colocation and Managed Services
- Financial Software as a Service
For an example of a company with both SOC 1 and SOC 2 certifications, let’s look at Oracle Retail, a suite of SaaS solutions for (you guessed it) retailers. This portfolio includes point-of-sale hardware that handles transactions, inventory and supply chain management, and marketing. Oracle Retail’s mix of financial services and general business services make them a good fit for both audits.
A moment of silence if you’re on an Operations team reading this and slowly realizing this will become your reality soon enough. You’ll make it through (probably)!
Audits aren’t what most people would classify as “fun.” The words more commonly associated with them would be “frustrating,” “painstaking,” or “miserable.” But they are necessary to provide a sense of security to your clients and your team.
If you’re on the journey to become SOC compliant, you will need to document every process and procedure that falls within the audit’s scope. And that absolutely includes the health and security of your fleet of devices. Tools like Kolide make that easier.
At Kolide, many of our customers use our product to pass their SOC 2 audit. (In fact, we used it ourselves for our own audit!) Kolide provides visibility to your devices’ health, empowers employees to solve device issues on their own, and gives you real-time compliance data that you can show auditors.
That said, a SOC audit process is still a long and arduous process. But hopefully this blog has helped you figure out where you need to start.
May the paperwork be easy to find, the systems working as they should, and the auditor sympathetic. Godspeed.