Security

Signal is designed for enterprise data-handling requirements: single-tenant deployments, first-party data only, encryption everywhere, role-based access, and full audit logging.

Principles

• Single-tenant isolation. Every customer gets their own dedicated Signal deployment. No shared infrastructure, no cross-customer data paths.
• First-party data only. Datafly.js loads from the customer’s own subdomain, events go to the customer’s own endpoint, and all cookies are first-party.
• Encryption in transit and at rest. TLS for all network traffic; sensitive stored data encrypted with industry-standard ciphers and managed-DB envelope encryption.
• Certificate revocation checking. Before delivering to a vendor, Signal checks that the vendor’s TLS certificate has not been revoked, using OCSP and CRLs. A revoked certificate always stops delivery. Set TLS_REVOCATION_CHECK=hard on the delivery workers to also stop delivery when revocation status cannot be determined (the default, soft, connects and records it in the datafly_tls_revocation_checks_total metric). Allow outbound port 80 to certificate authorities for the checks to work.
• Role-based access control. Authenticated and authorised at the management API level. Owners, admins, editors, viewers.
• Audit logging. Every administrative action recorded with actor, timestamp, target, and detail. Retained for compliance.
• Two-stage consent enforcement. Consent gates events at both ingestion and delivery, with full CMP integration.

Account protection

• Password policy. Passwords are 12 to 72 bytes and are screened against known data breaches when they are set, using the Have I Been Pwned range API: only the first five characters of the password’s hash leave the deployment. There are no composition rules. Passwords are stored as bcrypt hashes.
• Two-factor authentication. Password sign-in adds a code from an authenticator app (TOTP: 6 digits, 30-second codes, each usable once) and gives each user 10 single-use recovery codes. By default it is required for organisation and cluster administrators, including the administrator password login that works when single sign-on is enforced; set MFA_POLICY=all on the management API to require it for everyone, or optional to let users choose. Five wrong codes in 15 minutes lock two-factor sign-in for the account until the window passes. An administrator can reset a member’s two-factor set-up from Settings → Members if they lose their phone. Single sign-on users get MFA from their identity provider.
• Brute-force protection. After 10 failed sign-ins for one account, or 100 from one address, within 15 minutes, further attempts are refused with HTTP 429 until the window passes. Single sign-on is unaffected.
• Sign-in audit trail. Successful and failed sign-ins, sign-outs, password changes and resets, and API key use (at most once an hour per key) are written to the audit log with the client IP address and user agent.

Compliance

Datafly Signal’s compliance posture is built on Signal’s single-tenant, customer-hosted architecture — customer data does not enter Datafly-controlled infrastructure.

• GDPR / UK GDPR — Signal is designed to support compliance for customers operating in scope. The customer is the data controller; Datafly’s role and responsibilities are documented in the standard Data Processing Agreement.
• ISO 27001 — certification work is on the roadmap. Signal’s narrow ISMS scope reflects the customer-hosted deployment model, which materially reduces the controls in scope compared with a SaaS data processor.
• SOC 2 — planned alongside US expansion.

To request a security questionnaire response or DPA, contact your account team or email hello@dataflysignal.com.