ETIS Library of Security KPIs - FINAL

Library of Information Security KPIs
Reference document for the ETIS community
Editor: Richard Kerkdijk (TNO)

Date: July 27th 2012
Status: v6 FINAL
Copyright © 2012 Participants in ETIS Information Security Working Group

ETIS Library of Information Security KPIs

Editor: Richard Kerkdijk (TNO)
Owner: Terje Tøndel (ETIS)
 2012 Participants in ETIS Information Security Working Group
Disclaimer
This document contains material which is the copyright of certain ETIS members and may
not be reproduced or copied without permission.
The commercial use of any information contained in this document may require a license
from the proprietor of that information.
© 2012 Participants in ETIS Information Security Working Group Page 2 of 38

Contents
CONTENTS ............................................................................................................ 3
ABBREVIATIONS .................................................................................................. 4
1 INTRODUCTION .............................................................................................. 5
1.1 BACKGROUND ................................................................................................. 5
1.2 PURPOSE AND LIMITATIONS ................................................................................. 6
1.3 ACKNOWLEDGEMENTS ........................................................................................ 6
2 CONTEXT AND GUIDANCE ............................................................................... 7
2.1 CONCEPT AND DEFINITIONS ................................................................................. 7
2.2 ESTABLISHING EFFECTIVE INFORMATION SECURITY KPIS ............................................... 9
2.3 MATURITY LEVELS............................................................................................11
3 SPECIFICATION OF KPIS .............................................................................. 14
3.1 BUSINESS VALUE.............................................................................................15
3.2 RISK MANAGEMENT ..........................................................................................16
3.3 VULNERABILITY MANAGEMENT ..............................................................................19
3.4 IDENTITY & ACCESS MANAGEMENT .......................................................................22
3.5 SPAM AND MALWARE PROTECTION .........................................................................24
3.6 AUDITING AND COMPLIANCE................................................................................28
3.7 SECURITY INCIDENTS .......................................................................................30
3.8 BUSINESS CONTINUITY MANAGEMENT ....................................................................33
3.9 SECURITY RESOURCING .....................................................................................34
REFERENCES ....................................................................................................... 38

Abbreviations
AT A1 Telekom Austria
BCM Business Continuity Management
CAPEX CAPital Expenditure
CEO Chief Executive Officer
CIO Chief Information Officer
CISO Chief Information Security Officer
CSO Chief Security Officer
CTO Chief Technical Officer
DT Deutsche Telekom
fte full time equivalent
IAM Identity and Access Management
IT Information Technology
KPI Key Performance Indicator
KSI Key Security Indicator
OPEX Operational EXpenditure
RTP Risk Treatment Plan
SIEM Security Incident and Event Management
SLA Service Level Agreement
SOx Sarbanes Oxley
TC Telefónica
VC Vimpelcom

1 Introduction
“Trust, but verify”

– Ronald Reagan, after signing INF treaty with Soviet Union in 1987
“You repeat that at every meeting”

- Mikhail Gorbachev, in response to Reagan’s statement
“I like it”
– Ronald Reagan, clarifying his statement to Gorbachev
1.1 Background
Key Performance Indicators (KPIs) are quantifiable variables that reflect the (critical)
success factors of an organisation. KPIs help an organisation define and measure progress
towards organisational objectives and support decision making processes. The concept of
KPIs has existed since the early 1960s and since been embraced in various industries and
working areas. In retail businesses, for example, a KPI might be the percentage of income
that stems from recurring customers. Similarly, a university might see the student
graduation rate as a key indicator of its performance, whilst customer service departments
might look at the percentage of calls answered within the first minute of waiting time.
Assessing performance by means of KPIs has also become common practice for (internal
and commercial) suppliers of IT services. IT related KPIs usually focus on continuity
aspects, e.g. the availability of IT systems and services, the mean time between failures
and the mean time to repair. Such KPIs are often found in Service Level Agreements
(SLAs) between IT suppliers and their customers.
Information security is a business function that has traditionally had difficulty to quantify
its objectives and performance in terms of KPIs. Faced with ever growing pressure on
budgets and manpower, CSOs and CISOs in the telecoms industry have increasingly been
seeking ways to quantify – preferably even monetise - their often intangible objectives and
achievements. Here, the underlying intent was usually to prove their business value
towards executive management and justify the need to maintain (or expand) their
budgets. Unfortunately, establishing effective information security KPIs has turned out to
be a tedious endeavour. The complexity of the matter was clearly revealed in the telco
security benchmark held among ETIS members in the past years. Most telcos that took
part in this benchmark indicated a strong desire to embrace the concept of information
security KPIs. To date, however, many have not been able to actually define and
implement such KPIs and those that have often indicate that the information security KPIs
they were able to devise are too technical for their (business) audiences.
The value of establishing information security KPIs is strongly recognised within the ETIS
Information Security Working Group. Participants in this group therefore took it upon
themselves to establish a library of information security KPIs to serve as a reference
document for the entire ETIS community. This document presents said library.

1.2 Purpose and limitations

The objective of this document is twofold:
1. Provide context and guidance. This document intends to supply ETIS members with
a clear insight into the concept of information security KPIs, including applicable
definitions, and tangible guidance for establishing specific KPI programmes that will be
effective within the individual telco organisations.
2. Suggest actual information security KPIs. This document presents a total of 37
information security KPIs. This specification may serve as a starting point from which
the ETIS members can adopt the elements that are suitable for their own context.
In the remainder of this document, these objectives are addressed in separate chapters.
When going through this library, readers should be aware that the specification of
information security KPIs (see chapter 3) is limited to KPIs that are presently in use
among the ETIS member telcos. These 37 KPIs should by no means be interpreted as the
definitive set of information security KPIs for telecoms providers, but rather as a starting
point for members to develop their own specific set. Here, please note that the KPIs
specified in chapter 3 are predominantly technical of nature. Members that suggested
these KPIs often indicate that they do not fully appeal to the information needs of business
and executive management. Depending on member preferences, the library might be
expanded with a set of “business oriented” information security KPIs in a later stage.
1.3 Acknowledgements
This library would not exist in its present form without the kind and competent
contributions of those participating in the ETIS security group. ETIS would like to thank
the delegates of A1 Austria Telekom, Deutsche Telecom, TDC, Telefónica, Teliasonera and
Vimpelcom for their efforts to this end. A special thank you is in order for Aleksandra Sowa
and Göran Laxén, who both contributed a valuable section to the context and guidance
chapter.

