What is data backup and disaster recovery for an insurance agency?

It is the combination of recoverable copies of agency data and a tested capability to resume operations after a disruption. For an agency, “operations” has a specific meaning: quoting, binding, servicing, taking claims calls, and getting to the documentation that proves what was done and when.

The agency-specific wrinkle is that much of what the agency runs on belongs to somebody else. The management system may be hosted by its vendor, email by Microsoft or Google, documents in a cloud drive, quoting in a rater. A recovery plan that only addresses the office server is protecting the smallest part of the problem.

Example: for the general version of this topic, see our companion guide, What is a Cybersecurity Risk Assessment? — the assessment is what tells an agency which of these systems actually matters most to recover first.

Does Alabama law require an agency to back up its data?

The statute does not use the word “backup,” but it gets there. Ala. Code § 27-62-4(d)(2)(j) directs a licensee to implement measures protecting against “destruction, loss, or damage of nonpublic information due to environmental hazards, such as fire and water damage or other catastrophes or technological failures.” In practice there is no way to satisfy that without recoverable copies.

Two neighboring provisions push the same direction:

• § 27-62-4(d)(2)(i) expects audit trails designed to reconstruct material financial transactions “sufficient to support normal operations and obligations of the licensee” — reconstruction implies retained, recoverable records.
• § 27-62-5 requires a licensee responding to a cybersecurity event to take reasonable measures to restore the security of its information systems. Restoration is difficult to demonstrate without something to restore from.

The familiar exemption caveat applies. Ala. Code § 27-62-9 exempts smaller licensees — fewer than 25 employees, or under $5 million in gross annual revenue, or under $10 million in year-end total assets — from § 27-62-4, which is where the security measures list lives. But the § 27-62-5 restoration duty is outside that exemption, and so is every practical consequence of losing your data. Confirm your agency's status with the Alabama Department of Insurance or counsel; this page is a general summary, not legal advice.

Example: an exempt agency is not required to document its consideration of catastrophe protection. It is still required to keep operating, and its clients still expect a certificate on the day the office floods.

Our management system is in the cloud — isn't the vendor backing it up?

Not in the way most agencies assume. Cloud platforms operate on a shared responsibility model: the vendor is responsible for keeping the service available, and the customer is responsible for the data in it. Those are different problems, and the second one is the one that bites.

The clearest illustration is Microsoft 365, which most agencies run on. Microsoft replicates data across data centers for availability — but replication is not backup: deleted or corrupted data replicates in its deleted or corrupted state. Native recovery windows are time-limited, commonly around 30 days for deleted items in Exchange Online and 93 days in the SharePoint and OneDrive recycle bins. Microsoft's own service agreement recommends that customers back up their content using third-party applications.

The same logic applies to a hosted agency management system. The vendor protects its infrastructure and can generally recover from its own outage. It is far less likely to restore the 400 records a staff member deleted in error last quarter, the data a compromised account corrupted, or your history after you leave the platform. Ask the vendor directly, in writing: what is your recovery point, how far back can you restore our data specifically, and what does that cost?

Example: an agency discovered a bulk edit had corrupted several hundred client records eleven weeks earlier. The platform was healthy, the vendor's own backups were intact, and neither fact helped — the corruption was inside the agency's data, and its retention window had closed.

What is the difference between backup, disaster recovery, and business continuity?

They are three widening circles, and agencies routinely buy the innermost one while believing they bought the outermost.

• Backup — recoverable copies of data. Answers: can we get the file back?
• Disaster recovery — the plan, systems, and tested procedure for restoring technology after a disruption. Answers: how fast can we be running again, and from where?
• Business continuity — how the agency keeps functioning while technology is degraded or gone. Answers: where do staff work, how do calls reach them, and how do we bind coverage in the meantime?

For agencies, the continuity layer carries weight the other two do not. Phone routing is often the single most important continuity control: policyholders calling a dead line during a storm do not conclude the office is closed, they conclude the agency is unreachable. A plan that restores servers in six hours but leaves the main number ringing nowhere has solved the wrong problem.

