alt Hacker NewsI can't say enough how not transformative SOC2 should be on your processes. Near-automatic exception-free attestations should be a byproduct of basic sane corpsec practices. SOC2 should never be leading or informing your security practices.
For people who don't know much about SOC2, the headline is that all SOC2 does is confirm that you do the things you say you do. There's a short vibes-based catalog of objectives --- things like "change management" and "access control" and "backups" --- but no actual standard on how any of those things are done. The controls you use to meet those objectives could be $50,000/yr enterprise software packages, or they could be a system of post-it notes. Your auditor does not care, so long as the things you say you do, you do consistently.
What happens all too often is that companies come into this process (usually ill-advisedly; probably as many as half the SOC2-attested firms don't really need to be) without clear objectives and security practices to begin with. They read the SOC2 DRL, reconcile it with what they are and aren't doing in IT already, and end up instituting whatever the "default" controls look like for each objective, which is how you end up with AWS SAAS startups running network intrusion detection in 2026.
I wrote a post 6 years ago for my clients who were ideating getting SOC2; it's about the (very small and very simple) set of engineering things you need to do to be in a place where you'll get an automatic SOC2 Type I attestation. It has held up very well. You should understand everything in this post well enough to have opinionated takes on everything in a SOC2 DRL, and to be in a position to tell your auditors to GTFO if they ask you to do more.
https://www.latacora.com/blog/2020/03/12/soc2-starting-seven...
Replies
Near-automatic exception-free attestations should be a byproduct of basic sane corpsec practices.
being key here. if you realize it's not all that sane when you start reviewing things, what happened in our case was it allowed us (there were other signals as well) to regroup on our practices and then it was painless.
I completely agree with the outlook, but from a practical standpoint (in the last couple of years) I have seen the opposite. The SOC2 process is often transformative ("should" vs "is" are not the same thing).
Especially smaller startups, who grew somewhat quickly, and now "want to get SOC2 because customers want it". In practice this also (often, unfortunately) means "not all employees should have AWS admin creds, we should have some separation between environments, and we should know who has access to what".
For these companies SOC2 "requirements" can be the business-value line item that can get proper security and access-control patterns in place.