Preparing for the Unexpected – 2018-04-12: The Challenges of BCM/DR Programs – Part 1

No matter the industry, the size of your organization, or the location(s) of your business, Business Continuity Management (BCM) and Disaster Recovery (DR) programs always seem to experience a common set of challenges. Drawing from 20+ years of experience, Alex Fullick will discuss these many challenges that seem to transcend industry and location – and which seem to appear at one time or another – in every BCM/DR program. Listen in to hear why some of these challenges occur and how to deal with them when you begin to encounter the same issues in your program.


The StoneRoad Team




BCM & DR: Plans That Can’t Be Made!

In many organizations, executives and employees – and even auditors, will ask Business Continuity Management (BCM) / Disaster Recovery (DR) practitioners if they have plans for every situation possible; every potential risk and every potential impact to the organization. Considering that the number of risks that exist in the world today is basically infinite – once you calculate all the various potential impacts to an organization from a single event – there will be communication, restoration and recovery plans that just can’t be developed, documented, implemented, communicated, validated or maintained. It is impossible to have a response to every situation; the secret it to be able to adapt to the situation and leverage the response plans you do have to help adapt to the disaster situation.
Still, the questions will come about these plans and why a response isn’t captured for a particular situation and its resulting scenarios. A BCM/DR practitioner must be able to address these questions and be able to respond with reasons as to why specific plans don’t – and can’t – exist.
There are a few key reasons that practitioners must be able to communicate to those asking the questions and they are noted below.

1. Unknown Unknowns – In any situation – both disaster related and non-disaster related, will contain all sorts of details. One specific activity or item can have multiple responses depending on the details that come from the situation itself. For example, an earthquake can cause minor or major damage to an area but depending on where it occurs and when it occurs, the responses to the earthquake will be completely different.

2. Highly Improbably – Sometimes a risk to an organization is just so improbably that creating a plan for the situation would be futile and a waste of resources (time and people). For example, an organization with a facility in the middle of the Canadian prairies wouldn’t bother creating a disaster response plan to avalanches; it’s just so highly unlikely that it could ever happen. If an organization documents the probably risks – such as floods or snowstorms for that previously mentioned prairie location – it can adapt the plans that address the likely risks to those that are highly unlikely. New plans for unlikely activities would just distract from developing plans and processes that are really needed.

3. Changes in Assumptions – Assumptions are those things we believe to be true and they should be challenged continuously; especially through tests and exercises. However, if they aren’t challenged at some point then the continued planning and BCM/DR program development could be based on false information. For instance, if specific partners are expected to perform specific tasks for your organization when it experiences a disaster but they don’t know about them – or the tasks have changed and they’ve not been notified – your plans are going to out of sync with expectations and need. Plans are not build on assumptions but the detailed activities contained with them will be built by assumptions and they must be reviewed at all times.

4. Public Opinion / Perception – Public opinion can change with no warning; what the public may agree to in one situation they may not agree with in another situation- even when the details are relatively the same. All an organization can do is ensure it has a comprehensive Crisis Management and Communications Plan (CM&C) and those responsible for the plan understand how to communicate with the public and respond to the public. There is no way and organization can guess at what the public may believe and trying to determine every response plan to unknown perceptions would take eons to develop – something that an organization just can’t do.

5. External Directives – Depending on the scale of the situation, an organization may receive instructions from 3rd parties, such as the police or local governments. It’s never known what these groups may dictate to an organization, as it’s never known ahead of time what or when a disaster will occur. Thus, a plan can’t be developed to address the specifics of what to do based on directives received from external sources. However, if an organization has an established BCM/DR program with relevant plans and processes, it can adapt itself to the situation based on the impact to the organization itself. If an external source dictates a directive then the organization can take what it has in place and adapt itself. But a plan specific to communications that haven’t been provided – because a disaster hasn’t occurred yet – can’t be documented.

© StoneRoad 2014
A.Alex Fullick has over 17 years experience working in Business Continuity and is the author of numerous books, including “Heads in the Sand” and “BIA: Building the Foundation for a Strong Business Continuity Program.”

BCM / DR Scheduling

