Risk MGMT Final Jan2010

2009

SETTING UP OF RISK MANAGEMENT
PROJECT ON PROCESS AND INFORMATION
SECURITY METRICS FOR IT SERVICES
Submitted by

S. Kalpana Devi | EMB80037
C. Nithya | EMB80006
P. Ravikumar | EMB80169
Project on Setting up of Risk Management Process

Student Declaration

I, hereby declare that this project report, “Setting up of Risk Management
Process and Information Security Metrics for IT Services” submitted to
Kuvempu University & ICBMS Educational Trust for the award of a degree
“Executive Master of Business Administration” record of original and
independent work carried out by me.

Date:
Place:

Signature
2
Acknowledgment
I would like to express my sincere gratitude to Mr. Ranganathan, for the
esteemed guidance and expert advice rendered by him in my modest
attempt to prepare this project report. He is the source of inspiration, who
impressed me with his dedication and sincerity to the subject of Systems &
Quality.

My special thanks to Dean of ICBMS Mr. A. Chandrasekaran, Mrs. Usha
Chandrasekaran and Mr. G Lakshmi Sekhar, for their silent and meaningful
guidance & support towards my career development. I would like to thank
Kuvempu University and ICBMS Educational Trust for the support given
throughout the Executive MBA course.

My heartfelt thanks to Priya Technologies Pvt. Ltd for giving the permission
to do the project on “Setting up of Risk Management Process and
Information Security Metrics for IT Services” in their company.

Last but not least, I would like to thank my parents & friends who gave the
moral support to carry out the project successfully.

Signature
3

TABLE OF CONTENTS

1. RISK MANAGEMENT – AN INTRODUCTION ............................................................ 6
2. PROCEDURE ........................................................................................................ 31
3. RECORD RETENTION ............................................................................................ 46
4. AUDIT CHECK POINTS .......................................................................................... 47
5. RECOMMENDATION OF INFO SEC METRICS FOR A TYPICAL IT ORGANIZATION ... 48
6. APPENDIX A ........................................................................................................ 81
7. APPENDIX B ......................................................................................................... 85
8. APPENDIX C: ........................................................................................................ 92
9. APPENDIX D: ....................................................................................................... 93
10. APPENDIX E: ........................................................................................................ 95
11. APPENDIX F: ........................................................................................................ 96
12. BIBLIOGRAPHY .................................................................................................... 98
SIGNATURES: ............................................................................................................ 100

4
List of Figures

S.No Figure No. Figure Caption
1. Figure 1 Risk Management Process
2. Figure 2 Systematic & Continuous Risk Management
Process
3. Figure 3 Example of Risk Breakdown Structure (RBS)
4. Figure 4 Risk Management Methodology
5
1. Risk Management – An Introduction

1.1 Risk Management Overview

“Risk” is an uncertain event or condition that, if it occurs, has positive or negative effect
on at least one project objective. Objectives can include scope, schedule, cost, and
quality. A risk may have one or more causes and, if it occurs, it may have one or more
impacts.

“Risk Management” is, in general terms, a process aimed at achieving an optimal
balance between realizing opportunities for gain and minimizing vulnerabilities and loss.
This is usually accomplished by ensuring that the impact of threats exploiting
vulnerabilities is within acceptable limits at an acceptable cost.

In other words, “Risk Management” includes the processes of conducting risk
management planning, identification, analysis, response planning, and monitoring and
control on a project. The objectives of Risk Management are to increase the probability
and impact of positive events, and decrease the probability and impact of negative
events.

In practical business terms, risk management means that risks are managed so that they
do not materially impact the business process in an adverse way, and that an acceptable
level of assurance and predictability to the desired outcomes of any important
organizational activity are provided for. Risk is inherent in all activities; there is a risk in
doing something and a risk in not doing it. But for most organizations, the relevance and
critically of information today gives rise to the necessary for effectively managing it to
ensure preservation of the organization.

6
The foundation for effective risk management is a comprehensive risk assessment
combined with a Business Impact Analysis (BIA). It is not possible to devise a relevant
risk management program without no understanding of the nature and extent of risks to
information resources and the potential impacts on the organization’s activities.
However, in the majority of the organizations, information security governance is just
beginning to develop, and risk management is a necessity that must be addressed of the
state of governance. At a high level, risk management is accomplished by balancing risk
exposure against mitigation costs and implementing appropriate countermeasures and
controls.

Controls are designed as part of the information risk management framework. The
information risk management framework is made of policies, procedures, practices and
organizational structures and is, in essence, an architecture. This framework is designed
to provide reasonable assurance that business objectives are achieved and that
undesired events are prevented or detected and addressed. The framework must
address people, process and technology and encompasses the physical, technical,
contractual and procedural aspects of the organization. It must take into consideration
the strategic, tactical, administrative and operational components of the organization to
be effective.

Countermeasures include any process that serves to reduce specific threats or
vulnerabilities and can be considered a targeted control. Countermeasures can range
from modifying architecture or reengineering processes, to reducing or eliminating
inherent technical vulnerabilities, to creating an awareness program for all employees
to target social engineering and promote early recognition and reporting of security
incidents.

Risk management forms the basis for virtually all decisions about the security activities
and projects that are undertaken. In some organizations, the information risk
7
management program is integrated into an existing risk management framework. In
others, risk is managed in a number of different departments and operational units,
necessitating efforts to ensure continuity and integration of risk management activities.

Since risk management decisions typically have major financial implications, and can
require changes across the entire organization, it is imperative that executive
management is supportive of the process and fully understands and agrees with the
results of the program.

Risk management means – different things to different people in the organization.
For Example: The business manager might assume threats seldom occur and is not
convinced of the return on investment (ROI) for security measures. The auditor’s view
may be that it means the prevention of loss, whereas an insurance manager might
define it as cost effective risk financing.

The significance of business experience and business decision making in any risk
assessment process should be recognized as important to achieving realistic and
successful outcomes from the process. Risk management must operate at multiple
levels, including the strategic, management and operational levels. The likelihood and
relevance of a particular threat of risk will usually be a matter of judgment and
experience will be beneficial in arriving at realistic results.

Risk assessment can be quantitative or qualitative or, as is usually the case, a
combination of both or semi quantitative. Whether an assessment is quantitative or
qualitative is based on a variety of factors including the types of risk and impact and
whether they are reduced to a meaningful number. The main difference in approach is
whether risk is determined by computational methods such as annual loss expectancy
(ALE) or value at risk (VAR) to attempt to arrive at specific values or whether judgment
and experience is used to place risk in some category such as low, medium, high. It must
8
be understood that all risk assessment will, to a considerable extent, be qualitative,
relying on subjective estimates, relevance and outcomes.

Whichever approach or combination of approaches is used estimates should allow for
the range of likely error in the process itself. In other words, since risk assessment relies
on predictions of future events and their frequency and magnitude, it is prudent to
consider the range of probable outcomes to ensure that the worst case scenario will not
result in a catastrophic outcome. With this caveat, the most likely outcomes should be
the primary consideration so as to avoid an overreaction to highly improbable events.
For example, when considering environmental risk, being struck by a comet while
possible is highly improbable and it is unlikely that it will merit any significant mitigation
efforts at least for a terrestrial facility. In addition, it would be difficult to mitigate the
risk and so it is usually just accepted.

It may be useful to consider that the success of any risk management process is to some
extent dependent on the feasibility of the process itself. One of the important factor, is
the cost and complexity of the execution of the process, As with other aspects of
security, it is important to find the optimal cost‐benefit balance between accuracy,
complexity and cost.

Depending on the type of organization and the maturity with respect to risk
management, a simple risk management process may have a greater chance of success
than a complex one. A simple process has the advantage of demonstrating the benefits
at a low cost.
9
1.2 Importance of Risk Management

Risk management is fundamental function and provides the rationale and justification of
any IT Organization. Functionally, it enables business activities by mitigating or
managing risks to reasonable predictable levels, acceptable and appropriate to the
mission of the business or organization. Without determining the risks, it is not possible
to determine the potential cost or impact of a particular activity or event.

The effectiveness of risk management will depend on the degree to which it is a part of
an organization’s culture and becomes everyone’s responsibility.

The design and implementation of risk management process in the organization will be
influenced by:
The organization’s culture;
The organization’s mission and objectives;
The organizational structure;
Its products and services;
Its management and operation processes;
Specific practices employed;
The local physical, environmental and regulatory conditions.

1.3 Outcomes of Risk Management

Effective risk management serves to reduce the incidence of significant adverse impacts
on an organization’s operations either by addressing threats, mitigating exposure or by
reducing vulnerability or impact. To the extent this is accomplished risk management
provides a level of predictability that supports the organization’s ability to operate
effectively and profitably.
10

One of the outcomes is effective risk management, that is executing appropriate
measures to mitigate risks and reduce potential impacts on information resources to an
acceptable level and providing an:
Understanding of the organization’s threat, vulnerability and risk profile.
Understanding of risk exposure and potential consequences of compromise.
Awareness of risk management priorities based on potential consequences.
Organizational risk mitigation strategy sufficient to achieve acceptable
consequences from residual risk.
Organizational acceptance/deference based on a understanding of the potential
consequences of residual risk.

RISK MANAGEMENT STRATEGY

A risk management strategy, to be effective, must be an integrated business process
with defined objectives that incorporates all of the organization’s risk management
processes, activities, methodologies and policies. The risk management strategy sets the
parameters and charts the course for the organization’s risk management program. It
must be consistent with and integrated into the overall security governance strategy.
The security strategy in turn devolves from the organization’s overall objectives and
business strategy.

Risk management strategies are determined by a number of internal and external
factors. Internal factors will include organizational maturity, history, culture, structure
and senior management’s risk tolerance. Various external factors such as industry sector
and legal and regulatory requirements will collectively have a significant effect on the
development of an effective strategy as well.

All risk management strategies include determining the optimal approach to align
processes, technology and behaviour to accept or reject risks based on management’s
11

tolerance for risk and the company ability to manage it. Collectively, the risk
management strategies should result in a rejection on unmanageable risks, mitigation
against the realization and impact of accepted risks, and predictable control of any risks
that are realized across the entire organization.

RISK COMUNICATION, RISK AWARENESS AND CONSULTING

For risk management to become part of the organization culture, it will be necessary to
communicate and create awareness of the issues across the organization at each step of
the risk management process.

Communication should involve all stakeholders with efforts focused on consultation and
development of a common understanding of the objectives and requirements of the
program. This will allow variations in needs and perceptions to be identified and
addressed more effectively.

EFFECTIVE INFORMATION SECURITY RISK MANAGEMENT
Effective information security risk management activities must be supported on an
ongoing basis by all members of the organization. Executive or C‐suite support lends
credibility and impetus to risk management efforts. Even the best designed and
implemented controls will not function as intended if operations are conducted by
careless, indifferent or untrained personnel. An organizational culture that includes
sound information security practices couple with senior management commitment to
effective risk management is required to achieve the objectives of the project/program.

In addition, personnel must understand their responsibilities and be trained in
applicable control procedures. Compliance to information security controls must be
tested and enforced on a continuing basis. Efforts must be made to integrate all risk
management functions to ensure the continuity and comprehensiveness of risk
12

management activities across the enterprise and provide an adequate level of assurance
to business processes.

DEVELOPING A RISK MANAGEMENT PROGRAM

Initial steps in developing a risk management program will include establishing:
Context and purpose of the program
Scope and Charter
The implementation team

Establish Context and Purpose:
A primary requirement is to determine the organization’s purpose for creating a risk
management program, determine the desired outcomes and define objectives. It might
be a limited effort to reduce the impacts of Internet‐based attacks and accidents or to
ensure compliance with legal or regulatory requirements. If normal risk management is
not established the program may be far border and encompass all aspects of
organizational activity with responsibilities distributed amongst several departments.

Setting the risk management context primarily involves defining the organization,
process, project or activity, scope, and establishing its goals and objectives.

To establish an effective program, an essential element will be to determine the
organization’s risk tolerance or appetite‐that is, what is considered by management to
be an acceptable level of risk. Each organization has a different tolerance for the
amount and type of risk it considers acceptable and this is likely to carry by department
of organizational unit as well. This is inevitably a business decision based on a number of
criteria, including mission and culture rather than any specific quantitative measures.
Typically, executive management, with the board of directors, sets the tone for the risk
management program. This “tone at the top” is an important component of
13

management’s responsibility for corporate governance. As with all other aspects of
security, a top‐down approach will be substantially more effective than a bottom‐up
approach, where lower‐level managers attempt to influence the organization.
Employees generally look to senior management to determine which issues deserve the
highest priority.

