CHAPTER 3: ISMS INITIATION

The first concrete steps in initiating the information security management system (ISMS) are to determine which continual improvement methodology to use and to put a document structure in place.

Continual improvement

ISO 27001 recognizes 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 organizations 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 organization’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 the organization selects, 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 RCA 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 assumptions are questioned and the real root cause of a problem is identified so it can be addressed.

Security improvement plan

I earlier identified that the ISO 27001 project could take the form of a security improvement plan, using a gap analysis as the starting point. Clearly, if this is the route you take, you will want to determine your continual improvement methodology early and ensure you report progress through your continual improvement log.

Expanding the RACI matrix

At this stage, you will also want to expand the RACI matrix by identifying who is formally accountable for the most important roles in the ISMS at the outset.

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 must be deployed in your ISMS, and your Statement of Applicability (SoA) identifies the controls you deploy 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 must be documented as a point of reference; as the basis for ensuring there is consistent application over time; and to enable continual improvement.

Documentation will be the most time-consuming part of the total project; therefore, how you address this aspect will be a major determinant of your overall success. Documentation must be complete, comprehensive, in line with the requirements of the Standard, and should fit your organization 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 the organization needs to meet the Standard’s requirement to maintain sufficient records to demonstrate compliance.

The key qualities of the ISMS documentation are it should be adequate, but not excessive, and 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 SoA 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 likely be one for each of the implemented controls) would be part of the policy manual that 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 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 the current version of any procedure is immediately available hassle-free to all members of staff. A structured numbering system should be adopted that ensures ease of navigation of the documentation, controlled document issue, tracking of replacement pages and changes, and completeness of documentation. 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 subject to security measures. These will include documents such as the risk assessment, the Risk Treatment Plan and the SoA, which contain important insights into how security is managed and should therefore be classified, restricted, and treated in accordance with the organization’s information classification system. Access should be limited to people with specified ISMS roles, such as the information security adviser.

Four levels of documentation

ISO 27001 clearly recognizes there is no such thing as a ‘one size fits all’ approach to documentation. Instead, it recommends the extent of the ISMS documentation should reflect the complexity of the organization 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 approved corporate policy, which drives all other aspects of the ISMS. A number of additional, subject-specific policies support this high-level policy (for instance, setting out 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 to perform each of the identified tasks.
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 are 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 organization that meets the criteria described earlier in this book, the length of time the project will require depends very much on the methodology adopted.

Trial and error

The first is a methodology known as ‘trial and error.’ 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 organization continues to fail 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 organizational learning, and overcoming resource deficiencies.

Third-party documentation toolkit plus guidance

While this approach is most appropriate for organizations that prefer to tackle internal change projects largely without external consultant support, it is an approach the success of which depends 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 right from the start.

It is essential any documentation toolkit is designed to meet the detailed requirements of the Standard, and 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 was developed specifically for organizations that want to avoid the costs and disadvantages of learning by trial and error. These toolkits are also specifically designed so they can easily be integrated into additional management systems, ensuring 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 checking out this toolkit as part of your preparatory research into how you will deal with the documentation part of your project.

Third-party documentation

As part of the documentation processes, controls should also be introduced for documents of external origin, including managing their retention periods.