Key elements of BC/DR planning
According to DisasterRecovery.org, an independent organisation that provides guidance and information on disaster recovery, a plan must include the following stages:
A policy statement, stating the goal of the plan, the reasons for it and the resources required.
A risk assessment will identify the situations that are most likely to occur.
A business impact analysis, describing how a catastrophic event may impact the business practically, financially and in other ways. It should also try to identify any preventive steps that can be taken.
Recovery strategies must explain how and what needs to be recovered and with what priority/speed.
The plan development stage will require documentation of the plan and implementation of elements as required.
Plan buy-in and testing is essential to ensure everyone knows and understands what the BC/DR plan is, what to do and when.
Plan maintenance and testing is important to ensure it is relevant and that it works.
Whilst third-party system vendors should be included in any BC/DR planning process to ensure they have the capacity to deliver when they are needed most, they should not be seen as a ‘get out of jail free’ card. Asking the right questions of them is an essential part of taking responsibility for DR/BC planning. Key points to raise (and include in any Service Level Agreement) would include: how long will it take to recover operations following an event (referred to as the Recovery Time Objective), how much data could potentially be lost (Recovery Point Objective) and the reliability (proven up-time) of the platform.
The core technology vendor
Properly executing, these stages can provide a business with reassurance that it is prepared for the worst. However, a common problem, says Reval’s Pettinato is that within a company there is often no clear ownership of DR. “A lot of business operations people – including treasury – think IT will take care of it,” he notes. Whilst this may be the case, those IT people may not always fully understand how critical each business operation is. This suggests a lack of co-ordination which, when creating a plan, is unhelpful at best. “Each business operation is responsible for ensuring it has a clear plan but that does not mean it can build and execute it on its own,” states Pettinato.
Of course, a SaaS-based TMS provider such as Reval should have a responsibility to its clients to provide DR as part of the deal, but it is the clients’ responsibility to know what to do in the event of a disaster. The same goes for the vendor in consideration of its own operations. Although Reval’s own IT function co-ordinates these plans, with guidance from an internal audit operation, ownership is very much accorded to each business unit. This ensures each is able to identify its own critical systems and operations and to put in place and test an effective plan so that everyone knows what to do and when in a co-ordinated manner.
Rather than isolating BC/DR processes, Reval tries wherever possible to bring them into its daily operations. By making them into “a second alternative to operating our business” and by actually using that alternative periodically they become ingrained into the collective consciousness of the staff, explains Pettinato. “Once a month or once a week we will operate using our DR platform; this is tied into the production platform to make sure it is operational.” He cites having seen companies build up “impressive DR and BC platforms, test them a couple of times and then forget about them”. But it is important to keep those platforms and procedures up to date and make them part of your operations. “If you are using it regularly you will know it works.”
Reval’s practical BC plan for its own business operations (as distinct from its client operations) allows it to operate from a number of different offices and even virtually, with staff able to connect remotely if necessary. It has all of its core infrastructure and systems in professional co-location facilities that offer redundant power supplies, communications links and so on, and it also replicates all of its data in real-time using two different data centres connected but situated in geographically diverse locations.
However BC/DR is managed, simply backing up data every day and sending it over the internet to another location may have been okay a few years ago, but in a world of Big Data and complex analytics, losing a day’s worth of data is a big deal for many businesses. “Any company that believes it can get away with running a simple daily backup and restoring from that is clearly running a huge risk,” comments Pettinato.
When cyber disaster strikes, ‘keep calm and carry on’ would be a suitable adage for treasurers, but it would be hoped that the banks would play their part in keeping the machine moving. Routine operations such as making payments and checking cash positions become a serious challenge should a host-to-host banking platform be unavailable following a major event.
Banks are cognisant of this fact and in this situation many will advise clients to use the bank’s online banking platform as a means of carrying on in the interim. “If a client cannot send a file to us, they can go online to initiate urgent payments, including payroll,” says one bank specialist. “If a client receives its banking intra-day and prior-day statements host-to-host, we can put those statements, in the same format, online as part of a disaster recovery plan.”
Incorporating mobile solutions into DR/BC planning is sensible but requires preparation. Accessing online banking requires the right people to have the security credentials and tokens necessary to function but they also need to know how to execute transactions in an emergency. “We recommend our clients test the process at least annually so that they know how to release manual payments,” advises the specialist. It is also essential to have a process in place to avoid duplication of manual payments that may be contained in the original files if those files eventually make it through to the bank via the normal channels.
Whilst inclusion of banking in DR plan is crucial, corporates are curiously quiet when it comes to checking the preparedness of their key partners. There is an expectation nowadays that bank products will conform to BIS (Bank for International Settlement) principles and stand up to any DR scenario. Rules, such as the minimum acceptable distance between a bank’s data centres, exist to give a level of common comfort for clients.
Banks must provide security and demonstrate that they can function whatever happens. To this end, there is increasing market interest in the sustainability of platforms, business models and processing capabilities. The industry is also seeing more co-sourcing of technology and more platform investment.
Yet, despite the banks’ and vendors’ best efforts to help clients to avoid cyber-attack, or to recover as swiftly as possible from a cyber-breach, ultimately, the treasurer must take responsibility here. This means working with all business partners – internal and external – to ensure that any threat to the company’s finances is minimised.