Define Scope and Charter
Since all departments and operational units in the organization have some level of
responsibility for management risk, it is important to clearly define the scope of
responsibility and authority that specifically falls to the information security manager
and to other stakeholders. This helps prevent gaps in the process, improves overall
consistency of risk management efforts and reduces unnecessary duplication of efforts.

It should be noted that since virtually all information security activities are in some
manner related to managing risk, this exercise should map closely to the security
manager’s job responsibilities. Regardless of the scope of responsibility of the security
manager, the total scope for organizational risk management needs to be defined and
the overall objectives determined.

Designate Program Development Team
The next step is to designate an individual or team responsible for developing and
implementing the organization’s risk management program. While the team is primarily
responsible for the risk management plan, a successful program requires the integration
of risk management within all levels of the organization. Operations staff and board
members(through an oversight or steering committee) should assist the risk
management committee in identifying risks, determining acceptable risk levels and
developing suitable loss‐control and intervention strategies. Of overriding importance is
the need for the risk management program to be properly aligned with the strategy and
direction of the business. For this reason, it is vital that participation include
14

representatives from all the key business units. It may also be appropriate for other
areas of risk to be considered in particular, as they influence or impact information
protection. The most important consideration is that the process is business‐driven and
not technology‐driven.

ROLES AND RESPONIBILITIES

Information security risk management is an integral part of security governance and it is
the responsibility of the board of directors or the equivalent to ensure that these efforts
are effective. Periodic reports on the efforts and effectiveness of risk management
activities should be required to provide the feedback needed to ensure that
management intent, direction and expectations are realized.

Executive management must ensure the availability of adequate resources and support
for risk management activities and should receive status reports on a periodic and
event‐driven basis. Event‐driven reporting will require management involvement to
determine the nature and severity that triggers a report. Management must also be
involved in and sign off an acceptable risk levels as well as risk management objectives.

A steering committee composed of major stakeholders, must set risk management
priorities and define risk management objectives in terms of supporting business
strategy. The committee should also be charged with developing levels of acceptable
risk mitigation for various business processes to be presented to senior management for
agreement. Defining levels of acceptable risk and obtaining senior management support
is an essential condition for effective risk management.

The information security manager is responsible for developing, collaborating and
managing the information security risk management program to meet the defined
objectives. The information security manager must also take responsibility for
15

maintaining liaisons with the risk management teams and assurance activities in the
organization to promote the integration of activities and to provide an effective and
coordinated level of business process assurance.

Key Roles
Risk management is a management responsibility. The US National Institute of Science
and Technology (NIST) Publication 800‐30 describes the key roles of the personnel who
must support and participate in the risk management process. While the specifics in
different organizations will vary, this high‐level view should generally map to most
organizations.

Governing Boards and Senior Management:
Senior Management, under the standard of due care and ultimate responsibility for
mission accomplishment, must ensure that the necessary resources are effectively
applied to develop the capabilities needed to accomplish the mission. They must also
assess and incorporate result of the risk assessment activity into the decision‐making
process. An effective risk management program that assesses and mitigates IT‐related
mission risks requires the support and involvement of senior management.

Chief Information Officer: The chief information officer (CIO) is responsible for
IT planning, budgeting, and performance, including its information security
components. Decisions made in these areas should be based on an effective risk
management program.
Information Security Manager. Information security managers are responsible
for their organizations' security programs, usually including information risk
management. Therefore, they play a leading role in introducing an appropriate,
structured methodology to help identify, evaluate, and minimize risks to the IT
systems that support their organizations' missions. Information security
16

managers also act as major consultants in support of senior management to
ensure that this activity takes place on an ongoing basis.
System and Information Owners. The system and information owners are
responsible for ensuring that proper controls are in place to address integrity,
confidentiality and availability of the IT systems and data they own. Typically,
the system and information owners are responsible for changes to their IT
systems. Thus, they usually have to approve and sign off on changes to their IT
systems (e.g., system enhancement and major changes to the software and
hardware). The system and information owners must therefore understand their
role in the risk management process and fully support this process.
Business and Functional Managers. The managers responsible for business
operations and the IT procurement process must take an active role in the risk
management process. These managers are the individuals with the authority
and responsibility for making the trade‐off decisions essential to mission
accomplishment. Their involvement in the risk management process enables the
achievement of proper security for the IT systems, which, if managed properly,
will provide mission effectiveness with a minimal expenditure of resources.
IT Security Practitioners. IT security practitioners (e.g., network, system,
application and database administrators; computer specialists; security analysts;
security consultants) are responsible for proper implementation of security
requirements in their IT systems. As changes occur in the existing IT system
environment (e.g., expansion in network connectivity, changes to the existing
infrastructure and organizational policies, introduction of new technologies), the
IT security practitioners must support or use the risk management process to
identify and assess new potential risks and implement new security controls as
needed to safeguard their IT systems.
Security Awareness Trainers (Security/Subject Matter Professionals). The
organization's personnel are the users of the IT systems. Use of the IT systems
and data according to an organization's policies, guidelines and rules of behavior
17

is critical to mitigating risk and protecting the organization's IT resources. To
minimize risk to the IT systems, it is essential that system and application users
be provided with security awareness training. Therefore, the IT security trainers
or security/subject matter professionals must understand the risk management
process so that they can develop appropriate training materials and incorporate
risk assessment into training programs to educate the end users.

1.4 IMPLEMENTING RISK MANAGEMENT
As a part of planning a risk management program, the information security manager
must identify all other organizational risk management activities and seek to integrate
these functions or leverage the activities within the context of the information security
program. Larger organizations usually have a risk management function that deals with
activities typically related to physical risks. In the case of financial institutions, there is
also typically a department dealing with credit risk. Other departments or roles, such as
human resources and privacy officers, and compliance functions such as audit typically
are involved in managing risks within the organization. To be effective, it is critical that
mechanisms be put in place to ensure good communication with other risk
management and assurance functions. This is to ensure that otherwise effective
information security risk management is not bypassed or subverted by the lack of
effective processes in other domains. It also prevents duplication of efforts and
minimizes gaps in assurance functions that can adversely affect information protection
activities as well as other areas of operational and business risk.
1.4.1 RISK MANAGEMENT PROCESS
Risk management is the processes, distinct from risk assessment, of weighing policy
alternatives in consultation with interested parties, considering risk assessment and
other factors and selecting appropriate prevention and control options at acceptable
costs.
18

Risk management usually consists of the following processes:
Establish scope and boundaries
Risk assessment
Risk treatment
Acceptance of residual risk
Risk communication and monitoring
These processes are defined as follows:
Establish scope and boundaries: Process for the establishment of global
parameters for the performance of risk management within an organization. Both
internal and external factors have to be taken into account.
Risk Assessment: A methodic process consisting of three steps: risk identification,
risk analysis and risk evaluation.
Risk Treatment: Process of selecting strategies to deal with identified risk,
according to business' risk appetite. Risk treatment strategies for negative risks or
threats are: avoiding, by cessation of risky activities, reducing, by developing and
implementing controls, transferring risk to a third party, which could be inside or
outside the organization, and retaining risk. Risk will usually be retained if there is
no cost‐effective way to mitigate it, if there is little exposure or potential impact, or
if it is simply not feasible to address it effectively. Risk treatment strategies for
positive risks or opportunities are exploiting, enhance, transfer and share.
Acceptance of residual risk: Risk acceptance can be defined as the decision and
approval by management to accept the resulting risk, after the treatment process is
concluded.
Risk communication and monitoring: A process to exchange and share information
related to risk, as well as reviewing the effectiveness of the whole risk management
process. Communication of risk is usually performed between decision makers and
other stakeholders inside and outside the organization. Through communication
19

and monitoring it is assured that the scope, boundaries, evaluated risks and action
plans remain relevant and updated.

The risk management process is shown below:
Figure 1: Risk Management Process
Developing a systematic, analytical and continuous risk management process as shown
in the following Figure 2 is critical to any successful security program and must be
implemented as a formal process. Determining the correct or appropriate level of
security is dependent on the potential risks that an organization faces and its ability to
20

deal with it. These risks can be unique to each organization and overgeneralization
should be avoided as a result of applying risk factors across industries or regions.
Furthermore, an adequate information security program is made more challenging by
organizational, technological and business/operational change. Risk management
should be a continuous and dynamic process to ensure that changing threats and
vulnerabilities are addressed in a timely manner.

Figure 2: Systematic & Continuous Risk Management Process

In addition, processes must be developed to monitor the status of security controls and
countermeasures to determine their ongoing effectiveness. Controls usually degrade
over time and are subject to failure, mandating ongoing control monitoring and periodic
testing.
21

Risk Management Plan:
The risk management plan describes how risk management will be structured and
performed. The risk management plan includes the following:
1. Methodology: Defines the approaches, tools, and data sources that may be used
to perform risk management on the project.
2. Roles and responsibilities: Defines the lead, support, and risk management team
members for each type of activity in the risk management plan, and clarifies
their responsibilities.
3. Budgeting: Assigns resources, estimates funds needed for risk management for
inclusion in the cost performance baseline, and establishes protocols for
application of contingency reserve.
4. Timing: Defines when and how often the risk management process will be
performed.
5. Risk categories: Provides a structure that ensures a comprehensive process of
systematically identifying risks to a consistent level of detail and contributes to
the effectiveness and quality of the Identify Risks process. An organization can
use a previously prepared categorization framework which might take the form
of a simple list of categories or might be structured into a Risk Breakdown
Structure (RBS). The RBS is a hierarchically organized depiction of the identified
project risks arranged by risk category and subcategory that identifies the
various areas and causes of potential risks. An example is shown in below
figure.
22


Figure 3: Example of Risk Breakdown Structure (RBS)

6. Definitions of risk probability and impact: The quality and credibility of the Risk
assessment process requires that different levels of the risks’ probabilities and
impacts be defined.
7. Probability and impact matrix: Risks are prioritized according to their potential
implications for having an effect on the project’s objectives. A typical approach
to prioritizing risks is to use a look‐up table or a Probability and Impact Matrix.
The specific combinations of probability and impact that lead to a risk being
rated as “high,” “moderate,” or “low” importance, with the corresponding
importance for planning responses to the risk, are usually set by the
organization.
8. Revised stakeholders’ tolerances: Stakeholders’ tolerances, as they apply to the
specific project, may be revised in the process.
23

9. Reporting formats: Defines how the outcomes of the risk management
processes will be documented, analyzed, and communicated. It describes the
content and format of the risk register as well as any other risk reports
required.
10. Tracking: Documents how risk activities will be recorded for the benefit of the
current project, as well as for future needs and lessons learned, as well as
whether and how risk management processes will be audited.

Organizations generally use the following process in determining the necessary risk
management activities:
Identifying organization’s risk profile
Understanding and documenting the nature and extent of risk exposures
Identifying risk management priorities commonly achieved through:
Identifying the likelihood of threats (Negative Risks)
Identifying the likelihood of opportunities (Positive Risks)
Identifying the quantitative (monetary) and qualitative (effect) value of
the critical information/asset the security program is in place to protect
Determining the impact to the business if vulnerability is successfully
exploited or if opportunity is successfully exploited / enhanced.
The information security manager should set up a regular process whereby risk
assessments are performed at the organizational, system and application levels.
Ensuring that there are measurements (metrics) in place to assess the risk and the
effectiveness of security measures is part of the information security manager's ongoing
responsibility. The information security manager should also explore and recommend to
asset owners continuous manual and automated techniques to monitor the
organization's risks. This risk assessment process is important since it is necessary to
focus the organization's security activities on issues that have the greatest impact and
significance.
24

DEFINING A RISK MANAGEMENT FRAMEWORK

To develop an organization's systematic risk management program, framework
reference model should be used and adapted to the circumstances of the organization.

Risk management requirements include:
Policy—The need for an organization's senior management/executive leadership
to define and document its policy for risk management, including objectives for,
and its commitment to risk management. The policy must be relevant to the
organization's strategic context, goals, objectives and the nature of its business.
Management should ensure that this policy is understood implemented and
maintained at all levels in the organization.
Planning and resourcing—The organization should ensure that the program is
established and maintained; performance should be reported to management

and used as a basis for improvement. Responsibility, authority and
interrelationships of personnel who perform and verify work affecting risk
management should be defined and documented. The organization should
identify resource requirements and facilitate the implementation of risk
management programs, through the assignment of trained personnel for
ongoing management of work activities and the verification activities for internal
review.
Implementation program—The organization should define the steps required to
implement an effective risk management system.
Management review—Executive management should ensure a review of the risk
management system at specific intervals, sufficient to ensure its continuing
stability and effectiveness in satisfying requirements of the program. Records of
such reviews should be maintained.
Risk management process—Risk management can be applied at many levels in
the organization—both strategic and operational. It may also be applied to
25

specific areas, products/services, business/IT processes, projects, decisions,

