A Code of Practice for Effective Information Security
Risk Management Using COBIT 5
Walid Al-Ahmad
Gulf University for Science & Technology
Mishref, Kuwait
alahmed.w@gust.edu.kw
Abstract—A low-level code of practice is presented in this
paper to help information security (IS) risk management
professionals manage enterprise IS risks effectively and
efficiently using COBIT 5 framework1. The proposed code of
practice is the result of the experience gained by the authors over
years through working with clients in many industries
implementing IS risk management using different international
standards and frameworks. COBIT 5 is supposed to serve as an
umbrella framework that integrates knowledge and practice of
many other standards and frameworks. However, COBIT 5, like
many other frameworks, lacks detailed guidelines at the low-level
activities carried out during IT risk management. This code of
practice is proposed to fill in this gap. The recommended
guidelines and activities have been successfully used in real-world
IS risk management projects.
Keywords— COBIT 5; Information Security; Risk
Management; Practical Guidelines; Risk Management Processes;
I. INTRODUCTION
There is no doubt that modern society and businesses
depend heavily on information technology in nearly every facet
of their activities. It is also widely accepted that enterprises of
all kinds are increasingly exposed to various kinds of risks,
including information technology risks. In any enterprise, IS
risks must be identified, evaluated, analyzed, treated and
properly reported. Therefore, it is critical to establish reliable
information security risk management (ISRM) frameworks.
There are many security standards and frameworks available to
help organizations manage these risks. However, many
companies across the globe have already adopted COBIT 5 [1]
as the primary business framework for the governance and
management of enterprise IT, including managing IS risks. In
fact, COBIT 5 as a comprehensive framework has already
incorporated and aligned with many standards and best
practices currently used such as ISO/IEC 31000 [2] and
ISO/IEC 27000 series [3], among others. Other researchers
have also advocated further research on COBIT 5 and its use in
practice [4]. As suggested by its designers, COBIT 5 provides
content with areas that need further elaboration and updates.
This paper is an attempt to address some of the elaborations
and updates related to IS risk management using COBIT 5 for
1
Throughout this paper, the quoted text from COBIT® 5 for Risk,
Appendix C, is used with permission. All rights reserved © ISACA,
ISBN: 978-1-4673-6988-6 ©2015 IEEE
Basil Mohammed
Accenture
Dammam, Saudi Arabia
basil.mohammed@accenture.com
Risk [5]. According to the market survey conducted by ISACA
[6] to identify what guidance COBIT5 users most needed to
help them obtain maximum value from the use of COBIT 5
framework, two main areas were highlighted, namely the need
for more guidance related to the COBIT 5 enablers and specific
topics where practical guidance related to COBIT 5 would be
most helpful. The authors believe that the practical guidelines
presented in this paper serve this purpose.
The remainder of this paper is organized as follows: section
2 highlights the high-level ISRM processes; section 3 presents
details of the ISRM process and its sub-processes; finally,
section 4, puts forward some conclusions and future research
opportunities in relation to our work.
II. OVERVIEW OF AN ISRM PROCESS
A process can be viewed as a road map or a recipe that
shows what should be done, how to do it, who is responsible
for doing it, and when in the lifecycle it should be done. The
use of processes has been proven to be useful to achieve
objectives in all fields. There is a consensus within the
information security community about the common
components of a high level process for ISRM [3, 5, 7]. The
high level processes of the ISRM are depicted in the diagram
shown in Figure 1. These processes are common to all risk
management frameworks. We refer the readers to COBIT 5 or
ISO 27005 for more information about the description of these
processes.
Each of the high level processes is usually implemented
using middle level sub-processes. The “Conduct Risk
Assessment” process is usually implemented using the
“Identify Risks”, “Analyze Risks”, and “Evaluate Risks” sub-
processes. The implementation of these sub-processes further
depends on low level sub-processes, which are sometimes left
to enterprises to determine and implement. The focus of this
work is on the implementation of these low level sub-
processes. This is done by providing all the details related to
the risk assessment activities that the IS risk management
professional needs to do. Where needed, detailed guidelines
and procedures are provided to clarify how to carry out the
activity. Moreover, clear explanations of the tasks is provided
and roles are assigned to these tasks as well. It is assumed that
the low level sub-processes are implemented sequentially in an
iterative manner. The approach outlined in the next section is
based on leading practices, namely ISO 27005 and COBIT 5.0
145
for Risk. Major effort was made to align the approach with
COBIT 5.0 for Risk. This approach is intended to be adaptive
and evolving and used to govern information security risk
assessments within the defined scope.
Fig. 1. High Level IS Risk Management Processes
III. LOW LEVEL PROCESSES
This section presents the low level processes used in the IS
risk management along with their corresponding activities and
guidelines to implement them. Each of the following sub-
sections introduces the high level and middle level processes to
which the low level sub-processes belong and a table to
describe and detail the activities of the low level sub-process.
The process ID and Practice ID references in the tables refer to
COBIT 5 for Risk processes [5].
A. Establish Scope and Boundaries
TABLE I. COLLECT DATA
Practice [1.1] Collect Data
COBIT 5.0 Process ID APO12 Process Manage Risk
Reference
Input Management direction
Output Detailed Information Security Risk Assessment Scope
References None
Sub-Process [1.1.1]: “Establish and maintain a method for
collection, classification, and analysis of Information Security
risk-related data.”
Description: The quality of the data collected and used for the
IS risk assessment is a critical success factor for the
assessment. Accordingly, the step of data collection should be
properly planned for. The ISRM team must agree on the
methods to be used for data collection that best fit into the
enterprise environment. This includes questionnaires, on-site
interviews, document review and use of automated scanning
ISBN: 978-1-4673-6988-6 ©2015 IEEE
tools. Following the agreement on the data collection method,
an understanding of data classification (in terms of
importance, relevance, etc.) and analysis approach must be
considered.
Outcome: Established method for IS risk-related data
collection, classification, and analysis. This can be
documented in the form of a process owned and managed by
ISRM team.
Sub-Process [1.1.2]: “Record relevant data on the enterprise’s
internal and external operating environment that could play a
significant role in the management of Information Security
risk.”
Description: ISRM team should identify internal/external
requirements related to the enterprise operating environment
(direction received from parent company, regulations of the
country of operation, considerations of cross relations with
other peer companies, direction received from senior
management and the board of directors)
Outcome: Detailed list of ISRM-related requirements in
relation to the operating environment of the enterprise.
Sub-Process [1.1.3]: “Survey and analyze the historical
Information Security risk data and loss experience from
externally available data and trends, industry peers through
industry-based event logs, databases, and industry agreements
for common event disclosure.”
Description: In order to have insights on the IS risks, and to
take into consideration the nature of the business and industry,
the ISRM team to survey available public information related
to IS risks in peer companies, analyze published IS risk trends,
and outreach to similar other companies to understand the IS
risks associated with similar environments.
Outcome: Understanding of IS risks associated with similar
industry. This should be maintained in the risk register.
Sub-Process [1.1.4]: “Record data on risk events that have
caused or may cause impacts to Information Security
benefit/value enablement, Information Security program and
project delivery, and/or Information Security operations and
service delivery.”
Description: In addition to considering the IS risks associated
with the industry, ISRM team needs also to capture IS risks
that already exist in the enterprise that were previously
identified as part of an internal assessment or an external audit
of a compliance check. Also, data recorded on incidents,
problems and investigations should be taken into consideration.
Outcome: Inventory of potential IS risks based on previously
conducted assessments. This should be maintained in a risk
register format.
Sub-Process [1.1.5]: “Organize and categorize the collected
Information Security risk data.” & “Determine the specific
conditions that existed or were absent when risk events
occurred and the way the conditions affected event frequency
and loss magnitude.”
Description: Based on the data collected on IS risks from
similar enterprises and the enterprise specific previous
experience, ISRM team to analyze this data and provide
146
recommendations on focus areas for IS risk assessment. This
step would identify the scope for the IS risk assessment to be
conducted with specific scope for the enterprise needs. ISRM
team needs to:
(1.1.5.1) Identify critical assets and the related information.
The assets can be hardware, software, services (processes),
personnel, and third party service providers.
(1.1.5.2) Identify the IS processes in scope for the assessment
(change management, access management, etc.)
(1.1.5.3) Collect supporting information on the IS risk
environment which includes but not limited to:
• Systems description
• Organizational IS policies and procedures
• Current network topology
• Technical controls used for IS Systems (Example: Built-
in or add-on security product)
• Management controls used for IS Systems (Example:
Rules of behavior)
• Operational controls used for IS Systems (Example:
Backup and recovery operations)
• Physical and environmental security mechanisms
(Example: Facility Security, Controls for humidity, water,
and power)
(1.1.5.4) Consolidate and propose scope for the IS risk
assessment. The scope must be approved by IS Risk Manager.
Outcome: Identification of focus areas and Scope of Work
(SoW) for the IS risk assessment.
Guidelines: Ref (1.1.5.1) - In order to identify critical assets,
the enterprise ISRM team needs to:
• Review existing assets inventory (if exists)
• Check the assets inventory appropriateness in terms of
coverage and quality of content.
• Review the existing Business Impact Analysis (BIA)
document (if exists)
• Check its appropriateness in terms of coverage and
quality of content.
• Arrange for meetings and\or interviews with assets
inventory and BIA document owners to:
o Check that the inventory of assets and BIA are up-
to-date.
o Understand how these documents were created and
what controls are associated with them in terms of
ownership and maintenance.
o If there is no assets inventory in place, ISRM team to
coordinate with concerned team(s) to create the assets
inventory.
• For the IS assets in the inventory, ISRM team needs to
select a subset for assets valuation and criticality
assessment. This subset has to be approved by the IS Risk
Manager.
• Conduct criticality and valuation assessment for the
selected assets. The assets criticality assessment criteria
must be documented, reviewed at least on an annual basis,
and approved by IS Risk Manager before use.
• Complete the criticality assessment, discuss results with
assets owners and collect their approval.
ISBN: 978-1-4673-6988-6 ©2015 IEEE
Ref (1.1.5.2) - In order to identify IS processes in scope for the
assessment, the enterprise ISRM team needs to:
• Consider IS general processes for the assessment that are
aligned with IS risk universe (ref COBIT 5 for IT general
processes)
• Agree with IS Risk Manager on the depth and breadth of
the IS risk assessment for the IS general processes.
• Document the IS processes in scope in an inventory with
clear justification for inclusion per process, ownership,
and scope for the assessment.
• Set/update the assessment dates for all IS processes
(included or excluded for tracking and monitoring
purposes).
Ref (1.1.5.3) – The IS risk assessment requires background
information that would give insights on the environment and
the existing controls. ISRM team needs to:
• Creates pre-assessment requirements document
• Circulate to concerned divisions/departments in the
enterprise
• Collect the requested documentation.
• Check collected data for appropriateness in terms of
coverage and quality of content.
Ref (1.1.5.4) – The ISRM team needs to consolidate the data
gathered on the assets, processes and other requested
documentation to propose SoW for the IS risk assessment.
• Document the SoW
• Collect IS Risk Manager approval
Sub-process [1.1.6]: “Perform periodic event and Information
Security risk analysis to identify new or emerging risk issues
and to gain an understanding of the associated internal and
external risk factors.”
Description: ISRM team to establish a process that would
ensure the previous steps are conducted on periodic basis to
keep reference information for security risks up-to-date.
Outcome: Process for keeping IS-risk related data current and
up-to date with set and agreed upon periodicity.
B. Conduct Risk Assessment
TABLE II. ANALYZE RISK
Practice [2.1] Analyze Risk
COBIT 5.0 Process ID APO12 Process Manage Risk
Reference
Input Detailed Information Security risk assessment scope
Output Completed risk assessment registers
References (1) Customized work plans, (2) Risk register template, (3)
Risk assessment map
Sub-Process [2.1.1]: “Define the appropriate breadth and
depth of risk analysis efforts, considering all risk factors and
the business criticality of assets.”
Description: The ISRM team needs to confirm the breadth
and depth of the intended risk assessment. This needs to be
adjusted to emerging needs, management direction and other
possible ad-hoc requirements (new systems, infrastructure
changes, etc.) Management might decide to do the assessment
147
for specific IS processes and/or selected IS assets. For this
purpose, ISRM team would:
(2.1.1.1) Customize the work plans to be used during the
assessment for each and every IS process.
(2.1.1.2) Collect input on the customized work plans from the
concerned divisions.
(2.1.1.3) Analyze and review collected responses. Consolidate
the identified gaps in observations format in preparation for
sharing the same with concerned divisions for final
confirmation.
Outcome: Completed customized work plans based on the
agreed upon scope. The number of work plans at this stage
will depend on the IS processes/assets selected for assessment.
This step will also conclude with the identification and
consolidation of weaknesses that exist in the IS processes.
Guidelines: Ref (2.1.1.1) - In order to customize the work
plans, ISRM team needs to:
• Review existing work plans (in case current existing work
plans are previously defined)
• In case the scope is including a new IS process, related
work plan needs to be created incorporating the areas
(controls based on selected standard with most applicable
coverage).
• The customization exercise would consider:
o Which processes/assets and related practices to
include or exclude based on the scope.
o Which activities or controls (in case of COBIT 5.0)
to include or exclude based on the scope.
• The work plans need to be customized by the IS Risk
Analyst reviewed by the IS Risk Senior Analyst and
approved by IS Risk Manager.
• ISRM team will be responsible for the maintenance of the
work plans and managing their life-cycle (revisions,
versioning, updates, retirement, etc.)
Ref (2.1.1.2) – With the customized work plans ready to use,
ISRM team needs to:
• Agree internally with IS Risk Manager on the approach to
use to collect responses on the work plans (conduct one-
to-one meetings, arrange for workshops, send over email,
etc.)
• Agree with concerned parties (departments) on the best
setup that would be efficient and effective to collect their
input on the work plans.
• Where meetings are involved, plan for the meetings and
collect needed input on the work plans.
Ref (2.1.1.3) – Once all responses are collected on the work
plans, ISRM team needs to:
• Review the collected data and validate in terms of quality
and factuality.
• Where the activity in the work plan is not in place,
highlight this as a gap that would require later treatment.
• Consolidate all the identified gaps in observations format
and categorize per IS process:
o An observation format would consider in referral to
the source of information (meeting, discussion, email,
etc.) what was not found in place compared to the
ISBN: 978-1-4673-6988-6 ©2015 IEEE
proposed condition as per recommended activity
reference.
• Once all observation are consolidated and categorized per
IS process, the IS Risk Senior Analyst to discuss with
concerned divisions for their confirmation on the
identified issues.
• The final list of observations is then shared with IS Risk
Manager for final approval.
Sub-Process [2.1.2]: “Build and regularly update Information
Security risk scenarios - consider custom scenarios specific
for the enterprise.”
Description: In order to have an effective risk assessment,
ISRM team needs to create and customize specific IS risk
scenarios that apply to the enterprise. The IS risk scenarios
should be based on the observations that were captured in step
[2.1.1] and take into consideration the previously collected
data in [1.1.1] as well.
Outcome: Customized risk scenarios specific for the
enterprise environment and IS challenges.
Guidelines: Ref (2.1.2) – ISO 27005/COBIT 5.0 for Risk
provides generic IS risk scenarios that can be used in the risk
assessment process, however, it is recommended that the
enterprise uses these scenarios for guidance in the course of
development of customized IS risk scenarios. In order to do
so, ISRM team needs to:
• Define risk scenario categories specific for the enterprise.
This would take into consideration specific environment,
business and IS challenges.
• Provide detailed description for the defined risk scenarios
explaining how the proposed scenario would affect the
enterprise business.
• Make sure that:
o Number of created risk scenarios is reasonable.
o The risk scenarios are realistic.
o Closely aligned with the observations consolidated
and data collected in [2.1.1] & [1.1.1]
• Risk scenarios should be approved by IS Risk Manager.
• Further reference is made to the created risk register
template containing the fields to be completed for each
and every custom risk scenario.
Sub-Process [2.1.3]: “Estimate the frequency and impact
associated with Information Security risk scenarios. This takes
into account all applicable risks, evaluate known operational
controls and estimate residual risk levels.”
Description: In this step, the ISRM team with the
consolidated observations and customized risk scenarios in
hand will be able to do the risk assessment:
(2.1.3.1) Create risk statements based on the consolidated
observations.
(2.1.3.2) For each risk statement created, map the risk to a risk
scenario from the risk scenarios categories.
(2.1.3.3) Evaluate the risk by estimating values for the impact
of the risk and the likelihood of its occurrence.
(2.1.3.4) Consolidate the identified risks per IS process.
148
Outcome: Detailed risk assessment that shows the identified
risks, enterprise risk scenarios, impact and likelihood of each
risk in the register.
Guidelines: Ref (2.1.3.1) – The ISRM team needs to:
• Review the documented observations carefully, identify
common points that can be grouped into one risk
statement.
• Create risk statements taking into consideration that risk
statements must:
o Contain cause and effect phrases in each statement.
o Be short but precise statements.
• All risk statements need to be documented in the risk
register template.
Ref (2.1.3.2) – Once the IS risk statements are created, ISRM
team needs to:
• Map the risk statements to the created risk scenarios.
• Customize risk scenarios as needed in order to
accommodate new risks
• If new risk scenarios are added, they need to be approved
by IS Risk Manager.
Ref (2.1.3.3) – As part of the risk evaluation, values must be
given to the risk impact and likelihood of occurrence:
• ISRM team needs to agree on the values to be assigned
for the risk impact.
• ISRM team needs to agree on the values to be assigned
for the risk likelihood of occurrence.
• The risk map to be used must be approved by the IS Risk
Manager before proceeding further with the assessment.
• The combination of the values assigned for impact and
likelihood will determine the estimated risk value. This
will be set based on the risk map used, however, as a
general rule; the assessor can take the higher of the two as
the overall risk value.
• Update the risk registers with the assessment results.
Ref (2.1.3.4) – In order to give comprehensive oversight on
the identified risks, ISRM team needs to:
• Create executive summaries for each risk register.
• Consolidate the summaries in one risk register that will be
shared with other divisions.
• All registers and executive summaries need to be
approved by IS Risk Manager.
TABLE III. MAINTAIN A RISK PROFILE
Practice [2.2] Maintain a Risk Profile
COBIT 5.0 Process ID APO12 Process Manage Risk
Reference
Input Completed risk assessment registers
Output ENTERPRISE IS risk profile & KRIs
References (1) IS Risk Registers, (2) IS Risk Executive Summaries
Sub-Process [2.2.1]: Capture all risk profile information and
consolidate into a risk profile. Include the status of the risk
action plans (in case previously defined) in the Information
Security risk profile of the enterprise.
Description: Based on the data collected and the effort spent
creating the risk registers, ISRM team will be able to create
the IS risk profile. The IS risk profile typically would contain
ISBN: 978-1-4673-6988-6 ©2015 IEEE
(1) the current IS risks at the enterprise and (2) the enterprise
acceptable level of risk:
(2.2.1.1) Review the risks captured in the risk registers.
(2.2.1.2) ISRM team to agree on acceptable level of risk for
each risk. This should be approved by IS Risk Manager.
Outcome: Completed IS risk profile.
Sub-Process [2.2.2]: “Based on the risk profile data, define a
set of key risk indicators (KRI) that allow the quick
identification and monitoring of current risk and risk trends.”
Description: The ISRM team needs to create a set of key risk
indicators (KRIs) that would be used in a later stage for
monitoring purposes.
Outcome: Defined set of key risk indicators (KRIs) for IS
risks captured in the enterprise risk profile.
Guidelines: Ref (2.2.2) – Creating key risk indicators would
require that ISRM team does the following:
• Review IS risk profile and identify risk trends per area.
• Specify metrics or thresholds that would be considered
alerting and require ISRM attention. This should be
aligned with the risk acceptance criteria:
o Example: under the IS process of change
management one KRI to monitor the risks associated
with change management process could be “the
percentage of IS changes per month that are found
not complying with the enterprise IS change
management policy (or procedure)”
o If this KRI is set to 1% this would mean that the
enterprise is accepting that 1% of the changes per
month might not be in compliance with the policy (or
procedure)
• Define the associated process of KRI reporting and/or
escalation of exceptions.
• Define a process for periodic review and update for
defined metrics.
• All defined metrics (KRIs) need to be prepared by the IS
Risk Senior Analyst and approved by IS Risk Manager.
TABLE IV. ARTICULATE RISK
Practice [2.3] Articulate Risk
COBIT 5.0 Process ID APO12 Process Manage Risk
Reference
Input The enterprise Information Security risk profile
Output Communication plan
References (1) IS Risk Registers, (2) IS Risk Executive Summaries,
(3) IS Risk Profile
Sub-Process [2.3.1]: Share the risk profile and KRIs with all
affected stakeholders in terms and formats useful to support
decisions. This should include risks, gaps, remediation status,
and their impacts on the overall IS risk profile.
Description: The ISRM process is owned by the ISRM team,
however, it is critical to make sure that the results of the risk
assessment are timely and adequately shared with the
concerned divisions who will take (1) part of the risks
treatment responsibility (2) ownership of some identified risks
149
(3) use the content of the risk profile in decisions making (4)
Support in KRIs monitoring
Outcome: IS Risk profile and KRIs communication plan with
concerned stakeholders (departments).
C. Risk Treatment
TABLE V. DEFINE RISKS ACTION PLAN
Practice [3.1] Define Risk Action Plan
COBIT 5.0 Process APO12 Process Manage Risk
Reference ID
Input The enterprise IS risk profile
Output Detailed risk treatment plan
References (1) IS Risk Registers, (2) IS Risk Executive Summaries,
(3) IS Risk Profile
Sub-Process [3.1.1]: “Decide on the risk treatment option(s)
and consider the activities to address identified risks in line
with the enterprise risk tolerance. Map treatment options to
specific Information Security risk statements.”
Description: ISRM team needs to ensure that risk treatment
plans based on the available risk treatment options are defined.
This should take into consideration the enterprise IS risk
tolerance (the enterprise IS risk tolerance is the amount of risk
the company is willing to accept in a certain specific IS
process). For each identified risk in the risk profile a decision
should be made on how to treat the risk. There are several
treatment options that include: 1) risk avoidance, 2) risk
acceptance, 3) risk transfer, 4) risk mitigation. Cost-benefit
analysis is usually used to select the best option; however, any
option to be selected must take into consideration the
enterprise business nature and operating environment.
Outcome: IS Risk treatment plan documented on the IS risk
register template.
Guidelines: Ref (3.1.1) – The ISRM team will use the IS risk
register template to document the risk treatment plans:
• There are usually four options to consider:
o Risk avoidance: terminate the activity leading to risk.
o Risk acceptance: simply accept the risk
o Risk transfer: transfer risk to another party.
o Risk mitigation: mitigate risk with appropriate
control measures or mechanisms
• The documented plans need to be created by the IS Risk
Senior Analyst and approved by IS Risk Manager.
• Since the plans would include actions from other
departments/divisions, ISRM team needs to consider
sharing these plans with concerned parties for input and
action as needed.
• Detailed justification for the selected option must be
documented in the risk register template.
ISBN: 978-1-4673-6988-6 ©2015 IEEE
TABLE VI. RESPOND TO RISKS
Practice [3.2] Respond to Risk
COBIT 5.0 Process ID APO12 Process Manage Risk
Reference
Input Detailed risk treatment plan
Output Risk response plan
References IS Risk Register containing the risk treatment plan
Sub-Process [3.2.1]: “Prepare and maintain plans that
document the specific steps to take to address and respond to
a risk event that may occur.”
Description: In order to minimize the impact of a risk on the
enterprise operations and ensure it is properly planned for, a
detailed action plan must be documented which would be
subject for monitoring in order to ensure: 1) it is adequate and
effectively addressing the risk 2) implemented as planned.
Exceptions to the plan must be justified and shared with IS
Risk Manager for approval.
Outcome: IS Risk response action plan(s).
Guidelines: Ref (3.2.1) – The ISRM team needs to follow up
with risk owners to provide detailed action plans for risk
remediation. These plans must be provided in reasonable time
with reasonable target dates. The risk owners would be liable
for timely implementation of the action plans:
• Use the risk register template to document the details of
the action plans.
o Check the plans for quality and effectiveness.
• Closely monitor the performance of the actions plans.
• Request justifications for exceptions and retargeted dates.
• Report exceptions to IS Risk Manager for approval.
• Provide a balanced set of proposals and initiatives
designed to reduce risk considering cost/benefits, effect
on current risk profile and regulations.
D. Communicate Risks
TABLE VII. COMMUNICATE RISKS
Practice [4.0] Communicate Risk
COBIT 5.0 Ref. Process ID APO12 Process Manage Risk
Input Detailed IS risk register
Output IS Risk Report
References IS risk register containing risks, risk assessment, risk
treatment and response plan
Sub-Process [4.1]: “Report on the risk profile (identified
risks, risks assessment, treatment, and overall risk exposure)
and the associated KRI’s to all concerned stakeholders
(internal/external).”
Description: ISRM team needs to create a report on the risk
assessment that was conducted and communicate it to other
internal/external stakeholders. The report can include in
addition to the details related to the risk values a description of
the scope that was covered, objectives of the assessment,
status of previous assessment results related to the identified
risks and most importantly an introduction to the approach and
methodology that ISRM team adopted in the assessment. The
risk assessment report can also highlight the challenges that
150
were faced during the assessment and suggest what to be done
differently next time to improve the overall risk assessment
results.
Outcome: IS Risk Report
Guidelines: Ref (4.1) –ISRM team needs to consider the
following:
• The assessment report should state the scope, objectives,
period of coverage and nature, timing and extent of the
assessment work.
• The report should state the risks, conclusions, and
recommendations in simple statements avoiding
complexity.
• When issued, the report should be approved and signed
by the IS Risk Manager, dated, and distributed according
to the agreed upon protocols within the enterprise.
• Communication channels are established for reporting and
disseminating the risk assessment report.
E. Monitor and Review Risks
TABLE VIII. MONITOR AND REVIEW RISKS
Practice [5.0] Monitor and Review Risks
COBIT 5.0 Process APO12 Process Manage Risk
Reference ID
Input KRI’s and other controls information
Output Reporting on KRI’s performance and any other exceptions
References (1) IS risk profile, (2) IS risk assessment report
Sub-Process [4.1]: Monitor the effectiveness of controls as
part of an ongoing effort to manage IS risks.
Description: An important component of the risk
management life cycle is continuously monitoring, evaluating
and assessing risk. The results and status of this ongoing
analysis needs to be documented and reported to IS Risk
Manager on a regular basis. To facilitate such reporting, visual
aids such as graphs or charts and summarized overviews on
KRI’s can be used. Exceptions requiring senior management
attention or the involvement of other stakeholders need to be
communicated timely through the defined communication
channels.
Outcome: Reporting on KRI’s performance and any possible
exceptions.
Guidelines: Ref (5.1) –ISRM team needs to consider the
following:
• Senior management will typically have little interest in
technical details and is likely to want an overview of the
ISBN: 978-1-4673-6988-6 ©2015 IEEE
current status and indicators of any immediate or
impending threat that requires attention.
• Dashboards or heat charts are often used to show an
overall assessment of the risk posture
• Whatever the form of reporting, ISRM team needs to
ensure that this reporting takes place and the results are
analyzed adequately and acted on appropriately in a
timely manner.
• This responsibility includes:
o Identifying the types of events that will trigger
reporting required by both external (law
enforcement) and internally.
IV. CONCLUSIN
A code of practice to implement low level activities have
been introduced in this paper to use COBIT 5 for risk
successfully to manage IS risks within an enterprise. The code
of practice has filled the gaps in the COBIT 5 framework with
respect to details and guidelines when implementing the
framework. The code of practice proposed in this paper has
been used in many real-world projects in different industries
and has proven to be effective and useful. It is hoped that
ISACA will adopt some of these guidelines and incorporate
them in COBIT 5 for Risk in future versions. The
recommendations and guidelines presented in this paper serves
as the basis for further investigation and elaborations by ISRM
practitioners on the same.
REFERENCES
[1] ISACA (Information Systems Audit & Controls Association), COBIT 5,
ISACA Publication/ United States, 2012.
[2] ISO (International Standards Organization), Risk Management –
Principles and Guidelines, ISO/IEC Publications, Switzerland, 2009.
[3] ISO (International Standards Organization), Information Technology –
Security Techniques – Information Security Risk Management, ISO/IEC
Publications, Switzerland, 2008.
[4] S. De Haes, W. Van Grembergen, and R. Debreceny, “COBIT 5 and
Enterprise Governance of Information Technology: Building Blocks and
Research Opportunities,” Journal of Information Systems, vol. 27, pp.
307–324, 2013.
[5] ISACA (Information Systems Audit & Controls Association), COBIT 5
for Risk, ISACA Publication/ United States, 2013.
[6] S., Chatterji, “COBIT 5 Market Guidance: What Next?”, COBIT Focus,
http://www.isaca.org/cobit/focus/, 2014.
[7] NIST (National Institute of Standards and Technology), Managing
Information Security Risks, NIST Special Publication 800-39/United
States, 2011.
151