As we move into CIS Control 11, Data Recovery, we’re shifting from preventing and detecting problems to something every organization eventually has to face: what happens when something goes wrong.
Safeguard 11.1 is Establish and Maintain a Data Recovery Process. CIS expects that process to address the scope of recovery activities, recovery priorities, and the security of backup data. The documentation should also be reviewed at least annually or when significant changes occur.
That sounds straightforward. In practice, it forces an organization to answer some uncomfortable questions before the answers are urgently needed.
I learned that lesson the hard way.
A lesson from before cybersecurity
Long before I worked in cybersecurity, or even held my first network administration position, I was responsible for building and maintaining the computer systems for my family’s business. This was the 1990s. I knew enough to get the systems running and make them useful, but I knew nothing about backup strategy, disaster recovery, business continuity, or any of the terminology I’d eventually use professionally. At the time, I didn’t really know that I needed to.
I’ll never forget the day someone told me they couldn’t access the shared drive on our server. I went to look at it and heard an ominous clicking noise coming from the drive. If you’ve worked around computers long enough, you probably already know where this story is going.
We lost it all. Accounting data, marketing files, production information, and years of accumulated business records disappeared with that drive. Because this was the 1990s, we still had paper records for most of it, and we were able to reconstruct portions of what we lost. But reconstruction isn’t recovery. We lost hundreds and hundreds of hours recreating information that should never have been lost in the first place.
I didn’t know it then, but that was my first lesson in data recovery. The worst possible time to decide how you’re going to recover critical information is after it’s already gone.
Having backups isn’t the same as having a recovery process
When I ask organizations about data recovery, the first answer is often some version of, “We have backups.” Good. You should. But that doesn’t answer the whole question.
A backup is a copy of data. A recovery process explains what the organization plans to do when production data or systems are no longer available. It defines what needs to be recovered, who’s responsible, and what gets restored first.
That distinction matters because not everything has the same importance to the organization. Payroll may become a business problem very quickly. An archived marketing folder may be able to wait. A production system supporting manufacturing may have entirely different recovery expectations than a departmental file share. Those priorities should be decided before an incident forces people to make them under pressure.
What actually needs to be recovered?
One of the first questions a recovery process should answer is scope. Organizations accumulate technology over time. Servers get added, applications move to the cloud, departments purchase SaaS products, and critical information ends up in places that weren’t part of the original backup plan.
If you haven’t identified what’s actually important to the business, it’s easy to discover after an incident that something everyone assumed was protected wasn’t included at all.
This is another place where the earlier CIS inventory controls begin to pay off. Asset and data inventories help identify the systems and information the organization depends on. Data recovery should build from that knowledge. The question isn’t simply, “What can we back up?” It’s, “What do we need to be able to recover?”
Recovery priorities are business priorities
IT can explain technical dependencies and how long a system might take to restore, but IT shouldn’t make every recovery priority in isolation. Accounting, operations, customer service, and other business functions understand which systems their work depends on and how long they can reasonably operate without them.
During an outage, every department will understandably believe its system is the most important one in the company. A documented recovery process gives the organization an agreed starting point instead of forcing leadership and IT to negotiate priorities while systems are already down.
Someone needs to own the process
Like most governance controls, recovery requires ownership. Someone needs to be responsible for maintaining the process, coordinating recovery activities, and making sure the documentation still reflects the environment. That doesn’t mean one person performs every recovery task. Internal IT, an MSP, application owners, cloud providers, and other vendors may all participate.
What matters is that responsibilities are understood. If the recovery plan assumes the MSP will restore a system while the MSP assumes the customer owns that responsibility, that misunderstanding won’t become apparent at a convenient time.
The same applies to cloud services. Moving an application or data to the cloud doesn’t automatically answer the recovery question. You still need to understand what the provider protects, what you’re responsible for, and how recovery is expected to work.
Recovery data still needs protection
CIS 11.1 also expects the recovery process to address the security of backup data. That matters because recovery copies often contain the same sensitive information as the production systems they protect. They may contain financial information, employee data, intellectual property, customer records, or nearly everything else the organization considers important.
The detailed safeguards for protecting and isolating recovery data come later in Control 11. For 11.1, the important point is that security has to be part of the recovery process from the beginning.
The process has to change when the business changes
A recovery plan isn’t something you write once, put in a binder, and declare finished. CIS requires the documentation to be reviewed at least annually, and when significant changes occur that could affect recovery. A cloud migration, acquisition, new business platform, change in service providers, or substantial infrastructure change can make yesterday’s recovery process inaccurate very quickly. That documentation needs to describe the environment you actually have, not the one you had three years ago.
A place to start
If you don’t have a documented data recovery process today, start with the business rather than the backup software. Identify the systems and data the organization depends on. Determine which ones need to come back first. Document who’s responsible for coordinating recovery and who needs to be involved. Make sure the process accounts for systems managed internally as well as those hosted or managed by third parties. Address the security of recovery data and establish a schedule for reviewing the process as the organization changes.
The safeguards that follow will get into automated backups, protection of recovery data, isolated recovery copies, and eventually testing whether recovery actually works. Safeguard 11.1 comes first for a reason.
Early in my career, I learned what happens when an organization depends on data without having a plan for getting it back. Technology has changed dramatically since the 1990s, but that lesson hasn’t. Backups matter. Recovery matters more.