Nothing happens without good planning and implementation strategies and this is required when planning out the development of the Business Continuity Management (BCM) / Disaster Recovery (DR) program. It’s impossible to just start something without having any idea when you’ll be finished or what you need to reach along the way to be able to take the next step.

Often, to get proper buy-in from executives, a BCM/DR practitioner has to provide a timeline alongside the goals and deliverables the project will provide. Its one thing to provide the reasons why you need a program and if those are accepted by executives as valid reasons (let’s hope they think so…), the next question will be, “When will it be done?” So, a draft timeline must be mapped out; from how long a BIA will take and when the findings will be delivered to when the 1st test will occur.

Of course, it will all be built upon assumptions such as resource availability for example, but a high-level timeline must be provided to executives. Below are ten considerations a practitioner must keep in mind when building the BCM/DR program:

1. Communicate Schedule – At first you’re communicating the schedule to the executive team hoping for buy-in on need for a BCM/DR program build but you also need to communicate the schedule with other stakeholders. For example, if you’re going to be meeting with all division leaders, they should know what you’re timelines are so they can work within those or recommend amendments if the timeline is unrealistic (to them).

2. Base on Agreed-to Availability – If a department isn’t available due to some high-priority initiative during the week of a specific month, then schedule around them and accommodate their priorities. It could be that you meet with them first or schedule them last so that they don’t experience any distractions as they implement their own high priority project. Meet with the department/division leads to ensure that timing is mutually satisfactory.

3. Report Progress – Once you’re got a timeline developed and approved, executives are going to expect a report on your progress; not just on the deliverables but if you’re moving on track to the timeline. Are you behind schedule or are you ahead of schedule and if you’re behind, what you’re going to do to try and get back on schedule. Keep in mind, you may be behind schedule due to an unforeseen circumstance, which had resources focusing on something else and the BCM/DR meetings needed to be rescheduled to later dates. If that’s the case, make sure this is communicated to the executive team, as they will understand if there were unforeseen circumstances based on an incident or sudden client issue that refocused individuals. They won’t be happy if you’re behind schedule for not ‘valid’ reason and have no plan to get back on track.

4. Issues, Risks & Assumptions – If the unforeseen circumstance, as noted in #3 above, there hopefully will have been a documented risk; a risk that states that the schedule is based on no unforeseen circumstances occurring and that available resources aren’t refocused for any amount of time to deal with it. If resources are repurposed to deal with the issue, then the BCM/DR schedule will be impacted. By doing this, executives will understand the reason for being behind and will allow you to re-plan but won’t be happy if you were always planning a ‘perfect path’ – that nothing will go wrong.

5. The Right Resources – When scheduling, make sure you’re going to get the right person to interview or participate. If you are assigned someone who is impossible to schedule a meeting with because their calendar is continuously full because they are over allocated, you may find your timelines slipping. Make sure you get the best resource participant from the department and ensure they have time committed to the BCM/DR program.

6. Project vs Program – Be sure to break up the overall timeline into min-projects. For example, when you will begin and end the Business Impact Analysis (BIA) project and when you will perform the BCM/DR strategy development project. Each must have a start and end date with a specific deliverable planned. All this needs to be sketched out.

7. Determine Milestones – The end dates noted above in #6 may also be your milestones; key points you’re striving to achieve in your overall timeline. Make sure that you have a few key points captured, as these are used in the progress reporting with executive management, so they can ‘see’ your progress.

8. Dependencies – If you have any dependencies between program phases, identify those up front so executives – and others – understand why some phases are performed in a specific order. For example, the development of BCM/DR strategies cannot begin until the BIA phase has completed and findings presented or a test cannot occur until specific plans have been developed and implemented.

9. Schedule Around ‘Them’ – When scheduling, try to schedule around the individuals themselves, as they have other responsibilities to deal with as part of their daily routine. If anyone’s schedule must be accommodating, it must the BCM/DR practitioners, not the department individual. Keep them in mind when schedule and show respect, meaning don’t schedule them over lunch or late on a Friday afternoon, it’ll only create a bit of animosity – unless you’re paying for lunch. Don’t forget, people have vacations so try not to ‘jump’ on them just before they leave or on the first day they get back.

