SOC 2 compliance: Attestation vs. certification, and why it’s important to get it right

SOC 2 compliance: Attestation vs. certification, and why it’s important to get it right

Compliance and security demand precision, especially when data, assets, and huge investments are on the line. Even the way we talk about compliance deserves consideration because language sets the precedent for what actually happens in the world.

Without getting too philosophical, we want to briefly take the opportunity to discuss common terms surrounding SOC 2 Type I and Type II compliance. Specifically, what’s the difference between attestation and certification?

Semantics aside, it doesn’t really seem important at first glance, but ignoring semantics in the realm of compliance can be costly in every sense of the word. So what is the difference and why does it matter? Let’s hash it out. 

The SOC 2 certification dilemma 

You don’t have to Google too hard to find the phrases “SOC 2 certified” or “SOC 2 certification.” LinkedIn posts, blog announcements, and PR headlines all seem to be typical places to communicate the win, and you definitely should communicate it.

Achieving compliance success is a proud moment for any business, and one worth shouting across the rooftops. Investing the time and effort to plan, prioritize, and finally receive a SOC 2 report is a venerable benchmark of progress. But there’s a catch. 

Technically, there’s no such thing as “SOC 2 certification.” Every time you’ve heard it or read it, it’s been wrong. A more detailed look into compliance jargon across the internet will also reveal another, more accurate phrase: “SOC 2 attestation.” 

What is SOC 2 attestation?

The vast majority of companies that comply with SOC 2 are not under a legal or regulatory requirement to do so. In other words, SOC 2 is not a mandatory compliance framework. It is a voluntary attestation, which is then proven by a third-party auditor. That proof is your SOC 2 report—a living document providing interested parties information about your company’s commitment to security.

Since any CPA can attest to being compliant with SOC 2 controls, there is no certifying body. The American Institute of CPAs (AICPA) designs the SOC 2 standards, but it does not award certifications. 

Therefore, there is no universally accepted SOC 2 certification. When a CPA reviews your company, there is no “pass or fail.” An auditor is simply an objective reference providing a report, for better or worse, that testifies to the state of your company’s security posture. “Failure” in SOC 2 generally comes in the form of a “qualified opinion,” meaning the auditor is telling the reader that your controls, or their execution, do not meet these particular criteria.

When a prospect or vendor inquires about your company’s security, they are asking for your attestation, not a certification. With this understanding in mind, your typical celebratory SOC 2 announcement headline should change.

from this: Llama Time, Inc. completes SOC 2 certification!

to this: Llama Time, Inc. successfully receives SOC 2 Type II attestation report.

To give a little more context, it also helps to understand what companies are actually attesting when it comes to SOC 2. Here’s a quick breakdown of the difference between SOC 2 Type I vs. SOC 2 Type II.

SOC 2 Type I attestation

SOC 2 Type I is a point-in-time, static snapshot that captures your business’s compliance frameworks as of a certain date or point in time. When an auditor is reviewing your business, they will investigate that snapshot to see whether or not the appropriate controls are present. Whether or not the controls are accurately present, an auditor will attest to, not certify. 

SOC 2 Type II attestation

SOC 2 Type II is a compliance review that takes place over a period of time, usually 6-12 months, in contrast to a point-in-time snapshot. The auditor will collect evidence and investigate the operating effectiveness of your business’s controls over the period. This is the reason why Type II is more intensive and expensive, but it’s also why it’s more meaningful. Just like Type I, an auditor will produce an objective report, not a certification, that is neither “pass nor fail.” 

Matt Cooper, Principal, Cybersecurity and Data Privacy

About the author: Matt leads the Privacy and Compliance team at Vanta. He has spent his 20+ year career in security and information technology. Prior to joining Vanta, Matt was the U.S. Director for the Cyber, Risk & Advisory practice at BSI where he led an information security consultancy providing risk management and readiness consulting for common industry frameworks such as ISO 27001, SOC2, HIPAA, and PCI. At Vanta, Matt works closely with audit partners, advises customers on security and compliance, and provides input to the product team.

Learn more about SOC 2 compliance 

Is all compliance regulatory compliance? 

What is a SOC 2 bridge letter?

Vanta’s SOC 2 compliance checklist

