The first concrete steps in initiating the ISMS are to determine which continual improvement methodology to use and to put a document structure in place.
Continual improvement
ISO 27001 recognises that a ‘process approach’ is the most effective method for managing information security. The Standard is open to the deployment of any continual improvement approach and allows for organisations that already use, for instance, the ITIL® 7 Step Continual Service Improvement approach, the COBIT® Continual Improvement Life Cycle or any other approach that may be appropriate in the organisation’s context, to be certified. One of the most widely known and widely used approaches in the management system world is the ‘Plan-Do-Check-Act’ (PDCA) model, which will be familiar to quality and business managers everywhere.
Whichever continual improvement model is selected, it should be understood before work starts and should inform every step. It should have the idea of ‘root cause analysis’ (RCA) built or added into it; RCA contributes to identifying whether or not similar issues exist, or could potentially exist, elsewhere in the ISMS and this will enhance the effectiveness of the process – not only for nonconformities (as required by the Standard), but for all issues requiring correction and corrective action.
A common root cause analysis technique is the ‘5 Whys’. This is a technique for determining the root cause of a problem or defect by repeating the question ‘Why?’ five times. Each question forms the basis of the next question. While a sixth or seventh iteration might sometimes be necessary, the objective of the technique is to ensure that assumptions are questioned and that the real root cause of a problem is identified so that it can be addressed.
Security improvement plan
I earlier identified that the ISO 27001 project could be tackled as a security improvement plan, using a gap analysis as the starting point. Clearly, if this is the way you’re going, you need to determine your continual improvement methodology early and ensure that you report progress through your continual improvement log.
Expanding the RACI matrix
At this stage, you would also expand the RACI matrix by identifying who is initially to be formally accountable for the most important roles in the ISMS.
The roles that need to be identified are the owners of:
• Oversight of the establishment, implementation, operation, maintenance, and improvement of the ISMS;
• Continual improvement;
• Information security risk assessment; and
• Managing information security incidents.
Documentation
Your risk assessment process determines the controls that have to be deployed in your ISMS, and your Statement of Applicability identifies the controls that you are deploying in the light of your approach to risk management. Every one of those controls, together with your approach to identifying and managing risk, your management structure, your decision-making processes and every other component of your ISMS has to be documented; as a point of reference; as the basis for ensuring that there is consistent application over time; and to enable continual improvement.
Documentation will be the most time consuming part of the total project and, therefore, how you decide to tackle this aspect will be a major determinant of your overall success. Documentation has to be complete, comprehensive, in line with the requirements of the Standard and fit your organisation like a glove. A properly managed ISMS will be fully documented. ISO 27001 describes the minimum documentation that should be included in the ISMS, i.e. what is needed to meet the Standard’s requirement that the organisation maintain sufficient records to demonstrate compliance.
The key test of the ISMS documentation is that it should be adequate, but not excessive, and that it enables each of the processes to be “systematically communicated, understood, executed and effective so as to be repeatable and dependable”.
The documents include:
• The information security policy, the scope statement for the ISMS, the risk assessment, the various control objectives, the Statement of Applicability and the Risk Treatment Plan. The scope of the ISMS (the minutes of board and steering committee meetings endorsing this can also be helpful).
• The management framework documentation (see the next chapter).
• The underpinning, documented procedures (which should include responsibilities and required actions) that implement specific controls. A procedure describes who has to do what, under what conditions, or by when. These procedures (there would probably be one for each of the implemented controls) would be part of the policy manual which, itself, can be on paper or electronic.
• Documents that deal with how the ISMS is monitored, reviewed and continually improved, including measuring progress toward the information security objectives.
All formal documentation should be controlled and available to all staff who are entitled to view it. It can be published in paper form but is most effective on an intranet, a shared drive or SharePoint. A shared drive or SharePoint ensures that the current version of any procedure is immediately available to all members of staff without hassle. A structured numbering system should be adopted that ensures ease of navigation of the documentation, that document issue is controlled, that replacement pages and changes are tracked and that the documentation is complete. Staff should be trained in how to use the documentation and how to draft operations procedures for the assets and processes for which they are personally responsible.
Clearly, there will be a number of security system documents that need to be subject to security measures. These will include documents such as the risk assessment, the Risk Treatment Plan and the Statement of Applicability, which contain important insights into how security is managed and should therefore be classified, restricted and treated in accordance with the organisation’s information classification system. Access should be limited to people with specified ISMS roles, such as the information security adviser.
ISO 27001 clearly recognises that there is no such thing as a ‘one size fits all’ approach to documentation. Instead, it recommends that the extent of the ISMS documentation should reflect the complexity of the organisation and its security requirements. In practical terms, there are four levels of documentation in an ISMS, and each level has different characteristics, including about who is entitled to make decisions regarding revisions to the documents. The four levels are:
1. The board-approved corporate policy, which drives all other aspects of the ISMS. This high-level policy is supported by a number of additional, subject-specific policies (setting out, for instance, what constitutes acceptable use of the internet).
2. Detailed procedures, that describe who is responsible for doing what, when and in what order.
3. Operations/work instructions, that set out in detail precisely how each of the identified tasks are performed.
4. Records, which provide evidence as to what was done.
The amount of work increases as you descend the four levels, once, of course, those have been brought into line with the control requirements; the most demanding, in terms of time, is producing the third level – even though this is essentially the documentation of existing ways of carrying out specific activities.
Documentation approaches
There are three approaches to tackling the documentation requirements of the Standard, two traditional and one using a documentation toolkit. In an organisation that meets the criteria described earlier in this book, the length of time that the project will require will depend very much on the methodology adopted.
Trial and error
The first is a methodology known as ‘trial and error’ and, because those charged with deploying the ISMS first have to learn how to perform every single aspect of the task, it is the most time-consuming of the three, has a high risk of failure and extends the period during which the organisation continues failing to meet its information security objectives.
External expertise
The second, equally traditional, method is to bring in outside expertise in the form of experienced consultants to produce your documentation. It is a quicker approach than trial and error, but substantially more expensive. Its major advantages include considerably reducing project time, reducing the risk of failure, increasing the speed of organisational learning and overcoming resource deficiencies.
Third party documentation toolkit plus guidance
While this approach is most appropriate for organisations that prefer to tackle internal change projects largely without external consultant support, it is an approach that depends for its success as much on the quality and extent of senior management support and commitment as it does on the quality of the tools themselves.
The major advantages of this approach are that documentation toolkits:
• are fit for purpose – designed to meet ISO 27001 requirements from the outset;
• are fast to deploy;
• are very cost-effective (with low TCO and high ROI);
• generate substantial cost savings in comparison to traditional approaches;
• are full of best practice;
• will be cross-functional, company-wide, with a correct continual improvement cycle;
• create a very low likelihood of project failure;
• have continuous improvement built in from the start.
It is essential that any documentation toolkit be designed to meet the detailed requirements of the Standard, and that it comes with detailed guidance on how to tackle the project and all of the detailed drafting requirements. At IT Governance, we designed and built a documentation toolkit that exactly meets the requirements of the Standard, reflects multiple successful deployments of certifiable information security management systems and that was developed specifically for organisations that want to avoid the costs and disadvantages of learning by trial and error. These toolkits are also specifically designed so that they can easily be integrated into additional management systems, ensuring that the opportunity to build an integrated management system that meets multiple standards is available from the outset.
There is a free, trial version of this toolkit available for download through each of our websites. It is worth taking a look at this toolkit as part of your preparatory research into how you are going to tackle the documentation part of your project.
Third party documentation
As part of the documentation processes, one should also be introduced for control of documents of external origin, including their retention periods.