Why Do I Need to Repeat Recovery Testing for GDPR?
As we saw in my last blog on recovery and GDPR, the relevant part of the regulation says a company must have:
“…. a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”
When I first read this, I was somewhat perplexed. It seemed strange that once you had proved both recoverability and recovery timeliness, that you would be asked to repeat that proof on request.
But then I realized that our IT world is in a constant state of change. Over time, an application might see:
- An increase in transaction volume
- An increase in data volume
- A change in the way customers interact with the application, introducing new “high priority” items
- A change in the technology supporting the application
- A new version of the database management system, the overall operating system, or the tools being used to manage the application and its data
- All of the above
Any one of these could compromise an organization’s ability to recover their data and maintain compliance with GDPR. It’s gratifying to see that the people who drafted the legislation realized that these changes are happening all the time, resulting in the need for repeated testing.
If you are using your disaster recovery (DR) strategy to support recovery compliance, then it could be possible to re-run your testing for GDPR at the same time as your next DR test, but that is likely to be time consuming and expensive to set up and execute. And don’t forget, the primary reason for a DR test is to prove recoverability in case of a disaster – trying to piggy-back compliance testing on the back of a DR test is risky, to say the least.
This is why BMC Software introduced ESTIMATION and SIMULATION to our software recovery portfolio.
ESTIMATION uses algorithms based on the way Db2 and IMS perform data recoveries, and on knowledge of the way data has been backed up to calculate an ESTIMATE of recovery time for a set of Db2 tables or IMS databases. Being a calculation, though, it’s really a best-case estimate of recovery time; it can’t account for many of the reasons for delays during recovery. However, estimation is quick to set up and equally quick to execute. It also doesn’t cost as much to run as a full recovery, so can be repeated as often as necessary.
It is also possible to do simplistic “what-if” calculations to model data growth and answer “would we still be compliant with 15% more data?”.
Estimation becomes a handy tool to get an understanding of recovery and recovery compliance, but it cannot provide the proof that GDPR requires.
Historically, the only way to prove recoverability and get an accurate measure of recovery times was to actually perform the recovery, which either meant costly disaster recovery-type tests, or making a production system unavailable for a while. BMC has a better way – recovery SIMULATION.
A simulated recovery does everything a real recovery would do, but does NOT overwrite the target data being recovered. So a successful recovery simulation proves that every object (Db2 table/index or IMS database) is recoverable, AND it delivers an accurate assessment of the time taken to do the recovery. Because a simulation is simple to set up and run, you can re-run it as often and as regularly as needed.
Lastly, it is possible to analyse the output of a recovery simulation looking for bottlenecks where time could be saved.
If you would like to learn more, please visit our GDPR page on the BMC website at www.bmc.com/info/mainframe-gdpr.html
Dummies Guide to Security Operations
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.