2 Context and guidance
Ever since information security is recognised as a core business process, the need for
effective measurement of that process has been growing. Information security metrics and
KPIs provide means to support this need. Using metrics and KPIs, an organisation is able
to assess whether its information security strategies and approaches are actually working
as effectively as they should. Moreover, metrics and KPIs help an organisation understand
the extent to which information security contributes to its overall objectives.
This chapter introduces the concept of information security KPIs and related terms and
provides guidance on how to use them effectively in a telco organisation.
2.1 Concept and definitions

In order to establish effective information security KPIs, it is important to understand their
purpose and broader context. To this end, the figure below depicts some essential
concepts and relationships.
ETIS member telcos – or any organisation for that matter – will have security policies and
objectives they strive to achieve. Responsible functionaries, e.g. the company’s CSO or
members of the board to which the CSO reports, will have a desire to monitor the status
and progress of such policies and objectives so that they can take appropriate decisions
and/or actions where required. Hence these functionaries have an information need, which
we define as follows:
Information need all insights necessary to manage information security objectives,

goals, risks and problems
Information security KPIs are a means to address this information need in a quantitative
fashion. Here, we define information security KPIs as follows:
KPI a quantifiable characteristic that provides an estimate or evaluation

with respect to (management) information needs

Key Performance Indicators (KPIs) are used by organisations as steering vehicles for
management. Thus, information security KPIs essentially facilitate evaluation, decision
making and governance of information security on tactical or strategic level. Such
information security KPIs usually work best when accompanied by so called decision
criteria, i.e. predefined quantitative values of the KPI that trigger specific decisions or
actions. To this end, we introduce the following definition:
Decision criteria thresholds, targets or patterns used to determine the specific need
for action that might be triggered by a KPI
Decision criteria hence enable an organisation to (formally or informally) define which

actions or decisions should be taken if a KPI reaches a certain value.
This brings us to the issue of actually determining a KPI value and the confusion that
sometimes arises when distinguishing between metrics and KPIs. The National Institute of
Standards and Technology (NIST) in his Special Publication 800-55 [NIST] provides the
following definition of metrics:
“metrics are tools designed to facilitate decision making and improve performance and
accountability through collection, analysis, and reporting of relevant performance-related
data. The purpose of measuring performance is to monitor the status of measured
activities and facilitate improvements in those activities by applying corrective actions,
based on observed measurements”
For the purpose of this document, we shall maintain a more compact definition:
Metric standard of measurement that facilitates the quantification of some

particular characteristic
What metrics and KPIs have in common is that both are derived from the business goals of
the organisation (see also following section). However, a KPI is an indicator that is
material for an organisation (it is a key indicator) and fundamental for management
decision making. Mortensen [Mortenson] defined seven key characteristics of KPIs:
1. KPI echoes organizational goals.

2. KPI is decided by management.
3. KPI provides context.
4. KPI creates meaning on all organizational levels (operational, tactical, strategic).
5. KPI is based on legitimate data.
6. KPI is easy to understand.
7. KPI leads to action.
In practice, a metric is something that can be measured directly on or via some object of
measurement whilst information security KPIs are determined by processing such metrics
in an analytical model and thus transforming the measurable date into a shape that
appeals to the information need of the target audience. As an example, one might for
instance measure the number of active passwords in an organisation (first metric) by
conducting a query on the company’s IAM system (first object of measurement). Possibly,
the target audience’s information need is best satisfied by presenting the number of
passwords per employee of the organisation. In that case, it will also be necessary to
determine the company’s present headcount (second metric), for instance by querying an

HR system (second object of measurement). The aspired KPI is then determined by

