It may be something of a cliché but, for information security management system (ISMS) projects, it is certainly true to say that ‘well begun is half-way done’. The person charged with leading an ISO/IEC 27001:2013 ISMS project has to reduce something that looks potentially complex, difficult and expensive in terms of time and resources, to something that everyone believes can be achieved in the time frame allocated and with the resources allowed. And then you have to make sure that it is actually delivered!
What this actually means is that the ISMS project leader has to set up the project in such a way that it is adequately resourced, that there is enough time (including for everything that may go wrong) and that everyone understands the risks in the project and accepts the controls that are being deployed to minimise them.
Almost everyone dislikes change. Very few people relish dealing with the unknown. Most people will see an ISMS project as something that brings both change and the unknown into their working life, and not everyone will welcome it. That’s normal; they’ll get on board in the end.
The project leader, in the first phase of the project, is the person to whom everyone else in the organisation turns for insight, comfort and support. You have to be the person who provides enthusiasm, certainty and an understanding of what’s involved.
This means that learning on the job in a transparent fashion is not advisable. I don’t mean that you need to know all the answers at the outset, because that’s not realistic. As long as you have a clear understanding of the strategic issues and practical knowledge of where to turn for advice and guidance, you can be effective – even if you’re only a day or two ahead of everyone else in the detailed knowledge required for the project.
You’d be surprised at the number of times someone has kicked off an ISMS project without adequate preparation, has failed to answer a series of questions or challenges about specific issues adequately, and has then been surprised that the project has lost credibility rather quickly.
Your CEOs support for the project is even more important than your own understanding of what you’re trying to achieve. Information security is both a management and a governance issue. Successful implementation of an ISMS depends absolutely on the project having real support from the top of the organisation. With it, you have a real chance of success; without it, none at all. Securing real top management support – not mere lip service – is key to ISO 27001 success. In this context, I’m not necessarily talking about the CEO of a large, multi-subsidiary organisation; I’m talking about the person who is accountable for the business success or failure of the trading entity that is considering ISO 27001. This could be a trading division, a subsidiary company, a standalone unit or a virtual organisation.
It’s important to be clear about the meaning of ‘accountable’ in this context. I am talking about the person whose job and career ultimately depend on the success of the business entity that is considering ISO 27001; this person does not always occupy the role that is formally ‘where the buck stops’. All organisations know exactly where the buck really stops, and this is the person I’m referring to as the CEO in this chapter.
Strategic alignment
The first reason why the CEO has to fully support you and the ISMS project is that it is a business project, not an IT project. It has to be fully aligned with the business model, business strategy and goals, and has to be prioritised for the business and allocated an appropriate level of resources. While the CEO is unlikely to be the ISMS project leader, the only person who can effectively prioritise cyber security is the CEO. No single project leader is in a position to be clear about the organisation’s strategic needs and goals but, as this is a strategic project that affects everyone, you need to be ‘in the loop’ so that you can tailor your own plans to deliver the organisation’s business priorities.
You also need to know what the strategic risks faced by the organisation are, and how these are reflected and prioritised in information security risks. There are many possible questions, the answers to which will be critical to your approach and detailed plan. For instance, is the risk of intellectual property theft more significant – with a greater potential impact – than the risk of, for example, a three day business closure? Is regulatory compliance more, or less, important than reducing the cost of sales? Is information security and regulatory compliance going to be important in outsourcing solutions (or, when faced with a choice between a lower cost, but less secure, and a more secure but more expensive outsourcing option, which one will the organisation choose?). How should conflict between the regulatory requirements of two different jurisdictions in which the organisation trades be resolved? What’s the trade-off between the operational flexibility that is allowed to subsidiary organisations, and implementation of a minimum, consistent level of information security and IT service reliability? What are the long term plans for specific support services (if they’re going to be outsourced, then you’re going to approach ISMS implementation differently than if they’re staying in-house)? There are many such questions, the answers to which you need to know before you can even start planning; there are many others that will come up in the course of the project.
Prioritisation and endorsement
The second reason you require this level of support is that, without it, the project simply won’t happen. It’s not enough for the CEO and executive management simply to acknowledge that the project is important. It’s not enough that they merely talk about it. It’s not enough that you know the organisation’s strategic priorities and are able to align the project with the business plan.
If it really is to happen senior management have to be committed, well and truly determined to achieve it. Top management commitment means that the project gets the financial and human resources it needs. It gets the oversight, ‘face time’ and internal communication headlines it needs. Unless you have this sort of commitment, there are going to be lots of things that people throughout the organisation will see as higher priorities than your project. Of course, there are going to be some higher priorities; what you need is clear prioritisation that is understood across the business and is continuously supported by the CEO.
The relative prioritisation of your project needs to be clearly understood. Within that context, it needs to have the firm and uncompromising endorsement of the CEO. By ‘endorsement’ I mean that, when those occasionally unnecessary internal barriers appear, the words: “This is a project endorsed/mandated by the CEO” should go a long way to overcoming them.
Change management
The third reason you need the CEO’s support is that an ISMS project is likely to be a change management project. The implementation of an ISMS is not a low-impact activity. It may require changes to how computer users do a number of things and it also affects aspects of managers’ everyday activities. A successful ISMS project is, in other words, a low-key, but nevertheless wide-ranging change management project and the way you approach it has to learn from the experience of successful change management programmes.
There have been many books written about change management. Many of these projects fail to deliver the benefits that have been used to justify the expense of commencing and seeing them through. Successful implementation of an ISMS does not require a detailed, strategic change management programme, particularly not one devised and driven by external consultants. What it does require is complete clarity among senior management, those charged with driving the project forward, and those whose work practices will be affected, as to why the change is necessary, what the end result must look like and why this result is essential. The change management aspects of this are the third reason why the CEO’s support and backing is essential: you want him to be setting the example, doing all the things that you’re going to want everyone else to be doing.
The fact is that the Standard itself demands this level of support. It will not allow any certification body to certify an ISMS without getting firm evidence that senior management is committed. The reason for this is simple: if commitment is lacking the ISMS will not be adequate; the risks to the organisation will not have been properly recognised or fully addressed; and the strategic business goals and consequent future information security requirements are unlikely to have been considered.
The CEO’s role
Ideally, the CEO should be the driving force behind the programme, and achievement of ISO 27001 certification should be a clearly stated goal in the current business plan. The CEO needs to completely understand the strategic issues around IT governance and information security, and the value to the company of successful certification. The CEO has to be able to articulate this to the board and senior management, and to deal with objections and issues that arise. Above all, he or she has to be sufficiently in command of this part of the business plan to be able to keep it on track against its strategic goals.
The chairman and board should give as much attention to monitoring progress against the ISO 27001 implementation plan as they do to monitoring all the other key business goals. Clause 5.1 of the Standard specifically requires evidence of this commitment from the top: “Top management shall demonstrate leadership and commitment with respect to the information security management system”. If the CEO, chairman and board are not behind this project there is little point in proceeding; certification will not happen without clear evidence of such a commitment. This principle of leadership from the top is, of course, also essential to all major change projects.
If you are already the CEO of the organisation, then you’re doing exactly the right thing by reading this book and preparing to drive the information security project yourself. If you’re not the CEO, then you’ve got to secure the sort of commitment and support that I described above.
The ideal leader of an ISMS project is a business leader – a COO (chief operations officer) or a line of business leader; adopting an ISMS is a business project and business leadership is therefore fundamental to its success. It is often the case that an ISMS project fails because it has apparently been set up as a technology project and it is therefore seen and treated as a narrow project that doesn’t deserve full business commitment. ‘Just another IT project’ is the wrong message for driving an ISMS into the culture of the organisation.
There are, of course, organisations in which the chief information officer (CIO) is a member of the senior management team, is responsible for an integrated function that includes information security and already has the full trust and support of the CEO and the board. In such an organisation the CIO could be the driver of the project, but it will still need the CEO’s commitment and support, not least so that everyone in the organisation understands that securing recognition is a business priority. The CIO will also urgently need to build a cross-business project team; I will return to this later.
The project mandate is where you capture initial evidence of this commitment in a usable format. A project mandate (or PID) is a document that is widely used to capture the key elements of any complex project. It ensures there is a single, original point of reference that sets out the three keys to project success: deliverables, timeline and budget.
Complex projects fail because one or more of these three project variables are poorly identified and/or managed. ‘Scope creep’ is one of the most common roots of project failure. Project mandates, therefore, seek to clearly identify project scope and to pin down the three variables in order to support an effective project governance process.
Your project mandate should address these four points:
1. Deliverables: identify the objective as the achievement of ISO 27001 certification for either a specific part or the whole of the organisation and, if possible, identify why information security is important for your organisation.
2. Timeline: create an outline project plan and target completion date on the basis of the nine steps to success.
3. Budget: identify the resources, both internal and external, as well as the training, software and tools that you are going to need for the project.
4. Authorisation to proceed: the mandate should contain management endorsement of the project and authorisation to proceed, to achieve the identified objectives using the budgeted resources.
Deliverables and the project objective
While the project deliverable is relatively easy to define (for example, achieve ISO 27001 certification within four months), you still need to be clear about the reasons for pursuing that objective as well as clarifying the difference between project objective and information security objectives.
The purpose of an information security management system is, of course, to reduce and control risks to your information. The actual objective (or objectives) of your ISMS project may be different to the purposes of the ISMS itself, and you should be clear about these differences if you are to appropriately focus both the project and the ISMS. The project objective may be, for instance, to secure ISO 27001 certification within a given time frame in order to meet a contractual or regulatory requirement, to improve business competitiveness or reduce the cost and complexity of sales and marketing responses to tender invitations. Project objectives, in other words, link specifically to business benefits that are to be derived from their achievement. Project objectives will usually be high-level and performance against them easy to track.
Information security objectives may be, but are not necessarily, related to the project objectives. Information security objectives will definitely be linked to the preservation of confidentiality, integrity and availability of information within the context of the organisation and in relation to its risk appetite. Progress toward achieving information security objectives must be measurable, which means the objectives themselves need to be specific, measurable, achievable, realistic and time-bound. Typical objectives might, for instance, be to reduce the number of disruptive information security incidents from 14 per year to two per year, or to increase network availability from 97% and 20×7×360 to 99.99999% and 24×7×365. Such objectives will be broken down into lower level objectives, with accountability for their achievement allocated to appropriate departments and levels within the organisation.
Gap analysis
Most organisations are already taking steps to manage their information security. While there may be significant vulnerabilities, it’s not as though nothing is currently being done! The starting point for your project is usually, therefore, to understand how far your current practices are from the requirements set out in ISO 27001, and the best way to do this is with what we call a ‘gap analysis’. This is a quick, reasonably high-level audit of your current information security management practices against the requirements set out in ISO 27001, which identifies where there is a shortfall and also identifies what resources and capabilities you have in place for closing the gap, or what resources you might need to bring from outside.
If you have already defined information security objectives, your gap analysis could also identify what steps still need to be taken in order to achieve those objectives.
You might call the output from the gap analysis a ‘security improvement plan’ or ‘SIP’. This SIP becomes, in effect, your ISMS Project Plan.
Budget and resources
You can’t implement an ISO 27001 ISMS on your own, or without some investment in tools and training. For ISO 27001, ‘resources’ means human, technical, information and financial resources. Purpose-designed tools are likely to reduce project time, error and cost. The two most useful tools are documentation templates and risk assessment software. The risk assessment solution we most recommend is available directly from Vigilant Software, here: www.vigilantsoftware.co.uk
A number of people across the organisation, and from different levels within it, will need to contribute. You may also want to bring in external consultants, whether for guidance or because you need additional resource to execute your project plan.
There are a number of specialist areas in which consultants can be helpful:
• You can use consultants – trusted third parties – to communicate the seriousness of the information risks faced by the organisation and the need, therefore, for an ISMS.
• You can use consultants to provide advice on specific (most often technical) issues – for instance, scoping and how external or internal threats might affect your decisions about project scope – to carry out a risk assessment, to deal with documentation, or to advise on integration with other management systems.
• You can (and might be well-advised) to use consultants to help you identify appropriate technical controls for specific risks that you’ve identified. This holds true as long as the consultants have no financial interest in any solutions they might recommend and fully understand and can help you apply the two key financial measures of return on investment (ROI) and total cost of ownership (TCO) to any solutions they propose.
• You can use consultants in a mentoring capacity, to review critical documents and as a sounding board with whom you can discuss key steps in your project and key issues that you have to deal with, and possible solutions.
You do not need to hire external consultants in order to achieve ISO 27001. Many organisations get the job done completely under their own steam. Many other organisations simply don’t have the time and resource to structure, manage and deliver an ISMS project without additional input. Whether or not you hire consultants is, therefore, a function of resource availability within your organisation, budget and your organisation’s cultural preference for working things out for itself versus bringing in outside expertise.
The major benefits of using outside consultants should be that:
• even if they are only working on your project one day per week, their time with you is focused exclusively on your project, and
• they have significant ISO 27001 implementation experience, which should help you avoid blind alleys, over-detailed or impractical methodologies, disjointed implementations or losing the plot entirely.
If you use consultants, it should go without saying that they should be able to point at substantial experience implementing ISO 27001 and, of course, that they themselves are ISO 27001 certified.
The ‘do-it-yourself’ approach can be simplified and accelerated by using the kinds of established tools and techniques discussed in this book, and by following this nine-step methodology.
The output from your gap analysis is therefore an ideal starting point for determining the resource requirements of the project, starting with whether or not you intend to use external consultants or will be recruiting for key internal ISMS or project roles. It’s particularly useful to identify who will be needed on the ISMS project team (we’ll discuss this shortly); who will be invited to contribute from across the business; who will have the key project roles and responsibilities; who owns the project; who the project reports to internally; how progress is tracked and reported; etc.
The major benefit of identifying your resource requirements in your PID is that, once top management have signed off on the project, you should be able to rely on having access to those resources. In any organisation where a considerable part of the required resource will have other duties and responsibilities, this is a major benefit!
Those who are involved with the ISMS will need to be competent to carry out their roles. I’ll return to the issue of competence later, but you will need to start taking steps to acquire competent personnel right away!
Apart from training and skill development, resource requirements may also include software, toolkits, staff awareness e-learning, training and/or consultancy support. Each of those options will be addressed at appropriate points in this book.
Timeline and outline project plan
Your gap analysis should also enable you to create an outline project plan, most sensibly in the form of a Gantt chart. At this stage, it can be quite high-level, setting out timelines, milestones and key objectives. The end point of your project plan should, of course, be the achievement of your project objective within the planned project timeframe; your information security objectives are likely to be pursued and achieved over much longer time frames.
As your project planning becomes more detailed, so will your Gantt chart; you will, however, still want to stay within the original timelines and will want to avoid disruptions to the project that could have an impact on the timeline you’ve committed to achieving.
Project Initiation Document
A PID is a formal document; most commonly used within a PRINCE2® project, the concept applies just as well to any complex project that involves multiple contributors, a number of whom may have multiple roles both inside and outside the project. It is also an excellent way to record the project objectives clearly and to have the key initial components of the project approved by top management.
If your organisation already has a process that meets these needs, you should use it: the sooner the ISMS project can be evidently set within your business as usual arrangements, the better. If you do not already have such a process, you can either create one yourself, or simply purchase the PID toolkit from one of our websites.
Within your document management system the PID should be treated as a record; after all, that’s what it is!