The Delve Compliance Scandal: 378 Companies, 494 Fabricated SOC 2 Reports
Publicly Published
2026-03-27 06:38
Summary
In March 2026, a whistleblower published evidence that Delve, a Y Combinator-backed compliance automation startup valued at $300M, had systematically generated fabricated SOC 2, HIPAA, ISO 27001, and GDPR compliance reports for hundreds of clients. Analysis of 575 leaked files revealed that 493 of 494 SOC 2 reports shared 99.8% identical text, including the same grammatical errors and test data artifacts. This advisory identifies the 378 unique affected companies and provides actionable due diligence guidance.
Description
What Happened
In March 2026, anonymous whistleblower "DeepDelver" published evidence that Delve had been systematically generating fabricated compliance reports. The leaked dataset — a publicly accessible Google Spreadsheet discovered in December 2025 — contained 575 files including 494 SOC 2 reports, of which 493 shared 99.8% identical text.
The only differences between reports were company names, logos, and auditor signature blocks. Reports contained identical grammatical errors and keyboard-mashed test artifacts ("sdf", "dlkjf") across supposedly independent audits. The dataset even included entries with names like "test", "sample", and "doodoo", demonstrating that reports could be generated with arbitrary inputs.
Deceptive Practices Identified
1. Carbon-Copy Report Generation — 493 of 494 SOC 2 reports contained 99.8% identical text with shared errors across what were supposed to be independent audits.
2. Fabricated Type 2 Attestations — All 259 Type 2 reports claimed zero security incidents, zero personnel changes, and zero customer terminations. Across 159+ companies, this is not statistically credible.
3. Pre-Populated Trust Pages — Trust pages at trust.delve.co/[company-name] displayed fully populated security attestations before compliance work was performed.
4. Rubber-Stamp Audit Firms — Seven firms identified, primarily Accorp Partners (India, virtual U.S. offices) and Gradient Certification (registered at a known shell entity address in Sheridan, WY).
5. Structural Inversion — Delve generated auditor conclusions and final reports before any independent review occurred, placing itself as both implementer and examiner.
Downstream Impact
Multiple Fortune 500 companies accepted compliance documentation from Delve clients during vendor reviews, including OpenAI, PayPal, Microsoft, IBM, Stripe, Amazon, Uber, Klarna, Zendesk, Broadcom, Starbucks, PwC, DoorDash, Mercury, and Brex.
Important Note
The 378 companies in this dataset are victims of the alleged fraud, not perpetrators. Most are early-stage startups that paid for a legitimate compliance service and trusted it to deliver. A company's presence in this list does not mean its security controls are inadequate — it means the documentation attesting to those controls cannot currently be relied upon.
References
[1] TechCrunch: "Delve accused of misleading customers with fake compliance" — https://techcrunch.com/2026/03/22/delve-accused-of-misleading-customers-with-fake-compliance/ [2] DeepDelver: "Delve: Fake Compliance as a Service - Part I" — https://deepdelver.substack.com/p/delve-fake-compliance-as-a-service [3] byteiota: "Delve Compliance Fraud: $32M Startup Faked 494 SOC 2 Audits" — https://byteiota.com/delve-compliance-fraud-32m-startup-faked-494-soc-2-audits/ [4] Insight Partners scrubs investment post — https://techcrunch.com/2026/03/23/insight-partners-scrubs-investment-post-amid-fake-compliance-allegations/ [5] dupedbydelve.com — https://dupedbydelve.com/ [6] PCAOB Release No. 102-2023-001: Disapproval of NG Associates CPA LLC — https://assets.pcaobus.org/pcaob-dev/docs/default-source/registration/firms/disapproval_notices/102-2023-001-ngassoc.pdf [7] LiteLLM confirmed as Delve client — https://techcrunch.com/2026/03/26/delve-did-the-security-compliance-on-litellm-an-ai-project-hit-by-malware/
1
What This Means For Your Organization
What This Means For Your Organization
Event Summary
Delve, a compliance automation platform, fabricated 494 SOC 2 reports for 378+ companies. Reports were 99.8% identical boilerplate. Any vendor risk decisions made based on Delve-issued SOC 2 reports are built on false premises.
Vendor Relationship Context
If any vendor in your ecosystem used Delve for their SOC 2 compliance, their attestation cannot be relied upon. This does not mean the vendor is insecure — it means you lack the evidence you thought you had.
Data Exposure Risk
No direct data exposure from this incident. The risk is indirect: vendors approved based on fabricated compliance evidence may have actual security gaps that were never independently verified.
Service Dependency Impact
Vendors handling sensitive data (PHI, PII, financial data, source code) that were approved based on Delve-issued SOC 2 reports represent the highest priority for re-verification.
Urgency: Critical
A major compliance platform has been found fabricating SOC 2 reports for hundreds of companies. If any of your vendors used Delve for compliance, their SOC 2 reports should be treated as invalid and replaced with independent verification.
2
Am I Affected?
Am I Affected?
Risk Assessment
Likelihood
high
Impact
critical
Rating
critical
With 378 affected companies across all industry verticals, the probability that at least one appears in a mid-to-large organization's vendor ecosystem is very high. The impact is critical because compliance attestations function as trust anchors — when they are fabricated, the entire vendor risk assessment is invalidated.
Threat Model
Attack Vectors
- • Supply chain trust compromise via fabricated compliance documentation
- • Downstream enterprise exposure through accepted false attestations
Threat Actors
- • Delve (compliance platform operator)
- • Accorp Partners (audit firm)
- • Gradient Certification (ISO certification body)
Affected Assets
- • Vendor risk management programs
- • SOC 2 reliance decisions
- • Regulatory compliance documentation
Exposure Indicators
- • Vendor's SOC 2 report issued by Accorp Partners
- • Trust page hosted on trust.delve.co
- • Vendor cannot name their auditor
- • SOC 2 obtained in under 30 days
Self-Assessment Checklist
- Do any of the 378 companies in the registry appear in your current vendor inventory?
- Have you onboarded any vendors since January 2025 whose SOC 2 was issued by Accorp Partners?
- Do any of your vendors have trust pages hosted on trust.delve.co?
- Have you accepted any SOC 2 reports that were completed in under 30 days?
3
Close the Loop
Close the Loop
Immediate Actions
- 1. Cross-reference your vendor inventory against the 378-company registry in this advisory
- 2. For any matched vendor, request an updated SOC 2 report from a different audit firm
- 3. Reject any SOC 2 report issued by Accorp Partners, Gradient Certification, NG Associates, Glocert, BQC Assessment, DKPC, or Prudence Advisors
- 4. Check vendor trust pages — if hosted on trust.delve.co, treat displayed controls as unverified
Short-Term Actions
- 1. Send the Due Diligence Questionnaire (below) to any affected vendor
- 2. For every SOC 2 report received during vendor onboarding, verify the audit firm's AICPA Peer Review status at peerreview.aicpa.org
- 3. Add compliance platform questions to your vendor assessment: What platform do you use? Which firm performed your SOC 2? Can you provide their AICPA Peer Review enrollment number?
- 4. Request bridge letters for any SOC 2 report with an observation period ending more than 6 months ago
Long-Term Actions
- 1. Supplement SOC 2 reliance for critical vendors with your own security questionnaire, penetration test report, or right-to-audit clause
- 2. Implement routine audit firm verification as a standard step in vendor onboarding
- 3. Consider requiring vendors to provide compensating evidence beyond SOC 2 for sensitive data handling
Escalation Path
CISO or Head of Vendor Risk Management
Timeline
Immediate for vendor inventory cross-reference. 30 days for affected vendor re-verification. 90 days for process improvements.
Evidence Requirements
- Maintain documentation showing awareness of the Delve situation, non-reliance on compromised reports, and compensating due diligence steps taken.
Vendor Due Diligence Questionnaire
This questionnaire should be sent to any vendor identified in the Delve-affected registry, or any vendor whose SOC 2 report was issued by one of the seven flagged audit firms. The purpose is not to punish the vendor — they are a victim of the fraud — but to independently verify that the security controls the SOC 2 was supposed to attest to are actually in place. Calibrate the depth of inquiry to the sensitivity of data the vendor handles.
1 Executive Attestation
Provide a signed attestation letter from a C-level executive (CEO, CTO, or CISO) confirming that your organization maintains an active information security program and that the controls described in your previous SOC 2 report reflect your actual operational practices.
Evidence required: Signed letter on company letterhead, dated within the last 30 days
Green
Signed letter provided within 5 business days, specific about control areas
Yellow
Letter provided but generic or delayed beyond 10 business days
Red
No letter provided, vendor refuses to attest, or letter contradicts known facts
2 Risk Management
Provide your current risk register or describe your risk assessment methodology, including how frequently assessments are conducted and who is responsible.
Evidence required: Risk register document or risk assessment policy with last review date
Green
Documented risk register with entries dated within the last 12 months, named owner
Yellow
Risk register exists but is stale (>12 months) or lacks owner assignment
Red
No risk register exists, or vendor cannot describe their risk assessment process
How do you identify, evaluate, and prioritize information security risks? What framework do you follow (e.g., NIST CSF, ISO 27005, FAIR)?
Evidence required: Description of methodology with framework reference
Green
Clear methodology aligned to a recognized framework with evidence of regular application
Yellow
Informal process exists but not aligned to a framework
Red
No structured risk assessment process
3 Incident Response
Provide your Incident Response Plan (IRP). When was it last reviewed and approved? When was the last tabletop exercise or simulation conducted, and what were the key findings?
Evidence required: IRP document with revision date, tabletop exercise report or summary
Green
IRP reviewed within 12 months, tabletop conducted within 12 months with documented findings and remediation
Yellow
IRP exists but hasn't been tested in >12 months, or tabletop had no documented findings
Red
No IRP exists, or vendor has never conducted a tabletop exercise
Describe your incident classification and escalation procedures. What is your target time-to-detect and time-to-respond for critical security incidents?
Evidence required: Escalation matrix or procedure document with SLA targets
Green
Documented escalation procedures with defined severity levels and measurable response SLAs
Yellow
Informal escalation process exists but SLAs are not defined or measured
Red
No escalation procedures or inability to articulate how incidents are classified
4 Business Continuity & Disaster Recovery
Provide your Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP). What are your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for critical systems?
Evidence required: BCP/DRP documents with defined RTO/RPO values per system tier
Green
Documented BCP/DRP with defined RTO/RPO, reviewed within 12 months
Yellow
Plans exist but RTO/RPO not defined per system, or plans are stale
Red
No BCP/DRP exists, or vendor cannot state their RTO/RPO
When was the last failover test or disaster recovery drill conducted? What was the outcome, and were RTO/RPO targets met?
Evidence required: DR test report with date, scenario, results, and gap remediation
Green
DR test conducted within 12 months, targets met or gaps identified with remediation plan
Yellow
DR test conducted but >12 months ago, or targets were not met with no remediation plan
Red
No DR test has ever been conducted
5 Penetration Testing
Provide your most recent penetration test report from a named third-party firm. When was it conducted, and what is the remediation status of critical and high findings?
Evidence required: Pen test report (executive summary acceptable) with firm name, date, and finding remediation tracker
Green
Pen test from a named firm within 12 months, all critical/high findings remediated or with documented timeline
Yellow
Pen test exists but >12 months old, or critical/high findings remain open without timeline
Red
No penetration test has been conducted, or vendor refuses to share results
6 Vulnerability Management
What is your vulnerability scanning cadence for infrastructure and applications? What is your SLA for patching critical, high, medium, and low severity vulnerabilities?
Evidence required: Vulnerability management policy with scanning schedule and patching SLAs
Green
Weekly or continuous scanning, critical patches within 72 hours, high within 30 days, documented policy
Yellow
Monthly scanning, patching SLAs exist but are not consistently met
Red
No regular scanning, no patching SLAs, or vendor cannot describe their process
Provide evidence of your most recent vulnerability scan results and the remediation actions taken.
Evidence required: Scan summary report (redacted if needed) showing scan date, finding counts by severity, and remediation status
Green
Recent scan (<30 days) with evidence of active remediation workflow
Yellow
Scan exists but older than 30 days, or remediation not tracked systematically
Red
No scan evidence available
7 Access Control
Do you enforce multi-factor authentication (MFA) on all production systems, administrative interfaces, and source code repositories? What MFA methods are supported?
Evidence required: MFA policy document or screenshot of MFA enforcement settings
Green
MFA enforced across all production, admin, and code access with hardware key or authenticator app support
Yellow
MFA enabled but not universally enforced, or SMS-only MFA
Red
MFA not enforced on production systems
How do you manage privileged access? When was your last access review conducted, and what percentage of accounts were modified or revoked?
Evidence required: Privileged access management policy, last access review report with date and outcome
Green
Formal PAM process, access reviews conducted quarterly, documented outcomes with revocations
Yellow
Access reviews conducted but less frequently than quarterly, or no formal PAM process
Red
No access reviews conducted, or no privileged access controls
8 Encryption
What data is encrypted at rest and in transit? What encryption standards and key lengths are used? Who manages encryption keys and how are they rotated?
Evidence required: Encryption policy or technical documentation covering at-rest, in-transit, and key management
Green
AES-256 at rest, TLS 1.2+ in transit, documented key management with rotation schedule
Yellow
Encryption in place but key management process is informal or rotation is not scheduled
Red
Data not encrypted at rest, or using deprecated protocols (TLS 1.0/1.1, DES)
9 Third-Party Risk Management
How do you assess the security posture of your own vendors and subprocessors? Do you maintain a vendor inventory with risk classifications?
Evidence required: Vendor risk management policy, vendor inventory, or assessment methodology description
Green
Formal vendor risk program with classified inventory and periodic reassessment
Yellow
Vendor inventory exists but assessments are ad-hoc or incomplete
Red
No vendor risk management process
10 Security Monitoring
Do you operate a SIEM or centralized logging system? Who reviews security alerts, and what is your mean time to detect (MTTD) for security events?
Evidence required: Description of monitoring infrastructure, alert review process, and MTTD metrics if available
Green
Centralized SIEM/logging with 24/7 alert review (internal or SOC), MTTD tracked and improving
Yellow
Logging exists but alert review is business-hours only, MTTD not formally tracked
Red
No centralized logging or security monitoring capability
What is the retention period for security logs? Can you provide evidence that logs are tamper-protected?
Evidence required: Log retention policy, evidence of immutable or append-only log storage
Green
90+ day retention with immutable storage and access controls on log infrastructure
Yellow
Logs retained but <90 days, or not stored in tamper-protected manner
Red
No log retention policy or logs can be modified by application administrators
Decision Matrix
Use this matrix to evaluate the vendor's responses to the Due Diligence Questionnaire. The evaluation is cumulative across all sections.
All Green: Vendor demonstrates independent, verifiable controls across the assessed areas. Evidence is current, specific, and consistent. Proceed with the vendor relationship with standard monitoring.
Yellow: Partial evidence or minor gaps identified. The vendor is making a good-faith effort but has areas for improvement. Proceed with enhanced monitoring and a 90-day follow-up to verify gaps are addressed.
Red: No evidence, refusal to respond, or contradictory information. The vendor either lacks the controls or is unwilling to demonstrate them. This does not confirm they are insecure, but it means you cannot make an informed risk decision.
Any 2 or more RED responses: Recommend vendor replacement or escalate to CISO for formal risk acceptance. Any 4 or more YELLOW responses: Escalate to CISO for risk acceptance decision with enhanced monitoring terms. All GREEN: Accept with standard monitoring for 12 months, then reassess.
Need Personalized Impact Analysis?
Sign up for GlassTrace to get personalized impact analysis for your organization.
Sign up for GlassTrace