5 Tips to Develop an IT Security Policy

It’s an all too familiar experience for many IT teams: a crisis hits, whether it’s an outage, security breach, or Cryptolocker infection. The culprit? User error due to unsafe computer practices. Your company has a security policy, but it’s stodgy, out of date, and most users just sign the bottom without ever reading it. Here are five ways to develop a clear, engaging, and inclusive corporate information security document that will actually get followed and protect your vital data.
 

Involve Your Employees at Every Level

Without knowledge of how employees are using technology in the trenches, how can you write a realistic security policy and expect it to be followed? Even if the person drafting your policy knows about infosec best practices, the latest threats, and the hardware and software in use across the company, without involving your users, you will meet with resistance.

Poll IT, the users themselves, and supervisors. If a security measure is too much of a hassle, it’s likely to be ignored or circumvented. For example, if your file sharing platform requires a password reset every couple of weeks, plus a lengthy authentication process, and users have to be on the company network to access it, they will probably go ahead and use a public solution instead.

Start Small

Begin with the most critical components and add on to your policy as needed. You’ll never be able to cover every possible attack vector or data loss in a single document, especially not one that you expect users to read. Keep it simple and add more written rules if it becomes evident that they require documentation. You should review your policy every couple of years to update it anyway, which is a good time to add anything new.

Keep It Flexible, But Within a Structure

As you revisit and revise your policy, you’ll find you need to change or modify based on new technologies, new threats, and user behavior. By structuring your policy into chunks that can be revised or interpreted in smaller pieces, you can keep things flexible while also maintaining a strong secure baseline that never changes.

Begin with a draft that will go all the way to your top executives for signature, which is the baseline structure of your security policy. On top of this, you can build additional policies, standards, guidelines, and procedures. Each of these components should be revisited every one or two years, while the baseline security policy stays in place for five or even ten years. Some of these guidelines may be structured so that different parts of your business can circumvent them or bend them without penalty; while others might be more strict. These security exceptions must be formally requested and documented, with a set timeframe.

For example, your IT team needs to be able to test security systems and therefore is exempt from what would normally be considered insecure behavior. Or a new vendor system doesn’t meet your password requirements. Or a legal hold is placed on your e-mail eDiscovery systems, bypassing your retention policy.  You cannot plan for all of these exceptions in your initial document, but they can still remain compliant with top-level best practices and policy if you start with a strong base.

Write It Right

Don’t just give the task of writing a comprehensive security policy to your Head of IT, a CTO, or even a compliance officer, unless they have previous experience writing policy. The word choice itself is vital both for communication and potentially has legal implications. If you don’t have any employees with experience writing policy, find an outside contractor to review and help draft.

This doesn’t mean that your policy has to be stuffy legalese. Match it to your corporate culture so users are comfortable reading and referring to it. Keep the end user in mind when writing—the effect on their daily work is what is important for the final draft, as that is what they’ll be thinking about.

The structure mentioned above comes into play as you draft each piece, as documents further down the organizational stack could get more and more specific, oriented around individual business processes, applications, departments, or systems.

Finally, carefully edit and be sure to remain consistent throughout in the person (you vs. they) and the verbs used (should vs. will).

Test, Test, Test

Try a few examples of security issues that your users will encounter and attempt to adhere to your policy. For example, bring in your own personal device and attempt to set up the usual workplace applications, e-mail, and network settings. How does the policy work with this scenario? On the other end, try and break your security protocol. See if you can access data or insecure websites—but do it carefully so as not to compromise actual working business systems. Ask your users for feedback as you roll out the policy. If they hit roadblocks to their daily work, you might need to adjust.

Security and compliance are vital for businesses of every size, from 5 employees to 500,000. A Cryptolocker infection won’t bring a huge enterprise to its knees the way it will a small business, and a small business doesn’t usually face the same legal consequences or massive amounts of sensitive data as a large company. But in both cases a documented security policy proves the roadmap to maintain the security integrity of your IT systems.