Written by
No items found.
Access Review Stage Content / Functionality
Across all stages
  • Easily create and save a new access review at a point in time
  • View detailed audit evidence of historical access reviews
Setup access review procedures
  • Define a global access review procedure that stakeholders can follow, ensuring consistency and mitigation of human error in reviews
  • Set your access review frequency (monthly, quarterly, etc.) and working period/deadlines
Consolidate account access data from systems
  • Integrate systems using dozens of pre-built integrations, or “connectors”. System account and HRIS data is pulled into Vanta.
  • Upcoming integrations include Zoom and Intercom (account access), and Personio (HRIS)
  • Upload access files from non-integrated systems
  • View and select systems in-scope for the review
Review, approve, and deny user access
  • Select the appropriate systems reviewer and due date
  • Get automatic notifications and reminders to systems reviewer of deadlines
  • Automatic flagging of “risky” employee accounts that have been terminated or switched departments
  • Intuitive interface to see all accounts with access, account accept/deny buttons, and notes section
  • Track progress of individual systems access reviews and see accounts that need to be removed or have access modified
  • Bulk sort, filter, and alter accounts based on account roles and employee title
Assign remediation tasks to system owners
  • Built-in remediation workflow for reviewers to request access changes and for admin to view and manage requests
  • Optional task tracker integration to create tickets for any access changes and provide visibility to the status of tickets and remediation
Verify changes to access
  • Focused view of accounts flagged for access changes for easy tracking and management
  • Automated evidence of remediation completion displayed for integrated systems
  • Manual evidence of remediation can be uploaded for non-integrated systems
Report and re-evaluate results
  • Auditor can log into Vanta to see history of all completed access reviews
  • Internals can see status of reviews in progress and also historical review detail

The ultimate guide to scaling your compliance program

Learn how to scale, manage, and optimize alongside your business goals.

PCI Compliance Selection Guide

Determine Your PCI Compliance Level

If your organization processes, stores, or transmits cardholder data, you must comply with the Payment Card Industry Data Security Standard (PCI DSS), a global mandate created by major credit card companies. Compliance is mandatory for any business that accepts credit card payments.

When establishing strategies for implementing and maintaining PCI compliance, your organization needs to understand what constitutes a Merchant or Service Provider, and whether a Self Assessment Questionnaire (SAQ) or Report on Compliance (ROC) is most applicable to your business.

Answer a few short questions and we’ll help identify your compliance level.


Does your business offer services to customers who are interested in your level of PCI compliance?


Identify your PCI SAQ or ROC level

The PCI Security Standards Council has established the below criteria for Merchant and Service Provider validation. Use these descriptions to help determine the SAQ or ROC that best applies to your organization.

Good news! Vanta supports all of the following compliance levels:


A SAQ A is required for Merchants that do not require the physical presence of a credit card (like an eCommerce, mail, or telephone purchase). This means that the Merchant’s business has fully outsourced all cardholder data processing to PCI DSS compliant third party Service Providers, with no electronic storage, processing, or transmission of any cardholder data on the Merchant’s system or premises.

Get PCI DSS certified


A SAQ A-EP is similar to a SAQ A, but is a requirement for Merchants that don't receive cardholder data, but control how cardholder data is redirected to a PCI DSS validated third-party payment processor.

Learn more about eCommerce PCI

for service providers

A SAQ D includes over 200 requirements and covers the entirety of PCI DSS compliance. If you are a Service Provider, a SAQ D is the only SAQ you’re eligible to complete.

Use our PCI checklist

Level 1 for service providers

A Report on Compliance (ROC) is an annual assessment that determines your organization’s ability to protect cardholder data. If you’re a Merchant that processes over six million transactions annually or a Service Provider that processes more than 300,000 transactions annually, your organization is responsible for both a ROC and an Attestation of Compliance (AOC).

Automate your ROC and AOC

Download this checklist for easy reference


Learn more about how Vanta can help. You can also find information on PCI compliance levels at the PCI Security Standards Council website or by contacting your payment processing partner.

The compliance news you need. Delivered securely to your inbox.

Subject to Vanta's Privacy Policy, you agree to allow Vanta to contact you via the email provided for marketing and other purposes