SOC 2 Type I & Type II: A Complete Beginner-to-Expert Guide

Why SOC 2 Exists

Before the acronyms, start with a thought experiment.

You walk into a new restaurant. The waiter tells you, "Our kitchen is the cleanest in the city, you can trust us." Do you just take their word for it? You have no way to check. That's blind trust.

Now imagine instead that you see an "A" grade from the city Health Department in the window before you even sit down. You no longer have to take the waiter's word for it. An independent inspector looked at the kitchen and verified it against a standard.

In B2B software, cloud infrastructure, and Web3, companies handle your sensitive data and run your critical logic. When a startup says "we have bank-grade security," they're playing the role of the waiter. As a buyer, or as a protocol relying on someone else's infrastructure, you can't operate on blind trust at scale. You need the health inspection. That's what SOC 2 is.

What SOC 2 Actually Is

SOC 2 stands for System and Organization Controls 2, a framework created by the AICPA (American Institute of Certified Public Accountants). It's an independent auditor's report on how a service provider handles sensitive data.

People constantly say "we're SOC 2 certified." That's technically wrong, there's no SOC 2 certificate. SOC 2 is an attestation: an independent CPA firm reviews your systems and attests that your security controls are designed properly and operating effectively. The distinction matters more than it sounds like it should, because procurement teams at large enterprises treat it as table stakes. No SOC 2 report, no deal. That single requirement creates a lot of friction in B2B sales, which is exactly why it exists as a category.

Type I vs Type II

This is the concept that actually matters most, so get it solid.

Type I evaluates your organization at a single point in time. It answers: are your controls designed correctly today? Back to the restaurant: the inspector walks in Tuesday at 2pm, checks the kitchen, and confirms everything is clean right now.

If your policy says "all employees must have 2FA enabled," a Type I audit checks that right now, every current employee has it on.

Type II evaluates your organization over an observation period, usually 3 to 12 months. It answers a harder question: do your controls hold up over time, under real operating conditions? This is the inspector watching the kitchen on camera for six months, confirming the floor got mopped every night, not just the night they happened to visit.

If you hired 10 people and fired 2 during that window, a Type II audit checks whether all 10 new hires got 2FA turned on immediately, and whether the 2 departures had their access revoked fast.

	Type I	Type II
Timeframe	A specific date	3-12 month observation period
Proves	Controls are designed correctly	Controls actually operate effectively
Effort	Moderate	High, requires sustained compliance
Enterprise weight	Fine for early-stage B2B sales	The actual bar for serious enterprise deals

If you remember nothing else from this guide: Type I is a snapshot, Type II is a track record. Most experienced buyers know this and discount a Type I-only vendor accordingly.

The Five Trust Services Criteria

Auditors test you against the AICPA's Trust Services Criteria. There are five categories, and you choose which ones apply to your business, except Security, which is mandatory for everyone.

Security (Common Criteria), required. The baseline: protection against unauthorized access, physical and logical. Firewalls, MFA, intrusion detection, background checks.

Availability. Is the system up when it's supposed to be? Covers failover, disaster recovery, load handling. If an AWS region goes down, do you have a path to another region?

Confidentiality. Data restricted to a specified set of people or organizations. Can your own engineers read a client's proprietary database in plaintext when they shouldn't be able to?

Processing Integrity. Is processing complete, valid, accurate, timely, and authorized? In a Web3 context: if an off-chain relayer network is moving transactions, are they processed accurately, without silent drops or tampering?

Privacy. Personal data collected, used, retained, and disposed of according to your stated privacy notice. Roughly GDPR-shaped obligations around deletion requests.

Don't try to cover all five on a first SOC 2. Security is required. Add Availability or Confidentiality only if your customers are actually asking for them.

Controls, Plainly

A control is a rule, process, or mechanism that mitigates a specific risk. If the risk is "a hacker guesses a password," the control is "require MFA."

A few concrete examples:

• Logical access: all employees use MFA for internal systems, so a leaked password alone isn't enough to get in.
• Least privilege: engineers get production database access only when their job requires it, which limits the blast radius if a laptop is stolen.
• Access reviews: quarterly review of AWS IAM users, which is how you catch the ghost account a fired employee left behind.
• Change management: every push to main needs approval from another engineer, so one person can't quietly slip in a backdoor.
• Incident response: a tested, written plan, so the team isn't improvising at 3am during a live exploit.
• Vendor management: reviewing the SOC 2 reports of your own critical vendors, since your security is only as good as theirs.

