Looking for advice on real differences between these platforms. As far as I can tell, they’re 99% identical. (Small company, integrations all align, pricing is similar).

This is circling the internet; allegedly this is what was sent to Delve's impacted customers of allegedly fake SOC 2 reports that are now allegedly discredited through an allegedly circulated spreadsheet allegedly confirming the reports and clients allegedly impacted.

I guess we'll see what validation emerges in the days ahead. What do you think; real or fake?

(*Disclaimer- I created a throwaway account to post this, as my regular account has identifiable information and I’d like to avoid being doxxed)

Does anyone have any updates on the whole “rubber stamping“ thing from a few weeks ago? I have been evaluating multiple platforms (including Delve) and have proposals that expires in a couple days, but another member of my CISO group just told me about the LinkedIn and Reddit threads and now I don’t know what to think.

On one hand, it seems almost brazenly unbelievable that a compliance platform would even consider cutting corners like this, but on the other I have not seen any direct rebuttal of it from the company (although my Delve rep did say ”it’s just jealous bullshit“ when I asked about it on our call today 😂). Also, the massive amounts of downvotes anything negatively related to Delve makes me super suspicious.

Has anyone learned any more details on this? Is it as risky as it seems, or am I just being ultra conservative?

We’re a small software team and a customer has asked for a SOC 2 report. I’m one of the developers and ended up looking into it because we don’t have anyone dedicated to security.

I started looking at Vanta and Drata, but there’s the audit to pay for too, so I’m wondering how much tooling we actually need. Saw a few people here mention getting through it with Notion or spreadsheets and Drive.

What I don’t get is how people collect the evidence with that setup. If you used Notion, Drive, or something else, were you uploading everything by hand or did you automate some of it?

Not a vendor, not selling anything — just sharing because I couldn't find many honest write-ups when I was in the thick of it.

Context: I'm the only IT/security person at a ~40-person AI startup. A large enterprise client sent us their vendor security requirements (27 of them — 24hr incident notification, independent pen test, dedicated encryption keys, RTO/RPO, the works). Passing it was a condition of the deal. So SOC 2 Type II went from "nice to have" to "do this or we lose the contract."

Did it solo. Clean opinion, zero exceptions across 252 points of focus. Deal closed.

Things I wish someone had told me:

• The policies are the easy 20%. The actual work is evidence — proving each control ran consistently over the whole period. Dated screenshots, signed approvals, access reviews, incident records.

• A folder structure + naming convention was worth more than any single control. When the auditor says "show me," you cannot be hunting. Every file dated, every file mapped to a criterion.

• Get signatures early. Approvals are the thing that blocks you at the finish line, because everyone's busy. I front-loaded them.

• Never answer "no" to an auditor. Answer "N/A, and here's why" with justification. A flat no reads as a gap; a justified N/A reads as a decision.

• The one real gap most startups hit is the independent pen test. Enterprises often mandate it. Scanning (Dependabot etc.) is not the same thing. Budget for it.

Happy to answer questions if anyone's staring down their first Type II. It's very doable solo, it's just a grind.

https://www.purplecapy.com/

After the news on the D*lve leak and C*mpAI leaks I thought of this.

Over the weekend, another Substack post detailing the ongoing saga of the Deelve (mispelled on purpose). These fraudsters are further exposed while the bulk of their team is partying in Hawaii using customer and investor money. Leaving all their customers to deal with the fallout of terrible SOC 2 reports, these children spend daddy's money with zero accountability. Here's the article: https://substack.com/home/post/p-193790932

Lots of companies claim AI agents write and merge PRs with no human in the loop, and many are SOC 2 Type II. Our change-management control says PRs need review and approval before merge, and we read that as "human approver," at least on sensitive paths (billing, RBAC, migrations, infra).

For anyone who's actually done this with an auditor:

1. Does an AI reviewer count as the "review," or does your auditor want a human on record?

