How Often Should AMS Data Backups Occur? – IA Magazine

The Practical Answer: Back Up Critical AMS Data Daily

A sensible baseline for an independent insurance agency is to protect changing AMS data at least once every business day. Agencies that process large transaction volumes, maintain their own servers or cannot tolerate losing a full day of client activity should use hourly snapshots, continuous replication or another automated method with a much shorter recovery window.

IA Magazine’s discussion of AMS preparedness distinguishes between cloud-hosted and locally hosted systems. Its experts suggested monthly downloads of broader reports, daily or weekly activity reports and, where an agency could otherwise lose all access to locally stored information, current data downloaded at least weekly. The article also emphasized documenting procedures and periodically confirming that the intended information is actually being protected.

That advice creates a useful minimum, but it should not be interpreted as permission to protect every AMS record only once per month. A monthly report may help management review the book of business, but it will not preserve yesterday’s endorsements, claims conversations, payment entries or coverage instructions. For frequently changing information, daily protection is the safer operational standard.

A Recommended AMS Backup Schedule

Let RPO and RTO Determine Backup Frequency

Backup frequency becomes easier to calculate when an agency establishes two objectives: the recovery point objective and the recovery time objective.

Recovery Point Objective

The recovery point objective, or RPO, describes how much recent data the agency can afford to lose. An RPO of 24 hours means management accepts the possibility of reentering up to one full day of work. An RPO of one hour means backups or replication must create usable recovery points at least hourly.

For an AMS, a 24-hour data-loss window can be surprisingly painful. Imagine reconstructing every endorsement request, certificate, payment note, cancellation warning and client conversation handled since yesterday morning. Even if employees remember most of it, “I think that is what happened” is not an ideal record-retention strategy.

Recovery Time Objective

The recovery time objective, or RTO, defines the maximum acceptable period the system may remain unavailable. An agency with a four-hour RTO needs more than a backup file stored somewhere. It needs compatible equipment, credentials, internet access, documented recovery steps and people authorized to make decisions.

AWS and NIST guidance treats RPO and RTO as business-defined recovery targets rather than arbitrary technical settings. A shorter RPO requires more frequent protection, while a shorter RTO generally requires faster restoration methods, prepared infrastructure and better-tested procedures.

For many agencies, a reasonable target is an RPO of four hours or less for critical AMS activity and an RTO that restores essential client service within the same business day. High-volume agencies, call centers and firms handling time-sensitive commercial accounts may require considerably tighter targets.

Cloud-Based AMS Backups: Trust, but Verify

Cloud-hosted AMS platforms usually include vendor-managed redundancy, system backups and disaster recovery capabilities. That is one of their major attractions. An agency no longer has to rely on a server quietly humming in a closet next to a mop bucket and a stack of holiday decorations.

Cloud systems can improve geographic redundancy, remote access and business continuity. Insurance technology providers commonly describe encrypted backups, failover infrastructure and geographically separated facilities as important cloud-service features.

However, “the vendor backs it up” is not a complete disaster recovery plan. Microsoft’s cloud guidance explains that customers remain responsible for their data, identities, configurations and access management even when infrastructure responsibilities shift to a SaaS provider. Agencies must therefore understand exactly what the AMS vendor protects and what remains the agency’s responsibility.

Questions to Ask an AMS Vendor

• How frequently is customer data backed up or replicated?
• What are the vendor’s contractual RPO and RTO commitments?
• How long are backup versions retained?
• Are backups geographically separated from production systems?
• Are immutable or offline recovery copies maintained?
• Can one agency’s data be restored without restoring every customer?
• Can the agency export client, policy, activity, document and accounting data?
• What access will remain available during a partial outage?
• How will the vendor communicate during a cyber incident?
• How is agency data returned if the contract ends?

The answers should appear in contracts, service descriptions, security reports or written vendor documentation. A cheerful sales presentation is useful, but it is not a recovery guarantee.

Reports Are Helpful, but They Are Not Full Backups