dividing the first metric by the second (analytical model).
Note that the terminology introduced above will also be employed in the actual
specification of information security KPIs, as presented in the following chapter.
2.2 Establishing effective information security KPIs
In the 1980s Basili and Weiss [Basili] introduced the so called Goal Question Metrics
approach (GQM. GQM essentially serves to select and implement metrics. The GQM
principle consists first in expressing business goals of the organization. From these goals,
questions describing these goals are derived. Finally, each question is analysed in terms of
what metrics is needed to answer each question. As metrics are defined, measurements
and other metrics have to be identified, to define qualitative or quantitative value of the
metrics
GQM method involves four steps:
1. List the major business goals of the organisation (focus: information security).
(1a. we can derive information security goals from the business goals as a
intermediate step, alike COBIT does for IT goals)
2. Derive from each goal the questions that must be answered to determine if the goals
are being met.
3. Identify metrics that help to evaluate the questions.
4. Decide what must be measured to value the metrics.
The following figure illustrates how metrics may be generated:
GOAL
QUESTION 1 QUESTION 2 QUESTION ...

…
Metrics 1 Metrics 2 Metrics 3 Metrics 4 Metrics ...
Using Goal-Question-Metrics method we can establish monitoring and metrics framework

for almost all aspects of information security, e.g. standardisation level, compliance,
performance, (design and operational) effectiveness, efficiency, quality, productivity, etc.
Metrics involve measurements (and sometimes also other metrics) that concern main
attributes of information security. These are:

1. Processes
(characteristics: internal and external)
Processes are measured to inform on duration, cost, effectiveness and efficiency of
information security measures and activities. Examples of process measurements (or
metrics) are the duration of the process or activity, the effort associated with a process
or activity and the number of incidents of a specified type arising during process or
activity
2. Products
By “products” we mean not only a delivered security product (or measure) but also the
test versions, documents and prototypes produced during the development, testing
and delivery process. All these process outputs can be measured in term of quality,
size, etc. External and internal attributes are distinguished as follows:
- External product attributes depend on product behaviour and environment that
influence the measure. Example of external attributes are: usability,
integrity,efficiency, testability, reusability, portability, operability.
- Internal products attributes are easy to measure in terms of size, length,
functionality, correctness.[22, p.78] Code clarity is an example of internal attribute
according to defined rules like "avoid GOTO".
3. Resources
Resources are measurable entities like personnel, materials and methods. Measuring
resources help managers to understand and control the process. Programmer’s
productivity is often measured in terms of lines of code.
By internal and external attributes of a product, a process or a resource, Fenton and

Pfleeger (see [Fenton]) understand the following:
- Internal attributes of a product, process or resource are those that can be measured
purely in terms of the product, process or resource itself. In other words, an internal
attribute can be measured by examining the product, process or resource on its own,
separate from its behaviour.
- External attributes of a product, process or resources are those that can be measured
only with respect to how the product, process or resource relates to its environment.
Here, the behaviour of the process, product or resource is important, rather than the
entity itself.
According to Fenton and Pfleeger, data that will be collected and measurements that are
made to satisfy metrics must fulfil several essential properties:
- Correctness
The data were collected according to the exact rules of definition of the metrics. For
example, if comments are not supposed to be included in the lines of codes count, then
a check for correctness assures that no comments were counted.
- Accuracy
This property refers to the differences between the data and the actual value. For
example, time measurement will be less accurate on an analog clock than on a digital
one.

- Precision
This refers to the number of decimal places needed to express the data.
- Consistency
Data must be consistent from one measuring device or person to another, without
large differences in value.
- Time-Stamped
We must know exactly when data has been collected in order to allow comparison.
- Replicated
Data definition must be accurate to allow other person to replicate the same
measurement.
Objectivity, reliability and integrity of data are other data properties that are named by
other authors, the latest (integrity) especially if the results of the measurements are used
for monitoring information security and are reviewed by external auditors or investigators
(in fraud investigation, for instance).
There are generally two main ways to collect data - the manual and the automated. The
main benefit of using metrics is that not cemeteries of data are produced, but only the
material and substantial data, which satisfy identified metrics are collected. Its quantity
has to be manageable.
2.3 Maturity levels

KPIs don’t exist without a reason. In order to be able to control information security there
is a need to know the current status and perform necessary actions to reach a wanted
status. These are elements in an information security management system, SMS. E g in
the ISO standard 27000 there are well known steps in the information security process
named “Plan-Do-Check-Act”. KPIs may be used as a subset of possible tools in the Check
part of the SMS.
In order to be successful with KPI implementations they need to be chosen with care,
depending on the need in the organization, so that the purpose with them is clear. We
have noted that the current situation vary a lot between different organizations. One
important aspect is the maturity of the information security process. As the maturity level
increases the need for KPIs will change. At the first steps it may be sufficient to measure if
there is a process in place at all, while at higher maturity levels it may be more useful to
implement KPIs where the performance of the process is measured.
The maturity model proposed here is focused on process maturity and may be used as a
reference, when planning KPI implementation. It may make it possible to foresee what is
required for a successful KPI implementation. The reader should be aware of, however,
that organization, people, influence on the line organization and tools are issues that may
be useful to consider as well.

The figure above was copied from Wikipedia.
When planning for KPI implementation it helps to know the current maturity level of the
information security process in your organization. At maturity level 1 everything is handled
in an Ad Hoc manner. Measuring performance will not be asked for, or even utilized, since
responsibilities are unclear, needed tools are missing and even if heroic efforts are made
by individuals it will solve a problem once, but there will be no lasting impact. On the other
hand at maturity level 5 carefully chosen KPIs will have clear receivers needing the
information in order to take appropriate action by fine tuning an already well defined
process. Hence, there is a good chance that the KPI implementation will succeed.
1 2 3 4 5
Initial Managed Defined Quantitatively Optimized
managed
Characterisation
There is no Informal An information A more The information
systematic processes occur security process systematic and security process
information by managing is developed by documented is a part of the
security process the same type the information information organization’s
in place. The of issues in a security security process culture. There is
process is similar way. Co- function, due to is developed by a balance
characterized operation with pressure from the information between
by the and hand over the line security reactive and
responsible to other units is organization function, and it preventive
person’s made. Security and focussing is used by the actions towards
background and benefits are on the security staff problems.
skills and it will recognized. prioritized and the line
be dependent of issues. organization.
the current Focus is not
priorities and limited to
work load. detection and
reactive
actions.
Examples of suitable KPIs
KPIs measured KPIs measured KPIs measured KPIs measured KPIs measured
once, in order repeatedly. E.g. continuously, continuously continuously

to get related to and the result is and used in a used in a

necessary security used in proactive way, proactive way
investments, incidents or risk processes. e.g. regarding and used to
e.g. for virus assessments security gain an
E.g. regarding
protection. made in requirements overview of the
regulatory
development and follow up in risks, e.g.
requirements
projects. outsourcing regarding the
contracts. quality in the
access rights
management
process.

3 Specification of KPIs
This chapter specifies information security KPIs presently in use among the members of
the ETIS Information Security Working Group. These KPIs are structured in to nine distinct
categories:
• Business value – KPIs that indicate the direct contribution and value of corporate
security teams towards business and operations
• Risk management – KPIs that indicate the effectiveness of risk management
processes and controls
• Vulnerability management –KPIs that address the effect of vulnerability scanning
and security testing activity and the company’s ability to effectively manage any
vulnerabilities found in IT systems
• Identity & Access Management (IAM) – KPIs currently in this category address the
company’s ability to manage administrator rights and access credentials
• Spam and malware protection – KPIs that assess the effectiveness of provisions to
protect against spam, viruses and other malware.
• Auditing and compliance – KPIs that address the company’s follow-up on audit
findings and specific compliance aspects.
• Security incidents – KPIs that appraise nature and severity of security incidents
encountered by the company as well as the follow up actions such incidents trigger.
• Business Continuity Management (BCM) – KPIs in this category currently focus on
existence and effectiveness of technical recovery plans
• Security resourcing – KPIs with respect to security budgets and manpower. Here it
should be noted that some members might consider these as benchmarking items
rather than actual KPIs.
Each of the above categories corresponds to a specific section of this chapter. The actual
KPIs are all presented in the following format:
Kx. Title [source company]

Definition Formal definition of the KPI
Purpose Rationale of the KPI in terms of the value it provides
Target audience Functionary typically interested in this KPI
Base metrics Measurable variables by which the KPI can be calculated
KPI calculation Exact calculation formula for the KPI
Implementation guidance Experiences from the members to guide implementation
For the implementation guidance component, members presently using the respective
KPIs were asked to provide recommendations with respect to
• The source of measurement, e.g. specific IT systems from which the required base
metrics might be extracted
• The method of measurement, i.e. how the base metrics might be quantified
• Reporting formats for the KPIs that have proven successful

• Decision criteria, i.e. the criteria by which the KPI may trigger business decisions
• Viable frequencies for measuring and reporting the KPI
The KPI specification addresses these issues to the extent that members were willing and
able to provide tangible suggestions. Note that the KPIs presented below are based on
inputs from A1 Telekom Austria, Deutsche Telekom, TDC, Telefónica and Vimpelcom.
3.1 Business value
K1. Issuance of security advisories

Definition Number of security advisories issued to specific segments of
the organisation
Purpose Evaluate the extent to which the corporate security team
issues security recommendations to the organisation, thus
directly aiding business and operations in fulfilling their
objectives.
Note: this KPI will often be pushed by the corporate security
team itself to have a tangible means of proving its value for
business and operations.
Target audience CSO/ CISO, business management
Base metrics A = # security advisories issued to the organisation
KPI calculation A
Implementation guidance Requires manual administration by corporate security team.
Members might consider differentiating the number of
advisories by the segment of the organisation to which it
was issued, i.e. # security advisories for business segment x
(e.g. residential customer area), operations segment y (e.g.
IT operations), staff department z (e.g. legal department),
etc. Moreover this KPI is most valuable when combined with
an indicator of the extent to which security advisories were
actually adopted by the respective departments (see K2).
K2. Adoption of security advisories

Definition Percentage of security advisories that was adopted by IT
and/or business departments targeted.
Purpose Evaluate the extent to which security advisories as issued by
corporate security team are actually followed up in the
organisation.
Note: this KPI will often be pushed by the corporate security
team itself to have a tangible means of proving its value for
business and operations.
Base metrics A = # security advisories adopted by applicable IT and/or
business departments

B = # security advisories issued by corporate security team

KPI calculation A
*100
B
Implementation guidance Both base metrics usually require manual administration by
the corporate security team. Members might consider
differentiating this KPI by the segment of the organisation to
which it was issued, i.e. % security advisories adopted by
business segment x (e.g. residential customer area),
operations segment y (e.g. IT operations), staff department
z (e.g. legal department), etc.
K3. Operational security duties

Definition Percentage of information security staffing dedicated to
operational security duties
Purpose Value the extent to which information security staff directly
contributes to operational needs of the organisation, i.e. the
balance between management and operational resources for
information security.
Note: “operational security duties” refers to tasks such as
firewall and IDS maintenance, user management, etc.
Target audience CSO/ CISO, security committee (if applicable)
Base metrics A = # ftes dedicated to operational security duties
B = # information security ftes
KPI calculation A
*100
B
Implementation guidance The member using this KPI quantifies the base metrics
manually from department and function headcounts and
depicts the KPI in bar charts that reveal differences among
different companies/subsidiaries in the group organisation.
3.2 Risk management
K4. Risk assessment on IT systems

Definition Percentage of information systems for which risk analysis
was performed or updated in the past [quarter/ year]
Purpose Assess the extent to which risks of IT systems have been
appraised.
Target audience CSO/ CISO
Base metrics A = # IT systems for which risk analysis was performed in
past [quarter/ year]
B = # IT systems existing within the company

KPI calculation A
*100
B
Implementation guidance Base metric B will usually require a manual count, for
instance based on risk analysis reports. Base metric A might
be available from a central IT system repository or otherwise
be delivered by the internal IT unit.
The member presently employing this KPI reports it in a bar
chart that depicts differences among different group
companies (subsidiaries). This bar chart is refreshed on a
yearly basis.
K5. Project security classification

Definition Percentage of projects to which a formal security
classification (e.g. critical, irrelevant, …) was assigned.
Purpose Evaluate the extent to security projects were assessed and
classified by corporate security team.
Note: Some members assign a security rating to
development projects in their early stages. This rating
subsequently determines the (detail of the) security
approach for the remainder of the project. Projects rated as
“critical” might for instance require a thorough risk
assessment whilst less “critical” projects might follow a
standard security baseline. This KPI is most valuable for
members that employ such a project classification scheme.
Base metrics A = # projects to which a formal security classification was
assigned by corporate security team
B = # projects currently running.
KPI calculation A
*100
B
Implementation guidance Base metric A usually requires manual administration by the
corporate security team, although some members have
formalised their project classification schemes to such an
extent that ratings can be gathered from the general project
administration as well. Base metric B is usually available via
a centralised project administration system.

K6. Fulfilment of Risk Treatment Plan

Definition Percentage of Risk Treatment Plans that has been
implemented in full.
Purpose To evaluate the effectiveness of the risk management
processes, in particular the extent to which Risk Treatment
Plans (RTPs) are actually put into effect.
Base metrics A = # Risk Treatment Plans demonstrably implemented
B = # Risk Treatment Plans defined.
KPI calculation A
*100
B
Implementation guidance Possibilities to gather the above base metrics strongly
depend on how the member administers its Risk Treatment
Plans (RTPs) and how the actual implementation is
monitored. In most cases, however, RTPs will go through a
formal approval process and be collected in a centralised
administration – often controlled by the corporate security
team. In such cases, base metric B can be gathered directly
from that administration.
Base metric A requires insight into the extent that security
implementations actually follow the RTP. Here, one approach
is to formally audit the implementation of each RTP. Whilst
this is likely to be the most accurate approach, it also
requires extensive effort and may hence not always be
realistic. To alleviate the effort, members might choose to
audit only a (selected or arbitrary) sample of available RTPs.
Alternatively, owners of the various RTPs might be required
to compile and deliver self-assessment reports on RTP
compliance and base metric A might be deduced from the
overall set of such reports. This is a more practical approach
but it is also more prone to error.
K7. IT Risk Management

Definition How many of the IT Risk elements in scope, are assessed by
the new IT Risk Management methodology.
Purpose Establish harmonized risk management with high data
quality.
Target audience CSO / CISO, business management
Base metrics A = # IT projects & IT applications assessed according to IT
Risk Management methodology, process and timeline
B = # IT projects & IT applications

KPI calculation A
*100
B
3.3 Vulnerability management
K8. Coverage of vulnerability scanning

Definition Percentage of externally exposed and/or business critical IT
systems that has been subjected to vulnerability scanning.
Purpose Evaluate coverage of vulnerability scanning activity with
respect to vital IT systems.
Base metrics A = # externally exposed and/or business critical IT systems
subjected to vulnerability scanning
B = # externally exposed and/or business critical IT systems
KPI calculation A
*100
B
Implementation guidance Base metric A can usually be quantified directly by the
vulnerability scan tools in use at the member. Base metric B
is more tedious, since it is difficult to keep track of all
systems accessible from the outside or otherwise deemed
“vital” in a large organisation. The KPI as defined above is
therefore only practicable if the member has a solid
administration of externally exposed and/or business critical
IT systems. If such an administration is not available, the
member could consider quantifying only base metric A. The
KPI is then simplified to the absolute number of critical IT
systems subjected to vulnerability scanning.
K9. Repetitive security scanning

Definition Percentage of IT systems for which security scanning is
applied on a repetitive basis.
Purpose Evaluates the effectiveness of security scanning activities by
assessing the extent to which such scanning is repeated on a
regular basis to reflect evolving risk profiles.
Target audience CSO/ CISO, unit management of IT operations
Base metrics A = # IT systems subjected to periodic security scanning
B = # IT systems on which security scan was performed
KPI calculation A
*100
B
Implementation guidance Both base metrics can usually be acquired directly from
security scanning tools. The member that suggested this KPI

reports the percentage of scanned IT systems per

operational department on a monthly basis.
K10. High risk security scan results

Definition Number of security scan results designated as “high-risk”
Purpose Assess extent to which security/ vulnerability scanning
activity results in “high-risk” items that must be followed up
outside of any standard release management schedule.
Note: refers to security scan results that have such a high
priority that fixing them cannot be delayed until the next
standard release.
Base metrics A = # security scan results designated as “high-risk”
KPI calculation A
Implementation guidance This KPI can usually be gathered from the analysis reports
that members compile following security scan activity. Such
reports will address follow-up actions required and should
hence also show security scan results that require immediate
attention. Actually quantifying the KPI will be a manual task.
This KPI is most valuable when combined with an indicator of
the extent to which high-risk scan findings were actually
fixed, see KPIs K10 and K11.
K11. Follow-up on security testing

Definition Percentage of IT systems for which findings from penetration
and similar testing effort were effectively followed up.
Purpose Evaluates the extent to which vulnerabilities in IT systems,
identified through penetration testing or similar, are
adequately followed up and closed.
Target audience CSO/ CISO, business management, IT operations
Base metrics A = # IT systems on which vulnerabilities found through
(penetration) testing were resolved
B = # IT systems subjected to a penetration test or similar
KPI calculation A
*100
B
Implementation guidance Base metric B can usually be quantified directly by the
vulnerability/ security scanning tools in use at the member
or otherwise be abstracted from security testing plans
and/or reports.
Base metric A could be determined manually, e.g. through
dialogue with the departments or specialists to which follow-

up actions were assigned. Alternatively, it could be appraised

by repeating the security testing exercise and assessing the
delta (drop) in IT systems that have (critical) vulnerabilities.
The member that uses this KPI reports on a monthly basis.
K12. Effectiveness of vulnerability mitigation

Definition Percentage of known critical vulnerabilities for which
mitigating measures have been implemented.
Purpose To evaluate the effectiveness of vulnerability management
processes.
Target audience CSO/ CISO, CTO, unit managers in IT operations
Base metrics A = # critical vulnerabilities mitigated
B = # critical vulnerabilities known
KPI calculation A
*100
B
Implementation guidance Both base metrics can usually be gathered through the
automated vulnerability scanning tools in use. If these
scanning tools only quantify the present number of critical
vulnerabilities, scans might be repeated to see if this number
drops as mitigating measures are implemented. The
observed delta in present critical vulnerabilities then equals
base metric A.
Members presently employing this KPI typically report it on a
monthly basis.
Note: some variations on this KPI are conceivable, e.g. one
member characterises the effectiveness of vulnerability
mitigation by dividing
# clients/servers that have no critical vulnerabilities
by
# clients/servers scanned for vulnerabilities.
The resulting percentage of clients/servers without critical
vulnerabilities gives a more direct view on present security
risk in particular networks.
K13. Effectiveness of patch management procedures

Definition Percentage of IT systems for which patch management
procedures were completed to full effect.
Purpose To evaluate the effectiveness of patch management
procedures, i.e. the extent to which such procedures actually
result in IT systems that are equipped with all required
security patches.
Target audience CSO/ CISO, CIO, CTO

Base metrics A = # IT systems equipped with all required security patches

B = # IT systems in existence
KPI calculation A
*100
B
Implementation guidance Both base metrics can usually be acquired directly from a
vulnerability scanning tool. Base metric B might also be
obtained from the central IT repository (if available) or
otherwise through enquiry at the company’s IT unit.
This KPI would typically be measured on a monthly basis. A
bar chart depicting the KPI value over the past (6 or 12)
months provides good insight into the effectiveness of patch
management procedures and any improvements that might
have been initiated in the course of time.
K14. Security gap closing

Definition Progress of planned remediation for identified IT security gap
findings in gap closing programs. The progress is measured
against the consolidated project plan(s) of the program(s).
The KPI indicates to what degree the remediations follow the
plan.
Purpose Ensure maximum security of customer data by closing
identified security gaps.
Base metrics A = # findings closed
B = # findings (plan)
KPI calculation A
*100
B
3.4 Identity & Access Management
K15. Violation of administrator rights

Definition Number of violations of administrator rights on IT systems
Purpose Assesses the extent to which administrator rights on IT
systems have been violated in a certain time span.
Base metrics A = # unauthorised changes on IT systems registered in
past [month/quarter/year]
KPI calculation A
Implementation guidance The above metric can usually be acquired from system logs,
provided the IT system is configured to log administrator
actions. In principle, logs can be analysed manually per

individual IT system. This approach is, however, time

consuming and susceptible to errors. A more efficient
approach is to forward system the system logs to a central
analysis tool, e.g. a Security Incident and Event
Management (SIEM) system, and conduct the analysis
through automated intelligence.
K16. Magnitude of access credentials

Definition Average number of access credentials per end user.
Purpose Value the complexity of access credential structures.
Note: KPI refers to internal and possibly also external
personnel accessing the company’s information systems. The
number of access credentials refers to the number of
usernames/passwords and any alternate means of
identifying and authenticating end users for the purpose of
granting them access to such information systems.
Base metrics A = # active access credentials
B = # employees in the organisation
KPI calculation A
B
Implementation guidance Base metric A might be available from centralised IAM
systems (provided that such systems are in place) or be
gathered from the internal IT department. The latter might
involve some manual work.
yearly basis.
K17. Recovery of access credentials

Definition Average number of access credential recoveries.
Purpose Asses end user ability to manage and remember access
credentials, e.g. passwords
Note: KPI refers to end user requests for password change
or similar access credential replacement, e.g. caused by loss
(forgetting) or block of the existing credentials.
Base metrics A = # access credentials resets/ reactivations in past
[month/ quarter/ year]

KPI calculation A
B
Implementation guidance Base metric A is usually available via the internal IT
helpdesk. Automated measurement is a possibility if
a) the security helpdesk registers incoming calls in a
database of some sort and
b) this database allows helpdesk employees to categorise
the call as “request for access credential recovery”
If such automated measurement is not easily implemented,
the helpdesk team could simply be instructed to count the
number of credential recovery requests manually and report
this number via e-mail or some other practical means.
yearly basis.
3.5 Spam and malware protection
K18. Effectiveness of virus mitigation

