It’s a new month and that means a new newsletter from CSP this September. This month Kevin and Clare both go over Information Security Policies, what they are for, how to create one and implement policies.
Kevin's Korner
Do we really need an Information Security Policy?
All companies try to formalise how things should be done, be it instructions on running a particular machine, or a sales process. But like most documents, they sit on a shelf and only get pulled out to either keep the new employee quite for a while, otherwise know as on the job training, or when an auditor comes around.
So, why on earth do you need an information security policy? Who’s going to read it? OK I’m being facetious, but often policies like this are created, filed, and forgotten.
An information security policy is the foundation of the security culture within your organisation, even if not everybody reads it. It sets the tone for all the other elements that come below it and for how your organisation approaches protecting its information. It defines the responsibilities within your company, who checks what accounts have been created, who ensures that the correct information is being sent to a customer, who handles a security incident etc.
One size does not fit all, but the basic elements of the policy are, responsibilities, methods of validation, how access is managed and how to report issues.
Responsibilities
Policies define the level of responsibility for security at each level of the business, from CEO to part-time office worker. Having that defined ensures that any other policies and procedures are targeted at the appropriate level. The CEO doesn’t need to know how to set an account up but does need to be sure it has been authorised.
Method of validation
The policy defines how you will measure security, who and how the checks and balances are performed. How do you report on who has access to the payroll, prospect list or latest design.
Access management
How are you going to make sure that only the design team have access to the latest design. Separate systems, or groups of users. It can define the physical segregation of your business operations, like limiting access to particular rooms or sections based on the information being held there.
How to report issues
A security issue isn’t just a data breach or a virus attacking part of your network. Any problem that weakens the security of your information needs to be reported, fully identified and corrected. So, having a procedure defined at the top level helps ensure that everyone within your organisation becomes a security monitor.
Policies are often seen as huge documents, which no one has the time to read and certainly time to fully understand, but a concise top-level policy really does set the scene for everything that comes below it. Yes, it’s more likely to be sat on a share or on your intranet site than on a shelf these days, but do you know the last time it was accessed? What if you haven’t got a report on who has accessed a specific file on your infrastructure?
Maybe you need a policy for that..
Clare's Tea Break
Steps for creating and implementing security policies
So, now we can discuss what the steps are for creation and implementation of security policies.
The task of writing an information security policy can be time consuming as there are many topics that often require bespoke documentation.
So, below are six steps to consider, that will help you save time when writing information security policies, at a broad level.
Step One – research documentation that already exists
Consider a paragraph insertion into documentation that already exists for the topic at hand.
For small organisations, the above method may work.
For medium to large organisations, a topic specific policy may be required which depends on the audience of the topic.
There is no one size fits all, adopt a flexible approach to each subject matter.
Step Two – identify who is the audience of the policy:
- If the policy audience is the whole organisation, use plain English.
- If the policy audience is a technical team, identify what the requirements are and break down into clear and actionable steps.
Step Three – use the active voice when writing policies
For example, in a training and awareness policy, you may consider asking people to: ‘report suspicious emails to a central location’. Staff are generally aware that they may receive bad emails. A sign post in the right direction will bring many more benefits such as: threat intelligence, and a positive security culture.
Pitfall statements to avoid writing: ‘Don’t click the link’, sometimes people are tempted to click on a link out of curiosity, and it may provoke extra reading and thought processes, about ‘what would happen if I did click on the link?’
Step Four – identify who needs to approve the policy
Once a policy is in draft, identify who needs to approve the policy.
If the policy is an amendment to existing documentation, make this clear in the document control or history log (this may speed up the approval process).
If the policy is new, and requires promotion and awareness to behavioural changes, create a communication plan to launch the new policy, and identify how exceptions to policy shall be accommodated.
Step Five – deposit policies in locations where people will read them
Consider locating:
- General security policies in an all-staff location.
- More technical policies in a location where technical staff are likely to read policies relevant to their subject matter.
Step Six – set a target date for a policy review
- Policies age, as technology changes. An annual policy review is often acceptable. Check to see if your organisation has a document control procedure, as it may state when policies require review.
So, to benefit your team and organisation, these above six steps will help you to plan multiple policy implementations and adapt when small changes are required to existing policies. Check out our Policy Reviews service for more info.