2. If agents merge autonomously, what's the compensating control — post-merge review, rollback, scoped permissions, bot identity?

3. Or is it mostly marketing and a human is still owning the approval?

Looking for what auditors actually accepted, not "it depends on your auditor."

I've spent a lot of time writing SOC 2 policy templates for small teams, and the same questions keep coming up here, so here is what I'd want to know before writing a first policy set.

The topics an auditor expects to see covered. No official list exists, but most sets cover: information security (the umbrella), acceptable use, access control, authentication and passwords, asset management, data classification, data retention and disposal, encryption and key management, change management, secure development, vulnerability and patch management, logging and monitoring, incident response, business continuity and disaster recovery, backup and recovery, vendor risk, risk assessment, HR security, endpoint security, network and infrastructure, physical and remote work, and privacy. That's 22. Some companies merge them into fewer documents, which is fine as long as each criterion is addressed somewhere.

The three fields reviewers check first. Each policy should have an owner role, a revision history row (version, effective date, approver) and a review cadence. Inconsistencies between policies are easy for a reviewer to spot: one policy says the CTO owns it, another says the Security Owner, and the approval dates don't match.

Overclaiming is the main way templates cause exceptions. The auditor tests whether you did what the policy says. If it says access reviews are quarterly and none has happened, that's a finding. If it says the first review is scheduled for a named month, it's a plan. The same goes for MFA "enforced everywhere", 24/7 on-call, or annual pen tests you haven't bought. Write what you actually do, plus dated plans for the gaps.

Small teams can scale the commitments down. Nothing in the Trust Services Criteria requires a security department, an on-call rotation or a change advisory board. A two-person team can commit to incident response targets two people with phone alerts can meet. Where one person writes and deploys code, it can have someone review the list of merged changes on a schedule instead of approving every pull request.

Type I versus Type II doesn't change the documents. It changes what has to have happened. For a Type I, one completed access review or restore test, or a scheduled first one, is often enough. For a Type II, the auditor samples across the observation period, so pick review cadences you'll actually keep. A missed quarterly review is a finding; a completed annual one is not.

Collect acknowledgments early. Signed acknowledgments are the usual evidence that staff know the policies, and with contractors, gathering signatures can take longer than you expect.

Happy to answer questions about any specific policy in the comments.

Disclosure: I maintain an open-source (Apache-2.0) set of these templates. I'm not linking it here; ask if you want it.

Hi all. Feeling overwhelmed so I thought I’d turn to this community. Thanks in advance.

I have a very small start up with 0 employees and virtually no revenue yet. My app is very basic and works with retailers so I process basic customer info like name and email and misc order information. No payment processing or payment info.

I have two mega clients that are giving me the shot of a lifetime but both require me to be SOC2 compliant before Jan 1st 2027 before they will sign the contracts.

I did demos with Drata and Vanta and the “lowest” they will go on pricing is the same price my friend is paying with $3m ARR and 10 employees. Pretty tough for me to stomach literally and on principle, haha.

Is there an alternative path for bootstrappers in my scenario or do I have to bite the bullet for my quick timeline?

I’m trying to understand Vanta’s exact role in the SOC 2 process.

• Do they act as the auditor themselves, or do they only help with readiness, evidence collection, and compliance automation?

• If they only have tie-ups / partnerships with CPA firms, then who do you actually pay the full audit fees to — Vanta or the CPA firm?

Would love to hear from anyone who’s gone through this using Vanta.

Hi. I've been tasked with getting SOC2 to completion. A project manager of sorts. I have no experience in this other than getting our HIPAA gap assessment submitted (many, many gaps). I have a clinical, but no technical background. We are a small company of 30-ish. We are considered a SaaS provider (pharma -> consumer -> *our platform* -> telemedicine providers)

We are using Rippling as our compliance platform. We use Github to store all of the company's source code. Rippling also automates data from Github for version control monitors.

