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.
1.1 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.
1.2 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.
1.3 The Project Mandate
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:
- 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.
- Timeline: create an outline project plan and target completion date on the basis of the nine steps to success.
- 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.
- 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.
1.3.1 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[Symbol]7[Symbol]360 to 99.99999% and 24[Symbol]7[Symbol]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.
This is an extract from Nine Steps to Success – An ISO 27001 Implementation Overview, Third edition
©IT Governance Publishing Ltd
If you’re tackling ISO 27001 for the first time, this book will give you the guidance you need to get to grips with the Standard’s requirements and ensure your implementation project is a success.
Author Alan Calder knows ISO 27001 inside out: the founder and executive chairman of IT Governance, he led the world’s first implementation of a management system certified to BS 7799 – the forerunner to ISO 27001 – and has been working with the Standard ever since.