1

A framework for financial institutions to achieve maturity level 4

based on the DNB assessment framework

Author: Torben Pijpers MSc

VU supervisor: Dr. Abbas Shahim RE

Status: Final

Date: 20th of April 2015

Contact: 0683608405 or torbenpijpers@gmail.com

Thesis number: 2042

2

Preface

This thesis has been written as part of the Postgraduate education IT Audit, Compliance & Advisory at the Vrije

Universiteit Amsterdam.

I’d like to take this opportunity to thank all people who have contributed in the creation of this thesis and which

supported me while writing this thesis.

A specific word of appreciation goes out to the subject matter experts and the 19 experts that helped validate

this thesis at the financial organisation which was visited as part of this thesis. Because of confidentiality

reasons, unfortunately their names are not disclosed. However both their large efforts and their availability for

this research has helped significantly in this thesis and helped create a validated framework. Without them, this

thesis would not have been the way it is now.

My gratitude also goes out to my supervisor at the Vrije Universiteit Amsterdam. Without your patience,

support and valuable feedback this thesis would perhaps not even finish.

Lastly, I’d like to express a word of thanks to my dad, girlfriend and friends who have supported me during the

writing of this thesis.

Enjoy reading,

Amsterdam, 20th of April 2015.

Torben Pijpers

3

Table of ContentsPreface........................................................................................................................................................................... 2

1. Introduction .......................................................................................................................................................... 4

1.1 Background of this thesis .................................................................................................................................... 4

1.2 Definition of problem and research question.................................................................................................... 5

1.2.1 Main research question................................................................................................................................ 5

1.2.2 Sub research questions ................................................................................................................................ 5

1.3 Research methodology.........................................................................................................................................7

1.4 Validity of this research .....................................................................................................................................10

1.5 Scope and limitations......................................................................................................................................... 11

1.6 Relevance of this study ......................................................................................................................................12

1.7 Contents of this thesis ........................................................................................................................................12

2. DNB assessment framework and processes in scope ........................................................................................14

2.1 DNB assessment framework and its origin ......................................................................................................14

2.1.1 Mission of the DNB.................................................................................................................................14

2.1.2 Assessment framework of the DNB .......................................................................................................14

2.1.3 Current compliance to assessment framework.....................................................................................15

2.2 Other frameworks and standards .....................................................................................................................16

2.3 Conclusion..........................................................................................................................................................17

3. Maturity levels of DNB assessment framework .................................................................................................18

3.1 Definitions of maturity levels from the DNB....................................................................................................18

3.2 Generic remarks from DNB of the maturity levels ......................................................................................... 20

3.3 Conclusion..........................................................................................................................................................21

4. Framework to achieve a maturity level of 4 .......................................................................................................... 22

4.1 Defining the framework.................................................................................................................................... 22

4.2 Documenting the creation of the framework in the research database......................................................... 23

4.3 Validating the framework of requirements ..................................................................................................... 23

4.3.1 Subject matter expert validation procedures........................................................................................ 23

4.3.2 Procedures for validation in practice with 19 professionals................................................................ 25

4.4 Conclusion ........................................................................................................................................................ 27

5. Conclusion, reflection and further research.......................................................................................................... 28

5.1 Conclusion of this thesis ................................................................................................................................... 28

5.1.1 Introduction and relevance of this thesis .................................................................................................. 28

5.1.2 Answer to the research questions.............................................................................................................. 29

5.1.3 Answer to main research question ............................................................................................................ 30

5.2 Reflection on research ...................................................................................................................................... 30

5.2.1 Reflection on thesis content ...................................................................................................................... 30

5.2.2 Reflection on thesis experience..................................................................................................................31

5.3 Suggestions for further research.......................................................................................................................31

Appendix A: Framework for achieving maturity level 4 .......................................................................................... 32

Appendix B: Literature used ..................................................................................................................................... 65

4

1. Introduction

1.1 Background of this thesis

In recent years electronic and computer crime has been on the rise (Stagliano and Sillup, 2014). The financial

sector has been one of the major targets of cyber criminals (Lagazio, Sherif, and Cushman, 2014) (Trustwave

security research, 2014) and according to some studies (Choo, 2011) is “the target of choice for financially

motivated cyber criminals”. Among the reasons why cyber criminals target the financial sector is to obtain

information on industrial secrets, employees’ personal data and customers’ credit card information. The attacks

on financial institutions in the Netherlands have not gone unnoticed and are the reason why The Dutch Bank

(“De Nederlandsche Bank”, hereafter “DNB”) has increased its focus on improving the maturity of financial

institutions on information security.

The maturity of financial institutions1 on information security is monitored by the DNB as part of the Financial

Supervision Act (in Dutch: “Wet op Financieel Toezicht”). All financial institutions in the Netherlands are

subject to this Financial Supervision Act. As part of the Financial Supervision Act financial institutions need to

ensure that they have procedures and measures in place to “safeguard the integrity, continuous availability and

security of electronic data”2. To ensure that financial institutions in the Netherlands comply to this, the DNB

requests of financial institutions to perform self-assessments on their IT processes since 2010. The self-

assessments follow an assessment framework created by the DNB3 which was based on COBIT4 and the DNB

expected of these financial institutions that they would reach a maturity level of “3” for their IT processes.

Since 2010 information security has even increased in importance (Whitman and Mattord, 2011) and along

with it also DNB’s expectation of the necessary maturity of IT processes of the financial sector in the

Netherlands. In May 2014 the DNB announced5 that it expected of the financial sector that for three IT control

objectives of the framework the IT processes would be of a maturity level of “4”. The three IT controls are “4.1

IT risk management framework”, “4.2 Risk assessment” and “4.3 Maintenance and monitoring of a risk action

plan” and the DNB chose these three controls to increase the resilience of the financial sector against

cybercrime.

With the increasing importance of information security and with recent more stringent regulation from the

DNB (van Solms, 2005), the expectation is that in the future IT processes of the financial sector need to be

further strengthened and therefore the maturity of financial institutions needs to be improved as well.

Generally it is expected that the DNB will at some point in the future announce that all IT processes need to

have a maturity level of “4”.

1 “Financial institutions” as stated in this thesis refer to banks, insurance agencies, pension funds and assetmanagement agencies in the Netherlands.2 Website of the DNB, http://www.toezicht.dnb.nl/en/3/51-203304.jsp3 Refer for an overview of the DNB assessment framework to Appendix A.4 COBIT is short for Control Objectives for Information and related Technology, refer for more information onCOBIT to section 2.1.4 of this thesis5 Website of the DNB, http://www.toezicht.dnb.nl/binaries/50-230767.pdf

5

Currently the DNB has provided an assessment framework with control objectives and controls and has also

provided a “Points to consider” document which includes COBIT and ISO points to consider for implementing

those controls. However the “Points to consider” document from the DNB is not a concrete overview of IT

requirements6 which are mandatory; instead it is an overview of possible points that financial institutions can

implement to improve their processes. Also, it does not include what exactly is needed to reach a certain

maturity level for each of the controls of the DNB assessment framework. The different levels of maturity are

given (these are: 0, 1, 2, 3, 4, 5 or not applicable) and a general definition of each level is given in general terms.

However there are no requirements on a control level of what is necessary for financial institutions to reach a

certain maturity level per control. Therefore it is unclear for a specific control objective or control what exactly

needs to be in place for a financial institution to reach a certain maturity level.

This means that for financial institutions in the Netherlands that soon they need to achieve a maturity level of 4,

however that there is still uncertainty what exactly needs to be in place to be able to reach that maturity level.

1.2 Definition of problem and research question

From the description above the clear problem arises that organisations in the financial sector in the

Netherlands need to reach a maturity level of 4 on the DNB assessment framework in the future and that it is

uncertain what exactly needs to be in place for organizations for their IT processes to have a maturity level of 4

on all controls of the DNB assessment framework. This thesis aims to provide insight in what needs to be in

place for financial institutions in order to achieve a maturity level of 4 on the assessment framework of the

DNB.

1.2.1 Main research question

The main research question of this thesis is therefore:

1. What is an appropriate framework for financial institutions in the Netherlands to

achieve a maturity level of 4 based on the DNB assessment framework?

1.2.2 Sub research questions

To answer the main research question above the following sub research questions have been defined:

1. What is the DNB assessment framework?

There are various frameworks for IT processes which could be used to determine maturity levels. For

instance COBIT, ITIL and the DNB each have their framework although they do have their similarities

or in the case of the DNB assessment framework, it is based largely on COBIT. For this thesis the DNB

assessment framework is used because the DNB is the regulating organisation in the Netherlands for

financial institutions.

6 “A requirement” or “requirements” are reoccurring words in this thesis. A requirement in this thesis is definedas a necessary condition to achieve something. In the case of this thesis specifically it means a necessarycondition to achieve a maturity level of 4 on the DNB assessment framework.

6

As a starting point for this thesis, insight is given in the DNB assessment framework and its contents.

As part of the DNB assessment framework, the DNB maturity level definitions are also be presented.

The information needed to be able to answer this question are academic journals, books and the

website from the DNB. The research question is therefore answered by literature study and this

approach is chosen to provide a theoretical background and input for answering research question 3.

2. What is a maturity level of 4 based on the DNB assessment framework?

To be able to determine what the framework is for financial institutions to obtain a maturity level of 4,

we need to know what it means to achieve this level based on the DNB assessment framework. By

answering this research question we have an understanding of the definitions of maturity levels

(including 4) for the DNB assessment framework. We also analyse the definition for a maturity level of

4 to analyse what is expected by the DNB.

The information needed to be able to answer this question are the maturity level definitions, academic

journals, books and the website from the DNB. The research question is therefore answered by

literature study and this approach is chosen for the same reason as research question 1: to provide a

theoretical background and input for answering research question 3.

3. What is an appropriate framework to achieve a maturity level of 4 based on the DNB

assessment framework?

Once we have an understanding of the DNB assessment framework and the maturity levels, we can

start defining for each of the control measures of the DNB assessment framework what the concrete

requirements are to achieve a maturity level of 4. The appropriate framework is then the combination

of the DNB controls and the requirements as defined by this thesis. This is defined as concrete as

possible while also keeping a degree of flexibility to be usable by different organisations.

To answer this research question it is defined per control measure of the DNB which requirements need

to be in place to achieve a maturity level of 4. This results in an initial framework of (1) IT processes of

the DNB assessment frame and (2) corresponding IT control measures of the DNB assessment

framework and (3) concrete requirements per control measure of what is necessary to achieve a

maturity level of 4 on that control measure.

The information needed to be able to this question is gathered from the COBIT v4.17, the DNB

assessment framework, from the “Points to consider” document from the DNB website and the

professional experience of the author.

7 COBIT version 4.1 was selected for this thesis since COBIT version 4.1 was used by the DNB when creating theDNB assessment framework. Therefore for financial institutions that want to achieve a high maturity on theDNB assessment framework, we considered COBIT version 4.1 to be the best match.

7

1.3 Research methodology

To give an answer to the 3 research questions above this section defines the approach and methodology used for

answering the research questions.

The model illustrated in figure 1 was used to design and describe the research approach of this thesis. This

model is based on Yin (2013).

Figure 1 – research approach model (Yin, 2013)

Plan phase

This research started with an initial question of how to achieve a maturity level of 4 based on the DNB

assessment framework. This question came from the industry in which the author works. Since the DNB

monitors the maturity on the DNB assessment framework, is becoming more strict and because as a regulatory

body has the power to impose actions on financial organisations who do not score (sufficiently) on the DNB

assessment framework, this question is very relevant for Dutch financial organisations. This research question

has started this thesis, has been split up in the research questions in section 1.2 and is leading in the further

design of this thesis. This thesis has been written between December 2014 and April 2015.

Design phase

To provide a structure to design the research the above shown research approach model is used and for all

phases it is described what these mean for this thesis and how they help in answering the research questions. As

part of the explanation of the phases the following topics are discussed for different phases: the research

methods used, the data collection techniques and the selection of participants for validation techniques.

For research questions 1 and 2 the methodology used is literature study (Baxter and Jack, 2008). To be able to

find the necessary information first the website of the DNB is used because this contains the DNB assessment

framework and the maturity level definitions. This information from the DNB on the assessment framework

and the maturity levels is analysed and it is researched in academic literature and journals what these state

about assessment frameworks and maturity levels.

8

For research question 3 an appropriate framework to achieve a maturity level of 4 is defined. The appropriate

framework is in the form of concrete requirements per control measure of the DNB assessment framework. The

concrete requirements are first gathered from various sources. Initially the sources used are the DNB

assessment framework itself, COBIT v4.1, the “points to consider” document from the DNB website and the

professional experience of the author. For each control measure of the DNB assessment framework it is defined

what the requirements are based on these sources. Sometimes multiple sources are used to define one

requirement. For instance if the control measure already describes that a certain policy should be present then

this could result in a requirement but the requirement can be made more specific by what COBIT says about

that policy and/or by what the professional experience is of the author. By analysing each control measure and

defining the requirements, the output is a framework of the control measures from the DNB assessment

framework with for each control measure the requirements that are necessary to achieve a maturity level of 4 on

the DNB assessment framework.

To improve the validity of the framework, the framework is validated with 2 groups. It is validated with subject

matter experts (Huber, 1998) and it is validated in practice (Richie et al., 2013) by validating the framework

with professionals of a financial organisation in the Netherlands.

The expert validation has the following structure:

1. 3 experts are selected based on their experience. The reason why they are selected and a

summary of their background is stated.

2. The initial framework is reviewed by the experts in which they have been asked to review (1) if

they agree with each of the requirements per control measure of the framework and (2) if they

consider any requirements to be missing.

3. The review of the experts is discussed with the experts to gain a thorough understanding of any

adjustments or new input that has come up from their review.

Based on the expert validation the initial framework is adjusted and/or expanded to include requirements that

came up from the expert validation. The information needed to be able to validate the framework has been

received from experts. This approach was chosen to create a concrete set of requirements based on accepted

standards as well as a concrete set of requirements that is tailored to the DNB assessment framework.

The validation in practice has the following structure:

1. A financial institution is selected that is based in the Netherlands and is large enough (IT

department of at least 50 employees). Preferably this organisation should perform most of its IT

processes themselves as opposed to having (a large part of) their IT processes outsourced to third

parties. This makes it both easier to discuss the IT processes and makes it more likely that

information is more readily available for all IT processes.

2. At the financial institution a relevant professional for each IT process is identified. This

professional should be knowledgeable on how that IT process is performed at the organisation.

3. Each IT process is discussed with the relevant professional. For the discussion the framework

with concrete requirements to achieve a maturity level of 4 is used and the requirements per

9

control per IT process are discussed. For this discussion a standardized format is used which is

