What happens if something goes wrong.
Incidents are inevitable in any production system. What separates a mature vendor from an immature one is the discipline around detection, response, communication, and learning. ArthurAI™ ships with a documented incident-response procedure, a named on-call rotation, contractual notification timelines, and a post-incident review cadence.
Severity classification
- SEV-1 (Critical). Confirmed unauthorized access to personal data. Platform-wide outage. Data integrity compromise. Triggers the full IR runbook with executive notification, customer communication, and (for breaches involving personal data) regulatory notification.
- SEV-2 (High). Material degradation affecting multiple institutions. Single-institution outage exceeding the contracted recovery time. Security event with elevated risk but no confirmed unauthorized access.
- SEV-3 (Medium). Localized degradation. Performance issues affecting a subset of users. Non-data security events (e.g., abusive traffic mitigated at the WAF).
- SEV-4 (Low). Minor issues with workarounds available. Documentation discrepancies. UX defects.
The runbook
- Detect. Monitoring fires (Application Insights alerts, Azure Monitor anomaly detection, Front Door WAF rule trips, audit log anomalies). On-call engineer is paged.
- Triage. On-call assesses scope and severity within the first hour. SEV-1 and SEV-2 trigger the incident commander rotation; SEV-3 and SEV-4 are handled by the on-call.
- Contain. Limit blast radius (revoke compromised credentials, isolate affected resources, fail over to redundant capacity).
- Eradicate. Remove the root cause. Apply fix or rollback.
- Recover. Restore normal operation. Verify with synthetic transactions and customer-impacting smoke tests.
- Communicate. Notify affected customers per contract. SEV-1 with personal-data exposure triggers regulatory notification per jurisdiction (Article 33 GDPR within 72 hours; analogous state and regional regimes per their requirements).
- Learn. Post-incident review within 5 business days. Action items tracked through the engineering ticket system. Material improvements communicated to affected customers.
Notification cadence
- SEV-1 with personal-data exposure. Initial customer notification within 24 hours of confirmed unauthorized access. Regulatory notification (where applicable) within 72 hours per Article 33 GDPR and analogous regimes. Detailed forensic summary delivered to affected institutional Data Protection Officers within 30 days.
- SEV-1 without personal-data exposure. Initial customer notification within 24 hours. Status updates every 4 hours through resolution. Post-incident review summary within 14 days.
- SEV-2. Initial customer notification within 4 hours of detection (for affected customers). Status updates every 4 hours through resolution. Post-incident review summary within 14 days.
- SEV-3. Customer notification at next business day if the incident affected the customer's deployment. Aggregate summary in the next quarterly trust update.
- SEV-4. Tracked in the platform changelog (when published).
Customer communication path
Institutional Data Protection Officers and primary technical contacts registered at onboarding receive incident notifications by email and (for SEV-1) by direct phone where possible. The current incident is also mirrored on a customer-status surface for affected institutions. There is no public status page pre-launch; institutional customers receive direct notification.
Post-incident review
Every SEV-1 and SEV-2 incident produces a written post-incident review within 5 business days, covering: timeline of detection through resolution, root cause, contributing factors, what worked, what didn't, and a list of remediation items with owners and due dates. The review is shared with affected institutional customers under NDA where it contains sensitive architectural detail; a redacted summary is delivered to all affected institutions.
Tabletop exercises
The IR runbook is exercised quarterly through tabletop scenarios covering credential compromise, data exfiltration attempt, denial of service, insider threat, and supply-chain compromise. Exercise summaries are available to institutional buyers under NDA.
Reporting an incident
For institutional customers reporting an incident in their deployment, contact your assigned engagement lead first. For security researchers reporting a suspected vulnerability, write to security@mindhyve.ai (PGP key available on request). For all other reports, write to hello@mindhyve.ai with subject line “Incident report”.
See also: security pillars · security FAQ · Data Processing Agreement.