Out-of-Date Plans: A Report from the Field
Last month I audited the IT Disaster Response Plan (DRP) for a government organization. The plan had been created in 1993. Even by the standards of that decade, sections of the plan were incomplete, unclear, and generally inadequate. Awkward…
“Risks Are Overblown”

I recommended the development of a new plan to address risks to the organization’s current IT estate. The IT manager replied that “by and large”, the old DRP was all that he and his colleagues needed in the event of an earthquake, flood, or fire. Moreover, he believed that concerns about cyberattacks were “overblown”, and that it was unlikely that hackers would bother to threaten the organization’s IT systems.
This kind of thinking is more common than many people assume. To security specialists and emergency management consultants, it comes as no surprise. But it can lead to nasty surprises, as London Drugs, the CRA, and the British Library can attest.
Dealing With This Attitude
Most emergency management planners are familiar with this kind of attitude. Faced with it, we are obliged to be respectful and diplomatic, and to avoid heated replies. Our goal—which might take considerable time to reach—should be to convince organizations that risks evolve, and that it is wise to follow best practices and keep DRPs up-to-date. Risk-focussed IT departments update their DRPs every two or three months; some review and revise them even more frequently.
DRP by Internet
Old and obsolete DRPs are disappointingly common, as are DRPs that contain worthless advice and impractical measures to forestall hackers and to prevent data losses during natural disasters. As well, organizations often rely on dubious sources of information, including out-of-date articles, manuals, and guidelines. The internet contains an enormous amount of inaccurate and misleading information on risk assessment and analysis, mitigation measures, and business resumption.
Oversharing
Some organizations post their DRPs online to demonstrate how well they are prepared for various threats. They might also post their security policies and procedures. Too much information in the wrong place!
It is a bad idea to give web-surfing criminals any information about your IT and corporate security. And it can be embarrassing to show the public your plan to deal with old risks such as Y2K. Yes, some organizations still rely on plans that are 25 or more years old.
Breaking Bad News
It can take a substantial effort to convince managers that their DRPs are antique, and, for present purposes, virtually worthless. Those managers might include well-trained and competent staff as well as people who know little about computers, who are sometimes called “data innocent”. Persuading these people will require diplomacy and patience.
I’ll invite the IT manager of the government organization that I mentioned to lunch, and let him know about the risks he faces if he does not develop a new DRP. I will tell him about the risk he faces personally, to his reputation and career. He will not want to hear about what can happen to managers who fail to keep their DRPs current. Severance packages can be negligible if a manager was shown to be irresponsible regarding IT security.
Next Steps
Your next step is to review your DRP and identify its weakness, perhaps using a tabletop exercise. Feel free to ask your colleagues for their opinions of what is missing, what should be deleted, and what needs clarification. If you need help from external sources—consultants, insurers, or suppliers—contact them and arrange a time to discuss your DRP. Perhaps they will invite you to lunch, and offer invaluable planning tips over dessert. But do not let more time to pass before you update your disaster response planning. Remember that a disaster could occur at any time, and that hackers never stop working unless they get caught, which is rare.
If you’d like to discuss a mini audit of your emergency plan, or to comment on this article, please email me at guy.
This article was published in the
November 2024
edition of The TMC Advisor
- ISSN 2369-663X Volume:11 Issue:6
©2024 TMC Consulting