←back to thread

233 points gmays | 2 comments | | HN request time: 0.435s | source
Show context
Vic-Bhatia ◴[] No.44362665[source]
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.

replies(2): >>44362673 #>>44365244 #
tptacek ◴[] No.44362673[source]
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.

replies(1): >>44362711 #
1. arbus5672 ◴[] No.44362711[source]
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.
replies(1): >>44362754 #
2. tptacek ◴[] No.44362754[source]
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.