This is all good, just a note for anybody reading this to the end: there's basically no way not to pass your Type 1, at least not if you're using a serious auditor. The point of a Type 1 is to document a point-in-time baseline. The Type 2 is the first "real" audit, and basically just checks whether you reliably did all the things you attested to in your Type 1.
All that is to say: you want to minimize the amount of security work you do for your Type 1, down to a small set of best practices you know you're going to comply with forever (single sign-on and protected branches are basically 90% of it). You can always add controls later. Removing them is a giant pain in the ass.
This is always my concern for people going into SOC2 cold: vendors in the space will use the Type 1 as an opportunity for you to upskill your team and get all sorts of stuff deployed. A terrible and easily avoided mistake.
I write this only because the piece ends with Excalidraw psyched to have cleared their Type 1. I hope their auditors told them they were always going to clear that bar.
In case it's helpful, I also collate quality blog posts in this genre over at https://rami.wiki/soc2/
RainyDayTmrw · 4h ago
Am I reading correctly between the lines? That sounds like you're suggesting that vendors in this space will actively work against your interests, and scope creep type 1, to get more business for type 2?
bravesoul2 · 4h ago
Such a cat and mouse game. Customer wants security. Vendor may or may not want it but wants to minimise required security to make enterprise sales. Vendor's vendor may want to add security (real or theatre) to type 1 to get more business for type 2 compliance.
robertclaus · 5h ago
Yup, for the most part you define your own controls! Even type 2 is pretty hard to "fail" if you're serious about security. You're more likely to just get minor exceptions in the report for being sloppy about something.
tptacek · 5h ago
I think we've managed to get an exception in every Type 2 we've done (each time, some dumb paperwork policy thing; I think in one instance we were untimely with a post-facto merge PR signoff, the closest we've come to an actual slip. The first exception we got, I raised hell and wrote a management statement. But nobody cares about trivial exceptions, and so I've learned not to here either.
But, true, I didn't even pay attention in our last Type 2 (I don't run security here) --- passing was a foregone conclusion.
colechristensen · 5h ago
>I write this only because the piece ends with Excalidraw psyched to have cleared their Type 1. I hope their auditors told them they were always going to clear that bar.
The signal having a Type 1 says is that you're interested in even trying to pass the next one, which in itself is a good sign to everyone. Maybe being excited and proud of "passing" type 1 is a little exaggeration for folks who know the details, but I'm very willing to forgive that. A lot of orgs show a lot more pride about much more dubious things.
tptacek · 5h ago
I'm not saying it's a bad sign, I'm saying: you really can't fail a Type 1, unless your auditor is messing with you (a good auditor's job is to make sure you end up with a Type 1). My broken-record SOC2 point is: minimize your Type 1 controls, and add new controls over time.
You can do lots of security things. I'm not saying minimize security. I'm saying minimize the security things you talk about in your Type 1.
colechristensen · 4h ago
I'm saying even if you can't fail, I'm still willing to congratulate an org for starting even though the first milestone isn't particularly impressive.
tptacek · 4h ago
Congratulations, Excalidraw. Also I love your product. Meanwhile, let's get back to talking about the pitfalls of actually getting SOC2.
colechristensen · 1h ago
Agreed. Certifications leave a lot to be desired but are at least better than nothing. I've been through it several times and it's a hard topic between good intentions and bad implementation.
Vic-Bhatia · 5h ago
Former Head of Security GRC at Meta FinTech, and ex-CISO at Motorola. Now, Technical Founder at a compliance remediation engineering startup.
Some minor nits. One can't be SOC 2 "certified". You can only receive an attestation that the controls are designed (for the Type 1) and operating effectively (for the Type 2). So, the correct phrase would be that Excalidraw+ has received its "SOC 2 Type 1 attestation" for the x,y,z Trust Services Criteria (usually Security, Availability, and Confidentiality. Companies rarely select the other two - Privacy, and Processing Integrity - unless there's overlap with other compliance frameworks like HIPAA, etc.)Reason this is important is because phrasing matters, and the incorrect wording indicates lack of maturity.
Also, as others have said, no one "fails" a SOC 2 audit. You can only get one of four auditor opinions - Unmodified, Qualified, Adverse, and Disclaimer (you want to shoot for Unmodified).
As fyi, the technical areas that auditors highly scrutinize are access management (human and service accounts), change management (supply chain security and artifact security), and threat and vulnerability management (includes patch management, incident response, etc). Hope this information helps someone as they get ready for their SOC 2 attestation :-)
Similarly, the report areas you want to be very careful about are Section 3: System Description (make sure you don't take on compliance jeopardy by signing up for an overly broad system scope), and Section 4: Testing Matrices (push back on controls that don't apply to you, or the audit test plan doesn't make sense - auditors are still stuck in the early 00's / "client server legacy data center" mode and don't really understand modern cloud environments).
Finally, if you're using Vanta/Drata or something similar - please take time to read the security policy templates and don't accept it blindly for your organization - because once you do, then it gets set in stone and that's what you are audited against (example - most modern operating systems have anti-malware built in, you don't need to waste money for purchasing a separate software, at least for year one - so make sure your policy doesn't say you have a separate end point protection solution running. Another one, if you have an office that you're using as a WeWork co-working space model only, most of the physical security controls like cameras, badge systems etc either don't apply or are the landlord's responsibility, so out of scope for you).
Hope this comment helps someone! SOC 2 is made out to be way more complicated (and expensive) than it actually needs to be.
tptacek · 5h ago
Cosign all of this wholeheartedly. Push back!
The ratcheting back system scope thing is super good advice I always forget to give, too. You can get your entire software security program wrapped up in your SOC2 --- but why would you ever want to do that. The security of your software is very relevant to your customers, but it is not and should not be relevant to SOC2.
arbus5672 · 4h ago
A point to add here on the scoping. This makes sense in a B2C world but for the B2B contracts, our customers specifically check that our scope clause includes all software systems that they are contracting for plus all the support systems that help make it, including your security program etc.
tptacek · 4h ago
All our contracts are B2B, and B2B is where all my prior consulting experience was.
I am very fond of telling the story about the very significant security product company a colleague works at where they had a vendor that gave them a series of repeated Type 1s. I don't believe any of this matters.
quicklime · 5h ago
From the article:
> SOC 2 is a security and compliance framework created by the AICPA
How is it that a group of accountants (the American Institute of Certified Public Accountants) was able to create a security framework for software, and position themselves as the sole gatekeeper who decides which auditors are allowed to certify SaaS vendors?
I’m surprised that companies would look to accountants, rather than people from the tech industry, to tell them whether a vendor has good IT security practices.
Yet the whole tech industry seems to be on board with this, even Google, Microsoft, etc. How did this come to be?
tptacek · 5h ago
It's an audit standard about security. It's not a security standard. It defines a small number of extremely broad goals, like "you do risk management" and "you have access control mechanisms", which might be IT tools or might be a tabletop RPG.
You're irritated that people keep describing it at a security standard, which is understandable, but it isn't. AICPA auditors run SOC2 audits because SOC2 is an audit; it's about reconciling paperwork and evidence, about digesting policies and then checking that you actually do anything in those policies.
If you want to know about a firm's actual security program, you'll need to ask deeper questions than SOC2 can answer.
alexjplant · 5h ago
When I worked someplace undergoing a SOC2 audit I had to periodically jump into calls with our auditor and security architect to answer all sorts of highly-specific questions about how we deployed our software and the infrastructure that it ran on. At one point, for instance, the auditor told me that they needed me to demonstrate that our servers were all configured to synchronize their clocks to an NTP server. Kubernetes was a foreign concept to them and pointing to GKE docs wasn't sufficient - if memory serves I had to MacGyver some evidence together by hacking a worker node to be able to get a terminal on it and demonstrate that, yes, Google's managed VMs indeed run chronyd.
This seems to be the opposite of
> It's not a security standard. It defines a small number of extremely broad goals
Is this because of the specific auditors we were using? Are some more sympathetic than others to contemporary engineering practices?
tptacek · 5h ago
Yes, and yes. No matter how good your auditors are, unless you're accepting a shrink-wrapped set of controls from a tool provider like Vanta, you need to be pushing back on things they demand; you just have to have a clear idea of what the Common Criteria control they're looking for is (you'll see this clearly from the DRL they give you at the start of the engagement), and then when they ask for stuff that doesn't matter or isn't relevant for your org, you explain how what they're asking for has nothing to do with the actual control you're working on.
So far as I can tell there is almost nothing that is a firm requirement in a standard SOC2 Security TSC audit. We even got "background checks" rolled back.
Our audit firm is a SOC2 practice that informally spun of out of a Big 4 firm. When people get audits after using GRC tools like Drata, they often get matchmade to auditors who bid down the cost of the audit. It's possible that one of the things you get when you pay low-mid 5 figures for an audit instead of low-mid 4 figures for an audit is a lot more flexibility and back/forth with the auditors; I don't know. If that's the case: pay for the better auditors. These are rounding error expenses compared to doing extra engineering work just for SOC2.
akerl_ · 4h ago
In my experience, it's more likely it was the approach of the folks at your company that made your controls.
SOC2 (and a bunch of similar regimes) basically boil down to "have you documented enough of your company's approach to things that would be damaging to business continuity, and can you demonstrate with evidence to auditors with low-to-medium technical expertise that you are doing what you've said you'd do". Some compliance regimes and some auditors care to differing degrees about whether you can demonstrate that what you've said you'd do is actually a viable and complete way to accomplish the goal you're addressing.
So the good path is that the compliance regime has some baseline expectation like "Audit logs exist for privileged access", and whoever at your company is writing the controls writes "All the logs get sent to our SIEM, and the SIEM tracks what time it received the logs, and the SIEM is only administered by the SIEM administration team" and makes a nice diagram and once a year they show somebody that logs make it to the SIEM.
One of the bad paths is that whoever is writing the controls writes "We have a custom set of k8s helm charts which coordinate using Raft consensus to capture and replicate log data". This gets you to the bad path where now you've got to prove to several non-technical people how all that works.
Another bad path is that whoever writes the control says "well shit, I guess technically if Jimbo on the IT team went nuts, he could push a malicious update to the SIEM and then log in and delete all the data", and so they invent some Rube Goldberg machine to make that not possible, making the infrastructure insanely more complex when they could have just said "Only the SIEM admins can admin the SIEM" and leaned on the fact that auditors expect management to make risk assessments.
The other bad path is that whoever is writing the controls doesn't realize they have agency in the matter, and so they just ask the auditors what the controls should be, and the auditors hand them some boilerplate about how all the servers in the server farm should run NTP and they should uninstall telnet and make sure that their LAMP stack is patched and whatever else, because the auditors are not generally highly technical. And the control author just runs with that and you end up with a control that was just "whatever junk the auditors have amalgamated from past audits" instead of being driven by your company's stack or needs.
zdc1 · 3h ago
Similarly, I've had many instances where an auditor would ask for X and instead of trying to show them X I would instead ask them what control / Common Criteria item they were trying to get assurance on. So much of the process is about educating the auditors about how your systems operate and how you manage risks, rather than just trying to provide or build anything and everything they ask for.
*X = password expiry configuration, server antivirus, approval emails, etc.
tptacek · 4h ago
This is gold. The good-path bad-path thing is exactly the right way to think about it.
close04 · 47m ago
Most of the bad paths are usually taken by engineers with little or no experience being audited. After going through the ringer a few times (learn not to answer questions that aren't asked, or that they have a say in what that control should be) the pendulum swings in the other direction, where the answers are always good-path, not necessarily the real-path. At least until the practical part of the audit starts to look at what they really do, not what they say they do.
There's another giant pothole to navigate in many organizations, related to this:
> when they could have just said (...) and leaned on the fact that auditors expect management to make risk assessments
When management has decision paralysis and fear of accountability the engineers feel the need to compensate for the tight spot and solve problems the way they know how to solve them. With technical measures. And a technical measure that fixes the organizational problem tends to be complex and fidgety. Doubly hard for the auditors to properly take in.
quicklime · 4h ago
> Kubernetes was a foreign concept to them and pointing to GKE docs wasn't sufficient
This doesn’t surprise me one bit, in my case our auditors didn’t have a clue what GitHub was and we had to explain how code reviews and deployment pipelines worked. And these are the people who are tasked with certifying whether we’re doing our job correctly.
Sure, maybe it’s because we didn’t pick good auditors. But the accountants certified those auditors, and the whole point of certification is that we can rely on it to establish basic knowledge.
tptacek · 4h ago
You're relying on their ability to review documents and the meaningfulness of the reputation they stake on a signature saying they actually reviewed those documents. Nobody who has been through a SOC2 audit would ever reasonably think you're relying on your auditor's technology skills.
er4hn · 4h ago
I've always viewed SOC-2 as a certification for business continuity, not security. Once you view it as making sure that the service can continue running, even with disaster or heavy turnover, it makes more sense.
citizenpaul · 4h ago
Because CS refuses to formalize/unionize/license itself to its own detriment. There is no standard software developer. Accounts have some minimum bar to maintain their license. Who would you choose?
ivolimmen · 2h ago
I do not know anything about that SOC 2 (or any official sounding framework for that matter). I work at a large municipality in the Netherlands and they also meticulously document every step so that the auditors can trace and verify everything.
Seeing what they did to achieve this goal I would say that the next step (their suggestion) to do ISO would be a breeze as all those 'frameworks' require meticulously documentation.
b0a04gl · 5h ago
we had to go through this at my current place. getting SOC2 type 1 wasn't easy, it forced us to clean up years of infra mess. audit trails that never existed, access logs that were half broken, no changelog discipline. suddenly had to make all of it real.
and since we're also running an open core setup with paid SaaS, same pain. had to clearly draw lines - what parts stay public, what goes behind login, what actions need tracking. OSS gives you velocity but hides the surface area until compliance hits. things/processes no one cared about when we were shipping fast suddenly became blockers.
it just checks if you said you'd do something and whether there's proof you actually did. forces you to grow up, in a way that isn't very founder friendly
rajeshrajappan · 2h ago
This is a good write up. We are going through the same process at the moment (SOC2 & ISO27001). It has been a long journey. Compliance platforms helps a lot but a lot of work still needs to be done. It's always good to get someone with auditing experience involved early on.
shrubble · 3h ago
I’m working at a telecom and this actually does a great job of explaining why there are so many bureaucrats in the security side of the company: they must have to deal with this security theater too since telecom is heavily regulated.
blackbirdsr71 · 5h ago
How did they create those diagrams? They look nice :)
doubtfuluser · 4h ago
Check out their product ;)
danjc · 2h ago
Unfortunately, carrying a SOC 2 attestation won't save you from vendor questionnaires (and one-off security asks), but it will make them easier. ;)
9283409232 · 5h ago
On the roadmap they posted, they have "self-host Excalidraw" as backlogged. Is there a self-hosted alternative to Excalidraw? I would love to use something like this internally with my team but we self-host all of our services.
lis · 45m ago
We've forked excalidraw a while ago to allow running excalidraw without firebase as a backend. This can already be self-hosted. It needs some love, but it's a good starting point:
I've found that the best experience of self hosting excalidraw is actually using it inside nextcloud, it's called whiteboard over there but it's actually excalidraw. Setup is bit finicky but workable if you understand how reverse proxies work.
Nextcloud allows you to have an actual file based workflow and collaboration works out of the box, so if you give someone the url they can see what you're doing and let them do edits as well.
It is, but the collaboration portion is a CYOA part you need to implement yourself. There are OSS versions of that as well but they are not officially supported.
doctorpangloss · 3h ago
When will this SOC madness end?
zxexz · 3h ago
I prefer SOM, or better yet a good SBC.
In all seriousness, as annoying as it is, I’ve been through it so many times now (not as the guy managing the process! That is some serious work I thankfully have not yet had to lead). At this point, a lot of it does feel like a pretty good guideline for enforcing some best practices, if you set up your initial controls right. Basic access management, SSO, branch protection, traceability, is actually really useful, and getting it right early on has saved some serious headaches. That being said, it does seem a little over the top sometimes. Especially some of the standard compliance vendor defaults. But it’s really not that hard with a good CISO (but again, whenever I see the documentation required, I’m so thankful it’s not me).
phendrenad2 · 2h ago
FYI:
SOC 2: Systems and Organization Controls 2
SoC: System-on-Chip
Get it right!
ranger_danger · 5h ago
> We got tired of endless security questionnaires, so we got SOC 2 certified to make things smoother for everyone.
Can someone explain what they meant by this? Questionnaires by who, and why?
tptacek · 5h ago
SOC2 is viral. When you sell B2B services to a SOC2-attested company, they will have a policy somewhere that requires them to ensure that you take adequate security precautions (this is called "vendorsec"). If you're not SOC2, the standard vendorsec process is that your prospective customer gives you a giant Excel spreadsheet questionnaire to fill out. If you are SOC2, your last SOC2 report will usually suffice.
jamiecurle · 1h ago
Organisations need to ensure that doing business with you isn't over their risk threshold. One of the areas they focus on is security (cyber, info and physical and perhaps soon AI). In order to determine this they ask you a bunch of questions in which you insert answers and evidence into a spreadsheet, sometimes an online app. These are "the questionnaires". They're also pretty expensive[0]
Having a SOC 2 attestation or certified IS027001 compliance of your Information Security Management System allows you to do business with "less friction" because you can often shortcut some / all portions of those questionnaires.
B2B companies often have to answer security questionnaires as part of the buyer's procurement process. Things like "how do you maintain separation of data between tenants?" or "do you encrypt data at rest?"
A SOC 2 attestation can bypass / answer some of these by default.
Analemma_ · 5h ago
If you’re not SOC2 certified, a lot of orgs (by policy or by law) have to ask you tons of questions about your security situation to verify that you’re “as good as” SOC2 before they can do business with you.
Strictly speaking it’s better than a hard-and-fast requirement to be certified— at least you have some choice— but as was the case here it tends to be so onerous and repetitive that people tend to just get the certification.
9283409232 · 5h ago
Excalidraw is used for everything from napkin math to meeting notes to complete software architecture. Naturally the companies using it want to know what the security make up of the company is. This can come in the form of a giant document of questions or simply asking for the SOC2.
hsbauauvhabzb · 4h ago
I regularly see products with a soc2 certification but have never viewed a report. Some of the real world security of these products is total dog shit.
Is it easy to bs your way through a soc2 certificate? Like are the companies in my experience lying or gaming the system, or are the auditors incompetent?
eclipticplane · 4h ago
If you're engaged with the vendor's sales team, ask to see the report. 99% of the content is useless. Most read like a poorly performing LLM even if the controls were written pre-LLM.
Why would a vendor get a SOC 2? Because their customers demanded it. Why did their customers demand it? Their customers demanded it.
99% of it is a useless make-work assessment demanded by equally incompetent customers' auditors demanding it to justify their own existence.
All that is to say: you want to minimize the amount of security work you do for your Type 1, down to a small set of best practices you know you're going to comply with forever (single sign-on and protected branches are basically 90% of it). You can always add controls later. Removing them is a giant pain in the ass.
This is always my concern for people going into SOC2 cold: vendors in the space will use the Type 1 as an opportunity for you to upskill your team and get all sorts of stuff deployed. A terrible and easily avoided mistake.
I write this only because the piece ends with Excalidraw psyched to have cleared their Type 1. I hope their auditors told them they were always going to clear that bar.
https://news.ycombinator.com/item?id=44362665
https://news.ycombinator.com/item?id=44362720
But, true, I didn't even pay attention in our last Type 2 (I don't run security here) --- passing was a foregone conclusion.
The signal having a Type 1 says is that you're interested in even trying to pass the next one, which in itself is a good sign to everyone. Maybe being excited and proud of "passing" type 1 is a little exaggeration for folks who know the details, but I'm very willing to forgive that. A lot of orgs show a lot more pride about much more dubious things.
You can do lots of security things. I'm not saying minimize security. I'm saying minimize the security things you talk about in your Type 1.
Some minor nits. One can't be SOC 2 "certified". You can only receive an attestation that the controls are designed (for the Type 1) and operating effectively (for the Type 2). So, the correct phrase would be that Excalidraw+ has received its "SOC 2 Type 1 attestation" for the x,y,z Trust Services Criteria (usually Security, Availability, and Confidentiality. Companies rarely select the other two - Privacy, and Processing Integrity - unless there's overlap with other compliance frameworks like HIPAA, etc.)Reason this is important is because phrasing matters, and the incorrect wording indicates lack of maturity.
Also, as others have said, no one "fails" a SOC 2 audit. You can only get one of four auditor opinions - Unmodified, Qualified, Adverse, and Disclaimer (you want to shoot for Unmodified).
As fyi, the technical areas that auditors highly scrutinize are access management (human and service accounts), change management (supply chain security and artifact security), and threat and vulnerability management (includes patch management, incident response, etc). Hope this information helps someone as they get ready for their SOC 2 attestation :-)
Similarly, the report areas you want to be very careful about are Section 3: System Description (make sure you don't take on compliance jeopardy by signing up for an overly broad system scope), and Section 4: Testing Matrices (push back on controls that don't apply to you, or the audit test plan doesn't make sense - auditors are still stuck in the early 00's / "client server legacy data center" mode and don't really understand modern cloud environments).
Finally, if you're using Vanta/Drata or something similar - please take time to read the security policy templates and don't accept it blindly for your organization - because once you do, then it gets set in stone and that's what you are audited against (example - most modern operating systems have anti-malware built in, you don't need to waste money for purchasing a separate software, at least for year one - so make sure your policy doesn't say you have a separate end point protection solution running. Another one, if you have an office that you're using as a WeWork co-working space model only, most of the physical security controls like cameras, badge systems etc either don't apply or are the landlord's responsibility, so out of scope for you).
Hope this comment helps someone! SOC 2 is made out to be way more complicated (and expensive) than it actually needs to be.
The ratcheting back system scope thing is super good advice I always forget to give, too. You can get your entire software security program wrapped up in your SOC2 --- but why would you ever want to do that. The security of your software is very relevant to your customers, but it is not and should not be relevant to SOC2.
I am very fond of telling the story about the very significant security product company a colleague works at where they had a vendor that gave them a series of repeated Type 1s. I don't believe any of this matters.
> SOC 2 is a security and compliance framework created by the AICPA
How is it that a group of accountants (the American Institute of Certified Public Accountants) was able to create a security framework for software, and position themselves as the sole gatekeeper who decides which auditors are allowed to certify SaaS vendors?
I’m surprised that companies would look to accountants, rather than people from the tech industry, to tell them whether a vendor has good IT security practices.
Yet the whole tech industry seems to be on board with this, even Google, Microsoft, etc. How did this come to be?
You're irritated that people keep describing it at a security standard, which is understandable, but it isn't. AICPA auditors run SOC2 audits because SOC2 is an audit; it's about reconciling paperwork and evidence, about digesting policies and then checking that you actually do anything in those policies.
If you want to know about a firm's actual security program, you'll need to ask deeper questions than SOC2 can answer.
This seems to be the opposite of
> It's not a security standard. It defines a small number of extremely broad goals
Is this because of the specific auditors we were using? Are some more sympathetic than others to contemporary engineering practices?
So far as I can tell there is almost nothing that is a firm requirement in a standard SOC2 Security TSC audit. We even got "background checks" rolled back.
Our audit firm is a SOC2 practice that informally spun of out of a Big 4 firm. When people get audits after using GRC tools like Drata, they often get matchmade to auditors who bid down the cost of the audit. It's possible that one of the things you get when you pay low-mid 5 figures for an audit instead of low-mid 4 figures for an audit is a lot more flexibility and back/forth with the auditors; I don't know. If that's the case: pay for the better auditors. These are rounding error expenses compared to doing extra engineering work just for SOC2.
SOC2 (and a bunch of similar regimes) basically boil down to "have you documented enough of your company's approach to things that would be damaging to business continuity, and can you demonstrate with evidence to auditors with low-to-medium technical expertise that you are doing what you've said you'd do". Some compliance regimes and some auditors care to differing degrees about whether you can demonstrate that what you've said you'd do is actually a viable and complete way to accomplish the goal you're addressing.
So the good path is that the compliance regime has some baseline expectation like "Audit logs exist for privileged access", and whoever at your company is writing the controls writes "All the logs get sent to our SIEM, and the SIEM tracks what time it received the logs, and the SIEM is only administered by the SIEM administration team" and makes a nice diagram and once a year they show somebody that logs make it to the SIEM.
One of the bad paths is that whoever is writing the controls writes "We have a custom set of k8s helm charts which coordinate using Raft consensus to capture and replicate log data". This gets you to the bad path where now you've got to prove to several non-technical people how all that works.
Another bad path is that whoever writes the control says "well shit, I guess technically if Jimbo on the IT team went nuts, he could push a malicious update to the SIEM and then log in and delete all the data", and so they invent some Rube Goldberg machine to make that not possible, making the infrastructure insanely more complex when they could have just said "Only the SIEM admins can admin the SIEM" and leaned on the fact that auditors expect management to make risk assessments.
The other bad path is that whoever is writing the controls doesn't realize they have agency in the matter, and so they just ask the auditors what the controls should be, and the auditors hand them some boilerplate about how all the servers in the server farm should run NTP and they should uninstall telnet and make sure that their LAMP stack is patched and whatever else, because the auditors are not generally highly technical. And the control author just runs with that and you end up with a control that was just "whatever junk the auditors have amalgamated from past audits" instead of being driven by your company's stack or needs.
*X = password expiry configuration, server antivirus, approval emails, etc.
There's another giant pothole to navigate in many organizations, related to this:
> when they could have just said (...) and leaned on the fact that auditors expect management to make risk assessments
When management has decision paralysis and fear of accountability the engineers feel the need to compensate for the tight spot and solve problems the way they know how to solve them. With technical measures. And a technical measure that fixes the organizational problem tends to be complex and fidgety. Doubly hard for the auditors to properly take in.
This doesn’t surprise me one bit, in my case our auditors didn’t have a clue what GitHub was and we had to explain how code reviews and deployment pipelines worked. And these are the people who are tasked with certifying whether we’re doing our job correctly.
Sure, maybe it’s because we didn’t pick good auditors. But the accountants certified those auditors, and the whole point of certification is that we can rely on it to establish basic knowledge.
and since we're also running an open core setup with paid SaaS, same pain. had to clearly draw lines - what parts stay public, what goes behind login, what actions need tracking. OSS gives you velocity but hides the surface area until compliance hits. things/processes no one cared about when we were shipping fast suddenly became blockers.
it just checks if you said you'd do something and whether there's proof you actually did. forces you to grow up, in a way that isn't very founder friendly
Nextcloud allows you to have an actual file based workflow and collaboration works out of the box, so if you give someone the url they can see what you're doing and let them do edits as well.
In all seriousness, as annoying as it is, I’ve been through it so many times now (not as the guy managing the process! That is some serious work I thankfully have not yet had to lead). At this point, a lot of it does feel like a pretty good guideline for enforcing some best practices, if you set up your initial controls right. Basic access management, SSO, branch protection, traceability, is actually really useful, and getting it right early on has saved some serious headaches. That being said, it does seem a little over the top sometimes. Especially some of the standard compliance vendor defaults. But it’s really not that hard with a good CISO (but again, whenever I see the documentation required, I’m so thankful it’s not me).
SOC 2: Systems and Organization Controls 2
SoC: System-on-Chip
Get it right!
Can someone explain what they meant by this? Questionnaires by who, and why?
Having a SOC 2 attestation or certified IS027001 compliance of your Information Security Management System allows you to do business with "less friction" because you can often shortcut some / all portions of those questionnaires.
But you can never get rid of them.
[0]: https://sharedassessments.org/sig/
A SOC 2 attestation can bypass / answer some of these by default.
Strictly speaking it’s better than a hard-and-fast requirement to be certified— at least you have some choice— but as was the case here it tends to be so onerous and repetitive that people tend to just get the certification.
Is it easy to bs your way through a soc2 certificate? Like are the companies in my experience lying or gaming the system, or are the auditors incompetent?
Why would a vendor get a SOC 2? Because their customers demanded it. Why did their customers demand it? Their customers demanded it.
99% of it is a useless make-work assessment demanded by equally incompetent customers' auditors demanding it to justify their own existence.