What Is SOC 2 Compliance? Requirements, Reports & Audits Explained by a Veteran IT Auditor

SOC 2 is an attestation report, issued by an independent CPA firm, that tells your clients whether your controls over security (and optionally availability, confidentiality, privacy, and processing integrity) are designed effectively and, for a Type 2, operate the way you say they operate over time. It’s built on the AICPA’s Trust Services Criteria, and it’s the report most SaaS companies, data centers, and managed service providers get asked for during the sales process. If you’ve been handed a security questionnaire that ends with “please provide your SOC 2,” you’re in the right place.

I’ve been performing SOC 2 audit work for a long time, and the same questions come up on almost every first call. What are the requirements? Is it a certification? Do I need a Type 1 or a Type 2? How long will this take, and what will it cost? SOC 2 doesn’t have to be difficult, but the terminology can make it feel that way at first. In this article, I’ll walk through each of those questions the way we explain them to our clients, including a few stories from the field. Let’s dive in!

SOC 2 Is a Report, Not a Certification

Let’s clear this one up early because it’s the most common misunderstanding we hear. People say “SOC 2 certified” all the time, and I understand why. But a SOC 2 is technically an attestation report, not a certification. There’s no certificate on the wall and no governing body that grants you a badge. Instead, a licensed CPA firm examines your controls and issues an opinion on them.

When people say a company is “SOC 2 compliant,” what they really mean is that the company has controls in place that meet the applicable Trust Services Criteria and has a CPA firm’s report saying so. That opinion is the heart of the report. Without it, you don’t have a SOC 2.

I learned how important that distinction is to clients during a readiness assessment a while back. Our client had outsourced its system development to a third party, and they told us the vendor had its own SOC 2. They pulled it up, and we started reading through it together. A few pages in, we realized there was no CPA firm’s opinion anywhere in the document. There was a management assertion saying the controls were met, a nice system description, and a list of controls. But no auditor. The vendor had assembled a “SOC 2” on its own and was passing it off as the real thing. Yikes.

If a report doesn’t include an independent auditor’s opinion signed by a CPA firm, it isn’t a SOC 2. When you collect SOC 2 reports from your own vendors, that’s the first page to check.

What Are the Trust Services Criteria?

The Trust Services Criteria are the AICPA’s framework for SOC 2. They define the scope of the report and are grouped into five categories. Only one is required.

• Security (required): Also called the common criteria. It covers protection of the system against unauthorized access and is included in every SOC 2.
• Availability: Whether the system is available for operation and use as committed or agreed.
• Processing Integrity: Whether system processing is complete, valid, accurate, timely, and authorized.
• Confidentiality: Whether information designated as confidential is protected as committed or agreed.
• Privacy: Whether personal information is collected, used, retained, disclosed, and disposed of appropriately.

We’ve had prospective clients tell us they want all five categories in their first report because they want the strongest SOC 2 possible. I understand the logic, but it usually backfires. If your company doesn’t process transactions on behalf of clients, processing integrity probably doesn’t apply. If you don’t collect personal information from end users, privacy may not either. We’ve also seen reports from other firms that include a category and then explain inside the report why it doesn’t apply. That adds cost and confusion without adding assurance.

Your best bet is to select criteria that apply to your services and answer the risk-related questions you hear most from your clients. If your clients keep asking about uptime and disaster recovery, add availability. If they keep asking how you protect their proprietary data, add confidentiality. Security alone is a perfectly legitimate SOC 2, and it’s what many of our clients start with.

SOC 2 Requirements & Controls

Here’s where SOC 2 differs from frameworks like PCI DSS or ISO 27001. There is no list of “thou shalt” requirements. The AICPA provides criteria, and each organization designs its own controls to meet them. That’s why two SOC 2 reports for two different companies can look very different and both be perfectly valid.

The security category is made up of nine groups of common criteria, CC1 through CC9. Below is each one in plain language, along with what we look for as auditors.

A Closer Look: CC6.2

To show how general the criteria are, here’s CC6.2 word for word:

“Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.”

In plain terms, you need a process to grant access only to people who need it for their jobs, and a process to remove access when they no longer need it. How you do that is up to you. One client might use ticketed access requests approved by a manager. Another might use role-based access assigned automatically through an HR system integration. Both can meet the criterion.

