What is incident response planning for an insurance agency?

It is the process of deciding, documenting, and rehearsing how the agency will detect, investigate, contain, report, and recover from a cybersecurity event. The output is a written incident response plan — short enough that staff can follow it, specific enough that it names people, systems, and deadlines.

Agency-specific planning differs from generic small-business planning in two ways. The reporting obligation runs to a state insurance regulator on a very short clock, not just to consumers on a longer one. And the agency's own operations depend on systems it does not own — the management system, carrier portals, raters — so the plan has to cover incidents that happen somewhere else and still land on the agency.

Example: for the general version of this topic, see our companion guide, What is Incident Response Planning? — this page covers what changes when the organization is an insurance licensee.

Does Alabama law require our agency to have a written plan?

If the written information security program requirement applies to your agency, yes — the incident response plan is part of it. Ala. Code § 27-62-4(h) requires a licensee to establish a written incident response plan as a component of its information security program.

Here is where agencies get caught, and it is worth reading slowly. 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. Since the incident response plan requirement lives inside § 27-62-4, an exempt agency is not statutorily required to have one.

But the duty to investigate a cybersecurity event sits in § 27-62-5, and the duty to notify the Commissioner within three business days sits in § 27-62-6. Neither is inside the exempted section. The result is the position most Alabama agencies are actually in: no legal obligation to have a plan, and a full obligation to perform under one.

That is a compliance argument, but the practical argument is stronger. The agencies that miss the three-day window are not the ones that were exempt from writing a plan. They are the ones that did not have a plan. Confirm your agency's exemption status and obligations with the Alabama Department of Insurance or your own counsel; this page is a general summary, not legal advice.

Example: a twenty-two-person agency read the exemption, concluded no plan was needed, and was technically correct. Eighteen months later it determined an event had occurred on a Wednesday and had until the following Monday to file a report it had never read the requirements for.

What must the plan actually address?

Alabama's statute is unusually concrete here. Ala. Code § 27-62-4(h)(2) lists seven items the written incident response plan must address, and they double as a serviceable outline for agencies building one from scratch:

• The internal process for responding to a cybersecurity event.
• The goals of the incident response plan.
• The definition of clear roles, responsibilities, and levels of decision-making authority.
• External and internal communications and information sharing.
• Identification of requirements for the remediation of any identified weaknesses.
• Documentation and reporting regarding cybersecurity events.
• The evaluation and revision as necessary of the incident response plan.

Two of these are where small-agency plans usually fall short. Decision-making authority means naming who can take the management system offline, approve an outside forensics firm, or authorize client notification — and who acts when that person is unreachable. Evaluation and revision means the plan is not finished when it is written; it is updated after every test and every real event.

Example: the most valuable page in most agency plans is a single sheet with names, mobile numbers, and after-hours contacts for the principal, the IT provider, the cyber carrier's hotline, counsel, and the agency management system vendor — printed, because it is needed exactly when the systems are down.

What counts as a cybersecurity event, and when does the clock start?

The clock starts at determination , not at discovery, and the distinction is the most consequential detail in the statute. Ala. Code § 27-62-6 requires notice within three business days from a determination that a cybersecurity event has occurred — which means the investigation under § 27-62-5 comes first, and the three days run from its conclusion.

That is not permission to investigate slowly. Section 27-62-5 requires a prompt investigation, so an agency cannot extend its reporting window by taking its time reaching a determination. The practical reading: move quickly to determine, then report within three business days of doing so, and document the timeline of both.

Notification is triggered when Alabama is the licensee's home state and the event has a reasonable likelihood of materially harming a consumer or disrupting normal operations, or when the licensee reasonably believes at least 250 Alabama residents are involved and the accompanying conditions are met. Events involving encrypted data where the key was not acquired are generally treated differently — another reason encryption earns its place.

Example: an agency noticing "something odd" in a mailbox on Monday has not started the clock. An agency concluding on Thursday that an unauthorized party accessed that mailbox has — and owes a report by the following Tuesday.

What does the agency have to do in the first few days?

