For IT leaders, these events highlight an important question:

If your team couldn’t access the office tomorrow, could your business continue operating?

Disaster Recovery Plans (DRPs) and Business Contingency Plans (BCPs) are often written to satisfy compliance requirements or insurance audits. Unfortunately, many organizations don’t revisit them until an actual emergency exposes the gaps. The reality is today’s business environment changes far more quickly than annual documentation updates can keep pace with.

The widespread Canadian wildfires are a timely reminder that every organization should review, test, and update its disaster recovery strategy at least once every year.

Disaster Recovery Isn’t Just About Technology

When many organizations think about disaster recovery, they immediately focus on backups, cloud infrastructure, and server redundancy.

Those are certainly critical components, but they’re only part of the picture.

A comprehensive Disaster Recovery Plan should answer questions such as:

• What happens if your office becomes inaccessible?
• Can employees securely work remotely?
• What if key members of your IT team are personally affected by the disaster?
• Are critical vendors able to continue supporting your systems?
• How quickly can business-critical applications, including legacy systems, be restored?
• Who has decision-making authority if leadership is unavailable?

Natural disasters rarely affect only one component of an organization. They impact people, communications, transportation, utilities, supply chains, and customer expectations simultaneously.

The Government of Canada’s Public Safety Department recommends that business continuity planning address ‘all hazards,’ including natural disasters, utility outages, pandemics, and cyber incidents because these events can have cascading operational impacts.

Annual Reviews Matter More Than Ever

Technology changes rapidly. Your Disaster Recovery Plan should evolve just as quickly.

Over the course of a year your organization may have:

• Migrated systems to the cloud
• Implemented new SaaS platforms
• Changed cybersecurity tools
• Replaced networking infrastructure
• Overhauled a legacy system
• Implemented AI tools
• Added new remote workers or new technical staff
• Lost institutional knowledge through employee turnover

If your DRP still references retired servers, former employees, or outdated vendor contacts, it can’t be relied on during an emergency.

The National Institute of Standards and Technology (NIST) recommends organizations maintain, review, and regularly test contingency plans whenever significant technology or organizational changes occur.

Similarly, ISO 22301, the international standard for Business Continuity Management Systems, requires organizations to regularly exercise, evaluate, and continually improve their business continuity plans to ensure they remain effective as business conditions evolve.

A plan that has never been tested is just a theory.

The Human Side of Disaster Recovery

Natural disasters, like wildfires should remind us that technology doesn’t work without people.

The impact is real:

• Employees may be displaced from their homes.
• Internet connectivity may become unreliable.
• Schools may close unexpectedly.
• Staff may need time away to care for family members or evacuate affected areas.

Building resilience means recognizing that your people are your most valuable resource.

Research from Deloitte’s Global Resilience Report consistently shows that organizations with mature resilience programs place equal emphasis on people, operational processes, technology, and external partnerships when preparing for disruptions.

Cross-training staff, documenting critical systems, and ensuring multiple people understand key applications reduces reliance on individual employees during emergencies.

Good documentation becomes invaluable when your subject matter expert is displaced or simply isn’t available.

Third-Party Partners Should Be Part of Every DRP

One area that organizations frequently overlook is the role of trusted external partners.

Even the best internal IT teams have limits.

If multiple team members are unavailable during an emergency, projects don’t stop, production systems still require support, and customers continue expecting service.

This is where strategic third-party partners become an essential part of business continuity.

According to Gartner, organizations are increasingly adopting ecosystem resilience strategies that include trusted technology partners to improve operational continuity and reduce recovery times during business disruptions.

Rather than scrambling to locate emergency assistance during a crisis, organizations should establish relationships with experienced technology partners before they need them.

Trusted third-party vendors can provide:

• Emergency application support.
• Additional development resources.
• Legacy system expertise.
• Infrastructure troubleshooting.
• Production monitoring.
• Software maintenance.
• Documentation assistance.
• Quality assurance and testing.
• Knowledge transfer for critical systems.

Having these relationships already in place can dramatically reduce recovery time while easing pressure on internal teams. Think of your external technology partner as an extension of your own IT department; not just a vendor you call when things go wrong.

Where STEP Software Fits into Your Recovery Strategy

Business continuity isn’t only about recovering servers; it’s about ensuring your business can continue delivering value to customers.

Here at STEP, we’ve spent more than 20 years helping organizations support, maintain, modernize, and extend business-critical applications.