As a developer, this is where SOC 2 stops being abstract. You can't force-push to main anymore. You can't SSH into production "just to look" without a logged ticket. The controls add friction on purpose. That friction is the security.

Evidence Collection

The operating principle auditors work by: if it isn't documented, it didn't happen.

Auditors are professional skeptics. Tell them "we disable access the day someone's fired" and the response is "show me." That's what evidence collection is for, providing the artifacts that prove a control is real and working, not just written down somewhere.

What counts as evidence: a screenshot of your AWS IAM password policy, a CloudTrail log of who accessed a specific S3 bucket, a Jira ticket where a manager approved a database access request in the comments, a GitHub PR with the green checkmark of a peer review before merge, the signed PDF of your employee handbook.

Companies used to keep folders with thousands of manually-collected screenshots. Now platforms like Vanta, Drata, and Sprinto pull this evidence automatically by integrating directly with AWS, GitHub, and Google Workspace.

The SOC 2 Journey

Getting a SOC 2 report touches every team in the company, and it's slow by design.

Readiness Assessment
        ↓
Gap Remediation
        ↓
Type I Audit (optional, but common)
        ↓
Observation Period (3-12 months)
        ↓
Type II Audit and Evidence Collection
        ↓
Report Issuance

A readiness assessment usually surfaces more gaps than you expect. Gap remediation is where you spend a couple of months turning on MFA everywhere, writing the policies you've never had, encrypting laptops via MDM, locking down AWS. The observation period is the hardest part: you actually have to live by the new rules, not just have them on paper. The external auditor then requests evidence, runs interviews, and checks your work before issuing the final report, which you send to enterprise buyers, almost always under NDA.

How Auditors Actually Test Controls

Over a six-month Type II window, an auditor doesn't check every single event. They sample.

If your control is "all code changes require a PR review," the auditor asks for the population: every code change in the period, say 500 of them. From that, they pull a random sample, maybe 25, and you provide evidence for those specific 25.

If one of those 25 turns out to be a CTO emergency merge at 2am with no review, that's an exception. An exception doesn't automatically fail the audit. Auditors expect reality to be messy. What they want is an explanation: "P0 incident, here's the ticket." But if 10 out of 25 PRs had no review, that's no longer an isolated exception, it's a deficiency. A severe enough deficiency becomes a material weakness, meaning the control failed outright.

Worth being precise about what this is actually checking, especially if you're coming from a smart contract security background like I am. A smart contract audit looks for logical bugs and exploitable code paths. A SOC 2 audit looks for process compliance. The SOC 2 auditor doesn't care whether your Solidity is safe. They care whether you followed your own rule requiring two reviewers before deploying it.

Reading the Actual Report

A SOC 2 report typically runs 40 to 100 pages. Anyone receiving one skips straight to the auditor's opinion.

There are four possible opinions. Unqualified is the one you want, and counterintuitively the name doesn't sound like good news: it means the auditor found nothing requiring a caveat, everything checks out. Qualified means mostly fine, but with a real deficiency somewhere specific. Adverse means the controls failed. Disclaimer of opinion means the auditor couldn't even gather enough evidence to render a judgment.

Scope matters just as much as the opinion. If a company has 50 products but the SOC 2 report only covers one, you cannot extend that assurance to the other 49. Read the scope section before you read anything else.

What SOC 2 Doesn't Mean

A few corrections worth making explicitly, because the misunderstandings are common and they matter.

SOC 2 doesn't mean a company can't be hacked. Plenty of breached companies had clean SOC 2 reports going in. It's a seatbelt, not a guarantee against crashes.

SOC 2 isn't a penetration test. A pen test is someone actively trying to break in. A SOC 2 auditor checks process, not exploitability, though an annual pen test is often itself one of the controls being checked.

SOC 2 isn't formal verification. It says nothing mathematically provable about whether your code is bug-free.

And compliance theater is a real risk: a company can have a policy that says "we review all code" while engineers rubber-stamp every PR without reading it. The control technically passes. The security it was supposed to provide is zero.

Chainlink Labs: A Real Case Study

Here's where this gets directly relevant if you follow Web3 infrastructure.

Chainlink Labs first achieved SOC 2 Type 1 attestation and ISO/IEC 27001:2022 certification in August 2025, covering Chainlink Data Feeds (Price Feeds and SmartData, including Proof of Reserve and Net Asset Value) and CCIP, with the examination performed by Deloitte & Touche LLP. That made Chainlink the first data and interoperability oracle platform to hold both certifications.

