Schellman becomes The First ISO 42001 ANAB Accredited Certification Body!

Contact Us
Services
Services
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
Sustainability Services
Sustainability Services
AI Services
AI Services
About Us
About Us
Leadership Team
Leadership Team
Corporate Social Responsibility
Corporate Social Responsibility
Careers
Careers
Strategic Partnerships
Strategic Partnerships

SOC 1 vs SOC 2: Which is Better?

SOC Examinations

Back when it first emerged in 2011, having evolved from SOX and SAS 70 in the wake of devastation caused by Enron, SOC wasted no time becoming the new market standard for compliance reporting, and it’s partly thanks to its flexibility that it remains such a staple.

So much so that it’s probably what’s brought you here, right?

More and more, it’s becoming customary for businesses of all types to request their vendors be audited before commencing partnership, and SOC is usually one of the first audit options that comes up. Having your systems or services evaluated through a SOC examination can provide some much neededor even contractually obligatedassurance.

But even within SOC, there are a lot of options these days.

Now, we have SOC for Cybersecurity and SOC for Supply Chain, but this SOC reporting brand was established through SOC 1 and SOC 2, who, from our perspective, remain kings of the hill in a lot of ways.

But though they are fruits of the same tree, yielding similar-looking deliverables and featuring the same report types available for your choice, there is a stark difference between SOC 1 and SOC 2 and it will benefit you greatly to understand.

As providers of both since the first emergence of the brand a decade ago, we’re going to break down exactly what sets SOC 1 apart from SOC 2 and what kinds of organizations usually turn to which report. With a better grasp on what you can achieve with either, you’ll be better positioned to pick which direction you’d like to go. (Or maybe, you’ll even want both!)

The Difference Between SOC 1 and SOC 2

So what is it? Where do SOC 1 and SOC 2 split at the fork in the compliance road?

Despite their similar elements in some ways, SOC 1 and SOC 2 are not the same, and the difference between them lies in what they validateby choosing either, you decide what controls you want to have evaluated within your organization.

What does that mean in layman’s terms? Both a SOC 1 and a SOC 2 can provide your stakeholders with the assurance they want, but they will do that after scrutinizing specific—and completely separate functions of your organization.

What is SOC 1?

Put simply, SOC 1 is specific to evaluating controls that impact your clients in a specific way—its focus is on how your services impact your customers' financial reporting. It’s limited to the examination of those business process controls and other relevant IT controls relevant to your customer’s financial reporting process. As such, SOC 1 is the path often trodden by those service organizations that do provide something that could impact their clients in this very specific way.

(However, it’s important to note that SOC 1 is not an audit of actual financial data. It only evaluates the controls in place that may affect that reporting process.)

You might need a SOC 1 report if you are:

  • An organization that hosts customer systems (e.g., infrastructure as a service (IaaS), platform as a service (PaaS), etc.)
  • An organization that hosts software in the cloud (e.g., software as a service (SaaS))
  • A data center or colocation service provider
  • A managed services provider
  • An organization that processes transactions (e.g. payroll, loan servicing, medical or insurance claims, inventory) or hosts financial information (databases)
  • A custodian for investment companies
  • An organization that services loans
  • A mortgage service company

If you do choose a SOC 1 report, you’ll be tasked with performing a risk assessment to define the different types of risks that are applicable to your specific scope. This part is critical because it’ll yield the identification of the control objectives that will form the basis of your audit.

After you’ve identified a risk, you’ll state it in reverse to create your objective to mitigate it.

  • Say you’ve identified a risk to your logical infrastructure as “unauthorized logical access to data or systems.”
  • You’d then create the related control objective as “to ensure logical access to data and systems is authorized.”

These control objectives can be as broad or specific as you need, but don’t worry if you have trouble coming up with them at first—service auditors like Schellman can provide you with lists of samples to help get you started.

Even still, it will ultimately remain your responsibility to define which objectives are applicable to your scope as they relate to financial reporting before you proceed with your SOC 1 report.

