Prepare recovery before you have to improvise it.
When a critical service stops, decisions have to be made quickly, sometimes with incomplete information. The disaster recovery plan aims to organise those decisions and the operations required.
Define what must restart first.
The technical priority is not always the business priority. We start with essential activities, their dependencies and the people able to confirm they are working. These elements guide the scenarios to prepare.
Bring together the conditions for restarting.
Data, equipment, access, applications and the people involved all play a part in recovery. The scope of our support specifies the documents to gather and the points that need further action. A list of backups does not replace this organisation.
Write a document people can use.
Who decides to trigger recovery? Who contacts partners? How are progress and business checks tracked? The answers must be accessible to the people concerned, including when the usual tools are unavailable.
Prepare a suitable exercise.
A tabletop scenario discussion and a technical test operation do not have the same impact. The arrangements are agreed with you. Lessons from the exercise help identify documents or dependencies to correct, without announcing a recovery time that has not been demonstrated.
Applying this to your line of work.
Food industry: Production, quality and shipping uses, with the physical and operational constraints of the site.
Medical transport: Call handling, administrative tools and confidentiality boundaries to define.
Your questions
Is a written plan enough?
It provides a framework, but it must be kept up to date and consistent with the resources actually available.
Can you give a standard recovery time?
No. It depends on the scenario, the systems and the resources tested. Objectives must be set for your environment.
Got a digital issue? You don’t have to work out who should handle it.
Describe your situation in your own words. The Skill Group team will get back to you to talk it through.