BCP for Thailand's volcanoes

The Bank of Thailand (BoT) released a BCM/BCP policy for financial institutions in January 2007.

This is the 15-page English version of BOT Notification No. 118-2550 (23-01-07) from Thailand's Foreign Bankers' Association and this is the Thai version .

The deadline to comply is January 2008.

This final policy does not differ significantly from BoT's proposed BCM guidelines of September 2006. BoT requires board-level involvement, identification and recovery plans for "Critical Business Functions", writing plans and testing them.

An appendix (page 15) to the policy lists 16 "Examples of Disruptive Events" in these categories: natural, reputation, economy/physical, human resources and man-made. Tsunami is listed, of course, but so are "volcanic eruption" and "hostage taking".

Are there volcanoes in Thailand?

Limiting planning to "Critical Business Functions" - defined in the policy as those that could "significantly impact operations, business, reputation, status and performance" – is a mistake, in my opinion.

A business continuity plan should cover all functions of a bank or any other enterprise. Some functions are "critical", others aren't, as determined from a business impact analysis (BIA).

For example: in a bank, is compliance critical? Is it critical in a disaster? Not in the first week after a tsunami, surely. But 90 days after a disaster, wouldn't BoT (and the Board of Directors of the bank) think it important (if not critical) that someone have a look at the bank's recent Treasury transactions and the deals made by the traders? If so, Compliance will need a recovery strategy and a continuity plan.

A low initial impact of failure doesn't mean that a function should be excluded from a BCP. Most functions become important, if not critical, at some point. That's why the functions exist in the first place.

Regulators and planners everywhere should expect banks to identify and list all business functions, and develop continuity plans for all of them - even if the strategy that eventually results is to suspend the function after a disaster.