Downloading reports can give an agency a temporary operational lifeboat. A current client list, policy roster, renewal report, open-activity report, employee directory and carrier contact list may allow staff to answer urgent questions while the AMS is unavailable.

However, reports usually do not preserve the full structure of the system. They may omit attachments, document relationships, permissions, audit trails, configuration settings, workflows, email histories and database connections. A spreadsheet containing client names and policy numbers is valuable, but it cannot magically rebuild the AMS any more than a restaurant menu can rebuild the kitchen.

Use reports as part of a business continuity package, not as the agency’s only backup method. Store the package securely in a format that authorized employees can open without logging into the unavailable AMS. Because these files may contain nonpublic client information, they should be encrypted, access-controlled and retained only as long as necessary.

What an Emergency Continuity Package Should Include

• Current client names and approved contact information
• Policy numbers, carriers, effective dates and expiration dates
• Upcoming renewals and cancellations
• Open claims, pending endorsements and unresolved service activities
• Carrier claims and underwriting contact information
• Employee phone numbers and emergency responsibilities
• Instructions for accessing alternate internet, phones and work locations
• Vendor support numbers and escalation procedures

Use the 3-2-1-1-0 Backup Strategy

The traditional 3-2-1 backup rule calls for three copies of important data, stored on two types of media, with at least one copy kept off-site. A modern variation, sometimes written as 3-2-1-1-0, adds one offline or immutable copy and a goal of zero unverified backup errors.

CISA recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity. The Federal Trade Commission similarly advises businesses to make backups part of routine operations and to keep important recovery copies separate from the production network.

For an agency with an on-premises AMS, the design might include the production database, an automated local backup appliance and an encrypted off-site copy with immutability enabled. Cloud-based agencies may combine the vendor’s platform protection with encrypted exports or an independent archival process, subject to contract terms and security requirements.

The key word is independent. If ransomware can access the production environment and every backup through the same administrator account, the agency may have several copies but only one point of failure wearing multiple hats.

Automate Backups and Separate Credentials

Manual backups tend to work beautifully until the employee responsible for them takes vacation, changes jobs or becomes distracted by an urgent renewal. Automation reduces dependence on memory and makes successful completion easier to monitor.

Backup systems should generate alerts for failed jobs, incomplete copies, unusual deletion activity and missed schedules. Someone must review those alerts. An automated system that has been failing silently for six months is not automation; it is decorative software.

Backup administration should use credentials separate from ordinary network accounts. Multifactor authentication, least-privilege access, encryption and restricted deletion permissions can make it harder for an attacker who compromises the agency’s network to destroy its recovery copies.

Testing Matters More Than the Backup Dashboard

A green check mark proves that a backup process created something. It does not prove that the agency can restore the right records, decrypt them, connect them to the required application and make them useful before clients begin calling.

NIST emphasizes conducting, maintaining and testing backups, while Ready.gov states that backup and recovery should be integrated into business continuity and IT disaster recovery planning. In other words, the backup is not a side project owned only by the person who knows where the server room key is hidden.

A Layered Testing Schedule

• Monthly: Restore selected client files, documents or reports to a protected test location.
• Quarterly: Confirm administrator access, encryption keys, vendor contacts and emergency exports.
• Semiannually: Run a tabletop exercise involving management, service teams, IT support and communications staff.
• Annually: Conduct an end-to-end recovery exercise and document actual RPO and RTO performance.
• After major changes: Retest whenever the AMS, integrations, server environment, vendor contract or backup platform changes.

Disaster recovery testing may feel inconvenient, but planned inconvenience is much more pleasant than discovering during an outage that the backup requires an encryption key belonging to an employee who retired two years ago.

Do Not Forget Connectivity and Human Access

An agency may have perfectly protected cloud data and still be unable to operate because the office has no electricity, employees lack approved remote devices or multifactor authentication depends on a phone that was left in the evacuated building.

Business continuity planning should therefore include laptops, chargers, secure hotspots, alternate internet providers, remote-access permissions, phone forwarding, emergency work locations and an offline copy of essential instructions. The Big “I” technology resources specifically encourage agencies to prepare employees, physical offices, data, systems and clients for disasters.