The story didn't stop there. In April 2026, Chainlink went further: Deloitte completed a full SOC 2 Type 2 examination across the same core scope, CCIP and Data Feeds. That's a meaningfully bigger claim than the Type 1 attestation alone, since Type 2 means those controls were tested for sustained operating effectiveness over months of real production use, not just verified as well-designed on a single day. As of that milestone, Chainlink became the only oracle platform holding SOC 2 Type 1, SOC 2 Type 2, and ISO 27001 simultaneously, a combination no competing oracle network has matched.

So what does this actually prove, and what doesn't it prove? This is where most people, including a lot of the original framing I'd drafted for this piece, get sloppy if they don't separate two very different kinds of trust.

Protocol trust comes from cryptography, consensus, and game theory. You trust a decentralized oracle network because of how it's built to resist manipulation by independent node operators with skin in the game, not because anyone signed a piece of paper about it.

Organizational trust comes from the maturity and discipline of the people and processes building the software. Chainlink Labs is a primary contributing developer to the Chainlink protocol, but Chainlink Labs is not the protocol itself.

The SOC 2 attestation, Type 1 or Type 2, proves the second kind of trust. It proves that when Chainlink Labs engineers ship code for CCIP or Data Feeds, they follow strict change management, peer review, access control, and vendor management, and now, with Type 2, that they kept following those practices consistently over an extended production window, verified by a Big Four firm.

It does not prove oracle manipulation resistance. It does not prove cryptoeconomic security. It says nothing about consensus guarantees. Those still come entirely from the protocol's own design, the DON architecture and the economic incentives behind it, not from an auditor's signature on a corporate controls report.

What the Type 2 milestone does prove, in practical terms, is that Chainlink Labs now clears the same procurement bar that institutions already demand from cloud vendors like AWS. For a bank or asset manager doing vendor risk review before touching tokenized assets on-chain, that's not a marketing claim, it's the specific document their compliance team is required to see before they're allowed to sign anything. That's a real unlock for institutional adoption. It's just not the same thing as a guarantee about the oracle network's resistance to attack, and worth keeping those two claims separate the next time you see "SOC 2" used as shorthand for "secure" in a crypto context.

Five Things to Actually Remember

If five things from this stick, make it these.

Start early. Don't wait until an enterprise buyer demands a SOC 2 before you begin, it takes months and will stall your sales pipeline in the meantime.

Automate evidence collection. Doing it manually is genuinely painful, and the tooling for this is mature now.

Scope carefully. Don't try to audit your entire company on day one, scope it to the systems actually touching sensitive customer data.

Culture beats compliance. A SOC 2 report doesn't secure your application. Engineers who actually care about security do. Compliance theater is what happens when you mistake the report for the substance.

It's continuous, not a one-time pass. Type II is a recurring annual audit. You don't pass it once and move on, it's a permanent operating constraint.

Glossary

SOC (System and Organization Controls): the AICPA's suite of service organization reporting standards.

TSC (Trust Services Criteria): the framework auditors test against, Security, Availability, Confidentiality, Processing Integrity, Privacy.

Type I: an audit reflecting control design at one specific point in time.

Type II: an audit reflecting control operating effectiveness over a sustained observation period.

Population: the full set of items, like all commits in six months, an auditor can sample from.

Sampling: pulling a representative subset of the population to test instead of checking everything.

Exception: a single instance where a control was bypassed or failed.

Control: a policy, procedure, or technical mechanism that mitigates a specific risk.

Evidence: the logs, screenshots, and tickets that prove a control exists and actually works.

Observation period: the 3-12 month window a Type II report covers.

Material weakness: a deficiency severe enough that a control is considered to have failed entirely.

Attestation: an independent CPA firm's declaration that your controls meet a stated standard.

Resources

• AICPA Official SOC 2 Guidelines
• AWS SOC Compliance Resources
• Chainlink Labs Achieves SOC 2 Type 1 and ISO 27001 (Aug 2025)
• Chainlink's Institutional-Grade Security and Compliance Page
• Vanta Compliance Automation
• Drata Continuous Compliance
• Sprinto Compliance Software

---

I'm a smart contract security researcher writing through Web3 infrastructure and compliance topics as part of a daily series. Follow along at X @0xramprasad.