10. Know the Executive/Board Schedule – When you’re reporting the status of your program build, you’ll be required to present the updates to executives (or a likeminded committee) and you need to know what their timeframes are. Do they meet every 2 weeks on a Wednesday? When does your status report need to be submitted to get on the agenda? Know these types of dates in advance.

11. Know ‘Busy’ Timeframes – This should be a no-brainer; don’t schedule around the busy timeframes when individuals are not going to available to attend meetings or provide information. For example, if there are numerous activities that occur at month end; don’t schedule people during that time. Use it to catch up on your own materials and update status reports etc.

12. Revisit Timelines – During each phase, review the schedule for the next phase to ensure you are on track and make adjustments where you need to. Keep your timelines realistic based on what’s happening and forecast what you think the next phase(s) will consist of. For example, you may have determined that 2 months would be enough to spend developing technology restoration and recovery strategies but based on the BIA findings, you may need to extend that by another month because you need to contact a 3rd party vendor.

© StoneRoad 2013
A.Alex Fullick has over 17 years experience working in Business Continuity and is the author of numerous books, including “Heads in the Sand” and “BIA: Building the Foundation for a Strong Business Continuity Program.”

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

Hello dear readers!! We’ve been a bit quiet lately over here at StoneRoad due to multiple vacations (Singapore, Australia, New Zealand and more) and now that we’re all back, it’s time to start posting once more. Enjoy…
The StoneRoad Team

**The below section is an abbreviated bonus taken from the Appendix of the book, “Business Impact Analysis (BA): Building the Foundations for a Strong Business Continuity Program” by A.Alex Fullick. The full text can be found in the aforementioned book.**

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.

A.Alex Fullick at the Australian & New Zealand Disaster and Emergency Management Conference (2013)

We’d like to give you a friendly reminder that if you’re attending the Australian & New Zealand Disaster and Emergency Management Conference in Brisbane, Australia (May 28-30, 2013), StoneRoad founder A.Alex Fullick will be presenting the topic “Heads in the Sand: What Stops Corporations from Seeing Business Continuity as a Social Responsibilty” on Wednesday, May 29, 2013. If you’re in the neighbourhood stop by; you’re sure to hear a great presentation.

StoneRoad 2013 (R)

7 Things That Can Ruin a BCM Program

When financial hardships strike an organization, the Business Continuity program usually takes a hit. In fact, often it will take a hit when times are good so that the corporation can focus on other initiatives; initiatives designed to build upon the good times and keep the company making money. Increase that revenue, YEAH!! When this occurs, resources get reassigned to other projects and the BCM program gets placed on the back burner or it will see resources funnelled away to support other initiatives.
What kind of things do organizations cut from their budgets that can undermine and slowly dismantle a BCM program? Here’s just a short list of some of the actions corporations will take in diverting BCM intended resources.

1. Training – Training is suspended because sending employees on courses to upgrade and keep skills current is deemed as being too costly, especially if travel and accommodation is required. This training also helps to bring new ideas to the organization on how to better their programs but at the same time many executives (or those that approve BCM training) will simply state that the corporation knows what it would do. Thus, additional training isn’t required. Or worse, they send BCM people on courses that have nothing to do with their role.

2. Tests / Exercises – Some BCM tests get cancelled because they take resources away from other initiatives that are deemed a higher priority. Not exercising – and validating – plans and policies can cause issues with recovery procedures when a real disaster occurs because they haven’t been validated and team members have not practiced what they need to do. Also, some believe that if you’ve exercised once before, that’s all you need to do. You did it so you don’t need to do it again. Wrong! The more practice and progressively challenging you make the exercises the more robust the plans and policies become – and the better you’ll be able to respond and recover when disaster strikes.

3. Business Impact Analysis (BIA) – An organization will choose to skip updating the BIA and utilize previous findings assuming that nothing has changed, which is rarely the case. If nothing changed – ever – then there would be no such thing as projects. Projects drive change; from technology to processes. When projects are implemented it will change existing processes, introduce new ones or cancel some others. All this must be captured in the BIA and then carried over to the appropriate plans (i.e. contingency plans, crisis mgmt, technology recovery etc). Remember, ‘change is constant’ and the BIA should be able to capture those changes and then funnel them through to the right areas of the program so it reflects the organization as it is now – not as it once was.

