Completing a timeframe analysis or business impact analysis can seem daunting for any size or sector of organisation. A technology resilience and business continuity review which we conducted for a teaching hospital, including a business impact analysis and timeframe analysis, demonstrated some common issues that complex organisations face when putting theory into practice and performing analysis into business impact.
Recently, I’ve focussed heavily on the importance of business impact analysis for business continuity, largely due to the release of the ISO/TS 22317. My review of the guidelines helps to put the BIA into perspective for business continuity practitioners, but I thought that it might also be useful to give an example of the BIA process, and the timeframe analysis that informs it, in practice. I’ve also put together a guide post to lead you through the key steps of performing a timeframe analysis.
Business Continuity for Hospitals and Complex Public Sector Organisations
A few years ago I was asked to provide business continuity consultancy to review technology resilience at a teaching hospital. Although some continuity strategies were already in place, I was asked to determine whether these met the hospital’s resilience and disaster recovery needs, highlight gaps and suggest new strategies. The hospital team and thus the health and well-being of its patients, relied heavily on IT, but despite the importance of service continuity, available budgets were limited. A new Chief Technology Officer had been brought into the organisation, and had serious concerns about the levels of resilience within the hospital’s IT services.
With over 100 key services to consider, we needed to balance the capability of the existing IT resource, with available funds and the necessary prioritisation of the services. The process started with the creation of a provisional risk appetite and impact tolerance statement. This helped to establish a sense of the hospital’s pain threshold, before moving on to the process of determining acceptable recovery time objectives for each service.
Impact Profiles and Pain Threshold
An organisation’s impact profile is the speed at which disruptive impact grows on loss of service. In the case of a hospital department, impact could be on patients’ wellbeing and quality of care, on staff, financial or reputational.
A pain threshold is the point at which the impact on an organisation becomes critical. For a business a pain threshold might simply be a matter of determining how long a service can be out of action before the impact on the business is critical, but in the case of a hospital there are additional levels of complexity.
Business Impact and Timeframe Analysis
It was soon clear that there were a number of cases where the established impact profiles meant that a department’s pain threshold was passed before IT could recover the necessary level of service. With lives potentially at risk, discussion between IT and senior management was fraught. In each case, there were 4 main options:
- Ignore and accept the risk: While this would typically be seen as an ‘easy route’, it was unlikely to be acceptable to stakeholders, and could create a breach of governance if not declared.
- Transfer the risk: Either through insurance or outsourcing, this would likely be the most expensive route.
- Dilute organisational impact tolerance: Similar to accepting the risk, but sets a precedent for situations of the same type and potentially has wide-reaching implications for the organisation.
- Balance the options to achieve compromise.
To negotiate this process, we began the task of using a Business Impact Analysis timeline to plot recovery time objectives (RTOs). The organisation would outline its ideal recovery timeline, and IT would explain its expected timeline without budget. In this example, the organisation wants full recovery of service in 2 hours, but IT can only realistically manage recovery within two weeks without additional budget. IT would then outline the cost of achieving recovery within 2 hours, 1 day, 2 days etc. Compromise is then achieved as the organisation adjusts its position on impact tolerance, and the process is repeated for all services.
Of course, BIA is distinct from Risk Assessment, largely because it does not predict the likelihood of a particular incident, but this was still a fascinating exercise in analysing business impact, and assessing the maturity, adequacy and extent of a complex organisation’s business continuity strategies.
If you’re still unsure about BIA and the ISO 22317, our review should help you put the guidelines into context.
