Trust Center
Last updated: July 2026
SIP.IO is an edge-native voice and cloud-contact-center platform, built with tenant isolation and encryption as defaults rather than add-ons. This page summarizes the controls we have in place today, what’s still on the roadmap, and how to reach us for a DPA, a vendor security questionnaire, or a vulnerability report. We’d rather tell you plainly what isn’t built yet than claim it early, so treat the “Roadmap” labels below as accurate, not as marketing softening.
1. Certifications & attestations
| Framework | Status | Notes |
|---|---|---|
| SOC 2 Type II | Roadmap | Not started. Planned once the customer base includes enterprise/regulated buyers who need it; contact us if this is a near-term requirement for you so we can prioritize accordingly. |
| ISO/IEC 27001 | Certified | Information Security Management System certification covering the platform. Certificate available on request, see §7. |
| GDPR (EU) / UK GDPR | In progress | The account/tenant model, encryption, and access controls below are built with GDPR obligations in mind; a standard DPA is available on request (see §6). |
| CCPA / CPRA (California) | In progress | Covered by our Privacy Policy today; a dedicated CCPA rights-request process is on the roadmap. |
| HIPAA (US) | Not offered | No Business Associate Agreement program today. Don’t route PHI through SIP.IO until this changes. |
| PCI-DSS | Not applicable | SIP.IO doesn’t collect or store cardholder data. Billing is invoice/contract-based today, not self-serve card payment; see Pricing. |
| STIR/SHAKEN (US/CA) | Live | Outbound PSTN calls are signed through our termination partner’s per-account subaccount identity model. See What is STIR/SHAKEN? and Outbound & Trunking. |
⚠️ SIP.IO has not completed a SOC 2 audit yet. If that’s a hard requirement for your evaluation today, talk to us about timeline, we’d rather be upfront than have you find out later.
2. Security controls
Encryption. TLS 1.2+ for all API, dashboard, and SIP-signaling transport (including WSS for WebRTC signaling). Voice media uses SRTP, with DTLS-SRTP for WebRTC endpoints. SIP device credentials are never stored as plaintext passwords, only an HA1 digest hash (MD5(username:realm:password)); see Authentication. API keys are shown once at creation and stored only as a hash after that.
Tenant isolation. Every row in the data model carries an explicit, indexed account_id; tenancy is never implicit. Presence, ACD state, and concurrency counters live in a per-account isolated object, not a shared table, so one tenant can’t see or exhaust another’s capacity. See Multi-Tenant & White-Label.
Edge protection. The control plane, public API, and dashboard run on a global anycast edge network with DDoS mitigation and TLS termination built in, not bolted on. There’s no single origin server to take down.
Abuse defense at the signaling layer. Every SIP node runs a defense-in-depth layer with three ban tiers: network-level flood bans, SIP-request-flood detection, and known-scanner User-Agent blocking. See The Media Edge.
Toll-fraud controls. Outbound PSTN calls must originate from an active, account-owned device; there’s no way to originate a call as an account you don’t control. See Outbound & Trunking.
Access & credentials. API access uses per-resource scoped API keys or short-lived (12-hour) JSON Web Token sessions, never a single all-or-nothing credential unless you explicitly grant *. Credentials are header-only; there’s no query-string key, with one narrow exception (a single-use wallboard ticket, since browsers can’t set custom headers on a WebSocket handshake). See Authentication.
Audit logging. Every recording view, play, download, and delete is logged unconditionally, there’s no way to fetch recording audio without an access-log row being written. See Call Recording.
3. Data handling & residency
Account, routing, and CDR data lives in globally-replicated edge data services with data plane presence across regions. Voice signaling and media are carried by dedicated regional SIP nodes, today in the EU and Israel, with additional regions on the roadmap as usage grows, so call audio takes a short in-region path rather than crossing the globe.
Call detail records are kept in a queryable window plus a long-term archive; retention and export are covered in Call CDR & Export. Call recordings, when you enable them, are retained per your account’s configured retention window and deleted (audio only, metadata is kept for the audit trail) once it expires; see Call Recording.
Formal, contractual per-customer data-residency pinning (e.g., an EU-only data plane guarantee) isn’t a shipped feature yet. If that’s a hard requirement for your deployment, talk to us, it’s an architecture we can accommodate for Enterprise accounts.
4. Sub-processors
SIP.IO uses a small number of third parties to deliver the service: our edge/hosting platform, our wholesale voice and number-sourcing partner, and an email-delivery provider for this website’s contact form. The full list, with purpose, data accessed, and region, is on the sub-processors page.
5. Vulnerability disclosure
If you’ve found a security issue affecting SIP.IO, we want to hear about it. Email developers@sip.io with:
- A clear description of the issue and its impact.
- Steps to reproduce, or a proof-of-concept.
- The systems or endpoints affected.
We aim to send an initial response within 3 business days. Good-faith security research against your own account/test data is welcomed. Out of scope: social engineering of our staff, physical attacks on infrastructure, denial-of-service testing, and automated scanning that generates significant traffic without prior coordination.
6. Data Processing Agreement
SIP.IO offers a standard Article 28 Data Processing Agreement with EU Standard Contractual Clauses as an annex, for customers who need one under GDPR or a similar framework. Email developers@sip.io with your billing entity name and a signing contact, and we’ll send the standard DPA for signature. If your legal team needs redlines to our standard form, tell us, we’re a small team so we handle these directly rather than through a self-serve portal today.
7. Trust & security contact
For vendor security questionnaires, DPA requests, vulnerability reports, or anything else on this page, write to developers@sip.io.