Definition Percentage of viruses on end user systems that was
effectively mitigated.
Purpose Evaluate the effectiveness of virus mitigation, i.e. the extent
to which viruses detected on end user systems were
effectively removed or otherwise mitigated.
Note: whilst the member presently employing this KPI
focuses on internal end users only, it could also be applied to
end user systems at corporate customers. Such a change of
focus would probably yield a different target audience.
Target audience CSO/ CISO, IT operations unit
Base metrics A = # viruses mitigated on end user systems
B = # viruses detected on end user systems
KPI calculation A
*100
B
Implementation guidance Most common anti-virus solutions (products) will quantify
the above base metrics directly. The figure below presents a
possible reporting format (as used by the member that
suggested this KPI). The member that uses this format,
reports the KPI on a monthly basis.

Please note that the blue line represents the virus mitigation
percentage, whilst the red line indicates the update level of
the anti-virus solution (i.e. the extent to which virus
definitions are up to date – a different but related KPI).
K19. Effectiveness of spam filtering

Definition Percentage of e-mails bound for end users that was actually
delivered to an end user mailbox.
Purpose To evaluate the effect of spam filtering provisions.
Note: this KPI could be applied for internal end users, but
also be of value for corporate or residential customers.
Target audience for the KPI report might vary depending on
the specific focus employed.
Target audience CSO/ CISO, business management, IT operations
Base metrics A = # e-mails delivered to end user mailboxes
B = # incoming e-mails bound for end user mailboxes
KPI calculation A
*100
B
Implementation guidance Most common anti-spam solutions (products) will quantify
the above base metrics directly. The figure below presents a
possible reporting format (as used by the member that
suggested this KPI). The member that uses this format,
reports the KPI on a monthly basis.
In this graph the red line represents spam e-mails whilst the
blue line represents e-mails delivered to end user inboxes,

