Introduction
Why is the policy needed? Because there’s a problem, a risk, etc. that needs explicit actions or precautions. This may be supported by statements such as ‘This policy supports our compliance with legislation abc’. Note that the legislation would not exist unless there are problems to be addressed so the legislation is not the primary reason for the policy.
What is a policy?
Within the context of Governance, a policy is usually a statement of a control or standard that is mandated across the organisation. Consequently it should normally be approved at Director level. Sometimes a policy will only apply to a part of the organisation, & may be known as a Standard Operating Procedure (SOP). An SOP though is usually more detailed than a policy. An approach may be to state ‘It is policy to follow the SOP for identifying patients’. The SOP document then sets out the detailed steps to be followed. Over time the Policy will not change much, but the SOP may do so as systems& processes evolve.
Content
Identify the following:
- Purpose/ Objectives
- What is to be achieved? Identify the risk will be removed, reduced, etc. by doing X & Y.
- Scope
- Who does it apply to?
- What systems or processes are in scope & which are out?
- Roles & responsibilities (R&R)
- Roles by post name (e.g. Head of IT) or special role (SIRO). State responsibilities in broad terms, specific responsibilities will be given later in the body of the document.
- The body of the Policy
This is the bit that you want your staff to read & comply with. Be clear. Provide enough explanation so that staff can understand why the control is needed, they are not robots so give them a context.
e.g. ‘Control: Staff will only use IT equipment issued by the organisation. Staff are not to use their own IT equipment for business purposes. Requests for exceptions must be approved by your manager/head of department before approval by the Head of IT, whose decision is final.
Reason: Any device used for business purposes must be secure. The IT department is responsible for securing all IT devices but cannot provide that service on the plethora of possible devices. Thus in most cases staff will use equipment issued by the organisation.’
- Glossary
Don’t try to re-write terms, search the internet as models will exist for most terms.
- References
No Policy exists in isolation, it needs to be related to other policies within the organisation or other formal documents, e.g. terms & conditions of employment. Writing policies from scratch is hard work so show what you used to get started. This makes updates easier, & it may happen that someone else will have to update your work – be nice & give them a chance! It also makes for a professional looking document as it shows that you have consulted the appropriate authorities (i.e. you’ve done your homework). If your policy is ever challenged, e.g. in a disciplinary hearing, then just like an exam question it helps to be able to show your working.
Include URLs if possible,
Internal – in-house policies
External – legislation, guidance, regulations etc.
Remember
This has to be readable & accessible – policies generally apply to all your staff. 50 pages of jargon will make a good door stop.
For every action stated in the policy, someone has to do it! Say who, & who will take an interest in them doing it (i.e. receive a report of some sort).
Reporting lines should be stated, defining a committee without saying who it reports to leaves it with no authority/ leverage.
This is policy, not strategy or tactics. Policy is fairly static (keep patient data safe), strategy is more fluid (train staff, use passwords, etc.) & tactics even more fluid (how will you train, rules for password complexity). This level of detail may be justified if you want the force of the policy to be explicit. e.g.
Policy: Keep patient data safe.
Strategy: All line managers are responsible for briefing new staff on controls in their area, & providing annual refreshers.
There will be exceptions, e.g. you may want staff to comply with a specific tactic (e.g. wear Id badges at all times), how this follows from policy should be clear so that if any aspect changes then the document is easier to update.
Do
Avoid just writing up what you have in place at the moment. That will be a useful exercise but it’s not policy.
Use a pre-existing framework that someone has already created. What you are writing about is unlikely to be novel. The chances are good that someone has published something you can use. But don’t follow it like a sheep. Think and if it doesn’t match your way or working then change it.
Make strong simple statements, it is easier to relax them for special situations than to write a complex piece of text catering for all eventualities. State who has the authority to allow exceptions.
Use section numbers & have a contents page, this aids accessibility.
Use footers – document title, publication date, page numbers.
Have a block showing the author & sign-off authority.
Don’t
Quote (large) blocks of readily available guidance, legislation etc. unless you are to map the policy to each part (e.g. the 8 principles of the Data Protection Act (1998) would be listed with text to show how the organisation complies with each one). This is policy, not a training document. If you want to train your staff on legislation or guidance then do that in another document, or in a training session. Keeping these functions clear makes it easier to update the separate documents.
Confuse your policy with SOP or with Good Practice Guidelines (GPG). Doing so will result in an unwieldy document trying to satisfy a mix of audiences & confusion over who can approve the content.
After the Policy
Write your in-house guidance so staff can see how to implement the policy.
These may be annexes to the policy – so they are immediately linked to the policy, & can be changed without changing the policy as such. SOPs may be placed in the annexes.
A. G. Capey
IG Smart Ltd
Andrew Capey BSc, MSc is a highly experienced data analytics, quality and security specialist. Andrew has written countless policies over the years, and is happy to share the lessons learned with you.
Call Andrew now on 0203 8242426 for advice and support with your information and technology management policy drafting and implementation.
Leave a Reply