alt Hacker NewsI went through the process and while it seems it's daunting, it's just a bunch of work and some cash. Once established it's also transformative (or should be) on your ongoing processes and practices. You codify those into a bunch of documents (jesus, that's a lot of documents type of thing) and provide evidence for each; Auditors latch onto those randomly. It's then your job to upkeep documents and evidence which can be helped with tools that have frameworks for those. We use drata and it's really simple and helpful to use.
I don't think you would be able to be compliant as a solo dude though, not easily. A bunch of protocols and practices revolve around governance, handovers, failovers, risk mitigation etc and if you're the only guy there's a hard path ahead. Are you reviewing and approving your own code that goes to production? If things go down and you're the first to call (let's say by automated alerting) and you're not available, who is the next one to call as in what's the documented succession plan or automated remediation.. etc.
Compensatory controls do not strictly require a human, they require mitigation of risk associated with a single human. You'd have to automate a lot of these governances "gates" then. So it would be possible, since evidence you would have to provide is work not org-chart, but it'd be a ton of work.
I went into it thinking I need to answer these 167 documents and provide evidence on an ongoing basis, but it actually also transformed the way we do things. I think for the better. At the end of the day, I also think this can be gamed as probably most certificates, but it's not worth it and transformation you go through makes sense.
Replies
Thank you for your feedback!
I 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...