hence this member chose to report slightly different

parameters than the KPI specified here. Specifically, whilst
the KPI is defined as (A/B)*100 [%], the above graph
depicts A (blue line) and B-A (red line) both in absolute
numbers. This illustrates the possibility to slightly fine-tune
KPIs to accommodate the information and reporting needs of
the target audience (as explained in chapter 2).
K20. Effectiveness of anti-virus update

Definition Percentage of systems provisioned with the most recent
anti-virus definitions.
Purpose To evaluate the effectiveness of anti-virus update processes.
Note: this KPI could for instance be applied to internal end
user systems or end user systems of corporate customers.
Target audience for the KPI report might vary depending on
the specific focus employed.
Base metrics A = # end user systems provisioned with the most recent
anti-virus definitions
B = # end user systems in existence
KPI calculation A
*100
B
Implementation guidance Base metric A might be quantified in a variety of ways,
depending on means available. One approach is to conduct a
vulnerability scan across all end user systems and configure
it to assess whether these systems have been supplied with
up to date anti-virus definitions. Alternatively, anti-virus
solutions under control of an internal IT unit or a sourcing
partner might be able to supply this number directly.
Base metric B is usually available from internal IT
repositories or via the (internal or external) supplier of the
office automation environment.
The member that uses this KPI reports it on a monthly basis.
K21. Malware handling at security helpdesk

