From time to time companies go through audits for various reasons.  In some cases, we’re the party performing the audit.  In other cases, a third party is performing the audit and we’re a participant from the technical team.  It’s a mixed bag because audits aren’t fun.  And no matter when you schedule them, it’s an inconvenience.  Rarely do I see both parties genuinely interested in the process or the outcome.  And let’s be honest, someone is questioning someone else’s ability to do their job.

That said, having been on the frontline of a disaster recovery or two has taught me to take audits seriously.  Particularly when it comes to backups because a company can survive many obstacles but data loss typically isn’t one of them. 

When I’m the auditor, no matter the type of audit, in almost every case, I want to start with backups:

Do you perform regular backups?  If so, how often?
How often do you monitor the backups?

What type of backups are being performed?
If the building burns to the ground, do you have off-site copies of your backups?  If so, where are they stored?
If I wanted to restore a file from six months ago, would you be able to recover the file?
Do you test the restore function?  If so, how often?
Can I see a copy of your written backup procedures and your disaster recovery plan.

I wouldn’t limit my questions to the above but it gives me a general idea of the backup process.  From here, I would ask about the critical pieces of infrastructure and the stakeholders.

In my interviews, I learn the engineering group takes up the majority of the file server and their tolerance for data loss is at most “a few days”.  I also learn the controller is the key stakeholder for the ERP system and anything more than a day would be catastrophic.  And finally, while everyone is a stakeholder with regards to the mail server, I uncover that the CEO lives out of her mailbox.  She uses it like a file server as well as all of the other collaborative aspects one would normally find in a mail server and loss of data would be a devastating blow to the company.

With that information, I now circle back to what I know and I evaluate the process against what I’ve learned.  In a perfect world, you would talk with stakeholders prior to building the backup process but that’s not how it normally works.  Somebody, at some point long ago, developed the process and rarely is the process questioned until there’s an actual loss of data.  After going through the audit, perhaps I determine the process is sound at which point I sign off on it.  Otherwise, I’ll make recommendations for improving the process based on what I’ve learned. 

In either case, I am doggedly in pursuit of the truth and I will make you prove the process works because I take backups and data loss seriously.  I’ve been called in to help with disasters and there’s no worse feeling than telling the client their data is gone.  It’s a horrible feeling and if I never have to experience it again, the last time it occurred is still too soon. 

A buddy I worked with many years ago would say – it’s not a backup solution, it’s a restore solution.  That’s a really good way of thinking about it and if you’re not clear about your disaster recovery plan, the two questions you need to ask are: 

What is our tolerance for data loss?
Will our backup process match our expectations for recovery?

If you need assistance with building your backup procedures, auditing your backup process, or managing your backups, please reach out to us!