Whether your environment includes modern cloud platforms, aging legacy systems, custom business applications, or a combination of technologies, having experienced specialists available can significantly reduce operational risk during unexpected disruptions.

Our team can assist organizations by providing:

• Third-party application support.
• Legacy software expertise.
• Software maintenance.
• On-demand development resources.
• Knowledge transfer and technical documentation.
• Quality assurance services.
• Custom software enhancements.
• Long-term modernization planning.

We routinely work alongside internal IT departments, meaning we can integrate into existing teams quickly when additional capacity is needed. This flexibility becomes especially valuable during periods of unexpected disruption.

Don’t Wait for the Next Emergency

The best DRPs are written during calm periods, not during emergencies.

The Canadian wildfires remind us that organizations cannot predict when the next disruption will occur, only that another disruption is inevitable.

Whether the challenge is a natural disaster, cyberattack, prolonged power outage, infrastructure failure, or critical staffing shortage, resilient organizations prepare before they need to respond.

Take the opportunity to review your DRP this year with a special focus on:

• Verifying your contact lists.
• Reviewing vendor agreements.
• Testing your backup and recovery procedures.
• Validating remote work capabilities.
• Updating documentation.
• Identify single points of failure.

Finally, ask one question:

If something happened tomorrow, would your organization have the people, processes, technology, and trusted partners needed to continue serving your customers?

If the answer isn’t a confident ‘yes,’ now is the time to strengthen your plan.

Drop us a line if you need help fortifying your DRP.

The post Canadian Wildfires Are a Wake-Up Call: Why Every IT Leader Should Review Their Disaster Recovery Plan first appeared on STEP Software.

The State of Hawaii calls its All-hazard Statewide Outdoor Warning Siren System the “largest single integrated public safety outdoor siren warning system in the world.” It has over 400 solar-powered sirens – 80 of them on the Maui archipelago – capable of alerting residents to a wide range of natural and human-caused events, such as hurricanes, tsunamis, volcanic eruptions, floods, terrorist threats, and wildfires.

The sirens are a critical part of the more broadly scaled Statewide Alert and Warning System (SAWS), which uses the Federal Emergency Management Agency’s (FEMA) Integrated Public Alert and Warning System (IPAWS), the Emergency Alert System (EAS), and Wireless Emergency Alerts (WEA). The integrated system warns the public of threats over a range of platforms, including cell phone networks and media, and is tested on the first day of each month by emergency management and civil defense agencies, as well as local radio and TV broadcasters.

Reports from wildfire victims, however, confirm that the sirens were not activated, and cell phone alerts went out late, if at all, and rather than ordering an evacuation, they simply warned of the risks of strong winds and possible fires. Amber alert-like messages – with loud alarms on recipients’ devices – were not sent.

The silence was almost by design, with Maui Emergency Management Agency Administrator Herman Andaya defending the decision to not activate the sirens. In an interview with Honolulu Star-Advertiser, he said the system is largely used for tsunamis – not wildfires – with residents trained to move to higher ground when they hear the sirens.

“Had we sounded the siren that night, we were afraid that people would have gone mauka (toward the mountain),” he said, echoing concerns that panicked residents might have instead headed straight into the flames. The siren network also included no equipment on the side of the mountain, and Andaya said residents likely wouldn’t have heard them anyway because they were inside their air-conditioned homes, surrounded by high winds that would have drowned out the sound.

A FAILURE OF TECHNOLOGY AND PROCESS

Following widespread criticism of his decision to not activate the system, Andaya resigned from his post. Hawaii’s Attorney General, Anne Lopez, has announced a comprehensive investigation into the lead-up to the fires, and the decision-making among government and emergency response resources as the situation worsened.

But the ripples from this tragedy are already racing far beyond the island state’s borders.

This isn’t a failure so much of a particular technology as it is a realization that for all the state’s advance planning, it simply wasn’t enough. The processes that led to officials on the ground deciding not to activate a critical piece of warning infrastructure were based on planning that failed to anticipate the scope of a rapidly changing environment – one permanently altered by climate change.

The system also relied heavily on components, such as cell phone networks, that lacked sufficient redundancy in the event of wildfires. For example, wireless and 911 services were compromised as the fires burned through ground equipment, forcing officials to rely on broadcast media and word of mouth.

Maui County Police Chief John Pelletier told CNN, “Nobody saw this coming. Period.”

WHERE WE GO FROM HERE

While it may be true that nobody saw this coming, it’s equally true that disaster planners in all organizations are responsible for understanding where tomorrow’s threats will come from – and planning risk mitigation around them. It’s their job to see these things coming.

