BUSINESS CONTINUITY MANAGEMENT · Business Continuity Management A Maturity Model Master’s Thesis Informatics & Economics by Naomi Smit - 2005 ii Preface 'Non scholae sed vitae

BUSINESS CONTINUITY MANAGEMENT

A Maturity Model – By Naomi Smit

BUSINESS CONTINUITY MANAGEMENT

A maturity model

Master's Thesis by Naomi Smit (271550)

November 1st 2005

Erasmus University Rotterdam

Informatics & Economics

Cosupervised by Dr.ir. J. van den Berg

Cosupervised by Drs. S. Debets MSIT

Business Continuity Management

A Maturity Model

Master’s Thesis Informatics & Economics by Naomi Smit - 2005 ii

Preface

'Non scholae sed vitae discimus' (Seneca)

This Master Thesis is the result of six months of research. During those six months I learnt a lot,

more than I could possibly fit in this thesis. However, Seneca's saying is a good comfort. I am sure

the things I learned during this research, both on a professional and a personal level, will be useful

for me, not only to obtain the MSc title, but also for my further life.

I would never have been able to accomplish this research the way I did and to learn all things I

learned without the support of so many people around me. Therefore it seems logical for me to start

this thesis with a word of gratitude.

First of all, I'd like to thank my both coaches, Steven and Jan. Without their guidance, my research

would never have been the same quality level as it is now. Steven, thank you for the great support

during my entire internship. I really appreciate they way you let me follow my own path and, at the

same time, provided me with so much valuable help and feedback. Jan, I had already decided I

wanted you to coach me, before I had even chosen a direction for my research. Your catching

enthusiasm not only for academic research but also for the way science and business can

cooperate has inspired me enormously.

Furthermore, I'd like to thank all my colleagues at VKA for their help. I cannot imagine a better place

where I could have written my thesis. Everyone, without an exception, has been very interested in

my research and more than willing to help me where they could. With the risk of forgetting people,

I'd like to thank some colleagues in particular. I'd like to thank my MBI colleagues who have

provided me with all the inputs and feedback I could wish for. Special thanks go out to Marc en Dick

for regularly discussing the research with me and for all their critical comments. I'd like to thank

Willem-Jan and Guus for shining their light on my work; Jos, for being the one that I could ask for

help or advice anytime about anything I could think of; Tim, for convincing me I should do an

internship at VKA; Koos, Christ, Onno, Hans , Berthold, Henk, Jan and Ferry for accompanying me

to one or more interviews; Joep for validating my model and everybody from support for providing

me with a better working environment than a student could think of.

Who I certainly must forget to thank are the people I have interviewed for this research. Without your

help, this research would not have been possible. Given the anonymous set-up of this research I will

not name you personally, but I'd like to thank you for your time, information and visions.

On a more personal level I'd also like to thank my friends for all their interest in my research and

more important, all the fun and good times that gave me renewed energy to devote myself to my

research.

Last but not least, I want to thank my parents for their support and their never-ending belief in me.

They taught me I could accomplish anything I would want to, as long as I would do the best I can.

At least up to now, they have always been right about this…


A Maturity Model

Master’s Thesis Informatics & Economics by Naomi Smit - 2005 iii


A Maturity Model

Master’s Thesis Informatics & Economics by Naomi Smit - 2005 iv

Management summary

Context

Organizations are more and more concerned about the risks that threaten the continuity of their

business. The increasing pressure that forces organizations to take measures to assure the

continuity of their business influences this rise in attention. This pressure is exerted by, among

others, customers who enforce requirements on their main suppliers and by supervisory bodies.

Besides this increasing need for continuity, continuity also becomes more difficult to assure due to

increasing threats, chain integration and an increasing dependency on complex information

systems.

Business Continuity Management can help ensuring the continuity of business by focusing on the

critical business processes. However, BCM is both relatively new for organizations, and a fairly

complex process which must be integrated through the entire organization. For this reason,

organizations appear to have a need for a BCM analysis tool that can provide insight on where they

stand and what they should do to improve their BCM.

In this research we aim to develop a maturity model that can serve as the basis for such an analysis

tool. We used both existing literature and the data from our own market scan for the development of

our model.

The maturity model for BCM

Our maturity model disttinghuishes two different dimensions along which an organization matures.

The maturity of BCM within a given organization is determined by both the process quality and the

considerd scope. By defining discrete stages on both axes, the model is separated into squares,

named SPQS's (scope process quality stages). Our model, as shown below, indicates the BCM

maturity of a given organization by the covered area of SPQS's for which an organization meets the

requirements.

1. Initiated

2. Planned

3. Implemented

4. Embedded

5. Controlled

6. Optimized

I. IT focus II. Organisationfocus

III. Chain focus

IV. Integralfocus

Scope

Proce

ss q

uality

The BCM maturity model


A Maturity Model

Master’s Thesis Informatics & Economics by Naomi Smit - 2005 v

Each SPQS is described by several characterics, and each characteritic is specified by a few

objectives. Each objective, in turn, is elaborated into several requirements, which are specific and

measurable and all requirements together form a quick scan. The structure of characteristics,

objectives and requirements is illustrated by the example below. 1

BC Analysis

Selection measures

RA

BIA incl all internaldependencies

Characteristic Objectives Requirements

Critical processesidentified

Processesvisualized

Continuity norms set

etc....

Structure model based on characteristics, objectives and requirements

In addition, our model also offers a general growth strategy that can determine the ideal growth path

for a given organization.

Acadamic relevance

This model forms valuable contribution to the existing theory of BCM. More practical information

about BCM, such as methodologies, is sufficiently available. The opposite, purely theoretical

concepts regarding BCM, is also provided sufficiently. However, there are not many general models

for BCM based on data from actual research, which can be used as an instrument to analyse

practical cases. Our model offers a simplified representation of reality that can be used as a

theoretical guide in all kinds of BCM research, such as comparisons between different types of

organizations.

Business relevance

Not only does our model contribute to the acadamic theory base for BCM, it can also serve as an

usefull analysis tool for organizations.

This maturity model can provide an organization with insight in the maturity of its BCM. This insight

can be supplemented by comparing the maturity acoording to our model to that of, for instance,

other organizations in the same sector.

In addition, the model can also serve as a tool to communicate the state of the BCM throughout the

organization. Given the BCM maturity, the model can subsequently be used as a guide to improve

the maturity of the BCM step by step.

1 In this example we focus on one of the characteristics of level 2, namely BC analysis, on an organization scope


A Maturity Model

Master’s Thesis Informatics & Economics by Naomi Smit - 2005 vi


A Maturity Model

Master’s Thesis Informatics & Economics by Naomi Smit - 2005 vii

Table of contents

Preface ii

Management summary iv

1 Introduction 1 1.1 Context 1 1.2 Research problem 2 1.3 Methodology of the research 3 1.4 Scope of this thesis 4 1.5 Reading guide 5 1.6 Conclusion 7

2 Business Continuity Management 8 2.1 Introduction 8 2.2 Definition BCM 8 2.3 Need for BCM 9 2.4 Scope BCM 11 2.5 Related areas of expertise 12 2.6 Conclusion 14

3 The concept of maturity models 16 3.1 Introduction 16 3.2 The concept 'maturity model' 16 3.3 Justification for the use of a maturity model for BCM 18 3.4 Evaluation of existing maturity models & design options 19 3.5 Conclusion 20

4 The maturity model to be developed 22 4.1 Introduction 22 4.2 Model requirements 22 4.3 Requirements versus objectives 23 4.4 Existing models 24 4.5 Developing our own model 26 4.6 Conclusion 28

5 Draft Model 30 5.1 Introduction 30 5.2 Development process for draft model 30 5.3 Selection of the best practice methodology 32 5.4 Determination of the areas within our model 33 5.5 Determination aspects within the areas 34 5.6 Consultation with focus group & settlement draft model 35


A Maturity Model

Master’s Thesis Informatics & Economics by Naomi Smit - 2005 viii

5.7 Conclusion 36

6 Design Market Scan 38 6.1 Introduction 38 6.2 Set up market scan 38 6.3 Set up interviews 39 6.4 Question list 40 6.5 Validity market scan 40 6.6 Research group 42 6.7 Conclusion 42

7 Outcome market scan 44 7.1 Introduction 44 7.2 Summary findings market scan 44 7.3 Comparison between kinds of organizations 46 7.4 Conclusion 47

8 The BCM maturity model 48 8.1 Introduction 48 8.2 Description framework 48 8.3 Determination of maturity 52 8.4 Recommendations to improve maturity 53 8.5 Conclusion 54

9 Development final model 55 9.1 Introduction 55 9.2 Development model as presented to focus group 55 9.3 Feedback from focus session 59 9.4 Development final model based on feedback focus group 59 9.5 Evaluation choices made regarding design options 61 9.6 Development generic growth strategy 61 9.7 Development model into a tool 62 9.8 Conclusion 63

10 Validation model 64 10.1 Introduction 64 10.2 Methods used for validation 64 10.3 Validation model regarding requirements 65 10.4 Conclusion 69

11 Conclusions and further research 71 11.1 Final result of our research 71 11.2 Validity of this result 72 11.3 Further research 72


A Maturity Model

Master’s Thesis Informatics & Economics by Naomi Smit - 2005 ix

References 74

Glossary 77

Overview appendices 79


A Maturity Model

Master’s Thesis Informatics & Economics by Naomi Smit - 2005 1

1 Introduction

1.1 Context This chapter serves as an introduction for this thesis ‘A maturity model for BCM’. We will first sketch

the context of our research and amplify on the observed need within organizations that made us

decide to start this research. Next we will formulate the precise objective of our research and the

approach used to achieve this objective.

Having introduced the research this thesis describes, we will subsequently focus on the thesis itself.

We will define the exact scope of this thesis and give a brief description of the contents of the

various chapters, which can be used as a reading guide.

1.1.1 Rising attention for continuity

Organizations are more and more concerned about the risks that threaten the continuity of their

business. Although many of those risks aren't new, there is definitely a rise in the attention for

continuity issues. The increasing pressure that forces organizations to take measures to assure the

continuity of their business influences this rise in attention. This pressure is, among others, exerted

by customers who enforce requirements to their main suppliers and by supervising institutions.

Besides this increasing need for continuity, continuity also becomes more difficult to assure. Due to

increasing chain integration, business processes cannot be regarded separately anymore.

Dependencies among chain partners increase and discontinuity of one of the parties has

consequences for the entire chain. Moreover, the threats regarding continuity have risen

considerably, also because of the increasing dependency on complex information systems.

1.1.2 Advent of Business Continuity Management

Given the increasing attention for continuity issues, other methods as security and disaster recovery

appear not to be sufficient anymore to fulfill those continuity needs. This has to do with the fact that

such methods mainly focus on the continuity of a facility, most often IT. Continuity of a facility

however is not a guarantee for continuity of the business. To assure the continuity of the business,

measures should be taken which assure the continuity of the processes that are critical for the

survival of the organization, the so-called critical processes. Such an approach based on the

identification of the critical processes is called Business Continuity Management.

Within many organizations one can see a shift in attention from only IT continuity as part of security

towards Business Continuity Management. Verdonck, Klooster & Associates (VKA), the sponsor of

this research, defines BCM as follows: “Business Continuity Management encompasses the

management process that aims to prevent severe disruptions in the business and to protect critical

processes2 against the consequences of disruptions or disasters.” BCM focuses thus on the

continuity of the business itself instead of only on the continuity of the IT.

2 A critical process is a process for which can be said that an interruption of this process will immediately have a

negative impact on the objective of an organization and a longer interruption can endanger the survival of the

organization (VKA intranet, 2005)


A Maturity Model


1.1.3 Need for a BCM analysis tool

Although the awareness that something should be done to assure business continuity is present in

many organizations, they often do not know how to implement business continuity management

processes properly. BCM is still relatively new and is regarded as a fairly complex process that

should be integrated with the entire business. Many organizations therefore call upon specialized

services providers, like external advisors. The sponsor of this research, VKA, supports organizations

in implementing BCM.

Although many different methodologies for implementing BCM exist, there is relatively much

consensus on what such a methodology should encompass. The contents of the various

methodologies do not vary much. Therefore, if research should attribute something useful to the

existing knowledge of BCM, it needs to focus on something else than just a methodology.

What the current methodologies do not offer is insight in the current situation of BCM within an

organization, i.e. some sort of perspective from which to look at the methodology or process.

Practice shows that organizations have a need for a tool that can provide insight on where they

stand, where other (similar) organization stand and what they should do to improve their BCM

starting from the current position. Such a tool could also aid the communication to the board and the

justification of a necessary investment in BCM. The observation of this need is also supported by the

fact that several organizations either have decided to or are considering to develop such a tool

themselves. Hence, the development of a tool as just described would be very useful in practice.

1.1.4 Maturity model for BCM as basis for the desired tool

To enable easy communication of the outcomes, this model should ideally be based on some

(scientific) model. The model should describe all phases an organization passes through before

BCM is an integral part of their business. A model that describes those phases can assist

organizations to determine the current state of their BCM and indicate the path to follow for the

further development of their BCM.

Such a model can be based on the concept of maturity models. Maturity models assume the road to

a goal goes through several phases and an organization reaches maturity on the research area step

by step. One of the best known examples of maturity models is the software development Capability

Maturity Model (CMM), but also for similar processes within an organization maturity models been

developed, such as for the project management process or the e-business process.

The development of a BCM maturity model, which could serve as a basis for BCM assessment tool,

would make a valuable contribution to BCM theory and practice.

1.2 Research problem 1.2.1 Definition research problem

The aim of this research is to fulfill the need for an analysis tool for BCM. Based on this tool, an

organization should be able to assess the current state of its BCM, to communicate it, to benchmark

it and to determine the steps to take to improve its BCM.


A Maturity Model


We will base this tool on a maturity model, which we will develop during this research. Our main

objective for this research therefore can be defined as:

Definition 1.1: Objective for the research

1.2.2 Assumption made regarding the research problem

Our model will focus on the maturity of the Business Continuity Management process. In defining

our research problem, we implicitly made the assumption that a more mature Business Continuity

Management process will result in a better Business Continuity capacity. An organization is

considered ‘more mature’ as it controls the BCM process (as it ought to be organized based on our

available information) better.

The reason to make this assumption is twofold. First of all, Business Continuity (BC) capacity itself is

a rather abstract phenomenon and therefore it would be hard to find a way to actually measure its

quality or maturity. The BCM process however can be assessed based on which activities are and

are not executed. It is therefore considerably easier to determine the maturity of the BCM process

than the maturity of BC itself. Secondly, even if it would be fairly straightforward to determine the

maturity of BC itself, it would be hard to give recommendations based on this judgment. The

observation that the outcome of the BCM process, namely Business Continuity, is not what it should

be, does not directly signal what activities should be undertaken to improve the Business Continuity.

If we focus on the BCM process, it is easier to see how to improve this process and hence the

outcome. Maturity models usually focus on the process maturity instead of the direct outcome. In

paragraph 3.3 we will elaborate on the difference between measuring the process outcome and the

process itself.

1.3 Methodology of the research Since we want to develop a model that serves as the basis for a practically usable analysis tool, this

model should be based on the way BCM appears to be organized in practice. For this purpose we

will execute a market scan, which should provide us with all the practical information about BCM we

need. This information will serve as the input for the development of our model.

However, BCM is not an entirely new research area and much valuable information about BCM in

the form of methodologies, models, articles and more is already available. It would be very inefficient

not to take this available information into account. Therefore, before we will conduct our market

scan, we will base an initial outlay for our model on existing literature. This outlay will serve as a

starting point for the market scan.

Both the initial outlay (also called 'draft model') and the complete model (also called 'final model') will

be discussed with a focus group, compounded of several industry BCM experts, whose feedback

'To develop a maturity model for BCM based on which the current state of BCM

within an organization can be assessed and recommen dations to improve this

state can be given’


A Maturity Model


will be processed before the draft and final models are settled. This focus group will serve as

additional quality assurance for our research project.

Having developed the final model, our last step is to validate whether our model is correct and

whether it meets the formulated requirements.

If we have validated our model, we can start to develop our model further into an actual complete

tool. However, this step falls outside the scope of our research, as stated in the previous paragraph.

This results in the following approach for our research project:

Figure 1.1 Research approach

1.4 Scope of this thesis This research is executed for two different target groups, VKA, an independent consultancy and

management organization that supported this research, and the Erasmus University, which

considers this research as the final part of the Master program Informatics & Economics the author

of this thesis completes. The exact deliverables of this research differ among those two target

parties. Therefore, this thesis does not contain all deliverables of the overall research.

This research will produce three separate deliverables:

1. The model itself, namely the description of the various maturity levels;

2. A quick scan that can be used to determine the maturity of a given organization and hence the

place within the model;

3. A generic growth strategy, which can determine the path to follow to improve the BCM given the

maturity of an organization.

The focus of this thesis will be mainly on the maturity model as a scientifically founded maturity

model that can serve as a basis for a BCM analysis tool.

The first deliverable, the model itself, therefore falls inside the scope of this thesis and hence both

the model itself and its development process will be described exhaustively.

The second deliverable falls outside the scope of this thesis. We only have to assure that it is

possible to base an easy applicable quick scan on the model we developed. The actual content of

the quick scan, however, does not fall inside the scope of this thesis and will remain exclusive

property of VKA.


A Maturity Model


With regard to the third deliverable we will make a high-level description showing how a growth

strategy can be determined based on the maturity of an organization. After all, this is one of the

requirements every maturity model should meet: the ability to show the path to maturity. The exact

actions that should be executed, thus the more concrete recommendations, fall outside the scope of

this thesis and will also remain exclusive property of VKA.

The scope of this thesis can be visualized as follows. The red parts fall inside the scope of this

research but outside the scope of this thesis.

Research

Maturity model incl levels

Quick scan

Recommendations

Figure 1.2 Scope of our research

1.5 Reading guide To sketch a picture of the outline of this thesis, we will now give a brief description of the contents of

the remaining chapters.

Chapter 2: Business Continuity Management

In this chapter we will introduce the concept of Business Continuity Management (BCM). For this

purpose we will present several definitions for BCM, explain the need for BCM and define the exact

scope of this topic.

Chapter 3: The concept of maturity models

The aim of this chapter is to define exactly what a maturity model is and how a maturity model can

be useful in achieving the goal of this research.

Chapter 4: The maturity model to be developed

In this chapter we will lay the foundation for the development of our model. First we will explicitly

state the requirements for the model we are going to develop. Next we will discuss how exactly we

will go about the development of our model and to what aspects we should pay extra attention in the

various steps of the development.

Chapter 5: Draft model

In this chapter we will develop the basis for our final maturity model by establishing a first set-up for

the aspects that determine the maturity of the BCM within an organization. This set-up will form our

initial model and serve as a basis for the execution of the market scan.


A Maturity Model


Chapter 6: Design market scan

Chapter 6 presents the set up of our market scan. First we will explain why we chose to execute the

market scan as a set of interviews. Next we will present how each interview was conducted, the

questions asked and the way these questions were developed. We will conclude this chapter with a

description of the interview group.

Chapter 7: Outcome market scan

Chapter 7 presents a summary of the findings of our market scan. This chapter will give us more

insight in the current state of the BCM within organizations.

Chapter 8: Presentation final model

In this chapter we will present our final model in three steps: first the framework that forms the basis

of our maturity model, next the method to determine the maturity of an organization based on this

model and finally the method to do recommendations based on a certain maturity. The reasoning

behind our approach in developing the model will follow in the next chapter. Therefore, for an

optimal understanding of the model it might be useful to reread this chapter after having read

chapter 9.

Chapter 9: Development final model

In this chapter we will describe the development process that led us to the model as presented in

chapter 8. In addition, this chapter gives a short preview on how we will go about the development of

the model into a tool.

Chapter 10 Validation model

In this chapter we will validate our model against all requirements formulated in chapter 4.

Chapter 11 Conclusions and further research

In this last chapter we will present the main conclusions of our research. Besides this, we will

identify chances for further research based on our findings.

A visualization of this can be seen on the next page:


A Maturity Model


Chapter 1: Introduction

Chapter 2: OverviewBCM

Chapter 4: Outlaydevelopment of the

model

Chapter 3: MaturityModels

Chapter 5: Initial model

Chapter 6: Designmarket scan

Chapter 7: Analysisoutcome market

Chapter 10: Validationmodel

Chapter 11: Conclusions& further

recommendations

PART I : Theoreticalbackground

PART II :Development model

PART III : Validation

definesstep 1-2-3

step 1

step 2

Chapter 9: Developmentfinal model

Chapter 8: Presentationfinal model

step 3

Figure 1.3 Visualization of thesis structure

1.6 Conclusion In this chapter we introduced our research and its objectives, what made us decide to do this

research and the approach we have decided to use. In addition, we have given a brief description o

the scope and the contents of this thesis. The rest of this thesis will describe the results of our

research and the process of researching itself, as described in the previous paragraph.


A Maturity Model


2 Business Continuity Management

2.1 Introduction In this chapter we will introduce the concept of Business Continuity Management (BCM). First we

will present several definitions for BCM and next we will illustrate why there is a need for BCM in

general. Finally we will amplify the exact scope BCM considers and the position it has regarding

related concepts.

2.2 Definition BCM Since we want to study Business Continuity Management in this research, we need to have a clear

image of what this term actually encompasses. The term Business Continuity Management was

introduced for the first time in the end of the 1990's. However, BCM has only recently started to gain

substantial momentum within organizations. Recent incidents like the Y2K threat (Oud, 2000),

(Koch, 2001) and the event on 9/11 (Yankee Group, 2001) have made an important contribution in

this rise of awareness.

A proper definition of the concept we are studying is a prerequisite to define the scope of this thesis,

so let us start with an overview of a few definitions for BCM.

The CCTA (1995-1) states that 'BCM is concerned with managing the risks to ensure that at all

times an organization can continue operating to, at least, a predetermined minimum level'.

The Business Continuity Institute (BCI, www.bci.org) defines BCM as: 'A holistic management

process that identifies potential impacts that threaten an organization and provides a framework for

building resilience with the capability for an effective response that safeguards the interests of its

key stakeholders, reputation, brand and value creating activities.'

Spring Singapore (2005) uses the following definition: 'BCM is a holistic management process of

identifying potential incidents that threaten an organization and the development of plans to respond

to such incidents. It covers a broad spectrum of business and management disciplines, including

risk management, disaster recovery and crisis management.'

Finally, the definition used by Verdonck, Klooster & Associates is: ‘Business Continuity Management

encompasses the management process that aims to prevent severe disruptions in the business and

to protect critical processes against the consequences of disruptions or disasters’.

Although there is no commonly accepted definition for BCM, we can identify some characteristics of

BCM that can be encountered in all the definitions and/or the accompanying explanations.

These characteristics of BCM are:

• The aim of BCM is to ensure the continuity of the business at a certain minimum level;

• BCM initiatives should be directed towards the critical business processes;


A Maturity Model


• BCM encompasses both the prevention of disasters or disruptions and limiting the damage to

business in case of a disaster or disruption, so it's has preventive, corrective and repressive

characteristics;

• BCM is a continuous management process, not a single project.

Since the definition used by VKA encompasses all these elements, we will use this as our research

definition for BCM from now on.

Definition 2.1: BCM

2.3 Need for BCM A description of the need for BCM is already enclosed in the term itself. Organizations occupy

themselves with BCM to assure the continuity of their business. Although the need for continuity of

business exists for just as long as business itself, BCM is a relatively new concept compared to

