IS Audit/Assurance Program

IT Risk Management

IS Audit/Assurance Program
IT Risk Management
Column Name Description Instructions
Process Sub-area An activity within an overall process influenced by the enterprise's To make the audit program manageable, it is recommended to break out
policies and procedures that takes inputs from a number of sources, the scope of the audit into sub-areas. The auditor can modify this field to
manipulates the inputs and produces outputs entity-specific names and terms. ISACA has used the most commonly
used terms as the basis to develop this audit program.

Ref. Risk Specifies the risk this control is intended to addressed This field can be used to input a reference/link to risk described in the
entity's risk register or enterprise risk management (ERM) system, or to
input a description of the risk a particular control is intended to address.

Control Objectives A statement of the desired result or purpose that must be in place to This field should describe the behaviors, technologies, documents or
address the inherent risk in the review areas within scope processes expected to be in place to address the inherent risk that is part
of the audit scope.

An IS audit manager can review this information to determine whether

the review will meet the audit objectives based on the risk and control
objectives included in the audit program.

Controls The means of managing risk, including policies, procedures, guidelines, This field should describe in detail the control activities expected to be in
practices or organizational structures, which can be of an administrative, place to meet the control objective. Control activities can be in roles and
technical, management or legal nature responsibilities, documentation, forms, reports, system configuration,
segregation of duties, approval matrices, etc.

An IS audit manager performing a quality control review must decide

whether an auditor has planned to identify enough controls on which to
base an assessment and whether the planned evidence is sufficiently
objective.

(c) ISACA 2016 All Rights Reserved 1

 IS Audit/Assurance Program
IT Risk Management

Control Type Controls can be automated (technical), manual (administrative) or Specify whether the control under review is automated, manual, physical
physical. or a combination. This information is useful in determining the testing
steps necessary to obtain assessment evidence.
Automated/technical controls are things managed or performed by
computer systems.
Manual/administrative controls are usually things that employees can or
cannot do.
Physical controls include locks, fences, mantraps and even geographic
specific controls.

Control Classification Another way to classify controls is by the way they address a risk Specify whether the control under review is preventive, detective,
exposure. corrective or compensating. This information will be helpful when
defining testing steps and requesting evidence.
Preventive controls should stop an event from happening.
Detective controls should identify an event when it is happening and
generate an alert that prompts a corrective control to act.
Corrective controls should limit the impact of an event and help resume
normal operations within a reasonable time frame.
Compensating controls are alternate controls designed to accomplish the
intent of the original controls as closely as possible when the originally
designed controls cannot be used due to limitations of the environment.

Control Frequency Control activities can occur in real-time, daily, weekly, monthly, annually, Specify whether the control under review occurs in real-time, daily,
etc. weekly, monthly, annually, etc. This information will be helpful when
defining testing steps and requesting evidence.

Testing Step Identifies the steps being tested to evaluate the effectiveness of the This field should describe in detail the steps necessary to test control
control under review activities and collect supporting documentation. The auditor can modify
this field to meet entity-specific needs. ISACA has used a set of generic
steps develop this audit program.

An IS audit manager may determine if the proposed steps are adequate to

review a particular control.

(c) ISACA 2016 All Rights Reserved 2

 IS Audit/Assurance Program
IT Risk Management

Ref. COBIT 5 Identifies the COBIT 5 process related to the control objective or control Input the COBIT 5 process or practice that relates to this control.
activities

Ref. Specifies frameworks and/or standards that relate to the control under Input references to other frameworks used by the entity as part of their
Framework/Standards review (e.g., NIST, HIPAA, SOX, ISO) compliance program.

Ref. Workpaper The evidence column usually contains a reference to other documents Specify the location of supporting documentation detailing the audit steps
that contain the evidence supporting the pass/fail mark for the audit step. and evidence obtained.
An IS audit manager performing a quality control review must decide
whether an auditor has tested enough controls on which to base an
assessment and whether the obtained evidence is sufficiently objective to
support a pass or fail conclusion.

Pass/Fail Document preliminary conclusions regarding the effectiveness of controls. Specify whether the overall control is effective (Pass) or not effective (Fail)
based on the results of the testing.

Comments Free format field Document any notes related to the review of this Process Sub-area or
specific control activities.

(c) ISACA 2016 All Rights Reserved 3

 IS Audit/Assurance Program
IT Risk Management

