Information security policies provide vital support to security professionals as they strive to reduce the risk profile of a business and fend off both internal and external threats.
The trouble is that very few organisations take the time and trouble to create decent policies; instead they are happy to download examples from the web and cut and paste as they see fit. The resultant mess is no good to anyone, and can often leave the business open to unforeseen issues.
A prime example of producing both good and bad information security policies is the National Health Service (NHS).
This huge organisation both shares and consumes vast amounts of very private information on a daily basis, so quite rightly there is a requirement on those that handle such data to have in place supporting information security policies that are in turn subject to an annual audit.
During February and March, throughout the length and breadth of the country, information governance (IG) leads of NHS trusts and other assorted healthcare providers gather evidence to submit to the Department of Health (DH) for this audit, otherwise called the IG Toolkit.
The IG Toolkit is loosely based on the ISO 27001 standard and is mandatory for all NHS organisations and any others who wish to provide services into the NHS. This covers the main areas of governance and assurance:
- Information governance management
- Confidentiality and data protection assurance
- Information security assurance
- Clinical information assurance
- Corporate information assurance.
The major area of focus is information security assurance. Interestingly, information security assurance accounts for about one-third of the requirements, which are combined to form an annual score.
For an organisation to pass the audit and achieve a "satisfactory" rating, they must now achieve a level 2 score for every requirement (each requirement has a possible score of 0-3). Failure to meet those minimum requirements would mean the organisation cannot be commissioned to provide services to the NHS. Clearly, failing to meet this would have a significant impact on any organisation currently providing services or those wishing to do so from 1 April 2013.
Despite the IG toolkit being very well established in the NHS arena – it is now in its 10th year – NHS trusts are still in need of specialist IG expertise to navigate the difficult waters of the toolkit, and non-NHS organisations coming to this for the first time find themselves very quickly out of their depth.
A lot of the issues are in the interpretation of the requirements and the specialised environment in which the NHS operates. Insider knowledge and experience are certainly key to a smoother ride when making a submission.
Information security policies are supposed to be read, understood and followed by all staff in the organisation
Not surprisingly, information policies and procedures make up the bulk of the evidence required to be submitted. Lest they be accused of wasting scarce public resources by continually reinventing the wheel, it is common practice for trusts to borrow such policies and procedure documents from friendly neighbours. This is fine until these policies are subject to an audit.
On undertaking a full review of information security policies, it very quickly became clear that the public sector has a specific and unusual way of tackling such documentation. A typical information security policy in the NHS runs to between 35 and 45 pages and goes into incredible detail about all sorts of minutia, including such esoteric concerns as to the cable trays necessary for datacentres.
This demonstrates a fundamental misunderstanding of the intended audience for these documents. It is not the IT professional looking to install or otherwise look after NHS IT systems – instead they are supposed to be read, understood and followed by all staff in the organisation.
The audience had been completely forgotten in the process of producing this document, compounded by the fact that the same document (slightly altered in each case to fit the name of the different trust) was being used across the patch as an exemplar of what should appear in the policy.
This is a crazy situation and a fresh approach is needed.
I suggest that each information security policy is approached from a number of key questions:
- What purpose is this policy meant to serve? Am I ticking a box, or is it adding real value?
- Have I aligned my policy with any subsequent information governance training I might deliver?
- Have I aligned my policy to the business objectives of the organisation?
- Is there a regulatory and/or statutory basis to the policy, or is it more guidance on good practice?
- Who is my audience for this policy?
- What is the absolute minimum information they need to have? Do I really need all the detail written into this policy, or is this better written in System Specific Security Policies (SSSPs) for the IT professional?
- What is the best format for my audience to receive this information?
- What are the key messages that I want them to retain?
In answering these questions and thinking from the user's point of view, I am often able successfully to cull policies from 45 pages down to six, including the necessary title pages and the Equal Opportunities Impact Assessment (these are mandatory for NHS documentation such as this.)
- Keep it as short as possible
- Keep it relevant to the audience
- Keep it aligned to the needs of the business
- Keep it aligned to the legislation and regulatory frameworks in which you operate
- Do not marginalise it by aiming to "tick the box", as the policy needs to add value to the employee and the overall outcomes and behaviours you are looking to promote
The typical information security policy may have the following headings:
- Document Control
- Document Location
- Revision History
- Document History
- Introduction and Purpose
- Your Responsibilities
- Our Responsibilities
- Where to find more information
- Equal Opportunities Impact Assessment
This provides a more structured and accessible document.
I accept that you may feel I have left out some key components into other separate documents and will be relying on the user to source and read them as well, but I still feel it a valid direction in which to travel.
You may also have expected to see something in there about passwords or other aspects of information security, but the point is that the other key security issues will be dealt with in the "acceptable use policy" and the "use of internet and email policy", tangible data assets dealt with in the "clear desk policy", and so on.
In addition to making staff read and sign to acknowledge any documents, it is key to ensure that they have read and actually understood the policies in question. The best way of achieving this is to provide suitable and focused governance training to reinforce the messages and bring the policy alive with current local examples.
It is important to spend considerable time making training relevant and accessible for all attendees so they leave the session with an engaged attitude to information security, rather than feel they have been put through an obligatory sheep dip and learnt nothing of relevance.
Information governance is a massive area, and users need to tackle the elephant one chunk at a time, rather than as a whole.
In the broadest sense, awareness training should inform users of the broad scope of IG – that it covers appropriate collection of data, appropriate use, data quality, records management, archiving and secure destruction, privacy, confidentiality, appropriate use of business-provided IT systems, appropriate use of social networking and so on. Each area benefits from its own policy documents, which can similarly be kept to minimum size and scope so users are not overwhelmed by the full scope of their responsibilities.
Download additional articles on information security
The policy document is exactly that – a simple statement of the business position on the chosen topic (the "why"), not to be confused with the procedural documentation which deals with "how" the policy is to be enacted. Procedures are sometimes necessarily much longer documents if they are describing complex processes which must be followed. The system-specific security policies and corresponding procedures mentioned earlier tend to fall into this category.
Ideally, the policy should be brief and to the point about the user’s responsibilities towards the information they collect, use, access or otherwise process, and to sign-post them to the other relevant policies and procedures for the areas in which they operate. There is very little point subjecting a hospital porter to a treatise on how to use the patient administration system, for example, if they will never have access to that system.
By following these ideas, you should be able to create an excellent information security policy, but more importantly have an engaged set of employees looking after your organisation’s assets.
Andi Scott is a senior information governance consultant and practice head at Incoming Thought
Image: Creatas Images/Thinkstock
This was first published in April 2013