most other business disciplines. BCM has been developed out of its predecessors disaster recovery,

which was born in the 1960's paired with the rising computerization and later contingency planning

(see paragraph 2.4 for a short explanation of disaster recovery and contingency planning).

Interest in BCM came up in the 1990's, but actually has only gained real momentum over the last

several years. The reason for this is twofold: on one side, an increasing pressure is exerted on

organizations to provide assurance for the continuity of their business processes. This is principally

caused by two changes in the business environment, namely rising competition and higher demands

of customers and increasing regulatory requirements.

At the same time, the assurance of the continuity becomes more and more complex for

organizations. Three changes that have caused this can be identified, namely increasing threats,

increasing supply and demand chain integration and increasing dependency of business processes

on complex information systems (Noakes-Fry & Diamond, 2001), (Leegwater & Reiniers, 2005),

(Leegwater & Ploeg, 2005).

Besides the five changes mentioned above, there is one other change that has influenced the

advent of BCM. Although the advent of process-based approaches (Leegwater & Ploeg, 2005) did

not directly cause the advent of BCM, it did cause a shift in management thinking which enabled the

process focus of BCM.

Below we will amplify all six changes.

2.3.1 Rising competition and higher demands of customers

Rising competition and higher demands of customers, such as the expectation of 24/7 availability of

(digitalized) services make it necessary for organizations to pay extra attention to their continuity

assurance. A disruption of business can have severe consequences such as financial loss and loss

Business Continuity Management encompasses the mana gement process that

aims to prevent severe disruptions in the business and to protect critical

processes against the consequences of disruptions o r disasters.


A Maturity Model


of credibility or goodwill for the organization concerned. Customers can also explicitly demand

certain assurance with regard to the continuity of their suppliers and do so to an increasing extent.

2.3.2 Increasing regulatory requirements

Not only businesses themselves and their customers acknowledge the need for continuity

assurance. The increase in rules and regulations regarding continuity can be seen as another major

driver for paying attention to BCM. Regulatory requirements force organizations to pay more

attention to the continuity of their (business) processes. The requirements of 'DNB' (De

Nederlandsche Bank) regarding Dutch financial institutions, the Health Insurance Portability and

Accountability Act (HIPAA), the Sarbanes-Oxley Act (SOXA) and the regulations for municipalities

regarding the municipal base administration (GBA) 3 are examples of such regulatory requirements.

2.3.3 Increasing threats

The threats that endanger the continuity of a business are increasing. Incidences of terrorism,

disasters, fraud and commercial espionage have increased in recent years. (CCTA, 1995-1) Besides

an increase of the threats themselves, we can also observe an increase in the visibility of the threats

and their consequences. This is largely caused by the extensive media attention. This extra visibility

reinforces the effect that the increasing threats have on the awareness within organizations.

2.3.4 Increasing supply and demand chain integration

Organizations choose to focus more and more on their core activities4 and outsource non-core

activities. This is due to the rising competition, which leads to a need for cost efficiency. This

extension of the supply and demand chains accompanied by the high demands regarding delivery

time, quality and price obliges chain partners to cooperate more intensively. As chain partners

increasingly integrate their processes with each other, the consequences of discontinuity also get

extended. The effect of discontinuity is not limited to one party but can also have consequences for

the entire chain. This has to be taken into account when planning for continuity.

2.3.5 Increasing dependency on complex information systems

Organizations depend more and more on their information systems and underlying infrastructures,

including (data) communication facilities. This rising dependency on IT and other technologies

makes organizations more vulnerable to disruptions in these technologies. An obvious example of

this dependency can be seen in the Y2K threat that caused great commotion within many

organizations and was followed by a substantial rise in BCM activities.

2.3.6 Advent of process based approaches

The need for more continuity played a major role in the development of BCM. Besides that, an

important change in organizational thinking also has to be mentioned. As opposed to concepts like

disaster recovery and information security, BCM focuses on (critical) processes instead of business

functions. This process focus has been enabled by the advent of the process-based approaches,

like Business Process Reengineering/Redesign (BPR), Business Process Improvement (BPI) or

3 Gemeentelijke Basisadministratie, which is Dutch for the municipal basis administration 4 Core activities are the activities by which an organization expects to distinguish itself from its competitors


A Maturity Model


Total Quality Management (TQM) and led to an important shift in organizational thinking.

Organizations started to realize they should focus not only on business functions but also, and

maybe even mainly, on business processes, since processes create the value organizations aim for.

2.3.7 Summary

Summarized, we can state that changes that result in increasing pressures to provide continuity

assurance, together with changes that make it more difficult to assure this desired continuity, form

an impulse that resulted in the advent of BCM. The change in management thinking that led to

process based approaches also was an important enabler for the advent of BCM.

2.4 Scope BCM To make clear what BCM exactly encompasses we will define its exact scope. This will enable us to

determine which aspects fall inside or outside its scope and to determine how BCM relates to other

concepts like disaster recovery, contingency planning and security, as discussed in the next

paragraph.

We can amplify the scope of BCM by stating on which processes, risks and measures it focuses.

2.4.1 The processes: only the critical business processes

BCM aims to ensure the continuity of business. Therefore, it focuses on the critical business

processes, which can be both core business processes and critical supporting processes.

Processes that are not critical also need to be recovered in the end, but not necessarily within a

given (often short) timeframe. Of course their protection and recovery is also important, but it does

not belong within the scope of BCM.

A successful BCM process requires an organization to identify its critical processes and to

determine all resources these processes depend on, including IT systems. However, the focus is not

primarily on these resources, but on the critical business processes. All BCM demands should

therefore be derived from requirements regarding the critical business processes.

2.4.2 The risks: only those that could cause a sudden and serious disrupt ion

Only risks that could result in a sudden and serious disruption of the business are considered as a

part of BCM. These may be any kind of risk, ranging from flood to a failure of suppliers and from

fraud to unavailability of staff.

Risks that do not satisfy this description are not considered to be within the scope of BCM. Risks

outside the scope of BCM are either not sudden or not severe enough.

Risks that are not sudden, but more long term, fall outside the scope of BCM. Although such a risk

may have a large impact, management has time to identify and evaluate the risk and take

appropriate measures. Threats formed by competitors are examples of such risks.

Risks that are not severe enough to endanger the continuity of business do not belong to the scope

of BCM either. We don't claim that these risks do not deserve attention, but BCM only focuses on


A Maturity Model


the major threats to ensure continuity of business. Less severe threats must be dealt with

somewhere else within the organization if necessary.

2.4.3 Continuity measures

BCM concerns both preventing disasters and disruptions and limiting the impact of a disaster or

disruption that takes place despite of preventive measures. Therefore BCM encompasses different

kinds of measures:

1. Preventive measures, which can either take a risk away or decrease its chance;

2. Repressive measures, which can limit the damage a risk in case it manifests;

3. Corrective measures, which can correct the damage caused by a manifested risk.

Graphically, the difference between the various measures can be shown below:

Incident

Loss to organisation

Damage

Threat

Preventive Repressive Corrective

Figure 2.1: Measures to handle risks

Besides those concrete measures, organizations have two other possibilities:

4. To either accept the risk (acceptance);

5. Or to transfer the negative consequences of a risk to another party (transference).

(Van den Akker, 2002)

This means that an organization has five ways to handle identified risks when it is executing a BC

analysis. The different options do not necessary rule each other out; they can also complement each

other.

2.5 Related areas of expertise Now we know the scope of BCM, it is easier to see how BCM relates to three other concepts that

are often mentioned in relation to BCM: disaster recovery, contingency planning and (information)

security.

2.5.1 BCM versus disaster recovery and contingency planning

The graphic below shows the difference between disaster recovery, contingency planning and

business continuity planning.


A Maturity Model


Disaster Recovery

Contingency Planning

Business ContinuityManagement

Measures

Focus

Processes

IT

Corrective&repressive

preventive

Figure 2.2 Disaster Recovery, Contingency Planning and Business Continuity Management

The first attempt to manage continuity was made by disaster recovery. Disaster recovery as it was

originally developed can be defined as ‘The process whereby an enterprise would restore any loss

of data in the event of fire, vandalism, natural disaster, or system failure.’(Hipaa Basics, 2005) This

focused mainly on the continuity of IT facilities. It supplemented the preventive measures taken as

part of IT security. Disaster recovery mainly provides fallback systems, which can be used in case of

failure of a system.

Slowly people started to realize that solely the existence of fallback systems does not assure

continuity of business. That is why contingency planning showed up. Contingency planning has a

broader focus than only IT and provides actual plans for how to handle in case of an incident.

Although contingency planning sometimes also encompasses some preventive measures, the focus

is mainly on corrective and repressive measures. There is not one generally accepted definition for

contingency planning; the defined scope of contingency planning varies considerably among various

descriptions. However, what can be settled is that contingency planning tries to handle unexpected

events that threaten organizations and that it uses a broader focus than disaster recovery, which

focuses only on data and IT.

It was not until the advent of BCM that continuity was actually assessed out of the focus of the

critical business processes. In addition to that, corrective and repressive measures where integrated

with the preventive measures, like security measures, to form one integral continuity management

approach.

2.5.2 BCM versus information security

Information security and BCM partly overlap. Not all BCM measures concern information security

and not all information security measures are part of BCM.


A Maturity Model


Information security ensures the availability, integrity and confidentiality of information. Information

security measures are mostly preventive. BCM encompasses not only preventive measures, both

also corrective and repressive measures5. Preventive BCM measures can concern information

security, however, not necessarily all preventive business continuity initiatives are related to

information security. They can also focus on resources other than IT, for instance on the building

itself (physical security).

In addition, not all information security measures are taken solely for the continuity of only the critical

business processes. Information security has a broader scope than only those preventive IT-related

measures that are part of BCM. The integrity of the salary administration is not necessarily critical

for the business continuity, but eventually it has to be assured. This is part of IT security, but

obviously does not belong to the scope of BCM.

Graphically we can show the overlap of BCM and IT security like this:

All processes

All functions Overlap

Critical processes

ITsecurity

BCM

ITsecurity

Figure 2.3: Overlap between IT security and BCM

Since information security and BCM overlap, the tuning of both is essential.

2.6 Conclusion In this chapter we introduced the concept BCM. We concluded that BCM is a relatively new

concept, which followed other approaches to assure the continuity of an organization, like disaster

recovery and contingency planning. BCM distinguishes itself from such approaches mainly by its

focus on the continuity of critical processes instead of the continuity of certain functions within the

organization (like IT) and by evaluating both preventive and repressive and corrective measures

(and acceptance and transference of risks).

5 (and acceptance and transference of risks)


A Maturity Model


BCM arose as a consequence of both the increasing pressure to provide continuity assurance and

the increasing difficulty associated with this. In addition to that, the advent of process-based

approaches was an important enabler for the development of the BCM concept.

Every time we use the term BCM in this thesis we will refer to ‘ the management process that aims

to prevent severe disruptions in the business and to protect critical processes against the

consequences of disruptions or disasters.’ The scope of this management process can be defined

by the processes (only the critical business processes), the risks (only that that could cause a

sudden and serious disruption) and the measures (both preventive, corrective and repressive

measures, and the transference and acceptance of risks) it focuses on.

This introduction on BCM provides the theoretical base for the research this thesis is about. In the

next chapter we introduce the other important concept in this research, namely the maturity model.


A Maturity Model


3 The concept of maturity models

3.1 Introduction The purpose of this research is to develop an instrument to efficiently assess the BCM process

within an organization. From the objectives stated in chapter 1, we require that this instrument must

take the form of a maturity model.

The aim of this chapter is to define exactly what a maturity model is and how a maturity model can

be useful in achieving the goal of this research.

After defining maturity models and examining their usefulness in paragraph 3.1, we will evaluate the

applicability of a maturity model specifically for BCM in paragraph 3.2. Subsequently we will identify

some important design issues, which we will take into account when we develop our own maturity

model in chapter 5 to 9.6

3.2 The concept 'maturity model' The concept of a maturity model is widespread within management theory. Many different maturity

models, with varying focuses, exist. Despite these varying focuses, most maturity models have one

important common feature: They represent the maturity of one or more specific processes within an

organization. The scope of a maturity model can vary from a constituent process or a process within

a certain function (e.g. software development Capability Maturity Model, CMM (Paulk, 1995)), to an

integrated whole of the main processes that form the business (Instituut Nederlandse Kwaliteit –

model, INK (Titulaer, 2001)). Most probably, the chosen scope will have implications on the design

of the maturity model. We should bear that in mind when evaluating different maturity models.

This notice of the considerable differences between the various maturity models is important to keep

in mind. Having stated this, we will now try to formulate a standardized characterization of a maturity

model, based on existing maturity models. We will introduce the maturity model as a concept by

formulating a definition and the main objectives.

3.2.1 Definition maturity model

The CMM, probably the best-known maturity model worldwide, defines the term 'maturity' as (Paulk,

1995) ‘the extent to which a specific process is exactly defined, managed, measured, controlled and

effective’.

A maturity model is based on a staged structure of maturity levels, each building on the previous

level. Hence, the line composed of the various levels along which an organization matures, is a

6 We focused mainly on: the Gartner Security Process Maturity Model (Dang Van Mien, 2001), the KPMG World

Class IT model (Delen, 2000), The IT service CMM (Niessink, Clerc and Van Vliet, 2002), the software

development CMM (Paulk, 1995), the INK-model (Titulaer, 2001), The Complete Public Domain Business

Continuity Maturity ModelSM (Virtual Coorporation Inc., 2004) and the Gartner BCP Maturity Model (Mingay,

2002).


A Maturity Model


cumulative one. (If an organization is positioned in level three, it not only meets the requirements of

level three, but also those of level two and one).

Since a maturity model aims to provide a simplified and easily communicable reproduction of reality,

it will generally distinguish no more than about five or six different levels of maturity. The principle

behind the different levels is that an organization develops new practices and processes, from which

it learns, and from which it can subsequently optimize these practices and processes to move on to

the next level. Most maturity models are designed in such a way that an organization cannot skip a

level, although not all specialists agree on this statement (Mingay, 2002). Simple models only

describe the various maturity levels; more extensive models also identify practices that can bring

organizations from one level to the next.

This description might suggest organizations should always strive for the highest maturity level.

However, this is not necessarily true. Although the original developers of maturity models often see

the highest level as the ideal situation one should strive for, in the actual application of the model it

is usually accepted that an organization can decide to aim for a level below the highest level. For

instance, if an organization only has one software developer that incidentally develops a relatively

straightforward program, the organization can decide it is sufficient that its software development

process is standard and consistent. The process does not need to be predictable and continuously

improving. In other words, an organization can, based on its needs, choose to set a target maturity

level, which is below the highest maturity level.

Based on the description of a maturity model by Gartner (Mingay, 2002) we can formulate a

definition of a maturity model. To explain the term 'maturity', we added the CMM definition of

maturity to our definition.

Definition 3.1: Maturity Model

3.2.2 Objectives maturity model

We can see many similarities between the goals stated by the maturity models we analyzed for this

research. In general, most maturity models have one or more of the following objectives:

Definition 3.2: Objectives Maturity Model

A maturity model is a staged structure of maturity levels, which defines the extent

to which a specific process is defined, managed, me asured, controlled and/or

effective, assuming the organization develops and a dopts new processes and

practices, from which it learns, optimizes and move s on to the next level, until the

desired level is reached.

• Provide an organization with insight into the maturi ty of a specific process within

the organization

• Enable an organization to compare the maturity of th is process with processes of

other organizations or with best practices

• Provide an organization with a roadmap for improving this process

• Enable an organization to assure its customers about the quality of this process


A Maturity Model


3.3 Justification for the use of a maturity model f or BCM As concluded above, a maturity model can be useful for a (management) process if we want to

assess ‘the extent to which a specific process is exactly defined, managed, measured, controlled

and effective’, based on the thought that an organization has to grow to a certain level before it

reaches maturity. Given the wide range of management processes for which the concept of a

maturity model has proven to be a useful analysis instrument, it is no more than logical to evaluate

the possible use of a maturity model for BCM. Especially for a management process as

comprehensive and complex as BCM, the reasoning that an organization learns to define, manage,

measure and control this process and make it effective, seems justified.

However, the fact that a maturity model could be useful for the analysis for BCM is not enough to

justify the development of one for the purpose of this specific research. In chapter 1 of this thesis,

we defined the objectives of our research as follows:

'To develop a maturity model for BCM based on which [1] the current state of BCM within an

organization can be assessed and [2] recommendations to improve this state can be given'

Although our objective already explicitly states the model should be a maturity model, it is useful to

assure that the objectives of a maturity model actually fit the purpose for this research.

When we look back at the objectives and the description of a maturity model as described in 3.2, we

can see a clear match. A maturity model can 'provide an organization with insight into the maturity of

a specific process within the organization', and thus assess the current state of BCM within an

organization [1]. Furthermore, it can also 'provide an organization with a roadmap for improving this

process' and thus give recommendations to improve this state [2]. Therefore, we can conclude that

developing a maturity model would indeed be a suitable approach to reach the objective of this

research.

Since we have decided to use a maturity model, it is important to be aware of an often-mentioned

point of criticism regarding the concept of maturity models. It is often claimed that a maturity model

only measures the quality of the process itself and not the outcome of the process. Although a good

process has a larger chance of resulting in a good outcome than a bad one, it cannot guarantee a

good outcome. The only way of knowing for sure the outcome is what it should be, is by measuring

the outcome itself. Why then measure the process instead of the outcome itself? Of course

measuring the process doesn't substitute measuring the outcome. For instance, the fact that one

measures the maturity of its software development process doesn't mean there is no need to assess

the quality of the software itself anymore. However, assessing the process instead of the outcome

offers an important advantage. Assessing the outcome of a process can signal the outcome isn't

what it should be, but it cannot signal why. If we assess the process itself, we can see how the

outcome is achieved and thus what can be done to improve this process and hence the outcome.

When defining our research problem, we already decided to focus on the BCM process itself instead

of on its outcome. Besides the reason mentioned above, we also identified another reason to focus

on the process. We concluded the process outcome of BCM, Business Continuity, would be much

more difficult to measure than that of the process itself. We assume that a more mature BCM


A Maturity Model


process leads to better BC, and thus a maturity model can be used for BCM as an instrument to

predict the ability of an organization to assure BC.

We can conclude that a maturity model is a useful instrument for both evaluating the quality of BCM

and identifying opportunities for improvement. In the next chapter we will look more precisely at the

exact objectives for this BCM maturity model.

3.4 Evaluation of existing maturity models & design options

As we stated before, many different maturity models that represent the maturity levels of various

processes have been developed in the history of management theory. The collection of all existing

maturity models is too extensive to provide a complete overview. However, an evaluation of a few

maturity models could give us insight in what a maturity model can contribute and the options we

may choose from when we design our BCM maturity model. We chose to evaluate three well-known

maturity models, namely the CMM (we will focus on the software development CMM since this was

the first one developed, but other CMM's like the IT service CMM have a comparable design), the

INK and the World class IT model.

We evaluated these particular three models since all three are well known and often used and at the

same time have a considerably different focus and design. By evaluating these three models, we

can not only gain more insight into the practical use of maturity models, but also identify the different

design options we have when developing our maturity model.

Appendix A describes a brief evaluation of all three maturity models. From our comparison of these

three models, we determine the following design options:

• The number of maturity levels

All three models distinguish five different levels of maturity. However, most organizations will

probably be concentrated within levels one to three and organizations will rarely reach level 5.

This is a point of criticism that is often heard, especially regarding the CMM.

• The number of areas on which maturity is determined

The CMM assigns a single maturity level to the whole process it focuses on. The process is for

instance either repeatable or managed, but not partly repeatable and partly managed. The world

class IT assigns a separate maturity level to five different areas, namely exploitation, incidents &

problems, changes & configuration, service delivery, development & maintenance and strategy

& policy. The INK model identifies no less than nine areas which all can have their own maturity

level.

The simplicity of the CMM is often seen as one of its main strengths. It is not without a reason

that this model is the best known and most often used maturity model of all. By only showing

one hierarchy of levels along which the process matures, it makes clear that there is a certain

order in the activities one should develop and therefore all sub processes are intertwined.

Nevertheless, integrating all sub processes into one line along which the total process matures

while still offering a valid representation of reality and without loosing valuable information is an


A Maturity Model


extremely hard thing to do. Possibly this is not feasible for every management process.

However, for communication objectives, one should always strive for such simplicity, as long as

the model still fits reality.

Nonetheless, having more areas in assigning maturity also has its advantages. Simplifying a

model also means loosing valuable information. If process C, which should actually only be paid

attention to after process A and B are optimized, already has been optimized in a practical

situation, but process A is not, you would loose this information in a model designed like the

CMM. However, if you assign a maturity separately to process A-E, you will retain this

information and be able to incorporate it in your assessment and advice.

When deciding on the number of areas to which a separate maturity is assigned, one should

balance the information one could loose by simplifying the model and the simplicity and

understandability one could gain. The more different areas, the less the model can serve its

primary goal: providing clear insight in the maturity of a process. The INK model for instance, is

well suited as a base for making comparisons between organizations, but doesn't offer the clear

view the CMM, and to lesser extent the World Class IT, do.

• Extra design dimensions

It is possible to add extra dimensions to a maturity model besides the number of areas maturity

is assigned on and the number of maturity levels. For instance, the world class IT distinguishes

two different focuses. It assigns a maturity level to each area two times, once from a supplier's

point of view, and once for the user's focus. This makes the model slightly more complex. On

the other hand, the tuning of the supplier and user side is exactly what makes this model so

useful, so in this particular instance the extra complexity could be justified.

If the value added by adding an extra dimension, like the focus, is large enough to justify the

extra complexity, one may choose to add an extra dimension to the model besides the number

of maturity levels and areas the maturity is determined on.

We have to take these three design aspects into account when we develop a maturity model.

3.5 Conclusion In this chapter, we analyzed maturity models as a concept. We defined a maturity model as 'a

staged structure of maturity levels, which defines the extent to which a specific process is defined,

managed, measured, controlled and/or effective, assuming the organization develops and adopts

new processes and practices, from which it learns, optimizes and moves on to the next level, until

the desired level is reached.' Based on the objectives of a maturity model, as identified in paragraph

3.2, we concluded that such a model indeed is well suited for achieving the objectives of our

research.

When we'll develop a maturity model for BCM, we still need to make some decisions about the

design of this model. As ascertained in 3.3, different choices can be made for certain design aspects

of the maturity model, as the number of maturity levels or number of areas on which the maturity is

defined. Those different choices have different advantages and disadvantages.


A Maturity Model


In the next chapter we will state the requirements of the model to be developed and determine which

steps to take in our development process.


A Maturity Model


4 The maturity model to be developed

4.1 Introduction In the two previous chapters we introduced both the concepts of BCM and maturity models. In the

second part of this thesis, we will develop the model as described in the goal of this research. In this

chapter we will lay the foundation for the development of this model.

First we will explicitly state the requirements for the model we will develop. A logical next step is to

look at existing models for BCM and evaluate whether there already is an existing model that meets

these requirements. After concluding it is necessary to develop a new model to meet our

requirements, we will discuss how exactly we will go about the development of our model. The

development steps we distinguish in this chapter will determine the content of the next five chapters.

4.2 Model requirements The first step in developing the model for BCM, is to determine the exact requirements the model

has to meet. We agreed on the following requirements for the model to be developed:

1. The most important requirement for our model is that it should be able to give a substantiated

judgment of the maturity of BCM within a given organization. Hence, the model must be able to

determine the maturity of the BCM based on measurable and distinguishing criteria. Based on

the maturity of the BCM process and the assumption made in paragraph 1.3 (a mature BCM

process leads to good BC), our model can thereby judge the BC capacity of an organization;

2. The maturity model should be easily communicable, e.g. by being easily graphically presentable

and explainable. The main purpose of our model was namely to communicate the maturity of its

BCM within an organization;

3. It must be possible to give recommendations on how to improve the maturity based on the

determined maturity level.

Many maturity models give some recommendations. However, often these are just some vague

pointers that seem logical but in practice these are hard to translate into concrete actions. To be

applicable in practice, recommendations need to be action based. Therefore, we aim to develop

a model that can give action-based recommendations based on the current maturity; 7

4. The model has to be suitable for benchmarking or making other relevant comparisons between

organizations or parts of an organization;

5. The model has to be based on a generally accepted best practices methodology.

7 As stated before, only the method that determines the ideal growth path and thus identifies the

recommendations for an organization falls inside the scope of this thesis. The exact recommendations will not be

described in this thesis.


A Maturity Model


There are three reasons for establishing this requirement. First of all, it is easier to derive action-

based recommendations if the assessment is done based on a certain methodology. Second, it

provides a solid foundation for developing the model, which makes it easier to check whether

the model is correct and complete than when the aspects of the model are selected randomly.

Third, using a generally accepted methodology as a base for the model makes it easier to

explain and justify the model to originations you would want to assess using the model.

6. The model should include an assessment tool that determines the maturity model.

This way the model becomes a practical and usable tool and does not remain a mere theoretical

concept. Since a model always is a simplified reflection of reality, the assessment tool will never

completely substitute an analysis by an expert. However, it can provide a basic insight into

specific practical cases relatively easily. This insight could serve as a starting point for further

analysis. This way, the model serves as an initial scan. For this purpose, applying the

assessment tool should not take too much time. In the discussion with the consultants it was

concluded that this quick scan should take at most four interviews of one and a half hour. 8

Summarized, the requirements can be formulated as:

1. Substantiated judgment of BCM maturity;

2. Easily communicable outcomes;

3. Producing action based recommendations;

4. Suited for comparisons;

5. Based on a generally accepted best practice methodology;

6. Easily applicable assessment tool;

4.3 Requirements versus objectives We can compare the requirements as mentioned above to the objectives of a maturity model. This

way we can determine which requirements are logically met by the nature of a maturity model and to

which requirements we have to pay extra attention. In chapter 3 we have defined the following

objectives of a maturity model:

a) Provide an organization with insight into the maturity of its own process