4. BCM Awareness Program – Awareness weeks or sessions, assuming your organization has them, are cancelled to concentrate on other initiatives or because management don’t want to put a ‘scare’ into employees. Most employees I’ve ever worked with have said they would like to know what is expected of them in a disaster; keeping it from them is not a good idea. You’re really harming yourself and the business in the end. Some of the best ideas will come from involving people and keeping them up to date on progress. To put this in perspective, I was told by a Senior Director of a client that they would be making a poster of a specific announcement and hang it up around the office. “Everyone will see it and know of it and we’ll make sure it’s updated as needed”” they said. I guess they didn’t notice that just outside this director’s office were 3 posters; 1 was no longer relevant for the last year and the 2nd poster had a due date on it that was just over 2 years. Hmm, I wonder if those were supposed to be updated too.

5. Maintenance Initiatives – Business Continuity Plans (BCP) or other BCM components don’t get updated, which means that the best any BCM program can do – when not having been maintained – is take the organization back to the state of services and systems at the last time of updating. This is very specific when it comes to Technology Recovery Plans, which if not updated will only bring back systems that could reflect the structure of the company three year prior – assuming maintenance hasn’t been performed for three years. It could end up costing a corporation more money to purchase software and hardware to help bring the recovered systems to more updated levels. This can also increase the time it takes to recovery causing additional delays in getting operations running again. Also, there nothing worse that trying to find someone through call trees or notification applications (or whatever method is used) only to find that they changed numbers and now you can’t find one of the key people you need to help get restoration and recovery efforts started.

6. BCM Support / Investment – Investment in BCM is reduced or halted. This would include future initiatives such as building a new data centre, upgrading the backup tape systems, renewing key components of a Disaster Recovery (DR) vendor contract, or ensuring that a hot-site DR site (which can be internal) is linked to the main data centre to ensure that constant communication is kept between the two sites. Sometimes these initiatives are cut in favour of sticking with what is known for now (i.e. restore from tape), which can be detrimental if it takes 24 hours to restore from tape but certain systems and services need to be available and fully functional by the 8 hour mark. Just like an old car, the older it gets the harder it is to find anyone who has the skills and knowledge to fix the issues and the parts become scarcer and scarcer and the level of reliability on the car slowly begins to slide down the scale.

7. Organizational / IT Change Management: Nothing last forever or rather nothing stays the same forever; change in constant and the organization is constantly changing. If organizational change management (OCM) and IT change management aren’t incorporated or monitored by the BCM/DR team, plans will quickly become obsolete. They’ll only represent the organization as it was before the last change, assuming that while various BCM/DR program components were made, no changes ever occurred (and we know that isn’t true). So keep an eye out for change at all levels because if you don’t, you’re program will quickly fall out of step with the rest of the organization.

When any of these occur, the corporation begins to put itself in danger because what may have been a strong BCM program is now being scaled back and no longer receiving the focus it should have. When the corporation is growing and expanding during the good times, so too should the BCM program, otherwise if the corporation is hit with a disaster situation, it will have a program that only reflects the corporation before it expanded and implemented new initiatives. The corporations BCM program is only as good as the resources and the focus it receives from the top tier levels of the organization and the amount of respect it gets.
StoneRoad 2013 ®

Purchase books by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3, at the following locations:, &

9 Things to Consider with BCM / DR and the Use of Manual Processes

When teams are determining and developing their Business (unit) Continuity Plan (BCP) the fact that manual procedures will be used, often crops up. ‘What will you do in a DR situation?’ they’re asked and the answer all too often – and quickly – comes back as “we’ll do ‘x’ manually.” Really, is it that easy to do; just revert to a manual process for what normally includes many checks and balances and possibly varying numbers of applications?

In some instances it might be that easy. If you telecommunications are still up you can answer calls and take down information clients are looking for and then call them back when applications come back up. Not a full manual process but you can at least get some client service going. For those old enough to remember, your credit cards were taken manually by restaurants and shops by copying the card imprint using carbon paper. That wasn’t a manual process back then – it was the process. However, if anyone in the restaurant or shop industry wants to ensure they can continue to service clients – and get paid by patrons – they still have an old dusty machine and credit card slips hidden in the back cupboard of the office. In this case, many places use this as the backup process – and it’s a manual process.

