When Did You Last Test Your Backups? A Cybersecurity Recovery Checklist for Credit Unions

October is Cybersecurity Awareness Month.

So let me give you a question to take to your next leadership meeting:

When did your credit union last test its backups?

Notice I didn’t ask:

“Do you have backups?”

Most organizations do.

I didn’t ask:

“Are the backups running?”

Hopefully they are.

I’m asking something different.

When did somebody actually prove that you could recover your critical systems and data?

There’s a big difference.

I’ve been in technology long enough to know that a green checkmark on a backup dashboard can make everybody feel pretty good.

Backup completed successfully.

Great.

But then imagine it’s 7:30 Monday morning.

A critical server won’t start.

Files aren’t available.

Maybe ransomware is involved.

Employees are waiting.

Members need service.

Leadership asks:

“How long until we’re back?”

That’s not the moment you want somebody saying:

“Well, we’ve never actually tested this.”

Cybersecurity Awareness Month is a good time to change that.

Because a backup isn’t really the goal.

Recovery is the goal.

1. Know What You’re Backing Up

This sounds obvious.

But start here.

Ask your technology team for a clear list of what is being backed up.

Not just:

“Our servers.”

Get specific.

What systems?

What data?

What applications?

What cloud environments?

What Microsoft 365 information?

What critical business information?

Are there systems managed by outside vendors?

Are there important files employees are storing somewhere that isn’t included in the backup strategy?

Technology environments change.

A backup plan created three years ago may not reflect the credit union you operate today.

New systems get added.

Applications move to the cloud.

Employees start using new platforms.

Vendors change.

That’s why backup strategy should be reviewed regularly.

2. Decide What Needs to Come Back First

Let’s imagine your credit union has experienced a significant technology outage.

Everybody wants their systems back.

Immediately.

That’s understandable.

But recovery needs priorities.

Ask:

What do we need first to begin serving members again?

Then:

What comes second?

And third?

Depending on your environment, critical services could include:

• Network infrastructure
• Identity and authentication
• Core banking access
• Employee workstations
• Microsoft 365
• Critical file systems
• Member-facing services
• Communications
• Internet connectivity

The exact list will vary.

What’s important is that leadership and technology agree on the order before an emergency.

When everything is called “critical,” nothing has really been prioritized.

3. Define How Much Downtime You Can Tolerate

Here’s where the technology conversation becomes a business conversation.

Suppose an important system goes down.

How long can the credit union operate without it?

Fifteen minutes?

Four hours?

One business day?

Longer?

Your technology team shouldn’t decide that by itself.

Operations and leadership need to be involved.

This is where you’ll often hear terms such as Recovery Time Objective (RTO).

Put simply:

How quickly does this need to be restored?

Then there’s another question.

How much data could you tolerate losing?

Five minutes?

An hour?

A day?

That’s commonly discussed as Recovery Point Objective (RPO).

You don’t have to love the acronyms.

You do need the answers.

Because those answers influence the backup and recovery strategy your credit union needs.

4. Make Sure One Cyberattack Can’t Take Out Everything

Here’s a scenario nobody wants.

Ransomware gets into the production environment.

Then it also reaches the systems you’re depending on for recovery.

Now you have a much bigger problem.

Your backup and recovery strategy should be designed with cybersecurity in mind.

That means discussing questions such as:

• How are backup systems protected?
• Who has administrative access?
• How is that access authenticated?
• Could compromised credentials affect both production and backup environments?
• Are appropriate backup copies protected from modification or deletion?
• How would recovery work if normal administrative systems were unavailable?

This isn’t simply a storage conversation.

It’s a security conversation.

5. Test Individual Restores

Start small.

Can you restore a file?

Can you restore a folder?

Can you recover important data?

Can you restore information to a usable state?

Testing smaller restores helps verify that the basic recovery process works.

It also helps your technology team understand the steps involved.

But don’t stop there.

Recovering one spreadsheet is very different from recovering the systems required to operate your credit union.

6. Test Critical System Recovery

This is the bigger question.

Can you restore an important system?

And when you do, measure what happens.

How long did it take?

Did the system work correctly afterward?

Were there dependencies nobody expected?

Did somebody need a password they couldn’t find?

Was a vendor required?

Did another application have to be restored first?

Were there licensing or configuration issues?

Every recovery test teaches you something.

And it’s much better to learn those lessons during a planned exercise than during an actual incident.

7. Test the People, Not Just the Technology

This is one of the biggest mistakes organizations make with disaster recovery.

They test the technology.

But they don’t test the organization.

Let’s say the backups work perfectly.

Great.

Now answer these questions:

Who declares the incident?

Who calls the technology provider?

Who decides what gets recovered first?

Who contacts critical vendors?

Who communicates with employees?

Who keeps leadership informed?

What happens if email is unavailable?

How are members handled if an outage continues?

Technology recovery and business continuity need to work together.

A server can be restored successfully while the organization is still completely confused about what to do.

That’s why tabletop exercises are so valuable.

8. Run a 60- to 90-Minute Recovery Tabletop

You don’t have to create a Hollywood disaster movie.

