 |
|
|
|
|
||
|
DISASTER
RECOVERY
_____________ Corporate President/CEO Vice
President
CONFERENCE REGISTRAR Brazil:
Jose Carlos Ferreira
|
Click Here for a Printable Version RISK
ANALYSIS Determining
Business Risk For New Projects As a business continuity
planner, you most likely focus on the recovery of critical business
processes in the event of a disaster. Do you also look at the recovery
of critical business systems? If you are an IT disaster recovery manager,
do you look at the recovery of the critical business processes or only
focus on the recovery of the systems? Do you have a process in place
to ensure the synchronization of the recovery objectives of the two
perspectives? In today’s business
environment, a business application system is entwined with the business
process it supports (especially if dependent on an e-business component).
This should also hold true for the recovery plans of those systems and
processes. Business recovery time objectives (RTO – the time to recover the system after a disaster) are usually determined by a business impact analysis. System recovery time objectives are usually defined by the method used and time required to recover the system. When was the last time you analyzed and compared these two for any gaps? Does your company
consider RTO and recovery point objective (RPO – time passed since
last backup prior to a disaster) when a new business systems application
is designed and/or implemented? Many companies have
system development and/or project management life cycles. Where in that
process/methodology do you find your recovery strategy being applied? What risks are you
willing to incur for what cost? This is all dependent on the criticality
of the application and the business process it supports. The disaster
recovery plan also needs to be tested prior to the system being deployed
into production. A disaster is an interruption
of a system for an unacceptable period of time. A business process may
utilize multiple computer systems and platforms. And each business process
may have a different unacceptable period of down time. The focus of
any recovery plan must be on keeping the business running – not
keeping the computer running. Are recovery objectives in sync between
the business process and the multiple systems and platforms that support
the process? Business continuity requirements should be done before
the computer requirements are defined. The business owner needs to determine
what is an acceptable risk for the business. The business owner should
determine the RTO and agree to the resulting cost of the systems implementation
to meet that objective. If a project is implementing new computer technology
not currently related to a new business application, the business processes
that will eventually be dependent on the project’s deliverables
will determine the recovery requirements. It’s helpful
to have a decision matrix that describes who has responsibility for
approval vs. review and information provider. For an example of a decision
matrix, please look at the graphic on this page. RTOs are usually tiered.
You’ll need to look at your company’s unique requirements
as to how many tiers are appropriate for your organization – more
than five usually become unmanageable. An example of four tiers for
RTO is: Possible RPO tiers
are: Answers to the following
questions addressed to the business owner will assist in determining
RTO and RPO: In most circumstances,
the definition of RTO and RPO will be an iterative process. There is
no absolute formula. There is also a negotiation process with the business
owner to balance the risk with the cost. That is, there may initially
be a requirement for a short RTO and RPO. But after weighing the costs
of the solution, the business owner may accept a longer RTO and RPO
that would be less costly. How much risk are they willing to take for
what cost? As with other business
continuity plan components, an annual review of the RTO and RPO requirements
should be done to capture changes to both the business environment and
the systems environment. So if you haven’t
already done so, get to know your counterpart on either the business
side or the technology side. We’re all in this together. To comment on this article, go
to 1502-13 at www.drj.com/feedback.
|
