The successful design, development and implementation of an ISMS that will be 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 International IT Governance: an Executive Guide to ISO27001/ISO17799. A project team will need to be set up and it will need the full support of management.
ISO27001 adopts the Plan-Do-Check-Act (PDCA) model that anyone familiar with other management system standards, such as ISO9001, will recognise. To implement an ISO27001-compliant ISMS, an organisation needs to ‘Plan’ what it is going to do, carry out those plans, i.e. ‘Do’ it, ‘Check’ that what they have done has achieved the desired objective, and then ‘Act’ on any shortfall. The ISO27001 specification puts 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 an ISO27001 project is in a P-D-C-A continuum, and the aim of this cyclic experience is to identify and manage risks, and drive continual improvement of the ISMS.
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/IEC27001 as well as complying with the requirements of controls A.6.1.1 through to A.6.1.3.
Clause 5.1 of ISO27001 (and control A.6.1.1) requires management to demonstrate its commitment to the ‘establishment, implementation, operation, monitoring, review, maintenance and improvement of the ISMS’ and goes on to list the specific steps that will provide that evidence:
establishing the ISMS policy, which should be formally debated and signed off by the board or top management team;
ensuring that ISMS objectives and plans are established, which is best done through the ISMS project team (see below);
establishing roles and responsibilities for information security, which should start with establishing the ISMS project team;
communicating the importance of information security to the organisation and providing ongoing support for the ISMS and its continual improvement;
providing sufficient resources for all stages and aspects of the ISMS development and deployment;
deciding the risk acceptance and control criteria, which should be done at a formal management meeting;
ensuring that the ISMS audits (as required under the ‘Check’ phase) are carried out;
conducting management reviews of the ISMS (also as required under the ‘Check’ phase).
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 A.6.1.5, Confidentiality Agreements, and A.6.2, External Parties, should be applied.
Control A.6.1.2 requires information security to be coordinated across the organisation by representatives from different parts of the organisation. In all but the largest organisations, this team should be the same team as the ISMS project team. This team can also be given the task of the detailed allocation of information security responsibilities that is envisaged by A.6.1.3, Allocation of Information Security Responsibilities.
The preparatory, pre-project 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.
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 ‘shall provide evidence of its commitment to the establishment, implementation, operation, monitoring, review, maintenance and improvement of the ISMS’. 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.
The most common methods of developing awareness are:
circulation of copies of relevant books[11] 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.
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[12] to provide them with guidance on how they can strengthen and improve the processes that make up their ISMS.
Control A. 10.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 organisation to another owing to the size of the organisation and the type of its activities and the scope and complexity of the security requirements and the system being managed.[13]
Clause 4.3.2 of ISO27001 deals with the documentation requirements for the ISMS. First, all documents need to be controlled. This means that they must:
be approved (or reviewed and re-approved) before use;
have a current revision and issue status (e.g. draft, final, and a version number);
have an issue date;
identify the document owner;
record the change history of the document;
be available at all points of use;
be legible, readily identifiable and stored or used in line with their classification (see below);
be withdrawn when obsolete;
be appropriately identified if their origin is external to the organisation.
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.7.2.1 Classification guidelines, which deal with confidentiality levels, and which mean that every document should be marked with its confidentiality classification;
A.7.2.2 Information labelling and handling, which deals with how confidentiality levels are marked on information and information media
A.15.1.4 Data protection and privacy of personal information, which may affect who is entitled to see what information.
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 requirement (A.10.1.3) for segregation of duties: 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 which 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.
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 4.3.1) the minimum documentation that should be included in the ISMS in order to meet the requirement that the organisation maintains sufficient records to demonstrate compliance with the requirements of the Standard. These documents include:
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 (project team/steering committee, 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.
Records have to be kept, as required by ISO27001 Clause 4.3.3, to provide evidence that the ISMS conforms to the requirements of the Standard. There 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.15.1.3, Protection of organisational 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.
The creation of the ISMS documentation is a key part of the process. It contains all the policies, procedures and records that set out how the ISMS should work and which record the evidence that it has worked. Organisations have two options about how they approach this, the most time-consuming part of the implementation:
Design the documentation in-house.
Purchase a ready-made documentation toolkit, one which contains pre-written templates that can be adapted by each organisation to the needs of its own particular ISMS.
The best toolkit available today is the Complete ISMS Documentation Toolkit, from www.itgovernance.co.uk; it comes in a number of versions, some including copies of the international standards, some also including an appropriate risk assessment tool.