Keep it simple.

Put the right people around a table.

Then give them a scenario:

“It’s 8:00 Monday morning. Several critical systems are unavailable. We believe ransomware may be involved. Normal recovery procedures could be affected. What do we do?”

Then start asking questions.

Who gets called first?

What systems are most important?

How do we determine whether backups are safe to use?

Who authorizes recovery?

How long do we expect restoration to take?

How will employees communicate?

What happens if the outage lasts four hours?

What if it lasts all day?

What if a critical vendor is unavailable?

You’ll probably find some gaps.

That’s the point.

Find the gaps during the exercise—not during the emergency.

A Simple Recovery Framework: RESTORE

During Cybersecurity Awareness Month, use the RESTORE framework to evaluate your backup and recovery readiness.

R — Rank Critical Systems

Know what needs to be restored first.

E — Establish Recovery Targets

Define acceptable downtime and data-loss expectations.

S — Secure the Backups

Protect recovery systems, accounts, and backup data appropriately.

T — Test Regularly

Don’t assume backups work. Prove it.

O — Organize Responsibilities

Know who makes decisions and who performs each part of the response.

R — Review the Results

Document what worked, what didn’t, and what needs improvement.

E — Exercise the Whole Team

Include leadership, operations, technology, and appropriate outside partners.

Rank. Establish. Secure. Test. Organize. Review. Exercise.

That’s how a backup strategy becomes a recovery strategy.

Your Cybersecurity Awareness Month Recovery Checklist

Before October ends, ask your technology team these 10 questions:

1. What critical systems and data are currently being backed up?
2. Is there anything important that isn’t included?
3. Which systems would we restore first?
4. How quickly do we expect critical systems to return?
5. How much data could we potentially lose between recovery points?
6. How are backup systems and administrative accounts protected?
7. When did we last successfully restore data?
8. When did we last test recovery of a critical system?
9. How long did that recovery actually take?
10. When is our next recovery or tabletop exercise scheduled?

Here’s the important part.

Don’t settle for:

“We should be okay.”

Look for evidence.

A test date.

A recovery result.

A documented issue.

A remediation plan.

A date for the next test.

What Should Leadership See After a Recovery Test?

You don’t need to hand the board 75 pages of technical logs.

Give leadership a useful summary.

For each important recovery test, document:

What we tested

When we tested it

How long recovery took

Whether the test succeeded

What problems we discovered

What we’re changing

When we’re testing again

Now your board and leadership team have something concrete to discuss.

Instead of:

“IT says the backups are good.”

You can say:

“We tested recovery of this critical system on this date. It took this long. We identified these two problems. One has been corrected, and the second will be completed by this date.”

That’s a much stronger cybersecurity conversation.

Don’t Wait Until Ransomware to Learn Your Recovery Time

One of the questions I like asking leadership teams is:

“How long would it take to recover?”

Sometimes the answer is:

“Four hours.”

My next question is:

“How do you know?”

If the answer is based on a recent test, great.

If the answer is based on an estimate somebody made three years ago, we probably have some work to do.

Recovery assumptions get old.

Technology changes.

Data grows.

Applications change.

People leave.

Vendors change.

That’s why testing matters.

Cybersecurity Awareness Month Is the Perfect Time to Prove It

We’ve talked throughout this series about cybersecurity awareness, employees, identity protection, ransomware, vendors, AI, and board oversight.

Backup and recovery connect to all of them.

Because eventually every cybersecurity strategy has to answer one uncomfortable question:

What happens when something still goes wrong?

Good cybersecurity reduces the chance of an incident.

Good business continuity reduces the impact when one occurs.

You need both.

Final Thoughts

Don’t judge your backup strategy by the number of green checkmarks on a dashboard.

Judge it by your ability to recover.

Know what’s protected.

Prioritize your systems.

Define recovery expectations.

Secure your backup environment.

Test individual restores.

Test critical systems.

Test your people.

Document what happens.

Fix the gaps.

Then test again.

Cybersecurity Awareness Month gives us a reason to ask the question.

But don’t wait until next October to ask it again.

Because the best time to discover that your recovery plan needs improvement is when nothing is wrong.

When Did Your Credit Union Last Prove It Could Recover?

If you’re not sure, that’s a good place to start.

At CTG, we help credit unions evaluate backup and disaster recovery, business continuity, ransomware preparedness, incident response, cybersecurity, Microsoft 365, infrastructure, vendor dependencies, and long-term technology strategy.

For more than 26 years, CTG has helped organizations prepare for technology problems before they become business emergencies, backed by a team with more than 200 years of combined experience.

And because CTG takes a vendor-agnostic approach, the goal isn’t to sell you a particular backup product.

The goal is to answer the question that matters:

Can your credit union recover when you need it most?

This Cybersecurity Awareness Month, don’t just check the backup report.

Test the recovery.

Talk with CTG

Phone: 330-655-8144
Email: brett.harney@ctgusa.net
Website: ctgusa.net

Let’s test the plan, identify the gaps, and build a recovery strategy your leadership team can have confidence in long after Cybersecurity Awareness Month is over.