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

Module 0: Why SOC 2 Exists

Before we dive into the acronyms, let's establish first principles.

Imagine this thought experiment: You walk into a brand new, highly-rated restaurant. You sit down, and the waiter tells you, "Our kitchen is the cleanest in the city. You can trust us."

Do you just take their word for it? What if the chef just dropped a steak on the floor, wiped it off, and threw it on the grill? You have no idea. You are trusting the waiter's word. That is called blind trust.

But what if, before you walked in, you saw an "A" grade from the city Health Department proudly displayed in the window?

Suddenly, you don't have to blindly trust the waiter. You have a third-party attestation that the restaurant follows strict cleanliness standards. An independent inspector looked at their processes and verified them.

As an enterprise buyer or a Web3 protocol relying on off-chain infrastructure, you cannot afford to just "trust" a vendor. You need proof. You need a health inspection.

That is exactly why SOC 2 exists. It is the health inspection of the tech world.

Module 1: What is SOC 2?

SOC 2 stands for System and Organization Controls 2. It is a framework created by the AICPA (American Institute of Certified Public Accountants).

At its core, a SOC 2 is an independent auditor's report detailing how a cloud-based service provider handles sensitive information.

Why do enterprises ask for it?

Enterprises are legally and ethically responsible for their customers' data. If a massive bank uses a small SaaS startup to process data, and the startup gets breached, the bank's customers don't care about the startup. They care that the bank failed them.

Therefore, enterprise procurement teams require SOC 2 as "table stakes." If you do not have a SOC 2 report, the enterprise will simply not buy your software. It is a massive friction point in B2B sales.

Module 2: SOC 2 Type I vs. SOC 2 Type II

There are two types of SOC 2 reports. The difference between them is the most fundamental concept you need to grasp.

SOC 2 Type I: Point in Time

A Type I report evaluates your organization at a single point in time. It answers the question: "Are your security controls designed correctly today?"

Going back to our restaurant analogy: The health inspector walks in on Tuesday at 2:00 PM, takes a photograph of the kitchen, checks the employee handbook, and verifies everything is clean right at that second.

Example: A startup writes a policy saying "All employees must have Two-Factor Authentication (2FA) enabled." On the day of the Type I audit, the auditor checks the system and verifies that all current employees have 2FA turned on.

SOC 2 Type II: Observation Period

A Type II report evaluates your organization over an observation period (usually 3, 6, or 12 months). It answers the question: "Are your security controls operating effectively over a sustained period?"

Restaurant analogy: The health inspector watches the kitchen via CCTV for 6 months. They verify that the kitchen was clean every single day, employees washed their hands every single time, and the fridge was never left open.

Example: During a 6-month Type II window, the company hired 10 new people and fired 2. The auditor will check if all 10 new hires got 2FA turned on immediately, and if the 2 fired employees had their access revoked within 24 hours.

Comparison Table

Module 3: Trust Services Criteria (TSC)

When an auditor evaluates a company, what exactly are they measuring against? They use the AICPA's Trust Services Criteria (TSC). There are five categories. An organization can choose which criteria they want to be audited against, but Security is mandatory.

1. Security (Common Criteria) - REQUIRED

The baseline. This criterion ensures the system is protected against unauthorized access (both physical and logical). It covers firewalls, multi-factor authentication, intrusion detection, and background checks.

2. Availability

Is the system up and running as promised? This covers network performance, downtime mitigation, disaster recovery plans, and handling high load.
Example: An AWS region goes down. Does your startup have a failover to another region?

3. Confidentiality

Data is restricted to a specified set of persons or organizations. This applies to company secrets, IP, and business data.
Example: Ensuring internal engineers cannot read the plaintext contents of a client's proprietary database.

4. Processing Integrity

System processing is complete, valid, accurate, timely, and authorized.
Web3 Example: If an off-chain relayer network is taking transactions, are those transactions processed accurately without being dropped or maliciously altered?

5. Privacy

Personal information is collected, used, retained, disclosed, and disposed of in conformity with the organization's privacy notice.
Example: Complying with user data deletion requests (similar to GDPR requirements).

Module 4: Controls

You will hear the word "Control" hundreds of times. What is it?

A Control is a rule, process, or mechanism you put in place to mitigate a risk.

If the risk is "A hacker guesses a password," the control is "Require Multi-Factor Authentication (MFA)."