Definition Number of virus and malware related calls to security
helpdesk in past period.
Purpose Assess customer’s exposure to viruses and malware and
extent to which this yields actual incidents.
Note: whilst the member presently employing this KPI
focuses on internal end users only, it could also be applied to
corporate or even residential customers. Such a change of
focus would probably yield a different target audience.


Base metrics A = # virus and/or malware related calls to security
helpdesk in the past [month/ quarter]
KPI calculation A
Implementation guidance Automated measurement is a possibility if
a. the security helpdesk registers incoming calls in a
database of some sort and
b. this database allows helpdesk employees to flag the call
as “virus/ malware related”
If such automated measurement is not easily implemented,
the helpdesk team could simply be instructed to count the
number of virus/malware related calls manually and report
this number via e-mail.
The figure below presents a possible reporting format (as
used by the member that suggested this KPI). The member
that uses this format, reports the KPI on a monthly basis.
Please note that the blue bars represent the virus/malware

calls, whilst the red bars depict the (related) number of end
user system reinstallments. The latter corresponds to KPI
#K9 in this specification.
K22. Reinstallment of end user systems

Definition Percentage of end user systems that has been reinstalled
due to virus or malware incidents.
Purpose Assess customer’s exposure to viruses and malware and
extent to which this yields actual incidents.
Target audience CSO/ CISO, business management, IT operations unit
Base metrics A = # end user systems reinstalled due to virus or malware
in the past [month/ quarter/ year]
B = # of active end-user systems in that period

KPI calculation A
*100
B
Implementation guidance Base metrics can be retrieved from IT operations unit,
provided they maintain a log of reinstallations and
corresponding root causes. Arrangements to this end should
be made with the corresponding departments. If the
member’s organisation maintains an IT helpdesk or similar
team, this seems like the most likely candidate to make
working arrangements with since this is will be the
notification point that first identifies the need to reinstall an
end user system.
Note that a possible reporting format is presented under the
implementation guidance for KPI #K8. The member that
uses this format, reports the KPI on a monthly basis.
3.6 Auditing and compliance
K23. Follow-up on audit findings

Definition Percentage of findings from security audits that has been
closed.
Purpose Assesses the extent to which findings from (internal or
external) security audits have been followed up.
Base metrics A = # audit findings for which follow-up was finalised
B = # audit findings for which follow-up was necessary
KPI calculation A
*100
B
Implementation guidance The base metrics will often require manual quantification.
Quantifying base metric A might for instance require a
dialogue with the departments or specialists to which follow-
up actions were assigned, whilst base metric B is usually
abstracted from the applicable security audit reports. Some
members might, however, have workflow tools that register
audit follow-up and hence enable automated measurements
of the above base metrics.
The figure below presents a possible reporting format (as
used by the member that suggested this KPI). The member
that uses this format, reports the KPI on a monthly basis.

In this figure, the blue bars represent actions “finalised”,

whilst red corresponds to “answered”, green to “planned”
and violet to “not planned yet”. Please note that the above
figure presents the base metrics A (blue) and B (sum of
other bars) rather than the actual “audit follow-up” KPI.
Nonetheless the graph provides a good indication of
reporting possibilities.
Note that the sudden peak in January 2012 stems from a
new security audit that was concluded at that time.
K24. SOx compliance

Definition Percentage of IT systems for which SOx mandated IT
security controls are in place.
Purpose Assess SOx compliance within the company.
Target audience CSO/ CISO, CEO, business management
Base metrics A = # IT systems equipped with all SOx mandated IT
security controls
B = # IT systems for which SOx compliance is required
KPI calculation A
*100
B
Implementation guidance Base metric A could for instance be gathered manually from
SOx audit reports. Alternatively, system logs could be
analysed to assess whether SOx controls are functioning in
accordance with applicable policies. The latter could be
automated by forwarding system logs to a centralised
analysis platform, e.g. a Security Incident and Event
Management (SIEM) solution of some sort.
This KPI is typically reported on a yearly basis, preferably
well before the company’s annual report is due. Members
might, however, also choose to report the KPI on a quarterly
basis so that any deficiencies can be addressed in the course
of the year rather than through last minute (crash) actions.

K25. Security Compliance

