1. IT Risks and Controls
Revised on 2015

2. Content Risk definition Categories of Enterprise Risk IT Risk
IT Risk Categories
Risk IT Framework
Risk IT Principles
Risk IT Domains
Audit Risk
Internal Control
Objectives of internal controls
Types of internal controls
Elements of internal controls
Categories of IT internal controls
Relationship between IT application and general controls
CISB424, Sulfeeza

3. Introduction
IT and other internal auditors need to identify all of the business risks they face in their review activities – IT, financial, operational as well as social, ethical and environmental risks, and to assess that these risks are managed at an acceptable level.
IT auditors need to have an understanding of risk management and how it impacts their approaches for assessing or developing effective internal controls.
(Moeller, 2012, pp 82)
CISB424, Sulfeeza

4. Risk
So, what is risk?
There is no standard definition of risk that is accepted in the industry.
As such, for the sake of this class, we will adopt the definition of risk by ISO as:
“Effect of uncertainty on objectives”
Where
Effect is a positive or negative deviation from what is expected
Uncertainty is a state or condition that involves a deficiency of information and leads to inadequate or incomplete knowledge or understanding
CISB424, Sulfeeza

5. Enterprise Risk Sometimes is also called as business risk
A probable situation with uncertain frequency and magnitude of loss (or gain)
(Source: ISACA)
Organizations need to find ways or approaches so that their business risks can be minimized, through adopting a systematic enterprise risk management, which is defined as:
The process which aims to help organizations to understand, evaluate and take action on all their risks with a view to increasing the probability of success and reducing the likelihood of failure
(Source: Institute of Risk Management)
CISB424, Sulfeeza

6. Enterprise Risk Categories
CISB424, Sulfeeza
Source: Moeller, 2009, pp 117

7. IT Risk So, what is IT risk? IT risk is business risk—specifically,
the business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise.
It consists of IT-related events that could potentially impact the business.
It can occur with both uncertain frequency and magnitude, and it creates challenges in meeting strategic goals and objectives.
IT risk always exists, whether or not it is detected or recognized by an enterprise
(Source: ISACA)
CISB424, Sulfeeza

8. IT Risk Categories
IT benefit/value enablement risk – associated with (missed) opportunities to use technology to improve efficiency and effectiveness of business processes, or as an enabler for new business initiatives
IT program and project delivery risk – associated with the contribution of IT to new or improved business solutions, usually in the form of projects and program
IT operations and service delivery risk – associated with all aspects of the performance of IT systems and services, which can bring destruction or reduction of value to the enterprise
(Source: ISACA)
CISB424, Sulfeeza

9. IT Risk Categories
(Source: ISACA)
CISB424, Sulfeeza

10. Risks IT Framework
The Risk IT framework is developed by ISACA, which is based on the principles of enterprise risk management (ERM) standards/ frameworks such as COSO ERM and ISO and provides insight on how to apply this guidance to IT.
Although Risk IT aligns with major ERM frameworks, the presence and implementation of these frameworks is not a prerequisite for adopting Risk IT.
By adopting Risk IT enterprises will automatically apply all ERM principles.
(Source: ISACA)
CISB424, Sulfeeza

11. Risks IT Framework
In this hierarchy, IT risks are regarded as a component of the overall risk universe of the enterprise
(Source: ISACA)
CISB424, Sulfeeza

12. Purpose of Risks IT Framework
The Risk IT Framework explains IT risk and enables users to:
Integrate the management of IT risk into the overall ERM of the enterprise, thus allowing the enterprise to make risk-return-aware decisions
Make well-informed decisions about the extent of the risks, and the risk appetite and the risk tolerance of the enterprise
Understand how to respond to the risk
(Source: ISACA)
CISB424, Sulfeeza

13. Risks IT Principles
Risk IT is based on a number of guiding principles for effective management of IT risk.
The principles are based on commonly accepted ERM principles, which have been applied to the domain of IT.
The Risk IT process model is designed and structured to enable enterprises to apply the principles in practice and to benchmark their performance
(Source: ISACA)
CISB424, Sulfeeza