further described in chapter 4. The standardized format ensures that it is verifiable how the

validation in practice has been performed and that the same approach for the validation in

practice is performed for all IT processes.

Prepare phase

The prepare phase has the following main activities (Shahim and Matthijse, 2010):

1. “Hone researcher skills.

2. Prepare and verify for the research.

3. Develop a research protocol.

4. Conduct a pilot study”.

For this thesis there are 2 important steps in the creation of the framework to achieve a maturity level of 4 on

the DNB assessment framework:

1. The definition of concrete requirements resulting in a framework.

2. The validation of the framework with subject matter experts and in practice.

Because this research is of a qualitative nature (May and Pope, 1995), in both of these steps any author would

have a significant influence on the outcome. However, to approach this research as unbiased and without

preconceived notions as possible, a standardized approach is used in defining the requirements and a

standardized set of questions is used for each of the persons that is asked to validate the framework (Boudreau

et al, 2001). Both the standardized approach and the standardized set of questions are presented in chapter 4.

It is chosen not to perform a pilot study for this research. In several meetings with professionals from financial

organisations it was already evident that the research question was of relevance to financial organisation in the

Netherlands. A pilot study could help in collecting more or better data when performing the validation

procedures, however since there are numerous validation interviews instead it was chosen to evaluate after the

first validation interviews if the validation procedure is effective.

Collect phase

For the creation of the framework of requirement it has already been described that the information required is

collected from an analysis of the DNB assessment framework itself, COBIT v4.1, the “Points to consider”

document from the DNB website and the professional experience of the author. In addition to that, as a

preparation for creating the framework, various sources of literature have been studied (which have been

referred to in the literature overview in Appendix B) and interviews have been held in preparation of this thesis.

For the validation of the framework a semi-structured interview is used (Bariball and While, 1994). A

standardized set of questions is defined before the validation interviews take place, however depending on the

specific topic discussed and the answers of participants follow up questions have been asked on the spot to fully

understand any feedback validation participants provide.

10

Analyse phase

Feedback given by validators is written in the research database and based of this feedback concrete

requirements of the framework have been adjusted and added. For all requirements of the framework it is

documented which sources the requirements came from (including if it came from a validator, either subject

matter expert of from a practice professional). Through this detailed documentation of where requirements

come from, we aim to create not only a framework of requirements but also show how it was created and which

sources of input have been used for each requirement.

Share phase

The final share phase includes making this thesis public. Also, a final conclusion is given in which the research

questions and main questions and the answers to these questions are presented.

1.4 Validity of this research

This section is written to support decision made in the choice of research questions and the approach used to

answer them. In quantitative research studies discussions on the reliability and validity are necessary elements.

In qualitative research these are not always provided even though “the accuracy, dependability and credibility

of the information depend on it” (Simon, 2011). This thesis and the research questions are qualitative in nature;

there is no empirical element used in answering the research questions (Onwuegbuzie et al, 2007). In

qualitative research, one of the ways in which the validity of the research can be verified is through “expert

review” and “member checking” (Simon, 2011) .

Expert review is performed by subject matter experts in the field in which the research is performed (Creswell

and Miller, 2000). When using expert review it is important that it is described how and why the experts have

been selected. In addition, better and more consistent results are achieved when the experts are provided with a

guide or instrument. When the expert review is performed, therefore a guide for expert reviewers is provided.

This is in the form of a set of questions that expert reviewers should answer. This set of standard questions

helps in the consistency of their review (Sandelowski, 1993).

Member checking “is the process of verifying information with the targeted group” (Simons, 2011) and also is a

validation method of qualitative studies (Carlson, 2010) (Rolfe, 2006). Member checking is used in thesis as

part of answering research question 3 and to provide validation of the framework of requirements. In the same

way, a guide or instrument is used to improve the consistency of the verification from the target group (a

financial organisation) of the framework of requirements to achieve a maturity level of 4 on the DNB

assessment framework.

Simon (2011) further describes that in qualitative studies it is important that for the member check it is

described how the review has resulted in alterations. This increases the validity (and trustworthiness) of the

research. Therefore the alterations are described from the member check but also from the expert review.

11

Since expert review and member checking improve the validity of qualitative research, and since they are also

applicable to the review of a framework of requirements, these 2 methods are chosen for this research and are

applied on the framework of requirements which results from answering research question 3.

1.5 Scope and limitations

This are 3 main limitations which help in giving this thesis focus. These are explained below.

Limitation 1: this thesis uses information from the DNB website but does not use other input from DNB, such

as input from an interview with DNB (IT) employees.

As a starting point of this thesis the assessment framework of the DNB is used. This thesis aims to create insight

into which IT elements are necessary to achieve a maturity level of 4 of all control objectives of the DNB

assessment framework. A straightforward approach would be to inquire with the DNB and request what exactly

is necessary for a maturity level of 4. However, this thesis has been started because financial institutions

approached us to gain more insight in what is necessary to achieve a maturity level of 4 since the DNB is not yet

providing more information than the contents available on their website. Therefore for this thesis we used the

DNB assessment framework from the DNB website, but did not conduct further interviews with the DNB.

Limitation 2: this thesis researches what is necessary to achieve maturity level 4 but does not consider a

specific starting point.

By researching how to achieve maturity level 4 for all controls in the DNB assessment framework the goal is

clear. The starting point for financial institutions is different and can vary between organisations. Some

organizations might be below maturity level 3 and others might be above it. Some financial institutions might

already be above maturity level 4. Even between different controls the maturity likely differs per organisation.

This thesis does not take into account all the possible different starting points, instead it describes what is

necessary to achieve a maturity level of 4. By providing a framework for the achieving a maturity level of 4

financial institutions could verify themselves which of their processes and/or controls need improvements and

which are sufficient.

Limitation 3: this thesis considers what needs to be in place to achieve level 4, not the organizational change

necessary to implement IT elements. In other words: this thesis describes what to do and not how to do it.

Identifying which processes needs to be improved and which are sufficient when aiming for maturity level 4 is

only a first step. If an organisation wants to improve its processes that are not yet at maturity level 4 then this

would be the next step. This thesis does not take into account how these improvements can be made for two

reasons:

- This thesis does not aim to add to the body of knowledge of organizational change since this field has

