Most Lincoln and Omaha offices will tell you they “have backups.” That sentence is incomplete. What matters is whether someone on your team — or your MSP — has restored from those backups lately, under conditions that look like a real bad day: a deleted shared-drive folder, a corrupted line-of-business database, or a workstation that never comes back clean.
This is not a ransomware incident playbook. We already cover response posture separately. This is the quieter discipline: proving restores work before you need them.
Answer first: a green backup job is not a restore. Treat backup and disaster recovery as a tested program — owners, access, an offline or immutable copy, and a note of what you last restored — not a checkbox that OneDrive exists.
Primary next step: book a free Security & IT Assessment if you want a second set of eyes on whether your backups are actually restorable. Or call 531-625-2111.
What “we have backups” usually misses
A green backup job is not a restore. Common gaps we see when walking Nebraska SMB environments:
- Backups land on a device that lives on the same network segment as production (same blast radius if ransomware moves laterally).
- Cloud sync is treated as backup. Sync mirrors deletes and encrypts; it is not a versioned, offline-capable recovery plan by itself.
- Encryption keys or MFA for the backup console sit with one person who is on vacation when you need them.
- Nobody has timed a restore of the one system that actually runs the business (practice management, agency AMS, QuickBooks company file, or the shared project folder — whatever yours is).
We are not publishing a statewide “X% of Nebraska SMBs never test restores” figure. If you have not tested yours in the last quarter, treat that as a local fact for your office — not a market statistic.
A practical restore-test checklist
Run these as tabletop-plus-hands-on, not as a binder exercise.
- Name the critical systems. Pick the top three things that stop billing, patient/client work, or quoting if they disappear. Write owners and where the backup lives.
- Small-file restore (monthly is a reasonable default). Restore a handful of files to an alternate folder. Confirm content and timestamps. Document who ran it and the ticket or note ID.
- Critical-app or server restore (on a planned cadence). Restore to isolated storage or a test host when possible. Confirm the app starts or the data mounts. If you cannot isolate, at least rehearse the steps and access path with your provider.
- Identity and console access. Can two people reach the backup console? Are MFA methods current? Are restore credentials separate from day-to-day admin where your design allows?
- Immutability / offline copy. Ask plainly: if ransomware hits the file server and the backup share, what still survives? If the answer is fuzzy, that is the work item.
- Cyber insurance alignment. Carriers increasingly ask whether you test restores. Point your answers at what you actually documented — not aspirational policy language. See our note on controls carriers verify and the insurability self-check.
Lincoln vs Omaha logistics (same standard, different drive time)
The restore standard does not change by city. How you get hands on a device sometimes does.
SAINT is Hickman-based (city-level HQ — no Lincoln or Omaha retail storefront). For many Lincoln footprints, on-site help is a short drive when a restore needs desk-side confirmation. Omaha-metro work (West Omaha, Aksarben, Bellevue, Papillion, and neighbors) is typically scheduled via I-80. Multi-site shops with a Lincoln HQ and an Omaha satellite should test restores at both ends of the identity and file story — not only the HQ NAS.
City hubs: Lincoln · Omaha. Broader managed IT context: managed IT in Lincoln & Omaha.
How this fits ransomware readiness
Restore testing is what makes a ransomware response plan honest. If your IR doc says “restore from backup” and you have never timed that path, the plan is aspirational. Pair this checklist with ransomware response for Nebraska businesses — response when something is on fire; restore tests on an ordinary Tuesday.
What to ask your IT provider (or yourself)
- When was the last successful restore of our most critical system, and who witnessed it?
- Are backups offline or immutable enough that ransomware on the domain would not quietly encrypt them too?
- If the backup admin is unreachable, who is second?
- For multi-site: do Omaha and Lincoln share one backup design with tested restores at each site’s critical data?
Exact RTO/RPO targets depend on your industry and systems. We will not invent hours for a “typical Lincoln clinic” or a “typical Omaha agency.” Define yours in writing, then test against that writing.
Practical next step
If you want a second set of eyes on whether your backups are actually restorable, talk to the team that already runs your stack — or book the free assessment / call SAINT at 531-625-2111. No public price book in this article; no “limited-time” language; scope after we understand what you are protecting.