This is also where we find more exceptions than anywhere else. A pattern we see every year: the offboarding checklist says access is removed on the employee’s last day, but when we pull a sample of terminated employees and compare termination dates to account deactivation dates, a couple of accounts stayed active for weeks. Usually, it’s a contractor or a secondary system nobody remembered, like a marketing tool or a legacy database. If you do one thing before your audit, reconcile your terminated user list against every system the user may have had access to.

Is There a SOC 2 Compliance Checklist?

Not really, and we’ve written about why a SOC 2 compliance checklist doesn’t exist. The criteria are available from the AICPA, and the CC1 through CC9 summary above is a good starting point. But because each organization meets the criteria in its own way, a generic checklist will either miss something specific to your environment or push you toward controls you don’t need. A readiness assessment is the closest thing to a checklist that fits your company.

SOC 2 Type 1 vs. Type 2

SOC 2 reports come in two types. The difference comes down to whether the auditor tests a single day or a period of time. A note on observation periods:

While a 3-month Type 2 is allowed under AICPA guidance, it may not provide adequate evidence that controls operated effectively long enough to be much more valuable than a Type 1 report. Our firm guidance is at least a six-month Type 2 report.

Here’s how that plays out in practice. A startup closes in on its first enterprise deal, and the client’s security team asks for a SOC 2. The startup doesn’t have time to wait out a 12-month period. One common path is a Type 1 now, followed by a Type 2 covering the next 6 months. Another is to skip the Type 1 and go straight to a 6-month Type 2 once remediation is complete. Which path makes sense depends on what the client will accept, so ask them before you decide.

How Often Are SOC 2 Reports Updated?

A Type 2 is generally renewed every year, and each report picks up where the last one ended, so there’s no gap in coverage. Clients will notice a gap. You also may be asked for a bridge letter, which is a management statement covering the time between the end of your previous report period and today. User auditors may not place reliance on a bridge letter greater than 6 months.

The SOC 2 Audit Process, Step by Step

Every SOC 2 audit we perform follows roughly the same path. Here’s what each step involves and what we’ll ask of you.

1. Scoping (1 to 2 weeks): We agree on which services, systems, locations, and Trust Services Criteria are in scope, and whether it’s a Type 1 or Type 2. We’ll ask you about your clients, what they’re asking for, your infrastructure, and the vendors you rely on (like AWS, Azure, or GCP). Scoping decisions drive cost more than anything else, so it’s worth slowing down here.
2. Readiness assessment (2 to 6 weeks): A readiness assessment compares your current controls to the criteria and identifies gaps before the real audit starts. We’ll interview your team and review policies, system configurations, and a few examples of evidence. It’s optional, but for a first-year audit, I strongly encourage it.
3. Remediation (1 to 3 months, varies widely): You close the gaps. That might mean writing or updating policies, turning on MFA everywhere, formalizing access reviews, documenting a risk assessment, or setting up a vendor management process. This is where we see timelines slip the most, usually because the work falls on one or two engineers who also have product deadlines.
4. Observation period (Type 2 only, 3 to 12 months): Your controls operate and generate evidence. Quarterly access reviews happen, tickets get approved, scans get run. The auditor isn’t doing much during this window, but you need to be. A control that’s skipped one quarter is an exception in the report.
5. Fieldwork (2 to 6 weeks): We request evidence, select samples, inspect documentation, observe processes, and interview control owners. We’ll send a request list up front, and you’ll upload evidence for each control. For a population-based control, like new hires or production changes, we’ll ask for the full list for the period and then select samples from it. See our post on audit procedures and testing.
6. Report issued (2 to 4 weeks): We draft the report, you review the system description and controls for accuracy, management signs its assertion, and we issue the final report.

How Long Does a SOC 2 Take?

For a first-year company starting from scratch, plan on 6 to 12 months to get a Type 2 report in hand, and 2 to 4 months for a Type 1. Companies that already have strong controls, or have been through another compliance audit like ISO 27001, move faster. You’ll see vendors promise SOC 2 compliance in two weeks. You may be able to get through fieldwork quickly, but it takes time to test properly and issue a report, and a Type 2 can’t be issued until the observation period ends. Also plan for audit firm availability. Good firms book up, sometimes months in advance. Read more on how long a SOC examination takes.

How Much Time Will It Take from My Team?

Plan on roughly 40 to 80 hours of internal time for a first-year SOC 2, and more if significant remediation is needed. That time usually falls on an engineering lead, an IT or security manager, and someone from HR. If your team is heads down shipping product, those hours can be the real constraint.

