In a pre-certification assessment, missing documentation would probably be flagged as a minor nonconformity, but addressing it can take some serious effort.
A noticeable benefit of the recent review, Data Handling Procedures in Government, has been the number of smaller companies that are starting to align their security practices with ISO/IEC 27001:2005, the ISO standard defining a code of practice for maintaining effective information security.
The reason for this is that companies now must be able to demonstrate that they meet government data-handling guidelines when tendering for or fulfilling government contracts. Some are actually going for full certification, while for others, being compliant with the ISO standards is seen as good enough.
The key clauses in ISO/IEC 27001:2005, which usually require changes or improvements to be made by companies looking to be compliant are: Clause 4: Information security management system (ISMS); Clause 5: Management responsibility; Clause 6: Internal ISMS audits; Clause 7: Management review of the ISMS.
I've recently been helping various companies bring their ISMSes into line with the requirements of ISO/IEC 27001:2005, and the area where most of them fall short is clause 4.3: Documentation requirements . This clause states that documentation must include written descriptions of information security processes and activities, controls documentation, risk assessment methods and reports, a risk treatment plan and a Statement of Applicability detailing the information security control objectives and controls that are relevant and applicable to the ISMS.
There tends to be either a lack of documentation for policies and processes or a lack of organised documentation. A documented procedure means that the procedure itself is established, documented, implemented and maintained.
In a pre-certification assessment, missing documentation would probably be flagged as a minor nonconformity, but addressing it can take some serious effort. For example, if there's no formally, properly documented business continuity plan, creating one can be a major piece of work. Even a missing documented procedure for information security incident reporting and management will take time and effort to create, agree upon with business managers and implement.
But it will be a wasted opportunity if you just set about creating the required collection of documents in order to tick them off your to-do list without giving proper consideration to their role in the overall security program. Depending on how these are created and used, they have the potential to greatly improve and strengthen security throughout an organisation.
Statement of Applicability
The most common document I find to be missing is the one that records why specific decisions regarding security have been made, and which security controls are being used and why; it's called the ISO 27001 Statement of Applicability (SoA).
ISO 27001 SoA identifies the security controls that have been established within your environment and explains how and why they are appropriate. It demonstrates the relationship among the results of the risk assessment, the selected controls and the original risks they are intended to mitigate, as well as the ISMS policy and objectives.
This is a key information security policy document as it brings together both how and why your security works. A good SoA shows how security controls combine to provide layers of defence and are not just isolated obstructions to everyday tasks.
Security training that includes references back to the Statement of Applicability is effective, as employees begin to see how security in their organisation works and the rationale behind what, at first, may seem like tedious and unnecessary controls. By showing how different policies and procedures relate to security objectives, the reasons behind these requirements become a lot clearer. And when people understand why they need to do something, they are far more likely to do it.
For example, the security objective of a small firm I recently worked with was to ensure its system, which handles government data, was protected from malware and unauthorised access. Involving staff in the development of acceptable-usage policies for network services such as the Internet and email is generally a wise idea, so I set up a meeting, open to everyone, to formulate a policy that would keep the staff happy and yet achieve the firm's security objective.
Everyone appreciated the importance of the government contract, so when I showed them the results of my risk assessment, they themselves started to suggest ways to mitigate the highlighted risks. With some guidance we quickly reached a consensus on the changes that needed to be made to the network infrastructure, the security controls and, most importantly, working practices.
By ensuring their needs were met or explaining why they couldn't be met and providing an acceptable compromise, the resultant policy and working practices were ones that everyone understood, agreed with, and have since rigorously defended and enforced, largely because they felt a real sense of ownership over the policy.
Maintaining information security policy documentation
The amount of information security policy documentation within an ISMS can vary greatly from one organisation to another, depending on the company's size and the nature of its activities, as these affect the scope and complexity of the security requirements and the systems being managed. However, even a small organisation will end up with a meaty set of documents. This is why it's so important to cross-reference relevant security objectives, decisions and controls so everyone can easily check back as to the purpose of a policy or procedure and its place in the organisation's overall security.
Documents required by the ISMS need to be protected and controlled themselves by a documented procedure that defines the management actions needed to approve, review and update documents, and ensure they're available to those who need them. Reviewing and updating ISMS documents is part of the continuous, systematic review and improvement required by ISO/IEC 27001:2005.
Unless you follow ISO/IEC 27001:2005 quite closely, it's surprising how quickly a disconnect can develop between an organisation's long-term business objectives and its IT security strategy, particularly during a period of change.
Changes and promotions amongst senior managers, or the start of a new service can quickly alter key business drivers. New reporting lines may blur risk ownership and accountability. Whenever there is a change within an organisation, it is essential that information security strategy and policies are reviewed to ensure they focus on delivering the type of security the organisation needs, support the technologies that will provide maximum business benefit and help the organisation deliver its goals.
To avoid having your organisation's security strategy become misaligned, the head of IT security should regularly engage with senior management to discover and discuss areas of concern. By ensuring all stakeholders are made aware of both business and security imperatives, more informed choices can be made when it comes to purchasing and implementing security technologies, and policies and procedures can be kept up to date to reflect the needs of the business and its security objectives.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.