In Safeguard 11.1, we talked about establishing a data recovery process. Before something fails, the organization needs to understand what has to be recovered, what comes back first, who’s responsible, and how recovery is supposed to work. Safeguard 11.2, Perform Automated Backups, takes the next step.
CIS requires automated backups of in-scope enterprise assets at least weekly, or more frequently based on the sensitivity of the data. The word “automated” is important. If protecting critical data depends on someone remembering to perform a backup every Friday afternoon, eventually someone won’t.
But automation is only part of the discussion. You also have to decide what gets backed up, how often it happens, and what type of backup makes sense for the environment you’re trying to protect.
Manual processes eventually fail
People take vacations. They get sick. Emergencies happen. Friday afternoon arrives and somebody has six other things to finish before leaving. A backup process that depends entirely on one person remembering to start it introduces a failure point that doesn’t need to exist. Automation takes that particular problem off the table. Once the backup jobs are configured, they run according to schedule without waiting for someone to remember.
That doesn’t mean automation eliminates responsibility. Backup jobs can fail. Storage can fill up. Credentials can expire. A system can be added to the environment without being added to the backup process. Automation makes the activity repeatable, but someone still needs visibility into whether it actually happened.
Frequency is really a business question
CIS establishes weekly backups as a minimum, with more frequent backups based on the sensitivity of the data. In practice, most organizations are going to need something far more frequent than once a week. The useful question isn’t simply, “How often should we back this up?” It’s: How much work can we afford to lose?
If a system is backed up every night and it fails at four o’clock the following afternoon, you may have lost most of a business day’s changes. For some systems, that’s inconvenient. For others, it could be extremely expensive.
An accounting system, transactional database, production environment, or heavily used file repository may justify frequent backups because recreating lost information would be difficult or impossible. A relatively static archive might not require the same schedule.
That’s why backup frequency shouldn’t simply be whatever default came with the software. It should reflect the importance of the information and how quickly it changes.
Not all backups work the same way
I learned some of these tradeoffs firsthand in my first network administration job. At the time, our backups ran to tape. A full backup took essentially the entire night and placed enough load on the production environment that doing one every evening wasn’t practical. We performed a full backup once a week and incremental backups during the rest of the week. It worked, but there was a tradeoff.
A full backup copies everything in scope. From a recovery standpoint, that’s relatively straightforward because the entire data set exists in one backup set. The downside is that full backups require more storage, take longer to complete, and can place more load on the systems being protected.
An incremental backup copies only the information that has changed since the previous backup, whether that previous backup was full or incremental. That makes incremental backups much faster and smaller. The tradeoff shows up during recovery. To restore the environment, you may need the last full backup followed by every incremental backup created after it.
A differential backup takes a slightly different approach. It captures everything that has changed since the last full backup. Each differential generally becomes larger as the week progresses, but recovery may be simpler because you typically need the last full backup and the most recent differential rather than an entire chain of incremental backups.
There isn’t one universally correct answer. The right combination depends on the environment, the available backup window, storage capacity, system performance, and how quickly the organization needs to be able to recover. The technology has changed considerably since my tape-drive days, but those tradeoffs haven’t disappeared.
Scope matters just as much as schedule
An automated backup job is only useful for the systems included in it. This is another place where the asset and data inventories we’ve discussed throughout the CIS Controls become important. New servers are deployed. Applications move to SaaS platforms. Departments adopt new business systems. Employees begin storing important data in locations nobody originally expected.
If those systems or repositories aren’t included in backup scope, automation won’t help. Organizations should know which enterprise assets require backup and have a process for making sure new in-scope systems don’t quietly appear outside the backup environment.
Cloud services deserve particular attention here. There’s sometimes an assumption that if information resides in Microsoft 365, Google Workspace, Salesforce, or another cloud platform, the provider has automatically solved the organization’s backup problem. The actual responsibilities and recovery capabilities vary by service. “Cloud” describes where the system runs. It doesn’t answer your recovery requirements for you.
A successful job needs to be visible
There’s another problem with automation: it can create confidence. A backup job was configured six months ago. It runs every night at 11:00. Everyone assumes the data is protected. But is it?
Automated jobs can fail silently if nobody is paying attention. Organizations need some way to identify failed or missed backups so they can be addressed rather than discovered during an incident.
That doesn’t require someone to stare at a backup console every morning. Modern platforms can generate alerts and reports when jobs fail. What matters is that those alerts go somewhere and that someone is responsible for responding to them. “Configured” and “completed successfully” aren’t the same thing.
Older technology, same problem
In that first network administration job, we also used a service that collected our backup tapes and stored them off-site. At the time, that was how we protected ourselves from losing the server and the backup tapes in the same physical event.
We’ll get into isolated recovery data later in Control 11, because that’s really a separate safeguard. The part that’s relevant here is that the backup process was deliberate. Full backups happened on one schedule. Incrementals happened on another. The jobs were built around the limitations of the technology and the needs of the business.
Today’s backup platforms are dramatically faster and more sophisticated, and we aren’t swapping tapes every morning in most environments. But the underlying decision hasn’t changed. How frequently do we need to capture our data so that a failure doesn’t cost the organization more than it can reasonably tolerate?
A place to start
If your organization is evaluating Safeguard 11.2, start with the systems and data already identified as important in your recovery process. Confirm that they’re actually included in automated backups. Determine how frequently those backups run and whether that frequency reflects how quickly the information changes and how much of it the organization could afford to recreate.
Understand whether you’re using full, incremental, differential, or some combination of backup methods and why that approach was selected. Make sure failed jobs generate visibility rather than disappearing unnoticed.
The next safeguards will address how recovery data itself should be protected and how an isolated copy should be maintained. Those are important conversations, but they begin with having current backup data in the first place. Automation makes sure the backup happens. The schedule determines how much you stand to lose when it doesn’t happen soon enough.