Common Examples of Controls

Module 5: Evidence Collection

Here is the golden rule of auditing:

"If it isn't documented, it didn't happen."

Auditors are professional skeptics. If you say "We disable access when an employee is fired," the auditor will say, "Prove it."

This is where Evidence Collection comes in. To prove your controls are working, you must provide artifacts to the auditor.

Examples of Evidence:

• Screenshots: A screenshot of your AWS IAM settings showing that password policies require 14 characters.
• Logs: A CloudTrail log showing who accessed a specific S3 bucket.
• Tickets: A Jira ticket showing that an engineer requested database access, and a manager approved it in the comments.
• GitHub History: A link to a Pull Request showing the green checkmark of a peer approval before the merge.
• Policies: The actual PDF of your Employee Handbook that new hires sign.

Module 6: The SOC 2 Journey

Getting a SOC 2 report is not a weekend project. It is a grueling marathon that touches every department in a company.

[ Readiness Assessment ] 
        ↓
[ Gap Remediation ] 
        ↓
[ Type I Audit (Optional but common) ] 
        ↓
[ Observation Period (3-12 Months) ] 
        ↓
[ Type II Audit & Evidence Collection ] 
        ↓
[ Report Issuance ]
        

1. Readiness Assessment: You hire a consultant or use software to figure out how far away you are from compliance. You realize you have 50 things to fix.
2. Gap Remediation: You spend 2 months implementing MFA, writing policies, encrypting laptops via MDM, and locking down AWS.
3. Observation Period: You live with these new rules. You actually do the access reviews. You actually enforce PR reviews. (This is the hardest part).
4. External Auditor: The CPA firm requests evidence, does interviews, and checks your work.
5. Report Issuance: You receive the final PDF report. You can now send it to enterprise buyers (usually under an NDA).

Module 7: How Auditors Test Controls

Let's get into the mind of an auditor. When evaluating a Type II report over 6 months, they don't look at every single thing that happened. They use statistical sampling.

Population and Sampling

If your control says "All code changes require a PR review," the auditor will ask for the Population: a list of all 500 code changes made in the last 6 months.

From that population, they will select a random Sample of 25 code changes. You must provide evidence (links to the PRs) for those specific 25.

Exceptions

What if one of those 25 PRs was merged by the CTO at 2 AM without a review to fix a critical bug? That is an Exception.

An exception doesn't mean you fail the audit! Auditors understand reality. But they will ask for an explanation. "We had an emergency P0 incident, here is the incident ticket."

Deficiencies

If there are too many exceptions (e.g., 10 out of 25 PRs had no review), the auditor will mark it as a Deficiency. If the deficiency is massive, it becomes a Material Weakness, meaning the control completely failed.

Module 8: Reading a SOC 2 Report

A SOC 2 report is typically 40 to 100 pages long. When a customer receives it, they skip straight to Section 1 to read the auditor's opinion.

The Four Types of Opinions:

• Unqualified Opinion: The holy grail. The auditor states everything is presented fairly and controls are working. (Counter-intuitively, "unqualified" means good—it means without qualifications or caveats).
• Qualified Opinion: Mostly good, but there was a significant deficiency in one area. (e.g., "Everything is secure, EXCEPT their background checks were missing").
• Adverse Opinion: Failure. Controls are completely ineffective.
• Disclaimer of Opinion: The auditor couldn't get enough evidence to even make a judgment.

Audit Scope

Customers must also read the Scope. If a mega-corporation has 50 software products, but their SOC 2 report only covers 1 specific product, you cannot assume the other 49 products are secure.

Module 9: Common Misconceptions

SOC 2 is powerful, but it is often misunderstood. Let's clear the air.

• SOC 2 is NOT hack-proof. Countless companies with pristine SOC 2 reports get breached. It proves you have a seatbelt; it doesn't mean you can't get in a car crash.
• SOC 2 is NOT a penetration test. A pen test is when ethical hackers try to break into your app. A SOC 2 auditor doesn't hack you. (Though, doing an annual pen test is usually a required control within SOC 2).
• SOC 2 is NOT formal verification. It does not mathematically prove your code is bug-free.
• Compliance Theater: This is a massive risk. A company might have a policy saying "We review all code," but engineers just blindly hit "Approve" without reading the code to satisfy the auditor. The control passes the audit, but the security is zero. That is compliance theater.