This extends beyond one state, one town, and one event. Organizations everywhere would do well to learn the lessons of this event – and must crack open their DRPs to assess where they fall short.

The Maui wildfires, in particular, highlight shortcomings in a number of areas, including communication protocols, resource allocation, risk assessment, training, stakeholder integration, data backup, testing and validation. Especially worrisome is the failure to recognize the lack of redundancies in advance, and the limited scope of recurring training that potentially lulled residents, government officials, and emergency responders alike into a false sense of security.

But this also opens up opportunities for technology leaders to lead the conversation within their own organizations about the scope of disaster recovery and business continuity efforts – and what must be done to keep them relevant and robust amid a fast-evolving natural and business landscape.

In that regard, this traumatic event could lead to better future preparedness across a much broader swath of society – including the organizations where we work. But only if we allow it to, and only if we prioritize it.

THE BOTTOM LINE

There is no doubt that this is a national tragedy that will have serious implications for emergency response teams and protocols, as it should. Opportunistic technology leaders are – or should be – already asking the hard questions about their own disaster preparedness, particularly around whether the scope of their original effort is enough to accommodate current and future realities.

As robust as we think our own DRPs may be, rest assured they, like the well-intentioned plans in Maui, have their own unseen gaps. And it’s those gaps that mean the difference between a plan’s success or failure. Give us a call anytime if you’d like to brainstorm ways to mitigate your own risk and ensure your DRP is ready for whatever comes next.

The post Maui wildfire alert system failure highlights critical gaps in disaster planning first appeared on STEP Software.

The Federal Aviation Administration has confirmed the event was triggered by an employee error that caused a corrupt file in the NOTAM system’s database. Worse, the backup system that would have been used to restore the database also contained the same corrupt file.

This should make IT practitioners cringe – I know I sure did. That’s because the presence of a corrupt backup strongly suggests the FAA’s disaster recovery plan (DRP) had likely not been tested in the leadup to this failure. Because the only way IT leaders would have known they had a problematic backup would have been if they had walked through a test-recovery scenario.

In this case, the undiscovered corrupt backup guaranteed a much longer recovery in the event of an outage – which is precisely what played out.

In the weeks and months ahead, FAA officials will undoubtably be held accountable as the U.S. Department of Transportation moves ahead with its investigation. And rightly so, as this colossal debacle sidelined thousands of flights in the U.S. and slowed service from dozens of countries worldwide.

But we don’t have to be working in the aviation industry to appreciate why understanding this event is so critical to any organization that uses technology.

THE UNIVERSAL TRUTH

We all (should) have DRPs – or business continuity plans (BCPs) – in one form or another. In a report from iLand and Zerto, only 54% of survey respondents said they had a full, company-wide DRP in place.

That’s a frightening figure. And in 2023, we’re long past the point where technology is a luxury. It is a critical pillar of every organization’s ability to deliver, compete, and survive. And organizations that choose to fly without a DRP are quite literally playing with fire.

With this in mind, it’s safe to say we can all be doing more to incorporate the potential for failure into our technology and business planning processes, and ensuring the DRP is a core piece of our IT strategy and culture.

A well-formed DRP understands what can fail, how it can fail, and in what context. But simply documenting what can go wrong isn’t enough. While documenting failure modes is crucial, the actual document can’t simply be something that gets tossed onto a shelf and dusted off every once in a while, if at all.

Any reasonable DRP must incorporate recovery, as well – steps the organization must take to ensure continuity in the event of a natural, accidental, or human-caused disaster. The recovery component should identify specific accountabilities, communication flows, and checkpoints. Ideally, it will include a detailed schedule for real-world recovery testing, with recommended intervals to ensure key leaders, staff, contractors and other stakeholders are conditioned to execute the plan if and when an actual disaster occurs.

The FAA learned the hard way that recovery testing, like a good insurance policy, can save heartache later on. Any organization runs an elevated risk of losing revenue, alienating customers, and damaging the brand if it fails to have the appropriate disaster response resources and capabilities in place. 

THE BEST ADVICE I EVER RECEIVED

Earlier in my career, I was an IT project manager and application development support lead. My mentor at the time said we had two choices when considering how we wanted to support the business areas that relied on us: We could either plan to fail, or we could fail to plan.

The FAA now finds itself on the wrong side of my mentor’s guidance. It needs a better plan, and it needs to test that plan to ensure it’s ready for the inevitable. That means looking at the 30-year-old system at the center of this debacle and fast-tracking plans to update it to current-century standards – and doing so not six years from now, as currently planned, but now.