b) Enable an organization to compare the maturity of its process with processes of other

organizations or with best practices

c) Provide an organization with a roadmap for improving its process

d) Enable an organization to assure the quality of the process to its customers

If we compare our requirements to these objectives, we can draw the following conclusions:

1. Substantiated judgment of BCM maturity – A proper BCM maturity model provides an

organization with insight into the maturity of its BCM process (I) and thus should give a

8 As stated before, this quick scan falls outside the scope of this thesis. There will only be described how this

quick scan is derived from the model.


A Maturity Model


substantiated judgment of its BCM maturity.

2. Easily communicable outcomes – A maturity model should be able to provide such outcomes,

based on the first objective of maturity model (I) stated above.

3. Producing action based recommendations - Recommendations can be done based on a

maturity model, as stated in the third objective (III). However, the addition 'action-based' to the

third requirement deserves extra attention, since, although most maturity models provide

recommendations, these are rarely action-based.

4. Suited for comparisons - Being suited for doing comparisons is also an objective for a maturity

model, as in the second objective (II).

5. Based on a generally accepted best practice methodology – A maturity model need not be

based on a generally accepted best practice methodology. However, it is possible to use a

generally accepted best practice methodology as a basis for the design of the various maturity

models.

6. Easily applicable assessment tool – An assessment tool is not necessarily coupled to every

maturity model, but it is possible to develop an assessment tool that can determine the place of

a given organization within the maturity model we will build.

To summarize, we can state that by developing a well designed maturity model, we will develop an

instrument that can give a substantiated judgment of BCM maturity (req. 1), produces easily

communicable outcomes (req. 2) and recommendations for improving the process (req. 3) and is

suited as a basis for making comparisons (req. 4). We have to pay extra attention to several aspects

when developing the model, which are not logical characteristics of a maturity model: we have to

make sure that the model is based on some best practice methodology, the recommendations are

truly action based and we have to couple a quick scan to the model for assessing the maturity of an

organization.

4.4 Existing models Before we begin developing our own model, we have to check whether there are existing models

that meet our requirements, if necessary with some small adjustments.

When searching for such models, we found two maturity models for BCM. The Complete Public

Domain Business Continuity Maturity ModelSM (which we will refer to as the "BCMM" from now on)

developed by the Virtual Corporation (Virtual Coorporation Inc, 2004) and the Gartner BCP Maturity

Model (Mingay, 2004), which is based on the maturity model of COBIT.

4.4.1 BCMM

The Virtual Corporation Inc (2004) states that the BCMM has been developed as a tool to

'objectively and consistently measure the organization's disaster readiness or state-of-

preparedness. The BCMM states the following as the primary goals to be achieved:


A Maturity Model


1. Provide a diagnostic tool for objective evaluation of business continuity program initiatives

2. Generate consistent data from which meaningful benchmark analyses can be drawn

3. Answer the following key questions for senior management:

a) Where are we now?

b) What is the target we are shooting for?

c) What evolutionary path do we follow to get there?

The BCMM distinguishes six different maturity levels regarding the BC program. Levels one to three

represent organizations that have not yet completed the necessary Program Basics needed to

launch a sustainable Enterprise BC program. Level 4 to 6 represent the evolutionary path of the

maturing Enterprise BCM program. The BCMM defines eight corporate competences. These

competences together determine the maturity of an organization.

Although this model contains a lot of useful information, it does not match our requirements stated in

4.1. The lag between the BCMM and the model we aim to develop lies within the different goals of

the models. The BCMM is mainly developed as a tool for evaluation, whereas we also want to be

able to give concrete recommendations. The BCMM is less suited for that goal. This can - among

others things - be seen in the fact that the BCMM identifies characteristics of organizations that

belong to a certain maturity level, which are not necessary practices that lead to this maturity level.

Instead of practices that lead to a higher maturity, these characteristics can also be consequences

of being at a certain maturity level. For instance, one can imagine that executive management

commitment can contribute to the maturity of the BCM. However, being an industry leader seems

more like a consequence of a mature BCM instead of the other way around. Since we want our

maturity model to provide a foundation for action-based recommendations, we want to base the

maturity on the activities an organization should perform.

Being able to do action-based recommendations was one of the reasons for the requirement that the

model should be based on a best practice methodology. BCMM is based on best practice, but not

on a generally accepted best practice methodology. There's no logical step-wise process or

methodology that visibly underlies this model.

So if we look back at the requirements, BCMM does not conform to the fourth and sixth requirement.

4.4.2 Gartner BCP Maturity Model

The purpose of the Gartner BCP Maturity Model is to help organizations (Mingay, 2002)

1. Grade the BCP processes and practice;

2. Enable senior management to appreciate what is required to improve the enterprise's BCP

position;

3. Complete a gap analysis so realistic targets can be set;

4. Provide a basis for peer-group comparison and establishment of industry standards.

The different levels of maturity that this model identifies are based on the levels of the COBIT

maturity model, which at their part are based on the CMM maturity levels. Gartner identifies 19


A Maturity Model


individual process and practice areas that must be assessed to measure an enterprise's BCP

maturity.

The criticism voiced on the BCMM also applies to this model. The Gartner BCP Maturity Model does

not identify real action-based recommendations and is not based on a best practice methodology.

4.4.3 Appropriateness existing BCM maturity models for purpose of our research

We can conclude that neither of the two existing maturity models for BCM meets all requirements

stated in paragraph 4.2. Furthermore, the gaps between our requirements and these models are

substantial enough to conclude it's not possible eliminate those lags by making just a few

adjustments. Therefore we have decided to develop our own maturity model for BCM.

Although these two models are not suited for the purpose of our research, we could use them as

useful inputs for the development of our own model.

4.5 Developing our own model 4.5.1 Chosen approach

In 4.4 we have concluded that, although we did find two well thought-through maturity models for

BCM, there is no existing model that matches all our requirements. Despite that, we can use some

valuable information form these two models as a theoretical base for developing our model. Besides

these models, there are many enumerations of best practices, descriptions of methodologies and

quick scans (which at their part are based on best practices too) that contain information on what is

important in a good BCM process. All this information can be used as a theoretical foundation on

which we can develop our own maturity model.

So how are we going to develop this model? First of all, as stated above, existing literature offers

enough information to develop a draft version of our model. We can use existing methodologies and

standards to compose or choose the best practice methodology our model must be based on.

However, we want to develop a model that fits the practice and not just the theory. Therefore, we

make our draft model fairly general and use it as a basis for a market scan that assesses BCM in

organizations in practice. The outcome of this scan can be used to work out and improve the model,

and to develop the end product of this research. By developing a draft model on existing best

practices, we can take advantage of prior research and need not start form scratch. This will provide

a richer foundation for the model and give us the chance to use the time available for this research

more productively.

Summarized, we decided to take the following four steps:

Step 1: Initialmodel

Step 2:Market scan

Step 3: Finalmodel

Step 4: Addquickscan &recommen-

dations

Figure 4.1: Steps in development process


A Maturity Model


The four steps as shown above ask for some further explanation.

4.5.2 Step 1: Draft model

First we will develop a draft model based on existing literature. This model will lay out the structure

for the final model. Our draft model will select several areas on which maturity will be determined

and for each area define the aspects that would determine the maturity level. These aspects should

be based on some best practice methodology.

In this first step we will thus choose the number of areas maturity is determined on. However, this is

just a temporary choice, which might be changed during the development of the final model.

No maturity levels will be used in the draft model. The reason is that organizing the aspects into

maturity levels and thereby translating information into a theoretical model should not be done until

the end of the development stage. The fact is that this simplification will enforce certain rigidities and

will possibly eliminate information in a stage in which everything should still be open.

The construction of this draft model will be described in chapter 5.

4.5.3 Step 2: Market scan

Next we will conduct a market scan to gain more insight in how BCM is organized in practice and in

what actually is important in determining the maturity of BCM. This market scan will be based on the

draft model developed in step 1. In this market scan we hope to discover what aspects of the draft

model are actually distinguishing in determining BCM maturity and what levels of BCM maturity can

be distinguished based on these aspects. We also hope to be able to assess whether the basis

offered by the draft model is the right one for our model and if not, what the basis of our model

should look like.

Chapter 6 will describe the set up of this market scan; chapter 7 will present the main findings.

4.5.4 Step 3: Final model

The last step in creating our model is to develop the final model based on the outcomes of our

market scan.

We will build a structure of maturity levels, which can position organizations based on the quality of

their BCM. For this purpose we will reassess the choice made in the draft model regarding the

number of areas on which maturity is defined. Besides this, we will make our choice regarding the

two other design options, the number of maturity levels and possible other dimensions.

In addition to the development of this structure (which forms the main part of our model), we will also

develop a generic growth strategy that determines the ideal growth path for an organization, given

their current maturity. Finally we will also determine how we will base our quick scan on this model.

Chapter 8 will present the resulting final model. Chapter 9 will explain how and based on what

considerations we developed our model.


A Maturity Model


4.5.5 Step 4: Add quick scan & recommendations

In steps one to three we have developed our scientific model. To make it also a practically usable

tool, we need to add two things: a quick scan that can be used to determine the maturity of an

organization and recommendations that can help an organization to reach a higher maturity level.

We have already laid the foundation for both in the previous step, in this step we will actually

develop both the recommendations and the quick scan, which, as stated in this chapter, should be

action based.

The actual quick scan and recommendations will be developed exclusively for VKA and thus will not

be part of this thesis. However, in chapter 9 we will give some limited insight in the development

process of both.

4.6 Conclusion In this chapter we formulated the following requirements for the model we will develop in this

research:







We concluded that by developing a maturity model, we automatically meet several of these

requirements. We do have to pay extra attention to the fact that the recommendations should be

action-based and the model has to be based on a generally accepted best practice methodology.

Furthermore, we have to elaborate our model into an easily applicable assessment tool too.

We justified the development of our own model by concluding that no model that matches all our

requirements exists yet. The two evaluated BCM maturity models offer some valuable information

for the development of our own model, but the gap between those models and the settled

requirements is too large to use one of those as a starting base for our research.

We concluded this chapter by settling the development process for our model. We distinguished the

four steps as shown in figure 4.1, namely (1) 'Initial model', (2) 'Market scan', (3) 'Final model' and

(4) 'Add quick scan & recommendations'.

This development process determines the content of the rest of this second part of the thesis. As

stated in paragraph 4.6, chapter 5 will describe the development of the draft model, chapter 6 and 7

the set up for and the outcomes of the market scan and chapter 8 and 9 respectively the final model

itself and its development. Step 4 falls outside the scope of this thesis. 9

9 However, chapter 9 will offer some brief insight on how we will go about the development of the quick scan and

the action based recommendations


A Maturity Model



A Maturity Model


5 Draft Model

5.1 Introduction In this chapter we will develop the foundation for our final maturity model by establishing a first lay

out for the aspects that determine the maturity of the BCM within an organization. This lay-out will

form our draft model and serve as a basis for the market scan.

In paragraph 5.1 we start by describing how exactly we are going to develop the draft model. Next

we establish the areas to which the model assigns the maturity levels. In the last paragraph we

elaborate on those areas by defining the aspects that would determine the maturity of each given

area.

5.2 Development process for draft model If we look back at chapter 3, we see that an important choice regarding the aspects that determine

maturity is 'the number of areas on which maturity is determined'. Do we choose to let the analysis

performed by our model result into one maturity determination, or do we distinguish various areas

for which we determine separate maturities?

We choose to develop a model with about four or five areas on which maturity is determined. This is

a number that one can comprehend and communicate easily, without sacrificing too much of the

added value of the model. Of course it would be better if all aspects would fit in one 'evolution line’

and still represent reality sufficiently. However, as already stated in chapter 3, this is very hard and

not always possible. By focusing on four or five instead of one area we can collect more information

and hopefully develop a logical set of maturity levels for each of them. Later in this research, we

might be able to integrate two or more areas into one area, if we conclude that the various steps

towards maturity on the different areas are taken simultaneously. We can only conclude this after we

have executed the market scan. Until then we will use a model with four or five different areas with

their own path to maturity.

Now that we have decided to develop four or five areas to which maturity gets assigned, the next

question is subsequently, how we should compose these areas. Since we stated that our model

should be based on a best practice methodology, it would be logical to base these areas on the

different steps within such a methodology. This means the first thing to do is to select a methodology

and arrange the phases within this methodology in four or five areas. When grouping the areas, we

should take the following guidelines into account:

• Each area should represent a clearly separated stage within the methodology;

• Each area should be homogenous enough to be assigned one single maturity level to;

• The maturity of the individual areas should be independent of each other.

As soon as we have determined the areas, we have a framework for the aspects that together

should determine maturity. The next step is thus to distinguish sufficient aspects for each area to be

able to determine the maturity of this area. These aspects can be selected from the existing


A Maturity Model


literature about BCM, which means all quick scans, best practices, methodologies and models that

are available to us.

Summarized, we will take the following steps in developing our draft model:

1. Select best practice methodology on which our model will be based (paragraph 5.3);

2. Form four or five areas based on this methodology for which our model will determine the

individual maturity level (paragraph 5.4);

3. Elaborate the areas by distinguishing aspects that together can determine the maturity of an

area. We will do this by first identifying relevant aspects and subsequently organize the aspects

into the different areas (paragraph 5.5).

The graphic representation of these steps can be seen below.

Step 1 Step 3Step 2 Step 4 Step 5 Step x-1 Step x

I. Best Practice methodology

Area 1 Area 2 Area 3 Area 5Area 4

II. Areas to which maturity isassigned

Aspect1

Aspect9

Aspect4

Aspect6 Aspect

7Aspect5

Aspect2

Aspectx-1

Aspect8

Aspect3

Aspectx

Select bestpractice

methodology

Identify aspects

Aspect1

Aspect9

Aspect4

Aspect6 Aspect

7Aspect5

Aspect2

Aspectx-1

Aspect8

Aspect3

Aspectx



Organize aspectsinto areas

III Aspects organized in areas

Figure 5.1: Steps in development process draft model


A Maturity Model


5.3 Selection of the best practice methodology To be able to establish the areas, we first need to choose some stepwise methodology (step I).

Although there is not one generally accepted best practice methodology, we can see that the

different methodologies are very similar. We analyzed seven methodologies. An overview of these

can be found in appendix B. Not all methodologies distinguish the same phases within the BCM

process. However, a closer examination shows us that all methodologies describe the same

sequence of activities that should be performed, whether or not formulated similar to the activities

below.

Among all methodologies we can see some kind of general agreement that the activities

enumerated below should be performed as part of the BCM process. This resulted in a methodology

that comprises the following steps:

1. Initiate a BCM initiative, develop a policy, assign responsibility, etc.;

2. Perform a business impact analysis (BIA);

3. Perform a risk analysis (RA);

4. Select the BC measures;

5. Develop the complete BC Plan;

6. Implement the preventive measures and prepare for the corrective and repressive measures;

7. Exercise, audit and maintain the BC initiative;

These seven steps form a cyclic process. The seventh step can provide feedback for all other steps

and thus cause another loop.

Several methodologies do not describe the initiation of a BC initiative as the first step, but see this

as a part of the activity ‘program management’. As opposed to the initiation activity, program

management is an activity that should be performed during the entire BC cycle. Besides the

activities ‘development of a policy’, ‘the assignment of responsibility’ and more activities that form

the initiation step, program management also encompasses other things, like awareness creation

and monitoring of the BC initiative. Since we find such activities important for BCM as well, we

decided to replace the first step by the activity program management, which is performed during the

entire BCM cycle. This results in the following methodology:


A Maturity Model


1. Program managament

2.BIA

3. RA

4.SelectionBC

measures

5.Develop-ment

BC plan

6.Imple-mentation

plan

7.Exercise,audit andmaintain

Figure 5.2 BCM methodology used as basis for draft model

This methodology will serve as the base for the model we will develop and the coupled quick scan

and recommendations.

5.4 Determination of the areas within our model Now we have selected our best practice methodology, we can determine the various areas to which

a maturity level will be assigned (step II in the development of the draft model). Although these

areas need to be based on the various steps within our methodology, we do not necessarily need to

translate each step into a separate area. In 5.2 we formulated the following guidelines regarding the

composition of the various areas:

• Each area should represent a clearly separated stage within the methodology;

• Each area should be homogenous enough to be assigned one single maturity level to;

• The maturity of the individual areas should be independent of each other.

All steps in our methodology automatically meet the first guideline. We can also assume that all

steps are homogeneous enough to be assigned one single maturity level. However, it is not

probable that the maturities of all steps are entirely independent. The risk analysis, the business

impact analysis and the selection of BC measures are strongly related. It is not very probable that an

organization is substantially more mature regarding one step than the other two. Therefore, we will

integrate step two, three and four into one area, which we will call ‘analysis’. This way, we have five

different areas left, which matches our objective of a division in four or five areas (as stated in

paragraph 5.2).


A Maturity Model


1. BCM program management (step 1) – How is BCM rooted within the organization, who is

responsible for BCM, is the management committed, how aware are the employees of the need

for BCM, etc.

2. Analysis and determination approach (step 2-4) –The identification of the critical processes and

their dependences, establishing continuity norms, performing a Business Impact Analysis (BIA),

performing an Risk Analysis (RA) and selecting a strategy

3. Development of the BC Plan (step 5) – The actual writing of all the plans that together form the

BC-Plan

4. Implementation (step 6) - Implement the preventive measures and prepare for the corrective

and repressive measures

5. Maintenance (step 7) - Exercise, audit and maintain the BC initiative

Graphically it can be represented like this:

1. Program managament

2. BC Analysis

3. Developmentplan

4.Imple-mentation

5.Maintenance

Figure 5.3 Areas within our draft model

5.5 Determination aspects within the areas Having defined the five areas, the next step (step III) is to assign several aspects to each area,

which together can determine the maturity of this area.

We started this process by collecting best practices out of a selection of quick scans, models and

best practice lists. We reduced this collection of best practices by:


A Maturity Model


• Removing doubles;

• Removing standard or methodology specific practices;

• Removing practices that are irrelevant for determining the maturity;

• Removing practices that are more like characteristics than practices and therefore cannot be

used for determining action based recommendations.

The next step we took was assigning all remaining practices to one of the five areas. We call this

organized list of practices the long list.

This long list contains too many practices for each area. Therefore another reduction is needed.

Moreover, this long list does not contain aspects, but practices, which are more specific. While a

best practice identifies what one should do to have a mature BCM process, an aspect indicates

which facets within an organization one should look at while determining the maturity. Various best

practices can relate to one single aspect. For instance, the best practices 'communicate the mission

regarding BCM’ and 'organize awareness sessions for BCM’ both relate to the aspect 'awareness'.

To reduce the long list to a manageable size and to translate practices into aspects, we did the

following:

1. For each area, we grouped the aspects in logical groups of interrelated best practices;

2. We evaluated each group once again and decided whether it really represented an aspect

which would be relevant for determining the maturity, if not, we removed it from the list;

3. For all the remaining groups, we replaced the best practices by the aspect that reflects the

group best.

5.6 Consultation with focus group & settlement draf t model The last step to take before we could establish our list of aspects was to let this list be reviewed by

our focus group. This focus group consists of four VKA consultants, one manager within a large

private organization and one manager within a large public organization. All members have

extensive knowledge of BCM. First we discussed whether the subdivision into five areas was

complete and correct. Next we discussed whether the aspects within the areas would all be relevant

for the determination of the maturity of this area, and whether the whole of the aspects is sufficient

for this determination.

The focus group did not criticize the subdivision into the five areas. Regarding the aspects, a few

remarks were made. We reformulated and added several aspects based on this feedback. However,

we did not receive extensive criticism on our draft model and hence haven't changed our draft model

much after this focus session.

After this consultation with the focus group, we have settled our draft model as follows. An

explanation of all aspects can be found in appendix C.


A Maturity Model


Definition 5.1: Draft model including areas and aspects

5.7 Conclusion In this chapter we established the draft framework for the model to be developed. First we

subdivided the total BCM process into five areas. For these areas, the aspects that would determine

the maturity had to be defined. Based on many best practices, a long list of aspects was put

1. BCM POLICY

1. Responsibility

2. Budgeting

3. Commitment management

4. Policy

5. Integration of BCM in other important processes

6. BCM awareness

2. ANALYSIS AND DETERMINATION APPROACH

1. Process analysis and strategy determination

2. Quality of business impact analysis

3. Quality of risk analysis

4. Quality of strategy determination

5. Level of analysis

6. Tuning with external stakeholders

3. DEVELOPMENT PLAN

1. Test plan

2. Maintenance plan

3. Communication plan

4. Security plan

5. Escalation plan

6. Disaster recovery plan

7. Process salvage and recovery plan

8. Training plan

9. Health and safety plan

10. Form of the plan

4. IMPLEMENTATION

1. Execution of the plan

2. Disaster response organization

5. MAINTENANCE

1. Tests and Exercises

2. Maintenance of all products

3. BCM audit


A Maturity Model


together. This long list served as a base for defining the aspects for each area. Before the final

establishment of the resulting framework of areas and aspects, we asked our focus group for