Definition To what extend security relevant new projects or system
implementations comply to security requirements.
Purpose Ensure compliance of new projects to security policies.
Base metrics A = % of security relevant new projects compliant to
security requirements
B = % of security relevance checks conducted on new
projects
KPI calculation A*B
3.7 Security incidents
K26. Severity of security incidents

Definition Percentage of registered security incidents that was
classified as “major” or “critical”
Purpose Assesses the severity of security incidents encountered.
Note: one of the members presently using this KPI applies it
to all incidents of sufficient severity to be reported to a high
decision making body (e.g. security committee or
management committee, depending on telco organisation).
Base metrics A = # security incidents classified as “major” or “critical”
B = # security incidents registered
KPI calculation A
*100
B
Implementation guidance Members that have an incident registration or incident
management (trouble ticketing) solution in place will usually
be able to quantify both base metrics directly from that
system. Here, an important requisite is that incident
classifications such as “major” or “critical” are actually
traceable in this system.
If an incident registration or incident management system is
not available but members maintain a distinct notification
point or helpdesk for security incidents, the helpdesk staff
might be instructed to administer the amount of “major” or
“critical” incidents. Here it will be important to define the
“major” or “critical” classification in terms that are
practicable for helpdesk employees.
An alternative approach to quantify base metrics A and B is
to gather them from audit or incident reports or perhaps
from insurance company reports or service platform logs.
This (manual) approach, however, is likely to be time

consuming and less accurate.

One of the members presently employing this KPI reports it
in a bar chart that depicts differences among different group
yearly basis.
K27. Security incidents with internal origin

Definition Percentage of registered security incidents that has an
internal origin
Purpose Assesses the source and nature of information security
incidents.
Base metrics A = # security incidents with an internal origin
KPI calculation A
*100
B
Implementation guidance Members that have a company wide incident registration
solution in place will usually be able to quantify both base
metrics directly from that system. Here, an important
requisite is that incidents with an internal origin are clearly
classified as such in this registration system.
Members that don’t have an incident registration system in
place might gather base metrics A and B manually, e.g. from
audit or incident reports or perhaps from insurance company
reports or service platform logs. This approach, however, is
likely to be more time consuming and less accurate.
yearly basis.
K28. External reporting of security incidents

Definition Percentage of registered security incidents that was formally
reported to external stakeholders.
Purpose Assess commitment and willingness to denounce information
security incidents to external stakeholders (e.g. customers,
government).
Note: the member that suggested this KPI applies it to
incident for which official reports were filed towards law
enforcement and regulatory authorities. This might be an
interesting perspective for many members in the near future
in view of the EU directive on reporting data breaches to the
national authority (“article 13”).


Base metrics A = # security incidents formally reported to external
stakeholders
KPI calculation A
*100
B
Implementation guidance Members that have a company wide incident registration
requisite is that incidents reported to external entities are
actually traceable in the registration system.
place might gather base metrics A and B manually, e.g. from
audit or incident reports or reports filed to law enforcement.
Alternatively, the information might be available at legal
departments or fraud management teams or simply be
archived manually by the security function. Note that manual
registration and calculation is likely to be more time
yearly basis.
K29. Incident resolve effort

Definition Average resolve effort for information security incidents.
Purpose Asses the average time required for resolving an information
security incident.
Base metrics Ax = time elapsed between detection and closure of
information security incident x
KPI calculation
∑A
1-B
x
B
Implementation guidance Members that have a (company wide) incident registration
requisite is that date and time both detection and closure are
registered accurately for each individual incident.
place might gather base metrics A and B manually, e.g. via
audit or incident reports or through dialogue with the
operational departments that actually handled the incident.
This manual approach, however, is likely to be more time

yearly basis.
3.8 Business Continuity Management
K30. Establishment of recovery plans

Definition Percentage of information systems for which a recovery plan
has been established.
Purpose Assess the organisation’s readiness to deal with eventualities
that might affect business continuity (and hence the
maturity of contingency planning).
Target audience CSO/ CISO, business management, security committee (if
applicable)
Base metrics A = # IT systems with recovery plan in place
B = # IT systems within the company
KPI calculation A
*100
B
Implementation guidance Base metric A will usually require a manual count of
information system recovery plans in existence.
yearly basis.
K31. Testing of recovery plans

Definition Percentage of information system recovery plans that was
tested in the past [quarter/ year]
Purpose Assess the effectiveness of present recovery plans for
information systems.
Note: testing of a system recovery plan usually refers to an
exercise in which continuity disruptions are simulated.
Base metrics A = # tested information system recovery plans
B = # information system recovery plans in place
KPI calculation A
*100
B
Implementation guidance Both metrics will usually require a manual count. Since a

recovery plan test (exercise) will usually result in some sort

of evaluation or testing report, base metric A might be
appraised by counting the amount of such reports produced
in the applicable period.
yearly basis.
3.9 Security resourcing
K32. Information security budget within IT

Definition Percentage of IT budget that was dedicated to information
security.
Purpose Value the level of budgetary resources dedicated to
information security within the IT departments
Note: refers to monetary (CAPEX and OPEX) budgets
available for IT security projects or investments, not the
salaries of IT security staff.
applicable)
Base metrics A = IT expense and investment dedicated to information
security
B = Overall IT expense and investment
KPI calculation A
*100
B
Implementation guidance IT security budgets can usually be abstracted from the year
plans (formal budgets) of departments with IT security
duties. In many cases these plans can all be gathered from a
single financial/ control unit. If this is not feasible, each
relevant department could be asked to deliver base metric A
for their specific context and the outcome could be summed
up manually. Similarly, base metric B is usually available via
corporate and/or IT finance units.
yearly basis.
Note: whilst the member that suggested this KPI considers
IT security budget only, an appraisal from other perspectives
(e.g. information security, physical security or even all
security related activity) is also conceivable. In such cases,
base metric B should be changed into the most suitable
(meaningful) reference budget.

K33. Security professionals within IT

Definition Percentage of IT security professionals among IT staff
Purpose Compare the professional resources dedicated to IT security
against those dedicated to IT on an overall basis.
available)
Base metrics A = # IT security professionals among IT staff
B = # IT staff
KPI calculation A
*100
B
Implementation guidance Both base metrics will usually be available from HR
administrations. Base metric A might, however, require a
manual headcount in some cases. The latter is applicable if
the HR administration distinguishes functions and roles of
internal employees on a relatively high level only (e.g. in
terms of “engineers”, “managers” and “consultants”,
whereas base metric A would require insight into “security
engineers”, “managers of security teams” and “security
consultants”).
yearly basis.
Note: whilst the member that suggested this KPI considers
IT security staff as a portion of overall IT staff, an appraisal
from other perspectives (e.g. information security, physical
security or even all security related activity) is also
conceivable. In such cases, base metric B should be changed
into the most suitable (meaningful) reference. As an
example, some members might find it useful to assess #
information security staff (base metric A) as a portion of the
companies overall headcount (base metric B).
K34. Budget per information security professional

