[{"innerBlocks":[],"name":"core\/freeform","postId":127371,"blockType":{"name":"core\/freeform","keywords":[],"attributes":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"providesContext":[],"usesContext":[],"selectors":[],"supports":{"className":false,"customClassName":false,"reusable":false},"styles":[],"variations":[],"apiVersion":3,"title":"Classic","description":"Use the classic WordPress editor.","category":"text"},"originalContent":"

7 critical steps in testing a disaster recovery plan<\/h2>
There\u2019s a tension with disaster recovery plans\u2014healthcare organizations have them, but hope they never use them. And while no one wants to discover that a disaster recovery is over-resourced\u2014with too much time, money and energy spent on maintaining it\u2014yet it needs regular stress testing to ensure it will do its job. Eric Dynowski, chief technology officer at ServerCentral Turing Group, suggests regular stress tests of a disaster recovery plan to ensure it doesn\u2019t become outdated\u2014in fact, it needs to evolve as an organization changes. \u201cAt a previous firm, we tested quarterly and found changes and updates during every test,\u201d he says. Here are seven steps to ensure that a disaster recovery plan fits a healthcare organization\u2019s current needs.<\/p>

Plan for failure<\/h2>
\u201cThings will fail during stress testing,\u201d he says. \u201cThat\u2019s the point of doing it.\u201d Those involved in the stress test need to prepare for this reality\u2014if they\u2019re not, \u201cpeople may feel incentivized to make everything look good rather than make sure that everything actually works.\u201d Dynowski suggests that IT execs \u201cneed to be champion of failure; when a DR plan doesn\u2019t go as you hoped, remember that you\u2019re actually a hero.\u201d These discoveries enable providers to get misalignments corrected to ensure failures don\u2019t happen during a real calamity.<\/p>

Put someone in charge<\/h2>
A disaster recovery stress test won\u2019t happen if no one is explicitly assigned to lead it, Dynowski contends. Responsibilities for the person tasked with leading it include keeping track of changing business needs as they relate to DR; schedule and oversee regular tests; update the DR solution as needed; and update the DR plan to accommodate the new solution. \u201cThat last item is crucial: the whole point of testing is to identify parts of the plan that no longer fit your business needs,\u201d he says. \u201cIt\u2019s easy for a \u2018failure\u2019 during a test to feel like a personal failure. In reality, though, testing failures are wins, because they let you prevent real-world failures.\u201d<\/p>

Look at the current disaster recovery plan<\/h2>
Before anything else, the current disaster recovery plan needs to be reviewed, especially if it\u2019s more than a year old. A plan that doesn\u2019t align with current needs requires an update. The DR lead will want to collaborate with leaders outside IT to determine which applications and functionality need to run; which hardware must be online; and what dependencies flow from those two requirements. \u201cIdeally, you\u2019ll walk away from these conversations with recovery time objectives and recovery point objectives that, in the event of a disaster, accommodate everyone\u2019s needs,\u201d he says. <\/p>

Get the C-suite on board<\/h2>
Getting leadership on board with the criticality of disaster recovery is crucial\u2014without such support, it will be a struggle to get other leaders in the organization to prioritize testing. Spell out the importance of having a plan that enables care delivery to continue in any eventuality. \u201cIf your C-suite already understands the importance of having a disaster recovery plan, make sure they\u2019re on board with the importance of testing,\u201d Dynowski notes.<\/p>

Stick a dollar sign on DR and testing<\/h2>
In talking to C-suite executives about stress testing, frame it in terms of dollars and cents: how long can your organization afford to have IT and other systems down? It\u2019s important to help leadership calculate potential revenue losses from each minute of downtime for various scenarios, not to mention the potential reputational hit that even relatively minor downtime can cause if handled wrong. DR leads also should provide insight about the many types of disaster recovery solutions and the various costs of each.<\/p>

Establish guidelines for real-life disaster recovery<\/h2>
A solid disaster recovery plan must include conditions that trigger it\u2014for example, give a team five hours to fix a problem before the DR plan is invoked, or if certain parts of an application go down (in other words, are they non-essential functions that an organization can temporarily live without). Guidelines should be based on larger business, so triggers will need validation from other stakeholders in the company. Non-IT employees should be enlisted to help during stress tests\u2014someone from each department should test the functionalities they depend on, and someone should be in charge of testing from a user\u2019s perspective.<\/p>

Plan the stress test strategically<\/h2>
Scheduled downtime can be an ideal time to conduct DR stress tests; when something goes wrong, the execs in charge can easily roll back to production and re-evaluate, recalibrate and update the plan. Disaster recovery is a whole-business effort, and any plan must work for the whole business. The whole business must participate in stress testing, and the plan and testing schedule should depend on the needs, budget and risk tolerance of the organization as a whole.<\/p>

","saveContent":"

7 critical steps in testing a disaster recovery plan<\/h2>
There\u2019s a tension with disaster recovery plans\u2014healthcare organizations have them, but hope they never use them. And while no one wants to discover that a disaster recovery is over-resourced\u2014with too much time, money and energy spent on maintaining it\u2014yet it needs regular stress testing to ensure it will do its job. Eric Dynowski, chief technology officer at ServerCentral Turing Group, suggests regular stress tests of a disaster recovery plan to ensure it doesn\u2019t become outdated\u2014in fact, it needs to evolve as an organization changes. \u201cAt a previous firm, we tested quarterly and found changes and updates during every test,\u201d he says. Here are seven steps to ensure that a disaster recovery plan fits a healthcare organization\u2019s current needs.<\/p>

Plan for failure<\/h2>
\u201cThings will fail during stress testing,\u201d he says. \u201cThat\u2019s the point of doing it.\u201d Those involved in the stress test need to prepare for this reality\u2014if they\u2019re not, \u201cpeople may feel incentivized to make everything look good rather than make sure that everything actually works.\u201d Dynowski suggests that IT execs \u201cneed to be champion of failure; when a DR plan doesn\u2019t go as you hoped, remember that you\u2019re actually a hero.\u201d These discoveries enable providers to get misalignments corrected to ensure failures don\u2019t happen during a real calamity.<\/p>

Put someone in charge<\/h2>
A disaster recovery stress test won\u2019t happen if no one is explicitly assigned to lead it, Dynowski contends. Responsibilities for the person tasked with leading it include keeping track of changing business needs as they relate to DR; schedule and oversee regular tests; update the DR solution as needed; and update the DR plan to accommodate the new solution. \u201cThat last item is crucial: the whole point of testing is to identify parts of the plan that no longer fit your business needs,\u201d he says. \u201cIt\u2019s easy for a \u2018failure\u2019 during a test to feel like a personal failure. In reality, though, testing failures are wins, because they let you prevent real-world failures.\u201d<\/p>

Look at the current disaster recovery plan<\/h2>
Before anything else, the current disaster recovery plan needs to be reviewed, especially if it\u2019s more than a year old. A plan that doesn\u2019t align with current needs requires an update. The DR lead will want to collaborate with leaders outside IT to determine which applications and functionality need to run; which hardware must be online; and what dependencies flow from those two requirements. \u201cIdeally, you\u2019ll walk away from these conversations with recovery time objectives and recovery point objectives that, in the event of a disaster, accommodate everyone\u2019s needs,\u201d he says. <\/p>

Get the C-suite on board<\/h2>
Getting leadership on board with the criticality of disaster recovery is crucial\u2014without such support, it will be a struggle to get other leaders in the organization to prioritize testing. Spell out the importance of having a plan that enables care delivery to continue in any eventuality. \u201cIf your C-suite already understands the importance of having a disaster recovery plan, make sure they\u2019re on board with the importance of testing,\u201d Dynowski notes.<\/p>

Stick a dollar sign on DR and testing<\/h2>
In talking to C-suite executives about stress testing, frame it in terms of dollars and cents: how long can your organization afford to have IT and other systems down? It\u2019s important to help leadership calculate potential revenue losses from each minute of downtime for various scenarios, not to mention the potential reputational hit that even relatively minor downtime can cause if handled wrong. DR leads also should provide insight about the many types of disaster recovery solutions and the various costs of each.<\/p>

Establish guidelines for real-life disaster recovery<\/h2>
A solid disaster recovery plan must include conditions that trigger it\u2014for example, give a team five hours to fix a problem before the DR plan is invoked, or if certain parts of an application go down (in other words, are they non-essential functions that an organization can temporarily live without). Guidelines should be based on larger business, so triggers will need validation from other stakeholders in the company. Non-IT employees should be enlisted to help during stress tests\u2014someone from each department should test the functionalities they depend on, and someone should be in charge of testing from a user\u2019s perspective.<\/p>

Plan the stress test strategically<\/h2>
Scheduled downtime can be an ideal time to conduct DR stress tests; when something goes wrong, the execs in charge can easily roll back to production and re-evaluate, recalibrate and update the plan. Disaster recovery is a whole-business effort, and any plan must work for the whole business. The whole business must participate in stress testing, and the plan and testing schedule should depend on the needs, budget and risk tolerance of the organization as a whole.<\/p>

","order":0,"get_parent":{},"attributes":[],"attributesType":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"dynamicContent":""}]

7 critical steps in testing a disaster recovery plan

More for you