CHAPTER 4: MANAGEMENT FRAMEWORK

ISO 27001 is a specification for an information security management system. Unsurprisingly, therefore, it sets out requirements for a management framework. The fourth step in the ISMS implementation is to create this management framework.

Clause 4 of ISO 27001 says the organisation must identify the needs and expectations of interested parties, as well as the internal context of the organisation, and that these should be taken into account in establishing the scope of the ISMS.

You started to identify these requirements when creating your project risk register, so you should revisit this information and build on it. The external context will include the business and risk environment, what’s going on in your sector, and any other developments that might impact your information security stance. The internal context is the range of internal issues that will affect how you design and deploy the management system; the Standard is saying, in effect, that your ISMS must be designed for your business.

As part of this internal context, you will want to begin identifying the organisation’s risk appetite; this will be a significant issue in many aspects of implementation and I will return to it later in this book.

The requirements of interested parties are more complex. Interested parties can include regulators, partners and customers. The Payment Card Industry Data Security Standard (PCI DSS), for instance, is a commercial requirement imposed by an acquiring bank; data protection activities are imposed by law and policed by regulators. All organisations are faced with a multitude of such compliance requirements, each of which imposes a specific set of information security controls and brings important variations in requirements for preserving confidentiality, integrity and availability.

The IT Governance Compliance Database is a tool that was designed to make available, to UK organisations, the complete set of approximately 100 relevant laws and regulations, identifying the specific clauses that impose compliance requirements and allowing for the addition of multiple third party contracts that bring their own specific needs.

All these compliance requirements will need to feed into your ISMS, into your risk assessment and into your risk treatment documentation. Although the Standard does not require it, it is worth documenting all these aspects for ease of reference and of review in future.

As part of documenting the organisation’s context, it would make sense to review and (re)confirm the information security objectives that were initially documented in the PID and then further developed when initiating the project.

Scoping

Scoping is fundamentally important. Your management system scope will be stated on your compliance certificate. It will inform the audit as well as the external parties who are interested in your ISMS. It is key, both because you need to know the boundaries of what you are planning to implement, and because the Standard itself requires it.

One way of thinking about scoping is from the perspective of your information security policy.

Clause 5.2 of ISO 27001 sets out the requirements in respect of the ISMS policy clearly. The policy must be approved by the board. The policy must provide an overall sense of information security direction for the organisation as well as including information security objectives. It must include meeting information security requirements (which might be business, contractual or regulatory in nature) and it must also contain a commitment to continually improve the ISMS.

The ISMS policy applies across all parts of the organisation that are within the scope of the ISMS. As I’ve said, the scope must take into account the characteristics of the business, its organisation, location, assets and technology – what the Standard calls the “external and internal context” of the organisation. ISO 27001 refers, at this point, to ISO 31000, the international best practice Standard for organisational risk management. For those organisations seeking to properly integrate risk management across all aspects of the business, this ISO 31000 link will be important.

Your policy requirements should drive your approach to scoping the ISMS and the project. Scope determination is harder for larger, complex organisations than it is for smaller ones. Scoping is essential though for any size of organisation: you have to decide which information assets you’re going to protect and which ones you’re not before you can decide on appropriate protection.

This should be a quick decision for a small or medium-sized business: the whole organisation. That’s because there will probably be hard-wired connections between all the information systems and day-to-day working relationships within the business that make it either extremely difficult or impractical to try and segregate one part of the business from another. The notion of segregation is at the heart of effective scoping: ultimately, you are going to try and create an impregnable barrier between the part of your business that is within the scope of your project and everything else. You have to be categorical about what is inside your information fortress and what is outside, and this means that you don’t want any information systems, devices or business units that are both inside and outside – because that will be your weakest link.

ISO 27001 explicitly requires you to consider “interfaces and dependencies between activities performed by the organisation, and those that are performed by other organisations”; in other words, you must identify what is outside the scope of your ISMS, be prepared to justify its exclusion and manage the associated risks appropriately. This is to help you ensure that you don’t try to draw the boundaries too narrowly.

Endpoint security

In today’s business environment, your defensive barrier has to operate at the individual device level and is highly dependent on user compliance with business procedures. In other words, your scoping decision needs to include all the information devices that people use in their jobs – such as Smartphones, wireless laptops, home offices, etc. – as well as the more obvious central office systems such as accounting, payment processing, production, sales and order management, email, office automation, etc.

There may well also be cloud-based components that have to be taken into account.

In larger, more complex businesses, you will also want to ensure the entity that is within scope has a clearly defined legal and management structure and that there is alignment with the compliance requirements – part of the reason for your information security system is to ensure that you are compliant with the myriad of laws and regulations, so it makes sense for the entity that has those compliance obligations to be fully within the scope of your information security project.