Example: after a tornado closed a Birmingham-area office for a week, the recovery that mattered was mundane: calls forwarded to mobiles within the hour, and staff working from a borrowed conference room with laptops that reached the hosted management system.

What actually needs to be backed up in an agency?

Everything the agency would need to reconstruct its book and prove its work. That is a longer list than the server, and most agencies have never written it down.

• The agency management system — client records, policies, activities, attachments, and the notes that document advice given.
• Email, including attachments — frequently the only record of what a client was told and when.
• Document storage and scanned files, including the scanning backlog nobody has filed yet.
• Accounting and premium trust records, plus the reconciliations behind them.
• Commission statements and downloads needed to reconstruct what the agency is owed.
• Rater and quoting configurations, which are tedious to rebuild from scratch.
• Phone system configuration and call routing — the continuity control most often forgotten until it is needed.
• Carrier portal credentials, held in a password manager that is itself recoverable and not stored only on one person's laptop.
• Certificates of insurance and the templates behind them.
• The incident response plan and contact sheet — kept where they can be reached when everything else is down.

Example: the item agencies most often discover missing is not client data. It is the accounting system's supporting detail — recoverable enough to show balances, not recoverable enough to show how they were arrived at.

What are RTO and RPO, and what should ours be?

Recovery time objective (RTO) is how long the agency can be down before the consequences become unacceptable. Recovery point objective (RPO) is how much recent work the agency can afford to lose. Both are business decisions the principal makes, not technical settings an IT provider chooses.

A workable approach is to set them per system rather than agency-wide, because the answers differ sharply:

• Phones and email — usually the tightest RTO, measured in minutes to a couple of hours, because they are how clients reach you.
• The agency management system — typically hours, since quoting, binding, and servicing stop without it.
• Accounting — often tolerant of a day or two, unless it is close to month-end or a carrier remittance deadline.
• Archived documents — usually the most tolerant, until a claim or an E&O matter needs one.

The seasonal caveat matters here. An agency's tolerable downtime in a quiet February week is not its tolerable downtime during a named storm or a January 1 renewal cycle. Set the objectives against the worst week of the year, because that is when the outage will feel most expensive — and, in a catastrophe, is when it is most likely to happen.

Example: an agency that had accepted a 24-hour RTO revisited it after a two-hour outage during a hail event produced more client complaints than the previous year combined.

Why does catastrophe season change the math for agencies specifically?

Because an agency's demand peak and its own disruption arrive in the same event. Most businesses experience a disaster as a pause in work. An agency experiences it as the busiest week of the year happening while the office is unusable.

For agencies in Alabama, the Florida Panhandle, and South Georgia, that is not hypothetical — hurricane season, spring tornado season, and severe hail all fall inside the service area. The practical consequences shape the recovery design:

• Recovery infrastructure should not sit in the same weather system as the office. A backup in the same building, or a failover site forty miles away, is exposed to the same storm.
• Staff will be displaced too — recovery has to assume people are working from homes, hotels, or other towns, some without power.
• Call capacity, not just call routing, matters when volume multiplies.
• Internet and power at the office may be out for far longer than the systems themselves take to restore.
• Carriers are simultaneously overwhelmed, so the agency's own records become the fastest source of truth for a policyholder asking what their coverage says.

Example: the agencies that came through recent Gulf storms best were not the ones with the most sophisticated technology. They were the ones whose staff could work from anywhere on a laptop, and whose main number reached a human on the first ring.

How does backup protect against ransomware?

A recoverable backup converts ransomware from an extortion decision into a restoration project — but only if the backup survives the attack, which is exactly what attackers now try to prevent. Modern ransomware operators look for backups first and encrypt or delete them before triggering the payload.

The properties that make a backup survive:

• Immutability — copies that cannot be altered or deleted for a defined retention period, even with administrative credentials.
• Separation — at least one copy outside the production environment, not reachable from a compromised domain account.
• Separate credentials — backup administration that does not use the same accounts as everyday IT administration.
• Sufficient history — enough retained points to recover from before the intrusion started, which is often weeks earlier than the encryption.
• Monitoring — alerting when backups fail or when large deletions occur, since silent failure is the common mode.

