Disaster recovery planning involves far more than simply the recovery itself. Here are six important considerations your MSP clients need to make.
Being prepared for a disaster starts with a plan.
A solid Disaster Recovery plan makes your MSP clients' businesses resilient to IT disruptions and able to restore their services in case of disaster with minimal to no impact on users and business operations.
This is more than just making regular backups. It's a complex IT infrastructure assessment and documenting (including hardware, software, networks, power and facilities), business impact analysis of applications and workloads and planning on staff, roles and risk assessment.
As their MSP, you'll have a trusted advisory role in helping your customers develop their Disaster Recovery Plan.
While there are a wide range of inclusions, here are six critical considerations your clients should make when developing a robust Disaster Recovery Plan.
1. Define roles and responsibilities
IIt is imperative that all stakeholders in the Disaster Recovery Plan are aware of the roles and responsibilities they have in carrying out the plan. They should have their contact information and everything they need to perform their tasks laid out in detail.
This is not only so that they can be reached in the event of a disaster, but also for accountability and evaluation of the plan itself after execution. There should also be backup personnel for important decision-making roles.
2. Storage considerations
You must identify the cost and storage utilization of the disaster recovery solution you plan to implement. These will allow you to set aside the necessary resources to have the plan run as smoothly as possible. For example, snapshot-based replication incurs an average overhead of 20-30% of total storage, whereas journal-based continuous data protection only requires 7-10%.
3. RPO/RTO requirements
The Recovery Point Objective (RPO) and Recovery Time Objective (RTO) targets must be set based on the SLAs and the total costs associated with business downtime.
RPO describes the maximum amount of data that can be lost in an incident before there is an unacceptable impact on business. In contrast, an RTO is the duration of time and service level within which a business process must be restored after notification to avoid unacceptable consequences associated with interruption.
They must also be reasonable based on your disaster recovery needs—if you’re inadvisably running backup-based DR for high-availability systems, your clients need to be aware that tighter RPOs mean signiﬁcantly higher overhead.
4. Login management
Disaster recovery requires access to very sensitive parts of your system, so having it be highly secure is imperative. However, it’s equally important for the secure login information to be accessible even if a key stakeholder is on vacation or otherwise unavailable.
Make sure that there are several backup personnel who have the necessary logins to initiate the Disaster Recovery Plan.
5. Set a testing schedule
All data security and management standards imply testing as a mandatory exercise. You can never know if everything will work as expected in cases of real disasters until you try it and run the planned procedures in advance. A disaster simulation will also allow you to ensure that your clients' personnel are well-prepared for outages and other scenarios.
Those stakeholders who have roles and responsibilities set out in your client's DR plan is aware of the activities they need to perform. Perform complete training drills that test the DR team’s performance and make sure they match your RPO. This will also help them practice their roles and perform their jobs better in the event of an actual disaster.
Any issues faced during DR testing, whether they're human or software-related, represent good opportunities to discuss with your client how to fix up their Disaster Recovery Plan accordingly. This can potentially avoid or minimize serious disruptions in their business continuity in the future.
You need to set a regular testing schedule of at least once a year to ensure that your failover and other DR capabilities are working as planned. Testing outcomes generally need to be kep as part of compliance documentation.
6. Ensure compliance documentation
Ensure that the status and location of sensitive information, essential documents, and other data required for compliance are all recorded and easily accessible by the DR team.
Depending on your client's industry, there may be different legislative or regulatory requirements. Most industries have regulatory obligations regarding reporting, documentation, and future protection against further instances. This might include ISO 20000-1, PCI/DSS, HIPAA/HITECH or SOC compliance, such as SSAE 18 SOC 1, SOC 2, and SOC 3.
If your client's business is subject to regulations which require reporting after an outage or breach, this will absolutely need to be included.
You need DRaaS in your MSP toolkit
Traditional backup only protects a segment of data. That's why our practical and free white paper Most MSPs Have Inadequate Disaster Recovery Solutions outlines everything your MSP needs to know about the importance of DRaaS.
Simply click below to download your copy today!