Ask anyone who’s worked in cybersecurity for any length of time and I’ll bet you they’ve been asked to draft or contribute to a cybersecurity policy for their org. Creating a “policy” sounds simple, but those same people who’ve been tapped to contribute will tell you that it’s not easy. That’s because enterprise-level cybersecurity policy is still a new thing and with new things comes many different interpretations and implementations. It’s also not always easy for policy writers to work with other teams to find that sweet spot where security needs and business needs are balanced … and without slowing employees down, of course.
But drafting a comprehensive cybersecurity policy is critical for enforcing guidelines and reducing liability. Here are some pro tips on what goes into a good cybersecurity policy and how you might use these tips in your own org.
What does policy really mean?
Before putting pen to paper, you’ve gotta understand what “policy” means in the first place. There are lots of terms that get tossed around when a policy is being created, but they’re not interchangeable (even though some people use them that way).
Here are a couple terms you might hear during a discussion about policy, along with their definitions:
|Policy||What it is: A plan or course of action to guide future decisions.
What it answers: What to do and why to do it.
|Procedure||What it is: Describes the exact steps for a policy to be executed.
What it answers: Who does what, when they do it, how they do it and what to do specifically.
|Audit||What it is: Measures against a set standard. An objective measurement of security. Common standards include NIST, PCI, IEC 62443.
What it answers: Are we meeting our goals? Are we following our policies?
|Assessment||What it is: Measures against the experience of others. A subjective measurement of security.
What it answers: Does it seem like we are meeting our goals? How do we feel about how the policy is being followed?
Now that we’ve got the basic definitions out of the way, I’ll use them in an example to see how they might actually be used in a conversation about your own org’s policy:
“We’re creating a new cybersecurity policy for the company. This policy will outline goals to guide us in our most important cybersecurity tasks. The policy will state that we’ll conduct an assessment every three months to verify employees are following policy and procedure and an audit every year to ensure that we’re meeting PCI compliance. Further, procedures will be made to provide guidelines and steps on accomplishing the goals set forth by the policy.”
Pro tips for writing a policy that doesn’t suck
The Valve Employee Handbook, Microsoft Standards of Business Conduct and even the US Constitution — all of these works come from large organizations and at their core is strong policy writing. What are some of the most important rules of policy writing these works use that we can use as we’re doing our own drafting?
The stuff you decide to include in your cybersecurity policy will be unique to your org — and companies’ needs when it comes to cybersecurity vary so widely that we can’t try and cram all of those nuances into a single blog post.
But all good cybersecurity policies do share some similar traits. After chatting with lots of Expletives who’ve written and contributed to countless policies over the course of their careers, here’s the final list of pro tips we came up with to help you as you’re drafting your own:
- Know your business goals. Sounds obvious, but it’s always good to gut check the direction of your policy against the broader business goals. If you’re not aligned with the same stuff the business cares about, you run the risk of cybersecurity being seen as a cost center or deadweight on the company — not exactly a position you want to be in. Michael Sutton goes into greater depth here on how to create or grow relationships with the other execs on your team so that you’re all on the same page when it comes to goals.
- Make it practical. Of course you want to create the ideal policy — but make sure the guidelines you’re creating are realistic for both your users and your own security team (if you’re lucky enough to have one). A common example of an impractical policy is one that includes lots of mandates around sensitive data protection. In these policies, orgs might say things like “all confidential data must be marked” and “all external transmission of data must be encrypted.” Sure, it sounds good on paper, but your users won’t do this because it’s a headache for them to do manually. Instead, you could ask employees to only mark the data when it’s leaving your org, and then have tech in place to do the secure transfer automatically. Setting realistic expectations for users and your own team gives you a much better chance that the rules you set forth will be followed.
- Make it applicable. Make sure the policy you’re writing is applicable to your org. For example, every so often a policy will get caught up covering too many specific security examples and how to resolve them. This turns the policy from a document providing direction to a document that’s applicable in only a few specific circumstances. And when a policy is not always applicable people start to ignore it.
- Be concise. You’re not drafting the Magna Carta here. Keep the policy short and to the point so that employees will actually read it. There’s sometimes a tendency to include a bunch of boilerplate language that “all policies must have” — but don’t do that. The longer the policy, the less likely your users are to internalize it.
- Write in plain English. All of us cybersecurity folks love speaking in APTs, CVEs, XSS, and LEET (sometimes). But remember that Mike in finance and Karen in sales don’t “speak” cybersecurity. Write your policy in everyday language so that anyone in your org — regardless of their knowledge level about cyber threats — can understand it.
Got a draft? Here are your next steps
Once you’ve got a draft of your policy, a great way to determine whether your policy passes the sniff test in the five areas mentioned above is to share it with others and ask for feedback. (Bonus: This is a great way to socialize the policy with your executive team and make some new friends.)
There are also numerous resources you can review as you’re drafting your policy that might help you get a better understanding of what a policy should and shouldn’t cover — take a look at NATO CCDCOE (NATO Cooperative Cyber Defence Centre of Excellence), NCCoE (National Cybersecurity Center of Excellence) or the NIST CSF (National Institute of Standard and Technology Cybersecurity Framework) for starters.
With that, you’re well on your way to becoming the policy whiz kid of the office … don’t let it all go to your head.
John Lawrence is a Security Operations Center intern at Expel. Check out his LinkedIn profile.