The evidence favors restoring over paying. Sophos found 54% of affected organizations used backups to restore encrypted data in 2025, while Fortinet reported that only 4% of organizations that paid a ransom in 2024 recovered all of their data. Paying is a poor recovery strategy even when it is a tempting one.

Example: the retention question decides more cases than the technology. An agency whose intrusion began five weeks before the encryption needs a clean restore point older than five weeks — a fourteen-day retention policy leaves nothing uncontaminated to go back to.

How do we know the backup actually works?

By restoring from it on a schedule. A backup that has never been restored is a hypothesis, and the failure mode is specific and common: the job reports success while silently skipping a locked database, a mailbox, or a folder that changed location.

A reasonable testing rhythm for an agency:

• Monthly — restore a handful of individual files and one mailbox item, and confirm they open correctly.
• Quarterly — restore a full system or database to an isolated environment and verify the data is complete and usable, not merely present.
• Annually — a full recovery exercise against the stated RTO, timed, ideally folded into the incident response tabletop.
• After any material change — a new management system, a server replacement, a migration, or an acquisition.

Two things to insist on regardless of who runs the backups: alerting on failure that reaches a human who will act, and a written record of each test with its date and result. That record is also useful evidence when a carrier, an underwriter, or a regulator asks whether backups are tested.

Example: verify the restore is usable , not just present. One agency successfully restored its management system database and then discovered it had no working copy of the application version required to open it.

How long do we need to keep backups and records?

Long enough to satisfy several different clocks, which is why backup retention and records retention should be treated as separate decisions. A backup is for recovering recent state; an archive is for producing a record years later. Using one to do the other job produces either enormous cost or an unpleasant gap.

The clocks an Alabama agency is usually working against:

• Cybersecurity event records — Ala. Code § 27-62-5 requires records concerning all cybersecurity events be kept at least five years and produced to the Commissioner on request.
• Compliance certification support — § 27-62-4 provides for supporting records to be maintained for five years alongside the annual certification, a provision written for insurers that agencies should confirm the reach of.
• E&O exposure — claims can surface years after the advice was given, and the file is the defense. Retention here is usually driven by counsel and the carrier rather than by statute.
• Carrier and contractual terms — appointment agreements sometimes specify retention, and occasionally specify deletion.
• Tax and accounting — ordinary business record retention on its own schedule.

Retention also cuts the other way. Every year of data kept past its usefulness is another year of nonpublic information exposed in a breach and notifiable afterward, which is why § 27-62-4(d)(2)(k) addresses secure disposal. Deciding what to delete is part of the same exercise as deciding what to keep — make those calls with counsel.

Example: an agency reduced its notifiable exposure substantially by archiving and then purging fifteen-year-old scanned applications it had kept purely because storage was cheap.

How do we choose a backup and recovery provider?

Choose on demonstrated recovery, not on storage. Any provider can copy data; the differences show up in how fast and how completely an agency comes back, and whether anyone has ever proven it.

Questions worth asking every candidate:

• What RTO and RPO will you commit to per system, in writing — and what happens if you miss them?
• Are backups immutable, and are they reachable from a compromised administrator account?
• Do you back up Microsoft 365 and our hosted agency management system, or only on-premise systems?
• Where is the offsite copy geographically, and is it outside our weather exposure?
• How often do you test restores, who reviews the results, and will you show us the last report?
• What is the process and cost if we need a full recovery during a regional catastrophe when you have many clients affected at once?
• Does the plan cover phones and call routing, or only data?
• How do we get our data if we leave you, and in what format?

The sixth question is the one that separates providers in this region. A vendor whose recovery plan assumes only one client is affected at a time has not planned for a hurricane.

Example: ask to see a restore report from an actual recovery, redacted. A provider who tests regularly has one on hand; a provider who does not will offer a capabilities deck instead.