Ditch the Checkbox, Use Plain Language, Make It Real: How to Create an Information Security Policy That Works

By Tom Ascroft, Chief Information Security Officer, Unit4 [ Join Cybersecurity Insiders ]

Information security policies are a table-stakes requirement for any significantly sized organization today but too often they are a mess composed of checkbox lists describing off-the-peg policies. CISOs now recognize the importance of a security policy document not just as a reference to win deals or a pass to get through an audit process. A good policy document can drive best practices, sharpen attitudes, and add real value.

The average security policy document may be worth a little more than the paper it is written on, but it can be just as dry. Often, a standard template is used, and the tone tends towards techno-speak and legalese. Few people read them properly, and relevant information is not easily discovered.

It can be challenging to corral all the necessary materials. Take Unit4. At one time it had multiple and disparate policies, which was probably not that exceptional compared to other large and growing organizations, which had accumulated various approaches to security guidelines through mergers and acquisitions. The  approach to compliance with standards like ISO27001 and others was done well, but in a disparate way, as different parts of the organization would have their own certification with limited scope leading to a complex situation. With collaboration and goodwill along the way, however, my team has been able to simplify and unify the certification scopes to get to 21 succinct policy points, in plain English were at all possible. Each scope was backed by a sponsor from the global leadership team with each designed to allow information to be found and understood quickly.

What we have created is a logical construct for cybersecurity policy documents. These are aligned to Unit4’s global strategy, supported by efficient processes, procedures, standards, with guidelines in place on how to get the desired outcomes of the Policies. Other organizations may take a difference approach based on their risk appetite and tolerances. Some will accept more risk than others, depending on sector, culture, and other factors: for example, we give R&D power users more rein to explore new technologies because innovation is critical to our culture and to delivering customer success.

But whatever the organization, the Information Security Framework, core security policy and supporting documentation, is critical. It lays out the attitude to security, governance processes and a simple map that points people to where they go if things happen, or they need to ask an expert. Similarly, leaders must have tools in place to educate staff, disseminate information, and execute escalation plans for when things go awry.

Over the course of this journey, we compiled some learnings on harmonizing security policies, and I wanted to share some of the key takeaways:

More than a mandate

Of course, a policy document needs to show how an organization abides by legal demands, standards, or regulatory mandates… but that need not make it dull. A strong security policy should have underpinning guidelines, processes and procedures to link those demands to the practical ways they are being met. All documentation should be presented in a readable form and be actionable in the real world rather than being filed away like a tax return.

Standards like ISO9001 or ISO27001 are important, but saying an organization adheres to them is not the be-all and end-all of the policy document. The Information Security Management System should add real value to the business that has implemented it.

Certification is critical but in a well-structured and expressed policy document it should be an automatic outcome of the actions you are taking. Therefore, a policy document should be seen as a guide to desired outcomes and a means to apply good ideas.

Divide and conquer

Start with the human factor. There shouldn’t be a one-size-fits-all approach. There will be varied levels of knowledge and areas of specialization in an organization, as well as different types of information that individuals will need to know. So, it helps if policies are split up into sections and searchable. Plain language should be used so facts are not obscured. A complex matter such as how an organization manages encryption may require some more jargon, whereas an Acceptable Usage Policy should be easy to understand.

Policy alone won’t cut it

At Unit4 we wanted to create general policies that are then supported by processes, Procedures, standards, and guidelines. Processes are interdepartmental and need to be followed to ensure that an end-to-end result is achieved – such as the Joiners, Movers and Leavers (JML) Process which explains the full lifecycle of an employee at Unit4.  Departments should have procedures that they use to get things done, such as those used in development for testing code.   All of this is supported by guidelines which explain how the organization needs people to act, or how to create a procedure or end to end process. This ensures that there is quality in everything we do, and all interactions are done in a secure way.

Living documentation 

The documentation should be updated as appropriate, and as things change, in line with the principles of continuous improvement. For example, Unit4 has been implementing new policies and guidelines for the appropriate use of AI. After studying the security rights required by some popular tools and finding some of them lacking, we quickly improved our policies to restrict access to insecure tools. And of course, a policy should be backed up by constant monitoring processes to guarantee incidents are logged and plans are being enacted – which is done by our internal audit process.  This is why we conduct phishing tests once per quarter and we know that fewer than five per cent of our staff have been caught out and they are given follow up training.

Continue to innovate

Policy can be used to advise people as to what they can and cannot do, apply rules in tools used by employees to ensure they are enforced, and then intervene on an individual basis only where necessary. But as CISOs we should always be looking to innovate. With the technologies now becoming available, we should all be on a mission to automate wherever possible to reduce the scope of human error and to ensure optimal performance of security strategies.

By considering the security policy document as something more than a regulatory commitment or chore, you may discover that it is actually a weapon for competitive differentiation. Maybe it’s time to dig out that document and take a fresh look.


No posts to display