A security program is judged as much by how it responds to an incident as by how it prevents one. This page documents ChironAI’s incident-response lifecycle and how breach notification is handled — consistent with the statutory obligations under HIPAA/HITECH and applicable state law, and routed through the Business Associate Agreements that govern each institutional relationship.
Operational telemetry on the clinical surfaces (Azure Application Insights: request errors, exceptions, and explicit instrumentation events), the tamper-evident audit log, and platform-level Azure signals feed detection. Suspected incidents can also arrive through the vulnerability-disclosure channel below. A report is triaged and assigned a severity that drives the response timeline.
The first objective is to stop the spread and limit exposure — isolating affected components, revoking or rotating credentials (secrets live in Azure Key Vault and are accessed keyless via Managed Identity, so rotation does not require code changes), and, where warranted, using the blue-green traffic-split to move production off an affected revision. Tenant-ID guards and row-level security constrain the blast radius by construction.
Once contained, the root cause is removed — patching the vulnerability, eliminating the foothold, and validating that no persistence remains. Changes follow the standard change-management path and are captured in the audit trail.
Service is restored to normal operation and monitored for recurrence. Where data restoration is needed, continuous-restore PostgreSQL backups support recovery to the objectives documented per deployment. A canary rollout confirms the fix is healthy before full traffic returns.
Every material incident gets a post-incident review that documents the timeline, root cause, and the corrective and preventive actions taken. Findings feed back into controls, tests, and detection so the same class of incident is harder to repeat.
Where an incident involves Protected Health Information, ChironAI operates as a business associate to the covered entity. Breach notification is handled consistent with the HIPAA Breach Notification Rule and the HITECH Act, and with any applicable state breach-notification law. The specific notification timelines and procedures are those set by the governing statutes and the executed Business Associate Agreement with each institutional customer — we notify within the periods the law and the BAA require.
Because the institutional customer is the covered entity and data controller, notification flows to that customer, who directs downstream notification to affected individuals, regulators, and, where required, the public, in accordance with their obligations. We support that process with the incident timeline, scope, and remediation record produced by the post-incident review.
For deployments governed by frameworks other than HIPAA (for example, GDPR or UK GDPR), the corresponding data-processing addendum specifies the equivalent notification obligations, and we handle notification to that standard.
We deliberately do not publish a fixed hour-or-day notification SLA on this page. The binding timelines are those in the applicable statute and the executed BAA; publishing a single number here risks conflicting with the specific commitment a customer has contracted for.
Suspected vulnerabilities and security concerns are routed to security@mindhyve.ai with the subject prefix "Security Disclosure". We acknowledge reports and coordinate on remediation and, where appropriate, coordinated disclosure.
Institutional customers with an active incident affecting their deployment should contact their account and security channel directly through the escalation path in their agreement, in parallel with the address above.
Vulnerability disclosure goes to security@mindhyve.ai. For diligence review of our incident-response and breach-notification procedures, our security team responds within two business days.
Contact our security team →