Incident and claims guide
Triage safety and continuity before classifying a claim
A platform outage, exposed dataset, incorrect product output, or failed implementation can begin as an operational alert and later become a customer demand or insurance matter. Activate the appropriate incident process, contain continuing harm, and give the response team a single factual record. Do not wait for a formal lawsuit to preserve evidence or review notice obligations, but do not assume every service ticket is a covered claim either.
Identify a coordinator for the event, a technical lead, a customer-communications owner, a legal contact, and the person responsible for insurance notice. Give each a role and backup. The FTC’s breach-response guide recommends assembling a response team and preserving forensic evidence; it also warns that legal notification duties depend on the facts. A SaaS incident plan should connect that operational guidance to the company’s actual contracts and policy contacts.
Create a chronology with sources, not reconstructed memory
Record when a signal first appeared, who saw it, how it was escalated, what systems and customer accounts were involved, which changes were made, and when service was restored or access was restricted. Keep original alerts, ticket timestamps, system logs, deployment records, status-page changes, vendor messages, and customer communications. Label every entry as observed fact, working hypothesis, or later conclusion; a timeline that silently mixes them can become misleading.
Preserve the version of the product and configuration in use when the event began. For a migration or integration dispute, retain the statement of work, acceptance criteria, mapping files, test results, change orders, and sign-off history. For a security event, preserve access logs, authentication records, affected data categories, backup status, and the scope of privileged access. Use the security team’s retention and forensic process so the evidence remains reliable.
Document impact without overstating certainty
Count affected tenants, users, transactions, systems, and time windows only as the evidence allows. Distinguish unavailable service from corrupted data, suspected access from confirmed acquisition, and a customer’s claimed financial loss from a verified amount. Track how each figure was calculated and when it changed. An early estimate may be necessary for response, but it should be marked as preliminary and updated rather than repeated as a settled fact.
For a dependent cloud provider event, retain the vendor’s status notices, incident updates, service agreement, and the company’s own monitoring. A third-party outage does not erase the SaaS vendor’s contractual duties or establish that a policy’s dependent-business-interruption wording applies. Compare the actual dependency, waiting period, and loss records with the issued form.
Separate customer, legal, and insurance notices
A customer contract may require notice under its own incident definition; privacy law may create a different obligation; and a cyber or technology E&O policy may require notice of a claim or circumstance through a specified channel. Build a notice matrix with the exact clause, trigger, recipient, method, deadline, and owner. Counsel should interpret legal and contractual duties, while the insurance team should read the issued policy and endorsements. Do not assume one notice satisfies all three paths.
Retain what was sent, the attachments, delivery proof, acknowledgment, and any response. If a customer demands damages, a refund, or an indemnity, preserve the original communication and escalate it promptly for a policy-specific notice review. A friendly phone call or help-desk exchange can be important context even when it does not match the policy’s defined claim. The exact wording and facts control.
Keep response spending and vendor decisions auditable
Track internal labor, outside forensic work, legal advice, restoration expense, customer support, credits, and other costs in separate categories. Save invoices, engagement letters, approval records, and the business reason for each expense. Some policies contain consent requirements, panel-provider arrangements, retentions, sublimits, or waiting periods. A necessary operational expenditure is not automatically reimbursable, so ask the insurer or intermediary about approvals without delaying urgent containment.
If a vendor participates in investigation or recovery, preserve its contract, scope, ticket history, technical findings, and communications. Verify that a stated fix was implemented and tested. NIST’s Cybersecurity Framework places supplier risk, response, and recovery within a wider governance process; that provides a useful structure for assigning ownership after the immediate emergency passes.
Use three incident examples to test the file
For a production outage, the file should show monitoring alerts, deployment changes, affected functions, vendor dependencies, customer notices, restoration steps, and measurable interruption. For a suspected data exposure, it should show data categories, access evidence, containment, forensic scope, legal analysis, and the status of notification decisions. For an implementation dispute, it should show the contract, agreed deliverables, acceptance tests, change history, customer complaint, and remedial work offered.
These examples may involve different policies and different notice triggers. Do not force them into one “cyber claim” bucket. A service failure can raise technology E&O questions even without a security event; a privacy incident can raise response-cost and notification questions even before a customer demands damages. The issued forms and circumstances determine the analysis.
Close the record and prepare for renewal
After containment, create a dated post-incident summary that separates root-cause findings, remediation completed, remaining controls, customer communications, claims or notices, and financial impact. Retain the original raw evidence alongside the summary. If a proposed fix is not yet deployed, say so. Update the service inventory, security questionnaire, vendor map, or contract template when the incident reveals stale assumptions.
Before the next insurance application, ask legal and the insurance owner which questions the event affects and which documents should accompany the answer. Keep the policy, declarations, endorsements, notice proof, and insurer correspondence with the incident file. This guide organizes documentation; it does not decide whether an event is covered or what a regulator, customer, or insurer will require.