been thoroughly studied already (there are many references that can be made, refer for instance to the

book “Organizational change and development” (Cummings and Worley, 2014) and to the book

“Organizational development: the process of leading organizational change” (Anderson, 2013)”.

- The type of organisational change necessary might be very different between organisations. Those that

have their processes already near maturity level 4 might only need minor improvements for which no

12

large organizational change is necessary. On the contrary, organisations who are far from reaching

maturity level 4 might need much larger programmes to improve their processes. Because these

situations are so different, this thesis does not focus on the road to the end goal but only on what the

end goal of the road looks like.

1.6 Relevance of this study

Practical relevance

Since financial institutions in the Netherlands are subject to the Financial Supervision Act they have to ensure

to comply with the regulations from the DNB. Currently the DNB expects financial institutions to have

procedures and measures in place to safeguard the integrity, continuous availability and security of electronic

data8. The DNB created the assessment framework to determine if organisations have these procedures and

measures in place and currently expect financial institutions to achieve a maturity level of 3 since 2010. Already

in June 2015 three IT controls will need to have a maturity of 4 and since the expectation is that soon all IT

controls will need to be at a maturity level of 4 it is relevant for all financial institutions in the Netherlands to

know which elements they need to have in place for all IT controls of the DNB assessment framework.

Academic relevance

Currently in the field of IT and IT audit research there is no framework or concrete framework available to

determine for financial institutions (or other organisations) what needs to be in place per control of the DNB

assessment framework to achieve a maturity level of 4 on that same assessment. This thesis does produce such

a framework and therefore contributes to the body of knowledge of IT audit research and the IT audit field.

1.7 Contents of this thesis

This thesis contains 5 chapters as illustrated in figure 2 below which are all relevant to understand this thesis

and its outcome.

Chapter 1 (this chapter) introduces the topic of this thesis and describes the foundation by presenting the

background and the central research question. The central research question is divided into sub research

questions which help in answering the main question. The sub research questions are translated into an

approach found in the research model.

Chapter 2 contains the literature study on the DNB assessment framework in which further insight is given in

how and why the DNB assessment framework was created by the DNB. Also it is presented how Dutch financial

institutions currently comply with the DNB assessment framework. This chapter gives an answer to research

question 1.

Chapter 3 contains the literature study on the DNB maturity level definitions. For the maturity levels

information from the DNB and COBIT is used. This answers research questions 2.

8 Website of the DNB, http://www.toezicht.dnb.nl/en/3/51-203304.jsp

13

Chapter 4 provides insight in what needs to be in place for financial institutions to achieve maturity level 4 of

the DNB assessment framework for each of the controls of said framework. This results in a framework which

states for each control what needs to be in place. This gives an answer to research question 3. Subsequently, the

framework is validated by subject matter experts and in practice to determine that the framework can be

applied and produces meaningful results. Chapter 4 contains both the creation of the framework and the

validation.

Chapter 5 gives a conclusion and an answer to the main research question and the three research questions. In

addition it includes a reflection on this thesis.

Figure 2 – contents of this thesis

Chapter 1

Introduction andthesis approach

Chapter 2

Further insight inDNB assessment

framework

Chapter 3

Further insight inthe DNB maturity

levels

Chapter 4

Creation andvalidation offramework of

requirements toachieve a

maturity level 4.

Chapter 5

Conclusion,answer to main

research questionand suggestions

for furtherresearch

14

2. DNB assessment framework and processes in

scope

This chapter gives an answer to the first research question of this thesis: “What is the DNB assessment

framework?”. To do this, in this chapter theoretical background is given of the main topics used in this thesis

and on the DNB assessment framework. It is presented what the mission of the DNB is and why they created

the DNB assessment framework. Furthermore this chapter gives insight into current compliance to the DNB

assessment framework and a short overview of other IT frameworks.

2.1 DNB assessment framework and its origin

2.1.1 Mission of the DNB

The DNB “seeks to safeguard financial stability and thus contributes to sustainable prosperity in the

Netherlands”9. To be able to do this, the DNB acts as a supervisor of the Dutch financial sector to ensure 3

goals:

1. “Price stability and balanced macroeconomic development in Europe, together with the other central

banks of the Eurosystem.

2. A shock-resilient financial system and a secure, reliable and efficient payment system.

3. Strong and sound financial institutions that meet their obligations.”10

To be able to achieve the 2nd and 3rd goal, financial institutions need to have sound processes around

information security. Without these processes financial institutions would be much less stable and more prone

to cybercrime. In worst cases, this could result in a loss of financial data, loss of trust from society and financial

losses (Baveco, 2014).

2.1.2 Assessment framework of the DNB

To ensure that financial organisations have sound information security processes the DNB expects that

financial organizations should have “adequate procedures and measures should be in place to control IT

risks”11. These procedures and measures should ensure the continuity of IT (and thereby the organisation) and

the security of information. To determine if this is the case the DNB has created an assessment framework with

which financial organisations can perform an assessment to determine the maturity of their IT processes.

DNB’s assessment framework is based on COBIT v4.112. The assessment framework includes 21 control

objectives which are divided over the following 6 areas:

- Strategy & policies.

- Organization.

- People.

- Processes.

- Technology.

9 DNB website, http://www.dnb.nl/en/about-dnb/onze-missie/index.jsp10 DNB website, missions statement, http://www.dnb.nl/en/about-dnb/onze-missie/11 http://www.toezicht.dnb.nl/en/3/51-203304.jsp12 Refer for the assessment framework of DNB to http://www.toezicht.dnb.nl/en/3/51-203304.jsp

15

- Facilities.

The DNB assessment framework includes the 21 control objectives (refer to appendix A for an overview of all

control objectives) which are further divided into 54 control measures. For these DNB assessment framework

controls on information security it is indicated to which COBIT controls and ISO 27002 controls these are

related. In addition, the DNB has provided a “points to consider” document for the self-assessment. The “points

to consider” addition from the DNB does include for each control several statements which can help in

determining the maturity level for a control (for an example of a statement, see: “Determine the effectiveness of

the collection and integration of information security requirements into an overall IT security plan that is

responsive to the changing needs of the organisation”).

2.1.3 Current compliance to assessment framework

Currently financial institutions are expected to have a maturity of level 3 on the DNB assessment framework.

However not all organisations actually obtain this level for all their processes. It has been researched by the

DNB and NOREA if the financial sector currently obtains a maturity level of 3 for its controls, refer for the

outcome to figure 3.

Figure 3 - Overview of controls below maturity level 3, green is 3 or higher, red is lower than 3. (Van

Oossanen and Biekart, 2014)

According to the DNB and NOREA (van Oossanen and Biekart, 2014) in 2010 still 41% of the controls in the

financial sector were below level 3. This has improved to 28% in 2013 which still means that a substantial

amount of controls are not yet at a maturity of level 3 and much improvement is needed to get these to an even

higher maturity.

This means that it we expect that at the time of writing this thesis (2015) that many financial institutions likely

still not don’t have all their controls at a maturity level of 3, let alone at a maturity level for 4. This further helps

the assumption that a framework of what is necessary to achieve a maturity level of 4 is helpful for financial

institutions because there is a definite area for improvement.

16

The topic of non-compliance to a maturity level of 3 on the DNB assessment framework is not an area that is

discussed in current literature. From discussions with the selected financial institution for validating the

framework of requirements in chapter 4, as well as from discussions with colleagues of the author it appears

that the DNB can act strongly upon prolonged non-compliance. In the case of the financial institution selected

in chapter 4 the DNB was not demanding in their compliance request and the extent of monitoring from the

DNB was not exactly known. It was assumed that the DNB was less strict with that particular financial

institution because of sufficient performance on the DNB self-assessment in previous years. From discussions

with colleagues (who as IT auditors in the financial sector frequently discuss the IT environment and

compliance with various financial institutions) another case was known for a large insurance company in the

Netherlands which performed weakly on IT continuity for several years. In this case the DNB set an ultimatum

when the deficiency had to be resolved. It is not known exactly to what extent the DNB performs monitoring on

performance on the self-assessment nor is it known exactly how severe their response to non-compliance is.

This is also not the goal of this thesis. It is sufficient to know that the DNB as a regulating authority has the

power to demand improvements and has done this in the past. Of course, a strong IT environment and a high

maturity on information security is important also for the stability of a financial organisation’s operations.

2.2 Other frameworks and standards

The DNB already started using IT frameworks for financial organisations in 1988 when they released the

“Memorandum met betrekking tot de betrouwbaarheid en continuïteit van de geautomatiseerde

gegevensverwerking”(Koning and Bikker, 2012). This first framework was developed by DNB itself at a time

when there were not many other frameworks available yet. This has changed significantly since 1988. Before the

turn of the century several frameworks have been created or have increased in popularity (Lemus et al., 2010).

Currently, the main well known standards are ITIL, ISO and COBIT (Nastase et al., 2009) (Sahibudin et al.,

2008). Each of these have their own focus or approach to organisations.

COBIT is described as a high-level governance and control framework (Nastase et al., 2009) (Tuttle and

Vandervelde, 2007) and is “the worldwide accepted standard which prescribes areas and individual controls for

IT governance, informatics and related IT processes” (Radavanovic, Radojevic, Lucic, Sarac, 2010). COBIT also

includes business and IT goals as well as maturity level definitions (Morimoto et al., 2009). The latest version

of COBIT is version 5 which has been released in 2012. However, when the DNB created the assessment

framework for information security, the latest version of COBIT was version 4.1. The DNB has stated that their

assessment framework is based on COBIT13. COBIT (Control Objectives for Information and related

Technology) is a framework for a structured implementation and the assessment of an IT environment

(Heusinkveld, 2014) (Hardy, 2006). Because the DNB assessment framework used COBIT version 4.1 in the

creation of their framework, for this thesis also COBIT version 4.1 is considered when determining the

requirements in chapter 4.

ISO standards 27001 and 27002 provide an information security framework and thereby also provide guidance

for organisations looking to improve their information security. The ISO standards have been split up in 27001

and 27002 where ISO 27001 is aimed at management and provides principles and ISO 27002 is more technical

13 Website of the DNB, http://www.toezicht.dnb.nl/en/3/51-203304.jsp

17

and provides guidance on actual implementation (Radavanovic et al., 2010). Since ISO 27001 and ISO 27002

are not specifically considered by the DNB in the formation of their assessment framework (or at least we have

no evidence of this), ISO 27001 nor ISO 27002 are not specifically used when defining the concrete

requirements per control measure of the DNB assessment framework.

ITIL also provides a framework which is considered a best practice framework for service management

processes (Nastase et al., 2009). ITIL’s focus is on aligning the IT services with the needs of the organisation

and has been started by the UK government (Spremic et al., 2008). Like ISO 27001 and ISO27002, the DNB did

not specifically use ITIL when defining the DNB assessment framework. Therefore similarly for ITIL it is not

specifically used when defining the concrete requirements. However for both ITIL and ISO27001/ISO27002,

when defining the requirements in chapter 4, if additional information on a specific topic is needed frameworks

like ITIL or ISO27001/ISO27002 might be consulted.

2.3 Conclusion

This chapter aimed to provide insight in the DNB assessment framework and thereby give an answer to

research question 1: “What is the DNB assessment framework?”. We conclude that the DNB assessment

framework was created to help financial organisations have sound information security processes and to control

IT risks. Also we found that the DNB expects from financial organisations that their procedures and measures

should ensure the continuity of IT (and thereby the organisation) and the security of information.

We found that the DNB assessment framework is based on COBIT version 4.1 which is also why we’ve selected

COBIT version 4.1 as the COBIT version which we consider throughout this thesis. The DNB assessment

framework is divided in 21 control objectives which have 54 control measures.

The DNB assessment framework is far from the only framework or standard for measuring, governing of

creating IT organisations and IT processes. Currently, the main well known standards are ITIL, ISO and COBIT.

We have discussed each of these in section 2.2 and found that each of these have their own focus or approach to

organisations. Since COBIT has had the biggest influence on the creation of the DNB assessment framework,

COBIT is also considered mostly in the remainder of this thesis and specifically when defining the requirements

in chapter 4.

When we analysed if currently financial organisations comply sufficiently to the demands of the DNB on the

DNB assessment framework, we found that the DNB currently expects of financial organisations to have a

maturity level of 3. Currently not all financial organisations in the Netherlands comply sufficiently with the

maturity level of 3 of the DNB assessment framework, let alone a maturity level of 4. As a regulatory body of

the Dutch financial industry, the DNB has the ability and power to demand improvements from financial

organisations. It has also done so in the past. Already in June of 2015 the DNB will expect a maturity level of 4

for three of the areas of the DNB assessment framework (as described in the introduction in section 1.1). With

the increasing importance of information security and with recent more stringent regulation from the DNB, the

expectation is that in the future IT processes of the financial sector need to be further strengthened and

therefore the maturity of financial institutions will need to be improved as well.

18

3. Maturity levels of DNB assessment framework

This chapter gives an answer to research question 2: “What is a maturity level of 4 based on the DNB

assessment framework?”. To be able to give an answer to this question first the maturity levels as described by

the DNB is presented. Subsequently these are analysed, specifically for a maturity level of 4, and it is

determined what the goal is of a maturity level of 4.

3.1 Definitions of maturity levels from the DNB

Along with the DNB assessment framework, the DNB has provided general definitions on its website14 of the

maturity levels that an organisation could have. The definitions for the maturity level provide a general

direction of what is expected. However, the DNB does not provide for each control measure which requirements

exactly need to be in place. That is the goal of this thesis.

The DNB has given the following definitions for maturity levels:

Level Control is: Criteria0 Non-existent - No documentation. There is

no awareness or attention for certain control.

1 Initial/ad hoc - Control is (partly) defined,but performed in an inconsistent way. Theway of execution is depending onindividuals.

2 Repeatable but intuitive - Control is inplace and executed in a structured andconsistent, but informal way.

The control execution is based on an informal, unwrittenthough standard practice.

3 Defined - Control is documented, executedin a structured and formalized way.Execution of control can be proved.

* Formal control is available for any critical process.* Critical processes and controls are identified based on riskassessments.* There is evidence of implementation of the control* Formal “test of design effectiveness” constitutes evidencefor level 3.* Formal “test of operating effectiveness” constitutes evidencefor level 3.*The test of operating effectiveness should be done over anappropriate period which fits the risk profile.

4 Managed and measurable - Theeffectiveness of the control is periodicallyassessed and improved when necessary. Thisassessment is documented.

Criteria for level 3 plus the following:* The periodic evaluation of the control is documented,including any identified action for improvement.*The frequency of the periodic evaluation should be based onthe risk profile.* The frequency of this assessment should be at least annually.

5 Optimised - An enterprise wide risk andcontrol programme provides continuous andeffective control and risk issues resolution.Internal control and risk management areintegrated with enterprise practices,supported with automated real-time

Distinguishing criteria are:* Continuous improvement.* Comparing control performance with market data of otherenterprises.* Advanced IT-support as workflow processing andintegration.

14 http://www.toezicht.dnb.nl/binaries/50-230767.pdf

19

Level Control is: Criteriamonitoring with full accountability forcontrol monitoring, risk management andcompliance enforcement. Control evaluationis continuous, based on self-assessments andgap and root cause analyses. Employees areproactively involved in controlimprovements.

Table 1 – Overview of definitions of different maturity levels as defined by the DNB (Source:http://www.toezicht.dnb.nl/binaries/50-230767.pdf)

It should be noted that in addition to these levels, the DNB assessment framework also gives the possibility of

indicating that a control is “not applicable” which should therefore be added to the different options that a

control outcome can have.

It can be seen from the table above that the maturity levels range a level of 0 where there is no awareness of

attention to being in control and not having defined controls to a level of 5 where the organisation has an

enterprise wide risk and control programme and continuously risks and controls are monitored and evaluated.

Based on the above table of maturity definitions from the DNB we can see that to achieve a maturity level of 4

that both the criteria for a maturity level 3 and for 4 should be met. For level 3 it can be seen that controls for IT

processes should be formalised; they should be defined (as part of a control framework) and they should be

tested over an appropriate time on both their design and operating effectiveness. In addition this test should be

documented and the evidence should be available.

A maturity level of 4 assumes all of the above for level 3 but goes a step further by saying that a periodic

evaluation of controls’ effectiveness is performed, that improvements actions should also be defined, that the

periodic evaluation of controls is performed at least annually and that a higher frequency of evaluation is also

possible if the risk of the process is higher. A suitable and efficient way of performing such an evaluation is to

perform a risk assessment of the control environment periodically (Peltier, 2005) (Pederiva, 2003). A risk

assessment according to COBIT has the following steps:

# Activity

1 Determine the likelihood of identified risks qualitatively (e.g., very likely, probable, improbable) or

quantitatively using statistical analysis and probability determinations, based on reasonable sources of

information that can be appropriately validated.

2 Determine the material impact on the business of identified risks qualitatively (e.g., catastrophic, critical,

marginal) or quantitatively (e.g., impact on revenue or shareholder value).

3 Assess risks inherent in the event and after considering the controls that are in place to identify the

residual risks for which a risk response will need to be determined.

4 Document the results of the risk assessment, showing the method followed to come to the conclusions.

Table 2 – Overview risk assessment steps (Source: Website of ISACA

http://www.isaca.org/Groups/Professional-English/po9-4-risk-assessment/Pages/Overview.aspx)

20

Based on the table above we see that a risk assessment starts with identifying and determining the likelihood of

risks, followed by determining the impact, assessing mitigating controls for risks and the risk assessment ends

with documenting the outcome of the risk assessment. In chapter 2 we saw that the DNB assessment

framework includes 21 areas with 54 control measures. Also we noted in the beginning of this section that the

DNB assessment framework includes an option to mark specific control measures as “not applicable”.

Combining these two, it is a sensible approach for financial organisations that want to achieve a maturity level

of 4 on the DNB assessment framework to perform a yearly risk assessment in which critical processes and

controls are identified and it is evaluated how important each area and control measure of the DNB assessment

framework is for the organisation. It could be that some areas and control measures are not relevant due to the

specifics of that organisation’s IT environment or IT implementation. The DNB assessment framework also

facilitates organisations in making these evaluations by giving the possibility of marking certain control

measures as “not applicable”.

Further evaluation of the definition for a maturity level of 4 shows that to achieve that level that the identified

controls are periodically assessed and improved. For the improvements the identified actions for improvement

are defined and assigned to owners. Since this is clearly stated in the definitions this is included in the

framework of requirements which is defined in chapter 4. When the concrete requirements are defined for each

of the control measures, per control measure the following is included:

“- The above requirements are periodically evaluated as part of a control or multiple controls. Based on the

results follow up actions are defined and assigned to owners.”

3.2 Generic remarks from DNB of the maturity levels

In addition to providing the definitions of the maturity levels the DNB has provided general comments on

maturity levels. The DNB has also given the following generic remarks on using the maturity levels in a letter on

the DNB assessment framework and the maturity levels15:

- “For all controls, management may vary control and process implementation across the organization

based on the situational risk profile and business context including local requirements by law and

regulators. Processes (business and IT) are not equally critical in every situation. The need to

demonstrate the required maturity level pertains only to key financial processes and assets and to

essential supporting processes.

- Based on a risk assessment management may choose to differentiate control objectives and strictness of

control measures.

- Control objectives are aimed to define WHAT has to be managed on a mature level. The ‘Points to

consider’ are provided to give guidance. Financial institutions should determine HOW they implement

procedures and measures to achieve the objectives stated in the assessment framework. “

Based on the generic remarks of the DNB on using the maturity levels it can be seen that the DNB also supports

and suggests performing a risk assessment. Based on the definition for a maturity level of 4 this risk assessment

should be at least yearly. Furthermore we can see that the DNB states that they have defined control objectives

15 Website of the DNB, http://www.toezicht.dnb.nl/binaries/50-230767.pdf

21

and the “Points to consider” document to provide some guidance on the implementation and measures,

however that it is up to organisations to determine the exact implementation. Based on discussions with

professionals of financial organisations in the Netherlands, the author has noted that for financial organisations

the exact implementation is unclear which further underwrites the need for this research.

3.3 Conclusion

This chapter aimed to provide an answer to research question 2: “What is a maturity level of 4 based on the

DNB assessment framework?”. To fulfil this goal, the maturity levels as defined by the DNB have been

presented and have been discussed with a focus on a maturity level of 4 according to the DNB definition. It has

been reasoned what is expected by a maturity level of 4 and we have conclude that financial organisations in the

Netherlands should perform a (at least) yearly risk assessment in which critical processes and controls are

identified and it is evaluated how important each area and control measure of the DNB assessment framework

is for the organisation. In this way, financial organisations would determine which areas and control measures

are critical and which are less relevant due to the specifics of that organisation’s IT environment or IT

implementation. This would provide the context for financial organisations when implementing the concrete

requirements for each control measure as we define in chapter 4.

Additionally, we have analysed what is needed for a maturity level of 4 and based on the definition of a maturity

level of 4 we have noted that to achieve that level that the identified controls are periodically assessed and

improved. Also, identified actions for improvement are defined and assigned to owners. We include this as part

of our framework of requirements in chapter 4 by adding to each set of requirements per control measure the

following prerequisite:

“- The above requirements are periodically evaluated as part of a control or multiple controls. Based on

the results follow up actions are defined and assigned to owners.”

22

4. Framework to achieve a maturity level of 4

This chapter contains the creation and validation of a framework of requirements to achieve a maturity level of

4 in the DNB assessment framework for financial institutions. By doing this, this chapter gives an answer to

research question 3 which is: “What is an appropriate framework to achieve a maturity level of 4 based on the

DNB assessment framework?”. As input the theoretical background from chapters 2 and 3 are used. Section 4.1

describes how we define the concrete requirements and what is used as input. Section 4.2 contains how the

process of defining the concrete requirements has been performed. Because the actual framework of concrete

requirements is extensive, the actual framework of requirements has been moved to Appendix A. Once it is

described how the framework of requirements is defined, it is described how this is validated by both subject

matter experts and in practice in section 4.3. This includes the standardised sets of questions for interviews and

how this has been documented in the research database. Lastly, this chapter finishes with a conclusion in

section 4.4.

4.1 Defining the framework

In chapter 1 we have discussed the need for financial institutions in the Netherlands to achieve a maturity level

of 4 on the DNB assessment framework. In chapter 2 we gained an understanding of the DNB assessment

framework and in chapter 3 we gained an understanding of the maturity levels and specifically level 4. Now that

we have an understanding of the key concepts, we can start defining the concrete requirements per control

measure of the DNB assessment framework. Even though the requirements come from various existing sources,

we still use the word “defining” in regards to the requirements because (1) some of the requirements are defined

based on the author’s experience and (2) because combining requirements from different sources to one

requirement still requires some extent of defining from the author.

Together, the requirements per control from the DNB form a framework of requirements that shows what a

financial organisation in the Netherlands should have in place to achieve a maturity level of 4 on all control

measures of the DNB assessment framework.

In sections 1.2 and 1.3 it has already been stated that as for the sources used for defining the requirements that

the following are used:

1. The DNB assessment framework (based on the control measures given).

2. COBIT 4.1.

3. The “Points to consider” document from the DNB.

4. The professional experience of the author.

For defining the requirements first the control objective from the DNB assessment framework is considered.

Then each control measure is considered and based on the control measure specific requirements are defined.

For instance if a control measure discusses a certain procedure then a defined requirement is that the

procedure is available.

23

Next, the sources COBIT 4.1 and the “Points to consider” document from the DNB are reviewed to determine if

these state any specific requirements for the control measure. If so, these are included in the framework of

requirements. Naturally, both COBIT 4.1 and the “Points to consider” document are very extensive and many

requirements could be drawn from them. The author also uses his professional experience to evaluate which

requirements make sense to be included. Because the author might be biased, this is one of the reasons that the

extensive validation procedures have been selected for this research (refer for more information to section 1.3

and section 4.3).

The framework of requirements has been defined and can be found in Appendix A.

4.2 Documenting the creation of the framework in the research

database

To provide insight into how each requirement was defined and which source or sources have been used, it has

been documented for each requirement which sources are used in defining that requirement (Creswell, 2013).

This has also been documented in the framework of requirements, refer to Appendix A. We can see in the

framework that not only the DNB control measure and the requirements per control measure is presented but

that in the subsequent columns it is stated which sources were used for each requirement.

For instance if the first requirement is about a certain procedure being available and this procedure is

mentioned in the DNB control measure then the number “1” (indicating the first requirement) is added in the

column “Based on control measure”. However, if COBIT4.1 and the “Points to consider” document are reviewed

and these include specific contents that should be in that procedure, then the requirement is expanded upon to

include which elements at a minimum need to be included in the procedure and the number “1” is also added to

the columns “Based on COBIT 4.1” and “Based on “Points to consider” document.

It can also occur that a certain requirement has been adjusted or expanded upon based on the professional

experience of the author. This is documented in the column “Based on professional experience”.

Lastly, requirements can also be added, adjusted or expanded upon based on the validation procedures

performed. This is documented in the columns “Based on expert validation” and “Based on practical

validation”. More information on these is given in section 4.3.

4.3 Validating the framework of requirements

In section 4.2 it is described how the initial framework of requirement to achieve a maturity level of 4 on the

DNB assessment framework has been created. As described in our research design phase (see section 1.3) we

also perform 2 validation procedures to enhance the reliability of the framework and to verify that the

framework produces useful results in practice. In section 4.3.1 the subject matter expert validation procedures

is described and in section 4.3.2 the validation in practice that is performed is described.

4.3.1 Subject matter expert validation procedures

In section 1.3 we have described the structure of the validation procedures for the subject matter expert

validation. The structure was:

24

1. 3 experts are selected based on their experience. The reason why they are selected and a summary of

their background is stated.

2. The initial framework is reviewed by the experts in which they are asked to review (1) if they agree with

each of the requirements per control measure of the framework and (2) if they consider any

requirements to be missing.

3. The review of the experts is discussed with the experts to gain a thorough understanding of any

adjustments or new input that comes up from their review.

These steps have been carried out as we have described in our research approach in section 1.3. Below are the

details of each step.

Step 1: selection of participants for subject matter expert validation

For the subject matter expert validation the experts would ideally have extensive knowledge of working with

and experience of the following:

- Working with and applying COBIT (v4.1).

- The financial industry in the Netherlands.

- The DNB as a regulating authority in the Dutch financial sector and the DNB assessment framework.

- IT Control frameworks.

For selecting the subject matter experts the above criteria where leading in the selection of the subject matter

experts. The following 3 subject matter experts have been selected and have been requested to perform the

validation of the framework:

Subject matter

expert

Role Profile

1 IT auditor - Has worked 12 years as an IT auditor for various

sectors including the financial sector.

- Extensive experience with information security.

- Experience with COBIT 4.1 and 5.0.

- Extensive experience of working with (IT)

control frameworks.

2 Supervisor - Has worked in the financial sector for 5 years.

- Knowledge of the DNB assessment frameworkand knowledge of other IT frameworks.

- Extensive knowledge of information security.

3 Compliance officer - Has worked in the financial sector for 7 years.

- Extensive knowledge of compliance, includingthe DNB.

- Extensive knowledge of COBIT 4.1 and 5.0, ITILand ISO.

Table 3 – Overview of subject matter experts

25

Step 2: requesting the validation from the subject matter experts

After the subject matter experts have been selected they have been asked to validate the initial framework of

requirements. To help in obtaining consistent results, the subject matter experts have all been asked the same

questions:

1. If they agree with each of the requirements per control measure of the framework.

2. If they consider that any requirements need to be adjusted and/or expanded on.

3. If they consider that any requirements need to be added.

It was also asked from the subject matter experts to document their validation which was then subsequently

discussed with the subject matter experts as part of step 3.

Step 3: discuss the outcome of the validation with the subject matter experts

After the subject matter experts have performed their validation, the outcome of the validation has been

discussed with the experts to gain a thorough understanding of any adjustments or new input that has come up

from their validation.

Based on the expert validation the initial framework has been adjusted and/or expanded to include

requirements that came up from the expert validation. In case a requirement was adjusted or added because of

the expert validation, then this has been documented in Appendix A in the column “Based on expert

validation”.

In total 41 requirements have been adjusted or added as a result of the subject matter expert validation. Refer to

Appendix A for the details on which requirements this relates to.

4.3.2 Procedures for validation in practice with 19 professionals

In section 1.3 we have described the structure of the validation procedures for the validation in practice. The

structure was:

1. A financial institution is selected that is based in the Netherlands and is large enough (IT department of

at least 50 employees). Preferably this organisation should perform most of its IT processes themselves

as opposed to having (a large part of) their IT processes outsourced to third parties. This makes it both

easier to discuss the IT processes and makes it more likely that information is more readily available for

all IT processes.

2. At the financial institution a relevant professional for each IT process is identified. This professional

should be knowledgeable on how that IT process is performed at the organisation.

3. Each IT process is discussed with the relevant professional. For the discussion the framework with

concrete requirements to achieve a maturity level of 4 is used and the requirements per control per IT

process are discussed. For this discussion a standardized format is used which is further described in

chapter 4. The standardized format ensures that it is verifiable how the validation in practice has been

performed and that the same approach for the validation in practice is performed for all IT processes.

26

Step 1: selection of financial institution for the validation in practice

For the validation in practice a financial institution in the Netherlands was selected. The selected financial

institution operates larges in the field of asset management within the financial sector. It has around 125

professionals in the IT department. It performs most of its IT processes themselves. It does use a dual setup

data centre which is managed by a third party but apart they largely are responsible for and perform all IT

processes themselves. Thereby this financial institution is an excellent match to validate the framework of

requirements because of 2 reasons:

1. It is easier to discuss all topics of the framework with relevant professionals. There is no need to discuss

them with third party suppliers.

2. The professionals with which the framework of requirements is validated are possible more

knowledgeable on each subject which is discussed with them because are responsible for and involved

in the execution of that process.

Step 2: selection of professionals at the financial institutions with which each control measure

is validated

To perform a strong validation a knowledgeable professional for each control measure has been selected.

Initially, the main contact for the financial institution has been an professional from the security department

with an extensive background in internal control who had worked in the financial institution for 3 years. With

this professional all control measures were assigned to the most knowledgeable professional of the financial

institution on each specific control measure. In this way the 54 control measures have been assigned over 19

individuals working at the financial institution. For confidentiality reasons, the exact functions of those

professionals are not disclosed. However, for most cases, the participants for the validation in practice were the

head of team lead of a sub department of the IT department. For instance, the team lead of the Security

department or the team lead of the Architecture department. For some specific control measures professionals

outside of the IT department were selected, such as a professional from HR for the HR control measures (for

instance for control measures, 8.1, 8.2 and 8.5, 8.3 and 8.4 have been discussed with someone from IT

management). Other control measures which were discussed with professionals from outside the IT department

include professionals from the internal control and internal audit departments.

Step 3: request the validation from the selected professionals

After the professionals which were most knowledgeable on each control measure have been selected, the

professionals have been approached to perform the validation of the control measures assigned to them. With

each of the professionals a 1 hour meeting has been scheduled. To obtain consistent results each professional

has been asked the same questions for each control measure:

1. If they agree with each of the requirements per control measure of the framework.

2. If they consider that any requirements need to be adjusted and/or expanded on.

3. If they consider that any requirements need to be added.

27

In the same way as the subject matter expert validation, the answers of the participants have been discussed

with the participants to gain a thorough understanding of any adjustments or new input that has come up from

their validation.

Based on the validation in practice the initial framework has been adjusted and/or expanded to include

requirements that came up from the validation. In case a requirement was adjusted or added because of the

validation in practice, then this has been documented in Appendix A in the column “Based on validation in

practice”.

In total 56 requirements have been adjusted or added as a result of the validation in practice. Refer to Appendix

A for the details on which requirements this relates to.

4.4 Conclusion

This chapter aimed to provide an answer to research question 3: “What is an appropriate framework to achieve

a maturity level of 4 based on the DNB assessment framework?”. To fulfil this goal, for the appropriate

framework we have defined for each of the control measures of the DNB framework what the concrete

requirements are to achieve a maturity level of 4. The overview of the DNB framework control measures and the

related concrete requirements from this thesis can be found in Appendix A. We have defined the initial

requirements based on 4 sources: (1) the DNB assessment frame work, (2) COBIT 4.1, (3) the “Points to

consider” document from the DNB and (4) the professional experience of the author.

The initial defined requirements have been validated both by subject matter experts and in practice. How these

validation procedures have been carried out have been described extensively in section 4.3.1 (subject matter

expert validation) and section 4.3.1 (validation in practice). For the subject matter expert validation the

validation has been performed with 3 subject matter experts. For the validation in practice, 19 professionals at a

financial organisation were selected with whom the control measures on which they were most knowledgeable

were validated.

Based on the validation procedures performed a total of 41 requirements have been adjusted or added as a

result of the subject matter expert validation and a total of 56 requirements have been adjusted or added as a

result of the validation in practice.

This chapter has resulted in a framework of concrete requirements per control measure of the DNB assessment

framework to achieve a maturity level of 4 and thereby gives an answer to research question 3. Due to the size of

the final framework, it can be found in Appendix A.

28

5. Conclusion, reflection and further research

In this final chapter the main conclusions from this thesis are presented which is stated in section 5.1. After the

main conclusions have been given, a reflection is given on the thesis contents and the experience of the author

in section 5.2. Lastly, in section 5.3 suggestions for further research are presented.

5.1 Conclusion of this thesis

5.1.1 Introduction and relevance of this thesis

In recent years electronic and computer crime has been on the rise and the financial sector has been one of the

major targets of cyber criminals. The attacks on financial institutions in the Netherlands have not gone

unnoticed and are the reason why The Dutch Bank (“De Nederlandsche Bank”, hereafter “DNB”) has increased

its focus on improving the maturity of financial institutions on information security. To assist in improving the

maturity, the DNB has created the DNB assessment framework. The DNB assessment framework is a

framework based on COBIT which includes several control objectives and underlying control measures to

assess the maturity of IT processes of an organisation.

As a regulating authority for the financial sector in the Netherlands, the DNB currently expects of financial

institutions to achieve a maturity level of “3” on the DNB assessment framework. However, the DNB has

announced that as of June 2015 it expects that the maturity of financial institutions on three control objectives

should already be of level 4. Because of the increasing importance of a strong financial sector and the increase

in capabilities of cyber criminals, it is generally expected that the DNB will demand a higher maturity level in

the future. The next expected maturity level would be a maturity level of 4 for all control objectives.

Even though the DNB has provided an assessment framework (including control objectives) and general

definitions of maturity levels, it is not exactly clear for financial institutions what exactly they need to have in

place to achieve a maturity level of 4 on the DNB assessment framework. This thesis aimed to provide insight in

this lack of clarity and therefore raised the main research question: “What is an appropriate framework for

financial institutions in the Netherlands to achieve a maturity level of 4 based on the DNB assessment

framework?”

The main research question has been split in the following research questions:

1. What is the DNB assessment framework?

2. What is a maturity level of 4 based on the DNB assessment framework?

3. What is an appropriate framework to achieve a maturity level of 4 based on the DNB assessment

framework?

29

5.1.2 Answer to the research questions

To answer the first research question, this thesis started by providing insight in what the DNB assessment

framework is. We concluded that the DNB assessment framework was created to assist in helping financial

organisations have sound information security processes and to control IT risks. Also we found that the DNB

expects from financial organisations that their procedures and measures should ensure the continuity of IT

(and thereby the organisation) and the security of information.

We also found that currently not all financial organisations in the Netherlands comply sufficiently with a

maturity level of 3 of the DNB assessment framework, let alone a maturity level of 4. As a regulatory body of

the Dutch financial industry, the DNB has the ability and power to demand improvements from financial

organisations. It has also done so in the past. Already in June of 2015 the DNB expects a maturity level of 4 for

three of the areas of the DNB assessment framework. With the increasing importance of information security

and with recent more stringent regulation from the DNB, the expectation is that in the future IT processes of

the financial sector need to be further strengthened and therefore the maturity of financial institutions needs to

be improved as well.

To answer the second research question, this thesis continued by providing insight in the maturity levels (and

specifically a maturity level of 4) as defined by the DNB. It has been reasoned what is expected by a maturity

level of 4 and we have concluded that financial organisations in the Netherlands should perform a (at least)

yearly risk assessment in which critical processes and controls are identified and it is evaluated how important

each area and control measure of the DNB assessment framework is for the organisation. In this way, financial

organisations would determine which areas and control measures are critical and which are less relevant due to

the specifics of that organisation’s IT environment or IT implementation.

Additionally, we have analysed what is needed for a maturity level of 4 and based on the definition of a maturity

level of 4 we have noted that to achieve that level that the identified controls are periodically assessed and

improved. Also, identified actions for improvement are defined and assigned to owners. These specific

description of the DNB on a maturity level 4 have resulted in adding this to our framework of requirements for

each control measure as can be found in Appendix A. The following text has been added to each set of

requirements based on our analysis of a maturity level of 4 according to the DNB:

“- The above requirements are periodically evaluated as part of a control or multiple controls. Based on

the results follow up actions are defined and assigned to owners.”

To answer the third and last research question, we have defined for each of the control measures of the DNB

framework what the concrete requirements are to achieve a maturity level of 4. The overview of the DNB

framework control measures and the related concrete requirements from this thesis can be found in Appendix

A. We have defined the initial requirements based on 4 sources: (1) the DNB assessment frame work, (2) COBIT

4.1, (3) the “Points to consider” document from the DNB and (4) the professional experience of the author.

30

The initial defined requirements have been validated both by subject matter experts and in practice. How these

validation procedures have been carried out have been described extensively in section 4.3.1 (subject matter

expert validation) and section 4.3.1 (validation in practice).

5.1.3 Answer to main research question

To answer the main research question first insight has been given in the DNB assessment framework and the

DNB maturity levels. We found that currently not all financial organisations in the Netherlands comply

sufficiently with a maturity level of 3 of the DNB assessment framework, let alone a maturity level of 4. Also, we

found that the DNB as a regulating authority in the financial sector can and has demanded improvements from

financial institutions if their maturity was deemed insufficient.

We have analysed what is necessary to achieve a maturity level of 4 on the DNB assessment framework and

have used this as input in defining concrete requirements per control measure of the DNB assessment

framework. The concrete requirements are all requirements that need to be met for organisations wanting to

achieve a maturity level of 4 on the DNB assessment framework. This has resulted in a new framework which

shows (1) the DNB control measure and (2) the requirements that need to be met to achieve a maturity level of

4.

To increase the reliability and validity of the created framework, the framework has been validated with 3

subject matter experts and with 19 professionals who are employed at a financial institution in the Netherlands.

Because of the subject matter expert validation 41 requirements have been adjusted or added and because of the

validation in practice 56 requirements have been adjusted or added. The final results is a framework of concrete

requirements to achieve a maturity level of 4 on the DNB assessment framework.

By answering the three research questions we have created a validated framework of concrete requirements per

control measure of the DNB assessment framework to achieve a maturity level of 4. This framework is seen as

the main output of this thesis and gives an answer to the main research question of this thesis.

5.2 Reflection on research

5.2.1 Reflection on thesis content

This thesis is of value to Dutch financial institutions by helping them achieve the maturity level that they need

to achieve from the DNB. This is relevant for Dutch financial institutions since they are subject to the Financial

Supervision Act and they have to comply with the regulations from the DNB. The framework of requirements

which is the main output of this thesis helps financial institutions gain insight into what they need to have in

place exactly. The framework of requirements can also help IT auditors identify which requirements financial

institutions have in place or do not have in place. Since we found in chapter 2 that a large part of the Dutch

financial institutions does not even comply with a maturity level of 3, this framework is even more relevant.

This thesis is also of value to the field of IT audit research since there was not yet a framework available with

which it could be measured if an organisation complies to a maturity level of 4 on the DNB assessment

framework. Since this thesis created that framework it has therefore contributed to the body of knowledge of IT

audit research.

31

5.2.2 Reflection on thesis experience

Writing this thesis has been an interesting and exciting journey. This thesis has greatly contributed to my

knowledge of the DNB assessment framework, maturity levels and other IT frameworks which was one of my

goals when starting this thesis. Although I’m happy to finish this thesis because it is the last part of my study, I

am confident that I will continue to use this knowledge in the rest of my career.

In addition, through writing this thesis I’ve gained many interesting business contacts. This can mainly be

attributed to the fact that during the writing of this thesis I have spent a full month at the financial

organisations at which I performed the validation in practice. During that month all interviews for the

validation in practice have been performed. Because I spent a full month at the IT department of the

organisation, at some point it felt like I had joined that organisation as an employee and was welcomed in their

team. The various meetings with (IT) professionals gave me a good insight into their organisation for which I’m

thankful.

5.3 Suggestions for further research

This research has been carried out on a specific topic which is relatively unstudied in current literature. Of

course, IT frameworks such as COBIT have been studied and maturity levels have been studied, however not

much literature was found on the DNB assessment framework. The creation of the framework of requirements

to achieve a maturity level of 4 on the DNB assessment framework could be seen as a first step since is only

describes what needs to be in place. An interesting area for further research would be how organisations can

actually get to this maturity level and what is holding them back in achieving this level.

Another obvious area for further research is what financial institutions needs to have in place to reach the next

maturity level which is a maturity level of 5. Researching this could follow similar steps used in this researched

and would help financial institutions that want to reach that higher level.

Lastly, for the validation of the framework of requirements an extensive number of professionals have been

asked to validate the framework of requirements. However, all of these were from the same financial

organisation. By performing further validation procedures with other financial organisations, it is likely that the

framework of requirements would be further enhanced.

32

Appendix A: Framework for achieving maturity level 4

Explanation of the numbers in the frameworkOn the right side of the framework there are 6 columns which include a number. The numbers refer to the requirements that correspond to the numbers inthe middle column. The numbers indicate which sources were used for each requirement.For instance if the first requirement is about a certain procedure being available and this procedure is mentioned in the DNB control measure then thenumber “1” (indicating the first requirement) is added in the column “Based on control measure”. However, if COBIT4.1 and the “Points to consider”document are reviewed and these include specific contents that should be in that procedure, then the requirement is expanded upon to include whichelements at a minimum need to be included in the procedure and the number “1” is also added to the columns “Based on COBIT 4.1” and “Based on “Points toconsider” document.It can also occur that a certain requirement has been adjusted or expanded upon based on the professional experience of the author. This is documented inthe column “Based on professional experience”. Lastly, requirements can also be added, adjusted or expanded upon based on the validation proceduresperformed. This is documented in the columns “Based on expert validation” and “Based on practical validation”. More information is given in section 4.2 ofthis thesis.

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

1

Define an information security plan:Provide direction and support for informationsecurity in accordance with business, risks andcompliance requirements with involvement ofBusiness and IT so priorities can be mutuallyagreed.

33

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

1.1

Information Security plan: Business, riskand compliance requirements are translatedinto an overall IT security plan, taking intoconsideration the IT infrastructure and thesecurity culture. The plan is implemented insecurity policies and procedures together withappropriate investments in services, personnel,software and hardware. Security policies andprocedures are communicated to stakeholdersand users.

- The following requirements are in place:1. An information security plan is available and approved by theappropriate management level which includes business, risk andcompliance requirements. The information security plan includes thefollowing:

• A complete set of security policies and standards in line with theestablished information security policy framework

• Procedures to implement and enforce the policies and standards• Roles and responsibilities• Staffing requirements• Security awareness and training• Enforcement practices• Investments in required security resources

2. The IT infrastructure and security culture are taken intoconsideration in the information security plan.3. The security plan is implemented in the form of security policiesand/or procedures which are communicated to stakeholders (includingrelevant third parties) and users. At a minimum these cover networksecurity, physical security, logical access and remote access.4. Security has been imbedded in the organisation and security roleshave been appointed. At the minimum an employee at board level isresponsible for security and a security officer role is appointed.5. Appropriate investments in services, personnel, software andhardware are made. It is determined by the organisation what isappropriate and it is verified that these investments are made.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2.3.5.

1. 4.5.

1. 3.

34

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

1.2

IT Policies Management: Develop andmaintain a set of policies to supportInformation security strategy. These policiesshould include policy intent; roles andresponsibilities; exception process; complianceapproach; and references to procedures,standards and guidelines for development,acquisition, maintenance and support. Theirrelevance should be confirmed and approvedregularly.

- The following requirements are in place:1. Formal policies supporting information security strategy and thecontrol environment are available and approved by the appropriatelevel of management which include:

• policy intent• roles and responsibilities• exception process• compliance approach including how to track compliance and a

definition of the consequences of non-compliance• references to procedures, standard and guidelines for system

development, acquisition, maintenance and support or it is describedon which standards the policies are based.2. The policies are reviewed and approved at least yearly and this isdocumented.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 2.

2

Define the information architecture:Ensure reliable, secured and reliableinformation to support business processes andto seamlessly integrate applications intobusiness processes.

35

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

2.1

Enterprise Information ArchitectureModel: Establish and maintain an enterpriseinformation model to enable applicationsdevelopment and decision-supporting activities,consistent with IT plans. The model shouldfacilitate the optimal creation, use and sharingof information by the business in a way thatmaintains integrity and is flexible, functional,cost-effective, timely, secure and resilient tofailure.

- The following requirements are in place:1. An enterprise information architecture model is available, known byappropriate business and IT stakeholders and approved by anappropriate management level.2. The enterprise information architecture model is used to translateIT strategy into (IT) tactical plans.3. To increase the effective use of the enterprise informationarchitecture model it includes flexibility, functionality, cost-effectiveness, timeliness, security and resiliency to failure.4. Maintenance of the enterprise information model is ensuredthrough regular updating and/or a periodic review.5. The enterprise information architecture team is notified if changesto application that impact the enterprise information model. This is astandardized part of the impact assessment of changes.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.3.4.

2.3.

1. 5.

2.2

Data classification scheme: Establish aclassification scheme that applies throughoutthe enterprise, based on the criticality andsensitivity (e.g., public, confidential, top secret)of enterprise data. This scheme should includedetails about data ownership; definition ofappropriate security levels and protectioncontrols; and a brief description of dataretention and destruction requirements,criticality and sensitivity. It should be used asthe basis for applying controls such as accesscontrols, archiving or encryption.

- The following requirements are in place:1. A data classification scheme is available and approved byappropriate management level.2. The data classification scheme classifies data on criticality,sensitivity. This has been further defined in measures such asconfidentiality, integrity and availability.3. The data classification scheme includes details on data ownership;definition of appropriate security levels and protection controls; and abrief description of data retention and destruction requirements,criticality and sensitivity4. There is an explicit relationship between the data classification(scheme) and access controls, archiving and encryption.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.4.

3. 3. 1. 2.

36

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

3

Determine technological direction:Provide stable, effective and securetechnological solutions enterprise wide toenable timely response to businessrequirements and changes in law andregulations, industry and technologydevelopments.

3.1

Monitor future trends and regulations: Aprocess is established to monitor the businesssector, industry, technology, infrastructure,legal and regulatory environment trends. Theconsequences of these trends are incorporatedinto the development of the IT technologyinfrastructure plan.

- The following requirements are in place:1. The organisation monitors the business sector, industry, technology,infrastructure, legal and regulatory environment trends. To do this theorganisation has sufficient external feeds in place, such asbenchmarking and industry knowledge from companies such asGartner.2. The results of the monitoring process on future trends andregulations are incorporated into the development of the IT technologyinfrastructure plan.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.

2. 1.

3.2

Technology standards: Consistent, effectiveand secure technological solutions are providedenterprise wide, a technology forum isestablished to provide technology guidelines,advice on infrastructure products and guidanceon the selection of technology, and compliancewith these standards and guidelines ismeasured. This forum directs technologystandards and practices based on their businessrelevance, risks and compliance with externalrequirements.

- The following requirements are in place:1. The corporate technology standards are approved by the ITarchitecture board.2. Corporate technology standards are communicated throughout theorganisation.3. A technology team is established to provide technology guidelines,advice on infrastructure products and guidance on the selection oftechnology, and compliance with these standards and guidelines ismeasured4. Monitoring and benchmarking processes are in place, such asmeasuring non-compliance to technology standards, to ensurecompliance to the standards.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

3. 1.4.

2. 1. 3.

37

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

4

Assess and manage (IT) risks: Ensure thatinformation security risks are discovered,prioritized and are accepted in a timely andstructured manner aligned with the enterprise’sappetite for IT risk and the organisation's riskmanagement framework.

4.1

IT Risk Management framework: An ITrisk management framework is established andaligned to the organisation’s (enterprise) riskmanagement framework.

- The following requirements are in place:1. An IT risk management framework is available to all stakeholders, itis actively monitored and tested by a risk management function andinternal audit and the lines of defense are defined.2. The IT risk management framework aligns with the riskmanagement framework for the organisation (enterprise) and includesbusiness-driven components for strategy, programmes, projects andoperations.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2. 2. 1. 1.

4.2

Risk assessment: The likelihood and impactof all identified risks are assessed on a recurrentbasis, using qualitative and quantitativemethods. The likelihood and impact associatedwith inherent and residual risk are determinedindividually, by category and on a portfoliobasis.

- The following requirements are in place:1 An IT risk management framework is available, approved by theappropriate management level and is assessed at least on a yearlybasis.2. The identified IT risks are assessed using quantitative andqualitative methods.3. The likelihood and impact associated with inherent and residual riskare determined individually, by category and on a portfolio basis.4. Risks are assigned to owners.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2.3.

1. 1. 4.

38

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

4.3

Maintenance and monitoring of a riskaction plan: The control activities areprioritised and planned at all levels toimplement the risk responses identified asnecessary, including identification of costs,benefits and responsibility for execution.Approval is obtained for recommended actionsand acceptance of any residual risks, andensured that committed actions are owned bythe affected process owner(s). Execution ismonitored of the plans, and any deviations arereported to senior management.

- The following requirements are in place:1. Risks are formally recognised and recorded in a risk action plan(which can be in the form of a control framework).2. An identification of the costs, benefits and execution responsibilitiesis made for all control activities.3. Residual risks are identified and formally accepted.4. Actions following from control deficiencies are assigned to theaffected process owner.5. It is monitored that the control framework and actions are executedand deviations are reported to senior management.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2.3.4.

1.4.5.

1. 5.

5

Information Security Organization:Information Security is managed at the highestappropriate organizational level, so themanagement of security actions is in line withbusiness, risk and compliance requirements.

5.1

Responsibility for risk, security andcompliance: Ownership and responsibility areembedded for IT-related risks within thebusiness at an appropriate senior level. Rolescritical for managing IT risks are defined andassigned, including the specific responsibilityfor information security, physical security andcompliance. Risk and security managementresponsibility are established at the enterpriselevel to deal with organisation wide issues.Additional security managementresponsibilities may be assigned at a system-specific level to deal with related security issues.From senior management is direction obtainedon the appetite for IT risk and approval of anyresidual IT risks.

- The following requirements are in place:1. Senior management has established an organisation wide,adequately staffed risk management and information security functionwith overall accountability for risk management and informationsecurity.2. Specifically, roles critical for managing IT risks are defined andassigned, including the specific responsibility for information security,physical security and compliance.3. The IT risk appetite is formally determined as part of a riskassessment.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2. 1. 1. 2.3.

2.

39

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

5.2

Management of Information Security:Information security is managed at the highestappropriate organisational level, so themanagement of security actions is in line withbusiness requirements.

- The following requirements are in place:1. An employee at top management level is responsible for informationsecurity.2. A security steering committee exists, which includes representationfrom key functional areas, including internal audit, HR, operations, ITsecurity, legal and architecture.3. A security management reporting mechanism exists that informs theboard, business and IT management of the status of informationsecurity.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 2.3.

1. 2. 2.

6

Data and system ownership: Data andsystem ownership is established to provideaccountability and ensure that data integrity,confidentiality and availability are in line withbusiness and compliance requirements.

6.1

Data and system ownership: The businessis provided with procedures and tools, enablingit to address its responsibilities for ownership ofdata and information systems. Owners makedecisions about classifying information andsystems and are protecting them in line withthis classification.

- The following requirements are in place:1. A procedure for data and system ownership is available andapproved by the appropriate management level.2. Data ownership and system ownership are assigned.3. Data and system ownership registration is supported by tooling.4. Data owners have classified information and data is protected in linewith the classification.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

7

Manage segregation of duties: A division ofroles and responsibilities is implemented thatreduces the possibility for a single individual tocompromise a critical process.

40

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

7.1

Segregation of duties: A division of rolesand responsibilities is implemented thatreduces the possibility for a single individual tocompromise a critical process. Personnel areperforming only authorised duties relevant totheir respective jobs and positions.

- The following requirements are in place:1. It is identified by the organisation which roles have criticalsegregation of duties and this is documented.2. A division of roles and responsibilities is available in the form of oneor more functional authorisation matrices and these have beenimplemented.3. The functional authorisation matrices are periodically reviewed.4. It is periodically assessed if there are discrepancies between theactive user rights and the functional authorization matrices.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2. 1.2.3.4.

4.

8

Manage IT human resources: Ensure thatfunctions are staffed properly with reliablepeople who posses the necessary skills to fulfiltheir role to reduce the risk of human error.

8.1

Personnel recruitment and retention: ITpersonnel recruitment processes aremaintained in line with the overallorganisation’s personnel policies andprocedures (e.g., hiring, positive workenvironment, orienting). Processes areimplemented to ensure that the organisationhas an appropriately deployed IT workforcewith the skills necessary to achieveorganisational goals.

- The following requirements are in place:1. An IT HR management plan exists that includes the definition ofskill requirements and preferred professional qualifications to meettactical and strategic IT needs of the organisation.2. IT HR management and recruitment responsibilities are assigned.3. Processes are in place to identify shortages in IT employees and/orspecific IT skills such as periodic meetings between HR andmanagement.4. A pre employment screening is performed to ensure futureemployees comply with regulatory demands.5. A periodic employee satisfaction survey is performed to measure thework environment and identify areas for improvement.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

3. 1. 1. 2. 3.4.5.

41

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

8.2

Personnel competencies: Regularly isverified that personnel have the competenciesto fulfil their roles on the basis of theireducation, training and/or experience. Core ITcompetency requirements are defined andverified that they are being maintained, usingqualification and certification programmeswhere appropriate.

- The following requirements are in place:1. Processes are in place through which it is assessed if personnel havethe competencies to fulfil their roles based on their education, trainingand/or experience. An example of a process in place can be periodicmeetings between HR and management.2. Core IT competency requirements are defined and it is verified thatthese are being maintained, using qualification and certificationprogrammes where appropriate.3. In mid or end year evaluation meetings it is identified if employeeshave sufficient competencies. In case of a lack of competencies followup is given.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.

1.2.

1. 1.3.

8.3

Dependence upon individuals: Exposure tocritical dependency on key individuals throughknowledge capture (documentation),knowledge sharing, succession planning andstaff backup is minimized.

- The following requirements are in place:1. It is periodically identified if there is a dependence upon individualsfor critical processes within the IT organisation. This assessment isdocumented.2. In case of dependence upon individuals an action plan is created tominimize the risk for the organisation. This can be in the form ofknowledge capture (documentation), knowledge sharing, successionplanning, staff backup and/or training programmes.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.

1. 2.

42

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

8.4

Personnel clearance procedures:Background checks are included in the ITrecruitment process. The extent and frequencyof periodic reviews of these checks aredependant on the sensitivity and/or criticalityof the function and are applied for employees,contractors and vendors.

- The following requirements are in place:1. As part of the IT recruitment process background checks areperformed which are applied for employees, contractors and vendors.2. A (IT) employee background check procedure is available. Criteriafor background checks are defined as part of the procedure.3. The extent of background checks is based on the sensitivity and/orcriticality of the function.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.3.

1.2.

8.5

Job change and termination: Expedientactions are taken regarding job changes,especially job terminations. Knowledge transferis arranged, responsibilities are reassigned andaccess rights are removed such that risks areminimised and continuity of the function isguaranteed.

- The following requirements are in place:1. There is a procedure for job termination and/or exit procedurewhich contain all required elements, such as necessary knowledgetransfer, timely securing of logical and physical access, return of theorganisation’s assets, and conducting of exit interviews.2. There is a procedure for job change which contains all requiredelements to minimise disruption of business processes such as theneed for job mentoring, job hand-over steps and preparatory formaltraining.3. User access rights are removed upon job change and jobtermination.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.3.

2. 1.3.

9

Ensure operations and use: Ensure thatpeople has the knowledge and skills to alloweffective and efficient operations of new oradjusted technology / application functions inline with the security policies and procedures.

43

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

9.1

Knowledge transfer to end users: Transferknowledge and skills to allow end users toeffectively and efficiently use the system insupport of business processes.

- The following requirements are in place:1. Training to help end users have the knowledge and skills to usesystems effectively and efficiently is available.2. Training documentation (training materials, user manuals,procedure manuals, online help, etc.) to help end users have theknowledge and skills to use systems effectively and efficiently isavailable.3. Periodically it is verified if on key systems sufficient knowledge ispresent among end users.4. It is an acceptance criteria from the IT department that for new keysystems sufficient supporting training documentation for end users isavailable.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 2. 2. 3.4.

9.2

Knowledge transfer to operations andsupport staff: Knowledge and skills aretransferred to enable operations and technicalsupport staff to effectively and efficientlydeliver, support and maintain the system andassociated infrastructure.

- The following requirements are in place:1. Training to help operations and support staff have the knowledgeand skills to use systems effectively and efficiently are available.2. Training documentation (training materials, user manuals,procedure manuals, online help, etc.) to help operations and supportstaff have the knowledge and skills to use systems effectively andefficiently is available.3. Operations and support staff members are involved in thedevelopment and maintenance of operations and supportdocumentation.4. Periodically it is verified if on key systems sufficient knowledge ispresent among support staff.5. It is an acceptance criteria from the IT department that for new keysystems sufficient supporting training documentation for support staffis available.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 2. 2.3.

1. 4.5.

44

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

10

Change Management: Ensure that allchanges, including patches, support enterpriseobjectives and are carried out in a securemanner. Ensure that day-to-day businessprocesses are not impacted.

10.1

Change standards and procedures:Formal change management procedures hasbeen set up to handle in a standardised mannerall requests (including maintenance andpatches) for changes to applications,procedures, processes, system and serviceparameters, and the underlying platforms.

- The following requirements are in place:1. A formal change management procedure is available, approved byappropriate management level and includes:

• The definition of roles and responsibilities• Classification (e.g., between infrastructure and application

software) and prioritisation of all changes• Assessment of impact (risk and/or IT), authorisation and approval• The change management approach used (waterfall, agile, etc.)• Tracking of changes• Impact on data integrity (e.g., all changes to data files made under

system and application control rather than by direct user intervention)• Management of change from initiation to review and closure• Definition of rollback procedures• Use of emergency change processes• Use of a record management system• Audit trails• Segregation of duties

2. Processes and procedures for contracted services providers (e.g.,infrastructure, application development, application service providers,shared services) are included in the change management process.3. Change registration is uniform, central and complete.4. In case key applications are hosted in the cloud, agreements forservice delivery are made.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 1. 1.2.3.

1.2.

1.4.

45

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

10.2

Impact assessment, prioritisation andauthorisation: All requests for change in astructured way are assessed to determine theimpact on the operational system and itsfunctionality. All changes are categorised,prioritised and authorised.

- The following requirements are in place:1. All requests for change are assessed in a structured way to determinethe impact on the operational system and its functionality.2. Criteria are defined for the assessment of the impact of changes.3. All requested changes are categorised, prioritised and authorisedbefore testing.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.3.

2. 2.

10.3

Test environment: A secure test environmentis defined and established representative of theplanned operations environment relative tosecurity, internal controls, operationalpractices, data quality and privacyrequirements, and workloads.

- The following requirements are in place:1. A secure standalone test environment is in place which includes aprocess to ensure only tested changes are moved to production, such asa version control mechanism or a transporting functionality forchanges to production supported by tooling.2. The test environment is representative of the productionenvironment when considering security, internal controls, operationalpractices, data quality and privacy requirements, and workloads.3. Protection measures and authorisation for access to the testenvironment are in place.4. Depending on the sensitivity of the data, data used in the testenvironment is scrambled.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 3. 3. 1.2.4.

1.4.

1.

46

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

10.4

Testing of changes: Changes are testedindependently in accordance with the definedtest plan prior to migration to the operationalenvironment. It is ensured that the planconsiders security and performance.

- The following requirements are in place:1. Changes are tested independently in accordance with the definedtest plan prior to migration to the operational environment.2. Test results are retained according to regulatory or compliancerequirements.3. Testing is only performed in the test and acceptance environment.4. Fallback or back out plans are prepared and tested if necessary priorto changes being promoted into production.5. It is determined for changes if regression testing needs to beperformed. In case it is necessary, regression testing is performed.6. Security and performance are part of the test plan.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.6.

5. 3.4.

2.5.

2. 3.4.6.

10.5

Promotion to production: The followingprocedure is being following: Following testing,the handover of the changed system tooperations is controlled, keeping it in line withthe implementation plan. Approval is obtainedof the key stakeholders, such as users, systemowner and operational management. Whereappropriate, the system is run in parallel withthe old system for a while, and the behaviourand results are compared.

- The following requirements are in place:1. A formal procedure for promoting changes to production is availableand has been approved by an appropriate management level and/orthis is part of the overall change management procedure.2. All changes are registered before being moved to production.3. Approval is obtained of the key stakeholders, such as users, systemowner and operational management before changes are entered intoproduction. It is defined which stakeholders need to give approval fordifferent types of changes.4. Where appropriate, the system is run in parallel with the old systemfor a while, and the behaviour and results are compared. Results of thisare retained.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 3. 4. 2.3.

1.

11

Continuity Management: Counteractinterruptions to business activities and toprotect critical business processes from theeffects of major failures of information systemsor disasters and to ensure their timelyresumption.

47

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

11.1

IT Continuity plans: IT continuity plans aredeveloped based on the framework anddesigned to reduce the impact of a majordisruption on key business functions andprocesses. The plans are based on riskunderstanding of potential business impactsand address requirements for resilience,alternative processing and recovery capability ofall critical IT services. The plans also coverusage guidelines, roles and responsibilities,procedures, communication processes, and thetesting approach.

- The following requirements are in place:1. IT continuity plans are available for all key IT functions andprocesses and have been approved by appropriate management level.Each plan includes:

• Defines roles and responsibilities• Includes communication processes• Defines the minimum acceptable recovery configuration• The resilience, alternative processing and recovery capability in line

with service commitments and availability targets• The order in which services/applications should be restored

2. The plans are based on a risk-based understanding of potentialbusiness impacts and address requirements for resilience, alternativeprocessing and recovery capability of all critical IT services.3. A risk assessment is performed on what the risks are regarding ITcontinuity.

- The frequency of testing for the control has been determined by a riskassessment and is at least annually.

1.2.

3. 1. 1.

11.2

Testing of the IT Continuity plan: The ITcontinuity plan is tested on a regular basis toensure that IT systems can be effectivelyrecovered, shortcomings are addressed and theplan remains relevant. This requires carefulpreparation, documentation, reporting of testresults and, according to the results,implementation of an action plan. The extent oftesting recovery of single applications tointegrated testing scenarios to end-to-endtesting and integrated vendor testing isconsidered.

- The following requirements are in place:1. IT continuity plans are periodically tested and the results aredocumented.2. For insufficient results of the test of the IT continuity plan actionsare defined and followed up.3. The extent of IT continuity plan testing is based on the criticality ofthe system(s). Based on the criticality the extent is adjusted.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 1.2.

48

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

11.3

Offsite backup storage: All critical backupmedia, documentation and other IT resourcesnecessary for IT recovery and businesscontinuity plans are stored offsite. The contentof backup storage in collaboration betweenbusiness process owners and IT personnel isdetermined. Management of the offsite storagefacility respond to the data classification policyand the enterprise’s media storage practices. ITmanagement ensures that offsite arrangementsare periodically assessed, at least annually, forcontent, environmental protection and security.Compatibility of hardware and software torestore archived data, and periodically test andrefresh archived data is ensured.

- The following requirements are in place:1. Critical backup media, documentation and other IT resourcesnecessary for IT recovery and business continuity plans are storedoffsite and/or it is made use of a dual data centre.2. The content of backup storage in collaboration between businessprocess owners and IT personnel is determined.3. Management of the offsite storage facility and/or the dual datacentre respond to the data classification policy and the enterprise’smedia storage practices.4. Offsite arrangements and/or the dual centre are periodicallyassessed, at least annually, for content, environmental protection andsecurity.5. It is periodically verified that back upped data can be restored.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.3.4.5

4.5.

3.5.

1.3.5.

11.4

Backup and restoration: Procedures aredefined and implemented for backup andrestoration of systems, applications, data anddocumentation in line with businessrequirements and the continuity plan.

- The following requirements are in place:1. A backup and restoration procedure is available and is whichincludes:

• Frequency of backup (e.g., disk mirroring for real-time backups vs.DVD-ROM for long-term retention)

• Type of backup (e.g., snapshot or full vs. incremental)• Type of media• Automated online backups• Data types (e.g., voice, optical)• Creation of logs• Critical end-user computing data (e.g., spreadsheets)• Physical and logical location of data sources• Security and access rights

2. The backup and restoration procedure includes systems,applications, data and documentation in line with businessrequirements and the continuity plan.3. Responsibilities have been assigned for taking and monitoringbackups.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 1.3.

2. 2. 1.

49

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

12Manage data: Maintain the completeness,accuracy, availability and protection of data

12.1

Storage and retention arrangements:Procedures are defined and implemented foreffective and efficient data storage, retentionand archiving to meet business objectives, theorganisation’s security policy and regulatoryrequirements.

- The following requirements are in place:1. A data retention procedure is available and approved by theappropriate management level.2. Retention periods for data are in line with contractual, legal andregulatory requirements.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 2. 1.

12.2

Disposal: Procedures are defined andimplemented to ensure that businessrequirements for protection of sensitive dataand software are met when data and hardwareare disposed or transferred.

- The following requirements are in place:1. A data disposal procedure is available and approved by theappropriate management level.2. Equipment and media containing sensitive information are sanitisedprior to reuse or disposal in such a way that data marked as ‘deleted’ or‘to be disposed’ cannot be retrieved (e.g., media containing highlysensitive data have been physically destroyed).3. Unsanitised equipment and media are transported in a secure waythroughout the disposal process.4. For sensitive data that is stored in the cloud agreements are madewith the service provider on disposal of data and this is validatedthrough (the evaluation of) periodic assurance reports.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2.3.

1. 1. 4.

50

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

12.3

Security requirements for datamanagement: Policies and procedures aredefined and implemented to identify and applysecurity requirements applicable to the receipt,processing, storage and output of data to meetbusiness objectives, the organisation’s securitypolicy and regulatory requirements.

- The following requirements are in place:1. Policies and procedures are available and approved by theappropriate management level supporting the management of data.This includes security requirements applicable to the receipt,processing, storage and output of data.2. The protection of sensitive and confidential data is ensured throughsecurity requirements.3. Awareness programmes have been instituted to create and maintainawareness of security in the handling and processing of sensitive data.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 3. 2. 1.

13

Configuration Management: Ensure that allconfiguration items are appropriately securedand security risks minimised by ensuring theenterprise's awareness of its IT-related assetsand licenses.

13.1

Configuration repository and baseline: Asupporting tool and a central repository areestablished to contain all relevant informationon configuration items. All assets and changesto assets are monitored and recorded. Abaseline of configuration items for every systemand service as a checkpoint to which to returnafter changes is maintained.

- The following requirements are in place:1. A configuration management database (CMDB) is in place.2. All assets and changes to assets are monitored and recorded.3. Configuration baselines for components are defined anddocumented.4. Mechanisms exist to monitor changes against the defined repositoryand baseline.5. Automated tools are used to verify and ensure the completeness ofthe CMDB.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

4. 3.4.

1.2.

5.

51

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

13.2

Identification and Maintenance ofConfiguration Items: Configurationprocedures to support management and loggingof all changes to the configuration repositoryare established. These procedures areintegrated with change management, incidentmanagement and problem managementprocedures.

- The following requirements are in place:1. A configuration procedure to support management and logging of allchanges to the configuration repository is available and approved bythe appropriate management level.2. Authorised and appropriate personnel have designated access to theconfiguration repository as per the policy.3. Changes to configuration items as a result of change managementresult in the necessary adjustments to configuration items.4. Changes and incidents are linked to configuration items in thechange and incident registration to be able to identify whichconfigurations items are and have been impacted by IT processes.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 3. 2. 3. 1. 5.

14

Manage third party and supplierservices: Ensure that third party (suppliers,vendors and partners) services meet businessrequirements and that related business and ITrisks associated with continuity and security areminimized.

14.1

Monitoring and reporting of ServiceLevel Achievements: Specified service levelperformance criteria are continuouslymonitored. Reports on achievement of servicelevels are provided in a format that ismeaningful to the stakeholders. The monitoringstatistics are analysed and acted upon toidentify negative and positive trends forindividual services as well as for servicesoverall.

- The following requirements are in place:1. Service level criteria are defined in the form of service levelagreements. It is determined for which service providers service levelagreements are relevant.2. Service levels are continuously monitored.3. Service levels reports are available which are periodically reviewedby the service level manager.4. In case of negative trends in service level reports, actions areassigned to an action owner to improve services.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2.4.

1. 2.3.4.

1.

52

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

14.2

Supplier risk management: Risks areidentified and mitigated relating to suppliers’ability to continue effective service delivery in asecure and efficient manner on a continualbasis. Contracts conform to universal businessstandards in accordance with legal andregulatory requirements. Risk managementconsiders non-disclosure agreements (NDAs),escrow contracts, continued supplier viability,conformance with security requirements,alternative suppliers, penalties and rewards,etc.

- The following requirements are in place:1. Risks associated with the inability to fulfil the supplier contracts aredefined.2. Based on the defined risks mitigating measures have been taken inthe form of non-disclosure agreements (NDAs), escrow contracts,continued supplier viability, conformance with security requirements,alternative suppliers, penalties and rewards.3. When a new contract is made with a supplier the legal, security andarchitecture departments of the organisation is involved in defining thecontract.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2. 1. 2.3.

3. 3.

15

Incident Management: Ensure informationsecurity events and weaknesses associated withinformation systems are communicated in amanner allowing timely corrective action to betaken.

15.1

Security Incident Definition: Thecharacteristics of potential security incidentsare defined and communicated so they areproperly classified and treated by the incidentand problem management process.

- The following requirements are in place:1. There is a security incident management process which includes thefollowing key elements:

• Event detection• Correlation of events and evaluation of threat/incident• Resolution of threat, or creation and escalation work order• Criteria for initiating the organisation’s CERT process• Verification and required levels of documentation of the resolution• Post-remediation analysis• Work order/incident closure• Monitoring and management

2. A computer emergency response team (CERT) is present to managesecurity emergencies.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.

1. 1.2.

53

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

15.2

Incident escalation: Service desk proceduresare established, so incidents that cannot beresolved immediately are appropriatelyescalated according to limits defined in the SLAand, if appropriate, workarounds are provided.Incident ownership and life cycle monitoringremain with the service desk for user-basedincidents, regardless which IT group is workingon resolution activities.

- The following requirements are in place:1. An incident management procedure is available and approved by theappropriate management level.2. A service desk is in place which handles and monitors incidents. Theservice desk classifies incidents which includes if an incident is asecurity incident.3. Security incidents are escalated to a CERT (Computer EmergencyResponse Team) and/or IT security team.4. Incident ownership and life cycle monitoring remain with theservice desk for user-based non-security incidents.5. It is monitored if incidents are resolved within the appropriate SLAtimes and escalation is performed if SLA times are close to beingexceeded or are being exceeded.6. User satisfaction is on incident management is measured. Based onthe results improvement plans are created if necessary.7. Incident management is monitored on a set of KPI's and if necessaryimprovement plans are created.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.5.

3. 4. 2.3.4.5.

1.5.

6.7.

16

Monitoring: Avoid breaches of any law,statutory, regulatory or contractual obligations,and of any security requirements. Ensurecompliancy of systems with and people'sadherence to organizational informationsecurity related policies, standards andprocedures.

54

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

16.1

Security testing, surveillance andmonitoring: The IT security implementationis tested and monitored in a proactive way. ITsecurity should be reaccredited in a timelymanner to ensure that the approved enterprise’sinformation security baseline is maintained. Alogging and monitoring function will enable theearly prevention and/or detection andsubsequent timely reporting of unusual and/orabnormal activities that may need to beaddressed.

- The following requirements are in place:1. An inventory of all network devices, services and applications existsand that each component has been assigned a security risk rating.2. Security baselines exist for all IT utilised by the organisation.3. An IT security management and monitoring function is appointed.4. The IT security management function has been integrated within theorganisation’s project management initiatives to ensure that security isconsidered in development, design and testing requirements, tominimise the risk of new or existing systems introducing securityvulnerabilities.5. A Security Operation Centre is present.6. Response times and acceptable follow up times are defined.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

3. 1. 1.2.4.

3. 5.6.

16.2

Monitoring of internal controlframework: The IT control environment andcontrol framework are continuously monitored,benchmarked and improved to meetorganisational objectives and adherence toinformation security policies, standards andprocedures.

- The following requirements are in place:1. The IT control environment and control framework are periodicallyassessed. As part of this assessed the following is verified:

• The results of control testing meets organisational objectives andadherence to security policies, standards and procedures.

• The IT control environment and IT control framework arecontinuously improved depending on organisational needs,organizational objectives or regulatory or compliance needs.2. There is executive-level support for organisational governancestandards for internal control and risk management. In addition, thereis regular reporting to the board on internal control.3. Sufficient lines of defense are in place. At a minimum it is expectedthat there are management tester (1st line), a risk managementfunction (2nd line) and an internal audit department (3rd line).

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 1. 2. 1. 3. 2.

55

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

16.3

Internal control at third parties: Thestatus of external service providers’ internalcontrols are assessed. Procedures are in place toensure that external service providers complywith legal and regulatory requirements andcontractual obligations.

- The following requirements are in place:1. A service level management role or department is present in theorganisation. At a minimum periodic service level reports areevaluated.2. It is determined yearly which external (key) service providers arekey to the organisation and which control requirements are necessary.3. Procedures are in place to ensure that external service providerscomply with legal and regulatory requirements and contractualobligations.4. For service providers the IT and legal department are involved inrequirement setting.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

3. 1. 1.2.

1. 4.

16.4

Evaluation of compliance with externalrequirements: IT policies, standards,procedures and methodologies comply withlegal and regulatory requirements.

- The following requirements are in place:1. Compliance responsibilities have been appointed in the organisation,for instance in the form of a compliance officer. In addition, theresponsibility for monitoring of regulatory requirements is assigned.2. It is identified which legal and regulatory sources placerequirements on the organisation. In case of new requirements,relevant process owners are informed and actions are taken.3. It is identified and documented which legal and regulatoryrequirements are relevant for the organisation.4. The legal and regulatory requirements are addressed in IT policies,standards, procedures and methodologies.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

4. 4. 4. 1.2.3.

1.2.

56

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

16.5

Independent assurance: Independentassurance (internal or external) is obtainedabout the conformance of IT with relevant lawsand regulations; the organisation’s policies,standards and procedures; generally acceptedpractices; and the effective and efficientperformance of IT.

- The following requirements are in place:1. It is determined what the significant risks are which need to becovered by independent assurance reports.2. It is identified through a risk assessment on which parts of the IT(for instance specific IT services from service providers) independentassurance (internal or external) is required.3. Independent assurance reports are obtained for all identified areasfor which an independent assurance report is necessary.4. It is reviewed if independent assurance reports cover the identifiedrisks sufficiently and if these include if the conformance of IT withrelevant laws and regulations; the organisation’s policies, standardsand procedures; generally accepted practices; a sufficient scope andtimeframe; and the effective and efficient performance of IT. Anyfindings are followed up.5. It is identified which are the relevant laws and regulations, includingthose for other countries in which the organisation operates.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

3.4.

4. 1.2.3.

1. 1.2.4.5.

17

User Account Management: Ensure that allusers (internal, external and temporary) onlyhave authorised access to data andfunctionalities, and their activities within the ITenvironment are uniquely identifiable.

57

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

17.1

Identity management: All users (internal,external and temporary) and their activity on ITsystems (business application, IT environment,system operations, development andmaintenance) are uniquely identifiable. Useridentities are enabled via authenticationmechanisms. User access rights to systems anddata are in line with defined and documentedbusiness needs and that job requirements areattached to user identities. User access rightsare requested by user management, approvedby system owners and implemented by thesecurity-responsible person. User identities andaccess rights are maintained in a centralrepository. Deploy cost-effective technical andprocedural measures are deployed, and keptcurrent to establish user identification,implement authentication and enforce accessrights.

- The following requirements are in place:1. An user account management procedure is available which includesrequesting, approving, establishing, issuing, suspending and modifyinguser accounts and related user privileges and this procedure isapproved by the appropriate management level.2. All users have a unique user ID.3. Critical actions of users on an application, database and O/S levelare logged.4. Generic user accounts are not present, except for system accounts.5. Access provisioning and authentication control mechanisms areutilised for controlling logical access across all users, system processesand IT resources, for in-house and remotely managed users, processesand systems.6. It is defined which users (including internal, external andtemporary) need which user access rights to data and systems.7. User access rights are requested by user management, approved bysystem owners and implemented by the security-responsible person.8. User identities and access rights are maintained in a centralrepository.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2.6.7.8.

2. 5. 1.2.3.6.

1.4.

3.

58

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

17.2

User account management: Requesting,establishing, issuing, suspending, modifyingand closing user accounts and related userprivileges are addressed with a set of useraccount management procedures. An approvalprocedure outlining the data or system ownergranting the access privileges is included. Theseprocedures should apply for all users, includingadministrators (privileged users) and internaland external users, for normal and emergencycases. Rights and obligations relative to accessto enterprise systems and information arecontractually arranged for all types of users.Regular management review of all accounts andrelated privileges are performed.

- The following requirements are in place:1. An user account management procedure is available which includesrequesting, approving, establishing, issuing, suspending and modifyinguser accounts and related user privileges and this procedure isapproved by the appropriate management level.2. The procedure should apply for all users, including administrators,internal, temporary and external users, and both for normal andemergency cases.3. The user account management procedure has been implemented forall users. It is ensured that only authorized users have access to dataand systems.4. A periodic review of all accounts and related privileges is performed.The frequency of the review is determined by the organisation and is inline with compliance and regulatory needs.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.4.

4. 1.3.

3.

18

Secure Infrastructure: Security techniquesand related management procedures (e.g.,firewalls, security appliances, networksegmentation, intrusion detection, trusted pathor medium, encryption) are used to secure datastorage and transport within the enterprise'stechnical infrastructure, flows from and to thenetwork and mobile devices (e.g. smart phones,usb sticks). Applied techniques are inaccordance with the related data classification.

59

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

18.1

Infrastructure resource protection andavailability: Internal control, security andauditability measures are implemented duringconfiguration, integration and maintenance ofhardware and infrastructural software toprotect resources and ensure availability andintegrity. Responsibilities for using sensitiveinfrastructure components are clearly definedand understood by those who develop andintegrate infrastructure components. Their useis monitored and evaluated.

- The following requirements are in place:1. Internal control, security and auditability measures are implementedduring configuration, integration and maintenance of hardware andinfrastructural software to protect resources and ensure availabilityand integrity. These include:

• All infrastructure data and software are backed up prior toinstallation and/or maintenance tasks.

• All application software is tested prior to installation in anenvironment separate from, but sufficiently similar to, production.

• Tests include functionality, security, availability and integritycondition, and any other vendor recommendations.

• Temporary access is authorised and access is revoked after its use.2. Responsibilities for using sensitive infrastructure components aredefined and assigned.3. Access to maintenance activities over sensitive infrastructurecomponents is logged and both the access and the logging is regularlyreviewed by a responsible senior staff member or reviewedautomatically by tooling.4. A twin data centre setup is in place.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.

1. 1.3.

2. 3. 3.4.

60

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

18.2

Infrastructure maintenance: A strategyand plan for infrastructure maintenance isdeveloped, and ensure that changes arecontrolled in line with the organisation’s changemanagement procedure. Include periodicreviews against business needs, patchmanagement, upgrade strategies, risks,vulnerabilities assessment and securityrequirements.

- The following requirements are in place:1. A strategy and plan for infrastructure maintenance (this can be inthe form of a life cycle management plan) is available and approved bythe appropriate management level.2. Changes to infrastructure are performed in line with theorganisation's regular change management procedure and process.3. Periodic reviews of infrastructure maintenance performance areperformed. As part of these reviews the following is included: businessneeds, patch management, upgrade strategies, risks, vulnerabilitiesassessment and security requirements.4. All important infrastructure components are covered by support(contracts).5. Continuously, infrastructure vulnerabilities are monitored andvulnerabilities are communicated.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.3.

1. 3. 2. 1. 1.4.5.

18.3

Cryptographic key management: Policiesand procedures are in place to organise thegeneration, change, revocation, destruction,distribution, certification, storage, entry, useand archiving of cryptographic keys is in placeto ensure the protection of keys againstmodification and unauthorised disclosure.

- The following requirements are in place:1. A cryptographic key management procedure is available andapproved by the appropriate management level which includes:

• Roles and responsibilities• The generation, change, revocation, destruction, distribution,

certification, storage, entry, use and archiving of cryptographic keys toensure the protection of keys against modification and unauthoriseddisclosure.

• Minimum key strength requirements.2. Private keys are backed up, stored and recovered only by authorisedpersonnel using dual control in a physically secured environment.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 1.2.

2. 1.

61

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

18.4

Network security: Security techniques andrelated management procedures (e.g., firewalls,security appliances, network segmentation,intrusion detection) are used to authorise accessand control information flows from and tonetworks. Available best practices in this area(i.e. GovCert, ISO/IEC, ITSec) are considered.

- The following requirements are in place:1. A network security policy (e.g., provided services, allowed traffic,types of connections permitted) is available and is approved by theappropriate management level.2. Security techniques and related management procedures are used toauthorise access and control information flows from and to networks.At a minimum firewalls and intrusion detection is in place.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.

2. 2. 1.

18.5

Exchange of sensitive data: Sensitivetransaction data is only exchanged over atrusted path or medium with controls toprovide authenticity of content, proof ofsubmission, proof of receipt and non-repudiation of origin.

- The following requirements are in place:1. It is defined and documented which are the trusted paths andmediums for exchanging sensitive data.2. Exchange of sensitive data is only allowed over a trusted path ormedium. Mechanisms are in place that sensitive data is onlyexchanged in these ways.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

2. 1. 2. 1.

19

Manage malware attacks: Preventive,detective and corrective measures are in place(especially up-to-date security patches andvirus control) across the organisation to protectinformation systems and technology frommalware (e.g., viruses, worms, spyware, spam).

62

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

19.1

Malicious software prevention, detectionand correction: Preventive, detective andcorrective measures are in place (especially up-to-date security patches and virus control)across the organisation to protect informationsystems and technology from malware (e.g.,viruses, worms, spyware, spam).

- The following requirements are in place:1. A malicious software prevention policy is available and approved bythe appropriate management level.2. The organisation has implemented malware protection mechanismfor all relevant systems.3. Virus protection tools are frequently updated to include the latestvirus definitions.4. Protection software is centrally distributed (version and patch-level)using a centralised configuration and change management process.5. Incoming e-mail is filtered appropriately against unsolicitedinformation.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 3. 2.4.5.

3. 1.2.

3.

20

Protect infrastructure components:Technology is hardened, security-relatedtechnology is made resistant to tampering, andsecurity documentation is not disclosedunnecessarily.

63

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

20.1

Protection of security technology:Security-related technology is made resistant totampering, and security documentation is notdisclosed unnecessarily.

- The following requirements are in place:1. Processes are in place to ensure that security-related technology ismade resistant to tampering. These processes include:

• Removal of unnecessary software.• Disabling of unnecessary user names and logins.• Disabling or removing of unnecessary services.• Closing open network ports.• Firewall and intrusion detection systems.• Security testing such as penetration tests and vulnerability scans

are performed.2. The security design features facilitate password complexity rules(e.g., maximum length, characters, expiration, reuse) and the passwordrules are of sufficient complexity.3. For large organisations, the network is logically separated based onuser functionalities.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1. 2. 1.2.

1. 1.3.

21

Physical security: Physical security measuresare defined and implemented in line withbusiness and data classification requirements tosecure facilities (e.g. buildings, power supply)and the physical and information assets.Physical security must be capable of effectivelypreventing, detecting and mitigating risksrelating to disasters and accidents (e.g. nature,human, vandalism, terror).

64

No Standard / Control measure Requirements per control to achieve a maturitylevel of 4

Ba

se

do

nc

on

tro

lm

ea

su

re

Ba

se

do

nC

OB

IT4

.1

Ba

se

do

n"P

oin

tsto

co

ns

ide

r"

do

cu

me

nt

Ba

se

do

np

ro

fes

sio

na

le

xp

er

ien

ce

Ba

se

do

ne

xp

er

tv

ali

da

tio

n

Ba

se

do

np

ra

cti

ca

lv

ali

da

tio

n

21.1

Physical security measures: Physicalsecurity measures are defined and implementedin line with business requirements to secure thelocation and the physical assets. Physicalsecurity measures must be capable of effectivelypreventing, detecting and mitigating risksrelating to theft, temperature, fire, smoke,water, vibration, terror, vandalism, poweroutages, chemicals or explosives.

- The following requirements are in place:1. A physical security policy is defined and implemented for thephysical security and access control measures to be followed for ITsites. This policy has been reviewed by the appropriate managementlevel.2. The physical security policy includes the following elements:security measures must be capable of effectively preventing, detectingand mitigating risks relating to theft, temperature, fire, smoke, water,vibration, terror, vandalism, power outages, chemicals or explosives.3. Physical security measures are periodically tested by theorganisation.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.

1. 1.2.3.

2.

21.2

Physical access: Procedures are defined andimplemented to grant, limit and revoke accessto premises, buildings and areas according tobusiness needs, including emergencies. Accessto premises, buildings and areas can bejustified, authorised, logged and monitored.This applies to all persons entering thepremises, including staff, temporary staff,clients, vendors, visitors or any other thirdparty.

- The following requirements are in place:1. A physical security policy is available and also includes the accesspolicy to premises, buildings and areas. This policy has been reviewedby the appropriate management level.2. Access to premises, building and areas is authorized before it isgranted.3. Access to premises, buildings and areas is timely revoked when theaccess is no longer necessary.4. Access logs to premises, buildings and areas with key data (such asdata centres) are periodically reviewed. As part of the review it isdetermined if the visitors were authorised to access the area. Thisapplies to all persons entering the premises, including staff, temporarystaff, clients, vendors, visitors or any other third party.

- The above requirements are periodically evaluated as part of a controlor multiple controls. Based on the results follow up actions are definedand assigned to owners.

1.2.3.4.

4. 2.4.

2.3.

1.

65

Appendix B: Literature used

Articles & Books

Andersion, D.L., 2013, Organizational development: the process of leading organizational change,

SAGE publications.

Bariball, K.L. and While, A., 1994, Collecting data using a semi-structured interview: a discussion

paper, Journal of advanced nursing, 19, pp328-335.

Baudoin, Claude R., and Colin R. Elliott., 2007, "Security maturity assessment method." U.S. Patent

No. 7,290,275.

Baxter, P., and Jack, S., 2008, Qualitative case study methodology: Study design and implementation

for novice researchers, The qualitative report 13.4: 544-559.

Boudreau, Marie-Claude, David Gefen, and Detmar W. Straub., 2001, "Validation in information

systems research: a state-of-the-art assessment." Mis Quarterly: 1-16.

Carlson, Julie A., 2010, "Avoiding traps in member checking." The Qualitative Report 15.5: 1102-1113.

Choo, K.R., 2011, Cyber threat landscape faced by financial and insurance industry, Trends & issues in

crime and criminal justice, No. 408.

Creswell, John W., 2013, Research design: Qualitative, quantitative, and mixed methods approaches.

Sage publications.

Creswell, John W., and Dana L. Miller., 2000, "Determining validity in qualitative inquiry." Theory into

practice 39.3: 124-130.

Cummings, T.G, and Worley, C.G., 2014, Organizational development & Change, Cengage learning.

Damianides, Marios., 2005, "Sarbanes-Oxley and IT governance: New guidance on IT control and

compliance." Information Systems Management 22.1: 77-85.

Janesick, Valerie J, 1994,"The dance of qualitative research design: Metaphor, methodolatry, and

meaning."

Hardy, Gary., 2006, "Using IT governance and COBIT to deliver value with IT and respond to legal,

regulatory and compliance challenges." Information Security technical report 11.1: 55-61.

Heusinkveld, B., 2014, Analyse van relevante aandachtspunten bij de toepassing van Big Data vanuit

het IT-audit perspectief, Vrije Universiteit Amsterdam thesis.

Huber, Ludwig., 1998, "Validation of analytical methods." Validation and Qualification in the Analytical

Laboratories, Interpharm Press, Buffalo Grove, IL 107.

Hussain, Syed Jamal, and M. Sibghatullah Siddiqui., 2005, "Quantified model of COBIT for corporate

IT governance." Information and Communication Technologies. ICICT 2005. First International

Conference on. IEEE.

Koning, E. and Bikker, H., 2012, Effect creëren in de boardroom, de IT-auditor nummer 3, pp17-20.

Kotulic, Andrew G., and Jan Guynes Clark., 2004, "Why there aren’t more information security

research studies." Information & Management 41.5: 597-607.

66

Lagazio, M., Sherif, N. and Cushman, M., 2014, A multi-level approach to understanding the impact of

cyber crime on the financial sector, Computers & Security 45, pp 58-74.

Lemus, Sandra María, Francisco J. Pino, and Mario Piattini Velthius., 2010, "Towards a model for

information technology governance applicable to the banking sector." Information Systems and

Technologies (CISTI), 2010 5th Iberian Conference on. IEEE.

Mays, Nicholas, and Catherine Pope., 1995, "Qualitative research: rigour and qualitative research." Bmj

311.6997: 109-112.

Morimoto, Shoichi., 2009, "Application of COBIT to security management in information systems

development." Frontier of Computer Science and Technology, 2009. FCST'09. Fourth International

Conference on. IEEE.

Nastase, P., Nastase, F. and Ionescu, C., 2009, Challenges generated by the implementation of the IT

standards COBIT 4.1, ITIL V3 and ISO/IEC 27002 in enterprises, Economic Computation & Economic

Cybernetics Studies & Research 43.1 (2009): 16.

Onwuegbuzie, Anthony J., and Nancy L. Leech., 2007, "Validity and qualitative research: An

oxymoron?." Quality & Quantity 41.2: 233-249.

Pederiva, Andrea., 2003, "The COBIT® maturity model in a vendor evaluation case." Information

Systems Control Journal 3: 26-29.

Peltier, Thomas R., 2005, Information security risk analysis. CRC press.

Radovanovic, Dalibor, et al., 2013, "Analysis of methodology for it governance and information systems

audit." The 6th International Scientific Conference “Business and Management 2010. 2010.

Ritchie, Jane, et al., eds. Qualitative research practice: A guide for social science students and

researchers. Sage.

Rolfe, Gary., 2006, "Validity, trustworthiness and rigour: quality and the idea of qualitative research."

Journal of advanced nursing 53.3: 304-310.

Sahibudin, Shamsul, Mohammad Sharifi, and Masarat Ayat., 2008, "Combining ITIL, COBIT and

ISO/IEC 27002 in order to design a comprehensive IT framework in organizations." Modeling &

Simulation. AICMS 08. Second Asia International Conference on.

Sandelowski, Margarete., 1993, "Rigor or rigor mortis: the problem of rigor in qualitative research

revisited." Advances in nursing science 16.2: 1-8.

Simon, M.K., 2011, Dissertation and scholarly research: recipes for success, Seattle, WA, Dissertations

Success, LLC.

Siponen, Mikko, and Robert Willison., 2009, "Information security management standards: Problems

and solutions." Information & Management 46.5: 267-270.

Siponen, Mikko., 2002, "Towards maturity of information security maturity criteria: six lessons learned

from software maturity criteria." Information Management & Computer Security 10.5: 210-224.

von Solms, SH Basie., 2005, "Information Security Governance–Compliance management vs

operational management." Computers & Security 24.6: 443-447.

Spremic, Mario, Zlatan Zmirak, and Krunoslav Kraljevic.. 2008, "IT and business process performance

management: Case study of ITIL implementation in finance service industry." Information Technology

Interfaces. ITI. 30th International Conference on.

67

Stagliano, A.J. and Sillup, G.P., 2014, Transparency and Risk Assessment Reporting: A Case Study

Sector Survey of Cybercrime Disclosures, Journal of Business and Economics, July 2014, Volume 5, No.

7, pp 1134-1140.

Topçu, S., and B. Metin., 2011, "Organizing COBIT control objectives for effective information

technology compliance." Computational Intelligence and Informatics (CINTI), 2011 IEEE 12th

International Symposium on.

Tuttle, Brad, and Scott D. Vandervelde., 2007, "An empirical examination of CobiT as an internal

control framework for information technology." International Journal of Accounting Information

Systems 8.4: 240-263.

Van Oossanen, R. and Biekart, J., 2014, Aantoonbaar in control van uw IT én de veiligheid van

deelnemergegevens!, DNB pensioen seminar, presentation, https://www.dnbpensioenseminar.nl/wp-

content/uploads/2011/09/Presentatie-DNB-Pensioenseminar-2014-workshop-Aantoonbaar-in-

control-over-uw-IT-%C3%A9n-de-veiligheid-van-uw-deelnemersgegevens.pdf.

Vroom, Cheryl, and Rossouw Von Solms., 2004, "Towards information security behavioural

compliance." Computers & Security 23.3: 191-198.

Whitman, Michael, and Herbert Mattord., 2011, Principles of information security. Cengage Learning.

Yin, Robert K., 2013, Case study research: Design and methods. Sage publications.

Websites & Others

Baveco, M., 2014, Informatiebeveiliging binnen de financiële sector: wat kunnen we hiervan leren?,

presentation sheets, http://www.pvib.nl/download/?id=17700312.

Shahim, A. and Matthijse, R., 2010, Vrije Universiteit Amsterstam Postgraduate education IT Audit,

Compliance & Advisory lecture slides.

Trustwave security research, 2014,

https://www2.trustwave.com/rs/trustwave/images/2014_Trustwave_Global_Security_Report.pdf.

Van Oossanen, R. and Biekart, J., 2014, Aantoonbaar in control van uw IT én de veiligheid van

deelnemergegevens!, DNB pensioen seminar, presentation, https://www.dnbpensioenseminar.nl/wp-

content/uploads/2011/09/Presentatie-DNB-Pensioenseminar-2014-workshop-Aantoonbaar-in-

control-over-uw-IT-%C3%A9n-de-veiligheid-van-uw-deelnemersgegevens.pdf.

Website of ISACA: http://www.isaca.org/Groups/Professional-English/po9-4-risk-

assessment/Pages/Overview.aspx

Website of the DNB, several:

o http://www.toezicht.dnb.nl/en/3/51-203304.jsp

o http://www.toezicht.dnb.nl/binaries/50-230767.pdf

o http://www.dnb.nl/en/about-dnb/onze-missie/index.jsp

o http://www.dnb.nl/en/about-dnb/onze-missie/