applications and platforms. The organization should prioritize the confidentiality,
integrity and availability dimensions according to the organizations profile and
regulatory framework.
Risk management documentation—For each stage of the process, adequate
records should be kept that are sufficient to satisfy an independent audit.
By establishing the framework for the management of risks, the basic parameters within
which risks must be managed are defined. Consequently, the scope for the rest of the
risk management process is also set. It includes the definition of basic assumptions for
the organization's external and internal environment, and the overall objectives of the
risk management process and activities. Although the definition of scope and
framework are fundamental for the establishment of risk management, they are
independent from the particular structure of the management process, methods and
tools to be used for the implementation.
In order to define an efficient framework it is important to:
Understand the background of the organization and its risks (e.g., its core
processes, valuable assets, competitive areas etc.);
Evaluate the risk management activities being undertaken so far;
Develop a structure for the risk management initiatives and controls
(countermeasures, security controls, etc.) to follow.
This approach is useful for:
Clarifying and gaining common understanding of the organizational objectives;
Identifying the environment in which these objectives are set;
Specifying the main scope and objectives for risk management, applicable
restrictions or specific conditions and the outcomes required;
Developing a set of criteria against which the risks will be measured;
Defining a set of key elements for structuring the risk identification and
assessment process.
26

An organization should integrate risk management within its overall management
system and adapt various elements, such as policies, organizational processes,
accountability, resources and communication methods, to their specific needs.
Many organizations' existing management practices and processes include elements of
risk management and many organizations have already adopted a formal risk
management process for particular types of risk or circumstances. These should be
critically reviewed and assessed.

DEFINING THE EXTERNAL ENVIRONMENT
Defining the external environment includes specifying the environment in which the
organization operates, and the definition of the relationship between this environment
and the organization itself. The external environment typically includes:
The local market, the business, competitive, financial and political environment;
The law and regulatory environment;
Social and cultural conditions;
External stakeholders.
It is also very important that both the perceptions and values of the various
stakeholders and any externally generated threats and/or opportunities are properly
evaluated and taken into consideration.

27

DEFINING THE INTERNAL ENVIRONMENT
As in every significant business process, the most critical prerequisite is to understand
the organization itself. Key areas that must be evaluated in order to provide a
comprehensive view of the organization's internal environment include:
Key business drivers (e.g., market indicators, competitive advances, product
attractiveness, etc.);
The organization's strengths, weaknesses, opportunities and threats (SWOT);
Internal stakeholders;
Organization structure and culture;
Assets in terms of resources (i.e., people, systems, processes, capital, etc.);
Goals and objectives, and the strategies already in place to achieve them.

GENERATING THE RISK MANAGEMENT CONTEXT
In business terms, risk management as a process should provide a balance between (all
kinds of) costs, benefits and opportunities. Therefore, it is necessary to draw the
appropriate framework, and to correctly set the scope and boundaries of the risk
management process.
Setting the risk management context involves defining the:
Organization, process, project or activity (to be assessed), and establishing its goals
and objectives;
Duration of the project, activity or function;
Full scope of the risk management activities to be carried out, specifying any
inclusions and exclusions;
Roles and responsibilities of various parts of the organization participating in the
risk management process;
Dependencies between the project or activity, and other projects or parts of the
organization;
28

The criteria by which risks will be evaluated have to be decided and agreed upon.
Deciding whether risk treatment is required is usually based on operational, technical,
financial, regulatory, legal, social, or environmental criteria or combinations of them.
The criteria should be in line with the scope and qualitative analysis of the organization's
internal policies and procedures, and must support its goals and objectives.
Important criteria to be considered are:
Impact criteria and the kinds of consequences that will be considered;
Criteria of likelihood;
The rules that will determine whether the risk level is such that further treatment
activities are required.
It is very common that criteria identified during these steps are further developed or
even modified during later phases of the risk management process.
RISK ASSESSMENT AND ANALYSIS METHODOLGIES
There is no right or wrong approach to selection of a methodology for conducting a risk
assessment. However the results must meet the goals and objectives of the organization
in identifying the relative risk rating of assets critical to business.
Risk assessment is the process of analyzing threats to and vulnerabilities that pose a risk
to the organization’s information assets. It also includes the process of analyzing
opportunities which will give positive impacts to the organization. Coupled with either
BIA or information asset classification to determine criticality the resulting analysis is
used as a basis for identifying appropriate and cost‐effective controls or
countermeasures to mitigate the identified risk.
The differences between "analysis", "assessment" and "management" activities in

relation to information systems are:
Risk analysis is an examination of information to identify the risk to an information
system.
29

Risk assessment is the formal description and the evaluation of risk to an
information system.
Risk management is the process of identifying and applying countermeasures
commensurate with the value of the assets protected based on a risk assessment.

Aim
Establish a methodology to identify and assess risks to which organization’s
information assets are exposed.
Establish a methodology to manage and address the identified risks.

1.5 Objective

Objective of Risk management is to ensure the following:
a) Understanding the importance of risk management as a tool for meeting
business needs
b) Identify, Analyze and quantify and manage information security related risks
c) Set up appropriate metrics and monitoring mechanism in place
d) Recommend appropriate procedures , Guidelines and templates towards risk
management

1.6 Scope
The procedure covers:
• Physical:
1. Priya Technologies Pvt. Ltd.
• Logical:
2. All Information Assets owned and managed by Priya Technologies Pvt. Ltd.
30

2. Procedure
Information Risk Management Methodology
- CEP ASSET IDENTIFICATION - Asset Register.

- PROJECT INFO - Asset Value
- CIA VALUES
RISK
THREAT & OPPORTUNITY - List of Applicable IDENTIFICATION
- VULNERABILITY (V)/
ASSESSMENT Threats, Vulnerability &
- THREAT DB (T) /
Opportunities.
- OPPORTUNITY(O) - T‐V PAIRING
IDENTIFICATION OF List of Existing
- SECURITY PRACTICE
EXISTING CONTROLS Controls
- SECURITY DOC
- INTERVIEWS
- Threat & BUSINESS IMPACT Business Impact

Opportunities ANALYSIS Value
RISK
ANALYSIS
- Threat ESTIMATION OF LIKELIHOOD Likelihood of
- Vulnerabilities OF OCCURENCE Occurrence Rating
-Opportunities
- Asset Value RISK Risk Factor

- Business Impact DETERMINATION
Value.
-Risk Factor EVALUATE THE RISK AGAINST Risk Assessment

RISK
-Acceptable Level ACCEPTABLE RISK Report
EVALUATE
of Risk
-Risk Assessment EVALUATE THE OPTIONS -Treatment

RISK
Report FOR TREATMENT OF RISKS Options
TREATMENT
-New Controls
Figure 4: Risk Management Methodology
31

The Risk Management Methodology involves the following key steps
1. Risk Identification
2. Risk Analysis
3. Risk Evaluation
4. Risk Treatment
5. Risk Communication & Monitoring
The details of each step are explained in the following sections below.

2.1 Risk Identification

2.1.1 Asset Identification and Valuation
1. Departments shall clearly identify applicable Information assets of their
respective departments. (Refer to Appendix A for Asset Register Template &
Information Assets).
2. The Ownership, Custodian and Business purpose of the Asset shall be agreed
upon and documented.( Refer to Appendix A for definitions)
3. The Owner shall identify the classification of the identified asset as per
Information Classification Policy.
4. Each department shall update the Asset Register (Refer to Appendix A for
Asset Register Template).
5. The INFO SEC FUNCTION shall compile Asset Registers received from
different departments and review them for sufficiency.
6. The INFO SEC FUNCTION shall categorize the assets in classes if
required.(Refer to Appendix A for Asset Classes Template)

32

2.1.2 Threat, Vulnerability & Opportunity Identification
1. The INFO SEC FUNCTION shall identify a list of applicable threats and
associated vulnerabilities which could cause loss to the Information Assets.
(Refer to Appendix B for Threat & Vulnerability Database)
2. The Threats and vulnerability pair is identified for every asset / class of
assets mentioned in the Information Asset Register and documented. (Refer
to Appendix C for Risk Assessment Template).
3. Possible opportunities are identified for every asset.

2.1.3 Identification of Existing Controls
1. The INFO SEC FUNCTION shall identify the existing controls that have been
implemented in PRIYA TECHNOLOGIES PVT. LTD. The controls either reduce
the
- The likelihood or probability of a threat exploiting an identified system
vulnerability, and/or
- The magnitude of business impact of the exploited vulnerability on the
asset.
- Or Increase the probability of Opportunity to get more benefit out of it.
The implemented controls can be technical (such as firewall, antivirus software
etc.), management (such as Business Conduct Guidelines (BCG), IBM security
standards)) and operational (such as contracts, Statement of Work (SOW))
depending on the identified system.
2. The identified controls will be documented in Risk Assessment Sheet (Refer
to Appendix D for Risk Assessment Template)

33

2.1.4 Tools & Techniques
The following Tools & Techniques will be used to identify risks.
1. Documentation Reviews: A structured review may be performed of project

documentation, including plans, assumptions, previous project files, contracts,
and other information. The quality of the plans, as well as consistency between
those plans and the project requirements and assumptions, can be indicators of
risk in the project.
2. Information gathering Techniques:
Examples of information gathering techniques used in identifying risk can
include:
Brainstorming: The goal of brainstorming is to obtain a comprehensive list of
risks. The team usually performs brainstorming, often with a multidisciplinary set
of experts who are not part of the team. Ideas about project risk are generated
under the leadership of a facilitator; either in a traditional free‐form brainstorm
session with ideas contributed by participants, or structured using mass
interviewing techniques such as the nominal group technique. Categories of risk,
such as a risk breakdown structure, can be used as a framework. Risks are then
identified and categorized by type of risk and their definitions are sharpened.
Delphi technique: The Delphi technique is a way to reach a consensus of experts.
Project risk experts participate in this technique anonymously. A facilitator uses
a questionnaire to solicit ideas about the important project risks. The responses
are summarized and are then recirculated to the experts for further comment.
Consensus may be reached in a few rounds of this process. The Delphi technique
helps reduce bias in the data and keeps any one person from having undue
influence on the outcome.
Interviewing: Interviewing experienced project participants, stakeholders, and
subject matter experts can identify risks.
34

Root cause analysis: Root cause analysis is a specific technique to identify a
problem, discover the underlying causes that lead to it, and develop preventive
action.
3. Checklist Analysis: Risk identification checklists can be developed based on
historical information and knowledge that has been accumulated from previous
similar projects and from other sources of information. The lowest level of the
RBS can also be used as a risk checklist. While a checklist can be quick and
simple, it is impossible to build an exhaustive one. The team should make sure to
explore items that do not appear on the checklist. The checklist should be
reviewed during project closure to incorporate new lessons learned and improve
it for use on future projects.
4. Assumptions Analysis: Every project and every identified project risk is
conceived and developed based on a set of hypotheses, scenarios, or
assumptions. Assumptions analysis explores the validity of assumptions as they
apply to the project. It identifies risks to the project from inaccuracy, instability,
inconsistency, or incompleteness of assumptions.
5. Diagramming Techniques: Risk diagramming techniques may include:
Cause and effect diagrams: These are also known as Ishikawa or fishbone
diagrams, and are useful for identifying causes of risks.
System or process flow charts: These show how various elements of a system
interrelate, and the mechanism of causation.
Influence diagrams: These are graphical representations of situations showing
causal influences, time ordering of events, and other relationships among
variables and outcomes.
6. SWOT Analysis: This technique examines the project from each of the SWOT
(strengths, weaknesses, opportunities, and threats) perspectives to increase the
breadth of identified risks by including internally generated risks. The technique
starts with identification of strengths and weaknesses of the organization,
focusing on either the project organization or the wider business. These factors
35

are often identified using brainstorming. SWOT analysis then identifies any
opportunities for the project that arise from organizational strengths, and any
threats arising from organizational weaknesses. SWOT analysis also examines the
degree to which organizational strengths offset threats and opportunities that
may serve to overcome weaknesses.
7. Expert Judgment: Risks can be identified directly by experts with relevant
experience of similar projects or business areas. Such experts should be
identified by the project manager and invited to consider all aspects of the
project and suggest possible risks based on their previous experience and areas
of expertise. The experts’ bias should be taken into account in this process.
2.2 Risk Analysis
2.2.1 Business Impact Analysis
1. The Owner will identify the business impact to the organization due to
impact on the Asset.
2. Express the Business impact in terms of the loss of system functionality,
degradation of system response time, dollar losses, loss of public confidence,
or unauthorized disclosure of data.
3. Arrive at a Business Impact value based on the Business Impact because of
loss of confidentiality, integrity or availability of the asset.
4. The Business Impact value is determined by expected loss to organization’s

