|
|
|
|
|
|
by kungfufrog
775 days ago
|
|
|
Just out of curiosity, and since this is vaguely related to the content, how has Fly.io adjusted to SOC 2 when it comes to infrastructure changes and deployment? I read a while ago about how you guys passed SOC 2 which was an enlightening read, but I'm curious what systems you have put in place to keep velocity going and how you manage change more generally across infrastructure? My current experience is that once we started transition to SOC 2 compliance and brought in new processes everything crawled to a halt, we now have multiple layers of reviews and scheduling, and the bureaucratic process is followed at the cost of expediency and doing sensible things in a sensible way (i.e., everything must follow the process, no matter how trivial or significant.) |
|
|
The very most important thing to remember about SOC2 is that your auditors are attesting that you meet a standard that you yourself set. If you set a standard for yourself that every single change anywhere is going to be reviewed in triplicate, that's what auditors are going to check you on. So the key is to be extremely deliberate about the standard you're setting in your initial Type I. Every auditor is going to want to see some kind of change review, but the purpose of that change review is something you determine, not them. For us, the SOC2-auditable change review process is about ensuring that people merging PRs aren't 3 raccoons in a trenchcoat; it's not a vulnerability management process.
The trap people fall into is that SOC2 is often the point at which they start paying attention to security process as a whole, and they led SOC2 lead security process for them. No! Death! Be thinking about security from day 1, and have clarity about what subset of your security process you want SOC2 to measure and track.