After completing a disaster recovery test, organizations must closely examine their DR processes from start to finish -- the good, the bad and even the ugly. And in order to do so, proper documentation must be recorded throughout, and after, the DR testing process.
Participants in our recent SearchCIO DR-themed tweet jam said that disaster recovery testing can be fraught with error. Once organizations finally get through the actual testing phase, SearchCIO asked #CIOChat-ters, "What should be in a post-test after-action report?"
An initial response was succinct and simply put:
A3: what didn't work! need to examine failures to avoid them again and successes to repeat them #CIOchat— Denise Dubie (@DDubie) June 25, 2014
One participant suggested that an after-action review include stats on recovery point objective (RPO) and recovery time objective (RTO):
In disaster recovery (DR) and business continuity (BC), RPO defines the age of files that must be recovered from backup in order for normal business operations to resume following an incident. Once RPO is defined, it determines the necessary frequency of backup for an organization's systems. RTO refers to the maximum tolerable length of downtime for compromised systems.
Understanding the effectiveness of disaster recovery plans through careful after-action review examination will help determine both RPO and RTO, but that's not all. According to our tweet jammers, there is a long list of documentation to include in a DR test evaluation, and it's important to extract it as quickly as possible:
One #CIOChat-ter suggests DR testers consider splitting their reports into more focused sections for each department or tested system:
#ciochat A3: Multiple reports/sections w/ diff. audiences from a straight pass/fail down to every timing and glitch. Lots of stakeholders.— Forvalaka41 (@Forvalaka41) June 25, 2014
Echoing similar comments about potential sources of DR failure, a tweet jammer advised organizations to be honest about where they might be drawing unsubstantiated conclusions:
With all that said, businesses tend to be less concerned with the specifics and more concerned with the bottom line. Hard numbers in an after-action report can bolster the case to higher-ups that DR testing is worth the investment:
Demonstrating what there is to lose in system downtime -- and what can be gained in disaster recovery testing -- is an important aspect of after-action reporting. Is your organization focused on post-test reporting to the business? Is your after-action review and report as thorough as tweet jammers suggest it should be? Sound off below in the comments section.