business if the threat becomes a reality.
5. The Business Impact is expressed in terms of High, Medium or Low. (Refer to
Appendix E for guidelines on calculating Business Impact)
6. The highest value out of values of Confidentiality, Integrity and Availability is
taken as the Business Impact rating ( Refer to Appendix F)
36

2.2.2 Estimation of Likelihood of Occurrence
1. The INFO SEC FUNCTION shall estimate the Probability of a threat exploiting
the vulnerability on the basis of following factors:
• Motivation,
• Skills required,
• Historical & Statistical Data,
• Current Environment
• Existing controls.
2. Likelihood of Occurrence shall be expressed under following categories:
• High ‐3
• Medium ‐2
• Low ‐1
3. Refer to Appendix F for template.
4. Tools & Techniques:
1. Risk Probability and Impact Assessment: Risk probability assessment

investigates the likelihood that each specific risk will occur. Risk impact
assessment investigates the potential effect on a project objective such as
schedule, cost, quality, or performance, including both negative effects for threats
and positive effects for opportunities.
Probability and impact are assessed for each identified risk. Risks can be assessed
in interviews or meetings with participants selected for their familiarity with the
risk categories on the agenda. Project team members and, perhaps,
knowledgeable persons from outside the project, are included.
The level of probability for each risk and its impact on each objective is evaluated
during the interview or meeting. Explanatory detail, including assumptions
37

justifying the levels assigned, is also recorded. Risk probabilities and impacts are

rated according to the definitions given in the risk management plan. Risks with
low ratings of probability and impact will be included on a watchlist for future
monitoring.
2. Probability and Impact Matrix: Risks can be prioritized for further
quantitative analysis and response based on their risk rating. Usually, these risk‐
rating rules are specified by the organization in advance of the project and
included in organizational process assets. Evaluation of each risk’s importance
and, hence, priority for attention, is typically conducted using a look‐up table or a
probability and impact matrix. Such a matrix specifies combinations of probability
and impact that lead to rating the risks as low, moderate, or high priority.
3. Risk Data Quality Assessment: A qualitative risk analysis requires accurate
and unbiased data if it is to be credible. Analysis of the quality of risk data is a
technique to evaluate the degree to which the data about risks are useful for risk
management. It involves examining the degree to which the risk is understood and
the accuracy, quality, reliability, and integrity of the data regarding the risk. If data
quality is unacceptable, it may be necessary to gather higher‐quality data.
4. Risk Categorization: Risks to the project can be categorized by sources of
risk (e.g., using the RBS), the area of the project affected (e.g., using the WBS), or
other useful category (e.g., project phase) to determine areas of the project most
exposed to the effects of uncertainty. Grouping risks by common root causes can
lead to developing effective risk responses.
5. Risk Urgency Assessment: Risks requiring near‐term responses may be
considered more urgent to address. Indicators of priority can include time to
affect a risk response, symptoms and warning signs, and the risk rating. In some
qualitative analyses the assessment of risk urgency can be combined with the risk
ranking determined from the probability and impact matrix to give a final risk
severity rating.
38

6. Expert judgment: Expert judgment is required to assess the probability and
impact of each risk to determine its location in the matrix. Experts generally are
those having experience with similar projects that occurred in the not‐too‐distant
past. In addition, those who are planning and managing the specific project are
experts, particularly about the specifics of that project. Securing expert judgment
is often accomplished with the use of risk facilitation workshops or interviews. The
experts’ bias should be taken into account in this process.
2.3 Risk Evaluation & Calculation
It is the process of numerically analyzing the effect of identified risks on overall
objectives. Risk Calculation is performed on risks that have been prioritized
previous process as potentially and substantially impacting the objectives. This
process analyzes the effect of those risk events. It may be used to assign a
numerical rating to those risks individually or to evaluate the aggregate effect of
all risks affecting the project. It also presents a quantitative approach to making
decisions in the presence of uncertainty.
In some cases, this process may not be required to develop effective risk
responses. Availability of time and budget, and the need for qualitative or
quantitative statements about risk and impacts, will determine which method(s)
to use on any particular area. This Risk Calculation should be repeated after Risk
Treatment, as well as part of Communication & Monitor Risks, to determine if the
risk has been satisfactorily decreased. Trends can indicate the need for more or
less risk management action.
39

2.3.1 Tools & Techniques:
1. Data gathering and representation Techniques
a) Interviewing
9 This involves interviewing the relevant stakeholders to collect data to quantify
the probability and impact of risks on project objectives
9 data is collected on the optimistic (low), pessimistic (high) and most likely
scenarios for some commonly used distributions
b) Probability Distribution
9 Continuous Distributions are commonly used in modeling and simulation.
9 They represent the uncertainty in values such as duration of schedule
activities and costs.

2. Quantitative Risk Analysis and modeling techniques
a) Sensitivity Analysis
It helps to examine the impact of one risk event on the project objectives, when all
the other risks are held stable. A tornado diagram graphically displays which risk
has the most impact when all the other risks are held constant.
b) Expected Monetary Value Analysis
A decision tree is a common technique that applies the EMV method. EMV
calculates the average value of an outcome when the future includes scenarios
that may or may not happen.
c) Modeling and Simulation
Using simulation, a project model is computed several times, with the input values
chosen at random for each iteration from the probability distribution of these
variables.

3. Expert Judgment: It is useful in identifying appropriate inputs for the tools
and interpreting the outcome of the tools. The risk thus calculated is a Net Risk
and is derived at after identifying existing controls. The risk is calculated for every
asset class and threat pair. (Refer to Appendix F).
40

2.4 Risk Acceptance and Treatment Criteria

Each asset will be treated to an acceptable risk level based on the risk value calculated.
The matrix below gives the Risk Acceptance criteria for the respective assets. The risk
acceptance criterion is approved by INFORMATION SYSTEMS SECURITY COMMITTEE.
The residual risk level is determined assuming full implementation of the recommended
controls/safeguards.

Risk is categorized in accordance to Risk factor mentioned in the below table.

Risk Categorization Risk Acceptance Criteria
Negligible / Low May need no action
Medium Immediate action required
High Immediate action required
Table 1: Risk category in accordance to Risk factor

41

2.5 Risk Evaluation & Mitigation
2.5.1 Evaluate the risk against acceptable risk
1. The INFO SEC FUNCTION shall compare the Risk Factor with the risk
acceptance criteria.
2. The INFO SEC FUNCTION shall determine whether the risks to the assets are
in the acceptable level or require treatment. The treatment can be decided
from any of the following options.
3. INFORMATION SYSTEMS SECURITY COMMITTEE shall decide on the

treatment option.
4. Tools & Techniques includes (i) Strategies for negative risks or Threats, (ii)
Strategies for positive risks or Opportunities.
5. Treatment for the positive risks or opportunities are,
Options Treatment
This strategy may be selected for risks with positive impacts where
Exploit the Risk
the organization wishes to ensure that the opportunity is realized.
Sharing a positive risk involves allocating some or all of the
Share the Risk ownership of the opportunity to a third party who is best able to
capture the opportunity for the benefit of the project.
This strategy is used to increase the probability and/or the positive
impacts of an opportunity. Identifying and maximizing key drivers
Enhance the Risk
of these positive‐impact risks may increase the probability of their
occurrence.
Accepting an opportunity is being willing to take advantage of it if
Accept the Risk
it comes along, but not actively pursuing it.
42

6. Treatment for the Negative risks or Threats are,

Options Treatment
Risk avoidance involves changing the plan to eliminate the threat
Avoid the Risk
entirely.
This strategy is adopted because it is seldom possible to eliminate
all threats. This strategy indicates that the team has decided not to
change the plan to deal with a risk, or is unable to identify any
Accept the Risk other suitable response strategy. This strategy can be either passive
or active. Passive acceptance requires no action except to
document the strategy, leaving the team to deal with the risks as
they occur.
Risk mitigation implies a reduction in the probability and/or impact
of an adverse risk event to be within acceptable threshold limits.
Mitigate the Risk Taking early action to reduce the probability and/or impact of a risk
occurring is often more effective than trying to repair the damage
after the risk has occurred.
Risk transfer requires shifting some or all of the negative impact of
a threat, along with ownership of the response, to a third party.
Transferring the risk simply gives another party responsibility for its
Transfer the Risk management—it does not eliminate it. Transferring liability for risk
is most effective in dealing with financial risk exposure. Risk
transference nearly always involves payment of a risk premium to
the party taking on the risk.
Based on INFORMATION SYSTEMS SECURITY COMMITTEE decision, INFO SEC

FUNCTION shall evaluate the Controls based on the cost benefit analysis and
present the control options to INFORMATION SYSTEMS SECURITY COMMITTEE for
review and approval.
43

2.6 Risk Communication & Monitoring

2.6.1 Communicate, monitor and control the risk
1. The risk factors should be communicated to the necessary personnel
within the organization, with appropriate mode and within the specified
time.
2. Risks should be monitored and controlled throughout the processes.
3. Tools & Techniques:
a) Risk Reassessment: Monitor and Control Risks often results in identification of
new risks, reassessment of current risks, and the closing of risks that are
outdated. Risk reassessments should be regularly scheduled. The amount and
detail of repetition that is appropriate depends on how it progresses relative to
its objectives.
b) Risk Audits: Risk audits examine and document the effectiveness of risk
responses in dealing with identified risks and their root causes, as well as the
effectiveness of the risk management process. Risk audits may be included
during routine project review meetings, or separate risk audit meetings may be
held. The format for the audit and its objectives should be clearly defined before
the audit is conducted.
c) Variance and Trend Analysis: Many control processes employ variance analysis
to compare the planned results to the actual results. For the purposes of
monitoring and controlling risk events, trends in the execution should be
reviewed using performance information. Earned value analysis and other
methods of variance and trend analysis may be used for monitoring overall
performance. Outcomes from these analyses may forecast potential deviation
from targets. Deviation from the baseline plan may indicate the potential impact
of threats or opportunities.
44

d) Technical Performance Measurement: Technical performance measurement

compares technical accomplishments during execution to the project
management plan’s schedule of technical achievement. It requires definition of
objective quantifiable measures of technical performance which can be used to
compare actual results against targets. Such technical performance measures
might include weight, transaction times, number of delivered defects, storage
capacity, etc. Deviation, such as demonstrating more or less functionality than
planned at a milestone, can help to forecast the degree of success in achieving
the project’s scope, and it may expose the degree of technical risk.
e) Reserve Analysis: Throughout the execution, some risks may occur, with positive
or negative impacts on budget or schedule contingency reserves. Reserve
analysis compares the amount of the contingency reserves remaining to the
amount of risk remaining at any time in the project in order to determine if the
remaining reserve is adequate.
f) Status Meetings: Risk management should be an agenda item at periodic status
meetings. The amount of time required for that item will vary, depending upon
the risks that have been identified, their priority, and difficulty of response. Risk
management becomes easier the more often it is practiced. Frequent discussions
about risk makes it more likely that people will identify risks and opportunities.
45

3. Record Retention
• Minutes of the Meetings for INFORMATION SYSTEMS SECURITY COMMITTEE
& INFO SEC FUNCTION
• Risk Assessment Sheet
• Asset registers
• Risk Treatment Plan
• Risk Register
46

4. Audit Check Points
The internal auditor during the audit should check for following:
• Periodic meetings of INFORMATION SYSTEMS SECURITY COMMITTEE & INFO
SEC FUNCTION
• Risk Assessment as per the procedure
• Sufficiency of Assets identified in asset register
• Risk treatment plan as per decisions taken by INFORMATION SYSTEMS
SECURITY COMMITTEE

47

5. Recommendation of Info Sec Metrics for
a typical IT organization
Based on our study we had conducted with various representatives of IT organization
we have proposed the metrics for a typical IT organization.
On the inputs provided by the stakeholders and the study conducted from a risk
perspective and taking into consideration the major vulnerability areas towards the goal
of “Protection of Information assets” we would like to propose the metrics. However
the set of metrics is only a guide line and does not attempt to provide a silver bullet
solution or unique solution for a given organization.

For any organization to adopt these metrics one needs to study the following
1) Type of business/service provided
2) Scale of the business/service provided
3) Vulnerabilities the organization is exposed to
4) Type of potential threats the organization would face
5) Amount of controls prevailing – could be preventive, detective, corrective or
compensatory controls
6) Likelihood of the potential threat exposing the vulnerability and thereby the risk
coming into reality
Approach
1) Brainstorming with various stakeholders from different IT industry who attend
the CISA sessions.
2) Selection of Vital few metrics for each group based on the following
considerations.
a) Cost of data collection
b) Control – in case the metrics shows a variance
c) Impact – The impact or the value that this particular metrics provides
48

d) Alignment – Alignment to Info sec objective and end alignment with
business objective
e) Ease of data collection

