How Insurance Teams Maintain Service During Disruptions

1. Assume your vendor will fail just as all others in the insurance and trading space have. One policy admin system, one payments processor, one cloud region is all it takes to test out how your system of choice will behave when it fails at 9am Monday morning. At TradingFXVPS, we run all critical components of our system with a second provider in a completely separate data center. In insurance terms, this means keeping a read-only copy of all policy and claims data for customers and agents to query as necessary. In addition to automating a failover for intake of claims, a pre-written message should be ready to send to customers within minutes of a failure. Perform failover testing of all systems (including all third parties) quarterly and simulate a complete failure of the primary system for each test case - don't rely on slides prepared for a table top exercise to be of any use.

2. Years ago a major upstream network provider went down for several hours. I had put in place what I call "paper redundancy" - two links to the same carrier, over the same fiber. Since then I have tried to map all dependencies down to the physical level, not just the suppliers above me but also the fourth-party suppliers that my suppliers use. The second lesson here is that silence is worse than pain - it took us 40 minutes to start sending status updates, but in the meantime customers were actually angrier with us than with their trading being down. Communication is now a key part of the runbook and triggers off automatically, as opposed to "ooh I'd better go and email them" which is how it was until recently. Redundancy you have never purposefully broken is merely theory.

Our payment provider went down for 2 days at the end of the month meaning we couldn't collect anything.

Lesson learnt: Using a back-up system that hadn't been used before means it is only theoretical. We created a manual process for requesting a bank transfer from the customers and had someone specific confirming they had received it. I asked the team to attempt this once during a busy day.

We attempted this however it didn't work as they couldn't get into the bank account. We resolved this issue.

Not sure how this would work in an insurance scenario where there would be much more expected from the customer.

From my experience managing enterprise IT systems, I believe insurance companies need a backup plan that goes beyond restoring technology. Employees should have alternative ways to handle urgent claims, communicate with policyholders, and coordinate with service providers when their primary systems are unavailable. This became very personal for me in 2023 when a house fire displaced my family for almost seven months. I had to manage insurance claims, deal with contractors, arrange temporary housing, and coordinate the rebuilding process while trying to keep my family's daily life as normal as possible. One lesson I learned was that having insurance coverage or a recovery plan doesn't mean the recovery process will be smooth, especially when multiple parties are involved and responsibilities are unclear. Since then, I've placed greater importance on clearly defined responsibilities, backup communication channels, vendor accountability, and testing how people will actually operate during a prolonged disruption.

Restoring a system is important, but making sure people can continue with their lives while recovery is underway matters just as much.

I shared this experience and the lessons it taught me in my personal blog, "The Runbook I Never Had."

https://kbitra.substack.com/p/the-runbook-i-never-had

Preparing insurance operations for worst-case scenarios means moving away from the belief that everything has to be online in order to work. From my twenty years of experience managing the delivery of technology in the financial and insurance sector, I learned that the greatest mistake from this type of service failure was to adopt a wait-and-see policy when one of the providers had a malfunction, which causes customers to lose their faith in the company. The step in a new phase of architecture was to change our design approach to asynchronous resilience. It means that we will build the intake system in such a way that it can work without being connected to the real-time processing back-office system. In other words, the customer does not just get the error message when the payment gateway or the credit scoring provider stops working; all data will be collected while receiving an acknowledgment. The transaction will be placed in a queue to be processed when the connection is established again. The business can still run while technicians are fixing the issue. A key aspect of disaster recovery in regulated industries, like insurance, is taking human factor into account. I saw cases of companies not functioning not because their servers did not work but because their team did not have a backup process that did not depend on a third-party service provider in their business processes. The company should always have a manually created alternative plan in case the most critical systems fail. In addition, creation of alternative channels for notifications and collecting data is required for claim processing. In conclusion, it should be noted that we should not perceive these redundancies as unnecessary costs but as a real safety net for the company.

Our clients don't experience a system failure as downtime. They experience it as a certificate that doesn't arrive or a policy change that doesn't get made, and either one can keep a truck from loading. So we prepare around the client's request, not around the system.

Three things matter most. First, every client request comes in through one channel and becomes a tracked task with a named owner and a due date. If our platform is unavailable, the queue still exists and nothing is lost, because the request doesn't live in one person's phone. Second, the system of record has to be recoverable: backed up, documented and understood by more than one person. Third, our team works across several time zones, so a problem found overnight is being handled before the client's morning starts.

The lesson came from rebuilding our own platform. It had grown faster than its foundation, and when I asked a simple question, "if this failed tomorrow, how fast would we recover?", I didn't like how long it took to get an answer. Backups, documentation, who owns the code and how problems are detected had been treated as paperwork for later. Now they are day-one requirements for any system or vendor we rely on. A system you can't fully understand or recover isn't really yours, no matter who paid for it.

Zebo Karim, Founder, Get Logan, a trucking insurance agency