But it’s not always that easy to just say you’ll do your processes manually anymore. With huge strides in technology and technology dependencies (and interdependencies) and service level agreements, not to mention the level of governance required in today’s business world, switching to a manual process may not be that easy and in many cases may not even be possible. For that reason organizations must really think through what they can and cannot do manually and take into consideration some key factors.
Below are 9 things an organization must consider before reverting to manual processes during disaster situations and before it’s inserted into any business unit BCP.

1. Short Term Use: If you’re going to use manual processes, remember they are only intended for short term use. They are not meant to be used for any long term use, as it could cause you other problems down the road. They are short term fixes used

2. They May Break Regulations: Sometimes a manual process breaks a rule – or sidesteps a rule – so that a function can be completed. In a disaster situation when (if) you’re using manual processes, be aware that the process may not meet your usual standards simply because technology has been taken out of the loop.

3. Less Audit and Governance: If you are developing manual processes and see a need to have them, know that the level of governance and audit tracing by various technology applications won’t exist if a manual process is leveraged. Still, consider adding some level of audit or governance to lessen an potential future impacts.

4. Serious Emergencies Only: Consider the use of manual processes only in real emergencies. If an application – or some other situation – is very short term, it may not be necessary to bring everyone up to speed on what to do when using the manual process. It may simply be easier to wait until the application (or other dependency) becomes available once more.

5. Not Widely Available (or known): It may seem a bit strange to withhold information but manual processes aren’t something you want everyone to know about. If everyone did know about them, they might be used in non-emergencies, which would completely cause chaos down the road when an issue pops up with the work completed. If you have them, keep them separate from regular operating procedures and don’t distribute widely to people until necessary.

6. Not a Process Replacement: Since manual procedures are intended as a short term fix, they are not a replacement for regular operational activities. They are only mean to be used to continue a critical operation – or as a short term partial fix – until normal operational activities can continue (i.e. applications become available etc). A manual process does not equate to an alternate method of doing the same thing; it’s short term because the normal operational activity can’t continue as is due to an unforeseen circumstance and will be stopped as soon as it’s feasible.

7. Determine Use Requirements: When Can They Be Used? Under what circumstances can – or will – the manual process be utilized? It could be that as part of normal operating procedures, a manual override is required by a management representative because our own authority doesn’t allow for us to continue with a function. We’ve all be in the situation where we are waiting for something to complete but we need to the ‘special authority (or input)’ of a manager before we can continue. You also want to ensure that the manual process can’t compromise your operations and utilized for underhanded purposes, so know when it is appropriate and when the manual process fits into operations – either as a disaster contingency or as part of governance processes.

8. Oversight Requirements: Need some level of oversight on manual processes – even in DR situations, as audit / governance / legislative requirements may still need to be captured (depending on the process and procedure being manually used (i.e. old credit card slips). Keep in mind that developing oversight processes during a disaster period may delay the actual recovery timeframes and can cause unnecessary work but it all depends on what manual process(es) you’ve decided to develop and implement for DR purposes.

9. Documentation – DR Use: Keep these documented and ready for use in a DR situation (part of a BCP plan for use by the appropriate departments (an appendix)) and kept in a separate location from other operating manuals. Quite possibly, they can be kept in a locker or other container at the DR restoration and recovery centre. Make sure you keep things updated too and reviewed every so often. Even if you do have manual procedures in place, they are based on regular operating procedures, so when those change the manual procedures may need to be reviewed as well.

If you’re in a position to use manual processes to get your operational activities completed, that great however, in a DR situation you aren’t operating in normal circumstances and manual processes may not be the norm even when there isn’t a disaster. Think carefully of what you can – and cannot do – with manual processes before you document and incorporate such worded activities into BCP plans. Incorporating them before you’ve considered the ramifications might cause another disaster situation further down the road…sometimes before you’ve even recovered from your first disaster.
© StoneRoad, 2013

Books by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3
Available at, &