While risk assessment is the core competence of information security, it is the information security policy and the agreed scope of the ISMS that provide the organisational context within which that risk assessment takes place. The first step in the planning phase for the establishment of an ISMS is the definition of the information security policy. A risk assessment can only be carried out once an information security policy exists to provide context and direction for the risk assessment activity.
This requirement is set out in clause 4.2.1 of ISO2700137 (and control A.5.1, in Annex A to ISO27001). It is not always, however, as straightforward as it seems. It may be an iterative process (particularly in complex organisations dealing with complex information security issues and/or multiple domains) and the final form of security policy that is adopted may, therefore, have to reflect the final risk assessment that has been carried out and the Statement of Applicability which emerges from that.
Clause 4.2.1 sets out clearly the components of the ISMS policy. Its scope, and the policy itself, must take into account the characteristics of the business, its organisation, location, assets and technology. The policy must include a framework for setting its objectives and establish the overall sense of direction. It must take into account all relevant business, legal, regulatory and contractual security requirements. It must establish the strategic context (for the organisation and for its approach to risk management) within which the ISMS will be established. It must establish criteria for the evaluation of risk, for the structure of the risk assessment, and for risk treatment decisions. It must be formally approved by senior management.
A statement that the board and management ‘are committed to preserving the confidentiality, integrity and availability of information’ will be at the heart of a security policy and an ISMS. It is important to define precisely the key terms used in the policy and we recommend that the definitions contained in ISO27001 and, where necessary, in ISO27002 are used. The introduction to ISO27002 defines information very widely:
Information [can be] printed or written on paper, stored electronically, transmitted by post or using electronic means, shown on films, [or] spoken in conversation.
In other words, appropriate protection is required for all forms of information.
Confidentiality [is defined in clause 3.1 of the standard as] ensuring that information is accessible only to those authorized to have access.
Integrity [is defined as] safeguarding the accuracy and completeness of information and processing methods by protecting against unauthorized modification.
Availability [is defined as] ensuring that authorized users have access to information and associated assets when required.
Availability is particularly important to businesses engaged in e-commerce. A business that depends for its very existence on the availability of its website, but which fails to take adequate steps to ensure that the site is up, running and running properly at all times, is likely to fail as a business much more quickly than a traditional bricks and mortar business that is unable to open its shop doors for a few days.
The board, management team and staff of the organisation should all understand that these are the definitions of these words and they should be prominently set out in the early briefings to staff and in internal communications. Auditors from certification bodies are likely to check (probably randomly) that staff understand what these words mean and, while they will not look for staff to remember verbatim these definitions, will want staff to demonstrate a practical understanding of how the pursuit of these aspects of information security is likely to impact their own work. This level of understanding is required, as a minimum, so that each member of staff is able to recognise and react appropriately to a security incident.
The organisation will also need to define which physical and intellectual assets are to be covered by the policy. The kinds of technology employed and the basis on which the organisation operates will also strongly influence the scope of the ISMS.
The information security policy will also have to be regularly reviewed and updated in the light of changing circumstances, environment and experience. As a minimum, if there is no earlier reason for the board to review its policy, it should be reviewed annually and the board should agree that the policy remains appropriate (or otherwise) to its needs in the light of any changes to the business context, the risk assessment criteria or in the identified risks. There may be components of the policy that ought to be reviewed very regularly, even monthly, and these should be identified through the risk assessment.
Initially, the information security policy is a short statement (we think organisations should aim for a maximum of two pages of A4) that is designed to set out clearly the strategic aims and control objectives that will guide the development of the ISMS. The policy may go through a number of stages of development, particularly in the light of the risk assessment, but the final version must satisfy clause 4.2.1 – and Annex A control 5.1.1 – of ISO27001, as well as appropriately reflecting the good practice that is set out in clause 5 of ISO27002. The guidance in the introduction to ISO27002 should also have been read and taken into account.38 Proof that the policy has been approved by management, published and communicated internally, and that it is reviewed regularly (usually annually, as a minimum), with any changes similarly published and communicated, will enable the organisation to fully satisfy control A.5.1 of the standard (Security Policy).
A copy of that section of the minutes (preferably initialled by the chairman as a correct copy) of the board meeting, in which the information security policy was debated and adopted, should be filed with the security policy documentation. It can be a controlled document and it does, for audit purposes, provide useful and immediate evidence of the process by which the policy was adopted, and of any amendments to it. This, together with the proposal that was put to the board, is the first part of the evidence that clause 4.3 (Documentation Requirements) of the standard requires to demonstrate that the actions set out in clause 4.2 did take place.
The policy itself should then be issued as a controlled document and made available to all who fall within its scope; as a minimum, members of the senior management team should receive individual copies and copies should be posted on all internal noticeboards, both the physical and electronic ones. These copies of the policy document should, of course, be clearly marked as controlled copies, to ensure that they are updated to reflect any changes that take place. Copies handed out, as part of training or awareness seminars, should be marked as uncontrolled copies.
Those parts of the organisation, and possibly beyond, to which the policy is going to apply, need to be clearly identified. This may be done in part on the basis of corporate, divisional or management structure, or on the basis of geographic location. The other aspect of scope that needs to be considered is the logical boundary. A virtual organisation, or a dispersed, multi-site operation, may have different security issues from one located on a single site. In practical terms, a security policy that encompasses all of the activities within a specific entity, for which a specific board of directors or management team is responsible, is more easily implemented than one that is to be applied to only part of the entity. It is important to ensure that the board of directors that is implementing the policy does actually have adequate control over the operations specified within the policy and that it will be able to give a clear mandate to its management team to implement it.
It is essential to decide the boundary within which the ISMS is to provide assurance. The business environment and the Internet are each so huge and diverse that it is necessary to draw a boundary between what is within the organisation and what is without. In simple terms, boundaries are physically or logically identifiable. Boundaries have to be identified in terms of the organisation, or part of the organisation, that is to be protected, which networks and which data, and at which geographic locations.
The key components of defining the scope of the ISMS are:
• identifying the boundaries or perimeters (physical and logical) of what is to be protected;
• identifying all the systems necessary for the reception, storage, manipulation and transmission of information or data within those boundaries and the information assets within those systems;
• identifying the relationships between these systems, the information assets and the organisational objectives and tasks;
• identifying the systems and information assets that are critical to the achievement of these organisational objectives and tasks and, if possible, ranking them in order of priority.
Clause A.7.1 is the ISO27001 Annex A control that deals with the asset inventory and the guidance of clause 7.1 of ISO27002:2005 should be taken at this point. It identifies clearly the classes or types of information asset that should be considered, and recommends that the information security classification of the asset be determined at this time – which would be sensible, given the requirement of control A.7.2 for information to be appropriately classified.
The first step, therefore, is to identify which organisational entity is within the scope of the ISMS. The entity that is within the scope must be capable of physical and/or logical separation from third parties and from other organisations within a larger group. While this does not exclude third party contractors, it does make it practically very difficult (although not necessarily impossible) to put an ISMS in place within an organisation that shares significant network and/or information assets or geographic locations. A division of a larger organisation that, for instance, shares a group head office and head office functions with other divisions, could not practically implement a meaningful ISMS.
Usually, the smallest organisational entity that is capable of implementing an ISMS is one that is self-contained. It will have its own board of directors or management team, its own functional support, its own premises and its own IT network.
The information that should be collected (following NIST SP 800-30, clause 3.1.1), in order to clarify what will – and what won’t – be within the scope of the ISMS, will relate to:
• hardware;
• software;
• system interfaces (e.g. internal and external connectivity);
• data and information;
• persons who support and use the IT systems;
• system mission (i.e. the processes performed by the systems);
• system and data criticality (e.g. the system’s value or importance to the organisation);
• system and data sensitivity;
• functional requirements of the IT system;
• users of the system (e.g. system users who provide technical support to the IT system, application users who use the IT system to perform business functions);
• system security policies governing the IT system;
• system security architecture;
• current network topology (e.g. network diagram);
• information storage protection;
• flow of information pertaining to the IT system (e.g. system interfaces, system input and output flow charts);
• technical controls used in the IT system;
• management controls used in the IT system;
• operational controls used in the IT system;
• physical security environment of the IT system;
• environmental security implemented for the IT system.
Information gathered about some or all of these issues will help clarify what should be in the scope of the ISMS.
It is possible for divisions of larger organisations to independently pursue certification. The critical factor is the extent to which they can be practically differentiated from other divisions of the same parent organisation, and can exercise practical control over their information assets and over the implementation of controls which their risk assessment determines are necessary to protect those assets.
For larger organisations, with a multiplicity of systems and extensive geographic spread, it is as a general rule often simpler to tackle ISO27001 and, in particular, risk assessment, on the basis of smaller business units that meet the general description set out above. On the other hand, larger organisations that have a single business culture and largely common systems throughout are probably better off creating a single ISMS.
Once the organisational scope is identified, it is necessary to list the physical premises that the chosen organisation occupies and to identify its network and information assets.
It is critical, if there are aspects of the organisation’s activities or systems that are to be excluded from the requirements of the security policy, that these are clearly identified – and explained – at this stage. Multi-site or virtual organisations will need to carefully consider the different security requirements of their different sites and their management implications. There should be clear boundaries (defined in terms of the characteristics of the organisation, its location, assets and technology) within which the security policy and ISMS will apply.
Any exclusions should be openly debated by the board and the steering group and the minutes should set out how and why the decision – for or against – was taken. It is possible that, in fact, divisions of the organisation, components of the information system or specific assets will not be able to be excluded from the scope, either because they are already so integral to it, or because their exclusion might have the effect of undermining the information security objectives themselves. It must, therefore, be clear that any exclusions do not, in any way, undermine the security of the organisation to be assessed.
Certification auditors will be assessing how management applies its information security policy across the whole of the organisation that is defined as being within the scope of the policy. They should be expected to test to their limits the boundaries of the stated scope to ensure that all interdependencies and points of weakness have been identified and adequately dealt with.
In reality, as stated earlier, the process of designing and implementing an effective ISMS may be made simpler by including, within the scope, the entire organisation for which the board has responsibility.
There is an argument, in large, complex organisations, for a phased approach to implementation. Where it really is possible to adequately define a subsidiary part of the organisation, such that its information security needs can be independently assessed, it may be possible to gain substantial experience in designing and implementing an ISMS, as well as a track record of success and the momentum that accompanies it, so that a subsequent roll-out to the rest of the organisation can be carried through successfully and smoothly. These considerations apply to any large, complex project and the appropriate answer depends very much on individual organisational circumstances.
It would certainly be a mistake to define the scope too narrowly. While it may appear, on the surface, that this is a route to a quick and easy certification, it is in fact, a route to a worthless certificate. Any external party, assessing the nature of an organisation’s ISMS, will want to be sure that all the critical functions that may affect its relationship are included and a limited scope will not do this. We are aware that some certification organisations are prepared to consider scopes that cover less than a complete business unit and, in our opinion, they are doing a disservice to their clients, as well as to the integrity of the ISO27001 scheme. Do not be tempted by such certification bodies to pursue an approach which is likely to be inadequate to your long term needs.
The other issue with regards to scope, and that directly relates to the risk management aspects of the project, as well as the project in general, is how it maps onto management responsibilities at the top level. The scope of the ISMS should be aligned with the boundaries of a single management team’s responsibility. This should be the management team that has authority to sign the information security policy and has responsibility for directing and managing the organisation that falls within the scope. This means that when it comes to deciding on the acceptable level of risk it is just one person, or group (e.g. board or management team) who decide, and this is demonstrated by one individual signing off the relevant documentation. Of course, it also helps with the smooth progress of the project in general when all those who will contribute fall within the remit of one, dedicated management team.
The overall issue of scoping is certainly one where experienced, professional support can be helpful in assessing the best way forward.
36 Much of this chapter replicates (but does not replace) content that is already in IT Governance: a Manager’s Guide to Data Security and ISO 27001/ISO 27002 (Kogan Page, 2007), as well as International IT Governance: an Executive Guide to ISO 27001/ISO 17799 (Kogan Page, 2006), and is repeated here to provide context for the further contents of this book. Readers are encouraged to read the original books for the full value of the contents of this chapter.
37 Readers who do not already have copies of both ISO/IEC 27001:2005 and ISO/IEC 27002:2005 should obtain their own copies and read them. The standards are the key documents against which an accredited certification is carried out. Copies of the standards (in either paper or downloadable format) can be obtained from national standards bodies and from the IT Governance online shop (at www.itgovernance.co.uk/standards.aspx).
38 The information security policy template that is contained within the ISO27001 ISMS Documentation Toolkit is drafted specifically to meet all these requirements and, like other top-level documents within the toolkit, needs minimal adaptation to meet the needs of individual organisations (see www.itgovernance.co.uk/free_trial.aspx).
3.14.134.188