IS Audit/Assurance Program
IT Risk Management
Ref. Control Control Control
Process Sub-Area Risk Control Objectives Controls Type Class Frequency

Governance CO1. Senior IT and enterprise management and
the board regularly and routinely consider,
monitor and review IT risk management.
C1. The board of directors or similar function
receives information on IT risk exposures and
measures in place to deal with risk containment
and associated costs, and approves the
appropriateness of the risk management plan
and its alignment with the appetite for risk.

C2. Management monitors risk management

practices to ensure that risk management is
operating as required, responsibilities for risk
management are appropriately and
unambiguously assigned, and management has
resources in place to ensure proper management
of IT risk.

C3. An escalation and follow-up process monitors

and identifies risk exceptions (i.e., risk exposures
exceeding the defined risk appetite, outstanding
risk mitigation projects in progress, controls not
implemented to facilitate achieving business
objectives).

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 4

 IS Audit/Assurance Program
IT Risk Management

IS Audit/Assurance Program
IT Risk Management
Ref. Control Control Control
Process Sub-Area Risk Control Objectives Controls Type Class Frequency

IT Risk Management CO2. The IT risk management framework is C4. Management Framework Definition
Framework aligned with the ERM framework. Control: The IT risk management framework
utilizes a methodology and definitions that align
with the ERM framework.

IT Risk Management CO3. The risk management process is aligned C5. Risk management process provides for risk
Process with the framework, addresses the goal of the identification by stakeholders and interested
risk assessment and establishes the risk criteria. parties.

The enterprise should follow the same risk

identification process, which should incorporate
a standard template (e.g., risk register) to record
identified risk. The process must include a
standard taxonomy to categorize risks in a
consistent way across all organizations.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 5

IT Risk Management
Process
IS Audit/Assurance Program
IT Risk Management

IS Audit/Assurance Program
IT Risk Management
Ref. Control Control Control
Process Sub-Area Risk Control Objectives Controls Type Class Frequency

C6. The risk assessment process evaluates the

quantitative risk using impact, probability and
time frame, where data/metrics exist, and uses
qualitative assessment using the same
components, where data/metrics do not exist.

C7. The risk process provides criteria for

prioritizing the types of risk and ranks them
according to an approved scale.

C8. The risk process is documented, distributed

to appropriate personnel and is utilized in the risk
analysis.

The IT risk management process includes risk

mitigation steps where the residual risk is
compared with the risk appetite and when
necessary, additional mitigation measures are
applied (risk avoidance, risk acceptance, risk
transfer or risk reduction).

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 6

 IS Audit/Assurance Program
IT Risk Management

IS Audit/Assurance Program
IT Risk Management
Ref. Control Control Control
Process Sub-Area Risk Control Objectives Controls Type Class Frequency

Event Identification CO4. Important events and near misses affecting C9. Stakeholders agree to and sign off on key
the IT function are identified, analyzed and risk- events and their impacts.
rated. The results are maintained in a registry or
database.

* Near misses are the events which have not

materialized to be identified as risk events.
However, recording near misses is equally
important to ensure that the right controls are
implemented to minimize impact on the
enterprise.

C10. Negative impacts are identified, analyzed

and documented.

C11. Cross-functional teams are involved in the

event and impact identification process.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 7

 IS Audit/Assurance Program
IT Risk Management

IS Audit/Assurance Program
IT Risk Management
Ref. Control Control Control
Process Sub-Area Risk Control Objectives Controls Type Class Frequency

C12. Event scope is addressed at a sufficiently

global/high level to ensure completeness and
identification of interdependencies.

Risk Assessments
CO5. Risk assessments are performed on a C13. Risk assessments follow the risk
recurrent basis, using qualitative and quantitative management framework and process, using the
methods that assess the likelihood (probability) defined qualitative and quantitative metrics.
and impact of identified risk. The scope of this
assessment addresses both inherent and residual
risk.

C14. The risk identified has been evaluated for

material effect on the business functions and the
materiality of such risk is within the enterprise
materiality classifications.

C15. The risk assessment includes a process to

evaluate the inherent risk in an event, the
controls in place, the resulting residual risk and
the required risk response.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 8

 IS Audit/Assurance Program
IT Risk Management

IS Audit/Assurance Program
IT Risk Management
Ref. Control Control Control
Process Sub-Area Risk Control Objectives Controls Type Class Frequency

IT Risk Response CO6. A risk response process has been defined C16. The results of the risk assessment generate
and effectively implemented. a risk mitigation strategy, which considers the
significance of the risk, probable cost and
benefits of remediation actions.