14. Risks IT Principles
(Source: ISACA)
CISB424, Sulfeeza

15. Risk IT Domains There are three (3) domains in the Risk IT Framework
Risk Governance
Risk Evaluation
Risk Response
(Source: ISACA)
CISB424, Sulfeeza

16. Risk IT Domains
(Source: ISACA)
CISB424, Sulfeeza

17. 1) Risk Governance Domain
The goal of risk governance:
Ensure that IT risk management practices are embedded in the enterprise, enabling the enterprise to secure optimal risk-adjusted return
The metrics to assess risk governance:
The degree to which the strategic use of IT in leveraging enterprise resources reduces overall enterprise risks
(Source: ISACA)
CISB424, Sulfeeza

18. 1) Risk Governance Domain
(Source: ISACA)
Integrate the IT risk strategy and operations with the business strategic risk decisions that have been made at the enterprise level
Process 2
Integrate with ERM
Process 1
Establish and maintain a common risk view
Process 3
Make a risk-aware business decisions
CISB424, Sulfeeza
Ensure that risk management activities align with the enterprise’s objective capacity for IT-related loss and leadership’s subjective tolerance of it
Ensure that enterprise decisions consider the full range of opportunities and consequences from reliance on IT for success

19. 1) Risk Governance Domain
Risk appetite is the amount of risk an entity is prepared to accept when trying to achieve its objectives.
When considering the risk appetite levels for the enterprise, two major factors are important:
The enterprise’s objective capacity to absorb loss, e.g., financial loss, reputation damage
The (management) culture or predisposition towards risk taking— cautious or aggressive. What is the amount of loss the enterprise wants to accept to pursue a return?
Risk appetite can be defined in practice in terms of combinations of frequency and magnitude of a risk.
Risk tolerance is the tolerable deviation from the level set by the risk appetite and business objectives
E.g., standards require projects to be completed within the estimated budgets and time, but overruns of 10 percent of budget or 20 percent of time are tolerated.
(Source: ISACA)
CISB424, Sulfeeza

20. 1) Risk Governance Domain
Risk appetite map
(Source: ISACA)
CISB424, Sulfeeza

21. 2) Risk Evaluation Domain
The goal of risk evaluation:
Ensure that IT-related risks and opportunities are identified, analyzed and presented in business terms.
The metrics to assess risk evaluation:
The cumulative business impact from IT- related incidents and events not identified by risk evaluation processes
(Source: ISACA)
CISB424, Sulfeeza

22. 2) Risk Evaluation Domain
(Source: ISACA)
Develop useful information to support risk decisions that take into account the business relevance of risk factors.
Process 2
Analyze risk
Process 1
Collect data
Process 3
Maintain risk profile
Maintain an up-to-date and complete inventory of known risks and attributes IT resources, capabilities and controls as understood in the context of business products, services and processes.
CISB424, Sulfeeza
Identify relevant data to enable effective IT-related risk identification, analysis and reporting.

23. 2) Risk Evaluation Domain
Meaningful IT risk assessments and risk-based decisions require IT risk to be expressed in unambiguous and clear, business-relevant terms.
Effective risk management requires mutual understanding between IT and the business over which risk needs to be managed and why. This means that:
An IT person should understand how IT-related failures or events can impact enterprise objectives and cause direct or indirect loss to the enterprise
A business person should understand how IT-related failures or events can affect key services and processes
The link between IT risk scenarios and ultimate business impacts needs to be established to understand the effects of adverse events
(Source: ISACA)
CISB424, Sulfeeza

24. 2) Risk Evaluation Domain
One of the methods that can be used to help organizations to describe IT risks in business terms is Balanced-Scorecard (BSC) approach by Kaplan and Norton.
In BSC, four business elements are assessed:
Financial – Tracks the financial requirements and performance of the organizations
Customer – Measures the customers' satisfaction and their performance requirements
Internal Business – Measures the critical business processes, their requirements and measures
Learning and Growth – Focuses on how you educate your employees, how you gain and capture your knowledge, and how you use it to maintain a competitive edge within your markets
(Source: ISACA; Hannabarger, Buchman & Peter)
CISB424, Sulfeeza

