When something goes wrong, the response is structured.

Incidents are classified into four severities based on data exposure, service impact, and customer-base scope. Severity-1 — confirmed exfiltration of customer matter data — triggers the most aggressive response: customer notification within the most-protective applicable statutory window, regulator notification per the laws of affected residents’ states, and a full post-incident review. Severity-4 — minor operational degradation not affecting data integrity — is handled inside the standard operations cadence.

Classification is the runbook’s first step, not its last. Misclassification is the most common reason incident response fails; the runbook treats classification as an iterative decision that escalates as evidence develops.

Customers are notified of confirmed security incidents affecting their data in the most expedient time possible and without unreasonable delay — the standard set by California Civil Code § 1798.82 and the breach-notification statutes of every other US state — and within any shorter window committed in the customer’s DPA. Where a specific jurisdiction, data category, or contract imposes a fixed deadline, the most-protective (shortest) window governs.

Notification content includes: a description of the incident; the data categories affected; the population of affected data subjects; the remediation steps taken and underway; a single point of contact at Eve-Legal, LLC for follow-up.

On notification, the customer typically activates its own breach-response protocols — its state bar’s confidentiality rules require the customer to notify its clients of incidents affecting their confidential information. Eve-Legal, LLC supports the customer’s notification effort with the evidence package the customer needs to satisfy its own obligations; the customer notifies its clients.

The customer’s contractual obligations under the DPA and the master service agreement remain in force during the incident. The reporting cadence accelerates; the obligations themselves do not change.

• Detection — Azure Monitor and Microsoft Defender for Cloud.
• Classification — severity matrix anchored to data exposure, service impact, and customer-base scope.
• Containment — automated and manual containment steps; tenant-scoped first, cross-tenant only when required.
• Eradication — root-cause analysis with engineering, security, and customer-side counsel involved.
• Recovery — service restoration, data integrity verification, customer notification.
• Post-incident review — published internally; relevant lessons shared with affected customers and the security FAQ updated.

The runbook includes specific named owners, escalation paths, and decision-tree shapes for each phase. The full runbook is provided under NDA on request.

The post-incident review is the runbook’s last step. Lessons feed the next revision of the runbook itself, the architecture (where the incident exposed a structural weakness), the security FAQ on this site (where the question was implicit in the incident), and the DPA notification mechanism (where customer expectations need to be reset).