C17. A risk action plan is developed based on the

risk assessment results.

Maintenance and CO7. The risk action plan is monitored for C18. The risk action plan contains a prioritized
Monitoring of IT Risk appropriate execution, identification of costs, risk response, which identifies implementation
Action Plans benefits, responsibility and approval of remedial priorities, responsibilities, schedules, expected
actions or acceptance of residual risk. outcome of risk mitigation, costs and benefits.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 9

Maintenance and
Monitoring of IT Risk
Action Plans IS Audit/Assurance Program
IT Risk Management

IS Audit/Assurance Program
IT Risk Management
Ref. Control Control Control
Process Sub-Area Risk Control Objectives Controls Type Class Frequency

C19. Risk response actions are approved by

appropriate management, affected business units
are aware of risk activities, and in instances in
which residual risk acceptance is warranted, it
has been approved at the appropriate levels of
management by individuals authorized to accept
the risk.

C20. The execution of the risk response plan is

monitored, showing progress, issue monitoring
and plan adjustment.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 10

 IS Audit/Assurance Program
IT Risk Management

IS Audit/Assurance Program
IT Risk Management
Ref. Control Control Control
Process Sub-Area Risk Control Objectives Controls Type Class Frequency

C21. IT risk management is part of operational

processes.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 11

 IS Audit/Assurance Program
IT Risk Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/St Workpaper Fail Comments
andards
1. Obtain the minutes from recent board meetings. Determine if: EDM03
- IT risk reports on exposures, measures in place and material residual risk that is outstanding.
- The board approves the risk management plan and agrees to the level of risk accepted by
management.

1. Determine if IT risk management practices are properly documented and reviewed at EDM03
predetermined intervals by senior IT management for approval.
2. Interview IT management to determine if management actively monitors the IT risk
management process.
3. Ensure that IT risk management reports to appropriate senior management responsible for
ERM and coordination with IT.

1. Determine if an escalation and follow-up process for monitoring IT risk exceptions is in place. EDM03
2. Determine if the follow-up process is reviewed by IT management and ERM on a regular
basis.
3. Determine if issues escalated to senior management have been acted on in a reasonable
time frame.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 12

 IS Audit/Assurance Program
IT Risk Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/St Workpaper Fail Comments
andards
1. Obtain the IT risk management framework and the ERM framework. EDM03;
2. Compare the two approaches and, if available, review documents and procedures. APO01
3. Verify that the risk management processes are aligned and integrated with the ERM
framework and related operational procedures.
4. Verify that the risk classifications are uniform and address strategic, program, project and
operational activities.
5. Identify the scales used to classify risk:
- Probability
- Expected losses/costs
- Materiality levels
- Nonfinancial factors
6. Assess whether the IT risk scales align with the enterprise risk scales.
7. Identify gaps and misalignments between the two processes.

1. Identify the process for risk identification (e.g., risk identification workshops, surveys, inputs APO12
and feedbacks) and ensure it has been implemented effectively.
2. Verify if a common template and taxonomy is used to identify, assess and record risk by all
organizations.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 13

 IS Audit/Assurance Program
IT Risk Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/St Workpaper Fail Comments
andards
1. Obtain the criteria for measuring: APO12
- Impact (catastrophic, critical, marginal)
- Probability (likely, probable, improbable)
- Time frame (imminent, near-term, far-term)
2. Determine if the process utilizes the same criteria as the enterprise risk process.
3. Determine if the criteria is effective and appropriate for the IT organization.

1. Obtain the prioritization process utilized in the risk assessment. APO12

2. Determine if the process incorporates priority assessments from the stakeholders/interested
parties, includes a voting process where appropriate, and conflict resolution/escalation
processes if the interested parties cannot agree on priorities.

1. Obtain the risk process documentation. APO12

2. Determine if the documentation is current, regularly updated and approved by senior IT
management.
3. Determine if the risk management process is communicated across the enterprise and
appropriate training is imparted to ensure effective and uniform implementation.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 14

 IS Audit/Assurance Program
IT Risk Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/St Workpaper Fail Comments
andards
1. Determine the process in which stakeholders review and approve the key events and their APO12
impact to the enterprise.
2. Obtain the key events and their impacts documentation for the most recent risk assessment.
3. Determine if the stakeholders signed off on the key events and that the impacts are
identified.
4. Determine if the stakeholders and IT agreed with the impact statements.