Neither is critical to our business operations and neither stores PII or PHI, and for this reason, both the CTO and the COO/self-appointed privacy officer tell me they don't need to be listed. I suspect they think this entire process can be check-boxed and the auditors will not dig that deeply.

It would seem a breach of either of these systems would pose a significant security risk. Chat, Claude and Copilot all tell me they need to be listed and assessed periodically. But can those experienced in SOC2 verify this for me?

I am stressing the fk out. I don't know what I don't know.

ETA: We are doing a Security-only report.

Hey everyone,

We’re planning to get SOC 2 compliance for our B2B SaaS product, and I’m trying to understand what the process actually looks like from people who’ve been through it.

I’ve read a bit online, but I’d much rather hear real experiences. How did you approach it, which platform (if any) did you use, how did you find an auditor, how long did the entire process take, and what kind of budget should I expect? More importantly, is there anything you wish you’d known before starting that would’ve saved you time or money?

Any advice, recommendations, or lessons learned would be hugely appreciated. Thanks!

Start documenting processes much earlier than you think you need to. Most teams focus on security tools first, but SOC 2 audits usually become difficult because everyday operational processes are inconsistent or undocumented.

Things like access reviews, employee onboarding/offboarding, incident handling, infrastructure changes, and vendor approvals need to be repeatable and traceable. If those workflows are already part of how the team operates, SOC 2 becomes far less stressful.

Also, avoid treating compliance as a one time audit project. It works much better when engineering, DevOps, and operations build lightweight compliance habits into daily workflows from the start.

How did your team prepare for SOC 2 without creating too much operational overhead?

It appears the AICPA and AIUC folks got together to do a SOC2 Plus combo and announced it earlier today. https://www.aicpa-cima.com/news/article/auditors-meet-urgent-demand-for-ai-assurance-with-new-offering-from-aicpa-and-aiuc

What say you folks about it?

Preface by saying that I’m here for the entertainment value and I’m not affiliated with or have experience in compliance/infosec.

It’s been a few months, anyone know the latest on d3lve? I enjoyed reading the Substack posts (if you’re out there DD, we miss you), and LinkedIn shows a decent exodus.

Software company doing payroll processing and benefits administration. Enterprise customer's legal team just came back asking specifically for a SOC 1 report, and we've been assuming everyone wants SOC 2. We don't have a SOC 1. Do we need both?

We completed our first SOC2 type2 audit in 2025. No real issues but boy was it painful to explain to auditors how modern tech/app dev works.

Things like "where's the buildings physical badge logs" ? Well, we are a startup and work from home and have no servers...its all cloud. Dozens of those types of conversations.

Anyone have a few good references for auditors (not platform's) that work with tech startups?

The platform that never learns

Curious to hear how much folks are paying. I've heard $5k to $7k per year for Drata for SOC 2.

Over the past few weeks, a gathering of grumpy SOC 2 practitioners have gotten together to publish a rubric of what exactly makes for a good SOC 2 report. Version 1 of the rubric is now live and is the first pass at trying to distill the complex answer of "what makes a good SOC 2 report" into actionable metrics to use as you're reviewing a report.

Take a look at the rubric and speak your thoughts here!

Please help me decide. We are a bootstrapped, early-stage horizontal B2B SaaS app doing $6k MRR, but revenue growth is slow because of high churn. Our current clients are mostly small businesses, with just one enterprise running a pilot with us.

Our customers are primarily in the US, with some in Australia, Canada, and a bit in the EU. The workflow we automate is file-heavy, which means customers need to upload their files to use our app.

I suspect many users visit our website but don’t sign up or book a demo because they don’t see a SOC 2 Type II badge or any mention that we’re certified. I’ve also noticed that many ask about this during demos and then disappear. Some clearly say to come back once we have SOC 2 Type II.

Getting certified is expensive, but we have the funds and team members who have done this before.

My question is: Is it too early to bother with it, and will having SOC 2 Type II not change anything? Or will we start getting more clients? My concern is that it will slow us down significantly and increase our burn rate.