feedback and processed their feedback in the draft model. This resulted in the list of areas and

aspects presented in paragraph 5.5. In the next chapter we will describe the market scan that has

been done based on this model. The outcomes of this market scan will subsequently be used to

develop this draft model into our final model in chapter 8 and 9.


A Maturity Model


6 Design Market Scan

6.1 Introduction In the previous chapter, we established the framework for the model we are going to develop. Within

this framework, we identified several aspects that we think could determine the maturity of BCM

within an organization. However, the selection of these aspects is based on a literature study. We

want our model to be applicable in practice and not just theoretical. Therefore we want to verify

whether the aspects in our draft model also turn out to be the distinguishing aspects for BCM

maturity in practice. We will verify the validity of our long list by performing a market scan among

circa thirty organizations that have expressed an interest in BCM. We will use the information

gathered in this market scan for the further development of our draft framework into a concrete

model with several maturity levels.

In this chapter, we will present the set up of our market scan. First we will explain why we chose to

execute the market scan as a set of interviews. Next we will present how each interview was

conducted, the questions asked and the way these questions were developed. We will conclude this

chapter with a description of the interview group.

6.2 Set up market scan The purpose of our market scan is to gather information on what aspects in practice determine the

maturity of BCM within an organization. For this goal we need a general overview of how BCM is

organized in practice. This corresponds to an exploratory research.

6.2.1 Case study research

Case study is a well-suited research method for exploratory research, as Yin (2003) states. It is able

to answer questions like 'how' and 'why', does not require control of the behavioral events and

focuses on contemporary events. All these characteristics apply to the (exploratory) market scan we

want to perform, so we have concluded that case study is a suitable approach for our market scan.

Yin provides the following definition for a case study: 'A case study is an empirical inquiry that

investigates a contemporary phenomenon within its real-life context, especially when the boundaries

between phenomenon and context are not evident (Yin, 2003)'.

Since we want to identify factors that discriminate between organizations that have different BCM

maturity levels, we are obliged to do multiple case studies. By choosing a research group that is

large enough we aim to be able to draw general conclusions usable for our research.

6.2.2 Use of interviews for case studies

Conducting interviews is one of the generally accepted instruments that may be used for performing

a (exploratory) case study. Since we do not need very detailed information on the individual

organizations, an interview would be well suited to collect the necessary information. We will only

use one interview per organization. Since we only need a general overview of how BCM is

organized in the market, this is sufficient. An extra advantage of holding interviews for our case


A Maturity Model


studies is that those interviews take little time compared to other methods and we can thus

investigate more organizations in the same time. This is a significant advantage since a broad base

is a prerequisite for a trustworthy market scan.

In every interview, the same questions will be asked. This way we can easily compare all the

interviews when developing the final model.

6.3 Set up interviews 6.3.1 Qualitative interviewing

Good interview design is important to assure that the outcomes of our research will be both valid

and useful. Gubrium and Holstein (2002) distinguish three different kinds of interviews; survey

interviews, qualitative interviews and in-depth interviews. For our purpose, qualitative interviews are

best suited.

Qualitative interviews can use some standard question list, so different interviews can be compared.

This is important since we are not primarily interested in the individual interviews but more in the

general image of how BCM is organized and on what aspects organizations differ from each other.

In depth interviews are less standardized and better suited to get a good image of individual

organizations than a general overview of several organizations and the differences between them. In

addition, qualitative interviews view the interviewees more as meaning makers than as passive

conduits for retrieving information (Gubrium and Holstein, 2002), as done in survey interviews. Since

our market scan serves as an exploratory study to determine what is important for the maturity of an

organization, we need to use an interview type that approaches the interviewees as actual meaning

makers.

6.3.2 Procedure followed

For qualitative interviews, we need a standardized interview list based on which we can compare

different organizations. However, the questions should ask for mostly qualitative answers and be

open enough to allow the interviewee to share his view on the subject instead of only asking for a

short answer. The question list consisted of several main (open) questions and a number of sub

questions. In the next paragraph we will elaborate on this list.

Prior to the interview, we sent the interviewees only the main questions. This way they were able to

prepare for the interview and at the same time we made sure the interview would not loose its

natural course and become too static.

Each interview lasted approximately 1.5 hours, which was enough to discuss the matter in sufficient

depth. Some organizations provided us with supportive material (documents, reports). Each

organization was visited by two interviewers and notes were made during the interviews. After both

interviewers had agreed on the interview report, we sent this report back to the interviewee and

asked him for feedback.

When we had completed the interviews, the resulting interview reports were analyzed and

compared. The outcomes of this comparison will be described in chapter 7.


A Maturity Model


6.4 Question list A proper question list is a requisite for doing good interviews. To this end, we had to translate the

identified aspects into questions that can be asked during the interviews. Babbie (2004) enumerates

the following guidelines for asking questions in an interview:

Definition 6.1: Guidelines for defining interview questions

Based on these guidelines, we formulated our interview questions.

It was important to make sure the questions did not steer the interviewees too much, so we could

examine the relevance of the theoretical aspects in practice. To give the interviewees the

opportunity to tell what they think is relevant, we chose to formulate about three open questions per

area. However, the answers to those open questions do not necessarily contain all the information

about the aspects we need. Therefore, we developed for each open question a few more directed or

even closed end questions, which can function as a checklist (we only pose a sub question if the

answer is not already covered in the answer to the main (open) question). We formulated those sub

questions based on the best practices that have been translated into an aspect. For each aspect,

we choose one or a few sub questions, based on these practices These sub questions should cover

the aspect and its possible role in the maturity assessment.

This list of questions was discussed with the focus group again, as described in chapter 5. Based on

the feedback from this focus group we improved and finalized our question list for the interviews.

This question list can found in appendix D (in Dutch, since the interviews were held in Dutch.)

6.5 Validity market scan Considering the importance of the market scan for the development of our model, it is essential to

assure the validity of this research. Yin (2003) indicates that, to assure the validity of an exploratory

case study, three common logical tests are relevant. Below we will discuss those tests and show

how we assured the validity of our research:

6.5.1 Construct validity

Construct validity is concerned with establishing correct operational measures for the studied

concept.

• Choose appropriate question forms

• Make items clear

• Avoid double barreled questions

• Respondents must be competent to answer

• Respondents must be willing to answer

• Questions should be relevant

• Short items are best, if possible

• Avoid negative terms

• Avoid biased items and terms


A Maturity Model


For construct validity we set up a 'chain of evidence' (Yin, 2003). We described our total research

process from initial research questions to ultimate conclusions and thereby allowed the external

observer to follow the derivation of all evidence. In addition to that, we discussed the outlay of our

case studies with several experts on the research area.

6.5.2 External validity

External validity is concerned with establishing the domain to which a study's findings can be

generalized.

Since we had too little data available to do a statistical analysis, we used analytical analysis to draw

our conclusions. In this multiple case study we assessed a wide variety of different organizations, so

we have a broader basis to base our generalization on.

6.5.3 Reliability

Reliability is concerned with demonstrating that the operations of a study – such as the data

collection procedures, can be repeated, with the same results.

To minimize the errors and biases in our study, we made a standard question list for the interviews.

In addition to that, we took several measures to assure the validity of the interviews, as described

below.

The reliability of our research depends largely on the quality of the interview design and execution.

Yin (2003) identifies four possible validity problems regarding interviews. Below we will explain how

we resolved these particular problems:

1. Bias due to poorly constructed questions

We counteracted this by using the feedback of our focus group to improve our question list.

2. Response bias

Within each organization we evaluated, we interviewed a person that had sufficient insight in the

continuity management of the organization to answer our questions. In addition, we have sent

the main questions to our interviewees in advance, so they could look up lacking information

before the interview if necessary.

3. Inaccuracies due to poor recall

We conducted each interview with two interviewers. Both interviewers and the interviewee have

approved the interview report.

4. Reflexivity (the fact that an interviewee only answers what he thinks the interviewer wants to

hear)

We tried to anticipate this in three ways. We did not show our list of aspects during the

interviews, we only showed the main question prior to the interview instead of the full list and we


A Maturity Model


used open questions as much as possible.

6.6 Research group For our market scan, we interviewed thirty organizations. Within each organization, we spoke with

the person who had the best insight in the state of the BCM within the organization. This could be a

general manager, an IT manager, a BC manager, etcetera.

Since our research concerns business critical information, we agreed to keep all information

confidential, including the names of the organizations we interviewed. However, we can characterize

our research group by the size and sector.

Fifteen of the interviewed organizations belong to the public sector; the other fifteen belong to the

private sector.

The organizations operate in a variety of branches. The private organizations, among others include

banking, insurance, industry, commerce, IT services, telecommunication and transport. Among the

public organizations are municipalities, municipal executive institutions, ministries, educational

institutions, executive governmental institutions, emergency aid organizations and more.

The size of the organization does also vary considerably. The smallest organization has only six

employees, the largest over 115 000. The table below gives some insight in the way the number of

employees varied among the interviewed organizations.

Size (in number of

employees)

Number of

organizations

<100 3

100<1 000 5

1 000<5 000 7

5 000<10 000 4

10 000<50 000 5

50 000<100 000 4

> 100 000 2

Table 6.1: Size of interviewed organizations (in number of employees)

The characteristics of the interviewed organizations mentioned above should give some insight in

the variety of the organizations evaluated in our market scan. By considering a wide range of

different organizations, we hope to have executed a market scan that offers a good overview of

Dutch organizations in general.

6.7 Conclusion For the further development of our model, we have performed a market scan consisting of thirty

case study interviews. In this chapter we justified the use case studies based on qualitative

interviews for our purpose and amplified the design of our market scan and the interviews in

particular. The question list used for the interviews can be found in appendix D. In the next chapter


A Maturity Model


we will evaluate the outcomes of our market scan as described above and use those to develop our

final model.


A Maturity Model


7 Outcome market scan

7.1 Introduction In this chapter we will present a summary of the findings from our market scan. These findings will

serve as important inputs for the development of the final model, which we will describe in the next

chapter. In addition to this summary, a complete overview of the main findings of the market scan

can be found in appendix E.

We will present our findings organized according to the main subjects in our question list (see

appendix D), namely (1) introduction/attention for BCM, (2) program management, (3) analysis, (4)

development of the plan, (5) implementation (6) maintenance.

In addition, we’ll give a global overview of the differences between the BCM maturities of various

kinds of organizations.

7.2 Summary findings market scan 7.2.1 Attention for BCM

Organizations are becoming more and more aware of the importance of BCM. However, an explicit

business case for BCM is seldom made. Within most organizations that recognize the need for

BCM, the attention for BCM is either created by some direct cause or at least raised considerably by

one. In most cases this is either fear for some concrete external threat, such as Y2K or of an

incident that has occurred elsewhere. Also, the requirements laid down by laws and regulations play

an important role in the management awareness around BCM. Customer demands seldom play a

role in this.

7.2.2 Program Management

In most organizations the general manager or the BU manager is formally responsible for BCM.

Only within a few organizations, which are relatively mature regarding BCM, the formal responsibility

lies with the risk management or operational departments. BCM activities are most often executed

by security/IT, a temporary project team, or, in more mature organizations, by the operations

management or risk management department or a specialized BCM department.

Separate BCM budgets and insight in the total costs of BCM are rare. If an organization does have a

BCM budget, most of the times it only encompasses the salary costs of the people that plan BCM or

the project costs for the startup of BCM.

Most of the organizations do have some sort of policy regarding their continuity. About 40% of the

organizations state their policy regarding continuity as part of the information security policy. About

the same percentage does have a separate BCM policy, which can vary from a single statement

regarding the obligation to have a BC plan to an extensive BC policy.

About half of the organizations that have a BCM/security policy assume the policy is well known

within the organizations. However, a special BCM awareness program is still a rare phenomenon.


A Maturity Model


Almost all organizations have one or more external drivers they should take into account in their

BCM policy. The main external drivers are regulatory demands, demands of customers and

requirements made by a governmental supervisor. So although customer demands appear not to be

the main reason to pay attention to BCM, once an organization considers BCM important and

decides to formulate a BCM policy, customer demands are taken into account.

7.2.3 Analysis

Most organizations prefer to use a standardized method for their BCM analysis. Approximately two

thirds (66 %) of the organizations use some kind of standard methodology for either a part of their

analysis or the entire BCM analysis.

Almost all organizations perform an analysis regarding their continuity to some extent. More than

one third of the organizations however have not based their analysis on concrete and tuned

continuity norms for critical processes and hence haven't performed a genuine BC analysis. Of the

two thirds that have, only about half have analyzed all internal and external dependencies, the

remaining organizations have not performed a complete analysis yet.

Most organizations use a standard risk analysis methodology, however, our market scan indicated

that a standardized method wasn't absolutely a necessity to perform a good risk analysis.

Most larger organizations perform their BC analysis on parts of their organizations instead of on the

organizations as a whole. The tuning and/or integration of those sub analyses however generally

leaves much room for improvement.

7.2.4 Development plan

It appeared that some parts of the BC plan are significantly more often present within organizations

than others. Almost all organizations have an (IT) security plan and an evacuation plan. Most also

have some kind of communication plan. A test plan, a maintenance plan, an escalation plan, a

disaster recovery plan, a process salvage plan and a recovery plan are only present in about 50 %

of the cases.

Hardly any organization has a special education plan for BCM. Most organizations indicate they

don't see a need for such a plan either.

The actual forms of the various plans differ, but extensive plans, which are not easy to use in

practice, are avoided by most organizations.

BCM software is rarely used, and if it is used, it is mostly used for the administrative part and not the

analysis itself.


A Maturity Model


7.2.5 Implementation

Having a BC plan does not necessarily mean you are prepared for calamities. Implementation of the

plans is not always realized. For instance, measures mentioned in BC plans are not always actually

implemented.

Furthermore, only half of the organizations interviewed has sufficiently communicated and assigned

the roles of their BCP internally. About half of the organizations train and/or educate their employees

for BCM. Also the BC plans are not always readily available in case of an emergency.

Of those organizations that include tasks for external parties in their plans, only about half have

sufficiently communicated those roles to the external parties.

7.2.6 Maintenance

A proper maintenance process distinguishes BCM projects from processes. Maintenance is

essential to assure your BC plan remains up to date and thus relevant for the current situation.

About two thirds of the organizations test their BCP to some extent. Integral testing appears often

too expensive and complex. Most organizations strive for a test frequency of once a year, but only

less than half of these organizations actually realize their own planned frequency.

More than two thirds of the organizations that have a BC plan have implemented controls to assure

the maintenance of the plan. However, less than half of these organizations actually have a formal

BC process.

Although most organizations realize BCM should be taken into account as a part of change

management, this is often not done consistently. Furthermore, BCM is rarely a part of the

managerial planning and control cycle.

Two thirds of the organizations are audited on their BCM, either specifically on BCM or as part of a

larger audit. The most important audit parties are internal auditors and governmental or other

supervising audit organizations. The accountant's audits regarding BCM often appear to be too

superficial to be considered as added value to the organization.

Most organizations require that their suppliers implement continuity controls and formalize their

requirements in a contract or Service Level Agreement (SLA). Less than half of the organizations

actually check whether suppliers meet the contractual requirements.

7.3 Comparison between kinds of organizations The interview group is too small to draw detailed conclusions about the differences between the

BCM of various kinds of organizations (regarding size, branch, etc). However, we can make some

general observations about the difference in the quality of BCM between the various types of

organizations we interviewed.


A Maturity Model


Based on the results of our market scan, we can for instance conclude that, in average, the private

sector finds BCM more important than the public sector. Consequently, the maturity of the BCM

process within an average private organization is considerably higher than that of an average public

organization. The main reason for that is probably that the public sector is not as pressured by their

customers to provide continuity assurance as the private sector. A public organization namely in

general has no (or very little) competitors and doesn’t need to fear bankruptcy. In addition, public

organizations do not feel the pressure of shareholders either, as opposed to private organizations.

The size of an organization is not necessarily an indication for the maturity of its BCM. Although

BCM within a smaller organization is often less formalized, this does not necessarily mean the BCM

process is also less mature. Large organizations can have a very well organized and relatively

formalized BCM process, but at the same time it is possible that the implementation of the policy

and plans is not up to standard. Especially the monitoring and tuning of several autonomous

business parts, such as Business Units, can be very complex.

Organizations for which the continuity of a certain facility is extremely important, such as IT service

providers or organizations in the chemical sector, often have their continuity management very well

organized for this particular facility. However, this does not necessarily mean it is relatively easy to

implement an organization wide BCM process of the same quality as that for only the facility.

The organizations that have the most mature BCM process are in general the private organizations

that provide some kind of infrastructure that is critical for society as a whole, mostly banks and

telecom organizations. Not only are such organizations supervised by an experienced regulator,

given their relevance for society, they also often operate on a highly competitive market and thus

have demanding customers.

All remarks made in this paragraph are observations made during our research. To draw real

scientifically motivated conclusions about the relation between the type of an organization and the

quality of BCM, a similar research under a considerably larger number of organizations would be a

necessity.

7.4 Conclusion In this chapter we discussed the main findings of the study we performed under 30 organizations.

These findings have served as a starting point for the development of our final model. In the next

chapter we will present this model. Chapter 9 will amplify the process by which this model has been

developed out of the data just described.


A Maturity Model


8 The BCM maturity model

8.1 Introduction In this chapter we will present our final model, which should meet the requirements as stated in

chapter 4. This model is based both on theory (the draft model developed in chapter 5) and practice

(the outcomes of the market scan as summarized in the previous chapter).

We will present our model in three paragraphs. First we will describe the framework that forms the

basis of our maturity model. This part of our model is the most interesting part from a scientific

viewpoint. However, to make this model practically usable, we have to develop it further, into a tool.

We need to add two things, namely a method to determine the maturity of an organization based on

this model and recommendations to reach a more mature level. Those will be described in the last

two paragraphs.

In this chapter we will not explain why we developed our model the way we did. We will only present

the final model. In the next chapter we will amplify on the development process that led to this model

and explain the considerations based on which we build this model. It might be useful to reread this

chapter after having read chapter 9.

8.2 Description framework In our model, maturity is determined in a grid, along two different axes. The combination of the

position on both axes determines the maturity of an organization. This is because we discovered

that BCM within organizations can become more mature in two different ways. An organization can

either become more mature because it controls its BCM process better or because BCM is focused

on a wider scope. Therefore, our model has two different axes with their own maturity stages,

namely ‘process quality' and ‘scope’. Each combination of a certain scope and a certain process

quality forms a scoped process quality stage (SPQS).

We will discuss the two axes in the next two paragraphs.

8.2.1 Vertical axis - process quality

The first axis illustrates the maturity path regarding the quality of the BCM process. It distinguishes

six different maturity stages, varying from (1) initiated to (6) optimized. Each stage is described by

two or three characteristics and the deliverable of that stage. The scale of this axis is cumulative,

which is a characteristic of a structure existing of various maturity levels, as stated in 3.2.1. This

means that an organization can't reach a maturity stage until all previous stages have been reached.

Hence an organization that is in stage 4 not only meets the requirements of that stage, but also

those of the stages 1-3.

The illustration below shows the six stages:


A Maturity Model


1. Initiated

2. Planned

3. Implemented

4. Embedded

5. Controlled

6. Optimized

- Responsibilities BCM- Policy BCM

- BC analysis-BC plan

- BC facilities- BC tasks

-BC services

- Maintenance plan BCM- Awareness importance BCM

-Familiarity & availability BC plan

- Strategic approach BCM- Continuous improvement BCM

- BC culture

- Maintenance process BCM- BCM exercises

- Audit&control existing BCM

Figure 8.1: Stages process quality axis

1. Initiated

An organization has initiated BCM if there is formal management commitment to the

organization of BCM. The responsibility for BCM is covered at a sufficiently high level within

the organization and an explicit BCM policy is in effect. The deliverable of the initiated

stage is BCM as an initiative.

2. Planned

An organization reaches the stage planned if it has performed all necessary analyses and

has written all relevant plans. Therefore, this stage is characterized by a BC analysis and a

BC plan. The deliverable of the planned stage is BCM as a blueprint.

3. Implemented

The next stage, implemented, is reached as soon as not only the measures to assure

business continuity are planned, but also realized. This means BCM facilities have to be

realized, services have been contracted and BCM tasks have to be assigned to the right

people. The deliverable of the implemented stage is BCM as an implemented project.

4. Embedded

On the first three stages, BCM is a project. As soon as an organization reaches the

embedded stage, BCM has turned into a process instead of a project. This stage is

reached as soon as a maintenance process is designed, hence a maintenance plan is

developed, the plan is known & available within the organization and there is awareness

regarding the importance of BCM within the organization. The deliverable of the embedded

stage is BCM as a process.

5. Controlled

At the stage embedded an organization has developed a maintenance plan and probably

formulated some BCM exercises and tests. In the next stage, controlled, this maintenance


A Maturity Model


process is also executed as it should and exercises are done as planned for. In addition to

that, the existing BCM is audited and controlled. The deliverable of the controlled stage is

BCM as business as usual.

If an organization has reached stage 5, its controls its existing BCM. For some

organization, a BCM process that is controlled is sufficient. However, other organizations

will strive for stage 6, optimized.

6. Optimized

If an organization has optimized its BCM, it can use its BCM as a strategic instrument, for

example to gain a commercial advantage or strive for operational excellence as a business

strategy. For this, a strategic approach of BCM is a requisite. Furthermore, BCM has to be

part of the organizational culture and the organization should strive for continuous

improvement of their BCM. The deliverable of the optimized stage is BCM as a strategic

instrument.

8.2.2 Horizontal axis – scope

Besides the quality of the BCM process, the BCM maturity of an organization is also determined by

another dimension, namely the scope of its BCM process. Regarding this scope, four different

maturity stages can be distinguished. The scale of this axis is also cumulative, just as the process

quality axis. Those four scope stages are facility focus, organization focus, chain focus and integral

focus. In illustration of these four stages is shown below:


III. Chain focus

IV. Integralfocus

Figure 8.2 Stages scope axis

A. Facility focus

The organization focuses its continuity management on a single facility (or a few facilities)

that is important for the continuity of the organization, but it does not consider all assets

within the organization on which the critical processes depend. In example of such a facility

could be IT or a production line in a plant

B. Organization focus

The organization focus encompasses not only one facility, but all internal assets on which

the critical processes depend.


A Maturity Model


C. Chain focus

The chain focus does not only look at all internal assets on which the critical processes

depend, but also on all in- and outputs of the critical processes and hence on the chain

partners.

D. Integral focus

The integral focus is dotted in the illustration above. The reason for this is that this scope is

not relevant for all organizations. Some large organizations choose to focus their BCM

analysis, plans, etc. not on the organization as a whole, but on some sub part of their

organization, such as a business unit. Ideally, those separate BC processes should be

integrated or at least tuned. In the integrated focus, all BU's have not only evaluated the

entire chain, but have also tuned their BCM with all other BU's.

In practice, this appears to be hard to do, even harder than tuning the BCM with chain

partners. Our research suggests two reasons for this: First of all, the relation with chain

partners is less complex for BU's than that with other BU's. Second of all, it is easier for

BU's to see why they should tune their BCM with chain partners, which have a clear role in

their primary process, than why they should tune it with other BU's.

This fourth maturity stage is only relevant for organizations which direct their BC analysis

and planning towards a level of analysis lower that the entire organization.

8.2.3 Combined grid

The combination of those two axes results in a grid, which forms the basis for our model. This grid

has 6 x 4, thus 24, scoped process quality stages (SPQS) which all have their own features. The

illustration below shows this grid:

1. Initiated

2. Planned

3. Implemented

4. Embedded

5. Controlled

6. Optimized


III. Chain focus

IV. Integralfocus

Figure 8.3: Our maturity model for BCM with both axes


A Maturity Model


8.3 Determination of maturity 8.3.1 Definition maturity within the model

The first thing we need if we want to determine the maturity of a given organization based on our

model, is an operational definition of maturity within our model. We will define maturity in this model

as: ‘the area of the SPQS's which the BCM of an organization complies with'. Since both axes have

a cumulative scale10 it is never possible that an organization complies with a SPQS cube but not

with the SPQS below or at the left of it. Therefore the maturity of an organization can be illustrated

as a colored area within our model, originating form the left lower corner.

8.3.2 Formulation requirements and objectives

To determine the BCM maturity of an organization, we need some way to assess whether the BCM

of an organization complies with a SPQS. This assessment can be done based on the requirements

that are formulated for each SPQS. How those requirements are determined can be explained by

the illustration below. In this example we focus on the characteristic BC analysis regarding the

scope organizational focus.

BC Analyse

Maatregelenselectie

RA

BIA incl alle interneafhankelijkheden


Kritieke processengeïdentificeerd

Processen in beeld

Continuiteitsnormengesteld

etc....

Figure 8.4: Structure model based on characteristics, objectives and requirements

In paragraph 8.2 we characterized each process quality maturity stage by two or three

characteristics. For each scope those characteristics are elaborated into several specific ‘objectives’.

Thus, each combination of process quality and scope is defined by a set of objectives. These

objectives are not shown in the model itself because this would make the graphical representation

too complex. However, the objectives form an important piece of documentation for the model.

The objectives are general and not specific and measurable enough to form the easy applicable

assessment tool we required in paragraph 4.2.Therefore, each objective is specified by several

10 This cumulative structure is a characteristic of a maturity model, as stated in paragraph 3.2.1


A Maturity Model


‘requirements’. The requirements aren’t a part of the model itself but form the basis for the quick

scan, which is the tool that can be used to determine the maturity of an organization. Figure 8.4

visualizes also this relation between the quick scan and the model; the white part (hence the

requirements) represents the quick scan, the colored parts the model itself.

An overview of all objectives can be found in appendix F. The list of requirements falls outside the

scope of this thesis. The quick scan based on those requirements is property of VKA and will be

used in BCM projects.

8.3.3 Organizations that fall outside the model

Every SPQS has certain requirements that must be met. This means it is possible for an

organization to fall outside the model, if it doesn't even meet the requirements of the lower left

SPQS. If an organization falls outside the model it has no actual BCM process according to the

model. Unlike some other maturity model, this model has no default 0-level, which would allow every

organization to fit in the model.

8.4 Recommendations to improve maturity Based on the current maturity, an organization can determine its growth path. This can be done by

following the next four steps:

1. Determine the (initial) scope

An organization has to choose the scope it wants to focus its BCM on. An organization can for

instance choose an organization focus at first. This choice should be made based on a cost-

benefit analysis. An organization can decide to limit its scope initially if the benefits of

considering a wider scope do not outweigh the costs. For instance, if an organization focus

covers the most important continuity risks an organization faces and including chain partners in

the BCM would make the process far more complex and costly, it can choose to apply an

organization focus. At the moment it controls its BCM on this limited scope sufficiently, an

organization can always decide to subsequently aim for a wider scope.

This chosen scope will be the focus of the growth process.

2. Develop your BCM on that scope at least until it is 'controlled' (level 5)

Having chosen the scope of its BCM, an organization should develop its BCM until it's under

controls. The first step is to bring BCM to the lowest level of process quality that hasn't been

entirely reached yet for the decided scope. If an organization initially falls outside the model, the

first step would be to grow to level 1 (initiated). Thus an organization grows one step at a time in

the entire breadth of the scope.

3. Reevaluate the chosen scope; if necessary, go back to step 1

When an organization controls its BCM process on a certain scope, it can reconsider its scope.

It has to consider whether it still aims for this scope or it wants to extend the BCM to a wider

scope. In the second case, the first and second step of this assessment method should be


A Maturity Model


applied again to the new scope.

4. Optional: Optimize BCM on the scope

When an organization controls its BCM on the chosen scope, there is one last optional step it

can take. If an organization considers its BCM important enough to use it as a strategic

instrument, the last step it has to take is that of optimizing its BCM.

This assessment method is illustrated by an example in appendix G.

8.5 Conclusion In this chapter we presented the maturity model for BCM, which is the prime deliverable of this

research. This model defines the maturity of a certain organization based on the quality of its BCM

process and the scope this process focuses on.

