DavsDisorder

Similar to a post from a few weeks back, I found this little summary amongst some old client correspondence which you may find useful.

8 Steps to Effective DR Planning and Budget Requisition

1. Use the term Disruption Recovery rather than Disaster Recovery.
2. Ensure you currently have some kind of DR/BCP management framework no matter how rudimentary. Show business management that there are current documented processes, metrics and testing that can be optimised. Technology supports the business insurance requirements, it doesn’t necessitate it. You need to show that DR planning is an ongoing process not a point in time flight of fancy.
3. Engage the right people in your organisation. Applications support and owners, facilities management, and of course, when ready, financial and executive management.
4. Conduct a joint Business Impact Analysis or Risk Assessment. What are we insuring/protecting against...delineate the actual dangers. Threats = Impacts = $$.
5. Then proceed to a ‘costs of downtime’ calculation. Dependency mapping of all business applications is the starting point for this. This is never a clean cut equation but, the revenue that a particular application or ecosystem of applications support is the dividend, downtime impact is the divisor and roughly speaking then the cost of downtime is the quotient (which should align roughly with a budget!)
6. Position a DR investment as having some competitive market value – ROI. Present ‘best-in-class’, industry peer data. – Reputational loss, client retention may be affected.
7. Develop a DR services catalogue...align costs to system criticality (RPO/RTO). Relative costs vs. Absolute costs wherever possible. Suggest chargeback to Bus etc.
8. Align DR investment with other IT budgets. Try and link the technologies used in providing DR services to other areas of IT ‘spend’. EG Data centre consolidation, server consolidation (virtualisation), and utilising DR infrastructure for development or test purposes.