How Much Does a SOC 2 Audit Cost?

Fees depend on scope: the number of Trust Services Criteria, the number of in-scope systems and locations, the size of the organization, and whether it’s a Type 1 or Type 2. Fees can range from $15,000 to more than $100,000 depending on the size and scope of the report and company being audited. Duplicate processes add cost too. If you have three different patch management processes for different environments, the auditor has to test each one. Read more in How Much Does a SOC Audit Cost?

We’ve heard of firms offering SOC 2 examinations for as little as $5,000. Like most things, you get what you pay for. Ask who is doing the testing. Are experienced auditors reviewing evidence, or is software generating the report? Is the CPA firm signing the opinion involved in the work, or is it a separate firm signing off on someone else’s testing? Your clients’ security teams are increasingly asking the same questions.

What Does a SOC 2 Report Look Like?

A SOC 2 report is usually 50 to 150 pages and follows a consistent structure.

• Section I: Independent Service Auditor’s Report: The CPA firm’s opinion on whether the system description is fairly presented and whether controls were suitably designed (and, for a Type 2, operated effectively) to meet the applicable Trust Services Criteria.
• Section II: Management’s Assertion: A signed statement from management making the same claims the auditor is opining on.
• Section III: Description of the System: Management’s description of the services, infrastructure, software, people, processes, and data in scope. This section also lists subservice organizations (like your cloud provider) and complementary user entity controls, which are the things your clients are responsible for.
• Section IV: Trust Services Criteria, Controls, Tests of Controls, and Results: The core of the report. Each criterion is mapped to your controls, along with the auditor’s test procedures and results. In a Type 1, this section describes the controls without operating effectiveness testing.
• Section V: Other Information Provided by Management (optional): Management’s responses to exceptions, planned remediation, or additional context. The auditor doesn’t opine on this section.

Here’s a mock excerpt of what a single row in Section IV might look like

“Criterion: CC6.2. Control: Access to production systems is removed within one business day of an employee’s termination. Test performed: Obtained the population of employees terminated during the period. Selected a sample of 25 and compared termination dates per the HR system to account deactivation dates in the identity provider and production environment. Results: For 2 of 25 terminated employees sampled, production access was removed 9 and 16 days after termination. No other exceptions noted.”

That’s an exception. It doesn’t automatically mean an overall negative report. Exceptions are disclosed in Section IV, and management can respond in Section V. The question is whether exceptions are significant enough to affect the auditor’s opinion.

Opinion Types

An unmodified opinion (often called a clean or unqualified opinion) means the auditor concluded the criteria were met. A qualified opinion means the criteria were met except for a specific area. An adverse opinion means the auditor concluded the criteria were not met. A disclaimer of opinion means the auditor couldn’t obtain enough evidence to form an opinion. Most reports have an unmodified opinion, and many of those still include a few exceptions in Section IV. When you’re reading a vendor’s report, read the exceptions, not just the opinion.

Who Needs SOC 2 Compliance? Is It Mandatory?

SOC 2 isn’t required by law. No regulator will fine you for not having one. In practice, though, it’s often mandatory in the way that matters most: your clients require it. If you sell to financial institutions, healthcare organizations, or larger enterprises, a Type 2 SOC 2 is frequently a contract requirement before they’ll share data with you.

The companies we see seeking SOC 2 most often are SaaS providers, data centers, managed service providers, and payment and payroll platforms. Because SOC 2 has become the de facto U.S. standard for information security, we’re also seeing non-traditional service providers like law firms, consultancies, marketing agencies, and blockchain and crypto companies pursue it.

Most information security frameworks in the U.S. are sectoral. PCI DSS focuses on cardholder data, HIPAA focuses on protected health information, and NERC CIP focuses on the energy industry. SOC 2 is different. It isn’t tied to a specific industry or data type, which is why it has become the closest thing we have in the U.S. to a general information security standard. That flexibility is also why so many types of companies, from SaaS startups to law firms, are now being asked for one.

The purpose of a SOC 2 is to give your clients independent assurance that you’re protecting their data and the service they rely on. Before a bank outsources a process, it wants to know its clients’ data will be protected. The shift to cloud computing and outsourcing has made that question come up in nearly every vendor relationship. A SOC 2 answers it with a CPA firm’s opinion rather than your word alone.