Introduction
Information Security Metrics will provide the management with parameters to evaluate
implementation status of Information Security in the organization. This metric will enable a
continuous improvement model by providing a numerical way of scoring the status of a
particular information security parameter on a continuous scale. The metrics defined fall
under the following categories:

Classes Criteria
Management Management metrics shall help the management in monitoring overall
Information Security Status in the organization. These metrics shall be used by
the management to make long term decisions with respect to information
assets.
Governance Governance Metrics shall be used in order to verify and track compliance with
various external requirements for security of information assets of the
organization.
Technical Technical Metrics shall help the organization in verifying security of technical
infrastructure and addressing vulnerabilities arising out of technology
infrastructure.

Responsibility
Information Security metrics shall be captured by Info Sec Function on periodic basis.
Analysis of the metrics shall be carried out based on the agreed upon threshold levels
(Defined by ISSC). Analysis of the metrics shall be presented to INFOMRATION SECURITY
STEERING COMMITTE in their quarterly meetings and corrective actions, if any, shall be
decided.
49

Metrics is a term used to denote a measure based on a reference and involves at least
two points—the measure and the reference. Security, in its most basic meaning, is the
protection from or absence of danger. Literally, security metrics should tell us about the
state or degree of safety relative to a reference point. Contemporary security metrics,
by and large, fail to do so.
It may be useful to clarify the distinction between managing the technical IT security
machinery at the operational level and the overall management of an information
security program. Technical metrics are obviously useful for the purely tactical
operational management of the technical security infrastructure—i.e., a server,
databases, firewalls, etc. They can indicate that the infrastructure is operated in a sound
fashion and that technical vulnerabilities are identified and addressed. However, these
metrics are of little value from a strategic management or governance standpoint. That
is, they say nothing about strategic alignment with organizational objectives or how well
risks are being managed; they provide few measures of policy compliance or whether
objectives for acceptable levels of potential impact are being reached; and they provide
no information on whether the information security program is headed in the right
direction and achieving the desired outcomes.
From a management perspective, while there have been improvements in technical
metrics, they are incapable of providing answers to questions such as:
How secure is the organization?
How much security is enough?
How do we know when we have achieved it?
What are the most cost‐effective solutions?
How do we determine the degree of risk?
How well can risk be predicted?
Are we moving in the right direction?
What impact is lack of security having on productivity?
What impact would a catastrophic security breach have?
What impact will security solutions have on productivity?
50

Attempts to provide meaningful answers to these questions can ultimately be addressed
only by developing relevant measures—metrics that specifically address the
requirements of management to make appropriate decisions about the organization's
safety.
Full audits and comprehensive risk assessments are typically the only activities
organizations undertake that provide this breadth of perspective. While important and
necessary from a security management point of view, these provide only history or a
snapshot—not what is ideally needed to guide day‐to‐day security management and
provide the information needed to make prudent decisions.
It is generally difficult or impossible to manage any activity that cannot be measured.
The fundamental purpose of metrics, measures, and monitoring is decision support. For
metrics to be useful, the information they provide must be relevant to the roles and
responsibilities of the recipient so that informed decisions can be made.
Standard security metrics will include things such as downtime due to viruses or Trojans,
number of penetrations of systems, impacts and losses, recovery times, number of
vulnerabilities uncovered with network scans, and percentage of servers patched. While
these measures can be indicative of aspects of security, none provides any actual
information about how secure the organization is.
Operational risk and its counterpart, security is not readily measured in any absolute
sense; rather, probabilities, attributes, effects and consequences are normally the
gauge. Various approaches that may be useful include value at risk (VAR), return on
security investment (ROSI), and annual loss expectancy (ALE). VAR is used to compute
maximum probable loss in a defined period (day, week, year) with a confidence level of
typically 95% or 99%. ROSI is used to calculate the return on investment based on the
reduction in losses resulting from a security control. ALE provides the likely annualized
loss based on probable frequency and magnitude of security compromise. These often
51

speculative numbers can then be used as a basis for allocating or justifying resources for
security activities.
Some organizations will attempt to determine the maximum impacts of potential
adverse events as a measure of security. Measuring security by consequences and
impacts is similar to gauging how tall a tree is by how loud a noise it makes when it falls.
In other words, adverse events would have to occur to determine if security is working.
An absence of adverse events provides no information on the state of security. It may
mean that defenses worked, that no one attacked or that a vulnerability was not
discovered. Of course, simulated attacks with penetration testing can provide some
measure of the effectiveness of defenses against those specific attacks performed.
However, unless a statistically relevant percentage of all possible attacks are attempted,
no prediction can be made about the state of security and the organization's ability to
resist attack.
It may be that all that can be stated with certainty about security is that:
1. Some organizations are attacked more frequently and/or suffer greater losses
than others
2. There is a strong correlation between good security management and practices,
and relatively fewer incidents and losses
Good management is, arguably, one result of good governance. Measuring effective
information security governance and management with any precision may be more
difficult than measuring security. Metrics will, in most respects, be based on attributes,
costs and subsequent outcomes of the security program
A sensible notion suggests that a well‐governed security program can be characterized
by one that efficiently, effectively and consistently meets expectations and attains
defined objectives. This is, however, of little help to most organizations since it is
unclear what the expectations or objectives of security are in any specific sense.
52

Commercial efforts to measure good governance by organizations such as Institutional
Shareholder Services (ISS) and Governance Metrics International (GMI) have not stood
up well to scrutiny according to a recent Yale report titled Good Governance and the
Misleading Myths of Bad Metrics (Sonnenfeld, Jeffrey; Associate Dean for Executive
Programs at Yale, Academy of Management Executive, 2004, Vol. 18, No. 1). The report
details studies showing that many, but not all, apparently sound governance notions are
not supported by fact. The converse is also true, however; many governance notions
are, indeed, supported by fact.
Because governance, in general, and security governance, in particular, is difficult to
measure by a set of objective metrics, there is a tendency to use metrics that are
available, regardless of demonstrated relevancy. A typical example apparent in most
organizations is the use of vulnerability scans as an indication of overall security.
Arguably, if it were possible to eliminate all or most vulnerabilities (which is not
possible), most risks could be avoided. The fallacy is the assumption that something can
be determined about risk, threat or impact by measuring just technical vulnerabilities.
While there is no universal objective scale for security or security governance, for
organizations that have taken the necessary steps to develop clear objectives for
information security, effective metrics can be designed to guide program development
and management. Essentially, metrics can be reduced to any measure of the results of
the information security program progressing toward the defined objectives. It must
also be understood that different metrics are required to provide information at the
strategic, tactical, and operational levels. Strategic metrics will be oriented toward high‐
level outcomes and objectives for the information security program.
In Good Governance and the Misleading Myths of Bad Metrics, the author states that:
The foundation of strong upper‐level management support is critical, not only for the
success of the security program, but also for the implementation of a security metrics
program. This support establishes a focus on security within the highest levels of the
53

organization. Without a solid foundation (i.e., proactive support of those persons in
positions that control IT resources), the effectiveness of the security metrics program
can fail when pressured by politics and budget limitations.
The second component of an effective security metrics program is practical security
policies and procedures backed by the authority necessary to enforce compliance.
Practical security policies and procedures are defined as those that are attainable and
provide meaningful security through appropriate controls. Metrics for compliance are
not easily obtainable if there are no procedures in place.
The third component is developing and establishing quantifiable performance metrics
that are designed to capture and provide meaningful operational data. To provide
meaningful data, quantifiable security metrics must be based on IT security
performance goals and objectives, and be easily obtainable and feasible to measure.
They must also be repeatable, provide relevant performance trends over time, and be
useful for tracking performance and directing resources.
Finally, the security metrics program itself must emphasize consistent periodic analysis
of the metrics data. The results of this analysis are used to apply lessons learned,
improve the effectiveness of existing security controls, and plan future controls to meet
new security requirements as they occur. Accurate data collection must be a priority
with stakeholders and users if the collected data are to be meaningful to the
management and improvement of the overall security program.
The success of an information security program implementation should be judged by
the degree to which meaningful results are produced. A comprehensive security metrics
analysis program should provide substantive justification for decisions that directly
affect the security posture of an organization. These decisions include budget and
personnel requests, and allocation of available resources. A security metrics program
should provide a precise basis for preparation of required security performance‐related
reports.
54

5.1.1 GOVERNANCE IMPLEMENTATION METRICS
Implementing an information security governance strategy and framework can require a
significant effort. It is important that some form of metrics be in place during the
implementation of a governance program. Performance of the overall security program
will be too far downstream to provide timely information on implementation and
another approach must be used. Key goal indicators (KGIs) and key performance
indicators (KPIs) can be useful to provide information about the achievement of process
or service goals, and can determine whether organizational milestones and objectives
are being met.
5.1.2 STRATEGIC ALIGNMENT
Strategic alignment of information security in support of organizational objectives is a
highly desirable goal, often difficult to achieve. It should be clear that the cost
effectiveness of the security program is inevitably tied to how well it supports the
objectives of the organization and at what cost. Without organizational objectives as a
reference point, any other gauge, including so‐called best practices, may be overkill,
inadequate or misdirected. From a business perspective, adequate and sufficient
practices proportionate to the requirements are likely to be more cost effective than
best practices. They are also likely to be received better by cost‐conscious management.
The best overall indicator that security activities are in alignment with business (or
organizational) objectives is the development of a security strategy that defines security
objectives in business terms and ensures that the objectives are directly articulated
from planning to implementation of policies, standards, procedures, processes and
technology. The acid test is the reverse order evaluation of a specific control being able
to be tracked to a specific business requirement. Any control that cannot be tracked
directly back to a specific business requirement is suspect and should be analyzed for
relevancy and possible elimination.

55

Indicators of alignment can include:
A security program that demonstrably enables specific business activities
A security organization that is responsive to defined business requirements
Organizational and security objectives that are defined and clearly understood
by all involved in security and related assurance activities
Security programs that are mapped to the organizational objectives and
executive management has validated this mapping
A security steering committee consisting of key executives with a charter to
ensure ongoing alignment of security activities and business strategy
5.1.3 RISK MANAGEMENT
Risk management is the ultimate objective of all information security activities and
indeed all organizational assurance efforts. While risk management effectiveness is not
subject to direct measurement, there are indicators that correlate to a successful
approach. A successful risk management program can be defined as one that efficiently,
effectively and consistently meets expectations and attains defined objectives.
Once again, it is a requirement that expectations and objectives of risk management be
defined; otherwise, there is no basis for determining whether the program is succeeding
and/or heading in the right direction, and whether resource allocations are appropriate.
Indicators of appropriate risk management can include:
A defined organizational risk appetite or a risk tolerance in terms relevant to the
organization
An overall security strategy and program for achieving acceptable levels of risk
Defined mitigation objectives for identified significant risks
Processes for management or reduction of adverse impacts
Systematic, continuous risk management processes
Trends of periodic risk assessment indicating progress toward defined goals
Trends in impacts
A tested business continuity/disaster recovery plan
56

The completeness of the asset valuation and assignment of ownership
Business Impact Assessments (BIAs) of all critical or sensitive systems
The key goal of information security is to reduce adverse impacts on the organization to
an acceptable level. Therefore, a key metric is the adverse impacts of information
security incidents experienced by the organization. An effective security program will
show a trend in impact reduction. Quantitative measures can include trend analysis of
impacts over time.
5.1.4 VALUE DELIVERY
Value delivery occurs when security investments are optimized in support of
organizational objectives. Value delivery is a function of strategic alignment of security
strategy and business objectives; in other words, when a business case can be
convincingly made for all security activities. Optimal investment levels occur when
strategic goals for security are achieved and an acceptable risk posture is attained at the
lowest possible cost.
Key indicators (KGIs and KPIs) can include:
Security activities that are designed to achieve specific strategic objectives
The cost of security being proportional to the value of assets
Security resources that are allocated by degree of assessed risk and potential
impact
Protection costs that are aggregated as a function of revenues or asset
valuation
Controls that are well designed based on defined control objectives and are
fully utilized
An adequate and appropriate number of controls to achieve acceptable risk
and impact levels
Control effectiveness that is determined by periodic testing
Policies in place that require all controls to be periodically reevaluated for cost,
compliance and effectiveness
57