This results in a grid with two axes and 6 x 4, thus 24, Scoped Process Quality Stages (SPQS's).

Each SPQS is described by several objectives. The maturity of an organization is determined by the

total area of SPQS's for which an organization has realized the corresponding objectives. Since both

axes have a cumulative scale, an organization can only comply with a SPQS if it also complies with

both the SPQS below and to the left of it.

Whether an organization has realized an objective that describes a SPQS is determined by the

requirements that specify that objective. As opposed to the objectives themselves, the requirements

are specific and measurable. The requirements do not belong to the model itself, but form a special

quick scan that may be used as an analysis instrument.

Based on the current maturity of an organization, this model can help to determine the growth path

that should be followed to improve the maturity of BCM within organization. In this chapter we

presented a generic growth strategy that could be used to determine this growth path. Summarized

this method consists the following for steps:

1. Determine the (initial) scope that is aimed for;

2. Develop your BCM on that scope at least until it is 'controlled' (level);

3. Reevaluate the chosen scope, if necessary, go back to step 1;

4. Optional: Optimize the BCM on the determined scope.

In the next chapter we will describe how we developed our draft model as presented in chapter 4,

together with the market scan outcomes presented in the previous chapter into the model just

presented.


A Maturity Model


9 Development final model

9.1 Introduction In the previous chapter we have presented our final model. In this chapter we will describe the

development process that led to this model.

As described earlier in this report, we have discussed our model with the focus group before we

have settled our final model. Therefore we will describe the development of this model in three parts,

first the development of the model as presented to the focus group, subsequently the feedback

received from this focus group and finally the development of the final model based on this

feedback.

In addition to the development of the model itself, we will also briefly amplify the development of the

generic growth strategy that can be used to determine the ideal growth path for a given organization.

9.2 Development model as presented to focus group The development of the first official version of our complete model has taken much iteration. We will

describe this development process in two phases; first we will describe how we have created the

basic structure of this model and then we will describe the further elaboration of this structure into

the model as we presented it to the focus group.

9.2.1 Development of the basic structure

The development of the structure that formed the basis for the model we presented to the focus

grouped occurred in three steps. Those three steps describe the creation of a model out of the data

of the market scan and our draft model. Stepwise, this model is refined until it was general and

communicable enough to be suited as a management model. These steps are: (1) development of a

first version, purely based on the market scan and the 5 areas of the draft model (2) simplification of

the model by integrating previously independent areas into one grid and (3) further simplification by

removing the division into five areas from the model. We will describe all three steps below.

1. Development of a first version purely based on the market scan and the five areas of the draft

model

As stated in chapter 4, we initially developed a model with different maturity paths for all five

areas and later on evaluate whether it would be possible to reduce the number of different sets

of maturity levels without making our model less useful in practice. Therefore, at first, we

maintained the five areas as formulated in our draft model and formed various maturity levels for

each area based on the outcomes of our market scan.

This way we developed the first version of our complete11 maturity model. We developed the

maturity levels purely based on the data from the market scan. For this purpose, we analyzed

11 The draft version in chapter 5 did not include any maturity levels, which makes this version the first complete

version of our model


A Maturity Model


which aspects would be most important for the maturity according to our outcomes. We coded12

our data based on a generic classification of the answers. We used this coded data file to

identify about five different levels of maturity per specific area that could be seen among the

analyzed organizations. The reason to make the number of stages equal for each area, was so

we would be able to compare the areas easily and maybe even to couple the areas into one

maturity path.

This resulted in a model with five areas which all have their own maturity path of five levels.

Figure 9.1: Version 0.1 final model

Simplification of the model by integrating previously independent areas into one grid

Version 0.1 of our model distinguishes five different maturity levels that are independent of each

other. Hence, it doesn’t result in one single judgment about BCM process of an organization Since

one of the requirements for our model is that the model should present an easily communicable

outcome, we would rather integrate the various maturity paths into one model, which gives one

judgment about the maturity of the BCM of a certain organization

An easy way to do this would be to simply match the levels of the various areas, so an organization

12 We coded the given answers by selecting several standard answer categories in which all answers could be

organized. For instance, the answers to what cause made an organization pay more attention to their BCM have

been coded in: ‘Y2K threat’, ‘rising threats other than Y2K’, ‘change in the internal organization itself’, ‘forced by

accountant/regulations’ and ‘demands of customers’.

4. GeintegreerdBCM plan

1. Niks/alleenbeveiligingsplan

2. Beveligingsplan&

Calamiteitenplan

3. Beveligingsplan&

Calamiteitenplanincl procesuitwijk &

herstel

2. Continuiteit deel(IT)security

3. Globaal BCMbeleid

4. RichtinggevendBCM beleid

5. BCM integraaldeel

bedrijfsvoering

1. BCM nietingericht

1. Geen RA/nietgebaseerd op BIA

2. BIA, alleen ITafhankelijkheden

3. BIA, alleafhankelijkheden

excl ketenpartners

4. BIA, alleafhankelijkheden,incl. ketenpartners

5. BIA, alleafhankelijkheden,incl alle externe

partijen (ookandere BU's)

1. Plan nietverspreid/

gecommuniceerd

2. Planbeschikbaar en

globaalgecommuniceerd

3. Plan verspreid,intern&extern

gecommuniceerd

4. Plan verspreid,gecommuniceerd

en geoefend

5. Plan deeldagelijkse

bedrijfsvoering

2. Verantwoorde-lijkheid beheer is

belegd

3. Beheer gepland& uitgevoerd voor

deel plan

4. Beheer geplanden uitgevoerd voor

heel plan.BCM deel change-

management.

5. Hele BCMproces beheerd.

1. BCM is project,geen beheer

5. BCM planafgestemd tussen

alle BU's/processen

I. Beleid

II. Analyse

III. Schrijven plan

IV. Implementatie

V. Beheer


A Maturity Model


would be in level 3 if it has at least reached level 3 within all five areas. However, based on our

research data we concluded this was not possible. There appeared to be too much variance

between the maturity stages a single organization has on the five different areas.

After a thorough analysis of the data, we concluded that the five areas could not be integrated this

way since the way an organization matured on areas 1 to 3 differed significantly from the way it

matured on level 4 and 5. If an organization becomes more mature regarding area 1, 2 or 3 (based

on version 0.1), this means it assesses a wider scope for its BCM. However, if an organization

matures on level 4 or 5, this means the quality of its BCM process increases.

We have solved this problem by distinguishing two paths along which an organization matures, one

regarding the scope of its BCM and one regarding the quality of its BCM process. The maturity

levels of areas 1 to 3 were aligned along the first path, those of 4 and 5 along the second path.

Moreover, this gave us the opportunity to add some other aspects regarding the maturity of the first

area by also adding a maturity line of program management to the second path. This resulted in the

next version of our model, version 0.2, which is showed below.


2. Further simplification by removing the division into five areas from the model

The two prior versions of our model both showed the five areas that we distinguished in our

draft model. In the second step we reevaluated whether it was necessary to assign each area a

separate maturity path and simplified our model. The next thing we did was to reevaluate

whether it was necessary to retain the division into the five areas in the description of the

stages. We concluded that removing this subdivision made our model a lot easier to

communicate. We developed a next version of or model without this subdivision, which did not

loose any valuable information, compared to the prior version and was better communicable.

This resulted in a more general model with two axes, which still are based on the initial areas,

but do not show them separately anymore. This more general model is called version 0.3, which

I. IT II. Internal III. In-& external IV. Entirely int egrated

IT continuity policy & responsibilities assigned

business continuity policy and responsibilities assigned

BCM policy tuned externally

Richtinggevend BCM beleid, afgestemd op strategie

Program management

BIA including IT dependencies

BIA including external dependencies

BIA including all in- and external dependencies

Integrale analyse hele organisatie Analysis

Security plan & disaster recovery plan

Contingency plan including process salvage and recovery

Contact external parties part of plan, plan tuned with all relevant stakeholders

Tuned with security plan, tuned with other BU's Planning

1. Initiated Policy formulated No implementation No maintenance

2. Implemented

Facilities realized, roles assigned and communicated

No/ ad hoc maintenance

ManagedResponsibility BCM process assigned

People instructed, ad hoc exercises

Maintenance formally organized

4. Controlled

Management aware of importance BCM. Execution monitored Regular practices

Regular testing, BCM part change management

5. Optimized

BCM competitive advantage, attention for BCM in management meetings. Audit on BCM. BCM part of culture

Entire process maintained, not only plan. BCM part planningcycle


A Maturity Model


can be found in appendix H.

If we distillate only the structure of this version and change the shape of it slightly, this results in

the structure that formed the basis for the model. We call this version 0.4, and it is shown below.

1. Initiated

2. Planned

3. Implemented

4. Embedded

5. Controlled

6. Optimized


III. Chain focus

IV. Integralfocus


9.2.2 Further specification of the model structure

The maturity of an organization in version 0.4 is determined by the number of squares for which it

meets the requirements. For this purpose, each square has to be exactly defined. Version 1.0 of the

model will complete version 0.4 by specifying the exact description for each square. Remember, an

organization can only meet the requirements of a certain square if the requirements of the square

below and to the left of the square are already met (this follows automatically from the

characteristics of a maturity model, see chapter 3).

To formulate the descriptions, we evaluated all aspects defined in the draft model, based on the

outcomes of our market scan. For each aspect we subsequently decided whether these should be

explicitly mentioned in the requirements and if so, how exactly.

This fourth step resulted into version 1.0. Version 1.0 has the same structure as version 0.4, but it

also encompasses a short description for each square. The overview of those descriptions can be

seen in appendix I.


A Maturity Model


9.3 Feedback from focus session We have presented this version 1.0 to our focus group and asked them for feedback on how to

improve our model.

The global structure of the model has not been a point of dispute during the focus group session.

The feedback received was directed more towards the details of our model. The most important

comments received where the following:

1. The description of the requirements of every square makes the model more complex than it

should. It would be better if every maturity level on the process quality axis has a general

description that accounts for all focuses and the actual requirements for a certain square can be

logically derived from the combination of the description of the scope maturity and the process

level maturity. The official definitions of those requirements can be used for assessments, but

need to be displayed in the general model.

2. Level A of the scope dimension should probably not be called IT focus, since this isolated focus

could also be something else than IT. for instance the most important production facilities. By

calling this focus isolated, or something similar, instead of IT our model would become more

general.

3. The meaning of the ‘integrated’ scope, as compared to the chain scope, might not be clear

enough.

4. The focus group gave several recommendations about the formulation of the actual descriptions

of the squares.

9.4 Development final model based on feedback focus group We have used the feedback received from the focus group to improve our model. This led to the

following refinements:

1. The first feedback point caused the most important change made to our model. We needed to

make our model less complex and hence easier communicable (one of the requirements of our

model). However, we also need enough detail to be able to do action-based recommendations

based on our model, and to develop an easily applicable assessment tool, which are two other

requirements.

To solve this dilemma between a simple, easily communicable model and a model that is

detailed enough to produce action based recommendations, we decided to split our model into a

high level model, which can be used for communication, and an underlying documentation set.

In the high level model, each maturity level of the process quality axis will be described by two

or three characteristics. This model will contain no further description of the individual squares.

In the documentation each square is described by a set of objectives. These objectives form the


A Maturity Model


specifications of the characteristics of the process quality maturity level for the scope in

question.

However, the objectives are still too general to form the basis of our quick scan (an easily

applicable assessment tool). Therefore, for this quick scan we have specified each objective

into several concrete and measurable requirements. However, as mentioned before, this quick

scan falls outside the scope of this thesis.

The structure of the specification of characteristics into objectives and requirements is illustrated

by the example below. In this example is focused on one of the characteristics of SPQS 2B

(planned- organization focus), namely BC analysis.

BC Analyse

Maatregelenselectie

RA

BIA incl alle interneafhankelijkheden


Kritieke processengeïdentificeerd

Processen in beeld

Continuiteitsnormengesteld

etc....

High level version

Documentation

Figure 9.4 Underlying structure maturity model

2. We changed the name of IT focus to facility focus, to indicate this could also be a scope that

considers some other facility the critical processes depend on than just IT.

3. We decided the integral focus would only be a relevant step in maturity for organizations that

perform their BC analysis, plan, etc. on some organization level below the organization-wide

level. Therefore, we chose to dot the lines of this focus and this way indicate that this scope is

only relevant in some cases.

4. While changing the specifications of the squares into the characteristic-objective-requirement

structure, we also took the advices about the descriptions of the squares into account.


A Maturity Model


Those changes led to the model as presented in paragraph 8.2 and 8.3.

9.5 Evaluation choices made regarding design option s In paragraph 3.4 we identified three design options; number of maturity levels, number of areas on

which maturity is determined and extra design dimensions. Now we will look back at the choices we

made for our model, regarding those design options, and we will motivate the choices made.

9.5.1 Number of maturity levels

For the vertical axis, process quality, we developed six maturity levels. For the horizontal axis,

scope, we developed only four maturity levels. We deliberately choose to vary the number of

maturity levels on both axes, since practice showed the evolution line of process quality is

considerably more complex than the evolution line of the scope. The modal number of maturity

levels we observed in chapter 3 is five, and we assume this would also be about the ideal number.

Therefore, both numbers are close to the modal (and probably ideal) number of maturity levels,

namely five. We explicitly choose not to add a level 0 to the process quality axis, also because we

considered seven different maturity levels as too much to comprehend in one view.

9.5.2 Number of areas on which maturity is determined

We integrated the five separate areas that formed our draft model as much as possible, to make our

model easier to communicate. However, we concluded there was one important factor that made it

impossible to integrate all areas entirely without loosing valuable information, namely the scope the

BCM process considers (in addition to the another factor that determines the first axis, namely

process quality). Therefore we kept both factors as areas on which maturity is determined, and thus

developed a model with two areas on which maturity is determined.

9.5.3 Other design dimensions

Since we already have two independent areas on which maturity is determined, adding another

dimension probably would make our model too complex. In addition, our model, as it is, can

comprehend all important information for BCM maturity, so there is no real need for an extra

dimension. What we did do, was coupling our two areas into one grid. This way we made our model

less instead of more complex.

9.6 Development generic growth strategy In a 'regular' maturity model with just one axis, the growth path for an organization with a given

maturity is pretty straightforward. A maturity model shows the path to the highest maturity level one

step at a time, so if there is just one axis, the next step to take for instance at level 3 is to grow to

level 4. In our model however, this next step could be either along the process quality axis or along

the scope axis.

Our generic growth strategy resulted out of several discussions, which were based on practical

experience of the consultants who joined the discussions, the information gathered in the market

scan and logical derivations from these. We concluded the following:


A Maturity Model


• The scope an organization aims for in its BCM depends on a cost benefit analysis (either explicit

or implicit). An organization has to balance the extra costs of a broader scope against the

additional risks that can be mitigated. It is also possible that an organization chooses to start

with a more limited scope and focus at a broader scope once it controls this more limited scope.

• As soon as an organization has chosen a scope, it has to start its growth path at the lowest level

it has reached for the entire scope. It's no use to reach a higher maturity level for just a part of

this scope, because the BCM process has to be considered as an integral process and the

areas of focus the scope encompasses exhibit tight coherence. For instance, if an organization

has chosen the organization focus, it would not be wise to grow from planned to implemented

on the facility focus if it has only reached the level initiated on the organization focus. This would

namely mean an organization starts an initiative to implement a plan that is bound to change in

the near future.

• If an organization has chosen a certain scope, it should develop its BCM process until it controls

its BCM on this scope. As soon as it has reached this level, it can reconsider its scope.

• If an organization has reached the level 'controlled' on the chosen scope and it either cannot

broaden its scope anymore or it chooses not to, the organization may consider to grow to the

level optimized. However, as stated before, for some organizations the level controlled will be

sufficient.

Those conclusions led to the development of the generic growth strategy. As can be seen, this

growth strategy results in a customized growth path, which depends on some choices to be made by

the organization itself. Two organizations with the same current maturity can thus have a different

growth path according to this method. This matches the observation made during the market scan

that not only the current maturity, but also the ambition level and strategy of an organization affect

the growth path.

9.7 Development model into a tool The maturity model itself together with the generic growth strategy does not form a complete BCM

analysis tool yet. To deliver this complete tool, we also have to take what is called the fourth step in

paragraph 4.4 ('Add quick scan and recommendations'). We have already mentioned several times

that this quick scan and these recommendations fall outside the scope of this research. However, in

this paragraph we'd like to give some global insight in how those two will be developed.

9.7.1 Development quick scan

The list of objectives forms a good basis for the quick scan. As described in paragraph 9.4, each

objective can be translated into several requirements. We will develop those requirements in

consultation with several consultants who have participated in BCM projects. This way, we can base

our requirements on experiences out of practice. In addition to this, we will also use the best

practices that served as an input for the aspects within the draft model (see paragraph 5.5) for the

development of the quick scan.


A Maturity Model


This should result in a quick scan that will take at most four interviews of one and a half hour, as

required in paragraph 4.2.

9.7.2 Development recommendations

The best way to couple action based recommendations to our model, is to link some (practical)

methodology to our model. Every stage transition should be coupled to a certain part of this

methodology. Based on this methodology we can subsequently give action-based recommendations

for every stage transition. We have to take the scope into account when translating the relevant part

of the methodology into recommendations.

Since the set of recommendations will be used exclusively by VKA, it would be logical to base those

recommendations on the VKA methodology. As can been seen in appendix J, it is possible to map

this methodology on our model and thereby determine the relevant parts of this methodology.

9.8 Conclusion In this chapter we amplified on the development process of the model presented in the previous

chapter. We have described our main steps and showed the most important intermediate models

that led to the final model. Furthermore, we described how we established our general growth

strategy.

In addition, we sketched how we will develop the quick scan and the action based

recommendations, two parts of the tool that fall outside the scope of this thesis.

Now we have both presented our model and explained how this model has been developed, the

only thing left to do is to validate whether this model is a valid representation of reality and whether it

actually meets the requirements as formulated in chapter 4. Chapter 10 will describe this validation.


A Maturity Model


10 Validation model

10.1 Introduction In the previous two chapters we have presented our final model and amplified on the development

process that led to this model. In this chapter we will validate this final outcome of our research. We

will base this validation on the requirements for our model as formulated in paragraph 4.2.

These requirements are the following:







It is hard to perform a complete validation within the time available for this research. However, we

tried to validate the result of our research as extensively as possible. In this chapter we will describe

this validation process. First we will explain why a complete validation is not possible and introduce

the validation methods we used instead of the ideal, complete validation. Next we will elaborate on

the validation of each requirement individually.

10.2 Methods used for validation The aim of this research was to develop a maturity model that could serve as (the basis for) an

analysis tool for BCM. More specifically, the objective of this research as described of 'To develop a

maturity model for BCM based on which the current state of the BCM within an organization can be

assessed and recommendations to improve this state can be made'. The best way to validate

whether our model actually can be used to assess the current state of the BCM and do

recommendations based on which this state can be improved, would be to apply this model in

practice. Once we would have determined the maturity of several organizations and implemented

the recommendations we would be able to see whether the model actually gives a proper image of

the maturity and whether the recommendations actually help to improve this state. Most probably

our model will evolve based on those practical experiences.

This kind of validation will actually be applied, since VKA will use this model as an analysis tool in

the near future. However, such a complete validation based on the practical application will take

several months. Therefore, it will not be possible to execute such a validation within this research

project. Instead of basing our validation on the practical application of the model, we will therefore

rely more on expert opinions.

We used the following expert groups:

• A group of several consultants who are experts on BCM, based on their practical experience out

of BCM projects.


A Maturity Model


During individual discussions we asked those consultants to give feedback on our model, taking the

requirements for our model (paragraph 4.2) into account.

• (A part of) our interview group, people who are responsible for the BCM of their organizations

and hence would be the target group for the application of the analysis tool.

We used their expert opinions as the target group for the model in two ways:

- During a theme session for BCM, we presented the model and asked for feedback;

- After this theme session, we sent an evaluation form to all persons present. This form I

shown in appendix K (in Dutch).

• Two auditors, who are experts on the application of analysis lists in general; like the quick scan

we are developing

Besides these expert opinions, we also used some other approaches to validate parts of our model,

such as a mapping of the model onto the methodology used by VKA and roughly positioning the

organizations out of our market scan into our model. Such methods may not offer full scientific

prove, but they give extra indication of the quality of our model.

10.3 Validation model regarding requirements As stated before, we have performed the check against the requirements mostly based on expert

opinions. Below we will describe for each individual requirement how we have validated whether it

was met and what the conclusion of this validation was.

10.3.1 Substantiated judgment of BCM maturity

Whether our model is able to make a substantiated judgment of BCM maturity of an organization

can be assessed based on the following criteria:

1. Is the model complete, hence, can it position every given organization?

2. Does the model have enough distinguishing capacity to give a meaningful judgment of the

maturity of an organization; hence, does it encompass all (and only) relevant aspects for the

determination of the maturity?

3. Are these aspects measurable?

We used the expert opinions of the BCM experts to check all three criteria. None of the experts

criticized the actual frame of this model. There can be some debate on the exact formulation of the

objectives, but the model itself was judged both to be complete and to have enough distinguishing

capacity. In addition, the objectives were all assessed to be measurable, especially after they are

translated into requirements (whether this translation is possible will be discussed in 10.3.6).

There has been made a remark that the addition of a level 0 for process quality would maybe make

the model more complete. However, this would add even another level to the six that already exist.

In addition, it would not be possible to determine on which scope an organization is in level 0 ("for

which scope do you have nothing?"). The value added by explicitly drawing a level 0 instead of only


A Maturity Model


mentioning the existence of it in the documentation would not outweigh the extra complexity and

loss of communicability.

Besides the BCM expert group, we also used our interview group to validate whether this

requirements is met. Both during the session and on the evaluation form sent afterwards, we asked

them whether our model could actually provide an organization with useful information about their

BCM maturity.

The conclusions that can be drawn from this are similar to those from the BCM experts. The frame

of the model and the actual stages has not been criticized.

The overall conclusion we can drawn is that our model is perceived to be complete and to have

enough distinguishing capacity to give a meaningful judgment of the maturity of an organization. In

addition, the aspects that determine the maturity of an organization seem very well measurable. The

only aspect of the model about which there could possibly be some dispute is the exact formulation

of the objectives.

10.3.2 Easily communicable outcomes

Whether the outcomes of our model are easily communicable, can be validated best based on the

opinions of our interview group, alias the target group for our model.

The presentation of the model to our interview group (which presented the model just as presented

in this thesis), as referred to in paragraph 10.2, hardly raised any questions on the structure of the

model itself. During the discussion after the presentation it also became clear that the model was

well understood by the entire group.

A similar conclusion can be drawn from the outcomes of the evaluation form sent after the

presentation. The interview group was both asked explicitly whether they thought the model was

easily communicable and tested implicitly by asking them to position their organization in the model

themselves.

The outcome of this evaluation was not different than that derived from the presentation session

itself. Combined with a short explanation as for instance given in this thesis the model is considered

to be relatively easy to understand. This has also to do with the fact that this model has a shape

people are familiar with; a 2-dimensional grid in which you ideally would want to grow to the upper

right corner. The self-positioning organizations did confirm this. Organizations did not place

themselves considerably differently than we would based on the interview data, which shows they

indeed understood the model well.

Our model is thus considered to be indeed easily communicable.

10.3.3 Producing action based recommendations

The production of action-based recommendations is done in two parts. First, the generic growth

strategy (which is described in 8.4) has to be applied. We validated whether this growth strategy


A Maturity Model


actually represents in the ideal growth path for a given organization based on the expert opinions of

the BCM experts.

The conclusion that can be drawn form those discussions is that, although not all organizations

follow such a growth strategy, our experts still think this would be the ideal strategy.

Whether our model can be used to do action-based recommendations is validated based on the

expert opinions of the BCM experts. We asked them whether they thought it was trivial to develop a

set of action-based recommendations for each position within the model. First we asked them this

without showing the mapping of the VKA BCM approach onto our model, next we showed them this

mapping and resumed the discussion.

Based on these discussions, we can conclude that our model is indeed able to provide the

appropriate focus on the VKA methodology given the maturity of an organization. However, the

translation into concrete action based recommendations is not as straightforward as it would seem,

since the VKA methodology is not elaborated into that much detail. This methodology is more a

guideline that can be used by an expert who identifies the recommendations himself. We could

choose to elaborate this methodology and make all expert knowledge explicit as much as possible.

However, it is doubtful whether this is desirable, whether it is worth the effort. Another option is to

wait with the formulation of the recommendations until we have developed our quick scan. The

requirement on the lowest level that an organization does not meet, could serve as a basis for the

recommendations. Therefore, we can first develop the requirements and subsequently analyze how

much more elaboration of the methodology is needed to formulate good recommendations.

Summarized, our model is considered to give good advice for the growth strategy to follow, but the

methodology we want to base the recommendations on needs some further elaboration before it is

suited for this purpose. The requirements of the quick scan could serve to fill up the gap.

10.3.4 Suited for comparisons

We assume this model can either be used to compare different organizations or to compare

organizational entities within one organization. In addition, the model can also be used to compare

on one specific organization or organizational entity over time.

To be suited for this kind of comparisons, the model should have enough distinguishing capacity to

position organizations with a different BCM maturity differently within our model. We used both the

expert opinions of the interview group and those of the BCM experts group to assess whether this is

true.

After the presentation on the Erasmus University, the possibility to use this model as a base for

different kinds of comparisons (as described above) was already mentioned spontaneously by

several persons present.

In addition, we asked the interview group on the evaluation form whether they thought this model

could be useful to do comparisons either within their organization or between their organization and

others. The reactions to this question were all affirmative.


A Maturity Model


We asked the BCM experts the same question. In addition to this, we performed a thought

experiment, by making up different imaginary organizations and assessing whether these where

also positioned differently within our organization. This also confirmed our assumption that our

model would be well suited for comparisons.

In addition to the expert opinions, the data set with information about the interview group also

confirms our model would be useful for comparisons. The assumed positions of the various

organizations showed sufficient divergence to confirm this.

Hence, we can conclude our model is indeed suited to serve as a basis for doing comparisons.

10.3.5 Based on a generally accepted best practice methodology

Already at the settlement of our draft model we have concluded that this model was based on a

generally accepted best practice methodology. Not only have the methodologies we used as a basis

for our model proven their validity in practice, our basis of the draft model had not been criticized

during the focus group session either.

Despite that, we have also discussed this requirement extensively in the BCM expert group. We

concluded that we can still state that our model is based on a best practice methodology. To be

more specific, this best practice methodology can be rediscovered in the process quality axis.

This best practice methodology is nevertheless not as visible as it was in the draft model. A

mapping, such as that one that maps the VKA approach onto the model, could therefore be a useful

addition when the recommendations based on the current maturity have to be explained to an

organization.

However, our model is definitely demonstrable based on a best practice methodology and thus

meets this requirement.

10.3.6 Easily applicable assessment tool

The last requirement was discussed with both the BCM experts group and the auditor group. We

asked them whether they thought the objectives of our model could be translated into requirements.

The BCM expert group appreciated the clear (underlying) structure of the model: characteristics �

objectives � requirements. They saw no limitations that could hamper the translation of the

objectives into requirements.

The auditors also considered the elaboration of the characteristics into objectives and subsequently

requirements very useful. They stated that this division into "conceptual – logical – factual" was a

good way to separate demonstrable 'check list' facts (requirements) from the value judgment done

by the expert who executes the analysis (objectives). They also thought the objectives in general

would form a good basis for the requirements.


A Maturity Model


There was however mentioned one important point of criticism. The objectives and the expert

opinion13 that is coupled implicitly to an objective are probably clear to experts that perform an

analysis. However, if the outcome of this analysis has to be communicated to the organization under

analysis, there may be some confusion about what the objectives actually encompasses. To

motivate the translation of the objectives into the requirements (which in general will be on a too

detailed level, so the communication will mostly be done based on the objectives), a more detailed

description of the objectives may be necessary. However, this more detailed description will

probably be too extensive to place in our overview of objectives. A solution for this could be to add a

(hidden) more detailed description to each objective, which can be used if necessary.

We can conclude that the objectives of our model are indeed suited to translate into requirements

that together will form a quick scan. However, it is desirable to first develop more detailed

descriptions for the objectives before we will formulate the requirements.

10.4 Conclusion Due to time restrictions for this research we haven't been able to fully validate whether our model

actually fulfills the need established in the first chapter of this thesis. Application of our model in

practice would be the best conceivable validation of our model, however, this was not feasible in the

time available for this research.

Therefore, we validated our model mainly based on expert opinions. . We used three different expert

groups (BCM experts, the target group of our model and auditors) to check the validity of each of the

six requirements as enumerated in paragraph 4.2.

Although the validation as described in this chapter cannot actually prove our model is valid, it

shows our model has survived the critical views of several experts and anyway has not been

falsified.

Our model itself, hence the structure of the various maturity levels, seems to meet all requirements

stated in chapter 4. It is considered to be able to give a sustained judgment of BCM maturity, to

produce easily communicable outcomes, to make comparisons and it is based on a generally

accepted best practice methodology.

Besides that, our validation shows that our model is most likely also suited as a basis for a complete

analysis tool. It already offers a way to determine the ideal growth path. Besides that, we can

translate our objectives into requirements and this way develop a quick scan that fulfills the

perceived need as described in the first chapter. Those requirements can serve as a starting point

for coupling action based recommendations to the different steps in a growth strategy,

supplemented with a possible further elaboration of the VKA methodology.

However, before we will develop our quick scan and recommendations, it is considered desirable to

add more specified descriptions to our objectives and thereby make these more concrete.

13 For instance, the objective 'maintenance plan' does not only require some document exists with the stamp

'maintenance plan' on it, it implicitly also requires this plan to meet certain characteristics.


A Maturity Model



A Maturity Model


11 Conclusions and further research

11.1 Final result of our research Given the increasing importance of continuity and the rising complexity associated with assuring this

continuity, more and more organizations start paying attention to Business Continuity Management

(BCM). We observed the need for an analysis tool that can give an organization insight in the

maturity of their BCM. Based on this observation, we decided to develop a maturity model for BCM,

which could serve as the basis for such an analysis tool. We implicitly assumed that a more mature

Business Continuity Management process would result in a better Business Continuity capacity. An

organization is considered ‘more mature’ as it controls the BCM process (as it ought to be organized

based on our available information) better.

We formulated the following requirements for this model:







Based on both existing literature and our own market scan we developed a maturity model as shown

below:

1. Initiated

2. Planned

3. Implemented

4. Embedded

5. Controlled

6. Optimized


III. Chain focus

IV. Integralfocus

Scope

Proc

ess

qual

ity

Figure 11.1: The maturity model for BCM

The full rationale behind this model is explained in chapter 8 and 9. We discovered that it was not

possible to give a substantial judgment of the BCM within an organization based on only one aspect.

Hence, our model defines not one evolution line, but two: process quality and scope. By defining

discrete levels on both axes, the model is separated in squares, named SPQS's (scope process

quality stages). Each SPQS is characterized by several objectives. Each objective, on its turn, is


A Maturity Model


elaborated into several requirements, which are specific and measurable, and all requirements

together form a quick scan. The maturity of an organization is determined by the area of SPQS's for

which an organization meets the requirements.

In addition, our model also offers a general growth strategy that can determine the ideal growth path

for a given organization, which is described into more detail in paragraph 8.4.

11.2 Validity of this result The model needs to meet six requirements, four requirements that were formulated for the model

itself (requirements 1,2,4 and 5 in paragraph 4.2) and two requirements that involve practical

application of the model (requirements 3 and 6 in paragraph 4.2)

Due to the time restraints for this research, we could not actually test our model by using it in

practice. Therefore, we based our validation primarily on expert opinions. Based on this validation,

we can state that our model meets all four requirements that were formulated for the model itself,

hence the structure of the model consisting of various maturity levels. The model is perceived to

meet the requirements to give a substantiated judgment of BCM maturity, to produce easily

communicable outcomes, to make comparisons and to be based on a generally accepted best

practice methodology.

The two other requirements are related to the extent to which our model is suited to be extended

with an analysis tool. They require our model at least to be suited to serve as a basis for the

development of a quick scan and as a basis for action-based recommendations. Our validation

indicates that, before we will actually develop this quick scan and these recommendations, we

should first formulate more specified descriptions for our objectives. With the refinement mentioned

above, our model is considered to be well suited to develop into an actual analysis tool.

11.3 Further research The most obvious opportunity for further research is the development of the model as described in

this thesis into a complete analysis tool. The first step would be to further specification the objectives

by adding more detailed descriptions. This is also a recommendation resulting from the validation.

The next thing to do would be to translate our objectives into requirements and to develop a quick

scan that can be used to apply our model in practice. Those requirements can serve as a starting

point for combining action-based recommendations with the different steps in a growth strategy.

Additionally, this could be supplemented with a further elaboration of the VKA methodology.

Another interesting option for further research would be to assess the extent to which this model is

actually useful as a practical analysis tool by actively employing this model in practice. This would

be most interesting as soon as the complete tool as described above actually exists. This way, we

might also be able to validate our implicit assumption that more mature BCM leads to better BC.

It would also be an interesting research to collect a large amount of data about various organizations

and their positions within the model. This would result in a considerable set of benchmark


A Maturity Model


information. Using this benchmark, one can compare organizations with, for instance, the average

maturity within their sector. In addition, based on this information, one could draw interesting

conclusions, for instance about the difference in maturity between various sectors.


A Maturity Model


References

Akker, van den, A.G., Prince2 Compact - Methode voor projectmanagement, Lagant Management

Consultants BV, 2002

Babbie, E, The practice of social research, Thomson Wadsworth, 10th edition, 2004

Barnes, J.C., A guide to business continuity planning, John Wiley&Sons, 2001

BCI, Business Guide to Continuity Management, www.bci.org, accessed May 2005

BCI, Guidelines to Business Continuity Management, www.bci.org, accessed May 2005

BCI, BCI PAS 56 audit workbook, www.bci.org, accessed May 2005

BCI, PAS 56, Guide to Business Continuity Management, BSI, March 2003

Bradburn, N.M. & Sudman, S., Improving Interview method and questionnaire design, Jossey Bass

Publishers, 1979

Butler, J., Contingency planning and disaster recovery strategies, Computer Technology Research

Corporation, 1994

CCTA, A guide to business continuity management, CCTA, 1995

CCTA, An introduction to business continuity management, CCTA, 1995

Dang Van Mien, A., The Gartner Security Process Maturity Model, Gartner Group Research

note, 2001

Delen, G., World Class IT; van service naar business gericht met uw ICT organisatie, KPMG

consulting, Focus Enterprise Uitgeverij; 2000

Gubrium. J.F. & Holstein, J.A., Handbook of interview research: context and methods, Thousand

Oaks, 2002

Hipaa Basics, Hipaa Basics Glossary, http://www.hipaabasics.com/glossary.htm, accessed on

September 6 2005

Holdburg, G., DR vs. BC, Dueling Recovery plans, Disaster Recovery Journal, Volume 18, Issue 2-

Spring 2005

Jordan, J., Zellenrath, H.& Verzuu, R., Guide to Business ContinuityPlanning, CSCI, 2005


A Maturity Model


Kalmis, L., Business Continuity Maturity Model, Faulkner Information Services, September 2004

Koch, Reinhard, Business Continuity Best Practices. Disaster Recovery Journal, Volume 14, Issue

1. Available online via <http://www.drj.com/special/strohl/win01/1401-12p.html> [accessed

September 2005]

Leegwater, D., & Ploeg, J., Business Continuity Management sterk gebaat bij procesdenken,

Business Process Magazine, March 2005

Leegwater, D. & Reiniers, C., Business Continuity Management – Methodiek en lessen vanuit de

praktijk, Jaarboek IT beheer en Informatiebeveiliging, 2005

Mingay, S., Outlining the Gartner BCP Maturity Model, Gartner Group Research Note, 2002

Niessink, F., Clerc, V., & Van Vliet, H., The IT Service Capability Maturity Model, Software

Engineering Research Centre, 2002

Noakes-Fry, N., & Diamond, T., Business Continuity Planning and Management: Perspective,

Gartner Research, September 2001

Oud, E.J., Business Continuity Management; meer dan Contingency Planning, IB jaarboek 2000

OGC, Guidelines on BC management,

http://www.ogc.gov.uk/sdtoolkit/reference/ogc_library/itbusinesschange/GuidelineBCM21.pdf,

November 2001

Paulk, M.C., e.a., The Capability Maturity Model for Software, Software Engineering Institute, 1995

Ream, S., Presentation : Business Continuity Maturity Model, Virtual Coorporation Inc, 2003

Roest, H., Business Continuity Planning vraagt om bedrijfsbrede inzet, IT-beheer, May 2005

Scheffel, Het doel, de weg en de rugzak; een gids voor praktisch ICT service management,

Verdonck, Klooster & Associates, van Haren Publishing, 2004

Spring Singapore, Fact sheet on business continuity management, available online via

http://www.spring.gov.sg/portal/products/nat_certification/bcm/bcm.html# , accessed on July 1 2005

Spruit, M.E.M. e.a., Van ontwijken naar uitwijken: Over het uitwijken van de informatievoorziening na

een calamiteit, Stichting Het Expertise Centrum, 2003

Titulaer, R., e.a.; Kwaliteit bij Burgerzaken:; stap voor stap op weg naar rekenschap,

http://www.zenc.nl/rekenschap/h3.htm , May 2001


A Maturity Model


UK Interest group, The "how to" guide for the year 2000 to continuity planning for business, The UK

Interest group, 1999

Virtual Coorporation Inc, The Complete Public Domain Business Continuity Maturity Model, Virtual

Coorporation Inc., Software Engineering Institute, 2004

VKA intranet, various documents, only accessible internal

Yankee Group (2001) , September 11, 2001: Infrastructure Impacts, Implications, and

Recommendations, Yankee Group Special Report, September 2001

Yin, R.K., Case study research – Design and methods, Sage Publications, 2003

http://www.ink.nl/public/?dirID=23, accessed June 2005

http://www.ogc.gov.uk/sdtoolkit/reference/tools/ms_positioning.html, accessed July 2005

www.bcmacademy.nl, accessed May 2005

www.businesscontinuityplanners.nl, accessed May 2005


A Maturity Model


Glossary

Business Continuity Analysis

(BC Analysis)

The analysis based of which a BC plan can be

composed, consisting of a BIA, RA and the selection

of measures.


(BCM)

The management process that aims to prevent

severe disruptions in the business and to protect

critical processes against the consequences of

disruptions or disasters.

Business Continuity Plan

(BC Plan)

The plan that encompasses all measures taken to

assure BC. It consists of a security plan, a

contingency plan and supportive plans, such as a

maintenance plan and an education plan.

Business Impact Analysis (BIA) The process of analyzing all business functions,

identifying the critical processes and determining

their continuity norms, identifying their dependencies

and analyzing what impact different extents of

disturbance of the process will have upon the

business

Case study research An empirical inquiry that investigates a contemporary

phenomenon within its real-life context, especially

when the boundaries between phenomenon and

context are not evident

Contingency plan A plan setting out an organized, planned, and

coordinated course of action to be followed in case

of a disruption of business; hence all corrective and

repressive BCM measures.

Core activities Activities by which an organization expects to

distinguish itself from its competitors.

Critical process A process for which can be said that an interruption

of this process will immediately have a negative

impact on the objective of an organization and a

longer interruption can endanger the survival of the

organization.


A Maturity Model


Disaster recovery plan The plan that describes how the IT services can be

resumed in an alternative way in case of a

disturbance

Draft model The initial version of our model that only

encompasses the aspects that should determine

maturity but no actual maturity levels yet.

Escalation plan A plan that describes whether, when and how the

contingency plan is activated

Maturity model A maturity model is a staged structure of maturity

levels, which defines the extent to which a specific

process is defined, managed, measured, controlled

and/or effective, assuming the organization develops

and adopts new processes and practices, from which

it learns, optimizes and moves on to the next level,

until the desired level is reached.

Process salvage and recovery

plan

The plan that describes how a process can be

resumed in an alternative way in case of a

disturbance and subsequently recovered to its initial

state

Risk analysis (RA) The analysis process that identifies the potential

threats an organization faces and analyzing both the

chance those threats become reality and the impact

this would have on the critical processes (see BIA)

Security plan A plan that describes all preventive BCM measures

Scoped Process Quality Stage A combination of a given process quality stage and a

given scope stage, hence a square within our

maturity model.


A Maturity Model


Overview appendices

A Three maturity models (ad chapter 3) 80

B Various BCM methodologies (ad chapter 5) 85

C Motivation selection aspects draft model (ad chapte r 5) 88

D Question list (ad chapter 6) 91

E Outcome market scan (ad chapter 7) 97

F Objectives of various SPQS's (ad chapter 8) 104

G Example general growth strategy (ad chapter 8) 111

H Final model version 0.3 (ad chapter 9) 114

I Descriptions final model version 1.0 (ad chapter 9) 115

J Mapping VKA methodology onto our model (ad chapter 9 ) 118

K Evaluation form 119


A Maturity Model


A Three maturity models (ad chapter 3)

As discussed in chapter 3 we based our analysis of the different design options regarding maturity

models on three existing maturity models, the CMM, the KPMG world class IT model and the INK

model. In this attachment we present a short evaluation of these three models.

A.1 The Capability Maturity Model (CMM) The original version of the Capability Maturity Model, developed in 1986 by the Software

Engineering Institute, was meant to model software development. However, many other versions

have been developed since for a variety of (management) processes. The Software Development

CMM provides organizations with guidance on how to control their software development processes

and evolve toward a culture of software engineering and management excellence. (Paulk, 1995)

The CMM can determine the current maturity of the software development and identify the issues

most critical to the quality of the software development process. The principle behind this model is

that the chance the outcome of the software development process is a success rises as the maturity

of the software developments process matures.

The software development CMM identifies five different maturity levels, which can be seen below:

Figure A.1: CMM levels

Every level has its own key process areas. These are the aspects that should at least be covered a

this level. The CMM doesn't judge the quality of the way the process area is covered, it only checks

whether the key process areas are covered or not. When all key process areas at a certain area are

covered, an organization can reach for the next level by starting covering the key process areas of

this level.


A Maturity Model


Every process area identifies a set of related activities that together achieve a goal important for

enhancing process capability. Those activities, or key practices, are organized by some common

features. Figure 2 illustrates the way maturity levels are compounded.

Figure A.2 Composition maturity levels CMM

A.2 The KPMG World Class IT model The KPMG World class IT model has been developed as a model to analyze the ICT within an

organization and determine a strategy for the future. Not only does it offer an image of the current

situation, it also indicates in which direction the next step should be taken. (Delen, 2000)

For this purpose, it identifies six primary processes within ICT:

1. Exploitation

2. Incidents & problems

3. Changes & Configuration

4. Service delivery

5. Development and maintenance

6. Strategy and policy

The extent to which these processes have been developed, determines the maturity of the ICT

within the organization.

The World Class IT model states that information management should be considered as one

integrated process and approaches that look separately at the demand and supply of ICT stimulate

imbalance and therefore aren’t effective. Supply and demand should be in balance and if


A Maturity Model


improvement of ICT is needed, both parts should grow simultaneously. Therefore the model

describes the six processes both from the supplier focus (which usually is a ICT supplier or an IT

department within an organization) and the user focus.

The maturity of a process depends on the way information management is really organized. In every

maturity level both the supply and the user side have a certain role in the processes. The maturity of

a process depends on the roles that the supply side and the user side have within the process.

The model distinguishes the following five different maturity levels for every process:

1. Technology driven – user follows

In the first phase supply and demand are two separate worlds. The ICT department is mainly

driven by technology and the user follows without steering.

2. Controlled – user chooses

In the second phase the ICT department controls its processes and the user chooses the

services it needs.

3. Service driven – user decides

The ICT department is able to supply stable services at a price and quality level determined in

advance agreed with the user.

4. User-driven – user is owner

The focus shifts from what can be supplied towards what is asked by the users.

5. Business driven – user steers

The responsibility for good Information management is fully shared between the user and

supplier.

An image of the KPMG World Class IT mode can be seen below:

Figure A.3: KPMG World Class IT model

A.3 The INK model The INK-management model originally was meant as an instrument to select candidates for the

Dutch Quality Price. It can be used to identify the strengths and weaknesses within an organization.

The functioning of an organization is the focus of the assessment. (www.ink.nl)

ICT is strategisch

wapen

geenissuemeer

geenissuemeer

integratie vraag-aanbod

flexibelop tijden op maat

geenissuemeer

geopti-maliseerd i.s.m.

klant via pro-actief beheer

toe-gevoegdewaardevoor

businessstaat

centraal

opti-malisatieafspraken

i.s.m.klant

integrale ontwikkeling

enonderhoud

van business

& IT

gezamen-lijke

strategie vorming

geopti-maliseerd,

volumeflexibel

gestan-daardiseerde

en geïntegreerde

processen

geopti-maliseerd:

gestroomlijnden versneld

proces

processen ingericht,meetbaar

voor aanbod,start metcostmgt.

geoptimali-seerdi.s.m.

gebruikers

up to dateinformatie-planning en architectuur

planmatig,onder controle processen

ingericht

wijzigingen & configuratie

procesingericht

P&D-catalogus,SLM geïnitieerd,beschikbaar-

heids- &capaciteitsbeheer

beheersbaarconform

standaarden

algemene richtingbepaald

met weiniginput van

de business

geen standaarden,geen planning,veel verstoring ongestructureerd

brandjesblussen:reactief

geen overzichtgeen afspraken

reactief,geen

projectmatige aanpak,ad hoc

geen(formeel)

beleid

Technologiegedreven

Beheerst

Servicegericht

Klantgericht

Businessgericht

afgestemdop

business processen

Str

ateg

ie &

Bel

eid

Ont

wik

kelin

g &

Ond

erzo

ek

Ser

vice

D

eliv

ery

Wijz

igin

gen

&P

roje

cten

Inci

dent

en &

Pro

blem

en

Exp

loita

tie

Str

ateg

ie &

bele

id

Inno

vatie

&

tren

d w

atch

Ser

vice

Lev

elM

anag

emen

t

Pro

ject

mng

t.&

wijz

igin

gen

(Geb

ruik

ers)

-on

ders

teun

ing

App

l.-be

heer

&aa

nstu

ring

expl

.

Klantvolgt

Klantkiest

Klantbepaalt

Klantstuurt

Klant iseigenaar

ICT is strategisch

wapen

geenissuemeer

geenissuemeer

geenissuemeer

focusop

innovatie

geenissuemeer

stabiliteitissue van klant en IT

wijzigingen beoordeeld vanuit bus.

& arch. perspectief

toespitsing opklantgroep

met inzicht inconsequenties van eisen en

wensen

integraal programmamanagement

vanuitstrategie

gezamenlijke strategie vorming

afbakeningheldertussenklant-IT

afspraken over niveau van onder-steuning en

taak-verdeling

betrokken in

besluit-vorming

onder-handelen over basis dienst-

verlening

wensen op elkaar

afgestemd en globaal op beleid

ICT-strategie afgestemd

opbusinessstrategie

aan-spreek-puntendeels

belegd

af-handeling in beginsel

gestruc-tureerd

partici-patie

inbelangrijke projecten

participatiein

belangrijkeprojecten

klantkiest

speer-punten

uit ICT-strategie

adhoc

zelfop-

lossen/regelen

zelfdoen niet niet

geenrelatie metIT

sturing en optimalisatie

van de exploitatie

begrip dat IT

bestuurd moet

worden

ICT is strategisch

wapen

geenissuemeer

geenissuemeer

integratie vraag-aanbod

flexibelop tijden op maat

geenissuemeer

geopti-maliseerd i.s.m.

klant via pro-actief beheer

toe-gevoegdewaardevoor

businessstaat

centraal

opti-malisatieafspraken

i.s.m.klant

integrale ontwikkeling

enonderhoud

van business

& IT

gezamen-lijke

strategie vorming

geopti-maliseerd,

volumeflexibel

gestan-daardiseerde

en geïntegreerde

processen

geopti-maliseerd:

gestroomlijnden versneld

proces

processen ingericht,meetbaar

voor aanbod,start metcostmgt.

geoptimali-seerdi.s.m.

gebruikers

up to dateinformatie-planning en architectuur

planmatig,onder controle processen

ingericht

wijzigingen & configuratie

procesingericht

P&D-catalogus,SLM geïnitieerd,beschikbaar-

heids- &capaciteitsbeheer

beheersbaarconform

standaarden

algemene richtingbepaald

met weiniginput van

de business

geen standaarden,geen planning,veel verstoring ongestructureerd

brandjesblussen:reactief

geen overzichtgeen afspraken

reactief,geen

projectmatige aanpak,ad hoc

geen(formeel)

beleid

Technologiegedreven

Beheerst

Servicegericht

Klantgericht

Businessgericht

afgestemdop

business processen

Str

ateg

ie &

Bel

eid

Ont

wik

kelin

g &

Ond

erzo

ek

Ser

vice

D

eliv

ery

Wijz

igin

gen

&P

roje

cten

Inci

dent

en &

Pro

blem

en

Exp

loita

tie

Str

ateg

ie &

bele

id

Inno

vatie

&

tren

d w

atch

Ser

vice

Lev

elM

anag

emen

t

Pro

ject

mng

t.&

wijz

igin

gen

(Geb

ruik

ers)

-on

ders

teun

ing

App

l.-be

heer

&aa

nstu

ring

expl

.

Klantvolgt

Klantkiest

Klantbepaalt

Klantstuurt

Klant iseigenaar

ICT is strategisch

wapen

geenissuemeer

geenissuemeer

geenissuemeer

focusop

innovatie

geenissuemeer

stabiliteitissue van klant en IT

wijzigingen beoordeeld vanuit bus.

& arch. perspectief

toespitsing opklantgroep

met inzicht inconsequenties van eisen en

wensen

integraal programmamanagement

vanuitstrategie

gezamenlijke strategie vorming

afbakeningheldertussenklant-IT

afspraken over niveau van onder-steuning en

taak-verdeling

betrokken in

besluit-vorming

onder-handelen over basis dienst-

verlening

wensen op elkaar

afgestemd en globaal op beleid

ICT-strategie afgestemd

opbusinessstrategie

aan-spreek-puntendeels

belegd

af-handeling in beginsel

gestruc-tureerd

partici-patie

inbelangrijke projecten

participatiein

belangrijkeprojecten

klantkiest

speer-punten

uit ICT-strategie

adhoc

zelfop-

lossen/regelen

zelfdoen niet niet

geenrelatie metIT

sturing en optimalisatie

van de exploitatie

begrip dat IT

bestuurd moet

worden


A Maturity Model


The INK-model focuses on nine areas of interest, five organization areas (which can be directly

controlled by an organization) namely leadership, employees, strategy and policy, resources and

processes and four result areas, namely recognition by employees, recognition by customers,

partners, consumers and suppliers, recognition by society and end results.

An image of the process areas (description in Dutch) can be seen below:

Figure A.4: INK model

Every organization area has a maturity level, varying form 1 to 5:

1. Activity oriented

Skills are central in this phase. The organization reacts ad hoc to situations; there is no real

policy.

2. Process oriented

The processes are central in the second phase. Separate steps are captured within work

processes. Processes are improved based on identified deviations.

3. System oriented

Every level of the organization is systematically trying to improve the organization as a whole.

Customer focus is dominant for the policy.

4. Chain oriented

The organization strives for a maximum value added together with partners in the value chain.

Control systems are linked in an innovative manner.

5. Excel and transform

The organization has embedded the process of continuous improvement within both the

structure and the culture of the organization. A long-term vision forms the base for initiating new

activities.

The result areas also have a maturity varying form 1 to 5. This maturity depends on the extent to

which the performance on the result area can be measured. The different levels are:


A Maturity Model


1. Only information available based on simple facts

2. Based on available information a trend in development can be seen

3. Actual performance can be compared to objectives

4. Performance compared with similar organizations

5. Performance compared with 'best practices' of excellent organizations worldwide

The total maturity is determined by the weakest link principle. The end goal of the INK methodology

is to reach phase 5, which describes the excellent organization.


A Maturity Model


B Various BCM methodologies (ad chapter 5)

B.1 Methodology PAS 56 (BCI, 2003)

Figure B.1: Methodology PAS 56

B.2 Methodology Business Continuity Planners (www.businesscontinuityplanners.nl)

Figure B.2: Methodology BCP

B.3 Methodology CSCI (Jordan, Zellenrath & Verzuu, 2005)

1. Initiation & Definition

2. BIA

3. Strategy Alternatives

4. Development


A Maturity Model


5. Testing

6. Maintenance

B.4 Methodology CCTA/ IT Infrastructure Library (CCTA, 1995-1)

1. Initiation

2. Requirements and strategy

- BIA

- RA

- BC strategy

3. Implementation

- Organization and implementation planning

- Implement stand-by arrangements

- Develop business recovery plans

- Implement risk reduction measures

- Develop procedures

- Initial testing

4. Operational management

- Education and awareness

- Review

- Testing

- Change control

- Training

- Assurance

B.5 Methodology BCM academy (http://www.bcmacademy.nl/?id=48&par=18)

Figure B.3: Methodology BCM academy


A Maturity Model


B.6 Methodology Verdonck, Klooster & Associates (VKA intranet, 2005)

Figure B.4: Methodology VKA

B.7 Methodology UK Interest Group (UK Interest Group, 1999)

InitiationIdentify

Assess

Plan

Implementation

Review

Check list A providesa way of monitoringprogress through theflowchart

Checklist BManagement actions

Worksheet 1What processes

can you not do without?

Worksheet 2What could happen?

How do you deal with it?

Worksheet 3Who does what?

When?How?

Start

Finish

Figure B.5: Mathodology UK interest group


A Maturity Model


C Motivation selection aspects draft model (ad chap ter 5)

1. BCM POLICY

1. Responsibility It is important that the right person, sufficiently

high placed within the organization to realize

BCM, is responsible for BCM

2. Budgeting Whether an organization has a separate BCM

budget and if so, how large this budget is, give an

indication of how important this organization

considers its BCM to be

3. Commitment management For successful BCM, sufficient resources and

cooperation are necessities. These can never be

obtained if the management is not committed to

BCM

4. Policy A clear and communicated policy gives the right

direction to BCM.

5. Integration of BCM in other important processes By integrating BCM into other processes and

projects continuity aspects are not only considered

afterwards but also taken into account and

optimized as an integral part of projects and

processes

6. BCM awareness Without sufficient awareness, an organization can

never implement its BC plan as it should.

2. ANALYSIS AND DETERMINATION

APPROACH

1. Process analysis and strategy determination

The use of some (standard) methodology can be

an indicator for the quality of the BCM

2. Quality of business impact analysis

Whether and how an organization identifies its

critical processes, determines the associated

continuity norms and the dependencies, is an

important indicator for the quality of BCM

3. Quality of risk analysis

The same is true for whether and how an

organization identifies and analyzes its risks

4. Quality of strategy determination

Idem for the continuity measures an organization

considers and the way it makes its selection

5. Level of analysis

The level of analysis and the degree of tuning

among various possible subparts of an

organizations could influence BCM quality

6. Tuning with external stakeholders The extent to which external stakeholders are


A Maturity Model


involved in the BCM is also important

3. DEVELOPMENT PLAN A Business Continuity Plan consists out of two

parts, a security plan (preventive) and a

contingency plan (repressive and corrective). This

contingency plan on its turn consists of an

escalation plan, a communication plan and

process salvage and recovery plan (including

disaster recovery), (a health and safety plan)14

and a training plan. In addition, there should be a

test plan and a maintenance plan for the entire BC

plan.

Whether all these plans are present gives an

important indicator for the quality of the BCM.

1. Test plan Describes tests for the BC plan

2. Maintenance plan Describes the maintenance of the BC plan and the

BCM in general

3. Communication plan Describes how the communication should occur in

case of an calamity

4. Security plan

Describes the preventive continuity measures

5. Escalation plan Describes the procedures based on which is

determined whether and how the contingency plan

is put into action.

6. Disaster recovery plan Describes the IT related corrective and repressive

measures

7. Process salvage and recovery plan

Describes how critical can be executed elsewhere

in case of a calamity and how can de returned to

normal business after the calamity

8. Training plan Describes the necessary training

9. Form of the plan Not only the existence of the plans is important,

also whether they are written in a usable format

4. IMPLEMENTATION

1. Execution of the plan

Whether an organization has only started the

project or already finished it, and thus

implemented all facilities as described in the plan

is also an important quality indicator for BCM.

2. Disaster response organization The same is true for the realization of the

14 Only belongs partly to the BC plan and is not added as a aspect


A Maturity Model


organizational part of the plan

5. MAINTENANCE

1. Tests and Exercises Frequent testing and exercising is important to

assure an organization is actually prepared for a

calamity.

2. Maintenance of all products An organization should also make sure BCM

doesn't remain just a project which is finished one

day, it should become a process. All BCM results

should be maintained to remain up to date and

thus useful.

3. BCM audit An independent check on the BCM can provide

useful feedback and serve as an incentive to

assure a good BCM


A Maturity Model


D Question list (ad chapter 6)

Since the interviews were held in Dutch, the question lists are also in Dutch. The first question list is

the complete list as used in the interviews. The second list is the list as it was sent to the

interviewees so they could prepare for the interview.

D.1 Question list used in interviews

0. INLEIDING

0.1 Hoe belangrijk is BCM voor uw organisatie?

A.Wat was de aanleiding om BCM aandacht

te schenken?

B. Is er een business case gemaakt?

1. BELEID

1.1 Hoe is het Business Continuity Management binne n uw organisatie georganiseerd? (verantwoordelijkheden, budgettering, etc)

A. Wie is er verantwoordelijk voor het BCM?

Aan wie rapporteert deze persoon? Als niet

management, is management er dan op

andere manier nog bij betrokken?

B. Wie voert het BCM uit?

C. Op welke wijze wordt het beschikbare

budget voor BCM vastgesteld? Is er één

centraal BCM budget? Wie is budgethouder?

D. In welke mate wordt BCM meegenomen

in belangrijke processen en projecten van de

organisatie?

1.2 Bestaat er een bedrijfsbreed BCM beleid?

A. Zo niet, wat is dan het hoogste niveau

waarop BCM beleid bestaat?

B. Wie is bij het opstellen hiervan

betrokken?


A Maturity Model


1.3 Welke externe eisen, zoals weten regelgeving of eisen van klanten, worden meegenomen in het opstellen van het beleid?

1.4 Wat doet de organisatie om haar medewerkers bew ust te maken van het gevoerde BCM beleid en het belang van BCM op zich?

A. Is de visie en het beleid van de

organisatie m.b.t. BCM bekend binnen de

hele organisatie?

B. Bestaan er speciale awareness

programma's om het bewustzijn binnen de

organisatie te verhogen?

2. ANALYSE EN BEPALING AANPAK 2.1 Hoe wordt vastgesteld welke maatregelen het BC plan moet omvatten?

A. Bestaan er standaard methodieken voor de

analyse en aanpakbepaling voor BCM binnen

de organisatie?

B. Hoe worden de continuïteitsnormen voor de

bedrijfsprocessen vastgesteld?

1 Heeft de organisatie inzicht in welke

processen van wezenlijk belang zijn

voor de continuïteit van de

bedrijfsvoering?

2 Welke afhankelijkheden van deze

processen zijn nagegaan?

-ICT

-mensen, middelen en info?

-ketenpartners/in & output

C. Hoe zijn de mogelijke bedreigingen

geïdentificeerd (bijv. i.s.m. de

proceseigenaars)?

D. Hoe wordt de uiteindelijke aanpak

vastgesteld?

(verzekeren, preventief, correctief, etc)


A Maturity Model


E. Zijn de restrisico's formeel geaccepteerd door

het management?

2.2 Op welk niveau van de organisatie worden de ana lyse en de bepaling van de aanpak voor BCM uitgevoerd?

A. Is er één integraal plan, wordt dit nog

verder uitgewerkt in deelplannen voor delen

van de organisatie?

2.3 Worden ook externe partijen betrokken bij het B CM en zo ja, welke?

Ketenpartners, leveranciers, hulpverleners,

klanten?

3. OPSTELLEN PLAN ( 2 vragen )

3.1 Uit welke onderdelen/plannen bestaat het BC pla n?

A. Testplan?

B. Opleidingsplan?

C. Beheerplan?

D. Escalatieplan/Staat er aangegeven

wanneer het calamiteitenplan in werking

treedt?

E. Bestaat er een beveiligingsplan?/ Staan

de preventieve maatregelen in het plan

vastgelegd?

F. Communicatieplan/ Staat er in het plan

vastgelegd met wie gecommuniceerd moet

worden in geval van een calamiteit?

Is ook het mediacontact opgenomen

in het plan?

Bevat het plan up to date contact

informatie van alle te informeren

partijen?

G. Ontruimingsplan?

H. ICT uitwijk?

I. Procesuitwijk?

J. Herstelplan?


A Maturity Model


3.2 Wat is de vorm van het BC plan? (gedetailleerde beschrijvingen, een

checklist, etc)

A. Software gebruikt?

4. IMPLEMENTATIE ( 3 vragen ) 4.1 Hoe worden de maatregelen uit het BCM plan geïmplementeerd?

A. Hoe worden de preventieve maatregelen

gerealiseerd?

B. Hoe worden de herstel- en uitwijk

faciliteiten gerealiseerd? (ook werkplekuitwijk

verzorgd?)

4.2 Hoe wordt er voor gezorgd dat iedereen weet wat van hun verwacht wordt in het geval van een calamiteit?

A. Zijn BCM rollen toegewezen aan personen

en vervangers en is dit gecommuniceerd?

B. Weten externe partijen, die ook een rol

spelen in het BC plan, wat van hen verwacht

wordt?

C. Worden medewerkers opgeleid en

getraind?

D. Op welke manier is het plan beschikbaar?

5. BEHEER ( 3 vragen )

5.1 Vinden er oefeningen plaats op het gebied van B CM?

A. Hoe vaak?

B. Maken jullie onderscheid tussen

verschillende testen, en zo ja, welke (scope:

technisch/proces/full en reality: cold, warm,

extra warm of hot)

C. Wat wordt met de bevindingen hiervan

gedaan?

5.2 Hoe wordt gezorgd dat het BCM up to date blijft ?

A. Wie is hier verantwoordelijk voor?


A Maturity Model


B. Omvat dit het hele BCM proces, dus ook

opleiding, awareness creatie, etc en niet

alleen het plan zelf?

C. Hoe vaak wordt het BCM vanuit dit

beheersplan geëvalueerd?

D. Wordt in verandertrajecten ook BCM

meegenomen?

E. Is BCM onderdeel van de jaarlijkse

planningcyclus?

5.3 Vindt er een onafhankelijk controle op de inric hting van BCM plaats?

A. Door wie? (intern/extern?)

B. Wat wordt als doel en scope van deze

audits gesteld?

C. Worden ook eventuele afspraken met

leveranciers t.b.v. BCM gecontroleerd?

6. Afsluitend 6.0 Kwantitatief: A. Hoeveel fte houden zich binnen de

organisatie primair bezig met BCM?

B. Hoeveel fte zijn er werkzaam binnen de

organisatie, waarvan hoeveel binnen IT?

C. Wat is het BCM budget?

D. Heeft u inzicht in de totale kosten en

baten van BCM, en zo ja, zou u daar een

schatting van kunnen geven?

6.1 Wat is de visie van .. met betrekking tot het B CM voor komende jaren?


A Maturity Model


D.2 Question list sent to interviewees in advance

VRAGENLIJST INTERVIEW BCM

0. INLEIDING

• Hoe belangrijk is Business Continuity Management (BCM) voor uw organisatie?

1. BELEID

• Hoe is het BCM binnen uw organisatie georganiseerd? (verantwoordelijkheden, budgettering, etc)

• Bestaat er een bedrijfsbreed BCM beleid?

• Welke externe eisen, zoals weten regelgeving of eisen van klanten, worden meegenomen in het

opstellen van het beleid?

• Wat doet de organisatie om haar medewerkers bewust te maken van het gevoerde BCM beleid en

het belang van BCM op zich?

2. ANALYSE EN BEPALING AANPAK

• Hoe wordt vastgesteld welke maatregelen het BC plan moet omvatten?

• Op welk niveau van de organisatie worden de analyse en de bepaling van de aanpak voor BCM

uitgevoerd?

• Worden ook externe partijen betrokken bij het BCM en zo ja, welke?

3. OPSTELLEN PLAN

• Uit welke onderdelen/plannen bestaat het BC plan?

• Wat is de vorm van het BC plan? (gedetailleerde beschrijvingen, een checklist, etc)

4. IMPLEMENTATIE

• Hoe worden de maatregelen uit het BCM plan geïmplementeerd?

• Hoe wordt er voor gezorgd dat iedereen weet wat van hun verwacht wordt in het geval van een

calamiteit?

5. BEHEER

• Vinden er oefeningen plaats op het gebied van BCM?

• Hoe wordt gezorgd dat het BCM up to date blijft?

• Vindt er een onafhankelijk controle op de inrichting van BCM plaats?

6. AFSLUITEND

• Wat is de visie van uw organisatie met betrekking tot het BCM voor komende jaren?


A Maturity Model


E Outcome market scan (ad chapter 7)

E.1 Attention for BCM Importance of BCM

General agreement exists on the fact that BCM is important for the organizations, especially in the

changing business environment. Only two interviewees think there is too much attention for BCM

within their organizations. These are 2 public organizations, which are forced to pay attention to

BCM by the GBA regulations. All 28 other interviewees state that BCM is very important and is only

becoming more and more important. They think their organization should pay more attention to

BCM.

However, we must realize that this opinion might not reflect the opinion of the organization in

general, since all people that are interviewed are more than average interested in BCM. Otherwise

they would first of all never have been invited for an interview and second of all they probably would

not have agreed to participate once they would have been asked.

Cause to pay attention to BCM

Within most organizations (23) some immediate cause can be pointed out that either raised or

intensified attention for BCM. 16 interviewees indicate there was an immediate cause that actually

put BCM on the agenda, 7 say there was already attention for BCM but some factor did increase the

attention considerably.

The main causes mentioned by those interviewees are (in order of the times mentioned) the Y2K

threat (mentioned by 6), some external pressure, i.e. regulations or the accountant (mentioned by

8), incidents that have occurred, either within their own organization or somewhere else (mentioned

by 5).

Internal changes within the own organization are mentioned only twice. What is remarkable is that

only one organization states that it started paying attention to BCM due to demands made by their

customers.

7 organizations do not see either an immediate cause for the rise of or a factor that caused an

increase of the attention for BCM. 3 of those indicate that nevertheless there is attention for BCM.

The other 4 indicate BCM does not have any attention yet within their organization.

Business case for BCM

Not one of the organizations has made an explicit business case for executing BCM or not. One

indicates it has done so globally by assessing the different options and the coupled costs and

benefits.

E.2 BCM program management Responsibility and execution of BCM


A Maturity Model


In most organizations the general manager of the organization or the BU is formally responsible for

the BCM. Only in a few organizations, which are relatively mature regarding BCM, the formal end-

responsibility lies at the risk management or operational department.

However, the person that is end-responsible does not always do the execution of the BCM, drawing

up the policy and the plans. Actually, only in very few organizations the general management

executes the BCM. In many organizations the execution is done by the IT or the security

department. In some other organizations BCM is executed by external consultants or a project

group.

In more mature organizations BCM is also often executed by the operations management or risk

management department or a specialized BCM department.

BCM budget

Most organizations do not have a separate BCM budget. Those that do (5), have a budget that only

encompasses the salary costs of the people that plan the BCM (2) or only the project costs for the

start up of BCM (3). It turns out to be almost impossible to have insight in the total costs of BCM,

since it is hard to distinguish the costs that are made for the regular business from the costs that are

made for the continuity assurance.

BCM policy

Only 8 organizations have a special BCM policy for the whole organization. This separate BCM

policy is made by the security department in 2 cases, by the operations department in 2 other cases,

by the policy department in another case and by a specialized BCM department in the last three

cases.

4 other organization have some kind of a global policy, i.e. they oblige their BU's/other sub

organizations to have a BC plan and to a limited extent they coordinate this from a central level. This

global policy is in 3 cases made by the general management and in 1 case by the policy

department.

11 organizations have a limited continuity policy as part of their information security policy. Of the 11

organizations that have BCM policy as part of their IT security policy, at 7 of them the security

department makes this policy. At 2 of them the general management made this policy. At the other 2

some policy department makes this policy.

The remaining 7 organizations don't have any kind of BC policy.

External requirements affecting BC policy

Most organizations have one or more external pressures they should take into account in their BCM

policy. Only one organization states it hasn't.

20 organizations state that regulators/regulations demand certain things regarding their

BCM/continuity management. 8 organizations have to meet demands made by their customers,

either or not recorded in some SLA. 6 organizations have to meet requirements made by their


A Maturity Model


'supervisor', i.e. the government. 2 organizations have chosen to participate in some cooperation

and therefore need to meet some requirements regarding BCM.

Awareness

About half of the organizations that have a BCM/security policy thinks the policy is well known within

the organizations. However, a special BCM awareness program as still rare.

Only 6 organizations have a special BCM awareness program. 9 organizations only have such a

program for security, not especially for BCM. 4 organizations only perform ad hoc activities for BCM

awareness when they think it is necessary. 11 organizations do (almost) nothing to increase BCM

awareness.

E.3 Analysis Standard methodologies

20 of the 30 organizations use some kind of standard methodology for their BCM. Dependent of the

scope, this can be a methodology that only considers the risks regarding IT systems or a

methodology that covers that entire BCM analysis process. 3 of those organizations do not oblige

their departments to use this particular methodology.

Business Impact Analysis

19 of the 30 organizations have identified their critical processes and defined continuity norms for

those processes. 5 organizations have identified their critical systems instead, without basing this on

an analysis of the processes. The other 6 organizations have identified neither critical processes nor

systems.

The 5 organizations that have identified the critical systems instead of processes have only looked

at IT, as you would expect. Of the 19 organizations that have performed a real BIA, 1 only focused

on IT dependencies, 2 have focused on all dependencies except for people, 5 have analyzed all

dependencies inside the organizations but haven't looked at the chain partners. 2 Organizations

have looked at chain partners but not further than what is mentioned in the SLA. The other 9

organizations claim to have analyzed all dependencies.

Risk Analysis

In our interviews we have not really gotten insight in the way the risk analysis is performed. The

people we interviewed often were not the ones who did the RA. Furthermore, even if they were, it

would go to far to check whether they have taken into account all possible risks. The only distinction

we can make is between organizations that do and do not use a standard risk analysis method. 22

organizations use a standard RA method.

However, organizations that do not use a standard method not necessarily conduct a RA of less

quality.

Determination of measures

For about the same reasons as stated above we haven't been able to get real information on how

different organizations determine the measures they are going to take.


A Maturity Model


Level of analysis

Although not all organizations do their analysis just as extensively and thoroughly, as can be

concluded from the statements above, 29 of the 30 organizations do some kind of analysis.

5 organizations perform the analysis on the level of the individual systems. 7 organizations have

performed the analysis for the entire organization (these are in general the smaller organizations)

The other 17 organizations 15 organizations perform the analysis on parts of their organization. 15

have performed their analysis on sub parts of the organization separately, as BU's or departments. 2

organizations perform a separate analysis for each individual product of service.

Of those 17, only 1 organization has integrated the individual plans into one integral plan. The other

16 organizations think there is room for improvement of their BCM by better tuning or integrating the

individual plans. 11 organizations have only tuned the individual plans on some aspects. The 5 other

organizations haven't tuned nor integrated the individual plans.

E.4 Development of the plan Parts of the plan

17 organizations don't have a test plan. However, in some of these organizations it actually is

obligated to have one.

4 organizations have a formal BCM education plan. 4 other organizations state that they don’t have

a separate education plan, but that BCM is an important part of the regular education plan.

15 organizations have a formal maintenance plan that describes the maintenance of the BC plan to

a varying extent. The other 15 don't.

9 organizations don't have any form of escalation plan. 5 organizations have described globally what

are the criteria for a calamity and/or who should decide whether the calamity plan should be put in

action. The other 16 do have some sort of escalation plan.

4 organizations don't have a security plan, the other 26 do. Only 2 of those have tuned or integrated

this plan explicitly and adequately with the BC plan.

22 organizations have some sort of communication plan. In 19 of those media contact is described

too. 18 of those plans contain contact information of parties that should be informed.

5 organizations do not have an evacuation plan, the rest does.

17 organizations have some kind of disaster recovery plan. 3 do not have their own plan, but claim

that their IT service provider should have one. 4 other organizations do have facilities for disaster

recovery but no plan for the usage.


A Maturity Model


15 organizations do not have a process salvage plan. The other 15 do have some sort of process

salvage plan. Not all plans are just as extensive, but this has also to do with the fact that for some

organizations process salvage is not or only to a limited extent possible.

14 organizations have a recovery plan. However, probably not all plans describe the recovery path

in enough detail.

Form of the plan

The form of the various plans differs too much to do some general statements. The only thing that

can be concluded is that the plans of several organizations probably are too extensive too be

practically usable in case of an incident.

BCM software used

Only 2 organizations use special BCM software. A few other organizations state they have looked at

the existing packages for BCM, but they find their own analysis process better. In general the

organizations aren't very enthusiastic about BCM software as guide for the analysis process.

However, several organizations are looking for software that supports the administrative part of

BCM, namely the writing of the plans and the maintenance of them.

E.5 Implementation Realization of the facilities for the BC plan

Our research did not deliver us interesting information on how the measures were implemented.

However, we did discover that the fact that measures are mentioned in the plan does not

necessarily mean these are also actually implemented. To this aspect should be paid careful

attention when analyzing the quality/maturity of the BCM.

Communication of the plan

Having a calamity plan does not guarantee that an organization is prepared for a calamity. Roles

have to be assigned to the right persons and those persons have to know what their roles exactly

encompass. Only about half of the organizations state that the roles defined in their BC plan are

both assigned to the right persons and sufficiently communicated. Most other organizations that

have a calamity plan have assigned roles to the right persons but think the communication of those

could be improved.

About the communication with external parties regarding their roles in the calamity plan about the

same things can be concluded. Regarding those organizations that have a calamity plan that

includes tasks for external parties, less than half of them has sufficiently communicated those tasks.

Most others state that this is partly communicated but not as thoroughly enough as should.

Training/education

11 organizations state they train and/or educate their employees to be prepared for BCM. 5

organizations indicate there is done something to prepare employees, but this training/education is

very limited. The other 14 organizations neither train nor educate their employees for BCM.

Availability plan


A Maturity Model


The most important conclusion we can draw is that the developed plan is not always available, as it

should. If the organization actually has a calamity plan (9 of the 30 don't) in about 25 % of the cases

it is only out in a closet or on the intranet and probably not available if needed. Organizations that

have an up-to-date plan lying in the salvage location and let the relevant people carry the plan with

them, are exceptions.

E.6 Maintenance Testing

18 of the 30 organizations test their BCM to some extent other than just evacuation. The other 12

don't test at all (6) or just test evacuations (6).

Most organizations strive for a test frequency of once a year. Less than half of these organizations

actually realize this frequency. Only one organization tests more often than once a year.

Integral testing appears often too expensive and complex to do. Even for technical tests sometimes

an extra test server is needed. Of the 18 organizations that test, only 4 (all private) state they test

everything they think they should, including the procedures of the plan and the technique. 6

organizations only execute walkthroughs for the procedures in the plan (5 private, 1 public). The

other 8 organizations (2 public and 6 private) only test their technical salvage facilities.

Maintenance process

A good maintenance process makes BCM a process instead of a project. 9 organizations have a

formal maintenance plan and process. 4 organizations have no formal maintenance process, but do

have some formal test or exercise plan.

7 organizations have made some one responsible for the maintenance but only have ad hoc

initiatives and no formal process for it.

8 organizations have no initiative to maintain their BCM and see it more as a project than a process.

The other 2 organizations have nothing that could be maintained.

5 of the 9 organizations that have a formal BC process focus on the entire BCM process when

maintaining BCM instead of only the BC plan itself (so also on training, education, etc.).

BCM as part of change management

If you want your BCM to remain up to date and to make the optimal choices regarding to BCM, you

should take BCM considerations into account when planning projects or other changes. For instance

this could be done by adding a paragraph about business continuity to the standard project

proposal. All though all interviewees acknowledge that BCM should be taken into account in

projects, this is rarely done consistently.

Only 5 interviewees state their organization takes BCM into account in every project, whether or not

under the name of BCM. 10 other interviewees state their organization takes BCM considerations

into account to an increasing extent, but not nearly as often as they would want their organization to

do.


A Maturity Model


6 organizations declare they only take considerations regarding continuity into account in IT related

projects.

The other 9 organizations state that BCM considerations are never or seldom taken into account in

projects.

Planning cycle

Within 6 organizations BCM is part of the planning cycle (5 private, 1 public), within the rest it isn't.

Audit

21 organizations are audited on their BCM, either specifically on BCM or as part of a larger audit. 10

of those 21 are audited by some internal audit party. 3 have asked an external party themselves to

perform an audit on their BCM. 11 organizations have been audited on their BSM as part of the

accountant's certification; however, most of those indicate that this kind of audit is not very detailed.

10 organizations are audited by a governmental audit organization or some other supervising

institution.

8 organizations check whether their suppliers actually act as agreed in contracts regarding BCM. 5

only ask for reportage as a proof. The other 17 do nothing to check these agreements.


A Maturity Model


F Objectives of various SPQS's (ad chapter 8)

A. Facility focus B. Organization focus C. Chain fo cus D. Integrated focus 15

Only part internal assets

on which critical

processes depend

All internal assets on

which critical processes

depend

All internal assets and in-

& outputs from

respectively to chain

partners on which critical

processes depend

BCM process of BU16

integrated/ tuned through

the entire organization

1.Resp

onsibi-

lities

BCM

(i) Responsibilities for

continuity of the facility

covered at least at

highest management

level for facility

(i) Responsibility for

BCM covered at

management team level


BCM covered board

level


BCM covered both at

board level and the

management team level

within each BU

1. Initial

2.

BCM

policy

(i) Objectives regarding

continuity of facility

(i) Policy formulated by

management team

regarding BCM

(i) BCM policy that takes

external parties into

account

(i) Policy of individual

BU's integrated/ tuned

15 This scope stage is only relevant for an organization that executes its BC process separately for an autonomous part of the organization and thus uses a level of analysis that lies

lower than that of the entire organization 16 Where is written 'BU’ , one can read any type of organization part that can serve as a lower level of analysis than the entire organization


A Maturity Model


2.

Planned

1. BC

analysi

s

(i) BIA focused on facility

interruptions

(ii) Risk analysis focused

on facility

(iii) Security, redundancy

and recovery measures

determined

(i) BIA including all

internal dependencies


on internal assets

(iii) BCM measures

determined

(i) BIA including all

internal & external

dependencies


on internal assets and in-

& outputs

(iii) BCM cooperative

measures determined

(i) BIA of all BU's

integrated/tuned

(ii) Risk analysis of all

BU's integrated/tuned

(iii) BCM measures

individual BU's tuned


A Maturity Model


2. BC

plan17

(i) Security plan for

facility

(ii) Escalation plan for

disaster recovery

(iii) Disaster recovery

plan for facility

(i) Preventive plan

(ii) Escalation plan

including description

crisis & disaster recovery

management

organization

(iii) Health and safety

plan

(iv) Salvage and

recovery plan

(v) Communication plan

(vi) Test plan

(vii) Training plan

(i) Plan including active

participation of chain

partners

(i) Preventive plans,

salvage & recovery plans

and BHV plans BU's

tuned

(ii) Organization wide

coordinating escalation &

communication plan

(iii) Uniformity among

plans of various BU's.

3.Implem

ented

1. BC

facilitie

s

(i) Continuity facilities

available for in question

(i) BC facilities available

17 Not all plans mentioned need to be separate plans, but their contents should be part of the BCM plan


A Maturity Model


2. BC

service

s

(i) Continuity services

formally agreed for

facility in question

(i) BC services formally

agreed

(i) Contractual

agreements in behalf of

BCM made (SLA)

(i) Possible (contractual)

agreements between

BU's made (SLA)

2. BC

tasks &

respon

sibilitie

s

(i) Tasks &

responsibilities continuity

plan assigned

(i) Tasks &

responsibilities BC plan

assigned

(i) Tasks &

responsibilities formally

assigned in DAP (Dutch

for file agreements and

procedures)

(i) Possible inter BU

tasks & responsibilities

formally assigned in DAP

(Dutch for file

agreements and

procedures)

4.

Embedd

ed

1.Maint

enance

plan

BCM

(i) Maintenance plan

developed for facility

continuity plan


developed for BC plan


encompasses also

external contracts

(i) Integral maintenance

process designed for

BCM

(ii) Supervision on set-up

BCM


A Maturity Model


2.

Aware

ness

import

ance

BCM

(i) Awareness

importance continuity

facility

(i) Awareness

importance BCM

3.

Familia

rity&

availab

ility BC

plan

(i) Contingency plan for

facility communicated,

including training if

necessary

(ii) Calamity for facility

available in case of

incidents

(i) Contingency plan

communicated, including

training if necessary

(ii) Calamity available in

case of incidents

(i) Contingency plan

communicated with

involved external parties,

including training if

necessary

5.

Controlle

d

1.

Mainte

nance

proces

s BCM

(i) Maintenance process

continuity management

facility executed

(i) Maintenance process

BCM executed

(i) Integral maintenance

process BCM executed


A Maturity Model


2.

BCM

exercis

es

(i) Exercises for facility

continuity plan

performed & evaluated

(i) Exercises for BC plan


(i) Exercises including

external parties


(i) Coordinating

escalation and

communication plan

exercised integrally,

including evaluation

3.

Audit&

control

existin

g BCM

(i) Audit and control on

existing facility continuity

management

(i) Audit and control on

existing BCM

(i) Agreements with

external parties checked

(i) Central supervision on

existence and

functioning BCM

6.

Optimize

d

1.

Strateg

ic

approa

ch

BCM

(i) Continuity

management tuned with

strategy regarding facility

(ii) Continuity part of

managerial planning and

control cycle

(i) BCM tuned with

business strategy

(ii) BCM part of

managerial planning and

control cycle

(i) BCM tuned with chain

strategy

(i) BCM tuned with

strategy of entire

company


A Maturity Model


2.

Contin

uous

improv

ement

BCM

(i) Continuous search for

new possibilities for

improvements continuity

management

(ii) Assumptions BCM

periodically audited

(iii) Maintenance entire

continuity management

process, not only plan

(i) Continuous search for

new possibilities for

improvements BCM


periodically audited

(iii) Maintenance entire

BCM process, not only

plan

(i) Knowledge exchange

with chain partners

in behalf of BCM


actively tuned with chain

partners

(i) Organization wide

knowledge exchange

in behalf of BCM

(ii) Central coordination

of entire BCM process

3. BC

culture

(i) Continuity part of

facility management

(i) BCM part of

organization culture

(i) Relation with chain

partners characterized

by continuity thinking

(i) Relation between

BU's characterized by

continuity thinking


A Maturity Model


G Example general growth strategy (ad chapter 8)

We will illustrate our general growth strategy by giving an example. We consider the following

organization, which has developed a BCM policy, analysis and plan and assigned all important

responsibilities, with regard to all internal dependencies.

G.1 Step 0: Position an organization within the mod el The position of this organization within our model18 would be the following:

G.2 Step 1: Determine the scope In this example the organization chooses the chain focus as the desired scope.

G.3 Step 2: Develop your BCM on that scope at least until it is ‘controlled’

18 For lay-out technical reasons we used the square version of our model for this example, instead of the original

(crooked) one


A Maturity Model



A Maturity Model


G.4 Step 3: Reevaluate the chosen scope, if necessa ry, go back to step 1 In our example, the scope doesn’t change, for instance since the organization does not have any

sub parts which execute their own analysis.

G.5 Step 4: Optional: optimize BCM on the scope In our example, the organization doesn’t consider BCM important enough at this moment to grow to

the optimized level. Its position in our model therefore doesn’t change.


A Maturity Model


H Final model version 0.3 (ad chapter 9)

IT Internal

whole

In- &

external

Entirely

tuned

Focus:

only on IT

dependen-

cies

Focus:

All internal

dependen-

cies

Focus:

All in- and

external

dependen-

cies

Tuned

between

all parts of

the

organiza-

tion

Initiated - Policy formulated,

responsibilities

assigned

Planned - BIA executed

- Plan developed

Implemented - Facilities realized

- Roles assigned

Embedded - Plan distributed,

people internally

instructed

- Maintenance

formally organized

Controlled -Management

monitors existence

BCM

- Exercised

- Maintained, BCM

part change

management

Optimized - BCM competitive

advantage, tuned

with strategy

- Attention for BCM

in management

meetings

- Audit on BCM

- BCM part


- Entire BCM

process maintained

- BCM part planning

cycle


A Maturity Model


I Descriptions final model version 1.0 (ad chapter 9)

I. IT focus II. Organization focus III. Chain focus IV. Integrated focus

1. Initial - Responsibility IT

continuity assigned

- Policy for IT continuity

- Responsibility

business continuity

assigned

- Policy for business

continuity

- Policy tuned with

external parties

- External

dependencies

addressed in policy

- Policies different parts

organization tuned

- Responsibilities BCM

and communication

lines organized

throughout entire

organization

2. Planned - BIA including at least

all IT dependencies BIA

- Risk analysis

executed for IT

- Measures for IT

continuity determined

- IT security plan

- Disaster recovery plan

- Escalation plan for

- BIA including at least

all internal

dependencies

- Risk analysis

executed

- Measures for business

continuity determined

- Preventive plan

- Process salvage and

recovery plan

- BIA including all in-

and external

dependencies

- Communication plan

including all external

communication

- BIA and RA tuned

between different parts

organization

- Plans tuned between

different parts

organization

- BCM plan tuned with

security and health and

safety plan


A Maturity Model


disaster recovery

- Escalation plan

- Communication plan

internal communication

3. Implemented - Facilities for IT

continuity implemented

- Roles disaster

recovery plan assigned

- Facilities for business

continuity implemented

- Roles contingency

plans assigned

- Roles contingency

plans for external

parties assigned

4. Embedded - Disaster recovery plan

distributed, people

instructed (internal)

- Maintenance process

designed for disaster

recovery

- Awareness

importance IT continuity

- BC plan distributed,

people instructed

(internal)


designed for BC plan

- Awareness

importance BCM

- External parties

instructed


including external

contacts

- Integrated

maintenance process

BCM organized

5. Controlled - Maintenance process

IT continuity plan

executed


BC plan executed

- Contingency plan

- Exercised including

contact with external

parties

- Central monitoring of

execution BCM


A Maturity Model


- Disaster recovery

exercised

- BCM part change

management for IT

projects

exercised

- BCM part change

management

- BCM part change

management regarding

external contacts

(including supplier

selection)

- Contracts for

continuity audited

6. Optimized - IT continuity part

planning cycle, BCM on

management agenda

- Maintenance entire IT

continuity process, not

only the plan

- IT continuity

management tuned with

strategy

- IT continuity part of


- BCM part planning

cycle

- Maintenance entire

BCM process, not only

the plan

- BCM tuned with

strategy

- BCM part organization

culture

- BCM actively tuned

with chain partners

- Central audit on BCM


A Maturity Model


J Mapping VKA methodology onto our model (ad chapte r 9)

Figure J.1: Mapping VKA methodology onto our model


A Maturity Model


K Evaluation form

1. Is volgens u het model eenvoudig te begrijpen?

� Ja

� Ja, indien de doelgroep voldoende voorkennis heeft van BCM wel

� Nee, er is uitgebreide toelichting noodzakelijk

2. Zijn naar uw mening alle relevante aspecten voor volwassenheid van BCM meegenomen?

� Ja

� Nee, de volgende aspecten zijn niet terug te vinden in het model:

3. Kunt u uw organisatie plaatsen in het model?

� Nee

Ja, als volgt: (u kunt de volwassenheid aangeven door het aankruisen/inkleuren van de relevante

hokjes)


A Maturity Model


6. Optimized

-Strategische

benadering

-Continue verbetering

-BC cultuur

5. Controlled

-Beheerproces

-Oefeningen

-Audit & control

bestaand BCM

4. Embedded

-Beheerplan

-Bewustzijn belang

BCM

-Bekendheid plan

3. Implemented

-BC faciliteiten

-BC taken

2. Planned

-BC analyse

-BC plan

1. Initiated

- BCM beleid

- Verantwoordelijk-

heden BCM

A. Facility focus B. Organisation

focus

C. Chain focus D. Integral focus

Documents

BUSINESS CONTINUITY MANAGEMENT · Business Continuity Management A Maturity Model Master’s Thesis Informatics & Economics by Naomi Smit - 2005 ii Preface 'Non scholae sed vitae