25. 2) Risk Evaluation Domain
(Source: Ernst & Young)
CISB424, Sulfeeza

26. 2) Risk Evaluation Domain
Key risk indicator (KRI)
Metric that shows that the organization is “foreseen”, or is “foreseen” to have high probability of facing risk that exceeds the defined risk appetite.
Criteria for choosing KRI:
Impact – those with high business impact
Effort to implement, measure and report – those that are easy to implement and measure
Reliability – good predictor of the risk
Sensitivity – Representative of the risk and capable of accurately indicating variances in the risk (Source: ISACA)
CISB424, Sulfeeza

27. 2) Risk Evaluation Domain
IT risk scenarios can be used in identifying the important and relevant IT risks.
A description of an IT-related event that can lead to a business impact, when and if it should occur
Components of risk scenario
(Source: ISACA)
CISB424, Sulfeeza

28. 2) Risk Evaluation Domain
Actor who generates the threat
Internal actors (within the org) – staff, third party contractors
External actors (outside the org) – competitors, regulators, market
Threat type – the nature of threat
Event – what is it actually
Asset/resource on which the scenario acts
Asset - any object of value to the enterprise that can be affected by the event and lead to business impact
Resource – anything that helps to achieve IT goals
Timing
(Source: ISACA)
CISB424, Sulfeeza

29. 2) Risk Evaluation Domain
Once the set of risk scenarios is defined, it can be used for risk analysis, where frequency and impact of the scenario are assessed. An important component of this assessment is the risk factors
Risk factors are those factors that influence the frequency and/or business impact of risk scenarios
Risk factor categories:
Environmental factor – degree of control that an org has
Internal environmental factor – under the control of the org
External environmental factor – outside the control of the org
Capabilities – how good the organization is in IT-related activities
IT risk management – To what extent is the organization mature in performing the risk management processes?
IT capabilities – How good the organization in performing the IT processes?
IT related business capabilities
(Source: ISACA)
CISB424, Sulfeeza

30. 3) Risk Response Domain The goal of risk response:
Ensure that IT-related risk issues, opportunities and events are addressed in a cost-effective manner and in line with business priorities.
The metrics to assess risk response:
The cumulative business impact from IT- related incidents and events anticipated by risk evaluation processes but not yet addressed by mitigation or event action planning
(Source: ISACA)
CISB424, Sulfeeza

31. Ensure that measures for seizing immediate
3) Risk Response Domain
(Source: ISACA)
Ensure that measures for seizing strategic opportunities and reducing risk to an acceptable level are managed as a portfolio.
Process 2
Manage
risk
Process 1
Articulate
risk
Process 3
React to events
Ensure that measures for seizing immediate
opportunities or limiting the magnitude of loss from IT-related events are activated in a timely manner
and are effective.
CISB424, Sulfeeza
Ensure that information on the true state of IT-related exposures and opportunities is made available in a timely manner and to the right people for
appropriate response.

32. 3) Risk Response Domain
The purpose of defining a risk response is to bring risk in line with the defined risk appetite after risk analysis
In other words, it means:
A response needs to be defined such that future residual risk (current risk with the risk response defined and implemented) is, as much as possible (usually depending on budgets available), within risk tolerance limits
There are four (4) ways on how to respond to risk:
Risk avoidance
Risk reduction/mitigation
Risk sharing/transfer
Risk acceptance
(Source: ISACA)
CISB424, Sulfeeza

33. 3) Risk Response Domain Risk avoidance Risk reduction/mitigation
Exiting the activities or conditions that give rise to risk.
Risk avoidance applies when no other risk response is adequate
Risk reduction/mitigation
Action taken to detect the risk, followed by action to reduce the frequency and/or impact of a risk
Risk sharing/transfer
Sharing means reducing risk frequency or impact by transferring or otherwise sharing a portion of the risk. Common techniques include insurance and outsourcing.
Risk acceptance
No action is taken relative to a particular risk, and loss is accepted when/if it occurs.
(Source: ISACA)
CISB424, Sulfeeza