What is SOC 2?

On the other hand, a SOC 2 report focuses on how you achieve your service commitments or promises related to security, service availability, transaction processing, data confidentiality, and/or privacy. It includes how your services remain secure and protect customer data, rather than financial reporting impact. As a framework, it’s more operational and security-centric—and where SOC 1 asks you to come up with your own objectives, SOC 2 provides a set of predefined criteria that you’re evaluated against.

Basically, SOC 2 has a preset baseline for internal control and information security. Somewhere along the line, you’ve presumably taken measures to ensure you’re securely managing data in order to protect your interests and those of your customers, no matter what kind of service you offer.

You might have set all these measures up in a hundred different ways, and it doesn’t matter which or how many you have—your SOC 2 audit will evaluate them against those preset categories. And when we say “categories,” we mean Trust Services Criteria (TSCs), of which there are five:

  • Security: The in-scope data and systems are protected against unauthorized access, unauthorized disclosure of information and damage.
  • Availability: The in-scope data and systems are available for use as agreed upon.
  • Processing Integrity: The in-scope data is processed in a complete, accurate, timely, and authorized manner.
  • Confidentiality: The in-scope data designated as confidential is effectively protected.
  • Privacy: The in-scope personal information is collected, used, retained, disclosed, and destroyed in accordance with your privacy policy.

Just as with SOC 1, there is some decision-making when it comes to these categories, and it can make for a delicate process, depending on your needs. For more information on these TSCs and how to choose those best for your organization’s SOC 2, check out our guide here.

SOC 2 can benefit anyone charged with protecting data and delivering services, but you might want to take a longer look at a SOC 2 report if you are:

  • An organization that hosts customer systems (e.g. IaaS, PaaS, etc.)
  • An organization that hosts software in the cloud (e.g., SaaS)
  • A data center or colocation service provider
  • A managed services provider
  • An organization that processes transactions (e.g. payroll, loan servicing, medical or insurance claims, inventory) or hosts financial information (databases)

If the listing above seems eerily similar to the SOC 1 listing, that’s no accident—many of the same organizations that could impact the internal controls over financial reporting also need to satisfy SOC 2 reporting requirements. But more on that later.

Which SOC Report is Best for Me?

After reading all that, perhaps it’s no surprise that it’s SOC 2 that has shot to the top of Schellman’s services provided over the years. Though still a trusted provider of assurance today, SOC 1 is very specific in its focus, whereas SOC 2 can provide assurance on a broader spectrum and to a broader audience.

It follows then, that many organizations, having successfully completed a SOC 1 examination, often then get asked or choose to undergo a SOC 2 examination as well. As daunting as that may seem—two audits rather than just the one—what’s fortunate is that, in many cases, we’ve seen the controls between SOC 1 and SOC 2 overlap, meaning your auditors can likely leverage certain documents used to complete the SOC 1 for use again in the SOC 2. Make no mistake though, scope is everything, so the degree of overlap is highly dependent on the services and boundaries of the systems to be evaluated, as well as effectively aligning the timing of the audits to be performed concurrently.

But, if you’re just getting started, choosing between SOC 1 and SOC 2 should be a decision based on three factors:

  • What kind of compliance reporting requirements you are bound to (i.e. client agreements)
  • What kind of assurance you’re seeking to deliver to your customers
  • What kind of information you are charged with protecting

Because there is so much that goes into choosing the right path to SOC reporting, it may help you feel more comfortable to hash it all out with a service auditor, and we at Schellman are happy to answer any questions you may have.

But if you’d rather continue your research on your own, please feel free to check out our other resources on the SOC subject, as seen here:

About JORDAN HICKS

Jordan Hicks is the Manager of Content at Schellman. As the owner of content marketing initiatives across all digital platforms and formats, she is responsible for the ideation of content, the authoring and development of the content, as well as developing and managing the editorial calendar to ensure the marketing goals are met as it relates to content.