Written for the person who has to approve us.
If you are the compliance officer or security reviewer on the other side of a vendor assessment, this page is for you. It states what we do, what we do not do yet, and who to contact for the artifacts your process requires.
Last reviewed: August 2026
Where we are today
We would rather be plain about our current state than imply coverage we do not have.
In place
- Business Associate Agreements available and executed before PHI is shared
- HIPAA-ready architectures: PHI boundaries, access controls, and audit logging designed in
- Encryption in transit (TLS 1.2 and above) and at rest for systems we operate
- Least-privilege access with named accounts; no shared credentials
- Audit logging of access to production systems
- Human review required for any AI output affecting care or eligibility
- Model documentation delivered with every model we put into production
- Secure development practices: peer review, dependency monitoring, secrets kept out of source control
Not in place yet
- We do not currently hold a SOC 2 report, HITRUST certification, or ISO 27001 certification.
- We do not claim to be "HIPAA certified" — no such certification exists for any vendor.
- We are a small team, which means our controls are documented and practiced rather than independently attested.
If your process requires an independent attestation before engagement, tell us early. We will say whether we can meet that bar on your timeline instead of stalling your review.
How we handle your data
Our default is to hold as little as possible, for as short a time as possible.
- Data minimization
- We ask for the narrowest dataset that lets us build and test. Where synthetic or de-identified data is sufficient for development, we use it and keep production PHI out of the development path.
- Where data rests
- For systems we operate, data stays within the boundary agreed in the engagement, in a region we name in writing. We do not move data between regions without your written approval.
- Retention and deletion
- Retention is set per engagement and written into the agreement. On termination we delete or return data on the schedule in the BAA and confirm completion in writing.
- AI providers and your data
- Where an engagement uses a third-party model provider, we use enterprise terms that exclude your data from provider training, we name the provider in the subprocessor list, and we require it to be covered by the appropriate agreement before any PHI is involved. If a provider cannot meet that bar, we design around it.
Subprocessors
Third parties in the delivery path for this website and for our own operations. Engagement-specific subprocessors are named in the agreement for that engagement, and we notify you before adding one that touches your data.
| Subprocessor | Purpose | Location |
|---|---|---|
| Google Cloud Platform | Website and application hosting | United States (us-central1) |
| GoDaddy | Domain registration and DNS | United States |
| Let's Encrypt | TLS certificate issuance | United States |
Engineering and operational practices
- Access control
- Named individual accounts, public-key authentication for infrastructure, no shared logins, and access removed when it is no longer needed rather than when someone remembers.
- Change management
- Changes to production go through review and are traceable to a specific author and rationale. Infrastructure configuration is kept in version control where practical.
- Vulnerability management
- Operating system security updates applied on a regular cadence, dependency advisories monitored, and a documented path for urgent patching outside the normal cadence.
- Monitoring and logging
- Access and application logs retained for the period set in the engagement, with the retention window stated rather than assumed.
- Incident response
- A documented procedure for containment, assessment, and notification. Where a BAA is in force, we notify you within the timeframe that agreement specifies.
- Business continuity
- Backups for systems we operate, with restoration tested rather than assumed. Recovery objectives are agreed per engagement instead of promised generically.
Certification roadmap
We publish this so you can judge whether our direction matches your requirements, and hold us to it.
Our next step is formalizing the policy set and evidence collection that an independent audit requires. We are not going to put a date on a SOC 2 report we have not started, because a vendor that overstates its audit status is exactly the vendor your process exists to catch.
If an attestation is a hard requirement for your organization, contact us and we will tell you honestly where we are rather than what you want to hear.
Security contact
For vendor assessments, security questionnaires, BAA requests, or to report a vulnerability in something we operate, write to the address below. Questionnaires get a real answer from a person, not a sales response.
Responsible disclosure
If you are reporting a vulnerability, please give us a reasonable window to remediate before public disclosure. We will acknowledge your report and keep you informed.
Do not include PHI in security correspondence.