There is a tendency to believe that once disaster recovery measures have been taken and systems brought back into operation, a disaster recovery manager’s job is done (apart from planning and preparing for future incidents). However, much like patients leaving hospital after an operation, vigilance is crucial. Complications and relapses can happen unexpectedly. Vulnerabilities can be created unintentionally
So, while you may be congratulating yourself for having properly backed up not only your business data, but also your application and configuration data, it’s important to check the following points for a truly effective and durable recovery.
- Check that employees know they can (and should) get back to work. Don’t rely on employees to constantly ping servers to see if they are running again or for telepathy to magically make people aware that everything is now working. Tell them, preferably by sending them an alert (a text message, for example) that they are likely to receive and action immediately.
- Check that system linkages have been properly restored. Complex networks of interlinked systems mean that risks increase that one or more servers are restored in a working state, but disconnected from the others. Watch out for hybrid cloud configurations with part of a use case on premises and the other part “somewhere up there”. That includes SaaS applications users have subscribed to without the blessing of the IT department. Yes, shadow IT it may be, but it’s still IT and you’ll be expected to help put things right.
- Check if backup and failover systems are still running in the cloud (for example). Cloud-based disaster recovery can be a boon and help people start being productive again as soon as possible. However, if they are supposed to take over just temporarily from on premises systems, users and their data will have to be brought back inside the corporate perimeter. Cost and security are two key factors here. Even if you decide to keep the cloud-based solution running, make sure it’s a deliberate business-based decision, rather just than a case of IT inertia.