In other words, those parts of the organisation to which your ISMS is going to apply need to be clearly identified. You should bear in mind that an ISMS is a management system, a formal structure that management deploys to ensure that its policy in information security is applied consistently throughout an organisation for which that management is accountable. Scoping of the ISMS may therefore be done on the basis of corporate, divisional or management structure, or on the basis of geographic location.

A virtual organisation, or a dispersed, multi-site operation, may have different security issues than one located on a single site. In practical terms, a security policy and ISMS 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 the board of directors that is implementing the policy does actually have adequate control over the organisation specified within the scope of the information security policy it will be expected to approve, and that it will be able to give a clear mandate to its management team to implement it within that entity. In other words, it is essential to decide the boundary within which protection is to be provided and ensure the team involved has the power to provide it.

Defining boundaries

The business environment and Internet are each so huge and diverse that it is necessary to draw a boundary between what is within the organisation and what is outside. 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 organisation 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 (though not necessarily impossible) to put an ISMS in place within an undifferentiated 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, or will have IT services supplied to it by a group or other supplier, subject to some form of service level agreement.

It is not unusual for divisions of larger organisations to independently pursue certification; the critical factor is the extent to which they can practically differentiate themselves and their business and information systems from other divisions of the same parent organisation.

For larger – usually highly decentralised – organisations that have a multiplicity of systems and cultures and an extensive geographic spread, it is often simpler as a general rule to tackle ISO 27001 and risk assessment on the basis of smaller business units that meet the general description set out above. Larger – more centralised – organisations that have a single business culture and largely common business and information systems throughout are probably better off creating a single ISMS.

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 the scoping stage. Multi-site or virtual organisations will need to carefully consider the different security requirements of their different sites and the management implications of them. 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 final scoping decision 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 that is implementing the ISMS.

For an ISMS certification, auditors are required to assess how management applies its information security policy across the whole of the organisation that is defined as being within the scope of the policy. You should expect them to test the boundaries of the stated scope to their limits 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 the entire organisation for which the board has responsibility.

Network mapping

It can help (but is not essential) to make a network map that shows how your central management and information systems link together and which identifies all of the points at which the outside world can interact with your network. This map will be very simple for a small organisation (because the network is simple) and far more complex for a larger, more complex organisation. The initial map that you draw to aid your initial scoping exercise will need to be extended as part of the detailed project planning phase to ensure that all aspects of your information systems have been identified. You do not need a detailed initial map; you just need to know how you will get from the initial one to the detailed one.

There is a range of network mapping software that will automatically map your network for you, some of which has additional helpful management features. The benefit of using such a tool is that it will quickly, completely and competently identify how your network is structured, what types of services are running and what access points and devices there actually are – and a status report of what is actually happening is much more useful than relying on a theoretical map.

Network maps are often drawn using software tools such as SmartDraw and Microsoft Visio, although you can start with a whiteboard and hand-draw a network diagram before attempting to model it with a software tool. Your network map will ultimately need to identify in detail all the devices (e.g. workstations 43, servers 6) that are connected to it, as well as their functions (e.g. print and file server, domain controller, etc.).

Cutting corners

All our experience teaches that it is a mistake to define the scope too narrowly. By ‘too narrowly’, I mean a scope that, for instance, includes only a head office, or only that bit of the organisation that is under pressure from third party (usually government) funders or customers to become certified. While it may appear, on the surface, that this is a route to a quick and easy certification, it is often in fact a route to a worthless certificate.

In the long run 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 ISO 27001 schemes. Do not be tempted to use such certification bodies.

In conclusion, I recognise that scoping the ISMS can be very difficult in large, complex organisations. It is certainly an area where experienced, professional support can be helpful in assessing the best way forward, although I would recommend only using consultants who adopt much of the approach set out in this chapter. This is important because the wrong scoping decision can, in the long run, invalidate the certificate you do achieve, leave key parts of your organisation open to all the risks that you are attempting to exclude and, when you finally focus on the need to do the job properly, will be far more expensive than if you’d done it right in the first place. Worse, because you did it wrong in the first place, it will be far harder to get adequate commitment and support for an extended project across the organisation than it would have been if you’d sold the whole project to the organisation in the first place.

Formalise key arrangements

At this point, you should formalise:

•  How you will demonstrate leadership and commitment (all the requirements of Clause 5.1 in the Standard, building on the project mandate).

•  The final version of the information security policy.

•  The first full version of the RACI matrix, setting out organisational roles, responsibilities and authorities.

•  The communication policy that identifies who is to communicate with which audiences, when and through which means. The communications process should include a method to ensure the message(s) in question has been correctly received and understood.

•  The competence requirements for the generic ISMS roles, such as top management, risk owner, internal auditor, etc., as well as those identified when initiating the project and the ISMS. Bear in mind that you will also need competent individuals who can implement and maintain the selected information security controls, plus people who can deal with IT security, physical security and legal compliance. At least one member of the project team, ideally the project manager, should be required to have something like the IBITGQ CIS LI certificate.