The agency should also identify at least two people who can contact the AMS provider, approve emergency decisions and access recovery documentation. A plan that depends entirely on one person is not resilient; it is a vacation-related crisis waiting to happen.

Common AMS Backup Mistakes

• Assuming cloud hosting automatically satisfies every recovery requirement
• Running monthly reports but failing to protect daily transactions
• Keeping the only backup in the same building as the production server
• Using the same credentials for production systems and backup administration
• Failing to include attachments, scanned documents or accounting databases
• Never testing whether a backup can be restored
• Storing emergency exports without encryption or access restrictions
• Forgetting to update the plan after switching vendors or adding integrations
• Failing to document who declares an outage and activates recovery procedures

Practical Experience: What Agencies Commonly Learn the Hard Way

Backup planning often looks straightforward on paper. Select a schedule, check a few boxes and assume the agency is protected. Real-world exercises usually reveal that the difficult part is not creating copies. It is maintaining access to useful, recent and trustworthy information while employees, vendors and clients are all under pressure.

Consider a composite scenario involving a small coastal agency preparing for a hurricane. The agency uses a cloud-based AMS, so management assumes the data is safe. Technically, that assumption is reasonable: the vendor’s infrastructure remains operational. Unfortunately, the office loses electricity and wired internet, several employees have never logged in remotely, and the principal’s multifactor authentication app is on an old phone that will not turn on.

The AMS was available, but the agency was not ready to access it. After the exercise, management issued encrypted laptops, tested secure hotspot connections and required employees with emergency roles to complete remote-login drills. The experience demonstrated that availability includes devices, identities and communicationsnot merely a healthy vendor data center.

Another composite agency dutifully copied its server data to network-attached storage every evening. The backup dashboard displayed reassuring green icons. During a ransomware simulation, the agency discovered that the storage device used the same administrator credentials as the primary network and remained continuously connected. An attacker with sufficient access could encrypt both the production files and the backups in one enthusiastic afternoon.

The agency added an immutable cloud copy, separated backup credentials and restricted deletion rights. It also began conducting monthly sample restores. The first test uncovered several missing attachment folders that had never been included in the original backup job. No disaster had occurred, yet the exercise had already paid for itself by identifying a gap while everyone was calm and coffee was still available.

A third agency exported its complete client roster every month. When a vendor outage occurred late in the month, employees had names, phone numbers and policy numbers, but the file did not include recent endorsements or open activities. One producer unknowingly promised a client that a requested coverage change had been completed, while the service team had actually been waiting for additional information.

Following that incident, the agency retained its monthly master report but added daily open-activity exports and weekly policy-change reports. It also created a short procedure requiring staff to label any information obtained during an outage as provisional until it could be reconciled with the restored AMS.

These experiences point to the same lesson: backup frequency should follow business activity, not habit. Monthly records may be sufficient for slow-changing reference information. Daily backups are appropriate for most operational AMS data. Hourly or continuous protection may be justified for agencies with heavy transaction volume or strict service commitments.

Most importantly, a backup should be judged by the agency’s ability to recover from it. A file that exists but cannot be found, opened, trusted or restored within the required time is not much of a safety net. It is merely a very organized collection of optimism.

Conclusion: Build a Schedule Around Acceptable Data Loss

For most insurance agencies, critical AMS data should be backed up or replicated at least daily, with hourly or continuous recovery points for high-volume operations. Activity reports should be generated daily or weekly, emergency client and policy lists should be refreshed weekly, and broader management reports can be archived monthly.

Cloud hosting can reduce infrastructure burdens, but agencies must verify vendor responsibilities, export options, retention periods and recovery commitments. On-premises systems require more direct oversight, including daily automated backups, off-site protection and isolated recovery copies.

Whatever schedule the agency chooses, it should be written down, automated, monitored and tested. The best backup plan is not the one with the most impressive dashboard. It is the one that lets employees securely retrieve accurate information and continue helping clients when the ordinary system is unavailable.