Compliance positioning
April 28, 2026 · View on GitHub
How the project's tools and scenarios map to the requirements of common regulatory regimes. This is not legal advice. Consult your compliance officer / regulator before treating any deployment as compliant. The goal is to make visible what the project provides toward a compliance posture, so you don't have to reverse-engineer it.
HIPAA (US healthcare voice)
HIPAA covers PHI in electronic communications. For a SIP proxy handling protected health information:
| Requirement | Project capability |
|---|---|
| Encryption in transit (45 CFR § 164.312(e)) | TLS via tls_mgm + the tls-from-scratch.md runbook. SRTP via rtpengine. |
| Access controls (§ 164.312(a)) | RBAC with readonly default; OPENSIPS_MCP_BEHIND_PROXY enforces nginx auth on network bind. |
| Audit controls (§ 164.312(b)) | Structured audit logging in security/audit.py. CDR rows include caller/callee/timestamps via the acc module. |
| Integrity controls (§ 164.312(c)) | cfg_backup / cfg_rollback + signed releases (when CI ships them) provide tamper-evidence. |
| Person or entity authentication (§ 164.312(d)) | auth_db with HA1-SHA256 / HA1-SHA512 (mandatory; SHA-1-only digest is non-compliant). |
| BAA required | The project itself runs only on infrastructure you control. Anthropic / OpenAI may need a BAA if you use their LLM with PHI in MCP tool inputs — this is your call, not the project's. |
Anti-pattern: sending PHI (subscriber names, dialed numbers,
call content) to a public LLM API via MCP tool descriptions is
likely a HIPAA violation. Use the CLI (opensips-mcp cfg ...)
for any operation that would expose PHI to the LLM.
GDPR / CCPA (privacy)
| Requirement | Project capability |
|---|---|
| Lawful basis | Project does not collect data; you control all logs. |
| Right to erasure | subscriber_delete, cdr_* queries, db_table_backup for retention proofs. |
| Data minimisation | Linter rule for acc.db_extra review; no telemetry leaves the host without operator action. |
| Pseudonymisation / encryption | TLS in transit; AES-256 at rest is your DB engine's job. |
| Data residency | All processing local to your infrastructure. LLM API calls go to the LLM provider's region. |
| DPA / DPIA | Operator's responsibility. |
Critical for EU operators: the LLM provider's data-handling policy matters. Use a self-hosted LLM (llama.cpp / ollama) with this project's MCP if EU data residency is non-negotiable. Or use the CLI exclusively, which has no LLM dependency.
SOC 2 (vendor trust framework)
The project itself is software, not a SOC 2-audited service. But your deployment of it can be part of a SOC 2 audit. The capabilities that matter:
| Trust Service Criterion | Project capability |
|---|---|
| Security (CC6) | RBAC, audit logging, validators, dependency-pinning |
| Availability (A1) | HA scenarios, drain/promote, smoke-test runbook, snapshot drift |
| Processing Integrity (PI1) | Linter, validator, drift-prevention test suite (576 tests) |
| Confidentiality (C1) | TLS, sanitize_cfg_value, secrets via OPENSIPS_MCP_*_SECRET env |
| Privacy (P1) | Audit logs, subscriber CRUD with delete |
The project's CHANGELOG documents every audit finding and fix across 4 rounds — useful evidence for a SOC 2 type 2 audit.
PCI DSS (payment-adjacent voice)
If your SIP proxy ever touches IVR collecting card numbers, you're in PCI scope. The project does not magically make you compliant; but:
- TLS for sigtran (mandatory; PCI § 4.1).
- SRTP via rtpengine (PCI § 4.1 if cardholder data is spoken).
- No card data should be in CDR
db_extra— review theaccmodparam. - siprec recording of card-collection IVRs is a direct PCI violation;
use
siprec_pause_recording()(cfg_explain documents the API) during card-entry windows.
FCC § 13.114 / E911 (US)
| Requirement | Project capability |
|---|---|
| Accurate caller location for 911 calls | e911_emergency scenario preserves Geolocation: header, synthesises P-Asserted-Identity callback. |
| Routing to nearest PSAP | scenario routes per configured PSAP URI; primary→secondary→ESInet failover. |
| Survival of 911 call regardless of UA registration state | scenario detects emergency BEFORE auth/ACL/ratelimit gates. |
| RTT (real-time text) accessibility | rtt_accessibility scenario (ships with project). |
| Annual testing | post-deploy-smoke-test.md includes 911 path verification. |
The e911_emergency scenario header explicitly notes: this gets
the call to the PSAP; it does not handle FCC NG911 / i3 ESInet
location-acquisition (HELD / LIS) which is operator-specific.
STIR/SHAKEN (US TRACED Act / FCC § 13.114)
| Requirement | Project capability |
|---|---|
| Sign all originating calls | stir_shaken_attestation scenario, attest A/B/C per call source |
| Verify Identity headers on inbound | same scenario, with 60s freshness window |
| Maintain certificate | tls_check_all_expiry warns 30 days ahead |
| Operator-assigned attestation policy | scenario param default_attestation; per-trunk via $avp(trunk_attestation) |
Carrier eligibility for STIR/SHAKEN signing requires an SPC token from iconectiv — outside the project's scope. Once you have the token, the scenario does the cryptography correctly.
CALEA (US lawful intercept)
The project does NOT include CALEA-compliant intercept primitives. For lawful intercept:
- Use the
siprec_recorderscenario as a starting point for full call recording (signalling + media). - Layer your own access controls on the SRS (open5gs / vendor SRS) side — operator must restrict who can read recordings.
- The LE-tap interface (X1 / X2 / X3) is operator-specific; the project does not implement it.
If your jurisdiction requires CALEA, the scenarios get you part-way, but you need a CALEA-certified recording / intercept overlay.
NENA i3 (NG911 in North America)
The e911_emergency scenario:
- ✓ Routes to PSAP / ESInet
- ✓ Preserves
Geolocation:per RFC 6442 - ✓ Failover primary → secondary → ESInet
- ✗ Does NOT handle PIDF-LO acquisition (LIS/HELD)
- ✗ Does NOT handle ECRF query
- ✗ Does NOT include i3 LIS / LDB integration
The structural primitives are in place; the location-acquisition overlay needs operator-specific work.
ISO/IEC 27001 (general infosec)
Maps as SOC 2 above. The project's documentation (security.md, audit history in CHANGELOG, SECURITY.md disclosure policy) provides concrete evidence for an ISMS audit.
Australian / EU emergency calling
| Region | Scenario applies | Caveats |
|---|---|---|
| AU 000 | e911_emergency (covers code 000) | Triple Zero TZP standards differ from FCC; verify |
| EU 112 | e911_emergency (covers 112) | 112 PSAP location handoff per RFC 5031 / 6443; scenario provides the signalling path, not the data layer |
| UK 999 | e911_emergency (covers 999) | BT Caller Locate Information (CLI) is operator-specific |
Practical compliance workflow
- Pick your regulatory regime. Most operators are subject to 1-3 simultaneously.
- Read the relevant section above + the linked scenarios / runbooks.
- Run the post-deploy smoke test after every cfg change. The compliance value of a checklist is in running it, not having it.
- Snapshot before and after every regulated change.
snapshot_*tools provide the audit-trail evidence. - Schedule annual reviews of the compliance positioning vs. what's deployed.
- Engage an actual lawyer / compliance officer for any determination of "are we compliant?". The project's docs are capability mapping, not legal opinion.
What this project does NOT claim
- Not certified for any regulatory regime.
- Not audited by an independent third party (yet).
- Not a substitute for operator-specific compliance work.
- Not a vendor of the audit artefacts (SOC 2 reports, BAAs, etc.).
What it provides: capabilities that make the compliance work possible and less expensive. The auditor's report is yours to earn.