For companies looking to get SOC 1 or 2 compliant, it can be hard to find out where to start, so we’re providing a straightforward guide to the ins and outs of SOC audits.
Chances are, if you clicked on this blog post, something like this 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!
What is SOC 1?
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: Vertex Inc.’s and Ingham Retirement Group’s Type 2 reports.
While they are the same audit and type, these businesses do not offer similar services. Vertex Inc. offers cloud tax compliance software, while Ingham acts as an employee benefit firm providing consulting and administrative services.
In the audit, Vertex Inc. is concerned with access controls to sensitive data, as well as the physical security of its third-party data center and physical cloud hosting facilities, 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 Vertex Inc., some of their control objectives - taken directly from their report - include:
Physical Security
Data Transmission Security
Backup Management, Issues And Change Management
Logical Access Control
For Ingham, some of their control objectives - taken directly from their report - are as follows:
Contribution and Loan Repayment Processing
Distribution Processing, Loan Processing
Trading
Dividends
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 Vertex’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.
Does your company need SOC 1?
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 close deals faster by showing their current and prospective clients that they’re trustworthy. 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 a TikTok. Still there? Alright, back to the show.
What is SOC 2?
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: “SOC 2 reports are intended to meet the needs of a broad range of users that need detailed information and assurance about the controls at a service organization relevant to security, availability, and processing integrity of the systems the service organization uses to process users' data 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: “Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems…”
Availability: “…systems are available for operation and use to meet the entity’s objectives.”
Processing integrity: “System processing is complete, valid, accurate, timely, and authorized…”
Confidentiality: “Information designated as confidential is protected…”
Privacy: This “…addresses requirements regarding collection, use, retention, disclosure, and disposal of personal information.
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 cybersecurity is lax, then they can’t fulfill their commitment to privacy, since sensitive information could be exposed in a security breach.
1Password had to make sure that the “gears” were in motion when we were becoming SOC 2 compliant. Even though our product assists us (and our clients) with information security and privacy by protecting passwords, it was only a piece to the SOC 2 puzzle. We also had to document our confidentiality policies, prove we had MFA enabled, and a host of other things.
Let’s take a look at ionLake’s 2019 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 the Environmental and Physical Security of data.
You’ve probably noticed that 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.
Does your company need SOC 2?
At this point, most B2B companies are collecting customer data, so interest is rising. But as Ed Garner, SOC 2 compliance consultant and CEO of New England Safety Partners, 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
Healthcare
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. 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.
What companies need both SOC 1 and SOC 2?
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 in between 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.
Found the matching SOC?
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 apps, passwords, and devices. Tools like 1Password® Extended Access Management make that easier.
1Password Extended Access Management’s Device Trust offering 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 post 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.
To learn more about how 1Password Extended Access Management could help on your compliance journey, reach out for a demo!
Kenny Najarro
Content Associate
Tweet about this post