It is a long-standing principle that all organisations, from the large multi-national to the small business, need and should have some kind of security policy.
How this security policy is constructed will, of course, differ from organisation to organisation, but it is essential that one exists to ensure that the organisation’s information assets are appropriately protected. Ultimately, a security policy must convey the senior management’s direction and commitment for security. It should provide unambiguous instruction on how the organisation intends to protect its information assets from being compromised and identify the principles for what is, and indeed what is not, permitted from a security perspective.
Unfortunately, the word ‘policy’ often provokes an adverse reaction. This is because policy is often littered with legalese, or overly technical language showing a complete disregard for the target audience. Policy is also often seen as stick to beat people with if, and hopefully not when, things go wrong. Consequently, security policies have a tendency of generating a negative response from people. But it doesn’t have to be this way!
Developing a security policy doesn’t need to be onerous. The worst mistake you can make is to try to create a policy which sounds like a policy so it is important to never lose sight of who will be reading it. If the intended audience of a policy is information technology professionals then you may be justified in filling it with technical jargon and three letter acronyms. However, the intended audience of a policy will typically include people from across the organisation with differing levels of experience (e.g. HR, Finance and Logistics). Will technical language work for all of them? If your employees don’t understand the policy, how can they be expected to follow to it? When developing policy unless all of the intended audience has the same experience and understanding you are better off using plain English and providing clear unambiguous instructions to ensure your employees understand what is expected of them, thereby reducing the opportunity for things to go wrong.
A previous client of ours specifically stated during the initial policy development consultation that the policy needed to be jargon-free and easy to understand (i.e. it had to be written in plain English). They were concerned that using confusing terminology would result in readers that are unfamiliar with technical terminology becoming detached, or worse uninterested in the content. Indeed, they went further than this by insisting that the policy was called a Security Policy, as their staff would consider an Information Security Policy to be limited to ICT security.
One way to address this is to identify who the audience for the various policy statements. Using our previous client as an example, during the engagement we identified over 100 policy statements that needed to be incorporated into their high-level security policy. Each of these policy statements had an intended audience specific to that statement (e.g. Manager ICT Operations, Human Resources, All Employees etc.). This served two purposes, firstly, a policy reader would immediately be able to identify whether a policy statement was relevant to them or not. Secondly, if the policy was posted on the organisation’s intranet, or exported to a spreadsheet, the reader could search or filter the policy statements by audience to present only those that apply to their role.
So how do you determine what goes into a high-level security policy? Well again there is no rule of thumb or ‘one-size fits all’ model, it will depend on the needs of the individual organisation. For example, a small business may find that they can encompass all their security requirements in one policy document that incorporates all policy areas such as Personnel Security, Physical Security and Access Control. In contrast, a larger business may find that a single policy document is insufficient for their needs and that they need additional policy artefacts that provide more granular detail on specific topics (e.g. Acceptable Use Policy, Privileged Account Policy, Cloud Computing Policy etc).
As I stated earlier, there is no single policy format that will work for all organisations, however, there are some elements I feel are necessary considerations for all security policy development:
• It is important that all relevant regulatory, legislative and contractual obligations are identified and incorporated into the policy. The policy should not contradict or disregard these artefacts/requirements.
• A security policy should not adversely affect or disrupt the business function. On the contrary, it should enhance the business, and provide a degree of assurance that the day–to–day business processes are conducted in a secure manner.
• The policy should be practical, if the organisation not be in a position to apply a policy statement, it may be necessary to review and revise it. That said, having a policy that is aspirational should not be discouraged, providing there is clear intent from the management to implement it (and the commitment to provide the required budget and/or resource to do so).
• Brevity is an important consideration. A reader confronted by hundreds of pages of policy will at best feel daunted and at worst indifferent. As I mentioned earlier, defining the audience for a policy statements will considerably reduce the number of statements that need to be read by a particular reader.
• Policy should explain ‘why’ the policy has been developed and ‘what’ the direction is. ‘How’ the direction is to be delivered should be identified in the supporting artefacts, such as standards, guidelines, processes and procedures.
• Policies are living documents that reflect the organisation’s environment, culture and direction. As such, any change to the organisation’s business strategy, opportunities and risks (or the legislation and regulations they are required to comply with) should be incorporated as soon as possible and the changes communicated.
Writing a security policy does not need to fill you with dread. The most important considerations are to ensure that it reflects the organisation’s intent and direction for security, as well as giving a clear indication as to how the policy can aid the business function. Whilst it is important that all regulatory and legislative considerations are reflected, a policy needs to be more than a list of do’s and don’ts. Giving the reader context and allowing them to understand the ‘why’ and ‘what’ in clear, concise and jargon-free language will help prevent reader apathy. Engaging the reader with a policy that is easily understood will greatly increase the likelihood that they will comply with the policy. Compliance with well-defined policy by employees significantly diminishes the opportunity for security incidents to eventuate. But how will we know if our policy is successful? One answer is to identify and define appropriate security metrics that demonstrate the performance of the policy, but this is something I will discuss in a future article.