Trust & security
How we handle health data, and what we will not claim.
Health-tech buyers ask three things before they ask about price: who touches the data, what happens if something goes wrong, and what you are actually certifying. Here are our answers, including the uncomfortable ones.
How we operate
Business Associate Agreements
We sign BAAs where an engagement puts us in contact with protected health information on behalf of a covered entity or another business associate. The agreement is signed before any environment containing PHI is accessed, not after kickoff.
Encryption in transit and at rest
Data is encrypted in transit over TLS and at rest using the platform-native encryption of the hosting provider. Products we build for regulated contexts add application-level encryption for sensitive fields where the threat model calls for it — Patient Talker uses end-to-end encryption on patient communication.
Access control and least privilege
Access to client environments is role-scoped and granted per engagement to the people delivering it. Credentials are held in a shared secret manager rather than in tickets or chat, and access is revoked at the end of an engagement as part of handover.
Audit logging
Systems we build that touch PHI record who accessed what and when, with logs retained for the period the client's own policy requires. We treat an unlogged read of patient data as a defect.
Prototypes run on synthetic data
Healthcare and mental-health prototypes are built on synthetic, non-sensitive data by default. Usability testing, stakeholder demos and fundraising material never require a real patient record, and asking for one is usually a sign the scope is wrong.
Independent security assessment
Products in our healthcare portfolio have been through third-party security assessment as a condition of release. Where a client requires one, we scope it into the release plan rather than treating it as a post-launch item.
Subprocessors
We use established infrastructure and tooling providers — cloud hosting, error monitoring, analytics and CI — and will provide the current subprocessor list for an engagement on request, before contracting.
Incident response
Suspected exposure of client or patient data is escalated to the client's named contact within one business day of detection, with what is known, what is not yet known, and the containment step already taken.
The boundaries
What we do not certify
Studios in this space tend to blur this line. We would rather lose a deal here than in a regulatory review.
- We build HIPAA-aware systems. We do not issue HIPAA certifications — no such certification exists — and we are not a substitute for your compliance counsel.
- We map intended-use boundaries, sensitive-data inventories and clinical dependencies during planning. We do not provide regulatory or legal sign-off.
- We do not determine whether your product is a regulated medical device. We will tell you when we think the question needs a specialist, and we would rather raise it in week one than at submission.
- We are not a clinical provider. Products we build do not deliver medical advice on our authority.
Asking for documentation
Security questionnaires, subprocessor lists, a draft BAA and architecture documentation for a proposed build are all available before contracting. Email contact@zeepalm.com with the document you need and the deadline you are working to.