When something goes wrong, the response is structured.
This page summarises the JustineAI™ incident-response posture. The full operational runbook is available under NDA for procurement review; the structure below is the shape the runbook gives. The page is the procurement-grade summary, not the operating document.
Classification
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.
Notification windows
Customers are notified of confirmed security incidents affecting their data per the most-protective applicable statutory window. For US customers, this is the 72-hour notification window applicable under California Civil Code § 1798.82 and the equivalent provisions of the seventeen-plus other US states with comprehensive consumer-privacy laws. Where a longer window applies to a specific data category or jurisdiction, the shorter (more-protective) 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.
Customer obligations
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.
Runbook scope (summary)
- Detection — Azure Monitor, Defender for Cloud, Microsoft Sentinel.
- 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.
Continuous improvement
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).