Firm Basel II risk management requirements needed now more than ever

Basel II experts say that stricter risk management rules and regulations for banks are just around the corner.

This tip is part of our Basel II risk management and implementation guide.

Since the final touches were put to the Basel II accord in 2003, the banking world has changed, to put it mildly.

By the time the accord came into force in Europe in early 2008 (and was due to be rolled out in the U.S. this year), the financial system was already starting to look rocky. Now, with the whole banking system still reeling from the repercussions of the subprime mortgage market's collapse, and with governments bailing out institutions around the world, the need for Basel II may be stronger than ever.

The Basel II accord was created to safeguard the financial system by ensuring banks and other financial organisations would have enough cash reserves to cover any risks and contingencies that might beset them. The accord focused on risk management and worked on the basis that if companies demonstrated they had sufficient controls in place to manage risk, then they would need less cash in reserve. By contrast, companies with poor controls ran greater risks, and would therefore need to hold a larger amount in cash.

Whether the seismic failure of the banking system worldwide could have been averted if the Basel II rules were implemented earlier is hard to say, but most experts agree that once the dust settles on the current financial chaos, Basel II is likely to be strengthened. And for anyone working the financial world, that will mean having to comply with more regulations.

Basel II and operational risk management
Although the accord deals with a range of risks, including market and credit risk, its requirements dealing with operational risk will most interest and affect information security professionals.

Unlike standards such as the Payment Card Industry Data Security Standard (PCI DSS), which spells out in detail what kind of measures should be deployed to protect credit card information, the Basel II accord merely states that operational risk is "the risk of direct or indirect loss resulting from inadequate or failed internal processes, people, and systems or from external events."

The Joint Forum of the Basel Committee produced a paper in 2003 called "Risk Management Principles for Electronic Banking," and in 2006, another called "High Level Principles of Business Continuity," but they both avoided any detailed prescriptive measures.

Since most of a bank's assets are held in digital form, many of the risks that could affect a bank will come from its IT systems. But with Basel's rules being so vague, IT security professionals have largely been left to deduce what they would mean in technical terms and formulate their own strategies.

Spelling out Basel II requirements
Given the economic problems of the last few months, some argue that more detailed, prescriptive rules are necessary. Rolf von Roessing, member of the Information Systems Audit and Control Association (ISACA)'s Security Management Committee and author of a paper entitled "IT Control Objectives for Basel II," said moves are afoot to provide more detailed guidance.

He and others say that work is already being done by those associated with the Basel committee to beef up the rules and make IT requirements more specific than they have been up to now. "I believe it will be more prescriptive with regard to information security," he said.

That view is supported by Brian Cleary, head of marketing at U.S. consultancy Aveksa Inc., which specialises in IT governance. "Basel 3 is needed on multiple fronts," he said. "Basel II does not include any technical definitions around areas like patch management, vulnerability management and reporting. It refers to other best practices such as ITIL, COBIT and ISO."

Cleary adds that a new version of Basel will need more prescriptive risk management controls to address areas related to process, function and job tasks, and also where IT controls will need to be put into place.

"Some of the controls will be fashioned around the COSO framework for risk management," he said. "They will prescribe things like separation-of-duties controls between back to mid- to front- office, for example."

Cleary draws a comparison with the U.S. Sarbanes-Oxley Act (SOX), which specifies a tight set of segregation-of-duty controls to prevent potential fraud. "Nowhere in Basel," he said, "does it get to that level of detail."

"No one on the front office should have access to mid- and back-office systems," Cleary adds. "The potential for fraud and misuse could hurt the bank, the brokerage firm or the wealth-management firm."

Cleary predicts that details of a new Basel accord will be made public as early as the G20 meeting of the world's leading 20 economies, which is due to take place in London in the first week of April.

The current state of Basel II requirements and security practices
In the absence of prescriptive controls, ISACA produced a list of IT Guiding Principles (see below), which Von Roessing describes as a "mirror image" of the Basel risk management controls, interpreted for the IT world.

In doing presentations to bank IT professionals around the world, he said he carried out straw polls to see which of the 10 principles are currently adopted in their organisations. His queries have uncovered glaring holes, particularly in areas of risk management and assessment, and also business continuity. "We found a lot of gaps. Business continuity management was one area -- not many people were aware that Basel expressly requires that," he said.

Proper control of identity and access management was also lacking among financial institutions. "[IAM] is not terribly well-implemented" he added. "In day-to-day practice, this is one of the biggest gaps."

Many organisations still struggle to keep up with provisioning and de-provisioning of users, Von Roessing notes, and when people change jobs within an organisation, they often retain the access rights associated with their prior position.

Some of the most notorious banking scandals, including Societe Generale's January 2008 fraud incident, involved individuals gaining access to systems they should not have been able to use, Roessing said.

In the absence of detailed requirements in Basel (for now at least), companies are best advised to adopt a ready-made framework, according to George Thompson, a director at management consultancy KPMG.

ISO 27001 provides a good template for operational security, Thompson said. "If you follow the standard in your management processes for information security, you will end up with a demonstrable system of control that the Financial Services Authority would be happy with, as would the people running Basel," he said.

The key, Thompson said, is to approach the process of implementing ISO 27001 with a view to improving the business rather than simply gaining ISO certification.

"You need to live and breathe the approach rather than just looking to get ticks in the boxes," he added. "If people follow within the spirit of the standard, that is probably adequate."

ISACA's Ten IT Guiding Principles

  • ITGP1 (Operational risk awareness) Information management and technology form a critical part of operational risk management. Practitioners, internal auditors and financial services experts should be aware of the significance of information risk.
  • ITGP2 (Internal audit requirement) The internal IT audit function should be effective and comprehensive. Skills, resources and funding should be adequate to ensure audit effectiveness.
  • ITGP3 (Management policies, processes, procedures) Information management and technology should be governed by an adequate set of policies, processes and procedures for risk management. The guidance given to practitioners, internal auditors and financial services experts should be in line with the organization's GRC framework.
  • ITGP4 (Risk assessment) In information management and technology, specific risk assessments should be conducted, using approved methods in line with the organization's GRC framework. Risk assessments should take into consideration the technology-specific complexity and indirect risk factors.
  • ITGP5 (Risk and loss monitoring) Losses related to information management and technology should be measured and documented. Specific risk profiles should be monitored.
  • ITGP6 (Control and mitigation policies, processes, procedures) Information management and technology should be governed by an adequate set of policies, processes and procedures for risk control and mitigation. The guidance given to practitioners, internal auditors and financial services experts should be in line with the organization's GRC framework.
  • ITGP7 (Business continuity management) Information management and technology should be protected by a comprehensive continuity management process. The IT continuity management process should be in line with the organizationwide business continuity management framework.
  • ITGP8 (Framework for risk control and mitigation) Information management and technology should be an integral part of the organization's GRC framework. Control and mitigation of information-related risks should be defined and recognized in the GRC framework.
  • ITGP9 (Independent evaluation) Information management and technology-related risks shall be adequately documented to support the supervisory review process. An independent audit function should perform reviews of IT-related operational risk management in line with the operational and information risk profile.
  • ITGP10 [Disclosure] Practitioners, internal auditors and financial services experts should identify all information-related risks that may be subject to disclosure. These risks should be communicated to stakeholders as defined by the organization's GRC framework. Corrective action should be taken when appropriate.
  • Read more on Regulatory compliance and standard requirements