Investigate, contain, and document — in parallel, not in sequence. Ala. Code § 27-62-5 sets out what the investigation must establish when a licensee learns a cybersecurity event may have occurred.

The statutory investigation must determine:

• Whether a cybersecurity event actually occurred.
• The nature and scope of the event.
• What nonpublic information may have been compromised.

Alongside that, the licensee must take reasonable measures to restore the security of its information systems and prevent further unauthorized access or disclosure. A workable agency plan sequences the first hours concretely: preserve evidence before cleaning anything up, contain by disabling accounts and sessions rather than wiping machines, notify the cyber carrier before engaging any outside firm, involve counsel early enough that the investigation can be structured appropriately, and keep a contemporaneous log of every decision and its timestamp.

The most common self-inflicted damage in this window is destroying the evidence needed to scope the event — reimaging the affected laptop, deleting the malicious mailbox rule, or restoring from backup before anyone captured what was there.

Example: a well-meaning office manager "fixed" a compromised mailbox by deleting the forwarding rule and changing the password. The rule was the only remaining evidence of where the copied mail had been going, and the agency could no longer establish scope.

What has to go into the report to the Commissioner?

Considerably more than "we had a breach." Ala. Code § 27-62-6 enumerates more than a dozen categories of information the licensee must provide in electronic form, to the extent known.

Among them:

• The date of the event and how it was discovered.
• A description of how the information was exposed, lost, stolen, or breached.
• The period during which the information system was compromised.
• The specific types of information acquired without authorization.
• The number of consumers affected, or a best estimate.
• Whether law enforcement was notified.
• Any lapse in internal controls that contributed, or confirmation that none was identified.
• Remediation efforts undertaken, and steps taken to notify consumers.
• A named contact person authorized to speak for the licensee.

Read that list as a specification for what your systems must be able to tell you. “The period during which the system was compromised” and “the specific types of information acquired” are unanswerable without retained audit logs. An agency that has never enabled logging in its management system or extended its email audit retention will be filing a report full of unknowns — and the obligation to keep the Commissioner updated does not end with the first filing.

Example: the cheapest incident response improvement most agencies can make is turning on and extending audit logging in the agency management system and the email tenant. It costs little, takes an afternoon, and determines whether the report says "60 records" or "we cannot determine."

What if the breach happened at a vendor rather than at our agency?

The obligation still lands on the agency. Ala. Code § 27-62-5 addresses this directly: where the affected system is maintained by a third-party service provider, the licensee must either complete the investigation steps itself or confirm and document that the provider has completed them. Outsourcing the system does not outsource the duty.

This matters disproportionately in insurance. SecurityScorecard's 2025 research found 59% of breaches affecting the insurance sector originated with a third party — roughly double the 29% cross-industry rate. For an agency, the realistic incident is not an intruder on the office network; it is a notification email from a rater, a management system vendor, or an outsourced service center.

A plan that anticipates this includes:

• A current vendor inventory with contacts and what data each one holds — assembled before it is needed.
• Contract terms obliging vendors to notify the agency promptly and to cooperate with its investigation.
• A defined process for confirming and documenting the vendor's investigation, since documentation is what the statute asks for.
• An internal determination step — the vendor's assessment is input to your determination, not a substitute for it.

Example: an agency received a vendor breach notice saying "a limited number of records may have been affected." That sentence does not satisfy § 27-62-5. The agency had to go back and obtain enough detail to determine whether its own consumers were involved, and document that it had.

How long do we have to keep records of an incident?

At least five years. Ala. Code § 27-62-5 requires a licensee to maintain records concerning all cybersecurity events for a period of at least five years and to produce them to the Commissioner on request.

“All cybersecurity events” is broader than “all reported events.” An incident the agency investigated and reasonably concluded did not require notification still generated records, and the reasoning behind that conclusion is exactly what a regulator would want to see later. Agencies that document only the incidents they reported end up unable to show why they did not report the others.

