Spring World 2015

Conference & Exhibit

Attend The #1 BC/DR Event!

Fall Journal

Volume 27, Issue 4

Full Contents Now Available!

DRJ Blogs

DRJ Community Blogs
Tags >> BIA
Jun 18
2014

Assessing Your Disaster Recovery and Business Continuity Strategy

Posted by Alex Belyarchik in Business Continuity , BRP , BIA , BCP , BCM Professionals , Awareness , Advice From A Risk Detective

Alex Belyarchik
  • Identifying business processes
    • How critical are they to the business? 
    • What are the RTO's for them? 
    • What is the supply RTO for them from IT? 
    • Are they relying on the applications, or could be done manually in case of disaster? 
    • If there are gaps within Supply / Demand RTO --> negotiate with the Sr. Mgmt to either implement the changes or sign off on accepting the risk
  • Assess the potential external / internal risks for the company
    • What are the disruptions to the business? (i.e. natural disasters, flu pandemic, building not available, e.t.c.)
    • What are the internal risks? (i.e. access privilege violation, information theft, e.t.c.)
    • Create "Criticality Matrix" to assess the probability of each of the risks happening to an organization. This could be on a High/Medium/Low basis
  • Review all DR/BCP Plans
    • Start off with the Tier 1's critical applications and go down the list
      • Conduct plan review called "Tabletop" with plan builder to review and update the document
      • Then conduct "Walkthru" with the plan builder presenting the plan in front of all stakeholders. You can also invite internal/external audit to assess the process
      • Conduct a functional test 
  • Vendor management
    • How often were the vendors reviewed? 
    • How often are the vendors visited? Top 10 critical vendors must be visited on an annual basis. This could be merged with the Security Assessment. 
    • Obtain information on data center locations, disaster recovery tests, contact persons, as well as dates and times of the past and future tests
    • Record information within plans and ensure that each plan requiring vendor application to be available possesses this vendor information
  • Functional Testing
    • How often are the critical applications tested? 
    • Is the testing methodology aligned with the corporate goals? Are you getting service disruptions during the tests? 
    • How often are Tier 2,3,4 applications tested? 
    • Were multiple concurrent tests conducted at once? (e.x. testing 20 applications as a bundle in datacenter failover test). 
    • Review the Test Certifications to ensure they possess critical information, such as: test times, applications tested, hardware tested, issues are logged, resolutions are found, physical signatures of the testers are obtained, Sr. Mgmt approvals
Apr 16
2014

Disaster Recovery and Change Management

Posted by Alex Belyarchik in Business Continuity Management , BIA , BCP , BCM , BC/DR conference

Alex Belyarchik

Change Management is often times the most overlooked aspect when it comes to Disaster Recovery. Not only does it not get enough attention, but we often times forget that building a recovery footprint is just as important as maintaining it. 

Has your server been operational in sync with the production environment? Have all the new production changes been replicated over to the DR? How can you be assured that your applications are still functioning? 

Mar 13
2014

Using the Results of Your BIA to Develop Disaster Recovery Requirements

Posted by Courtney Bowers in DR , Disaster Recovery , Business Continuity , BIA , Avalution Blogs

Courtney Bowers

By Michael Bratton, Avalution Consulting
Originally posted on Avalution Consulting’s Business Continuity Blog

So you’ve just completed your business impact analysis (BIA) – identifying recovery time objectives for a variety of processes and functions throughout your organization and captured the names of applications and systems that business owners state they just can’t live without. In addition, the IT department heard you were conducting a BIA and mentioned on a few different occasions that they were excited to see what the final results would be to help with their planning. You’ve taken all the applications and their reported recovery time and recovery point objectives and crammed them into a very lengthy spreadsheet, and then the inevitable happens… you realize that everything you have collected is a huge mess.

Oct 18
2013

12 Tips, Trips & Traps: The Business Impact Analysis (BIA)

Posted by Alex Fullick in Business Impact Analysis , Business Continuity Management , BIA

