CHAPTER 2: THE ISO27001 IMPLEMENTATION PROJECT

The successful design, development and implementation of an ISMS in line with the requirements of ISO27001 is a significant project. There are a number of important aspects to such a project, all of which are developed in detail in IT Governance: An International Guide to ISO27001/ISO27002. A project team will need to be set up and it will need the full support of management.

PDCA/Management methods

Previously, ISO27001 mandated the use of the Plan-Do-Check-Act (PDCA) model to create a compliant ISMS. The 2013 update, however, allows for the use of either PDCA or comparable continual improvement management methods such as ITIL^® or COBIT^® 5. Under the PDCA model, an organisation ‘Plans’ what it is going to do, carries out those plans, i.e. ‘Do’ it, ‘Checks’ that what they have done has achieved the desired objective, and then ‘Acts’ on any shortfall. For ISO27001, that would put the following tasks in each of the P-D-C-A stages:

• Plan (establish the ISMS): establish the scope, security policy, targets, processes and procedures relevant to assessing risk and carry out risk assessment in order to improve information security so that it delivers results in accordance with the organisation’s overall policies and objectives.
• Do (implement and operate the ISMS): implement and operate the security policy, and the controls that were chosen as a result of the risk assessment process, as well as the processes and procedures of the ISMS.
• Check (monitor and review the ISMS): assess and, where applicable, measure process performance against security policy, objectives and practical experience, and report the results to management for review. This will include measuring the effectiveness of the management system and the controls that it implements.
• Act (maintain and improve the ISMS): take corrective and preventive actions, based on the results of the management review, to achieve continual improvement of the ISMS.

Once the ‘Act’ stage is completed, the organisation then starts over again, planning what to do to improve the ISMS. Thus, an organisation which has embarked on a project using PDCA is in a continuum, with the aim of this cyclic experience being to identify and manage risks, and drive continual improvement.

Project team

An ISMS project will need an appropriately structured and resourced project team. This is common sense; it also reflects the requirements of Clause 5 of ISO/IEC 27001.

Demonstrating management commitment

Clause 5.1 of ISO27001 requires management to “demonstrate leadership and commitment with respect to the information security management system”, and goes on to list the specific steps that will provide that evidence:

• Establishing the ISMS policy and information security objectives, which should be compatible with the organisation’s strategic direction.
• Ensuring that the ISMS is integrated into the organisation’s processes.
• Ensuring that the resources necessary for the ISMS are available.
• Communicating the importance of information security management to the organisation
• Ensuring that the ISMS achieves its intended outcomes, in accordance with the information security policy and objectives.
• Directing and supporting persons to contribute to the effectiveness of the information security management system.
• Promoting continual improvement of the ISMS.
• Supporting management roles in demonstrating leadership in information security.

Project team/steering committee

Top management should create the business-led project team mentioned earlier and/or a steering committee to design and implement the ISMS. This team should be led by a senior manager with general business responsibility, ideally the CEO. Experience teaches that this team should not be led by an IT manager, as IT managers tend not to have sufficient cross-business and general management experience and credibility to create and implement a management system that has to work across the business as a whole.

The project team, led by a general manager, should include key functional managers as well as IT and information security technical expertise. Where the resources are not available in-house, this technical expertise should be externally contracted; where an external contractor is used, the various control requirements related to third-party contracts, such as A13.2.4, Confidentiality or non-disclosure agreements, and A15.1, Information security in supplier relationships, should be applied.

This team can also be given the task of the detailed allocation of information security responsibilities that is envisaged by A.6.1.1, Information security roles and responsibilities.

Project initiation

The preparatory phase of an ISMS implementation should involve at least the following four stages:

• Awareness – developing an understanding, amongst the board, senior management and key functional managers, of why an information security management system is required and, broadly, what is likely to be involved.
• Learning – developing, in greater depth, the skills and knowledge of those likely to be in the project team and more directly involved in the project itself.
• Scoping – determining what will be within the scope of the ISMS and what will be outside it.
• Policy formulation – developing and agreeing the information security policy for the organisation. This policy sets the direction for the ISMS within the context of the business objectives.

Awareness

Deploying an ISMS is a business project, not a technical or IT one.

Unless the ISMS project has the active support of the board, top management and those senior managers (business and functional) whose influence in the business is critical to the success of any project, it will fail.

ISO27001, in Clause 5, also explicitly requires that management “demonstrate commitment with respect to the information security management system”. In the light of this, and of the explicit control and continuous improvement requirements described in the Standard, any organisation that is developing and implementing an ISMS will make the full involvement of top management a priority. Clause 5 of the Standard supports the argument that, without top management support, the organisation simply will not be able to implement a useful ISMS, let alone achieve accredited certification.

Awareness tools

The most common methods of developing awareness are:

• circulation of copies of relevant books⁷ to all who are likely to be involved;
• presentations and workshops, by internal or external experts, on the Standard and on the implementation requirements;
• use of e-learning or other internal communication and training tools;
• large-scale staff presentations and training workshops.

It is important that all awareness-building exercises focus on the specific benefits the organisation intends to derive from the implementation of an ISMS, and on the specific threats and risks faced by the organisation, as this helps build understanding and commitment from all those staff members involved in the process.

Documentation requirements and record control

