Compliance
Ready, not certified
dotwire is compliance-ready software. It is not, and cannot be, "SOC 2 compliant," "ISO 27001 certified," or "HIPAA compliant" on its own. Certifications and attestations attach to a deployment and the organization running it, not to a piece of open-source software.
dotwire's job is to ship the technical controls a host needs and to be clear about which controls it can't provide. Nothing in these docs claims that dotwire itself is compliant or certified.
Technical controls
- At-rest encryption with AES-256-GCM in both JetStream and Postgres, on by default. See Encryption and retention.
- TLS in transit. Client and inter-service traffic is expected to run over TLS. TLS termination and certificate management are a host deployment concern.
- Hash-chained, append-only audit log with logged audit access, daily checkpoints, and a verify endpoint. Every admin mutation writes an ids-only event. See Audit log.
- Role cross-check and membership authorization. See Auth.
- Redaction that physically removes a message from both stores. See Redaction.
- DSAR export of a user's messages, memberships, role, and audit references. See DSAR export.
- Configurable retention for content and metadata. See Retention.
- Key rotation for both key systems. See Two key systems.
Control mappings
These mappings are a starting point for your own auditor conversation, not a substitute for one. Frameworks are satisfied by an organization's full control environment, of which dotwire's technical controls are one input.
SOC 2 (trust services criteria)
| Framework requirement | dotwire mechanism | Host obligation |
|---|
| CC6.1 / CC6.6 — logical access controls | JWT signature/claims verification + role cross-check pipeline against user_roles and room_members | Manage who holds admin/auditor roles; issue and scope host-side JWTs correctly |
| CC6.7 — transmission and at-rest protection | TLS in transit + AES-256-GCM at-rest encryption | Terminate and manage TLS; supply and custody the encryption key in production |
| CC7.2 / CC7.3 — system monitoring and incident detection | Hash-chained audit log, including self-logging of audit access | Monitor the audit log operationally; define and run an incident response process |
| CC8.1 — change management | No dotwire mechanism | Host owns change management for its deployment: release approval, testing, and rollout process for dotwire and its configuration |
ISO 27001 Annex A (2022)
| Framework requirement | dotwire mechanism | Host obligation |
|---|
| A.5.15 — access control | Role cross-check pipeline (dw:role vs. user_roles) + room membership check against room_members | Define the organizational access-control policy; grant/revoke roles and memberships correctly |
| A.8.10 — information deletion | Redact/delete message API + configurable retention (content and metadata) | Choose and enforce a retention policy; invoke redaction/DSAR endpoints as part of an operational process |
| A.8.12 — data leakage prevention | AES-256-GCM at-rest encryption; audit events never contain message content, only ids | Prevent leakage in host-side systems (logs, backups, exports) outside dotwire's boundary |
| A.8.15 — logging | Hash-chained, append-only audit log | Ship/retain logs per organizational policy; review the audit log periodically |
| A.8.24 — use of cryptography | Both key systems: AES-256-GCM at-rest encryption keys and RS256 JWT signing keys | Custody and rotate the encryption key and JWT private key; document key management procedures |
HIPAA technical safeguards (§164.312)
| Framework requirement | dotwire mechanism | Host obligation |
|---|
| §164.312(a) — access control | Role cross-check + membership authorization pipeline | Assign unique user identities on the host side; manage emergency access procedures |
| §164.312(b) — audit controls | Hash-chained audit log | Review audit log output as part of an operational compliance program |
| §164.312(c)(1) — integrity | Hash chain (hash = SHA-256(prev_hash ‖ canonical_event)) with daily checkpoint anchors and a GET /audit/verify endpoint, enabling tamper detection via chain verification | Act on integrity-verification failures; archive audit_checkpoints rows to independent cold storage on a regular cadence so a verification anchor survives even if the live database is compromised, and retain checkpoint verification records |
| §164.312(e) — transmission security | TLS in transit + AES-256-GCM at-rest encryption for content that traverses JetStream | Terminate and configure TLS correctly for the deployment's network topology |
| Not addressed by dotwire | — | Business Associate Agreement (BAA), and all administrative and physical safeguards, are entirely host obligations — dotwire is software, not a covered entity or business associate |
GDPR
| Framework requirement | dotwire mechanism | Host obligation |
|---|
| Art. 15 — right of access | DSAR export endpoint (decrypted messages, memberships, roles, audit references) | Authenticate and fulfill the data subject's request through the endpoint within the legal deadline |
| Art. 17 — right to erasure | Redact/delete message API; the hash chain survives because audit events carry ids only, never content | Decide and execute an erasure process (including any host-side copies dotwire has no visibility into) |
| Art. 25 — data protection by design and by default | AES-256-GCM at-rest encryption on by default | Keep encryption enabled; document the design choice in the host's own DPIA/records |
| Art. 30 — records of processing activities | Hash-chained audit log as an input to the host's processing-activity records | Compile and maintain the actual Art. 30 record; the audit log is a source, not the record itself |
| Art. 32 — security of processing | AES-256-GCM at-rest encryption + TLS in transit + hash-chain integrity | Perform the host's own risk assessment and select organizational measures beyond dotwire's boundary |
Shared responsibility
| dotwire provides | Host must do |
|---|
| AES-256-GCM at-rest encryption, on by default, both stores | Custody and back up the encryption key (external secret in production; dotwire won't start without one) |
| TLS-capable transport | Terminate TLS and manage certificates |
| Hash-chained, append-only audit log with self-logged audit access | Custody and rotate the host's RS256 JWT private key; set the token TTL policy |
| Role cross-check + membership authorization pipeline | Grant and revoke roles/memberships correctly via the admin API; keep user_roles and room_members accurate |
| Redact/delete message API (GDPR Art. 17 mechanism) | Choose and enforce retention policy (content and metadata) for both Postgres and JetStream |
| DSAR export endpoint (GDPR Art. 15 mechanism) | Operate the org-level compliance program: policies, security training, DPAs, BAAs, DPIAs, consent management |
| Configurable retention, applied consistently to content and metadata | Encrypt and secure backups; dotwire's at-rest encryption does not automatically cover backup storage the host controls |
| Documentation mapping controls to common frameworks | Harden the surrounding infrastructure: host OS, network, container runtime, secrets store |
What dotwire doesn't do
dotwire is not an org-level compliance product. It has:
- No policy management. Security policy documents live wherever you already manage policy.
- No consent tracking. Consent for data processing is a host application concern.
- No DPIA tooling. The mappings above are an input to a Data Protection Impact Assessment, not a substitute for one.
- No compliance dashboards. dotwire ships APIs and audit data. You build or buy the reporting UI.
- No end-to-end encryption. The server must read message content to fan it out.
- No metadata encryption. Who messaged whom and when stays in plaintext columns so queries work. Use a short, enforced retention window to limit how long it exists.