Disaster Plan Waiting to Happen? MGAs Must Prepare For All Emergencies
His last words of advice might have been the most important: “If you haven’t started, start small.”
Not all managing general agencies are as large as CRC/Southern Cross of Birmingham, Alabama, where Mike Roy is chief information officer. CRC/SC has 700 employees and 24 offices, up from just four offices less than five years ago. Roy runs a large national database center, arranges for off-site storage, and has a replica office of his main information center in a branch location. His information technology budget is about 3.7 percent of the firm’s revenues.
In short, Roy has a lot of data, systems and equipment, not to mention jobs, to protect, probably a lot more than many IT people at other MGAs around the country. But smaller size is no excuse for ignoring the need for a comprehensive disaster recovery plan for IT, according to Roy.
Roy shared his agency’s DRP — or disaster recovery plan — with fellow IT professionals at the recent Insurance Automation Conference sponsored by the American Association of Managing General Agents in Philadelphia.
A wholly-owned subsidiary of BB&T, CRC Insurance Services Inc. is one of the nation’s biggest wholesale brokers. Southern Cross is the MGA and program underwriting division in the CRC network, handling the binding facility markets for the CRC group and writing those middle market accounts that do not fit into the CRC brokerage facilities. Additionally Southern Cross runs programs for middle market umbrella, coastal homeowners and marine.
Developing a DRP
Developing a DRP involves figuring out “how best to prepare for a wide array of emergencies, not just worst case scenarios,” Roy told the AAMGA crowd. These emergencies can range from tornadoes that wipe out everything to more common memory failure.
“Starting small” in preparing for emergencies means making backups and creating complete documentation of systems. Then, an MGA can move into ancillary systems including virus protection, web filtering, spam filters, firewalls and the like. “Get a consultant to do it if you can’t,” Roy advised.
Even starting small can lead to bigger things because once the process begins, more and more issues arise, Roy revealed with his presentation.
A comprehensive recovery plan is an ongoing commitment of resources and time, not just a summary on a piece of paper, and it’s a plan that involves more than the specialists in IT.
“It’s not simply an IT effort,” Roy said. “Involve the folks from the rest of the organization. Make them aware of what can happen if they lose access. Approach it as a team.”
Roy shared four principles to guide the development of a DRP:
Organize and document
A DRP team should assess the agency’s physical location for after-hours access, weather patterns, outages, even construction and congestion in the area that might impede evacuation or delivery of supplies.
It’s also critical to understand water and energy sources for a location as well as the workings of all systems from servers and phones to lighting and air conditioning. CRC/SC keeps current information on all vendors, including security, climate control, power and fire suppression companies.
Documentation should identify the configuration of the network including each workstation, all servers, remote access instructions, every phone and fax. Roy also writes out how to actually restore every system step by step.
CRS/SC keeps a binder on and off site with key people. In it, Roy includes the exact rules and responsibilities for every person on the disaster response team, a blueprint of who does what in the event of an emergency. He includes emergency contacts for key employees and vendors and an action item checklist for each team person. There is an explanation of which systems should be restored in order of priority. There is also information on how communications and notification during an emergency will occur and a designated meeting place outside of the office.
Backup and restore
“A simple but most important and most often overlook ingredient” of a DRP is the data backup and restoration system. “I will beat this to death,” Roy warned before returning to the subject again and again in his talk. He also stressed that any system must address not just data, but systems as well. And backups must be confirmed daily.
In preparing to design their backup and restore program, Roy’s team first defined the emergencies that they had to prepare for, such as loss of any key system, destruction of data, an extended power outage, and facility failures.
They next identified what types of communications they believe are critical — phone calls, Internet, emails, faxes — and what types of information must be accessible — submissions, rating/policy issuance, accounting, claims, documents (paper and electronic), and human resources/payroll records.
He urged IT departments not to forget to retain all original software installation CDs, license keys and documentation. “This hit us like a ton of bricks,” Roy acknowledged.
As he made obvious, Roy doesn’t just believe in a minimum backup plan. “Any data backup and restore system should include an alternate facility operation,” he said. His firm has multiple locations, so Roy utilizes one of his branch offices as a “cold” site to back-up the “hot” site at his Birmingham headquarters. The cold site has most everything the hot site has, but it is backed up into fewer servers. “Keep your backup or ancillary system compatible and upgraded the same as the original,” Roy advised.
CRC/SC even keeps some backup equipment, such as faxes and copiers, and has the names of service providers who can provide other equipment in an emergency.
The server room itself must be secure, kept temperature controlled and have fire suppression systems. A good plan includes systems for monitoring these factors and should also contain contact information on these vendors.
Finally, Roy warned against assuming that systems and backups work. “Systems are no good unless you test them,” he stressed repeatedly. One way to do this is to set up a laboratory like area where they can be run before they are released company-wide for use.