Part of our normal new-client onboarding conversation includes the prompt "tell me about your infosec policies" -- which is usually followed by either a long pause or a sigh. Why?
Clients joining the Havoc Shield family are often ones that have experienced recent growth causing them to have the realization that they can no longer "get away with" do-it-yourself cybersecurity. Some have drafted rudimentary infosec policies on their own in their do-it-yourself era, some haven't, but almost none of them are confident that they've got the right infosec policies in place. And that's a source of anxiety (one that we can help with).
Let's talk about some of the drivers of that anxiety, and we'll share a bit at the end about what we see as the dramatically better way.
The mere topic of cybersecurity tends to stoke the flames of any underlying fear of the unknown. For example, if you don't know whether you are or aren't using DKIM and SPF, there is a good chance you don't know whether it's a "big deal" -- whether you need to find out (and potentially mitigate) today, or whether it just needs a look sometime in the coming days/weeks.
This pattern of fear of the unknown bleeds into do-it-yourself infosec policies in unhelpful ways. We see clients who previously felt like they had to make a choice between omitting a particular topic because they aren't sure if they are compliant, versus including it and being unsure if a future audit or questionnaire might cause them to look foolish by being found to be non-compliant with their own policy... a policy that they drafted.
None of that is good. It's dramatically easier to have a professional on your side that can explain esoteric infosec topics in plain language, so that you can make an informed Cost/Benefit/Risk decision when it comes to what commitments you'd like to make in your infosec policies.
This is a biggie, and there is almost no way to get over this concern without having access to someone who has reviewed infosec policies of a bunch of other companies that are similar in size / stage / industry to yours.
What you'd want is to be able to do, for example, is to ask a seasoned expert "Do most companies like mine -- same size, same industry, same maturity -- tolerate the use of personal social media accounts from company laptops?"
That's just one example, but you get the point: you want to know the norms for similarly situated companies. You want to know if your approach is dramatically less secure or dramatically more secure than similar companies. That helps you calibrate whether your infosec policies reasonable -- which is good to know in advance of a time where your organization is under the microscope of a third party. For example, when you find yourself subjected to an enterprise security questionnaire from a new customer, partner, or investor.
Please DON'T do this. If you are starting your Infosec policies from File=>New, you are reinventing the wheel in a way that is WAY more painful than it has to be. Just like there is no reason at all for a new company to write articles of incorporation from scratch (lawyers often reuse sections or at least structures from other forms they've refined over the years), there is no reason at all to start your infosec policies from a blank page. For one thing, it puts unnecessary pressure on you to be all-knowing about the appropriate structures and language; but, for another, it's almost certain to end up with a document that doesn't pass the sniff test of a third party that later reviews it in some type of audit or customer/partner interaction.
What we would recommend (and really, we can't recommend it strongly enough) is to start with battle-tested infosec policies in template form -- and then make minor customizations from that starting point. It's fair game to remove a section that you understand and aren't comfortable with. It's fair game to change a paragraph or a particular requirement. But, think of it as making a 10% modification on a document that was 100% battle-tested by organizations that used it before you.
Want help with that? We're standing by.