The utilization of controls; controls that are rarely used are not likely to be cost
effective
The number of controls to achieve acceptable risk and impact levels; fewer
effective controls can be expected to be more cost effective than a greater
number of less effective controls
The effectiveness of controls as determined by testing; marginal controls are
not likely to be cost effective.
5.1.5 RESOURCE MANAGEMENT
Information security resource management is the term used to describe the processes
to plan, allocate and control information security resources, including people, processes
and technologies, for improving the efficiency and effectiveness of business solutions.
As with other organizational assets and resources, they must be managed properly.
Knowledge must be captured disseminated and available when needed. Providing
multiple solutions to the same problem is, obviously, inefficient and indicates a lack of
resource management. Controls and processes must be standardized when possible, to
reduce administrative and training costs. Problems and solutions must be well
documented referenced and available.
Indicators of effective resource management can include:
Infrequent problem rediscovery
Effective knowledge capture and dissemination
Standardized processes
Clearly defined roles and responsibilities for information security functions
Information security functions incorporated into every project plan
Information assets and related threats covered by security resources
The proper organizational location, level of authority and number of personnel
for the information security function.
58

5.1.6 PERFORMANCE MEASUREMENT
Measuring, monitoring and reporting on information security processes is required to
ensure that organizational objectives are achieved. It is quite clear that "you cannot
manage what you cannot measure." Methods to monitor security‐related events across
the organization must be developed; it is critical to design metrics that provide an
indication of the performance of the security machinery and from a management
perspective, information needed to make decisions to guide the security activities of the
organization. When the ideal of a security dashboard has not yet been realized most
measures are indirect indicators of the state of security and performance of the security
program.
Indicators of effective performance measurement might include:
The time it takes to detect and report security‐related incidents
The number and frequency of subsequently discovered unreported incidents
Benchmarking comparable organizations for costs and effectiveness
The ability to determine the effectiveness/efficiency of controls
Clear indications that security objectives are being met
The absence of unexpected security events
Knowledge of impending threats
Effective means of determining organizational vulnerabilities
Methods of tracking evolving risks
Consistency of log review practices
Results of business continuity planning (BCP)/disaster recovery (DR) tests
59

5.1.7 ASSURANCE PROCESS INTEGRATION (CONVERGENCE)
An area of emerging conceptual interest related to a suggested outcome of information
security governance is called business process assurance or assurance integration.
For organizations that are considering an approach to information security governance
that includes an effort to integrate a variety of assurance functions and ensure that
processes operate as intended from end‐to‐end minimizing hidden risks, KGIs can
include:
No gaps in information asset protection
The elimination of unnecessary security overlaps
The seamless integration of assurance activities
Well‐defined roles and responsibilities
Assurance providers understanding the relationship to other assurance
functions
All assurance functions are identified and considered in the strategy
In regards to management of the risk inherent in a business, Booz Allen Hamilton (in its
publication titled Convergence of Enterprise Security Organizations) suggests that:
In the past, management of the risk inherent in a business was a function embedded
within the individual roles of the "C Suite". The traditional approach was to treat
individual risks separately and assign responsibility to an individual or small team.
Managing a singular kind of risk became a distinct job, and performing that job well
meant focusing exclusively on that one particular area. The problem with this stove
piped approach is that it not only ignores the interdependence of many business risks
but also sub optimizes the financing of total risk for an enterprise.
Breaking stovepipes and addressing the sub optimizing of investments requires a new
way of thinking about the problem. This new thinking brings together the various
stakeholders in the problem set to work closely together. A major objective of this study
60

is to understand how leading organizations bring together diverse elements and get
them to orient on a common objective.
Metrics Classification
Based on the business requirement it is very important to classify the metrics. The high
level categories are mentioned as follows
a) Management
b) Technical
c) Governance
We have further stratified this into various categories of metrics based on the sub
function. The sub functions are categorized based on the generic business requirements
as follows. Refer Table A for the proper classification:

Risk Assessment
Asset Classification & Handling
Third Party Access
Change Management
Emergency Change Management
Problem Management
Backup & Restoration
Physical Security
Technical Controls
Trainings
Reviews
Compliance & Audit
User Access Management
Anti Virus
Patch Management
Security Incidents

61

Table A

S.No. Metrics Classification
1 Risk Assessment Management
2 Asset Classification & Handling Management
3 Third Party Access Governance
4 Change Management Management
5 Emergency Change Management Management
6 Problem Management Management
7 Backup & Restoration Technical
8 Physical Security Management
9 Technical Controls Technical
10 Trainings Management
11 Reviews Management
12 Compliance & Audit Governance
13 User Access Management Management
14 Anti Virus Technical
15 Patch Management Technical
16 Security Incidents Management & Governance
62

Risk Assessment

No. of Percentage of
No. of
Percentage of "Confidential' & " "Confidential' & "
No. of "Confidential' &
"Confidential' & Non‐ Public" Non‐ Public"
Half "Confidential" " Non‐ Public"
" Non‐ Public" Assets with Assets with
Year & "Non‐Public" Assets covered
Assets assessed comprehensive comprehensive
Assets* under Risk
for Risks Risk Treatment Risk Treatment
Assessment
Plan1 Plan
I
II

* Input from Asset Register
1
Input from Risk Treatment Plan

Threshold Levels
Percentage of "Confidential' & " Non‐ Public"
Percentage of "Confidential' & " Non‐
Assets with comprehensive Risk Treatment
Public" Assets assessed for Risks
Plan
Compliant 95% 98%
Minor Non‐ Compliance 90‐95% 95‐98%
Major Non‐ Compliance < 90 < 95
63

Asset Classification & Handling

No. of Assets
No. of No. of
No. of Assets with
Half Assets in Assets with
with Identified % Established % %
Year Asset Classificatio
Owners1 Classification
Register n Labels2
level*
I
II

* Classification defined as per Asset Classification Policy
1
Refer to Information Classification Policy in ISMS
2
Refer to Labelling Scheme for Different kind of assets

Threshold Levels
% of Assets
without % of Assets without classification
% of Assets without Identified Owners
Established labels
Classification
Compliant 10% 5% 2%
Minor Non‐
10‐20% 5‐10% 2‐5%
Compliance
Major Non‐
More than 20% More than 10% More than 5%
Compliance
64

Third Party Access

No. of Third No. of formal No. of Third
No. of
Parties with Access Parties with
Third
Quarter Logical/ Physical % Approvals % Formal Risk %
Parties
Access to Org. available for Assessment
Engaged
Information Third Parties Conducted
I
II
III
IV

Threshold Levels
% of Third Parties with Access Rights to Org information % of Third Parties with Access Rights but
without formal Approvals without formal risk assessment
Compliant 0% 0%
Major Non‐ Compliance More than 2% More than 2%
65

Change Management

No. of
No. of Changes changes No. of change
Total No.
with approved implementation
Quarte of
implementatio % without % s approved %
r Changes*
n prior to proper prior to
made1
approvals rollback verification
procedures
I
II
III
IV

* Changes shall include infrastructural changes and changes to the systems. Changes made to the
applications as part of service delivery to the client are not covered in this metrics.
1
Input either from Change Register (Ticketing Software) or a ballpark figure from different departments

Threshold Levels
% of changes approved
% of changes with implementation % of change implementations
without proper rollback
prior to approvals approved without verifications
procedures
Compliant 0% 0% 0%
Minor Non‐ Compliance 0 ‐ 2% 0 ‐ 2% 0 – 2%
Major Non‐ Compliance > 2% > 2% > 2%

66

Emergency Change Management Metrics

No. of
Total No. of changes No. of change
No. of Changes with approved implementation
Quart
Change implementati % without % s approved %
er
s* on prior to proper prior to
made1 approvals rollback verification
procedures
I
II
III
IV

*Changes shall include infrastructural changes and changes to the systems. Changes made to the
applications as part of service delivery to the client are not covered in this metrics.
1
Input either from Change Register (Ticketing Software) or a ballpark figure from different departments

Threshold Levels
% of changes % of change
% of changes with
approved without implementations
implementation prior to
proper rollback approved without
approvals
procedures verifications
Compliant 0% 5% 5%
Minor
0 ‐ 2% 5 ‐ 10% 5 ‐ 10%
Non‐ Compliance
Major
> 2% > 10% > 10%
Non‐ Compliance

67

Problem Management

Problems not
Total No. of No. of Problems not
closed/ escalated
Quarter Problems* closed as per defined Percentage Percentage
in 48 hours after
faced1 closure date
the closure date3
I
II
III
IV

* Problems include faults faced in network infrastructure or end user computing
1
Input from Problem Register or ballpark figure from different departments
2
Deviation of +/‐ 5 % is tolerable from the ballpark figure
3
Input from Problem Register

Threshold Levels
% of open Problems % of open Problems not
escalated in 48 hours
Compliant 5% 0%
Minor Non‐ Compliance 5 ‐ 15% 0 ‐ 5%
Major Non‐ Compliance > 15% > 5%
68

Backup & Restoration Metrics

No. of tapes
No. of
Total No. of No. of Tapes with No. of
Backup
Tapes as per identification Tapes
Quarter % Tapes % % %
required for Backup label as per stored
physically 2
backup* Register 1 labelling offsite
available
scheme
I
II
III
IV
* Calculated from No. of tapes for backup/ day required for backup of identified servers/ data
1
Input from physical count of backup media
2
Input from Backup Register
No. of Failed
No. of Backup
No. of Tapes tested No. of Failed Restorations
Quarter Tapes to be Percentage Percentage
for Restoration Restorations Resolved/
restored
Escalated
I
II
III
IV 7 7 100 0 0 0

Threshold levels – Backups
Percentage of Backup tapes Percentage of Backup Percentage of Backup

physically available onsite tapes without tapes physically available
identification labels offsite
Compliant 100% 2% 100%
Minor Non‐ 98 ‐ 100% 2 ‐ 5% 98%
Compliance
Major Non‐ < 98 > 5% < 98

Compliance
69

Physical Security Metrics

No. of Daily
Percentage of % Increase
Checks
available No. of Percentage in
Required to No. of No. of
reviewed Failures in Increase in Environmen
Quart be reviewed Failures
checklists vis‐ Environme Utilities tal controls
er performed checklists in
à‐vis total ntal every failures
(UPS/ DGs available Utilities
checks Controls Quarter every
Health
performed quarter
Check etc.)
I
II
III
IV
Physical Access Cards Management
No. of Percentage
No. of Pre‐
Pre‐ of
Activated
Activat available*
Access No. of Pre‐ No. of Pre‐ Percentage
ed cards vis‐à‐ No. of
Cards Activated Activated of forms
Quart Cards vis total Temporary
received Access Cards available for
er availab cards Card forms
from PRIYA Cards available with temporary
le with received available
TECHNOLO issued team cards
the from PRIYA
GIES PVT.
Recepti TECHNOLOG
LTD
on IES PVT. LTD
I
II
III
IV
* Available Cards will be sum total of Cards issued, available with team and available
with reception

70


Threshold Levels
Percentage of
Percentage available* pre‐
Percentage Percentage of
Increase in activated cards vis‐à‐
Increase in forms available
Environmental vis total pre‐activated
Utilities faults for temporary
faults Every cards received from
every quarter cards
Quarter PRIYA TECHNOLOGIES
PVT. LTD
Compliant 0% 0% 100% 0%
Minor Non‐ 0 ‐ 5% 0 ‐ 5% 90 ‐ 100% 0 ‐ 10%
Compliance
Major Non‐ > 5% > 5% < 90% > 10%
Compliance

71

Technical Control Metrics

Number of Number of Number
Number of
Systems Systems of
Systems
No. of without without Systems
Quart with
Syste Account % Logging % without % %
er Pirated/
ms Lockout (Event/ monitor
Unauthorize
Configurati Security) ing of
d Software
ons enabled logs

Threshold Levels
Percentage of
Percentage of Systems/ Percentage of Systems/
Systems/ Servers with
Servers without Account Servers without logging
Pirated/ Unauthorized
Lockout Configuration enables
Software
Compliant 0% 0% 0%

Minor Non‐
0 ‐ 2% 0 ‐ 2% 0 – 2%
Compliance
Major Non‐
> 2% > 2% > 2%
Compliance

Trend Analysis
Percentage Increase in Non Compliances on

Quarterly Basis
72

Training

No. of New
No. of New Employees taken
Quarter Percentage
Employees joined through Info Sec
training

Half Years No. of Employees* No. of Employees Percentage

on Roll taken through
refresher training

* These Employees will not include the employees who have joined during last six months from the date
when this metrics is being captured.

Threshold Levels
Percentage of new Employees Percentage of employees taken
taken through Info Sec training through refresher training
Compliant 100% 98%
Minor Non‐ Compliance 98%‐100% 95‐98%
Major Non‐ Compliance <98% <95%
73

Review of Metrics
Reviews* Reviews % of
% of Changes/
required Conducted reviews Documentatio
Documente Review
(Quarter I/ II/ (Completed / In conducte n Available
d reviews Results
III/ IV) Progress) d

* Reviews that are required to be carried out by different forums are defined in the Organization ISMS
(Policies & Procedures)

Threshold Levels Reviews
Percentage of Reviews Percentage of documented
Conducted reviews
Compliant 100% 100%
Non‐ Compliance <100% <100%