Worth keeping alongside it: the investigation notes and timeline, evidence preserved, the determination and its date, communications with vendors and carriers, remediation completed, and any revision made to the plan afterward. Separately, § 27-62-4 provides for an annual written certification of compliance, submitted by February 15, with supporting records maintained for five years — that provision is written for insurers, so agencies should confirm with the Department or counsel whether and how it reaches them.

Example: keep the records somewhere that survives the incident. An agency whose only record of a ransomware event was a folder on the file server that got encrypted learned this the expensive way.

Who else do we have to notify besides the Commissioner?

Usually several parties at once, on different clocks, which is precisely why the communications element of the plan exists. The Commissioner is the fastest deadline but rarely the only one.

• Affected consumers. The Alabama Data Breach Notification Act of 2018 generally requires notice as expeditiously as possible and no later than 45 days after determining a breach occurred and is reasonably likely to cause substantial harm.
• The Alabama Attorney General. Required under that act when more than 1,000 Alabama residents are notified.
• Your cyber carrier. Typically immediately, and usually before engaging any forensics or legal vendor, or coverage can be jeopardized.
• Appointing carriers. Appointment and access agreements commonly impose their own notice terms, often tighter than any statute.
• Other states' regulators. An agency licensed in multiple states may owe reports under each adopting state's version of the model law, on differing deadlines.
• Law enforcement, where appropriate — and the report to the Commissioner asks whether you did.

Notification decisions are legal decisions. The plan's job is to make sure the right people are in the room quickly, not to pre-decide what gets sent — work those calls with breach counsel and your carrier.

Example: an agency writing across the Alabama–Florida line near Dothan may owe a report in its home state and another under Florida's requirements for a nonresident licensee, plus consumer notice under each state's breach statute — from one incident.

How do we test the plan, and how often?

With a tabletop exercise, at least annually, plus a review after any real incident or material change. A tabletop is a facilitated discussion, not a technical drill: the team is given a realistic scenario and walks through what each person would do, in order, against the clock.

For an agency, an hour is usually enough, and three scenarios cover most of the ground:

• A producer's email account is compromised and has been forwarding externally for six weeks.
• The agency management system is encrypted on a Friday afternoon before a holiday weekend.
• A rater or service-center vendor emails to say it had a breach and your agency's data may be involved.

The point is to surface the gaps while they are free. Typical findings: nobody knows where the cyber policy is, the after-hours contact left the firm last year, the backup has never been restored end to end, or the person named as decision-maker is the person most likely to be on vacation. Preparation shows up in the numbers — Sophos found 53% of organizations recovered within a week in 2025 while 18% took over a month, and organizations with intact backups recovered materially faster than those whose backups had been compromised.

After each exercise, revise the plan. That closes the loop the statute asks for in § 27-62-4(h)(2) — evaluation and revision as necessary.

Example: one agency's first tabletop ended in four minutes. The scenario was ransomware on a Friday; the principal's first question was who to call; nobody had an answer. That four minutes was the most useful part of the year's security spend.

Should we write the plan ourselves or have someone build it?

Either can work, and the wrong answer is the downloaded template nobody adapted. A generic plan fails at exactly the moment it is needed, because it names roles the agency does not have and omits the systems the agency actually runs on.

If you build it internally, keep it short, name real people and real systems, and test it. If you engage someone, ask:

• Will the plan map to Ala. Code § 27-62-4(h)(2) element by element, so we can show which section each part satisfies?
• Does it account for the three-business-day determination clock specifically, not a generic 72-hour timeline?
• Have you worked with agency management systems and carrier connections, and does the plan cover a vendor-side incident?
• Will you facilitate a tabletop exercise, and is the first one included?
• What role do you play during an actual incident — and what is your response commitment outside business hours?
• Will you help us confirm our logging can answer the report's questions before we need it to?
• Does the deliverable include the printed one-page contact sheet and a documentation template?

A plan an agency can execute at 6:00 p.m. on a Friday beats a thorough one nobody has read.

Example: ask any candidate to show the one-page version — the sheet a staff member would actually hold during an incident. If there isn't one, the plan is a document rather than a procedure.