Basel II - managing IT risk

Financial services organisations are facing new challenges presented by the Second Capital Accord defined by the Basel Committee on Banking Supervision, colloquially known as " Basel II." The accord builds on an embryonic framework for managing risk in banking and financial services transactions.
In contrast to the first Capital Accord of 1998, information risk and information technology have become critical factors in shaping modern business, and many financial services organisations have undergone a fundamental transformation in terms of IT infrastructure, applications, and It-related Internal Controls.
Corporate Governance, Risk management and regulatory Compliance (GRC) have evolved as top business priorities. A new evolution in business is being driven by increased stakeholder demands, heightened public analysis and new performance potential. The trend toward improvement in corporate governance is seen in many initiatives.
Operational risk is regarded as a particularly important risk category, as witnessed by a vast number of incidents and crisis over the past decade. The risk inherent to banking operations and conducting ordinary business is often more diverse than the comparatively narrow areas covered by other categories, such as interest rate risk.
However, identifying and measuring operational risk has proved to be a fearsome challenge to banks and financial services organisations. Information technology and information management are key elements. IT related components such as applications, infrastructure elements and controls are all defined as parts of operational risk.
In order to adequately address information-related risks, a business-driven approach is required. Business processes drive the definition of controls and metrics, while the set of IT-related controls are complemented by a set of indicators to measure compliance and maturity, that includes the use of KPI (Key Performance Indicators) and, KGI (Key Goal Indicators).
Where an information-related risk has an impact on the business process, steps toward reducing and mitigating the risk are integral parts of the organisation's GRC framework. Managing information risk in a Basel context requires an adoption of known Frame Work of IT processes, controls and related activities (ISO 27001, COBIT, ITIL, SOX, COSO etc).
Information and information technology management require a specific approach toward GRC. The complexity of an IT environment, its interdependencies with business processes and the need to identify and address indirect risks and decisive factors in defining and developing an IT risk framework.
Risk evolution, control and mitigating factors must be aligned with overall operational risk approach that the organisation has selected under BASEL II. These leads to a corresponding set of guiding principals for managing information management and information technology risks.
Information management and technology form a critical part of operational risk management. Practitioners, internal auditors, IT auditors, External auditors and financial services experts should be aware of the significance of information risk.
Organisation should be aware of the operational risks due to IT components and, thus, the capital charge; IT components require definition and in-depth understanding. Awareness should not be restricted to the fact that there is an existing IT risk, and all GRC-related objectives and practices should be aligned with the organisational GRC framework.
The importance of internal audit, in general, should be reflected in the setup and functioning of the Internal IT audit, or information risk audit. The size and complexity of the financial organisation under review should determine the skills, resources, and funding of the internal audit function.
This may include the use of specialist external audit resources where internal resources cannot provide an adequate level of coverage and effectiveness. Internal IT audit should have ultimate accountability to the organisation's audit committee, and report to the board as appropriate. It should be noted that internal IT audit must be impartial and independent with regard to the organisation's management.
Managing governance, risk management and compliance requires a clearly defined and documented set of policies, processes and procedures. These should match the overall structure and order of general policies on GRC. IT policies should be specific and targeted in their scope and contents. This is a guiding principal and requirement for a risk management process, as distinct from risk-related controls.
Operational risk disciplines relate to the management of operational risk only, as distinct from the risk functions that are responsible for the management of other types of risk. This means that the work done on operational risk by the credit or market risk management functions do not become credit or market risk disciplines. Similarly, an operational risk breakdown within the credit or market risk management function does not become a credit or market risk breakdown.
This principal is particularly important for the information technology function within a financial services organisation. In order to understand IT risk and related factors, the risk management methods selected should provide an in-depth understanding of both direct and indirect risk. Any risk assessment conducted should cover the risks intrinsic to IT, and risks induced by the use of information technology.
Technology related losses should be monitored in line with the overall loss monitoring implemented by the organisation. Risk profiles should adequately reflect the complexity of technology and its use with financial services organisations.
The organisation must have a clearly defined understanding of its risk appetite, of how much risk the entity is agreeable to assume. Risks or events falling outside the defined risk appetite are identified for immediate corrective action. Incident responsibilities need to be assigned in line with the organisation's incident management and escalation policies.
These policies should also define a process for notification so that the chief executive officer, the chief risk officer, the chief information security officer, internal auditor and the board risk and audit committees are aware of significant incidents and the risk they represent.
The quality data must possess following attributes:
-- Accuracy
-- Integrity
-- Consistency
-- Completeness
-- Validity
-- Timeliness
-- Accessibility
-- Use-ability
-- Audit-ability, the commitment to data quality needs to be driven from top.
For risk control and mitigation, policies, processes and procedures should be implemented as a complement to management policies. This may include specific processes for control and measurement, mitigation procedures for individual risks, and other guidance to provide comprehensive coverage of risks in information technology and management. Risk control and mitigation should be seen as distinct from overall risk management process.
IT continuity, incident management and recovery are all components of a comprehensive IT continuity management process. It is essential that the management of IT continuity be aligned with overall business continuity in order to enable the continuation of IT and core business performance under adverse circumstances. High-level principals of business continuity in financial services organisations have been documented by the Basel Committee.
The principals stipulate that an organisation shall design and implement a business continuity management (BCM) process with senior management responsibility for implementation and monitoring.
IT related risk control and mitigation plans and activities should be designed, implemented and monitored in accordance with GRC framework. Ant technology-related measures should be recognised as a separate and distinct type of risk in GRC framework. Any technology related measures should be recognised as a separate and distinct type of risk in the GRC. This may include organisational management, individual controls and guidance on compliance.
The underlying assumption of enterprise risk management (ERM) is that every entity exists to provide value to its stakeholders. All entities face uncertainty and the challenge for management is to determine how much uncertainty to accept as it strives to grow stakeholder's value. Uncertainty presents both risk and opportunity, with the potential to erode or enhance value. ERM enables management to effectively deal with uncertainty and associates risk and opportunity, enhancing the capacity to build value.
Information-related risks require documentation in line with requirements of the supervisory review process in order to enable and support this process. Documentation should be subject to impartial and independent review, including external reviews at regular intervals. Audits and independent reviews of the IT risk documentation should be aligned with the risk profile defined by the organisation. Organisation should adopt a holistic capability maturity assessment of their ERM, where "capability" is how well a discipline or process works and "maturity" is a measure of how far the capability has developed. Each component of the ERM framework is assessed against the Six "Stages of Control Reliability", as shown below:
0- Non-existent
1- Initial
2- Repeatable but intuitive.
3- Defined
4- Managed & measureable
5- Optimised
The organisation's ERM capability framework must be assessed and managed "bottom-up" and "top-down". ERM needs to be an integrated framework, therefore the capability maturity assessment must determine weak points which could potentially undermine the whole ERM framework, such as data quality in monitoring, role clarity, tools and people skills.
Risks, deficiencies and other issues identified within the organisation shall be evaluated and assessed with regard to their severity and significance. Where an individual risk, or more than one risk in combination, may lead to operational losses that require disclosure, this information must be communicated to stakeholders as appropriate. This escalation should be clearly defined in the overall GRC framework.
Operational risk is easily recognised, but difficult to comprehensively define. Risk factors may be found anywhere in the operation of a financial services organisation. Potential losses may arise from failure in one or more areas of the organisation that would not normally be considered profit centers or value contributors. IT is a significant component of operational risk and is, therefore, a part of the capital charge attributed to operational risk.
The definition of operational risk looks very broadly at causes since this provides an effective mechanism for classifying events.
Causes include:
-- Processes - Caused from a firm's execution of business operations
-- People - Caused by employee error or misdeeds
-- Systems - Resulting from a disruption of services.
-- External events - Caused by natural and un-natural events.
Cause classification types can be used as a starting point for managing operational risk, especially regarding the mitigation, transfer or avoidance of risk. To provide greater clarity and differentiation that is useful in managing IT risk, the four main types of causes should be broken down into three levels of cause categories. This is especially important since, in practice, risks are often attributed to more than one cause, but should only be allocated to one classification type.
EXAMPLE 1: An insider exploiting a programming error in an internal application should be categorised in the cause category systems, whereas an intruder obtaining access to a bank's computer hacking tools, phishing or malware would be categorised under External Events.
EXAMPLE 2: A fire occurring in a data center destroys IT systems, resulting in IT being unable to support business activities. Taking the Basel cause and loss event categories, this would be categorised as an External Event and the category would be Damage to Physical Assets/disaster.
-- Looking at the cause chain, the main elements of this risk event would be:
-- External event (fire) -> disaster (fire in the data center) -> damage to physical assets (IT system destroyed) -> business disruption (business processes not available)
It is apparent that this comparatively simple risk event already links to two Basel loss event type: Damage to Physical Assets, and Business Disruption and System Failures. The business disruption in itself is attributable to the cause category Systems, if only this loss event type of the chain is addressed. If the fire was caused by an electrician who improperly connected two power cables, a third category would be added: People.
Basel II requires financial services organisations to use scenario analysis and expert opinion in conjunction with external data in order to evaluate their exposure to high-severity, infrequent events. The Scenario analysis approach brings experienced business managers and risk management experts together to derive reasoned assessment of plausible severe losses.