34. 3) Risk Response Domain
Criteria in selecting and prioritizing risk response:
Cost of the response
Importance of the risk addressed by the response (based on its position on the risk map)
Capability to implement response
Effectiveness of response
Efficiency of response
(Source: ISACA)
CISB424, Sulfeeza

35. Audit Risks What is audit risk?
The risk of reaching an incorrect conclusion based upon audit findings
There are three (3) components of audit risk:
Control Risk
Detection Risk
Inherent Risk
(Source: ISACA)
CISB424, Sulfeeza

36. Audit Risks Control Risk
The risk that an error could occur in an audit area and could be material, individually or in combination with other errors, will not be prevented or detected and corrected on a timely basis by the internal control system.
Example:
The control risk associated with the reviews of computer logs can be high because the volume of logged information.
(Source: ISACA)
CISB424, Sulfeeza

37. Audit Risks Detection Risk
The risk that professionals’ substantive procedures will not detect error that could material, individually or in combination with other errors
Example:
The detection risk associated with identifying breaches of security in an application system ordinarily is high because logs for the whole period of audit are not available at the time of audit
(Source: ISACA)
CISB424, Sulfeeza

38. Audit Risks Inherent Risk
The susceptibility (vulnerability) of an audit area to err (make mistake) in a way that could be material, individually or in combination with other errors, assuming that there were not related internal controls
Inherent risks exist independent of the audit and can occur because of the nature of the business.
Example:
Complex database updates are more likely to be miswritten than simple database updates
Thumb drives are more likely to be stolen (misappropriated) than blade servers in a server cabinet. 
(Source: ISACA, InfoSec Institute)
CISB424, Sulfeeza

39. Internal Control
Internal control is a process, affected by an entity’s board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in the following categories:
Effectiveness and efficiency of operations
Reliability of financial reporting
Compliance with applicable laws and regulations
(Source: COSO)
CISB424, Sulfeeza

40. Objectives of IT Internal Control
Reliability and integrity of information
Compliance with policies, plans, procedures, laws and regulations
Safeguarding assets
Effectiveness and efficiency of operations
CISB424, Sulfeeza

