Security & Compliance
Security engineered in — not bolted on
balanceback is being built for multi-site deployment, with security and compliance designed in from the first line of code. Here's the architecture we're engineering, what maps to the HIPAA Security Rule, and what's on the roadmap — labeled honestly, so your IT, security, and procurement teams know exactly where we stand.
Built for procurement, IT & security
Your evaluation scorecard, answered
Security isn't a box we check at the end — it's the foundation the rest of the platform is built on. Every item below is labeled for exactly where it stands: By design is engineered into the platform today; On the roadmap is named honestly, not hidden.
- By design
Encryption at rest (AES-256-GCM)
PHI is encrypted at rest with AES-256-GCM authenticated encryption. Each record's ciphertext is cryptographically bound to its own identity, so a copied database can't be read and records can't be swapped undetected.
- By design
Tamper-evident audit log
Every access and change appends to an HMAC-SHA256 hash-chained, append-only log — each entry seals the one before it, so any alteration or deletion breaks the chain. The system is designed to refuse to start on a broken chain rather than run unprotected.
- By design
Role-based access control
Per-clinic, role-based permissions govern who can run tests, sign reports, and administer the system — enforced by one central policy decision point, not checks scattered through the code.
- By design
Multi-tenant isolation
The cloud reports layer isolates each organization's data by tenant. Clinical directors see across their own sites — and only their own sites.
- By design
Documented key custody
Encryption keys are custodied by the OS key store (Windows DPAPI) by default, with an Argon2id passphrase option. Keys never travel with the data and are zeroed from memory after use.
- By design
HIPAA Security Rule alignment
The architecture maps directly to the HIPAA Security Rule technical safeguards — access control, audit controls, integrity, and encryption (mapped below).
- On the roadmap
SOC 2 Type II
An independent SOC 2 Type II audit is on our roadmap; we'll share the report under NDA when it's available.
- On the roadmap
HL7 ORU & FHIR R4
Structured PDF reporting first; HL7 ORU result messages and FHIR R4 DiagnosticReport export are on the integration roadmap.
- On the roadmap
Single sign-on (OIDC / SAML)
SSO via OIDC — and SAML for Azure AD environments — for network-wide identity is on the roadmap.
- On the roadmap
SIEM forwarding & replication
Streaming the audit trail to your SIEM and replicating it to the cloud are designed-in extension points, on the roadmap.
Compliance mapping
How it maps to the HIPAA Security Rule
The technical safeguards in 45 CFR §164.312, matched to the controls we're building.
- §164.312(a)(1) Access control Role-based, per-clinic permissions enforced by a central policy decision point.
- §164.312(b) Audit controls Append-only, HMAC-chained audit log of every PHI access and change.
- §164.312(c)(1) Integrity Hash-chain tamper detection; the system refuses to start on a broken chain.
- §164.312(a)(2)(iv) Encryption AES-256-GCM authenticated encryption of PHI at rest, bound per record.
The 60-second test
What an audit-log entry looks like
A single entry from the append-only, HMAC-chained audit log. Each entry carries the prior entry's MAC and its own — the chain that makes tampering detectable. This is the schema we're building, so your security team knows exactly what they're getting.
{
"schema_version": 1,
"utc_timestamp": "2026-06-03T14:22:07.913Z",
"user_id": { "id": "8f2a3b…", "display": "S. Chen, AuD" },
"workstation_id": "BB-EXAM-03",
"action": "ReportSigned",
"resource_type": "Diagnosis",
"resource_id": "4c19df…",
"outcome": "Success",
"before_hash": null,
"after_hash": "b204…e8d9",
"correlation_id": "018fce…",
"sequence_number": 48217,
"prior_entry_mac": "9f3c…a71b",
"entry_mac": "b8d0…1f4e"
}Fields follow NIST SP 800-66r2's audit-control field set (UTC timestamp, user + workstation identity, action, resource, outcome, content MACs) plus the chain fields (sequence_number, prior_entry_mac, entry_mac). Retention, rotation, and SIEM-forwarding options are detailed in the security overview.
Request a security & deployment briefing
A working session for your IT, security, and procurement stakeholders — architecture, the audit-log and encryption design, the HIPAA control mapping, deployment, and the integration roadmap.