Excalidraw+ Is Now SoC 2 Certified
plus.excalidraw.com
plus.excalidraw.com
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.
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.
But, true, I didn't even pay attention in our last Type 2 (I don't run security here) --- passing was a foregone conclusion.
Or at least *cough*, that's what I've heard.
If I hire a fire safety consultant, I gotta expect he’s going to recommend sprinklers and extinguishers and fire doors.
The auditors want you to get the Type 1. To do that they need docs and policies. If they say “send us your change management policy” and your team either says “we don’t have one, what would it look like” or sends them a one-line policy that says “The team does change reviews”, the auditors are going to send back recommendations for what you should include. They’re trying to be helpful (within the specific scope of getting you a type 1), but they aren’t engineers and don’t know your system. So a lot of their advice is going to be irrational and scope-creep. As a mundane example: the easiest thing for them to suggest if your change management policy doesn’t exist or looks weak to them is “set up a change control board that meets weekly to review all changes”, but that would be nuts to implement.
185.199.108.153 185.199.109.153 185.199.110.153 185.199.111.153
which you already have. Your CNAME record at www.rami.wiki needs to point to "ramimac.github.io/wiki", and your CNAME file in the root of your repo needs to contain "www.rami.wiki" (www is necessary).
At this point, https://rami.wiki should automatically redirect to https://www.rami.wiki.
At least, that's more or less how mine is set up and it works for me :) I had the same issue as you until I got that all straightened out.
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.
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.
*X = password expiry configuration, server antivirus, approval emails, etc.
At a large financial company, I was tasked with gathering some audit data to evidence that only certain people could access certain things. To do that, we had to get the list of users with access.
The access control tool at the time used plain text files. I sent the plaintext file with the list of names to the auditor. The auditor said that won't do, because it could have been forged. That's fair.
After lots and back and fourths, the solution was that I needed to send over a screenshot of a terminal window with a list of names, because that's what the auditor expected, and that's what had previously been submitted.
Not a screenshot of the actual document. Not a terminal showing the hostname or similar on the server. I had to get the textfile I'd sent, open it in vim, take a screenshot of vim, and submit that.
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.
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.
* https://github.com/b310-digital/excalidraw
* https://github.com/b310-digital/excalidraw-room/
* https://gitlab.com/kiliandeca/excalidraw-fork
* https://gitlab.com/kiliandeca/excalidraw-storage-backendCan someone explain what they meant by this? Questionnaires by who, and why?
Getting a well-designed SOC2 will help some of this. If you are in an industry with a lot of regulation, your customers will ask or insist on getting ISO 27001. That is a substantial amount of work.
So if you have both, the spreadsheets won't totally go away, but it will reduce the load.
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.
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.
We are completely remote with no office. Most of our developers are on Ubuntu, and we use rented laptops which gets shipped to them by our vendors (we have couple of them, and we select one depending upon which is closest to their area of operation).
Due to this, I couldn't figure out a proper MDM based solution. We evaluated Fleetdm, Kaspersky, eSet, ...) But none of them worked well with Ubuntu laptops.
What do you guys use?
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.
But forget the report for a moment. The work that goes into answering the questions and providing the evidence requires tidiness and systematic attention at a scale and duration that is unlikely without the SOC 2 (or ISO xxxxx or whatever) audit looming. That imposed journey is very much the reward.
YMMV, but as someone who's wrangled organizations through multiple years and scopes of SOC 2: You may not get a lot out of the final report, but the process is a tremendous forcing function for good practices that most organizations need.
Sure, it may raise the baseline, but only as much as a teacher telling off a bunch of middle school boys before walking away.
At least for our auditor, that means pentest and remediation steps, risk assessment and treatment steps, BCP/DRP and IRP must be updated and each tested, vulnerabilities reported, access audited, etc. Ship-shapeness becomes metronomic and mandatory.
The gating factor isn't the duration or intensity of the auditor's gaze, but how well the local infosec team can use that gaze to bump the organization forward ("make hay while the sun shines"), and whether/how well it can make the process a ratcheting movement forward. If everything and everyone could backslide 100%, I would share your cynicism. That decay is not inevitable IME. Of course, YMMV.
Is it to use something like Vanta/Drata? Are they any good?
Vanta/Drata are big players and they're charging big time for their platform. That's why I've started working on own startups, that's meant to disrupt this for SMBs - by making it waaay more affordable (for managing compliance, not attestation/certification itself, which we don't do).
An unsolicited suggestion: it would be helpful if you could clearly walk through how your tool supports GRC compliance. I haven’t been able to find this kind of explanation on your site—or others.
For example, something like this:
Step 1: Select a Program – Choose the compliance framework you’re targeting (e.g., ISO 27001, SOC 2, etc.).
Step 2: Guided Evidence Collection – You’re taken through a step-by-step questionnaire outlining what evidence is needed.
Step 3: Pre-Built Templates – For each requirement, you provide example templates or guidance on what needs to be submitted or completed.
Step 4: Centralized Dashboard – All responses and documents are organized into one place that can be reviewed by an auditor.
Step 5: Auditor Handoff – Once everything is ready, you recommend a third-party auditor to complete the certification process.
It would also be helpful to clarify what’s included in your offering vs. what still requires external engagement (like paying for the actual audit).
Just sharing this in case it’s helpful—apologies if I’ve misunderstood the flow above, but hopefully this illustrates the kind of clarity that might help others too.
Sharing the link for others to see https://humadroid.io
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!
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
Cosigned. I've lived exactly this in startups and SME.
Perhaps more surprising—but also somewhat reassuring—I've heard the exact same thing from Fortune 500 insiders themselves facing SOC 2, ISO 9xxx, ISO 27xxxx, lorem ipsum for the first time.
Everyone, everywhere apparently lets the bits hang out—until the day comes when someone requires formal processes, checkpoints, documentation, and audits. Then pants go on fast.