1. Identify the procedure to identify and evaluate relevant negative impacts that could affect APO12
the enterprise goals or operations.
2. Determine if the procedure adequately records each event and the rationale used to assess
the risk priority and effect on the enterprise.
3. Obtain the negative impacts document. Determine if the documentation is maintained,
describes the known negative impacts, and include those impacts that should reasonably be
known.
4. Determine if a negative impacts registry is used and maintained.

1. Obtain documentation (meeting minutes, notes, etc.) that identifies team involvement in the APO12
event identification process.
2. Determine if the subject matter experts from the various functional teams have been actively
involved in event identification.
3. Determine if the cross-functional teams participate in the prioritization of events.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 15

 IS Audit/Assurance Program
IT Risk Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/St Workpaper Fail Comments
andards
1. Interview representative members of the event identification team. EDM03;
2. Determine if the scope of the event identification was addressed at a sufficiently high level to APO12
include a wide range of events for risk assessment.
3. Determine if interdependencies were included in the analysis, including their impact and
probability.

1. Obtain the most recent risk assessment documentation. APO12

2. Select a sample business risk identified in the documentation.
3. For the sample item determine that the risk was appropriately evaluated and included:
- Qualitative risk (probability)
- Quantitative risk using statistical analysis and probability
- The sources of information to base the risk assessment
- Validation of the propriety of the sources

1. Using the sample generated for the risk metrics, determine: APO12
- If the materiality has been identified for each risk
- If the materiality is within the materiality classifications approved by the enterprise
- If the materiality assessment is reasonable

1. Review the risk assessment process for a required identification of each event's inherent risk, APO12
the controls in place that address the inherent risk, the residual risk as a result of the control
implementation and any required risk response.
2. Using the sample population generated of the risk metrics, for each event, determine if the
inherent risk, controls in place, residual risk and a required risk response have been
documented and analyzed.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 16

 IS Audit/Assurance Program
IT Risk Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/St Workpaper Fail Comments
andards
1. Obtain the risk assessment analysis process. APO12
2. Determine if the analysis process provides guidance on how to utilize the risk, probable cost
and remediation benefits to evaluate and recommend a remediation strategy.

1. Obtain the risk action plans for the issues and risk mitigation strategy identified in the APO12
sample.
2. Determine that the risk response action plan includes the following evaluation attributes:
- Priorities
- Existing controls that could be improved or modified
- Practical implementation considerations
- Any specific legal, regulatory or contractual requirements
- Probable costs
- Potential benefits
- Effort and time

1. Obtain the risk action plan. APO12

2. Determine if the risk action plan includes the following risk response attributes to determine
milestones and deliverables:
- Priority
- Assignment of responsibility
- Schedule of implementation
- Expected result after risk mitigation
- Expected residual risk after risk mitigation
- Costs
- Benefits

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 17

 IS Audit/Assurance Program
IT Risk Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/St Workpaper Fail Comments
andards
1. Determine how risk response actions are approved by appropriate management. EDM03;
2. Using the sample, determine if the appropriate management has approved the risk response APO12
actions.
3. Determine if the business units have been formally notified of the risk actions.
4. Identify instances in which management has accepted the residual risk of a risk response.
Determine if the individual approving the acceptance of risk has the authority, responsibility
and accountability to accept the residual risk on behalf of the entity.
5. Ensure that all risk acceptance events are properly recorded with approvals.

1. Determine if a formal risk execution monitoring process exists. The process should include: EDM03;
- Action plan description APO12
- Report progress
- Target dates
- Deviations from plan
- Notification of progress and escalation of issues to management
- Formal management review process
2. Obtain recent risk response plans.
3. Determine management receipt and review of the monitoring reports.

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 18

 IS Audit/Assurance Program
IT Risk Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/St Workpaper Fail Comments
andards
1. Determine if the following documents include the necessary activities to manage IT risk: EDM03;
- Information Security Policy APO12
- Crisis Management Policy
- Third-party IT Service Delivery Management Policy
- Business Continuity Policy
- Program/Project Management Policy
- HR Policies
- Compliance Policy
- Quality Management Policy
- Service Management Policy
- Change Management Policy
- Delegation of Authority Policy
- Whistle Blower Policy
- Internal Control Policy
- Intellectual Property Policy
- Data Privacy Policy

(c) 2016 ISACA All Rights Reserved IT Risk Management, Page 19