This site does not address the continuity of the critical processes themselves but rather the continuity of ICT and IS that is needed to provide the critical processes with their technology and information requirements following an incident. This is represented in the figure on the right.
Within the organisation Business Units may have a number of critical processes which each have a time period within which they must be recovered in order to meet the organisational objectives. This time period is known as the Recovery Time Objective (RTO). Most critical processes will have a dependency upon IT in order to function, therefore the IT components upon which they depend will also need to be recovered within the Recovery Time Objective. Without information or data the critical process will not be able to operate and the point in time to which this can be recovered is known as the Recovery Point Objective (RPO). The RTO and RPO are shown as green and blue arrows in Figure 1. These requirements for availability of IT and IS feed into the IT Service Continuity Strategy and drive the overall architecture of ICT and the IT Service Continuity Plans.
The Business Continuity Plans which detail the method of recovery of the critical processes are out of scope of this report, but the IT and IS requirements of those critical processes are within the scope of this report as IT Service Continuity Management (ITSCM) is determined purely by the requirements of Critical Processes. This covers a number of interdependent IT components such as hardware, applications, databases, networks and pre-requisite software. The chain of dependencies determines the prioritised order of recovery and timescales for recovery. If outages are recovered within the approved timeframe, IT outage events will not trigger Business Continuity events.
In order for ICT to be available to recover the required IT and IS in accordance with the IT Service Continuity Plan and within the agreed RTOs and RPOs, ICT need to be operational themselves. The continuity of operation of ICT is covered by their own Business Continuity Plan, which defines their requirements for recovery in terms of technology, equipment, materials, people, premises and critical suppliers. If ICT do not have a Business Continuity Plan, it is unlikely that the critical processes IT and IS dependencies could be recovered if the incident also impacted ICT. Business Continuity Planning for ICT is within the scope of this report and is shown at the bottom of the diagram, where their RTOs and RPOs are not only driven by the requirements of the Business Units, but also by the recovery capabilities. In order for an effective IT Service Continuity Strategy to be developed, the Business Units and ICT need to work together at this point to develop a strategy which not only meets the requirements of the organisation, but is also within the capabilities of ICT. This is discussed further in this report.
Specific technical procedures for IT system recovery – usually contained in the IT Service Continuity Plan - are not developed in detail in this report, and more information can be found within standards and guidelines such as PAS 77, NIST 800-34, ITIL v3 and COBiT v4 [COBIT]. However, the interfaces between the Business Continuity Plan and the IT Service Continuity Plan are extensively covered in this report.
Whilst this report focuses on Business Continuity, it concentrates on ICT, on the relationship of IT Service Continuity to Business Continuity, and on the importance of considering both together (and not each in isolation) to achieve a successful, integrated recovery from an incident. The methodologies described in PAS 77, ITIL v3 and COBiT v4 all state that BCM should be in place before ITSC can be achieved. If it is not, then BIAs must be performed by the Business Units in order to provide ICT with a business view of the IT requirements. The results of the BIA study are recorded in a report which is then transferred from BCM to ICT. This report is referred to in the present document as the IT Requirements document.
The present pages show the relationship between BCM and RM, where BC is seen as a method of Risk Treatment to mitigate continuity risks. These risks are either treated in a proactive or reactive manner. Proactive controls implement agreements and systems in place to deal with the effects of a disruption. These can take the form of an agreement with a Work Area Recovery Facility (WARF), a clustered server with UPS and RAID disks or simply having a second telephone line installed. Business Continuity Plans are developed for a reactive response.
HB 292-2006, the Australian Handbook for Business Continuity practitioners [HB 292-2006], advocates a proactive approach to Business Continuity where the BCM practitioner works closely with the risk managers so that much of the Risk Assessment for BCM is undertaken by others, providing more quality input into the process. This means that treatment of disruption events become a focus and ‘the (BCM) practitioner can lead the creation of proactive improvements in capabilities in resilience’. It goes on to state that the contents of the standard have a strong emphasis on conducting a robust Risk Management process as part of BCM.
A number of standards use a proactive and reactive approach to Risk Management and the mitigation of continuity risk e.g. NIST 800-34, BS 25999-1 and Business Continuity Institute Good Practice Guide [BCI GPG]. In this report we consider only the reactive controls as the proactive ones are mitigated in the classical Risk Management activity leaving Business Continuity to address the risks which cannot be successfully mitigated or treated as well as those that arise as a result of an incident. More detail is given in Overview of the Business Continuity Process section.