Security practices
What we do today, stated plainly. Where a control is planned rather than in place, it says so.
Controls in place
| Control | Status | Detail |
|---|---|---|
| Encryption in transit | In place | TLS on all connections |
| Encryption at rest | In place | Managed database and object storage encryption |
| Per-practice isolation | In place | Row-level access scoped by practice |
| Access logging | In place | User, timestamp, and scope on every case-data read |
| Least privilege | In place | Access limited to staff computing your report |
| Formal certification | Pending | CERTIFICATION STATUS PENDING |
We are not claiming a certification we have not completed. When one is in place it will be named here with its date and scope.
Isolation is the one that matters
A user of one practice must never be able to read another practice's rows. Every table carrying case data is scoped by practice identifier and enforced at the database layer, so an application bug cannot widen the query. This is the control we treat as non-negotiable.
Data minimization
- Patient names, DOB, SSN, full addresses
- Clinical notes or diagnoses
- A pseudonymous case reference you supply
- Dates, amounts, status, case type, firm
The full PHI position is on the HIPAA page.
Reporting a vulnerability
If you believe you have found a security issue, write to SECURITY CONTACT PENDING with enough detail to reproduce it. We will acknowledge within ACKNOWLEDGEMENT SLA PENDING and tell you what we found. We will not pursue anyone who reports a genuine issue in good faith and does not access or alter another practice's data.