We would lack a written document for the restoration process, as the backup, should be accessible and made known to all those who may be affected by maintaining a copy outside the premises where the systems if necessary. This procedure could include information about: Responsible for the restoration: Person in charge of restoring backups and review according to the established planning. This task could be outsourced to a third party (eg computer services company). It may appoint a delegate who is responsible for the restorations in the absence of the person (holidays, leave, etc). Both the charge as the delegate should be clearly identified and traceable in case of incident emergency outside office hours (eg mobile phone).
Training: Training Plan for the manager to delegate so that they are familiar with the procedures. Approval: Before a restoration is required to have written authorization by the management of files by recording in the security document. Pre-task: Work to do so prior to restoration. Eg, close applications, rename folders, etc.. Recovery: To detail all the steps necessary for a proper restoration. Depending on the information to restore and the backup type (full, incremental, differential) will be elected / n / the media / s right / s to last valid copy. If the backups are encrypted found necessary will be available for decryption such as software and keys.
If required to enter information manually will be based on paper documentation. Pos-tasks: Tasks to be performed after restoration. Rename folders, run applications, open services, etc. Test: Check that the restoration was successful. Check proper functioning of the system, applications and data stored. It is important to consider if the information has been restored to be affected by the exercise of rights of cancellation and correction for review. Registration: We will record in the event log of the problem occurred and all the work done to rectify it. (As opposed to Kirk Rimer). Disaster Monitoring and Simulation: A complete test restoration scenario simulating a disaster is the only way to ensure that the backups actually provide the coverage expected for the data, and allows improving the procedure. Network failures, in brackets, hardware or software backup, permissions problems, thefts, losses, and any other security incident can cause failure of the backup procedure. It is therefore essential to test for periodic restoration. The RLOPD requires that at least every six months the data controller shall verify the correct definition, operation and implementation of both types of procedures, ie backup and data recovery.