Module 10: Chainlink Labs Case Study

Let's apply all this theory to a real-world Web3 example: Chainlink Labs.

Chainlink Labs first achieved SOC 2 Type I attestation and ISO/IEC 27001:2022 certification in August 2025. The examinations were performed by Deloitte & Touche LLP, and covered Chainlink Data Feeds (specifically Price Feeds and SmartData, which includes Proof of Reserve and Net Asset Value) and the Cross-Chain Interoperability Protocol (CCIP). This made Chainlink the first data and interoperability oracle platform to hold both certifications.

The story didn't stop at Type I. In April 2026, Deloitte completed a full SOC 2 Type II examination across that same scope: CCIP and Data Feeds. This is a materially bigger claim than Type I alone, because Type II verifies that controls actually operated effectively over a sustained period of live production use, not just that they were well-designed on a single audit day. With this milestone, Chainlink became the only oracle platform holding SOC 2 Type I, SOC 2 Type II, and ISO 27001 simultaneously, a combination no other oracle network has matched as of this writing.

But what does this actually mean in a Web3 context? To understand this, we must separate Organizational Trust from Protocol Trust.

Organizational Trust vs. Protocol Trust

Protocol Trust relies on math, cryptography, consensus mechanisms, and game theory. You trust the decentralized oracle network (DON) because of cryptoeconomic security and decentralization, not because of a paper attestation.

Organizational Trust relies on the maturity, security, and operational excellence of the humans building the software.

What the SOC 2 Attestation Proves:

The SOC 2 Type I and Type II attestations prove that Chainlink Labs (the organization) has mature, enterprise-grade security controls, designed correctly and, as of the Type II result, consistently operated over an extended production window, verified by a Big Four accounting firm. It proves that when Chainlink Labs engineers write code for CCIP or Price Feeds, they follow strict change management, peer review, access control, and vendor management, and that they kept following those practices over time rather than just on the day of the audit.

What the SOC 2 Attestation Does NOT Prove:

It does not prove oracle manipulation resistance. It does not prove cryptoeconomic security. It does not guarantee consensus. Those are guarantees provided entirely by the decentralized protocol's own design and economic incentives, not by an auditor's report on corporate policies.

Why this matters in practice: For a bank or asset manager running vendor risk review before deploying capital through tokenized assets on-chain, the SOC 2 Type II result is not a marketing claim, it's the specific document their compliance team requires before they're permitted to sign off on a vendor. With Type II, Chainlink Labs now clears the same procurement bar institutions already demand from cloud vendors like AWS. That's a genuine unlock for institutional adoption. It is a claim about organizational discipline, though, not a claim about the oracle network's resistance to attack, and the two are worth keeping separate whenever you see "SOC 2" used as shorthand for "secure" in a crypto context.

Module 11: Expert Takeaways

If you take away five things from this bootcamp, make them these:

1. Start Early: Do not wait until an enterprise buyer asks for a SOC 2 to start. It takes months to achieve. It will block your sales.
2. Automate: Evidence collection is painful. Use compliance automation platforms to hook into your APIs and collect evidence automatically.
3. Scope Carefully: Don't try to audit everything on day one. Scope your SOC 2 down to the specific systems handling critical customer data.
4. Culture > Compliance: Avoid compliance theater. A SOC 2 report doesn't secure your app; a culture of engineers who actually care about security secures your app.
5. It's Continuous: SOC 2 Type II is an annual recurring audit. You can't just pass it and forget about it. It is a permanent lifestyle change for a company.

Glossary

A suite of service organization reporting options defined by the AICPA.

The framework used to evaluate controls. Includes Security, Availability, Confidentiality, Processing Integrity, and Privacy.

An audit report reflecting the design of controls at a specific point in time.

An audit report reflecting the operating effectiveness of controls over an observation period.

The complete set of items (like all git commits) an auditor can draw from to test a control.

Selecting a subset of a population to represent the whole during an audit test.

An instance where an established control was bypassed or failed.

A policy, procedure, or technical mechanism put in place to mitigate a specific risk.

Artifacts (logs, screenshots, tickets) provided to the auditor to prove a control exists and works.

The span of time (usually 3-12 months) covered by a Type II report.

A severe deficiency indicating that a control has failed entirely, leading to a modified auditor opinion.

An independent declaration by a CPA firm that your controls meet the specified criteria.