Alex Fullick
Business Continuity Management (BCM), like most corporate programs, is often plagued by common mistakes; these common mistakes also apply to the Business Impact Analysis (BIA. The following are some common mistakes that need to be addressed to ensure that the BIA is effective: 1. Minimal Management Support – Senior management must buy in to the need for continued maintenance of the BCP program. The program requires on-going resources to ensure that the program is funded and there are dedicated resources assigned across the organization. The people who head up the BCP program must have the requisite training, as well as the skills to provide leadership, prioritize tasks, communicate with stakeholders, and manage the program. 2. No Timely Follow Up of Results – A BIA is conducted almost always in support of an enterprise-wide business continuity program. The real value of a BIA is the follow-up activities that lead to effective recovery strategies being implemented based on the BIA priorities of the business processes. Occasionally, so much effort and cost is put into the BIA that business continuity planners never get around to fully implementing the follow-up recovery strategies and plans. Without the implementation of these follow-ups, the value of the BIA becomes wasted. 3. No Agreement on Scope (Level of Detail) – This level of detail can span an entire spectrum. On one end, some BIAs will contain relatively little detail to provide a higher-level executive view of the analysis. On the other end, and far more prevalent, are BIAs that include for each business process its corresponding input dependencies, output dependencies, recovery point objectives, recovery time objectives, and financial impacts. The common mistake here does not involve selecting the right or wrong level of detail – what’s appropriate for one company may be totally inappropriate for another – but rather, failing to reach agreement among all relevant parties as to what level of detail best meets the requirements that are driving the BIA in the first place. 4. Minimal Executive Support – One of the factors that most influences the relative success of a BIA is the degree of executive support offered at the outset. The kickoff process usually consists of two parts: a widely distributed email and an initial presentation. The email should come from the highest level executive sponsoring the BIA and should be distributed to all parties who will be participating in the effort. The email should emphatically voice the executive’s support for the project and insist on the support of al participants, particularly during the interview process. 5. Poor Questionnaires – An important step of any BIA is the collection of data from business units. The manner in which this data is asked for often spells the difference between a full, timely and meaningful collection of data, and one that is delayed and incomplete. One of the best ways to avoid this situation is to develop survey forms that are thorough enough to capture all relevant information and simple enough for business users to complete quickly and easily. 6. Lack of Preparation for Interviews/Workshops – Interviews are the cornerstone of a successful BIA, yet few planners prepare adequately for them to ensure their effectiveness. Interviewers need to learn as much as they can about a given business unit prior to the meeting, including a thorough review of the respondent’s survey. 7. Lack of Critical Focus – Analysts frequently make the mistake of asking business users ‘what are the most important business processes within their department?’ The reason this is a mistake is because virtually all critical business processes have a large degree of importance and value – otherwise they would not be designated as critical – resulting in less likelihood of it being easy to prioritize processes according to value or importance. A much better question to ask is ‘how long can a business process be idle before major impact is felt? 8. Focusing on the Tools Instead of the Process – Some analysts who conduct BIAs become very focused on the tools they will be using in the collection, compiling and analyzing the data provided by the business users. The emphasis often shifts inappropriately from the process being used, to the automation that can be applied to the process. There is an inherent flaw in this approach. If a poorly designed manual process that is being used to collect and analyze the data suddenly becomes automated, what you typically end up with is a poorly designed automated process. 9. Ineffective Interviewing Technique – I have known more than a few BIA analysts who preferred to rely solely on surveys, questionnaires and emails to collect needed data. The example previously cited concerning the over-focus on tools shows how this can less than desirable results. Analysts often say that setting up interviews can be more hassle than it’s worth. They will mention how interviews often start late, or may be cut short, or have to be re-scheduled, or cancelled altogether. In my experience, the real reason some BIA analysts try to steer clear of face-to-face meetings is that they tend to use ineffective techniques when interviewing business process owners. 10. Insufficient Results Analysis – Analysts conducting a BIA collect a wealth of information during the course of their efforts. But the value of this information is sometimes diminished by poor or incomplete analysis of the data. Analysts need to look for trends, patterns, relationships and discrepancies among and within the data to ensure a thorough and meaningful analysis. 11. Unclear Presentations – Data that is thoroughly collected and well analyzed is sometimes de-valued by an unclear or confusing presentation of the information and results. Managers in general and sponsoring executives in particular, expect BIA analysts to summarize their results in high-level presentations that are succinct and effective. Unfortunately, this does not always happen. Analysts gather a huge amount of data in the process of conducting BIA. In compiling and analyzing this data, analyst sometime err on the side of presenting too much information rather than too little. 12. Undefined Scope – Often, the BCP focuses entirely on system restoration. Resumption of business needs to include the people and processes required to resume operations. Many BCP programs are headed up by IT departments. ‘Tunnel vision’ can often cause these departments to focus on system recovery and not take the people issues into account. During an event, the people issues are often the most difficult to resolve. The scope of a business impact analysis (BIA) pertains to the number of business units, such as Finance, Administration and IT, which will be participating in the effort. Don’t let your BIA efforts fall to the wayside; make sure you have strong BIA approach and you’ll end up with a strong BCM / DR program. (C) StoneRoad (A.Alex Fullick) 2013Alex Fullick is the author of several books including the latest, "Business Impact Analysis: Building the Foundation for a Strong Business Continuity Program"  (Available at www.amazon.com or www.stone-road.com/shop.)