By Derek Gilmore and Kevin Tsuei, CISA, CISSP, AuditOne LLC
With the myriad regulatory guidance statements related to business contingency planning, it is no wonder that so many community banks continually misinterpret the intent of this practice. We often hear our clients say that between the analyses, policy, procedures and testing, they feel that they would need a dedicated team of staff members to do it correctly. However, with a few practicable recommendations, we intend to show you how to better integrate all areas of your business continuity program into a tailored and manageable process in accordance with FFIEC guidance.
It all begins with the Business Impact Analysis (BIA). A BIA conducted with correct methodology serves as the foundation for the entire program. A good BIA should catalog each and every departmental business function and the systems and applications required for these functions. Taking into account interdependencies between systems and connectivity, the BIA should then go on to assess the impact of a loss in functionality for each of the identified business functions. We recommend assessing loss impact based on, at a minimum, the degrees of financial, operational and regulatory impact, with a loss impact score assigned to each function. That score is then translated into a recovery-time objective (RTO). Functions with what the bank deems to be “critical” RTOs should be subject to the drafting and testing of function-specific disaster recovery procedures. These procedures will require internal coordination among the BCP coordinator, IT and department heads. For example, each department will be responsible for identifying the recovery procedures specific to their functions, including interdependencies such as key systems and software. IT will then be responsible to ensure that their disaster recovery procedures are able to recover these key systems and software within the functional area’s RTO.
Any and all disaster recovery procedures noted in the bank’s Business Continuity Policy (BCP) should directly parallel those functional RTOs listed in the BIA. The RTO should not be a range of hours, days, or weeks, but rather a single digit timeframe. Additionally, when constructing the pandemic planning portion of the BCP, and specifically when assessing resource redundancy/cross training and staffing recovery criticality, this should be done for those very same business functions as cataloged in the BIA.
We have already described how the BIA should be used to determine the need and extent of disaster recovery (DR) procedures testing. That said, we offer the following DR testing recommendations in order to further tie the program together:
Create a standardized DR testing worksheet. This might include the following information: the date and location of the test; the business function which is being tested (from BIA); the systems and applications involved; the personnel and assets involved; the specific test to be performed; the functional DR procedures and test script to be followed; the expected RTO and results; and the actual recovery time and success or failure. It is important to get the proper stakeholders involved as part of the testing. We have observed that many institutions rely on their IT department or vendor to conduct testing without the involvement of departmental manager and employees. Conducting functional disaster recovery testing can also serve as a training for employees. Another issue to keep in mind about having an IT-centric test plan is that there are some processes that are so critical that manual intervention is often needed. One example would be wire transfers. We have observed from time to time that wire recovery procedures are heavily dependent on restoring connectivity to Federal Reserve Bank or a correspondent bank’s systems. The reality is that wires are such a critical function that manual processes (e.g., originating by fax or phone) should be developed and tested at least annually.
Most importantly, we recommend that the worksheet prominently feature a section detailing lessons learned and management review. This section should be used to highlight areas in which DR procedures, Policy, and even the BIA itself should be revised to include previously unconsidered issues discovered during testing. Perhaps the recovery objective was unrealistic, or a key recovery step was missing, or there was an unrecognized systemic interdependency on which the business function relies. These issues should be assigned to owners and prioritized. It is important that they be tracked, resolved, and used to enhance future testing.
While disaster recovery can be seen as a burden to many smaller institutions, management can create a multi-year testing schedule to provide some relief. For example, many institutions elect to conduct table-top testing the first year followed by functional testing for high priority functions for the second and third year. When real-life disasters do happen, the bank should take the time to document the disaster using a similar layout as the worksheet above. There are always many lessons to be learned during a real-life disaster, and any lessons to be learned and they should be properly incorporated to further enhance the bank’s DR procedures.
We strongly encourage banks to regularly revisit their BCP program with lessons learned, as this is the linchpin of an effective but manageable business continuity program.
Published in Western Independent Bankers Association’s Technology & Security Digest, Issue 23 – September 2014.