3 ms·
Look, I agree with pretty much all of what you say. I would never suggest any company, whether a startup or an established enterprise (which is my case) go thro
by teilo 7y ago
Look, I agree with pretty much all of what you say. I would never suggest any company, whether a startup or an established enterprise (which is my case) go through the SOC2 process unguided, attempting to interpret the ACIPA docs on their own. That is a recipe for disaster. The TSC is almost inscrutable on its own. The AICPA cannot write in plain english to save their life.
That said, I don't understand this statement: "You can also sit around and worry about which of the "COSO Principles" you're covered on or not covered on."
In the end, to pass a SOC2 audit, you have to have evidence for each of the applicable TSC points, including the COSO Principles, which have little or nothing to do with information security but are all about general business governance. It's not a question of "sitting around wondering." It's understanding what the COSO Principles actually are after, so that you can assemble the appropriate evidence. And that means working with HR and finance.
You make it sound like the COSO Principles are irrelevant. Believe me, if I could skip them I would. If I could skip a risk assessment, I would. If I could skip all the "written and audited policies" I would. But you can't skip them. And in the case of a risk assessment, you shouldn't skip them. I mean, that's the whole point in the end: knowing your risks, and having the controls in place to mitigate them.
So yes, of course you need to be sensible. But you also have to do the work, and the work is hard. It is by far the last favorite part of my job.
But my point is: It's not about the product category boxes you have ticked. Security products are important. They make compliance much easer. No question. But for SOC2 to have real value to an organization (and I think there is real value that can be gained from it), it is far more about process, and it is process that is the most difficult thing to implement and religiously maintain and document.
- tptacek 7y agoThis has simply not been my experience of how SOC2 processes have actually worked at real startups. The experience I've seen, repeatedly, in variations but always on this one theme, is of a collection of mostly boilerplate policies being exchanged for a turbocharged vendorsec questionnaire, followed by a series of interviews. The line items on the questionnaire are answered in any ways that is convenient for the auditee and credible for the auditor. At no point is anyone on the engineering side made familiar with TSC points or COSO; the runic accountancy is driven be the auditor. I would, in particular, not recommend that startups thinking about pursuing SOC2 spend a lot of time familiarizing themselves with the TSC or (god forbid) the COSO Framework, because it simply isn't going to matter. My general belief is that SOC2 is of no intrinsic value to organizations, and going into it with a mind towards letting your engineering practice be guided by SOC2 rather than dictating SOC2 is a recipe for heartbreak. Among security engineers (and managers) at tech startups I've talked to, I don't seem to be far out of the mainstream. SOC2 is like most university degrees: it's a demonstration of seriousness, and nothing more. If you think this blog post is about "buying the right products", you've entirely missed its point.