The policy section and example policy had me cringing hard, not because of the "simplistic" tone (well, a little) but more because of the blithe ignorance of why policies are written with "whereas" and "designee" and such. It's all well and good to have a quirky fun simple summary of a policy, or a simple straightforward policy that is super vague to cover every base, but don't discount the legal jargon.
I don't know if the example given is real or not, but something as simple as saying "Slack or E-mail" might make sense if those are literally the only two methods of electronic communication used, but when shit hits the fan that language won't cover it if someone sent a SMS. And let's face it: shit will hit the fan.
This doesn't mean any given policy has to be unreadable (and in fact that might be detrimental) but neither can it be so jocular that it is ignored or unenforceable. If fly.io has received ISO certifications with those examples in actual usage, I'd be skeptical about who issued those certs; ISO doesn't certify directly, relying on the free market reputation of external companies/consultants to be truthful about compliance. Of course, ISO compliance isn't legally enforceable other than as a checkbox for some other procurement or investigative body, so maybe a dice roll on whether anyone checks is worth the cost.
Just my two cents, take it for what it's worth in 2022 USD.
As I am now an authority on the authoring of security policies I can reliably inform you: you are criticizing an information security policy for not being a data classification policy. The data classification policy spells out exactly what kinds of information are suitable for exactly which modes of transmission and storage.
SOC2 demands both an information security policy and a data classification policy. And a retention policy. And an access review policy. And an incident response policy. And a BC/DR policy. And a change management policy. And a vulnerability management policy. And a vendor management policy. These are different policies. Some of them have broad audiences, like the data classification policy, which is incorporated by reference in the information security policy. Some of them have narrower audiences, like the vulnerability management policy.
Yes, thank you, that soothes me somewhat. I am not overly familiar with SOC2 specifically, so I read it as a generality. I was kinda harsh, but mainly because I really don't want somebody unfamiliar to think policy writing in general is a waste of time and that they should globally adopt the same sort of language as in the example provided. To be fair, I think the world of what fly.io has been doing. Just not a fan of that particular section.
I don't know if the example given is real or not, but something as simple as saying "Slack or E-mail" might make sense if those are literally the only two methods of electronic communication used, but when shit hits the fan that language won't cover it if someone sent a SMS. And let's face it: shit will hit the fan.
This doesn't mean any given policy has to be unreadable (and in fact that might be detrimental) but neither can it be so jocular that it is ignored or unenforceable. If fly.io has received ISO certifications with those examples in actual usage, I'd be skeptical about who issued those certs; ISO doesn't certify directly, relying on the free market reputation of external companies/consultants to be truthful about compliance. Of course, ISO compliance isn't legally enforceable other than as a checkbox for some other procurement or investigative body, so maybe a dice roll on whether anyone checks is worth the cost.
Just my two cents, take it for what it's worth in 2022 USD.