In March 2026, an anonymous Substack writer called "DeepDelver" published a bombshell: Delve, a Y Combinator-backed compliance automation startup that raised $32 million, was accused of systematically faking SOC 2 audit reports for hundreds of clients. The allegations were specific — 493 out of 494 reports used the same boilerplate text, including the same grammatical errors and nonsensical descriptions. Auditor reports appeared to be fully written before clients submitted any evidence. By April 3, Y Combinator had removed Delve from its companies directory and asked the founders to leave.
The scandal exposed a problem that's been lurking in the compliance industry for years: buyers accept SOC 2 reports at face value without understanding what a real audit actually involves. If you don't know what auditors are supposed to examine, you can't tell the difference between a legitimate report and a template with a logo slapped on it.
This is the SOC 2 checklist that auditors work from — the actual control areas they examine, the evidence they request, and what "operating effectively" actually means in practice.
When evaluating a vendor's SOC 2 report, check the audit firm name against the AICPA's licensed CPA firm directory. Legitimate SOC 2 audits are conducted by licensed CPA firms. Also verify the report covers a meaningful observation period (Type II) and that the scope matches the systems and services you're relying on. A report scoped to a single internal tool doesn't cover the product you're buying.
SOC 2 basics: what the framework actually is
SOC 2 stands for System and Organization Controls 2. It's a framework developed by the AICPA (American Institute of Certified Public Accountants) for evaluating whether a service organization's controls adequately protect the data it handles on behalf of customers. Unlike ISO 27001, it's not a certification — it's an attestation. A CPA firm audits your controls and issues a report. The report says what they examined, what they found, and whether they believe your controls are suitably designed and operating effectively.
Two types of reports matter in practice:
Type I — Point-in-Time
Assesses whether controls are suitably designed as of a specific date.
Faster to obtain — typically 4–8 weeks once documentation is ready.
Less persuasive to enterprise buyers. Shows controls exist, not that they work consistently.
Type II — Operating Period
Assesses whether controls operated effectively over a defined period — typically 6 to 12 months.
The standard enterprise buyers require. Shows sustained compliance, not just audit-day compliance.
Full timeline from scratch: 9–18 months.
Most enterprise procurement teams won't accept a Type I report as sufficient for ongoing vendor approval. If you're targeting enterprise sales, you need Type II — and you need to start the observation period early enough to have it ready when deals require it.
The five Trust Services Criteria
SOC 2 auditors evaluate your controls against the AICPA Trust Services Criteria. Security is mandatory for every SOC 2 report. The other four are optional, included based on what commitments your organization makes to customers.
Security (CC1–CC9)
The core of every SOC 2. The Security criteria map across nine Common Criteria (CC) categories — from control environment and risk assessment to logical access, system operations, and change management. This is where the bulk of audit work happens.
Auditors examine: organizational structure and accountability, risk assessment processes, logical and physical access controls, security monitoring and incident response, and change management procedures. All of it.
Availability (A1)
If you commit to uptime SLAs in customer agreements, include this criterion. Auditors will examine your capacity planning, performance monitoring, disaster recovery plan, backup procedures, and incident response as it relates to availability. They'll look for evidence that your systems actually met your stated availability commitments during the observation period.
Processing Integrity (PI1)
Relevant if you process transactions, financial data, or any workflow where complete and accurate processing is a customer commitment. Auditors examine whether your system processes data completely, accurately, in a timely manner, and with appropriate authorization. Common in fintech, payroll, and data processing services.
Confidentiality (C1)
If you commit to keeping certain data confidential — beyond just secure — include this. Auditors examine your data classification procedures, how confidential data is identified and labeled, access restrictions specific to confidential data, and disposal procedures when the data is no longer needed.
Privacy (P1–P8)
Covers the collection, use, retention, disclosure, and disposal of personal information consistent with your privacy notice and applicable law. If you're already GDPR or HIPAA compliant, much of this overlaps — but auditors will specifically examine your privacy notice, consent procedures, data subject rights processes, and how personal data is disposed of at end of retention.
Check your SOC 2 policies before the audit does
PolicyAudit scans your security policies, incident response procedures, and privacy documents against SOC 2 Trust Services Criteria. Find gaps before your auditor does — free for up to 3 documents.
Scan your policies for SOC 2 gaps →What auditors actually examine — the evidence list
Here's where organizations get surprised. Auditors don't accept written policies as proof that controls work. Policies establish intent. Evidence demonstrates operation. In 2026, auditors increasingly require system-generated logs and audit trails over screenshots and verbal explanations.
For each control area, here's what auditors request:
Access control and identity management
This is the area that generates the most audit findings. Auditors examine:
- User access provisioning logs — who was granted access, when, and who approved it
- Access review records — evidence that you periodically reviewed user access and removed unnecessary permissions (quarterly or semi-annual reviews are standard)
- MFA enforcement — system-generated evidence that MFA is required, not just configured
- Privileged access management — separate accounts or controls for admin-level access
- Terminated employee access revocation — evidence that access was removed within your policy's defined timeframe after offboarding
- Least privilege evidence — that users have only the access their role requires, not blanket admin rights
The offboarding gap is where many audits find exceptions. An employee leaves, HR processes it, but the IT access removal takes weeks. That gap shows up in the access review logs.
Change management
Auditors examine your change management process for production systems — how changes are requested, reviewed, tested, and approved before deployment. They want:
- A documented change management policy defining the process and approval requirements
- Ticketing records or deployment logs showing that changes went through the process
- Separation of duties evidence — the person who wrote the code didn't also approve and deploy it
- Emergency change procedures — how you handle urgent fixes outside normal process, with compensating controls
- Rollback procedures
Small teams frequently have separation of duties issues. A two-person engineering team where both members can approve each other's deployments is a control gap. Document compensating controls — post-deployment review, peer code review requirements, or manager sign-off — if full separation isn't feasible.
Risk assessment
Auditors want evidence that you have a formal process for identifying, evaluating, and responding to security risks — not just a one-time exercise, but something you do periodically. They look for:
- A documented risk assessment or risk register
- Evidence the assessment was conducted during the audit period (not three years ago)
- Treatment decisions for identified risks — accepted, mitigated, or transferred
- Linkage between risk assessment findings and control implementation
Incident response
You need a documented incident response plan and evidence it's been tested or exercised. Auditors look for:
- Incident response policy and procedures document
- Defined severity classification and escalation procedures
- Incident tracking records from the audit period — even minor incidents should be logged
- Evidence of tabletop exercises or simulations
- Post-incident review records for significant events
If you had zero incidents during the audit period and zero incident records, auditors will question whether your detection and logging capabilities are actually working.
Vendor and third-party management
The Delve scandal is a perfect example of why this matters. If your vendors have security failures, those failures become your problem. Auditors examine:
- A vendor inventory listing all third parties with access to your systems or customer data
- Vendor risk assessments — how you evaluate new vendors before onboarding them
- Executed agreements with security provisions (data processing agreements, BAAs, security addenda)
- Periodic review of critical vendor compliance — do they still have SOC 2? Is it current?
- Evidence of ongoing monitoring for critical vendors, not just point-in-time review
In 2026, auditors are increasingly asking for evidence of continuous vendor monitoring rather than annual review cycles. If a key vendor's SOC 2 lapsed mid-period and you didn't catch it, that's a finding.
Security training and awareness
Every employee who touches customer data or systems must receive security awareness training. Auditors want:
- Training completion records showing which employees completed training and when
- Evidence of onboarding training for new hires
- Annual or recurring training records across the audit period
- Training content that addresses relevant threats (phishing, social engineering, data handling)
In 2026, SOC 2 auditors are beginning to ask about AI governance controls — particularly for organizations using AI in customer-facing processes or automated decision-making. This includes controls around algorithmic bias, data poisoning risks, and explainability of AI-driven decisions. If your product uses AI, document your AI governance approach now. It's becoming a standard line of inquiry even when AI governance isn't formally in scope.
The policies you need in writing before you start
SOC 2 auditors expect documented policies for each control area. Not a wiki page — formal, version-controlled documents with a clear owner, approval date, and defined review cadence. Here's the policy inventory most auditors check:
- Information Security Policy (overall security program)
- Access Control Policy (user provisioning, least privilege, access reviews, offboarding)
- Change Management Policy (how system changes are reviewed and approved)
- Incident Response Plan (detection, classification, response, escalation, post-mortems)
- Vendor Management Policy (due diligence, ongoing review requirements)
- Risk Assessment Policy (frequency, methodology, treatment decisions)
- Data Classification Policy (what's confidential, restricted, public)
- Business Continuity and Disaster Recovery Plan (RPO/RTO targets, recovery procedures)
- Acceptable Use Policy (workforce obligations for systems and data)
- Vulnerability Management Policy (scanning frequency, patch timelines by severity)
- Encryption Policy (data at rest and in transit standards)
- Physical Security Policy (if applicable to your infrastructure)
Each policy needs to be approved by management, distributed to relevant personnel, and reviewed on a defined cadence (annually is standard). Evidence of the approval and distribution matters as much as the policy content itself.
Running your policy drafts through PolicyAudit before the audit is one of the fastest ways to identify gaps — it checks your documents against SOC 2 requirements and flags vague or incomplete sections that auditors will question.
Common reasons SOC 2 audits find exceptions
These are the control failures that show up most frequently in SOC 2 audit exceptions:
- Stale access: Terminated employees or contractors whose access wasn't revoked on time. Auditors sample termination events and verify revocation timestamps against HR records.
- Access review gaps: You have an access review policy that says quarterly — but evidence only exists for two of four quarters during the audit period. The gap is an exception.
- Undocumented changes: Changes to production systems that bypassed the change management process, even for urgent fixes. If it's not in your ticketing system, auditors treat it as a control failure.
- No incident records: If your SIEM or logging system generated zero alerts during the entire observation period, auditors question whether the detection controls are actually working.
- Training gaps: Employees hired during the audit period who didn't complete security training within your defined onboarding window.
- Vendor with expired SOC 2: A critical vendor's SOC 2 lapsed and you didn't detect it during your vendor review cycle.
Don't start operating controls on the day the audit period begins. Start at least a month early. Your first access review, your first training completion batch, your first vendor review — all of it should happen before the formal observation period starts so you have time to find and fix gaps without those gaps appearing in the audit evidence.
Type I first, then Type II — or skip straight to Type II?
If you have a deal on the table that requires SOC 2 now, get a Type I done while you're accumulating the observation period for Type II. It's better to have a Type I report than nothing, and it shows your enterprise prospect that you're on the path to Type II.
If you don't have immediate deal pressure, skip Type I and go straight to Type II. Type I costs money and adds time. The observation period starts when you say it starts — you're not waiting for anything external. Get your controls in place, start the clock, and save the Type I cost for your actual compliance budget.
One practical consideration: your auditor relationship matters. The same CPA firm that does your Type I will typically do your Type II, and having that continuity makes the Type II process faster. Pick your audit firm based on their experience in your industry and their technical depth — not just their price.
Using compliance automation platforms
Platforms like Drata and Vanta automate a significant portion of SOC 2 evidence collection. They connect directly to your cloud infrastructure, identity providers, and code repositories to pull system-generated evidence continuously. That's genuinely valuable — it removes the manual scramble of gathering screenshots and logs before each audit.
What they don't do is write your policies for you, ensure your controls are actually operating correctly before audit, or verify that the underlying control implementations are sound. The platform collects evidence; your team implements the controls the evidence documents.
For policy-level compliance — checking that your written information security policies, incident response plan, and privacy documents actually satisfy SOC 2 requirements — PolicyAudit fills the gap that automation platforms leave. You can scan your drafts before they're finalized, before the audit, before you pay for an auditor's time to tell you what's wrong.
Frequently asked questions
Know where your SOC 2 gaps are before the audit
PolicyAudit checks your security policies and documentation against SOC 2 Trust Services Criteria and identifies specific gaps — missing sections, vague language, and control areas with no documented procedures. Find out what needs work before you pay an auditor's hourly rate to tell you. Free for up to 3 documents.
Check your SOC 2 readiness for free →