Trust & security
We build to healthcare-grade security standards and we’re candid about where we are. Below are the controls actually implemented in the platform and our honest readiness status against each framework. To be clear: RadiantScanAI is not yet SOC 2 certified and does not claim third-party attestations it has not earned. This page describes our real posture, not a certificate.
Framework alignment
HIPAA
Aligned — technical & administrative safeguards implemented; BAA available on request. (HIPAA has no certification body.)
GDPR
Aligned — controller/processor model, consent & lawful-basis records, and data-subject access/erasure workflow.
NDPA · POPIA · DPA
Aligned — African data-protection overlay with in-country residency; per-jurisdiction registration as we enter each market.
SOC 2
In progress — NOT yet audited. Controls mapped to the Trust Services Criteria; a Type II report requires an independent auditor over an observation window.
Security practices in place
Authentication
bcrypt (work factor 12), signed JWT access/refresh tokens verified server-side, fail-closed secrets (no fallback keys), account lockout, and rate limiting on auth, AI and data-subject endpoints.
Multi-factor authentication
TOTP (RFC 6238) with the secret encrypted at rest and backup codes stored only as hashes.
Enterprise SSO
OpenID Connect with PKCE. id_tokens are cryptographically verified against the provider JWKS (signature), with audience, expiry and a per-flow nonce all validated before any claim is trusted.
Authorization
An 11-role RBAC hierarchy enforced in the API layer (the authoritative boundary) and in edge middleware.
Encryption
TLS with HSTS in transit; AES-256-GCM with versioned, rotatable keys for sensitive fields at rest.
Tamper-evident audit log
Append-only, SHA-256 hash-chained record of logins, role changes, exports and AI/EHR access; HMAC-signable so silent edits are detectable.
Data minimisation & de-identification
Identifiers are stripped before any AI prompt; the training corpus stores only salted-hash subject references and coarse demographics — never raw PHI.
Web hardening
Strict Content-Security-Policy (object-src / frame-ancestors none), HSTS, X-Frame-Options DENY, nosniff, Referrer-Policy, and secret scanning in CI.
SOC 2 readiness
| Control family | Status | Notes |
|---|---|---|
| Access control & least privilege | Implemented | RBAC, MFA, lockout, fail-closed secrets |
| Encryption in transit & at rest | Implemented | TLS/HSTS; AES-256-GCM |
| Audit logging | Implemented | Hash-chained append-only log |
| Centralised monitoring / SIEM & alerting | Planned | Aggregate logs + alert on anomalies |
| Change management / SDLC | Partial | CI gates, tests, secret scan; formal approval flow pending |
| Vulnerability management | Partial | Dependency review; scheduled third-party pen test pending |
| Incident response | Partial | Runbook defined; tabletop exercise pending |
| Vendor / sub-processor management | Partial | List + DPA/BAA templates; executed agreements in progress |
| Business continuity, backup & DR | Partial | Managed DB backups; documented RTO/RPO pending |
| Risk assessment & policy set | Planned | Formal risk register + policies for the audit |
| Independent SOC 2 Type II audit | Planned | Engage an accredited auditor over an observation window |
Maturity reflects internal implementation; it is not an auditor’s opinion. A SOC 2 Type II report is issued only by an accredited third party.
Controls → frameworks
| Area | Control implemented | HIPAA | GDPR | SOC 2 | NDPA |
|---|---|---|---|---|---|
| Access control | bcrypt(12) + JWT, 11-role RBAC in UI and API, MFA, account lockout | §164.312(a) | Art. 32 | CC6.1 | Part V |
| Audit controls | Hash-chained append-only audit log; operator status view | §164.312(b) | Art. 30 | CC7.2 | s.24 |
| Transmission security | HTTPS/HSTS, strict CSP, X-Frame-Options DENY, nosniff, Referrer-Policy | §164.312(e) | Art. 32 | CC6.7 | s.39 |
| Integrity | Signed tokens verified server-side; typed schema + migrations; CI secret scanning | §164.312(c) | Art. 5(1)(f) | CC6.8 | s.39 |
| Minimisation / de-id | Identifiers stripped before AI prompts; only de-identified references stored | Safe Harbor | Art. 5(1)(c) | CC6.1 | s.25 |
| Consent & lawful basis | Consent records with purpose, lawful basis, timestamp; revocable | Authorization | Art. 6/9 | P-series | s.26 |
| Breach management | Documented breach-response process + register; secret-rotation runbook | §164.400 | Art. 33/34 | CC7.4 | s.40 |
| Vendor management | DPA/BAA templates with cross-border clauses; sub-processor list | BAA | Art. 28 | CC9.2 | DPA |
| Data residency | Per-tenant in-country residency commitment for African markets | n/a | Ch. V | CC6.1 | Residency |
| Availability | Graceful fallback; health probe; CI blocking gates before deploy | §164.308(a)(7) | Art. 32 | A1.2 | s.39 |
Data handling
In demo mode no patient data is processed. In live mode, PHI is de-identified before any AI call, stored encrypted, and access is logged. Sub-processors (hosting, database, AI provider) are documented with data-processing agreements; per-tenant in-country residency is available for African deployments.
Responsible disclosure
Found a security issue? Email security@omnialera.com. We aim to acknowledge within 3 business days and follow a 90-day coordinated-disclosure window. Please do not access data that isn’t yours or degrade the service while testing.
This page is a summary of our security posture and readiness, provided in good faith for evaluation. It is not legal advice, a warranty, or a certification. Regulatory clearance of AI as a medical device, SOC 2 attestation, and jurisdictional registrations are performed by independent third parties and are pursued on our roadmap. Last reviewed with release v3.18.