2017-11-23 Episode: We talk to East Bay Municipal Utility District, which provides water to approximately 1.3 million people in the Oakland and Berkeley, California area. Continue reading
On Saturday, September 26, 2014 Mount Ontake – 200km west of Tokyo – suddenly erupted, spewing ash and rock over a wide area and killing nearly 50 people (at last count). What’s strange is that this volcanic eruption occurred with no warning – at least that’s what the specialists are saying at this stage. I’m not so sure that’s true.
It’s always been said that Japan has one of the best early warning / monitoring systems in the world due to its location on the Pacific Rim of Fire. If the best monitoring system in the world didn’t catch this, then is the best system even worth it? I mean, these systems are developed to help save lives and provide early warnings to evacuate people and ensure life safety. Yet, that didn’t happen so are the monitoring systems we have in place any good? Are they providing any help at all? Continue reading
Check out our revamped shop at http://www.stone-road.com. We’ve added lots of new document templates to help get your new BCM / DR program off the ground – with more on the way. Each comes with built-in instructions so you don’t need to try and figure it all out on your own. You can even manipulate the templates if you want to so they address your specific need. Our goal is to show you ‘how’ to do things not just tell you ‘what’ you need to do.
Here’s a sample list of what we’ve got so far:
1 – Test-Exercise Project Change Request Template – $9.99
2 – Test-Exercise Scope Statement (Charter) – $29.99
3 – Test-Exercise Executive Summary – $29.99
4 – Operating Unit Business Continuity Plan (BCP) – $79.99
5 – Business Impact Analysis (BIA) (This one along can cost thousands for a software application.) – $79.99
1 – Employee Logistics Plan – $tbd
2 – BCM/DR Program Policy Template – $tbd
3 – BCM / DR Program Overview (As a bonus, this will include the Policy template) – $tbd
If there’s something specific you’re looking for, send us an email. We’ve got lots in our arsenal and alwasy building new templates so we may just have what you need and just haven’t gotten around to getting it up on the site. We can always build something for you. You can reach us at firstname.lastname@example.org.
StoneRoad: Reducing Corporate Suffering Through Continuity Planning.
The StoneRoad Team
StoneRoad 2013 (C)
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
Most organizations don’t want to imagine what would happen if a disaster struck their operation, but what if a disaster did strike. How would your organization respond? The best way to know how to respond is to develop, implement and maintain a Business Continuity Management (BCM) program. A BCM program provides a framework for building organizational resiliency with effective responses and safeguards that protect its reputation, stakeholders, employees, and facilities.
BCM is not just about remedying technology shortfalls, as many organizations believe. It’s also about securing, protecting, communicating and preparing corporations from disastrous impacts upon its workforce, facilities and its technologies – To minimize the impact on operations. BCM touches every aspect of an organization from the mailroom, the field and the call centre to the manufacturing floor and right up to the boardroom.
To make your program effective, consider some of the following suggestions when planning:
1. Start With the Worst – Begin the planning with the worst-case situation your organization can imagine. For many, this example is the tragic events of September 11, 2001. Work backwards from there and you’ll start to fill in many of the dangers that can harm your corporation. You’ll also be able to start challenging the worst case situation and begin to get more inventive with potential impacts – and develop the plan accordingly.
2. 3 Pillars of a Business Continuity Plan (BCP) – Every BCP plan must address three things; Workforce Availability, Facility Availability and Technology Availability. If each plan has these three core components, an organization can respond to any disaster situation and expand their capabilities by adding varying situations and scenarios through validation exercises.
3. Dedicated Resource – Assign a person with the appropriate training and authority to get things done, if not, the program will quickly fall to the wayside in favour of other initiatives. This may include getting outside help to get the process kick-started (i.e. consultants, contactors etc).
4. BCM Program vs. BCM Project – The BCM program must live on and continually meet the needs of an organization, as it grows and changes; so to must the BCM program. A project has an end date but a program must live and breathe and contain more than just a single aspect of BCM. Therefore, when the Business Impact Analysis (BIA) is completed, that’s just one ‘project’ of the overall BCM program; you’ve got lots more to get through and develop.
5. Exercising/Testing – Plans mean nothing if they haven’t been validated. Every organization must exercise its plans to make sure they’ll work during a disaster. It’s better to find gaps in your plans through exercising and under controlled circumstances rather than when the real thing happens.
6. Executive Support – If no one is there to champion the BCM program, it won’t last too long. In fact, there’s a good chance it will run out of steam and end up on the backburner of boardroom discussions. Having executive support shows the rest of the organization that BCM is taken seriously.
7. Awareness & Training – It can take a long time to develop continuity plans and create processes and procedures but if no one knows how to use them, where they’re kept or under what circumstances they’re required, they won’t be of any value or use. Remember, awareness and training are not the same things and every level of the organization must received its fair share of both if the program (and all the developed plans and processes) are to be useful and successful.
8. Focus on People – This should be a no brainer; BCM is about people. It’s people that build the plans, use the plans, review and exercise the plans. It’s people that will be impacted by not having plans in place; clients, vendors, employees and communities. If you state that technology availability is the most important part, you’ve basically told those individuals – who you need to help build plans – that they aren’t important. Keep in mind; people first.
9. Business Impact Analysis (BIA) – Every company must understand what it does and how it does it. A BIA is the process of analysing business functions and the effect that a disruption might have upon them. Knowing this will help corporations develop appropriate Business Continuity Plans (BCP) and other contingency strategies. Ensure you get agreement on the findings, don’t just state what they are and move forward. The findings from a BIA are what the attendees believe is important and it could turn out that what they feel is important to the company is not what executives believe is important. Make sure executives are in agreement with the findings before you start developing restoration and recovery plans – you could be way off the mark.
10. Program Maintenance and Monitoring – If program components aren’t maintained and updated the Business Continuity strategies developed – and the related documentation – will reflect the corporation as it once was, not as it current is.
11. Bonus: Using Software Only – Software can be very beneficial for maintaining and gathering information but beware, it doesn’t take into account the nuances of people or scenarios specifics. It may tell you that you need 10 desktops in 24 hours but the situation itself may call for something completely different based on what has occurred. Don’t fall into the trap that DR/BC software will answer all your questions and save you; it’s a tool to help you.
Having a BCM program in place is a part of an organizations Corporate Social Responsibility (CSR) but there are other benefits to implementing a program. First, your organization will have the security in knowing a robust plan is in place to deal with disasters, providing safety and security for all employees. Second, a proper BCM program will provide a competitive advantage. Those organizations will strong programs win out over organizations that don’t have BCM plans in place because there is knowledge that your organization will have developed a way to provide a product or service even during a disaster.
It’s not easy building a BCM program; it can be tough to develop, implement and maintain but it will only take a single crisis or disaster to prove its worth. A single crisis or disaster can be one too many. Are you prepared?
© StoneRoad (2013)
BCM document templates available in the ‘shop’ section at http://www.stone-road.com.
Alex Fullick wants you – and your business – to succeed. Better yet, he wants you to flourish beyond your wildest dreams. But what Alex Fullick knows (and what you may not yet know) is that business success doesn’t come out of the blue, or on a whim or stroke of luck. You have to plan for business success, not only for the anticipated good times of strong sales, revenues and profits, but also for the difficult days when a sudden disaster strikes. It can – and does – happen.
Welcome, then, to the world of Business Continuity Management (BCM), the world where BCM expert Alex Fullick resides. Over the years, he has seen it all – and the one key conclusion he’s reached is that businesses with a plan to deal with significant disruptions and disasters are generally the ones that emerge from the situation stronger and with their operations intact. The reverse is just as true: an organization without a continuity plan is taking an enormous risk, one that has the potential to destroy the company and lay waste to years of hard work.
Fullick acknowledges that, to most eyes and ears, the very notion of “Business Continuity Management” is a term that might cause the ears to shut down and the eyes to glaze over. It may be a dry topic, rather lacking in sex appeal, but it is also a very important cog in your business-planning machine. Simply put, if you are a business owner or key manager, you need to know exactly what you will do when disaster strikes.
Fullick’s most recent planning guidebook is entitled Business Impact Analysis: Building the Foundations for a Strong Business Continuity Program, takes a detailed look at the steps a business owner needs to take to gather the information required to create and manage a strong business continuity program. The BIA, in Fullick’s view, is the foundation upon which a business continuity program is built; it follows, then, that a proper Business Impact Analysis requires strength and depth and that its content must fully reflect the operational and cultural needs of your organization. There is no single cookie-cutter approach that can be applied to each and every business operation.
This book should be required reading for business owners and senior corporate officials, not only because the subject is itself of vital importance, but also because Fullick lays out his BIA foundation in a straightforward contextual manner that is both appealing and highly informative. Business Impact Analysis is a critical building process – and Fullick provides the tools required in an easy to follow systematic approach so that organizational leaders can use the BIA process to its very best advantage.
Alex Fullick is the founder and managing director of StoneRoad, a business consultancy based in Southern Ontario that specializes in a process known as Business Continuity Management (BCM). Fullick published his first work in 2009 entitled Heads in the Sand; he followed that up with Volumes 1 and 2 of Made Again. Business Impact Analysis is his fourth publication with two further publications in the works. In his free time, Fullick is an avid curler and hiker.
Business Impact Analysis: Building the Foundation for a Strong Business Continuity Program
by A. Alex Fullick
For more information visit: http://www.stone-road.com
When disaster – or a crises – strikes, organizations must be able to refer to a plan to help guide them through the tasks they need to consider executing to respond, restore and recover, systems and operations. All to often when a BCM / DR plan is pulled off the shelf or printed from a file, one ends up with a document that is huge in nature and breadth though rather slim and small in usable content.
This is because many organization put everything they can think of into their BCM/DR plans, which more times that naught, overshadows the actual content needed to be followed; the stuff that provides the detail on what to do. A BCM / DR plan should be action oriented not full of irrelevant information; irrelevant at the time of disaster, not irrelevant to the overall program.
I tend to follow a specific rule of thumb that says if there aren’t action items listed by Page 5, then it’s not an action oriented plan. It might address audit concerns, legal arguments and executive expectations but for the user – the one executing activities – it doesn’t address what they need and doesn’t provide it in a clear and concise manner.
So, noted below are a dozen things that shouldn’t be in your BCM / DR plan; the plan needed by users. It doesn’t mean that some of these things aren’t available in another document; an over-arching BCM program document.
1. Distribution Lists (Program Level): You can keep these separate, as names and positions will change constantly. It’s better to keep this separate, as it offers no value to the action plan.
2. Methodology Utilized: Sure you have a documented strategy for how you’re going to develop the program – and plans – but again, there’s no reason to have this in the plans themselves. It just adds more useless information to the plan and isn’t relevant when activities need to be executed.
3. Program Assumptions: You may have some assumptions related to the plan and they should only be those attributed to the plan. Program level assumptions should be kept separate and in a program document – not a plan.
4. Meetings / Schedules / Attendees: Who really needs to know who attended a meeting(s) in the past? No one that’s executing activities needs to know this. You may need to keep track of meeting attendees during the disasters, but not those planning meetings. They can be kept separately.
5. Maintenance Schedule (Program Level): How you monitor and maintain the various plans should be kept in a central location and kept at the program level. Can you imagine the confusion you’d have if you kept this type on information in every single plan? Repetition all over the place and most of it out of sync.
6. Names: The names of individuals change constantly due to new hires, those that leave their position and those that are promoted. Try to use position titles whenever possible – it’ll make it easier.
7. Document Audience: This is like the distribution lists and should be kept separate – if it’s even needed. The audience for an action-oriented plan should be anyone in the organization because you never know who has to pick it up and use it. Keep in mind, the audience isn’t always the same group that has a copy of the plan.
8. BCM / DR Program Descriptors: You can define the program in a program document but don’t redefine it for a plan.
9. Document Approvals / Signoffs: For audit purposes, it’s always a good idea to keep track of signoffs in a separate document.
10. Project Management / Definition: Just like ‘Methodology’ you don’t need to define how you created the plan. That information can be kept separately in a program document or a document that outlines how plans were to be developed. Incorporating it into the plan itself is unnecessary fluff used only to increase the page count.
11. Reporting Mechanisms: Only those reporting mechanisms that are needed to execute the plan should be in the document. There shouldn’t be the overall reporting strategy in a document that details how to rebuild the mainframe.
12. Program Overview: If you have a plan that details how to vacate the facility due to a fire, do you really need pages and pages that describe how the rest of the program operates and what other functions are part of the program? No. What you do need though is to ensure that there is a link to the next stage of the program – the next plan – that needs to be activated/executed because of the disaster.
13. (BONUS) Test and exercise results and documentation. This information is still good to have but it’s not relevant when a plan needs to be activated and followed. it’s just extra fluff that hides the information users really need in their documents. Keep your test and exercise results in documents related to tests. Test information isn’t action-oriented and won’t help anyone in a disaster.
The larger the plan (document) the harder it is to follow and the longer it’ll take people to find what steps they need to execute / implement. If the document is kept action-oriented, then the fluff materials aren’t needed. All the fluff can be kept in a separate document at the program level so that its kept for audit and regulatory purposes – where applicable – and the plan can be better followed and utilized during a real disaster. Just remember, the KISS principle (and I don’t mean Gene Simmons here): Keep It Simple Stupid!
© StoneRoad (Stone Road Inc) 2013
“Heads in the Sand: What Stops Corporations From Seeing Business Continuity as a Social Responsibility” and “Made Again Volume 1 – Practical Advice for Business Continuity Programs”
by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3
Available at http://www.stone-road.com, http://www.amazon.com & http://www.volumesdirect.com