The benefits go beyond closing deals. A SOC 2 can differentiate you from competitors who don’t have one. It replaces hours of security questionnaire responses, since many clients will accept your report in place of their questionnaire, or at least cut the questionnaire short. And the process itself tends to make your operations more consistent. We hear this from clients in year two all the time: the access reviews and change approvals they set up for the audit caught real issues they would have missed otherwise.

The consequences of not having one usually show up in the sales pipeline. Deals stall in security review, procurement teams move on to a competitor that has a report, or one person on your team ends up spending a large part of their week answering questionnaires.

One thing a SOC 2 doesn’t do is guarantee data security. No audit can. A SOC 2 means an auditor tested your internal controls against the criteria and reported the results. It shows you’re doing the fundamentals of an information security program well, which is exactly what your clients want to know.

SOC 1 vs. SOC 2 vs. SOC 3

Companies often aren’t sure which SOC report they need. When a prospective client calls us, we start with two questions: who is asking for the report, and what service do you provide to them?

• SOC 1 is for service organizations whose services can affect their clients’ internal control over financial reporting. Think payroll processors, claims administrators, or loan servicers. The audience is usually your clients’ financial auditors and controllers. See What Is a SOC 1 Report?
• SOC 2 is for service organizations whose services affect the security, availability, processing integrity, confidentiality, or privacy of their clients’ data. The audience is usually your clients’ security, IT, and vendor risk teams. Some organizations need both. A payroll SaaS platform, for example, might get a SOC 1 for its clients’ auditors and a SOC 2 for their security teams.
• SOC 3 is a general-use version of a SOC 2. It includes the auditor’s opinion and a high-level description, but it leaves out the detailed controls and test results that could be useful to an attacker. That makes it suitable for posting on your website as a trust signal. See our comparison of SOC 2 vs. SOC 3.

Can You Have a SOC 3 Without a SOC 2?

No, a SOC 3 must be issued alongside a SOC 2 because the SOC 2 testing supports both. Most clients who see your SOC 3 will still ask for the full SOC 2. The SOC 3 is more of a marketing tool than a compliance report. It says to prospects that you have an unqualified SOC 2.

Is SOC 1 or SOC 2 Harder?

Neither is inherently harder. Difficulty depends on scope and how mature your controls are. A SOC 2 covering all five Trust Services Criteria for a complex environment will take more effort than a narrow SOC 1, and the reverse is also true. The better question is which report your clients need.

Frequently Asked Questions About SOC 2

We are used to receiving questions about SOC 2 compliance. Below are a few of the common questions we hear.

Is ISO 27001 the same as SOC 2?

No. ISO 27001 is an international certification of your information security management system, issued by an accredited certification body. SOC 2 is a U.S. attestation report issued by a CPA firm with detailed test results. Many controls overlap, so companies often pursue both and reuse evidence across audits. Read more about ISO standards.

Does SOC 2 Mean HIPAA Compliant?

No. SOC 2 doesn’t evaluate HIPAA requirements on its own. However, a SOC 2 can be expanded to map controls to the HIPAA Security Rule, often called SOC 2 + HIPAA. That approach gives healthcare clients one report covering both sets of requirements.

How Hard Is It to Get SOC 2?

It depends on where you’re starting. A company with documented policies, MFA, access reviews, and formal change management may need only light remediation. A startup with none of those in place will need several months of work. The hardest part for most companies is consistency, performing controls every time over the full period.

Who Is Responsible for the Accuracy of a SOC 2 Report?

Both the service organization and the auditor. Management is responsible for the system description and its assertion, so read Sections III and IV carefully before the report is issued. The auditor is responsible for testing and the opinion. CPA firms performing SOC audits also go through AICPA peer review every three years, where reports and workpapers are reviewed against professional standards.

Final Thoughts on SOC 2 Compliance

A SOC 2 is a CPA firm’s report on whether your controls meet the Trust Services Criteria you’ve chosen, with security always included. Pick the criteria your clients care about, decide between a Type 1 and Type 2 based on what they’ll accept, and give yourself enough runway for readiness and remediation. Most of the pain we see comes from rushing those first steps.

If you have questions about SOC 2 reports, whether you need one, or what Linford & Company’s SOC 2 audit process looks like, please contact me to discuss.

This article was originally published on 11/22/2017 and was updated on 10/13/26.