•  You should ensure that you have adequate resources to achieve the ISMS objectives.

Information security policy

The information security policy is the main driving force for the ISMS; it sets out the board’s policy on, and requirements in respect of, information security. It should be a short document, but it has to capture board requirements and organisational reality while meeting the requirements of the Standard. There is a full discussion of the issues involved in, and development process required for, an information security policy statement in IT Governance – An International Guide to Data Security and ISO27001/ISO27002, Sixth Edition.

The board and management have to be completely behind and committed to the ISMS; therefore, the policy statement must be issued under their authority and there should be clear evidence, in the form of written board minutes, that the policy was debated and agreed by the board as a whole and/or by the management steering group. Any revisions to the policy should also be agreed through the same route.

It will also require participation by all employees in the organisation and may require participation from customers, suppliers, shareholders and other third parties. This is part of the context of the ISMS referred to earlier. In thinking through the security policy, the board and the forum will need to consider how it will impact on these constituents and/or audiences and the benefits and disadvantages that the business will experience as a result of this. It is a good idea to start thinking these issues through before you commence the detailed process of designing and deploying your ISMS.

Communication strategy

Communication is important to ISO 27001 project success. Underlying every successful change management programme, and especially necessary for the successful roll out of an ISMS, is a well-designed and effectively implemented internal communications plan. Compliance with ISO 27001 and common sense both suggest that key components of this plan must include:

•  Top down communication of the information security vision – why the ISMS is necessary, what the organisation’s legal responsibilities are, what the business will look like when the programme is complete and what benefits it will bring to everyone in the organisation.

•  Regular cascade briefings to all staff on progress against implementation plan objectives. These briefings should quickly become part of the existing organisational briefing cycle so that ISMS progress becomes part of the normal business process – ‘just another thing that we’re doing’.

•  A mechanism for ensuring that key constituencies and individuals within the business are consulted and involved in the development of key components of the system. This ensures that they buy into the outcome and to its implementation, and is a key reason for structuring the steering group and project team as was suggested in chapter two.

•  A mechanism for ensuring regular and immediate feedback from people in the organisation – or in affected third party organisations – so that their direct experience of the initial system as it is implemented can be used in the evolution of the final version. This can form part of your continuous improvement process and, more immediately, offer evidence of effective ‘checking’.

•  These face-to-face communications should be underpinned with an effective information sharing system. Usually this will be part of the corporate intranet, on which regular progress reports as well as detailed information on specific aspects of the ISMS, are posted. Email alerts can tell staff to access the intranet for new information whenever it is posted and the site can encourage feedback by means of a ‘write to the CEO’ function.

Of course, if the organisation doesn’t currently have a well-developed internal communication process, it will need to develop one. Allowance should be made in the outline project planning timetable and resource allocation for the development of such a system. Do not try and take an ISMS project forward without an adequate internal communication process: information security controls depend to a very large extent on the informed and committed behaviour of individuals within the organisation and, as a result, you simply have to ensure that you can deliver this.

Staff buy-in

The initial staff briefing, the one that accompanies the project kick- off, should set out clearly the nature of the threats faced by the organisation and the possible costs, in both financial and non-financial terms, of information security breaches. The Case for ISO27001:2013 and the chapters on information security risk and governance in IT Governance – An International Guide to Data Security and ISO27001/ISO27002, Sixth Edition, provide useful information that can underpin a communications strategy.

Wherever possible, local and/or industry specific information should additionally be sought and used in staff presentations as this gives immediacy and currency to the possible threats. Illustrations of the possible direct consequences to your own organisation should be developed in order to add make the situation more relatable and help all those involved to fully appreciate the need for the ISMS.

A key part of getting effective user buy-in is translating information security risks and technology issues into widely and clearly understood business ones. Boards and managements understand issues in terms of their impact on the business and, unless those impacts are clearly delineated, clearly credible and clearly quantified, they’re not going to pay them much attention. The same is true of functional and business leaders across the organisation whose interest is, if anything, more parochially focused on their own specific issues. The truth is that they are less interested in the long term strategic needs of the organisation than they are in achieving the specific sets of goals that drive their own compensation or promotion possibilities.

All this means that you not only need to translate the information security imperatives into a small number of credible, quantified and relevant numbers for the board and senior management, you also need to make the ISMS initiative directly relevant to every single person on whose support you’re going to rely. Like all organisational politics, there’s almost certainly no single message that will do this job for everyone. You’re going to need a single, strong organisation-wide, top-down commitment supported by a large number of one-on-one, locally focused discussions in which you set out how the ISMS project will specifically improve the business circumstances for each person to whom you talk.

A large part of effective project management is sales skills and a detailed understanding of the organisational politics; this is why it can be very hard for an outsider to succeed as project manager in delivering an ISMS project.