Assume incidents will happen; design for how you respond
No vendor should promise that incidents will never occur. What a vendor owes you is a clear answer to three questions: how will you know, what will you do, and when will you tell me. Here are ours.
What is in place today
Detection and classification
Incidents are classified by severity when identified:
| Severity | Meaning |
|---|---|
| Critical | Confirmed or suspected exposure of PHI, or loss of system integrity |
| High | A security control failure with no confirmed data exposure |
| Medium | A vulnerability or anomaly requiring prompt remediation |
| Low | A hardening gap or deviation with no immediate risk |
Application-level audit logging of chart access and changes is the primary forensic record for investigating suspected inappropriate access.
Containment
- Registered API tokens are revocable, so a compromised service credential can be cut off immediately.
- Role-based access means a compromised user account is bounded by that role’s privileges.
- Privileged operational changes are approval-gated, which both slows an attacker’s path to administrative action and creates a decision trail for investigators.
- The Security Officer owns incident coordination; the Privacy Officer owns the privacy impact assessment when PHI may be involved.
Notification commitments
Consistent with the HIPAA Breach Notification Rule and our role as a business associate:
- We notify affected covered entities of a breach of unsecured PHI without unreasonable delay, and within the timelines specified in the applicable Business Associate Agreement.
- Notifications include what is known at the time — nature of the incident, data involved, affected individuals to the extent known, and remediation under way — with follow-ups as the investigation progresses.
- We do not sit on bad news to perfect the wording.
Reporting channel
Suspected incidents or vulnerabilities: [email protected]. We acknowledge reports within 3 business days — see Responsible Disclosure.
On our roadmap
- Documented incident-response policy pack (in progress): the practices above, formalized as written runbooks with defined roles, escalation paths, and post-incident review requirements.
- Third-party penetration testing before general availability — planned adversarial exercise of our detection and response.
- Incident-response tabletop exercises on a regular cadence as part of the formal policy program.