Is DR testing (Disaster Recovery testing) introducing new risks?

If you are interested in disaster recovery testing then you should take a look at this article: Is disaster recovery testing putting your company at risk? So a new angle - testing introducing risk rather than merely gaining a better understanding of it or helping reduce it. Increasing risk! Savour that for moment.

The nub of the article is that during DR testing some organisations break the date replication process and this action introduces a new risk of lengthy data recovery delays if a critical problem strikes whilst the testing is running. And don't forget possibly breaching compliance. And don't forget compliance:

"...compliance legislation will remain a serious issue for companies for the foreseeable future. Regulations such as Sarbanes-Oxley, Government Securities Act Regulation 17, FDA 21 CFR Part 11 and HIPAA, increase compliance exposure for companies, and demand more aggressive measures to lower risk. In the case of a legal discovery, where companies may be required to submit company data as evidence, it is imperative that this information be factual, up-to-date, and compliant. If data is unavailable for several hours or days during DR testing, then companies will not be able to produce the requested information in the time required and may put your company at further risk for non compliance. "

But no need to despair. The article not only raises awareness on this issue but it helps identify how disaster recovery testing can run without introducing these risks. It concludes:

"Physical tape backup is no longer a viable option in an era of alarming security and compliance breaches. Peer-to-peer data vaulting is an improvement, yet businesses must have a way to ensure continuous data replication, even during disaster recovery testing. Taking a point-in-time snapshot of mainframe systems data alleviates these security and compliance exposures, as well as speeding up recovery time and giving organizations a powerful means to avoid system interruptions and possible costly downtime. "