Compliance program v1.0 · Adopted 2026-07-21 · Sami Ben Chaalia (Security Officer)
The state today. RailCall is 100% compliant with the HIPAA § 164.312 technical safeguards, runs an adopted internal SOC 2 program (independent audit targeted for Q4 2026), and addresses the GDPR Art. 5 + Art. 28 processor obligations. BAAs are signed at Enterprise, reviewed under NDA on request. Everything on this page is what we can back with real artifacts today, not what we plan to say later.
Controls implemented today per our §164.312 map (which the same technical controls satisfy for SOC 2 CC6). Working toward an independent CPA report by Q4 2026. Readiness posture available under NDA on request.
One click in Studio generates an auditor-ready bundle from your station's own receipts: an executive summary of every governed AI action (counted from sealed receipts, never estimated), a verification section where the station re-audits its entire corpus from canonical bytes — failures named, never hidden — the signed execution policy in force, and a HIPAA §164.312 / SOC 2 control mapping. The pack itself is sealed with an integrity hash + Ed25519 signature. See a real one, published unedited from our own dev station.
Full Evidence Packs write-up →Business Associate Agreement drafted (aligned to 45 CFR § 164.504(e)(2)(ii)) and reviewed on request under NDA. Signed per-customer at the Enterprise tier. §164.312 technical safeguards implemented and documented in an adopted Security Risk Analysis. In most deployments RailCall is not a business associate at all — PHI stays on your infrastructure by design.
Full HIPAA write-up →Storage-limitation + integrity + confidentiality principles addressed in Data Retention and Confidentiality policies. Processor DPA available on request. Standard Contractual Clauses in place where a subprocessor is EU-serving.
We haven't started a formal ISO 27001 audit engagement. Most controls a certification would test map to the CC (Common Criteria) trust service categories covered by our in-flight SOC 2 program — Access Control, Change Management, Risk Management, Incident Response, Vendor Management all live in the same adopted policy set. If your procurement questionnaire needs a specific Annex A control mapped, ask under NDA and we'll walk through the artifact for that control.
Deploy fully offline. A self-contained install bundle ships every CLI file, governance ruleset, and the station tarball with an in-bundle sha256 manifest + verifier — move the archive onto a network-isolated host, run verify.sh, then install.sh. No outbound connectivity at install OR at runtime. The local engine has no runtime dependency on any RailCall-operated service.
Full Air-gap / data residency write-up →Complete public list of every third-party processor and infrastructure vendor that touches customer data (Render, WorkOS, Stripe, Resend, GitHub, Cloudflare) with per-vendor data categories and jurisdictions. Updated before any new vendor takes production traffic. Enterprise customers get 30 days' notice via email per DPA §5.
Full Subprocessor list write-up →Full DFD + LINDDUN privacy analysis + STRIDE security analysis for the Phase C egress broker. Every named gap has either a compensating control or a shipped roadmap reference. Auditor cheatsheet maps every receipt field to what it proves + a copy-paste verify-a-receipt runbook. Not the marketing version — the honest one.
Full Threat model write-up →Paste any signed egress receipt or witness anchor + the install pubkey it claims to come from, and get a PASS/FAIL verdict — computed entirely in your browser via @noble/ed25519. No server-side check; the auditor doesn't have to trust anything RailCall operates for the verdict to mean something. Same 4-check pass the station's /api/receipts/verify runs.
Full Verify a receipt write-up →The set below is adopted and internally in force. Full text is confidential — see “Request the bundle” below to receive it under NDA.
| # | Document | Framework basis |
|---|---|---|
| SRA | HIPAA Security Risk Analysis v1 | 45 CFR § 164.308(a)(1)(ii)(A) |
| 01 | Access Control Policy | SOC 2 CC6.1 · HIPAA § 164.312(a) |
| 02 | Encryption Policy | SOC 2 CC6.1/CC6.7 · HIPAA § 164.312(a)(2)(iv) + (e) |
| 03 | Incident Response Policy | SOC 2 CC7.3–7.5 · HIPAA § 164.308(a)(6) |
| 04 | Data Retention & Deletion Policy | HIPAA § 164.316(b)(2)(i) · GDPR Art. 5(1)(e)/17 |
| 05 | Vendor & Subprocessor Management Policy | SOC 2 CC9.2 · HIPAA § 164.308(b) · GDPR Art. 28 |
| 06 | Business Continuity & DR Policy | SOC 2 CC7.5/CC9.1 · HIPAA § 164.308(a)(7) |
| 07 | Change Management Policy | SOC 2 CC8.1 |
| 08 | Risk Management Policy (with operating risk register) | SOC 2 CC3.1–3.4 · HIPAA § 164.308(a)(1)(ii)(A/B) |
| 09 | Access Review Policy | SOC 2 CC6.3 · HIPAA § 164.308(a)(4)(ii)(C) |
| 10 | Acceptable Use Policy | SOC 2 CC1.1/CC1.4 |
| 11 | Confidentiality Policy | SOC 2 C1.1/C1.2 · GDPR Art. 5(1)(f) |
| 12 | Software Development Lifecycle Policy | SOC 2 CC7.1/CC8.1 · NIST SSDF |
| 13 | Password & Credential Policy | SOC 2 CC6.1/CC6.2 · NIST SP 800-63B |
| 14 | Physical Security Policy | SOC 2 CC6.4 · HIPAA § 164.310 |
| 15 | Service Availability & Commitments Policy | SOC 2 A1.1–A1.3 |
One PDF: the SRA, all 15 adopted policies, the BAA draft, and the operating risk register. Sent within 1 business day once the mutual NDA is signed. Happy to sign yours or send ours.
Every “implemented” claim in our internal policies cites a specific file and test that proves it. Every gap is stated as a gap with a documented reason and treatment strategy. If a policy claims something and the code doesn't back it, the policy is wrong, not the code. This is the operating principle behind the program — we'd rather have a smaller number of controls we can genuinely defend than a longer list a review would puncture.
Adopted 2026-07-21 · Next review: at the next station release, and no later than 2027-07-21.