Its mostly marketing, "look at this MIT genius that noticed something about legacy xyz industry that no one else did"
Truth is venture funds are allocating a limited pie of what is really societies capital to people that dont deserve it
Something bad happens because of lack of regulation -> People strive for regulation -> Govt's actually regulates and sets some norms/procedures -> system works for a while -> Then someone takes the same idea and molds it into something else to bypass the regulation -> they get promoted because they are "clever" and get rewarded -> Then something bad happens as the tool is used by public.
From Prediction markets to Buy now, pay later to Delve to so many other things.
Is there a name to this particular phenomenon, because this just keeps on repeating in multiple industries.
This pie does not seem that limited recently.
The only security compliance frameworks that have any particular reputation with me are the ones associated with the department of defense where the consequences range between a slap on the wrist warning or a small 5 figure fine to execution for espionage (which only ever happened for Julius and Ethel Rosenberg, though one could imagine there may have been more, uh, unofficial consequences that nobody ever heard about). In other words, people actually care about the enforcement of security standards in meaningful ways and there are meaningful consequences.
Everything else... well they're all at least a little better than a participation trophy and the process proving you're trying isn't meaningless. It's just not been my experience with these things that they're particularly good guarantees that the spirit embodying the compliance program is actually being done particularly well.
If you really care about security, you need to separate it from this stuff, it can only hurt you.
Do your own, real, security, and treat this compliance stuff as an opaque customer feature request.
* Run a SOC2/compliance program that is entirely disjoint from your security practice.
* Defer SOC2 until the work required to sell into customers demanding it (phone calls, questionnaires) exceeds the cost of obtaining SOC2.
* Prepare for SOC2 by making simple best-practices engineering decisions, in particular single-signon for virtually everything and protected branches for all your repositories.
* Do not allow SOC2 to force any engineering decisions that you would not have intuitively made yourself (this is a big risk with the evidence-gathering platforms like Drata, Delve, and Vanta).
* Assume your SOC2 Type I report will suffice as a first attestation (ie: buy you 1 year of time) with all your customers, and understand that you cannot fail to obtain a Type I; your Type I is guaranteed.
Over 5-6 years of discussing SOC2 with other security practitioners pretty intensively, the overwhelming weight of the evidence is that ~practically nobody actually reads SOC2 reports; they just check the box for each vendor and move on. Plan accordingly.
Getting a SOC2 doesn’t mean you’re amazing or secure or stable. If a customer says they’ll write you a fat check but they need you to have a SOC2, tell them you’ll get it within a year if they start paying. Otherwise don’t bother.
A ton of these SOC2 vendors take all of the potential good parts of SOC2 out of the equation, building the threat models for you and then you just hook up your gsuite/ github and they check boxes for you or tell you to flip a policy here or there. Delve took this to the extreme by not even asking you to flip the checkboxes.
That said, it doesn't matter if it's legit. Everyone is SOC2, and part of being SOC2 is that the vendors whose products you purchase are SOC2, so it's not a choice - you have to be SOC2 if you want to sell (industry/ product specific, but at some point it'll be clear if it applies). If your goal is security, well, SOC2 is irrelevant.
Ultimately, you'll end up having a separate compliance team to manage SOC2 and you'll actively try to keep "real security" from it because real security has to change over time. You'll encode the absolute minimum possible into your compliance for that reason so that you can easily pass every year and then, if you care about security, you'll invest in that separately.
The idea that SOC2 forces you to do important stuff gets it backwards; SOC2 documents your existing practice, and demands only extremely high-level controls that you can deliver in any number of ways. Your security practice should (minimally) inform your SOC2, not the other way around.
Yes, that's true. I edited my post to be a bit clearer about this. When you need a SOC2 is going to depend a lot on your business. Lots of companies can make exceptions very easily. Type 1 is easy, I would highly recommend starting there pretty much no matter what since it'll be good practice before your SOC2.
> The idea that SOC2 forces you to do important stuff gets it backwards;
It's the goal behind SOC2. You're assuming a company has a security practice that informs the SOC2 but I think the idea is that companies have no security practice and the SOC2 is what forces them to sit down and build one. What you're describing is more like what happens when a company that actually cares about security goes through SOC2 - you take what you have, put it into a NIST format, and map minimal controls from your practices to the CCs. Most companies have nothing to start with.
We were considering getting certified, but it only really makes sense if your customers require you to have it.
And another question but as a consumer, is there any certification which can meaningfully try to show if people/business take their security carefully or are all things security theater in that aspect and at some point, we just have to trust the enterprise and look for other signals of security (like for example blog posts which might show a deep-dive into security for example comes to my mind)
In my mind getting a clean report required three kinds of work:
1. Work that actively improved our security posture. 2. Work that didn't change much, but made our security posture easier to understand. 3. Busy work.
I think for most companies all three kinds of work will be required, but you can also make decisions that will push the percentages around. SOC 2 required us to start doing an annual security table top exercise. You could sit down, run a scenario, run it as fast as you can, and come up with a few pre-determined "improvements" that would help if you actually had that problem in the future. Or you could sit down and really put work into it, and see what works well and what doesn't.
As an example in our last tabletop I "exfiltrated" some data from one of our servers, and challenged the team to figure out what I'd done. The easy way out would have been for someone to say "We'll look at the logs and figure it out", but instead I asked them to actually try and find it. We discovered that the sheer volume of logs for that system made them hard to work with. So we made some changes to make them easier to work with and repeated the exercise later.
It could have been busy work, but instead we got real value from it.
But it’s ultimately not up to you if you do it or not. If all of your potential clients demand it, it’s generally easier to get it than it is to get on the phone with all of your potential clients’ IT departments and explain why you don’t have it.
this + new HN account? couldn't be more obviously a competitor. not to defend delve, but can’t be pushing this like some noble effort with the goal of transparency
also lol @ the fake realtime "just searched for" toasts on a setInterval in the bottom left.
https://trustcompliance.xyz/_next/static/chunks/17psh0.nytnh...: 404 Not Found
There is intermittent XHR traffic, but it's most definitely not returning any such information and it's posting what looks (in FF's dev tools) like garbage binary data.
How is it bigger than the auditors that Delve was using. Surely Delve wasn't there only client. Delve is just a drop in the bucket.
There's a fair amount of boiler plate language in these reports, and a bunch of re-stating the SOC 2 controls. I'd expect two reports (same auditors, same platforms) to be nearly identical. If they're both using AWS, Github, Stripe, Vetty, they're subbing a lot of the exact same thing out to the same companies, referencing the same set of internal controls.
Reading ours. There's a section titled $Company's Controls, followed by 20 pages listing the various SOC 2 controls. e.g.
---
CC9.0 Common Criteria Related to Risk Mitigation
CC9.1 The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions.
IR-01 A Security Incident Response Plan that outlines the process of identifying, prioritizing, communicating, assigning, and tracking confirmed incidents through to resolution is accessible to all relevant employees and contractors and is reviewed annually.
---
Then there's another 20 pages of those same controls being listed, some language about how they tested the controls, and hopefully "No Exceptions Noted".
That's not going to change much between companies.
Did someone actually go and confirm your role based access control matrix is up to date and user accounts have the right access? Were all of those screenshots watermarked with timestamps?
There is work to do, whether or not auditors are doing it is another question.
SOC2 certified, has never actually put to paper "here's what we know we're doing wrong, here is how we plan to remediate it."
fake popups, xyz domain, recent zeitgeist, 100% straight vibecoded. good hustle I have to say. a domain that'll now get ranked on google for SOC 2 compliance which likely has a high CPC and good DR to piggyback off.
fadijob•1h ago
- The same auditor license number (PAC-FIRM-LIC-47383) appears in 487 out of 494 reports
- Every Type II report has identical page numbers: Section 4 at page 30, tests at page 59, Section 5 at page 82
- 220+ "No exceptions noted" per report, across every single client
- The system descriptions were copy-pasted from each company's marketing website
We built tools to check this data:
- Search by company name to see if they're in the leaked database
- Paste any SOC 2 report text to scan for 10 template fingerprints
- A swipe game where you try to tell real audit excerpts from the fakes (harder than you'd think)
455 companies indexed, all free, no signup needed.
I'm also curious what the HN community thinks about the fingerprint detection approach, are there patterns we're missing?
nemomarx•1h ago
dpe82•1h ago
chromacity•1h ago
Of course, this shows that the entire system is a bit of a charade, but the point is that someone cares and they're gonna be annoyed when they find out that the audit appears to be a sham.
Whether they have a good alternative is a separate question. But here's another way to look at it: if we show blatant disregard for self-regulation, the government is eventually going to show up and come up with more onerous rules.
throw310822•57m ago
Is it true, though? Or has everyone just been psyched into asking for that certification out of a vague fear of "consequences" or of being left behind?
chromacity•41m ago
Small vendors will tell you what you want to hear because they're desperate for your business. Independent auditing is, in theory, a way to get closer to the ground truth. Well, in theory.
mikeocool•1h ago
In my experience, clients don't dig deeply into the report or the auditor, they just want to see that you 1) have the report 2) it doesn’t have any egregious exceptions. Perhaps if this makes big enough news, that’ll change.
mikeocool•56m ago
jiveturkey•42m ago
SOC2 reports are private between you and the auditor (that way if you "fail" you can just find another auditor or have a re-do, and no one is the wiser), and basically always gated behind a sales touchpoint (another hint about what utility they provide). I guess the Delve ones leaked which is why they can all be compared.
220 out of 494 "no exceptions" seems quite high to me. Nobody I've ever dealt with allows an exception to make its way into the report.