It also has implications for the rest of us, in any organization and in any industry. Because we need to plan our own plans, too. Because eventually, we’ll all find ourselves needing to recover from an outage or an attack, and no one ever wants to find out the hard way that their backups can’t be restored.

If you’re not sure where your own DRP stands, we’re always here to help you get started.

The post FAA NOTAM outage should scare all of us into (finally) testing our DRPs first appeared on STEP Software.

Begin developing your disaster recovery plan by identifying the potential risks to your IT infrastructure. Possible dangers may include events like hardware failure, power loss, cybercrime, fire, or flood. In some cases, the type of risk will dictate the appropriate DRP action. If you identify hurricanes as a risk, for example, your DRP would need to include a provision for moving your operation to an alternative, unaffected site.

2. DOCUMENT ALL YOUR IT RESOURCES

You will need to make a full inventory of all your IT resources. This inventory should include all your hardware, data, and applications. You will also need to know which skills will be required to recover each of these resources should they be lost. When you are preparing your inventory of resources, it is imperative to be thorough. Even a small application or data file could be a critical element of your overall IT system.

3. PRIORITIZE THE RECOVERY

The next step in your disaster recovery planning should be to prioritize the order in which you will need to bring your computer systems back online. This prioritization will be based on how critical each application is to your business. You will need to consider any interdependencies between your various applications. It’s helpful to create a timeline for getting each system operational again.

4. ASSIGN A DISASTER RECOVERY LOCATION

Should your business premises become unusable, you will need to procure an alternative location. It would be best to identify a suitable place to run your business from, before you need it, as a part of your DRP. If you already operate your business from multiple locations, you could consider designated space in your existing premises as a disaster recovery location. Or, if you work from a single site, you could investigate the option of taking up a short-term lease in a local serviced office facility.

5. PLAN THE ACQUISITION OF REPLACEMENT HARDWARE

A large company may maintain a full suite of hardware off-site as a part of its DRP strategy. However, a smaller enterprise will probably need to acquire new hardware in the event of a disaster. Speed will be of the essence when you are recovering from an IT disaster. So, include in your DRP several reliable sources of replacement hardware.

6. CREATE A DATA AND APPLICATION BACKUP PLAN

A crucial part of any disaster recovery plan is the backing up of data and applications, and, of course, ensuring that backups are held off-site. Your inventory of IT systems will have identified all the critical data that needs backing up. Your DRP will need to document the order in which systems and data will need to be restored. Backups of essential data should be taken on a grandfather-father-son basis, a backup rotation system that uses different media for each backup to guard against data corruption.

7. APPOINT A DISASTER RECOVERY TEAM

To ensure a smooth recovery from a disaster, you will need to appoint personnel to a disaster recovery team. Each team member should know their role and be fully versed in the recovery plan. If you can, it would be best to designate backup members for each of the team’s functions to cover for employee absences. You will also need to document the lines of authority and communication in your DRP.

8. WRITE A DETAILED DISASTER RECOVERY PROCEDURE

Your disaster recovery plan should include detailed procedures for the restoration of your IT systems. It is not sufficient to have an action point of “Restore Finance System,” for example. A DRP needs to include instructions on how the system is to be restored. Documenting procedures in detail will ensure that critical systems can be brought back online, even if key employees are absent from work.

9. TEST YOUR DRP

What looks good in theory may not work in practice. So, you need to test your DRP regularly. Carrying out frequent tests of your disaster recovery plan will help ensure that systems will be fully restored within the targeted timeframe. Testing will also provide employees with the opportunity to practice their disaster recovery roles.

10. KEEP YOUR DRP CURRENT

Finally, last year’s disaster recovery plan is unlikely to meet your needs in the coming years. So, someone will need to be appointed to keep your DRP up to date. The DR manager will need to be notified of all new hardware and software added to your IT resources and of any changes to the location and setup of systems. Risks to your IT infrastructure will need to be regularly reviewed and documented as well.

CONCLUSION

Some of the above steps may be overkill for a small business. However, the principles contained in each point can be scaled to fit smaller organizations. The crucial point is that, regardless of business size, having an up-to-date disaster recovery plan will help minimize the disruption to business that an IT disaster can cause.

If you looking for the Best Custom Software development for any complex problem in your technology. Please mail to support@stepsoftware.com

The post 10 Tips for Developing a Disaster Recovery Plan (DRP) first appeared on STEP Software.