Compliance & Audit
No. of
No. of Total No. of Departments/
audits1 need
Quarter Audits % Departments/ Processes %
to be
conducted Processes covered
conducted*
I
II
III
IV

* Input from IS&PO / Audit Calendar.
1
Information Security Audits as per Information Security Policy of the Organization.

74

No. of findings
No. of findings
No. of major2 findings closed/ corrected
Quarter % same as of %
during the audit as per agreed
previous audits
timelines
I
II
III
IV

2
Major Findings shall include the findings which may lead to high impact on the business.

List of Applicable Compliance Status ( Non Compliance/
Remarks
Laws Compliant with exceptions/ Compliant)

Threshold Levels
Percentage of Percentage of Percentage of findings

audits conducted open findings same as of previous
audits
Compliant 100% 0% 0%
Minor Non‐ Compliance N.A. 0‐5% 0‐5%
Major Non‐ Compliance <100% >5% >5%
75

User Access Management

No. of users on No. of Users
Quarter No. of New Users Percentage
Rolls Resigned
I
II
III
IV
Remarks
No. of UserIDs
No. of Unaccounted for
in Active Percentage
UserIDs Discrepanc
Directory
y
I
II
III
IV
No. of UserIDs
No. of Active User
not logged in
IDs not logged in for Percentage
for past 30
past 30 days
days
I
II
III
IV
No. of
No. of
Administrator
Administrators on Percentage
s as per Access
the servers
Control Matrix
I
II
III
IV
No. of desktops
Total No. of
unapproved admin Percentage
desktops
rights
I
II
III
IV

76


Threshold Levels
Percentage of Percentage
Percentage of Percentage of Active Administrators on of desktops
Unaccounted UserIDs not logged in servers vis‐à‐vis as with
UserIDs for past 30 days per Access Control unapproved
Matrix admin rights
Compliant 0% 0% 100% 0%
Minor Non‐ 0‐2% 0‐5% N.A. 0‐2%
Compliance
Major Non‐ >2% >5% <100% >2%
Compliance

77

Protection Against Malicious Code

No. of systems No. of systems
No. of (Desktops)without (Desktops) without
Quarter Percentage Percentage
Systems latest Anti‐Virus latest Anti Virus
Engines Definition files
I
II
III
IV

No. of servers No. of servers
No. of
Quarter without latest Percentage without latest Anti Percentage
Servers
Anti‐Virus Engines Virus Definition files
I
II
III
IV

Threshold Levels‐Desktops
Percentage of Systems without Percentage of Systems without
Anti‐Virus Engines updated version of Antivirus
Compliant 0% 0%
Minor Non‐ N.A. 0‐2%
Compliance
Major Non‐ >0% >2%
Compliance
78

Patch Management

Quarter Number of Systems Number of Systems with missing patches

I
II
III
IV

Threshold Levels
Percentage of Systems with Missing Patches
Compliant 0%
Minor Non‐ Compliance 0‐2%
Major Non‐ Compliance >2%
79

Security Incident

Incident Extent Approx
s of Time
Root Vulnerabili
Reporte Inciden Damag to Defined Actual
Cause ty Correctiv
d for t Time e (Low/ Contai Escalate Escalatio
Analysi (Existing/ e Action
Quarter & Date Mediu n d time n time
s Done New)
I/ II/ III/ m / Inciden
IV High) t

Threshold Levels
Percentage of Incidents
Percentage of Incidents with
not escalated within
Known Vulnerabilities
defined time
Compliant 5% 0%
Major Non‐ Compliance >10% >2%

Trend Analysis
No. of Incidents Percentage No. of Incidents No Incident not

Quarter with High Extent Increase in No. with Known escalated within
of Damage of Incidents Vulnerabilities defined time
I
II
III
IV

80

6. Appendix A
6.1 Information Asset

Information Assets, as defined by ISO 27001, is a definable piece of information, stored
in any manner which is recognized as 'valuable' to the organization. Information Assets
can be categorized under following types:

Assets Examples
Information Asset Databases, data files, system documentation, user manuals,
training material, operational and support procedures,
intellectual property, continuity plans, fallback arrangements
Paper based Information Contracts, guidelines, company documentation, business
results, HR records, purchase documents, invoices
Software Assets Applications, development tools, utilities, OS
Physical Computers, routers, hubs, firewalls, communication
equipment, magnetic media, other equipment
Services Fire Extinguishers, Cabinets, safes, rooms, furniture, AC plant,
DG Sets
People Employees

81


6.2 Asset Register Template

Asset
Asset Name Asset Group Asset Owner Location Value Backup Format Remarks
Code
Software Assets (Business application, system, knowledge management application, development tools, utilities)

Information Assets (Central database, data files, intellectual property, system documentation, user manuals, training material,
operational & support procedures, continuity plans)

Paper documents (Contracts, company documentation, business results, purchase document, invoices, license agreement)

Infrastructure Assets (Servers, network devices, desktops, laptops, voice equipments, backup tape, magnetic media etc…)

Services (Telecommunication, data processing, air conditioning, intruder alarms, fire control, generators, UPS)

People (Personnel, customers, contractors)

82


6.3 Owner & Custodian

The term ‘owner’ identifies an individual or entity that has approved management
responsibility for controlling the production, development, maintenance, use and
security of the assets. The term ’owner’ does not mean that the person actually has any
property rights to the asset.

The term ‘custodian’ identifies an individual or entity that has been provided custody of
the asset by the owner for business reasons.

83

6.4 Asset Class Template

Asset List
Category Asset Class Owner/ Custodian
Servers located at PRIYA TECHNOLOGIES PVT. LTD PRIYA TECHNOLOGIES
PVT. LTD
Servers located at PRIYA TECHNOLOGIES PVT. LTD TIT ‐ PRIYA
Desktops TECHNOLOGIES PVT.
Infrastructure
Laptops LTD
Networking Equipments
Electronic Office Equipments
Backup Media
Development Utilities & Tools ( Software required for TIT
carrying out tasks assigned by the client)
Hygiene Level Software (Base minimum software TIT
required for all Workstations)
Software Business Applications ( Software required for carrying out Essential Services
essential services)
Mailing Application TIT
Operating Systems & Databases on Servers at PRIYA TIT
TECHNOLOGIES PVT. LTD
CS Forms Corporate Services
Finance Records Finance
Information (in
LOGISTICS Data LOGISTICS
paper form)
Human resources Records LTM
TIT Data TIT
CS data Corporate Services
Finance records Finance
Information (in LOGISTICS data LOGISTICS
digital form) Human resources Records LTM
QA related files QA
Development, Production Support & Maintenance related Core Services
files
IP Telephony & EPABX TIT
Generator, UPS & AC Corporate Services
Service Assets
Building Management System Corporate Services
Bandwidth TIT
Key Personnel
People
Others
84

7. Appendix B
Threat & Vulnerability Database:
• A threat is an unwanted (deliberate or accidental) event that may result in harm to
an asset. Often, a threat exploits a known vulnerability.
• Vulnerability is a weakness in an information system, system security procedures,
internal controls, or implementation that could be exploited. The same vulnerability
can be exploited by different threats. E.g. Lack of Access Controls can lead to
Unauthorized Intrusion or Equipment Failure.

S.No. Threats Associated Vulnerabilities
Availability of flammable materials such as paper or
1. Fire
boxes

Absence of fire fighting equipments

Absence of Fire Detecting equipments

Back‐up files and systems not available

Inadequate BCP/DRP

Inadequate contacts with relevant authorities

Calamities (Floods, Earthquake, Building
2.
/Structure Collapse, lightening, etc) Location susceptible to calamities

Lack of contacts with/ of relevant authorities

Faulty Building Structure

Inadequate BCP/DRP

Social Unrest (Riots, Strikes, Terrorist Located in an area susceptible to activities like riots,
3.
Attacks, etc) terrorist attacks, etc.

Inadequate BCP/DRP

Inadequate contacts with/ of relevant authorities
85

4. Unauthorized Intrusion/ Theft (Logical)
Lack of Access Control Matrix

Lack of Firewall & IDS

Inadequately configured firewall & IDS

Inadequate OS hardening

Logs not maintained & reviewed
Lack of controls on access to systems and

applications
Lack of controls on access to software and system

configurations

Inadequate user management procedures

Lack of review of user access rights

Absence of session timeouts

Inadequate change control procedures

Inadequate protection of security tools

Lack of segregation of duties

Weak passwords

Lack of secure logon procedures

Uncontrolled Dial in Access

5. Unauthorized Intrusion/ Theft (Physical)
Absence of entry/exit controls

Inadequate monitoring of premises

Inadequate procedure for material movement

Inadequate protection for information in transit
Lack of controls on issue and retrieval for access

cards

Negligent/ Un‐informed users

Lack of management commitment to information
6. Industrial Espionage
security

Lack of inclusion of security in the core services

Unaware/ Negligent employees
86


Lack of security controls with respect to personnel
Employees have an access to sensitive client and

employee information

Equipment failure ‐ Data Processing
7.
Equipments Absence of periodic equipment maintenance
Lack of appropriate environmental controls for

equipment (In use & Spare) siting and maintenance
Unprotected Equipment Movement within and out

of the premises
Inadequate/ Poor procedures for Equipment/

system purchase, acceptance and installation

No/ Inadequate AMCs, Warranties & Insurance
Unskilled personnel handling the equipment

installation & maintenance.

Equipment Failure ‐ Network
8.
Equipment Lack of redundancy of network devices/links
Lack/ Inadequate procedures for network

management

Lack of updated documentation for networks
Faulty Cable Layouts ( Data & Power Cables in the

same duct)

Absence of periodic equipment maintenance
Lack of appropriate environmental controls for

equipment (In use & Spare) siting and maintenance
Unprotected Equipment Movement within and out

of the premises
Inadequate/ Poor procedures for Equipment/

system purchase, acceptance and installation

No/ Inadequate AMCs, Warranties & Insurance
Unskilled personnel handling the equipment

installation & maintenance.

Utilities failures (Services & Associated Inadequate utilities e.g. UPS, Generators, Phone
9.
Infrastructure) Lines etc.

Lack of monitoring and maintenance of utilities

Inadequate physical access controls to utilities

Unmonitored/ Unescorted maintenance personnel
87


Lack of SLAs/ AMCs with Utilities provider

Faulty delivery with respect to SLAs/ AMCs

10. System Failure
Inadequate information backup & restoration
System capacity and performance not reviewed

periodically

Patches not applied

Inadequate software/configuration/version control

procedures

Inadequate BCP/DRP
Lack of controls on access to systems and

configurations

Inadequate change control procedures

Lack of monitoring of network
Lack of controls on access to network & network

services

Lack of / Inadequate application purchase,
11. Application Failure
installation & maintenance procedures
Lack of / Inadequate application testing before
acceptance & installation (Input data validation/
buffer overflows etc.)

Lack of periodic reviews of application performance

Lack of controls on access to application servers

Lack of support from third party vendor

Lack of Logs & their review

12. Virus attacks/Malicious Software
Lack of security awareness of information users

Absence of Anti‐virus

Anti‐virus updates not applied

Patches not applied
Inadequate controls on installation of software

(shareware/ freeware)
88


Inadequate controls on downloads from internet
Covert channels/ malicious code embedded in the

software during development

Inadequate software testing

Attachments/ removable media not scanned for

viruses

USB/floppy drives enabled

Lack of monitoring of AV server & regular reports

Litigation liability (IPR violations,
13. Contractual Breaches, Software Piracy
etc.) Lack of security awareness amongst users
Inadequate information security related clauses in

the vendor contracts

Inadequate protection of organizational records

Absence of applicable legislation list

Inadequate legal warning messages on systems
Inadequate controls on installation of software

(shareware/ freeware)
Inadequate software license management

procedures
Lack of policy restricting staff to use of licensed

software

Lack of software auditing

Unrestricted copying of software

14. Resource Inadequacy
Lack of backups for resources
Lack of/ Inadequate planning of resource

requirements
Lack of knowledge transfer during exit of the

employee

15. Incidents
Inadequate Incident Handling Procedures

Unaware/ Negligent Employees

Lack of Incident Logs/ Fault Logs
89


16. Unauthorized Dial‐In Access
Lack of a Firewall

Lack of audit logs to detect unauthorized access

Lack of intrusion detection software
Lack of physical security over telecommunications

equipment cabinets
Lack of policies in respect of dial up access, modem

use, and software use

Lack of user authentication

Unrestricted use of modems

Eavesdropping (Sniffing, shoulder surfing
17.
etc.) Unaware/ Negligent employees

Data cables left in open

Unmonitored network ports

Confidential information left in open
Lack of physical security over data communications

closets or hubs