41. Types of Internal Control
Preventive controls – Steps designed to keep errors or irregularities from occurring in the first place
Detective controls – steps designed to detect errors or irregularities that may have occurred
Corrective controls - steps designed to correct errors or irregularities that have been detected
Directive controls – steps designed to produce positive results and encourage acceptable behaviors
Compensating controls – a weakness in one control may be compensated by another control elsewhere
(Source: Cascarino, 2012;
CISB424, Sulfeeza

42. Elements of Internal Control
Management must ensure the followings when designing internal controls:
Segregation of duties
Competence and integrity of people
Appropriate level of authority
Accountability
Adequate resources
Supervision and review
(Source: Cascarino, 2012)
CISB424, Sulfeeza

43. Limitations of Internal Control
Judgment - the effectiveness of controls will be limited by decisions made with human judgment under pressures to conduct business based on the information available at hand.
Breakdowns - even well designed internal controls can break down. Employees sometimes misunderstand instructions or simply make mistakes. Errors may also result from new technology and the complexity of computerized information systems.
Management Override - high level personnel may be able to override prescribed policies or procedures for personal gains or advantages. This should not be confused with management intervention, which represents management actions to depart from prescribed policies and procedures for legitimate purposes.
Collusion - control system can be circumvented by employee collusion. Individuals acting collectively can alter financial data or other management information in a manner that cannot be identified by control systems.
(Source:
CISB424, Sulfeeza

44. Categories of IT controls
Objectives of IT controls are related to the confidentiality, integrity, availability of data and the overall management of IT function in an organization
Confidentiality
The principle of least privilege – a person should only have access to the data, systems, hardware, etc. that they need to be able to do their job, no more. 
This access should be reviewed periodically, no less than annually and by all means when a change of employment occurs.
Who has access to the hardware (logical or physical?) 
Who has access to the data and are they authorized to make changes to the data? 
Who’s reviewing those changes to the data to see if the change was authorized? 
 (Source: Wikipedia, InfoSec Institute)
CISB424, Sulfeeza

45. Categories of IT controls
Integrity
The data or information processed and produced by the system is valid and accurate (i.e. not being tampered with)
3. Availability 
The data and/or system is available when it is needed
 (Source: Wikipedia, InfoSec Institute)
CISB424, Sulfeeza

46. Categories of IT controls
IT controls can be categorized as:
IT general controls
IT application controls
(Source: Wikipedia)
CISB424, Sulfeeza

47. IT General Controls
IT general controls are those controls within the IT processing environment that provide reliability and availability of data (e.g., information security and change management controls, IT operations and job scheduling controls).
As such, failures or breakdowns in IT general controls can have a significant impact on the effectiveness of the application controls.
A strong system of IT general controls can enable more reliance on automated application controls, whereas a less reliable system of IT general controls may suggest that greater emphasis should be placed on manual controls.
(Source: Cascarion, 2012, ISACA)
CISB424, Sulfeeza

48. IT General Controls
Helps to ensure the reliability and availability of data generated by reviewing the controls that are present in the environment surrounding the information systems
Areas included:
IT Organizational Structure
Computer operations
Physical security
Logical security
Program change control
Systems development
(Source: Cascarion, 2012, Wikipedia)
CISB424, Sulfeeza

49. IT Application Controls
The policies, procedures and activities designed to provide reasonable assurance that objectives relevant to a given automated solution are achieved.
Application control objectives:
Completeness—The application processes all transactions and the resulting information is complete.
Accuracy—All transactions are processed accurately and as intended and the resulting information is accurate.
Validity—Only valid transactions are processed and the resulting information is valid.
Authorization—Only appropriately authorized transactions have been processed.
Segregation of duties—The application provides for and supports appropriate segregation of duties and responsibilities as defined by management
(Source: ISACA)
CISB424, Sulfeeza

50. IT Application Controls
The control practices that can be implemented:
1. Source data preparation and authorization
Ensure that source documents are prepared by authorized and qualified personnel following established procedures, taking into account adequate segregation of duties regarding the origination and approval of these documents.
Errors and omissions can be minimized through good input form design.
Detect errors and irregularities so they can be reported and corrected.
(Source: ISACA)
CISB424, Sulfeeza

51. IT Application Controls
The control practices that can be implemented:
2. Source data collection and entry
Ensure that data input is performed in a timely manner by authorized and qualified staff.
Correction and resubmission of data that were erroneously input should be performed without compromising original transaction authorization levels.
Where appropriate for reconstruction, retain original source documents for the appropriate amount of time.
(Source: ISACA)
CISB424, Sulfeeza

52. IT Application Controls
The control practices that can be implemented:
3. Accuracy, completeness and authenticity checks
Ensure that transactions are accurate, complete and valid.
Validate data that were input, and edit or send back for correction as close to the point of origination as possible.
4. Processing integrity and validity
Maintain the integrity and validity of data throughout the processing cycle.
Detection of erroneous transactions does not disrupt the processing of valid transactions.
(Source: ISACA)
CISB424, Sulfeeza

53. IT Application Controls
The control practices that can be implemented:
5. Output review, reconciliation and error handling
Establish procedures and associated responsibilities to ensure that output is handled in an authorized manner, delivered to the appropriate recipient and protected during transmission; verification, detection and correction of the accuracy of output occur; and information provided in the output is used.
(Source: ISACA)
CISB424, Sulfeeza

54. IT Application Controls
The control practices that can be implemented:
6. Transaction authentication and integrity
Before passing transaction data between internal applications and business/ operational functions (within or outside the enterprise), check the data for proper addressing, authenticity of origin and integrity of content.
Maintain authenticity and integrity during transmission or transport.
(Source: ISACA)
CISB424, Sulfeeza

55. Relationship between IT Application & General Controls
(Source: ISACA)
CISB424, Sulfeeza