How is my data protected?

Your ad data and WhatsApp conversations carry phone numbers, click identifiers and timestamps - exactly the kind of signal you don't want sitting in a spreadsheet. WAct treats it accordingly. Here's how your data is handled from the moment it leaves your site until it lands back in your ad platform.

Encryption everywhere it travels and rests.

Every request between your site, your BSP's webhook (Twilio, 360dialog, Bird, Gupshup, Meta direct) and WAct moves over TLS 1.2+. Once stored, conversation records, click identifiers and account credentials are encrypted at rest with AES-256. Nothing is written in plaintext on disk.

Phone numbers and PII are hashed before they're stored.

WAct only needs a fingerprint to match a WhatsApp conversation back to a click — not the raw phone number. Numbers are SHA-256 hashed (with a per-workspace salt) the moment they enter the pipeline. The hashed value is what gets matched, exported and shown in your dashboard. The raw number never sits in our database.

Strict data minimization - we don't store what we don't need.

Message bodies, media attachments, contact names, group chats, voice notes — none of it touches WAct. We capture only the metadata required for attribution: click ID (fbclid / gclid / msclkid / ttclid / li_fat_id), utm_* parameters, conversation start timestamp and a hashed phone identifier. If a field isn't used to attribute a conversion, we don't ingest it.

Least-privilege access on our side.

Only a small, named group of WAct engineers can touch production data, and every access is logged and auditable. The controls we keep in place:

• SSO + mandatory 2FA for every WAct employee account — no shared logins, no static admin passwords.
• Role-based access controls inside the app: Owners, Admins, Analysts and Read-only roles each see a different slice of the data, and you decide who lands in which role.
• Ephemeral database credentials. Any direct production query goes through a session-bound credential that auto-expires within minutes. No engineer holds a long-lived database key.
• Redacted views for support. When customer support opens a workspace to help with a ticket, raw identifiers (hashed phone, full click IDs) are masked by default — they only see what's needed to debug.
• Audit log on every access. Each read of customer data — by an employee or a service — is recorded with timestamp, actor, workspace and reason. Logs are retained for 12 months and exportable to your security team on request.
• Production isolation. No customer data is ever copied into staging, sandbox or local dev environments. All non-prod environments use synthetic data only.

Compliant infrastructure: GDPR, CCPA, SOC 2.

WAct is hosted on tier-1 cloud infrastructure (AWS, EU and US regions available) and operates under a written GDPR Data Processing Agreement, CCPA-compliant deletion workflows and SOC 2 Type II controls. You choose the data residency region at workspace setup; data doesn't leave it without your action.

You stay in control of retention and deletion.

Default retention is 24 months for attributed events and 90 days for raw webhook payloads, but you can shorten either to match your privacy policy. End-user deletion requests propagate within 30 days across our systems and any synced ad-platform endpoints, and you can wipe a full workspace from Settings → Data — credentials, hashes and exports — in one click.

‍

If you need a copy of our DPA, sub-processor list or SOC 2 report for vendor review, request it from privacy@wact.io and we'll send it the same business day.

‍