Unencrypted communications
Use of Shared Ethernet means that all traffic is
broLogisticsast
to any machine on a local segment

Workstations left unattended

18. Frauds
Lack of segregation of duties

Lack of periodic review procedures
Lack of violation matrix/ disciplinary actions

procedures

Disgruntled Employees

19. Masquerading/ Social Engineering
Unaware/ Negligent Employees
Lack of identification and authentication

mechanisms

Lack of identification of sender and receiver
90


Unprotected password tables

Lack of security related training to information users

Inadequate network management (resilience of
20. Denial of Service
routing)
Incorrectly configured / maintained security

controls

Lack of a Firewall

No Anti Virus software
Not keeping up to date with various online Security
organizations
such as CERT will lead to a known weakness not
being corrected
in a timely manner

Data Losses ‐ Unavailability/ Leakage/
21.
Corruption Lack of regular backups & restoration procedures
Lack of information classification & handling

procedures
Lack of security requirements during information

exchange with third parties
Lack of / Inadequate access control matrix &

procedures

91

8. Appendix C
Threat & Vulnerability Identification Template

Asset Type
Asset Class
Owner

Threat Vulnerability
Threat A Vulnerability AA
Vulnerability AB
Vulnerability AC
Threat B Vulnerability BA
Vulnerability BB
Threat C Vulnerability CA
Vulnerability CB
Vulnerability CC
Vulnerability CD

92

9. Appendix D
Infrastructure
Backup Media ( along
Asset Class
with information stored)
TIT – PRIYA
Owner TECHNOLOGIES PVT. LTD

Threat Vulnerability Identified Controls

Fire Availability of flammable materials such as paper Following are the
or boxes Recommendations:
Backup tapes should be
Absence of Fire Detecting equipments
stored at PRIYA
TECHNOLOGIES PVT.
Absence of fire fighting equipments LTD premises.
There should be smoke
Inadequate contacts with relevant authorities detectors and fire
extinguishers installed
Inadequate BCP/DRP all across the premises.
CS team should have
contacts with relevant
authorities.
There should be BCP/
DR plan for the backup
tapes
Calamities Location susceptible to calamities The building has been
(Floods, Lack of contacts with/ of relevant authorities constructed keeping the
Earthquake, zone in mind. Chennai is
Building Faulty Building Structure prone to floods.
/Structure Inadequate BCP/DRP However PRIYA
Collapse, TECHNOLOGIES PVT.
lightening, etc) LTD office is on 2nd
floor and water has
never reached that
level.
CS should maintain a list
of relevant authorities
to be contacted in case
of emergencies.
tapes
93


Social Unrest Located in an area susceptible to activities like
(Riots, Strikes, riots, terrorist attacks, etc.
Terrorist
Attacks, etc) Inadequate BCP/DRP
Corporate services
department should have
a contact list of all the
relevant authorities.
Inadequate contacts with/ of relevant authorities tapes
Unauthorized
Intrusion/ Theft
(Physical)
Absence of entry/exit controls
Inadequate monitoring of premises
Inadequate procedure for material movement Movement of tapes
within and outside
premises should be
Negligent/ Un‐informed users controlled.
Training has to be
Lack of controls on issue and retrieval for access provided with respect to
cards information security.

94

10. Appendix E
Business Impact Analysis
Business Impact definition Illustration / Example Impact Rating Value

The threat event which impact 1) Result in major loss (such as High 3
confidentiality, integrity or availability of Loss of reputation),
the asset and which in turn: 2) Legal / Regulatory lapses
(such as DPA, IT Act, GLBA
(1) may result in the highly costly loss of violation),
major tangible assets or resources; 3) Render system unfit for user
(2) may significantly violate, harm, or 4) Termination of client services
impede an organizations mission,
reputation, or interest;
(3) May lead to termination of service
delivery to the client
(4) May result in human death or serious
injury.
The threat event which impact 1) Result in partial malfunction Medium 2
confidentiality, integrity or availability of 2) Cause loss of performance
the asset and which in turn: 3) Cause customer complaint
(1) may result in the costly loss of tangible 4) Affect ethics and personal
assets or resources data
(2) may violate, harm, or impede an 5) Violation of service delivery
organization's mission, reputation, or terms and conditions
interest;
(3) may lead to business loss in terms of
service delivery
(4) May result in human injury.
The threat event which impact 1) Cause minor performance Low 1
confidentiality, integrity or availability of problem
the asset and which in turn: 2) Be unnoticed and cause
(1) may result in the loss of some tangible minor performance problem
assets or resources 3) Cause a little nuisance
(2) may noticeably affect an organizations
mission, reputation, or interest
95

11. Appendix F
Servers located at
PRIYA
TECHNOLOGIES
Asset Class PVT. LTD
*PR‐ Probability Rating, 1‐5; Lowest ‐
TIT ‐ PRIYA 1; Highest‐ 5
TECHNOLOGIES BI‐A‐Business Impact Analysis,
Owner PVT. LTD Rating‐.1‐3; Low‐1; High‐3

Overall
Risk
Threat Vulnerability Identified Controls PR BI‐A Rating
Fire Availability of
flammable materials Servers should be kept in the data
such as paper or boxes center where flammable materials
Absence of Fire viz. papers and boxes are very few in
Detecting equipments number.
Absence of fire
3 3 High
fighting equipments Fire Extinguishers should be provided
in the server room.
Inadequate contacts

with relevant
There should be backup for
authorities
information stored on the server
Inadequate BCP/DRP
Calamities Location susceptible The building has been constructed
(Floods, to calamities keeping the zone in mind.
Earthquake, Lack of contacts with/ Corporate services department
Building of relevant authorities should have a contact list of all the
2 2 Medium
/Structure Faulty Building relevant authorities.
Collapse, Structure
lightening, There should be backup for
etc) Inadequate BCP/DRP information stored on the server.
Social Unrest Located in an area PRIYA TECHNOLOGIES PVT. LTD is
(Riots, susceptible to situated in Chennai. There have been
Strikes, activities like riots, no major riots in past 5 years in this
Terrorist terrorist attacks, etc. region.
Attacks, etc) Inadequate BCP/DRP Corporate services department
Inadequate contacts should have a contact list of all the
with/ of relevant relevant authorities.
authorities 1 2 Low
There should be backup for
information stored on the server but
there are not backups for the
equipments (Except Mail Server) as
of now.

96

Unauthorized
Intrusion/ Absence of entry/exit Servers are kept inside the data
Theft controls center. Access to data center is
(Physical) provided only to authorized
Inadequate
personnel.
monitoring of
There are access control doors at
premises
entry of the premises.
Inadequate procedure Material movement takes place only 2 2 Medium
for material after approvals from TIT & CS. Gate
movement pass needs to be issued prior to
Negligent/ Un‐ material movement outside PRIYA
informed users TECHNOLOGIES PVT. LTD premises.
Users have not been provided with
any training with respect to
information security.

97

12. Bibliography
1. Anand, Sanjay; The Why and How of Leveraging Synergies Across Sarbanes‐Oxley
and Other Regulations, Information Systems Control Journal, vol. 3, 2007, p. 49.
2. Bellone, Jason; Dino Cataldo Dell'Accio; Juan Rodriguez; "A Cosmological

Approach to IT Governance: Val IT and COBIT Lessons Learned at the United
Nations," Information Systems Control Journal, vol. 1, 2007, p. 37.
3. Project Management Body Of Knowledge (PMBOK), Fourth Edition from Project
Management Institute (PMI), USA, 2009.
4. Rita Mulcahy; “PMP Exam Prep”, Sixth Edition, 2009.
5. Bhatia, Mohan; "IT Merger Due Diligence: A Blueprint," Information Systems

Control Journal, vol. 1, 2007, p. 46.
6. Brotby, Krag; Information Security Governance: Guidance for Boards of Directors
and Executive Management, 2nd Edition, IT Governance Institute, USA, 2006.
7. Business Roundtable, "Information Security Addendum to Principles of Corporate
Governance," April 2003, www.businessroundtable.org.
8. Chatterji, Sushil; "Bridging Business and IT Strategies With Enterprise

Architecture: Realising the Real Value of Business‐IT Alignment," Information
Systems Control Journal, vol. 3, 2007, p. 17.
9. Cano, Jeimy J.; "Inseguridad Informática y Computación Anti‐forense: Dos

Conceptos Emergentes en Seguridad de la Información," Information Systems
Control Journal, vol. 4, 2007, p. 54.
10. Cerullo, Michael J.; Virginia Cerullo; "Threat Assessment and Security Measures

Justification for Advanced IT Networks," Information Systems Control Journal,
vol. 1, 2005, p. 35.
98

11. Cobb, Andrew T.; Jian Guan; Alan S. Levitan; "Control Considerations in Object‐
oriented Systems," Information Systems Control Journal, vol. 3, 2007, p. 28.
12. Cohen, Gidi; "The Role of Attack Simulation in Automating Security Risk
Management," Information Systems Control Journal, vol. 1, 2005, p. 51.
13. Deshmukh, Meera; Raj, Shankar; "Environment Interaction Evaluation: Building

Proactive Compliance into Technology Solutions," Information Systems Control
Journal, vol. 4, 2007, p. 43.
99

Signatures
Author Reviewer Authorizer

100

Risk MGMT Final Jan2010

Uploaded by

Document Information

Original Description:

Original Title

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

Risk MGMT Final Jan2010

Uploaded by

Copyright:

Available Formats

established and maintained; performance should be reported to management

specific areas, products/services, business/IT processes, projects, decisions,

The differences between "analysis", "assessment" and "management" activities in

- CEP ASSET IDENTIFICATION - Asset Register.

- Threat & BUSINESS IMPACT Business Impact

- Asset Value RISK Risk Factor

-Risk Factor EVALUATE THE RISK AGAINST Risk Assessment

-Risk Assessment EVALUATE THE OPTIONS -Treatment

1. Documentation Reviews: A structured review may be performed of project

4. The Business Impact value is determined by expected loss to organization’s

1. Risk Probability and Impact Assessment: Risk probability assessment

justifying the levels assigned, is also recorded. Risk probabilities and impacts are

3. INFORMATION SYSTEMS SECURITY COMMITTEE shall decide on the

Based on INFORMATION SYSTEMS SECURITY COMMITTEE decision, INFO SEC

d) Technical Performance Measurement: Technical performance measurement

10 Trainings Management

11 Reviews Management

12 Compliance & Audit Governance

13 User Access Management Management

14 Anti Virus Technical

15 Patch Management Technical

16 Security Incidents Management & Governance

Minor Non‐ Compliance 90‐95% 95‐98%

Major Non‐ Compliance < 90 < 95

Compliant 0% 0%

Minor Non‐ Compliance 0‐2% 0‐2%

Major Non‐ Compliance More than 2% More than 2%

Minor Non‐ Compliance 0 ‐ 2% 0 ‐ 2% 0 – 2%

Major Non‐ Compliance > 2% > 2% > 2%

Minor Non‐ Compliance 5 ‐ 15% 0 ‐ 5%

Major Non‐ Compliance > 15% > 5%

Percentage of Backup tapes Percentage of Backup Percentage of Backup

Major Non‐ < 98 > 5% < 98

Compliant 0% 0% 0%

Half Years No. of Employees* No. of Employees Percentage

Compliant 100% 98%

Minor Non‐ Compliance 98%‐100% 95‐98%

Major Non‐ Compliance <98% <95%

Compliant 100% 100%

Non‐ Compliance <100% <100%

Percentage of Percentage of Percentage of findings

Minor Non‐ Compliance N.A. 0‐5% 0‐5%

Major Non‐ Compliance <100% >5% >5%

Minor Non‐ 0‐2% 0‐5% N.A. 0‐2%

Major Non‐ >2% >5% <100% >2%

Minor Non‐ N.A. 0‐2%

Major Non‐ >0% >2%

Quarter Number of Systems Number of Systems with missing patches

Major Non‐ Compliance >10% >2%

No. of Incidents Percentage No. of Incidents No Incident not

S.No. Threats Associated Vulnerabilities

Threat Vulnerability Identified Controls

Business Impact definition Illustration / Example Impact Rating Value

2. Bellone, Jason; Dino Cataldo Dell'Accio; Juan Rodriguez; "A Cosmological

5. Bhatia, Mohan; "IT Merger Due Diligence: A Blueprint," Information Systems

8. Chatterji, Sushil; "Bridging Business and IT Strategies With Enterprise

9. Cano, Jeimy J.; "Inseguridad Informática y Computación Anti‐forense: Dos

10. Cerullo, Michael J.; Virginia Cerullo; "Threat Assessment and Security Measures

13. Deshmukh, Meera; Raj, Shankar; "Environment Interaction Evaluation: Building

Author Reviewer Authorizer

You might also like