Dejan Kosutic Very often I see questions on various forums on how to develop an Information Security Policy. Quite frankly, I don’t think it is a good idea to stuff all the security rules into a single document, and here’s why…
Information security policy vs. ISMS Policy
First of all, let’s clarify the difference between these two documents: ISO 27001 2005 revision in its clause 4.2.1 b) requires ISMS Policy to be a high-level policy, with its purpose being for management to define how it will control the ISMS – e.g. how to set security objectives, how to fit information risk management with overall risk management, compliance requirements, etc. (Click here to read more about the content of ISMS Policy.)
On the other hand, Information security policy is mentioned in control A.5.1.1 of Annex A, and it can describe any security rule like passwords, backup, anti-virus, network security, etc.
So, the point is that ISMS Policy is aimed mainly at top-level managers (for their understanding of what information security needs to achieve and how to control it), and Information security policy should be used by almost every employee (with the main purpose of making sure their day-to-day activities comply with security rules).
Update 2013-09-25: New ISO 27001 2013 revision calls this high-level policy an “Information security policy” instead of the ISMS Policy. Therefore, there is no need to make a difference between these two policies any more.
Information security policies – how many?
In reality, the following options exist when you start the ISMS implementation:
a) Merge all information security policies into a single document, or
b) Write top-level Information security policy and Operational information security policy separately, and such Operational information security policy covers most of the controls (safeguards) from Annex A, or
c) There is a separate Information security policy, and different areas from Annex A are covered through different documents – e.g. Access Control Policy, Classification Policy, Backup Policy, etc. (In this case, there is no need for Information Security Policy).
I think option c is probably the best – in most cases it is not feasible to put all the security rules in one single policy, because this would result in an excessively large and unreadable document. Very often these documents are 20 pages or longer, and as could be expected, no one wants to read such an extensive document, let alone comply with it.
The best practice is to divide those security rules into several policies like Access Control Policy, Classification Policy, Backup Policy, Acceptable Use Policy, etc. – this way such policies will be shorter (and therefore easier to read and understand), and easier to maintain (e.g. system administrator will be responsible for Backup Policy, while security manager will be responsible for Classification Policy).
There are exceptions, of course – for example, if you are a very small company (fewer than 10 employees), you will tend to decrease the number of documents. In such case, it may make sense to go for options a or b.
But, whichever option you choose, here’s the most important thing – you have to figure out what is best for you, what is suited for the particular circumstances of your company. Don’t expect to use a template your colleague has sent you just because it works fine for his company – you have to develop your own documentation and make it work for you.
Click here to download a free Checklist of ISO 27001 Mandatory Documentation.
