Excalidraw+ Is Now SoC 2 Certified

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.

>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.

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'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 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'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.

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?

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...

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.

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

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.

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

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.

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.

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...

"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.

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.