Compliance
HIPAA
We are building DashForDevs toward being able to handle protected health information, and to sign a Business Associate Agreement. We expect that to be in place in early 2027. Until then, this page says plainly where the work stands.
- Status
- In progress
- Target
- Early 2027
- Business Associate Agreement
- Not yet available
- Scope
- Platform, dashboard and API
What This Page Does Not Claim
DashForDevs is not currently able to act as a Business Associate, and we are not asking anyone to place protected health information on the platform today. There is also no such thing as a HIPAA certification, because no body issues one, so any vendor telling you they are “HIPAA certified” is describing something that does not exist. What HIPAA actually requires is a documented risk analysis, implemented safeguards, signed agreements with subprocessors, and evidence of operating all three. That is the work described below.
Today
Already In Place
Verified against the running platform, not planned. These are the foundations the remaining work builds on.
Encryption In Transit
Every connection to the platform, the dashboard and the database is encrypted, with HTTP Strict Transport Security enforced on both public hostnames.
Tenant Isolation
Each organization's data is separated at the application layer. Every request that touches organization data resolves that organization's membership first, and API keys are scoped to a single tenant.
Role-Based Access
Access inside an organization is granted by role and checked per request, so a member sees the parts of the product their role covers and nothing else.
Change Auditing
Every request that changes data is recorded with who made it, what it affected, and when. That record is what answers the question after the fact.
Field-Level Encryption
A multi-key encryption facility with key rotation is in production and protects credentials, access tokens and integration secrets at rest.
Automated Backups
The production database is backed up automatically, and restoring from a backup has been exercised rather than assumed.
Underway
What We Are Building
The gap between where the platform is and what handling regulated data requires. Each is engineering work with a defined finish, not a policy we intend to write.
Encrypting Personal Data At Rest
Extending the existing encryption facility to cover customer identifiers, not only credentials.
Authentication Auditing
Recording sign-in, sign-out, failure and second-factor events alongside the change log already kept.
Enforced Multi-Factor Authentication
Required rather than optional for staff and administrative accounts, using an authenticator app.
Independent Log Retention
Shipping audit records to storage separate from the systems they describe, with a defined retention period.
Formal Risk Analysis
The documented assessment the Security Rule requires, covering where regulated data is created, stored, transmitted and disposed of.
Subprocessor Agreements
Business Associate Agreements with every supplier that would handle regulated data, and replacing any that will not sign one.
SOC 2
The same programme covers SOC 2. Access control, audit logging, encryption, vendor management and incident response satisfy both frameworks, so they are being built once and mapped twice. SOC 2 is an attestation issued by an independent auditor after examining controls over a period of time. It is not a certificate that can be bought, and not something a compliance tool issues. We will publish the report’s availability here when there is one to publish.
Handling Regulated Data?
If you are evaluating DashForDevs for a workload involving protected health information, tell us what you need and when. It shapes what we build first, and we would rather hear the requirement early than be measured against it late.