When implementing an ISMS, organisations are attempting to institutionalise some of the knowledge and behaviour that are required for the management of their information security in a way that will be both repeatable and secure against the possibility that critical knowledge might be lost when an individual leaves the organisation. Repeatable processes are more consistent, and more predictable. Every management system depends for its effectiveness on proper documentation of its processes and the retention of records that demonstrate compliance or non-conformance with the system.

As part of its longer-term programme of continuous improvement, organisations should look to capability maturity models⁸ to provide them with guidance on how they can strengthen and improve the processes that make up their ISMS.

Control A.12.1.1 explicitly requires security procedures to be documented, maintained and made available to all users who need them. A compliant ISMS will be fully documented. However, not every organisation has to implement an equally complex documentation structure:

The extent of the ISMS documentation can differ from one organization to another due to: the size of organization and its type of activities, processes, products and services; the complexity of processes and their interactions; and the competence of persons.⁹

ISO27001 document control requirements

Clause 7.5.3 of ISO27001 deals with the control requirements of documentation for the ISMS. This means that they must:

• be available and suitable for use;
• be adequately protected.

• How the information will be distributed, accessed, retrieved and used.
• How the information is to be stored and preserved, including preserving legibility.
• How changes are controlled.
• Rules governing how the information is retained and disposed of.
• Information of external origin must be appropriately identified and controlled.

Annex A document controls

There are document-related controls in Annex A that should also be included in the document control aspects of the ISMS. They are all important controls in their own right; they are:

• A.8.2.1 Classification of information, which deals with confidentiality levels, and which means that every document should be marked with its confidentiality classification.
• A.8.2.2 Labelling of information, which deals with how confidentiality levels are marked on information and information media.
• A.8.2.3 Handling of assets, which covers how confidentiality labels translate into handling procedures.
• A.18.1.4 Privacy and protection of personally identifiable information, which may affect who is entitled to see what information.

Document approval

The issue of controlled documents must be approved as adequate, as will any revisions. Approval must be from an appropriate level of authority and should represent the ISO27001 control for segregation of duties (A.6.1.2): the person who drafts a document should not be responsible for the final approval before its release. Practically, one has to allow for revision and improvement to documents; those that are most detailed are prone to change most frequently as process improvements are identified. It makes sense for those documents that are likely to be frequently revised to be approved at the lowest possible level within the organisation.

The way to do this is to create a tiered document structure, in which those documents that undergo only infrequent change are subject to the most senior level of approval, while those likely to change frequently are subject to a much lower level of sign-off.

Policies, which set general direction and requirements, should not need to change frequently, and should be subject to board (or other top management) approval. Procedures, which implement policy, are likely to change from time to time, and should be subject to middle management approval (by the person ultimately responsible for the department or process to which the procedure applies). Work instructions, which set out the detailed, step-by-step requirements for carrying out specific functions, should be subject to approval by the person to whom the relevant asset owner reports.

Contents of the ISMS documentation

Documentation has to be complete, comprehensive, in line with the requirements of the Standard and tailored to suit the needs of individual organisations. ISO27001 describes (in Clause 7.5) the minimum documentation that should be included in the ISMS to meet the requirement to document compliance with the Standard. These documents include the following:

• The information security policy, the scope statement for the ISMS, the risk assessment methodology and output of the risk assessment exercise, the various control objectives and procedures that support the ISMS, and the statement of applicability. Together, these form the ISMS manual.
• Evidence of the actions undertaken by the organisation and its management to specify the scope of the ISMS (the minutes of board and steering committee meetings, as well as any specialist reports). The Standard requires that there should be records of management decisions, that all actions should be traceable to these decisions and policies, and that any results that have been recorded should be reproducible.
• A description of the management framework (roles and responsibilities, etc.). This could usefully be related to an organisational structure chart.
• The risk treatment plan and the underpinning documented procedures (which should include responsibilities and required actions) that implement each of the specified controls. A procedure describes who has to do what, under what conditions, or by when, and how. The Standard also requires that the relationship between the selected control, the results of the risk assessment and the risk treatment process, and the ISMS policy and objectives, should all be demonstrable.
• The procedures (which should include responsibilities and required actions) that govern the management and review of the ISMS.

Record control

The organisation will need to retain records that track the effectiveness of the ISMS for the purposes of internal audits and management reviews (as required in Clauses 9.1 – 9.3). These are not the same as the records that the organisation has to keep in the ordinary course of its business, which will be subject to a variety of legislative and regulatory retention periods (which should be specifically related to control A.18.1.3, Protection of records). Records that provide evidence of the effectiveness of the ISMS are of a different nature from those records that the ISMS exists to protect but, nevertheless, these records must, themselves, be controlled and must remain legible, readily identifiable and retrievable. This means that, particularly for electronic records, a means of accessing them must be retained even after hardware and software have been upgraded.

Documentation process and toolkits

The creation of the ISMS documentation is a key part of the process. It contains all of the policies, procedures and records that set out how the ISMS should work and that record the evidence that it has worked. Organisations have two options for approaching this, the most time-consuming part of the implementation:

1. Design the documentation in-house.
2. Purchase a ready-made documentation toolkit, which contains pre-written templates that can be adapted by each organisation to the needs of its own particular ISMS.