Definition Monetary budget per information security professional
Purpose Value the level of monetary dedication to information
security.
Note: refers to monetary (CAPEX and OPEX) budgets
available for information security projects or investments,
not the salaries of information security staff.
Base metrics A = Total monetary budget for information security
B = # information security professionals

KPI calculation A
B
Implementation guidance Information security budgets can usually be abstracted from
the year plans (formal budgets) of departments with specific
information security responsibilities. In many cases these
plans can all be gathered from a single financial/ control
unit. If this is not feasible, each relevant department could
be asked to deliver base metric A for their specific context
and the outcome could be summed up manually.
Base metric B could be quantified by means of a headcount
among departments that have information security
responsibilities, but might also be available via corporate HR.
yearly basis.
Note: some members might find it more suitable to quantify
base metric B as the number of information security ftes
rather than employing a headcount that might include part-
time employees.
K35. Outsourcing of information security duties

Definition Percentage of information security staff that has been
outsourced.
Purpose Assess extent to which information security duties have been
outsourced to external parties.
Base metrics A = # external information security ftes
B = # information security ftes (both internal and external)
KPI calculation A
*100
B
Implementation guidance Base metric A can usually be abstracted from outsourcing
contracts, whilst metric B can be based on a manual
headcount or is perhaps available from department year
plans or the HR administration.
yearly basis.
K36. Budget for information security training

Definition Average expense per internal employee in security training
and security awareness

Purpose Value the company wide investment in information security

knowledge and skills.
Note: refers to CAPEX and OPEX investment for information
security training of all employees, not only information
security professionals.
Base metrics A = Monetary budget devoted to information security
training
KPI calculation A
B
Implementation guidance The majority of investments in information security training
will usually be done or at least be requested by departments
that have specific information security responsibilities (not in
the least the corporate security team). A manual inventory
amongst these departments should provide a sufficiently
accurate appraisal for base metric A.
Base metric B is usually available from a variety of sources,
e.g. corporate HR departments, the company’s annual report
or even the company’s public website.
yearly basis.
K37. Man hours for information security training

Definition Average number of information security training hours per
information security professional
Purpose Value the knowledge level of information security
professionals in the organisation.
Base metrics A = # information security training hours
B = # information security professionals
KPI calculation A
B
Implementation guidance Both base metrics can usually be gathered directly from the
year plans (formal budgets) of departments in which the
information security professionals reside.
yearly basis.

References
[Basili] Basili, V.R. and Weiss, D.M. A methodology for collecting valid
software engineering data. IEEE Transactions of Software
Engineering 10 (6) (Nov. 1984), 728–738
[Fenton] Fenton, N., and Pfleeger, S. L. Software Metrics - A Rigorous and

Practical Approach, 2 ed. International Thomson Computer Press,
London, 1996 (p 74 ff.)
[Mortenson] Dennis Mortensen: “The difference between a KPI and a Metric”.

http://visualrevenue.com/blog/2008/02/difference-between-kpi-and-
metric.html
[NIST] National Institute of Standards and Technology (NIST): Performance

Measurement Guide for Information Security. SP 800-55 (Rev. 1),
June 2008


ETIS Library of Security KPIs - FINAL

Uploaded by

Document Informationclick to expand document informationSecurity KPIs

Document Informationclick to expand document information

Copyright:

Available Formats

ETIS Library of Security KPIs - FINAL

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ETIS Library of Security KPIs - FINAL

Uploaded by

Copyright:

Available Formats

Library of Information Security KPIs

Reference document for the ETIS community

Editor: Richard Kerkdijk (TNO)

Copyright © 2012 Participants in ETIS Information Security Working Group

ETIS Library of Information Security KPIs

© 2012 Participants in ETIS Information Security Working Group Page 2 of 38

© 2012 Participants in ETIS Information Security Working Group Page 3 of 38

© 2012 Participants in ETIS Information Security Working Group Page 4 of 38

“Trust, but verify”

“You repeat that at every meeting”

© 2012 Participants in ETIS Information Security Working Group Page 5 of 38

1.2 Purpose and limitations

© 2012 Participants in ETIS Information Security Working Group Page 6 of 38

2 Context and guidance

2.1 Concept and definitions

Information need all insights necessary to manage information security objectives,

KPI a quantifiable characteristic that provides an estimate or evaluation

© 2012 Participants in ETIS Information Security Working Group Page 7 of 38

Decision criteria hence enable an organisation to (formally or informally) define which

Metric standard of measurement that facilitates the quantification of some

1. KPI echoes organizational goals.

© 2012 Participants in ETIS Information Security Working Group Page 8 of 38

HR system (second object of measurement). The aspired KPI is then determined by

2.2 Establishing effective information security KPIs

GQM method involves four steps:

The following figure illustrates how metrics may be generated:

QUESTION 1 QUESTION 2 QUESTION ...

Metrics 1 Metrics 2 Metrics 3 Metrics 4 Metrics ...

Using Goal-Question-Metrics method we can establish monitoring and metrics framework

© 2012 Participants in ETIS Information Security Working Group Page 9 of 38

By internal and external attributes of a product, a process or a resource, Fenton and

© 2012 Participants in ETIS Information Security Working Group Page 10 of 38

2.3 Maturity levels

© 2012 Participants in ETIS Information Security Working Group Page 11 of 38

The figure above was copied from Wikipedia.

© 2012 Participants in ETIS Information Security Working Group Page 12 of 38

to get related to and the result is and used in a used in a

© 2012 Participants in ETIS Information Security Working Group Page 13 of 38

Kx. Title [source company]

© 2012 Participants in ETIS Information Security Working Group Page 14 of 38

3.1 Business value

K1. Issuance of security advisories

K2. Adoption of security advisories

© 2012 Participants in ETIS Information Security Working Group Page 15 of 38

B = # security advisories issued by corporate security team

K3. Operational security duties

3.2 Risk management

K4. Risk assessment on IT systems

© 2012 Participants in ETIS Information Security Working Group Page 16 of 38

K5. Project security classification

© 2012 Participants in ETIS Information Security Working Group Page 17 of 38

K6. Fulfilment of Risk Treatment Plan

K7. IT Risk Management

© 2012 Participants in ETIS Information Security Working Group Page 18 of 38

3.3 Vulnerability management

K8. Coverage of vulnerability scanning

K9. Repetitive security scanning

© 2012 Participants in ETIS Information Security Working Group Page 19 of 38