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.
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).
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?
I don’t think it’s malicious. I usually see it happen when the company staff in charge of working with the auditors either aren’t interested in engaging (often due to stigma and baggage about the compliance industry) or don’t realize the dynamic of what they’re responsible for.
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.
Or the vendors you’re paying to help you adopt a bunch of corporate paperwork are helping you adopt a bunch of corporate paperwork. Kinda their job, no?
If I hire a fire safety consultant, I gotta expect he’s going to recommend sprinklers and extinguishers and fire doors.
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.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
I have also felt the need to claim to be “SOC 2 Certified”. It’s made hard by so many vendors using that language, that it’s come to be expected. Do I want to start the sales call by explaining that the purchaser is wrong… or just say yes, and if you sign this NDA you can have our auditors report.
> 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?
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.
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?
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.
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.
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.
> "whatever junk the auditors have amalgamated from past audits"
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.
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.
“Management” here is a term of art. For many compliance regimes and controls, the engineer responsible for a system can make a statement as “management”.
> 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.
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.
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.
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?
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
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.
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.
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:
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.
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.
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.
I can tell many stories about the giant spreadsheets. The larges of them has near 1000 rows. And if you have a lot of security-conscious customers, you will get a lot of them. And they supposedly all cover the same topics, but they all divide the topics up differently. Thus, the hope of generalizing a pool of answers is defeated.
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.
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.
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.
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.
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.
Just a query, how do people who are going through the certification process manage their endpoint management? Do you use any MDM solution?
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.
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.
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.
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.
Meta used/uses Excalidraw for technical interviews, but mostly as an Etherpad (cooperative text editor) for unexecuted, mentally-evaluated code. As such, PiratePad/Etherpad or Google Doc would suffice.
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?
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.
Enh. I have no great love for most SOC 2 reports. They're seemingly endless and contain lots of blah blah blah and they're written defensively, so it's often hard to get actionable intel and insight out of them. But the System Description and the auditor exceptions are often helpful.
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.
The skepticism is warranted, but the audits must be periodically refreshed.
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.
You could even use google drive with set of spreadsheets and screenshot. The biggest problem is getting through requirements, understanding what they actually mean and having some sort of framework for writing policies. But once you past that, it's manageable. Vanta/Drata just make this easier.
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).
One thing I really appreciate about your site is the transparent pricing—something I haven’t seen on any other platform. It also seems surprisingly affordable, assuming I’m correctly understanding what’s included.
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.
That's a great suggestion, thanks! More or less it works like so, policy drafts are auto-generated by AI, you need to go through controls and provide the evidence. To support you better on this, we allow redoing their description with your context - and that helps a lot. On top of that we're able to generate some potential risks for you (as this part is also tricky to get started with). Now I'm completing business continuity planning (again - will get AI assistance) and then we need to add incidents - that should make us a complete platform and hopefully I'll be able to do Show HN post ;)
Nonetheless - thanks again, we'll add how the process looks like to the landing page.
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).
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.
Thomas is being a good HN citizen so he's not plugging his own blogpost, but for anyone else embarking on their SOC2 journey i'll plug his guide for him: https://fly.io/blog/soc2-the-screenshots-will-continue-until...
These two comments on this thread are as good as anything I've read on this subject:
https://news.ycombinator.com/item?id=44362665
https://news.ycombinator.com/item?id=44362720
In case it's helpful, I also collate quality blog posts in this genre over at https://rami.wiki/soc2/
I get a 404 currently, fwiw.
Fixed! Pages drops the custom domain whenever I push right now, have been putting off debugging it - apologies
If I understand the issue correctly, you just need a file called CNAME in the root of your repo containing your custom domain, like this: https://github.com/justusthane/justusthane.github.io/blob/ma...
Thanks! Unfortunately, I've somehow fallen off the paved road :) https://github.com/ramimac/wiki/blob/main/CNAME
GH Pages is particular about how your apex and www records are set up. I believe you need apex A records pointing to
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.
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?
I don’t think it’s malicious. I usually see it happen when the company staff in charge of working with the auditors either aren’t interested in engaging (often due to stigma and baggage about the compliance industry) or don’t realize the dynamic of what they’re responsible for.
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.
Or the vendors you’re paying to help you adopt a bunch of corporate paperwork are helping you adopt a bunch of corporate paperwork. Kinda their job, no?
If I hire a fire safety consultant, I gotta expect he’s going to recommend sprinklers and extinguishers and fire doors.
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.
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.
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.
"Nobody cares about trivial exceptions"...except the most persnickety GRC teams of your most persnickety enterprise customers.
Or at least *cough*, that's what I've heard.
>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.
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.
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.
Congratulations, Excalidraw. Also I love your product. Meanwhile, let's get back to talking about the pitfalls of actually getting SOC2.
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.
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.
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.
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.
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.
I have also felt the need to claim to be “SOC 2 Certified”. It’s made hard by so many vendors using that language, that it’s come to be expected. Do I want to start the sales call by explaining that the purchaser is wrong… or just say yes, and if you sign this NDA you can have our auditors report.
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?
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.
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?
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.
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.
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.
> "whatever junk the auditors have amalgamated from past audits"
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 is gold. The good-path bad-path thing is exactly the right way to think about it.
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.
“Management” here is a term of art. For many compliance regimes and controls, the engineer responsible for a system can make a statement as “management”.
> 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.
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.
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.
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?
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
> forces you to grow up
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.
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.
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:
the code is here... MIT license https://github.com/excalidraw/excalidraw
Oh cool. Didn't know excalidraw was open source.
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.
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.
> 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?
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.
I can tell many stories about the giant spreadsheets. The larges of them has near 1000 rows. And if you have a lot of security-conscious customers, you will get a lot of them. And they supposedly all cover the same topics, but they all divide the topics up differently. Thus, the hope of generalizing a pool of answers is defeated.
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.
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.
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.
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.
But you can never get rid of them.
[0]: https://sharedassessments.org/sig/
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.
Unfortunately, carrying a SOC 2 attestation won't save you from vendor questionnaires (and one-off security asks), but it will make them easier. ;)
Especially if you have one of those effusive "trust pages" at https://trust.yourdomain.com. They really work.
Just a query, how do people who are going through the certification process manage their endpoint management? Do you use any MDM solution?
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?
How did they create those diagrams? They look nice :)
Check out their product ;)
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.
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.
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.
Meta used/uses Excalidraw for technical interviews, but mostly as an Etherpad (cooperative text editor) for unexecuted, mentally-evaluated code. As such, PiratePad/Etherpad or Google Doc would suffice.
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?
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.
Enh. I have no great love for most SOC 2 reports. They're seemingly endless and contain lots of blah blah blah and they're written defensively, so it's often hard to get actionable intel and insight out of them. But the System Description and the auditor exceptions are often helpful.
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.
Functions for as long as the auditor is looking in that project areas direction, in my experience.
Sure, it may raise the baseline, but only as much as a teacher telling off a bunch of middle school boys before walking away.
The skepticism is warranted, but the audits must be periodically refreshed.
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.
Yes.
What’s the easiest way to get certified?
Is it to use something like Vanta/Drata? Are they any good?
You could even use google drive with set of spreadsheets and screenshot. The biggest problem is getting through requirements, understanding what they actually mean and having some sort of framework for writing policies. But once you past that, it's manageable. Vanta/Drata just make this easier.
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).
One thing I really appreciate about your site is the transparent pricing—something I haven’t seen on any other platform. It also seems surprisingly affordable, assuming I’m correctly understanding what’s included.
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.
That's a great suggestion, thanks! More or less it works like so, policy drafts are auto-generated by AI, you need to go through controls and provide the evidence. To support you better on this, we allow redoing their description with your context - and that helps a lot. On top of that we're able to generate some potential risks for you (as this part is also tricky to get started with). Now I'm completing business continuity planning (again - will get AI assistance) and then we need to add incidents - that should make us a complete platform and hopefully I'll be able to do Show HN post ;) Nonetheless - thanks again, we'll add how the process looks like to the landing page.
When will this SOC madness end?
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).
FYI:
SOC 2: Systems and Organization Controls 2
SoC: System-on-Chip
Get it right!
Well, if we're picky here, then it should actually be: SOC 2® ;)