Skip to content
Security

Security and data handling

Zigzaag handles phone calls, customer messages and the credentials that connect to your calendar and CRM. This page explains, in plain terms, how that data is separated, protected and retained.

Last updated 17 September 2026

Tenant isolation

Zigzaag is multi-tenant. Every record — agents, conversations, contacts, bookings, workflow runs, usage — carries a workspace identifier, and every query executed by the application is scoped to the workspace resolved from the authenticated session or API key. There is no code path that reads conversation data without a workspace scope.

API keys are issued per workspace and cannot be used to reach another workspace's data. Agencies running many clients get a workspace per client, so a misconfigured agent in one can never read the knowledge base or conversations of another.

  • Workspace-scoped queries enforced at the data-access layer, not in the UI.
  • Role-based access inside a workspace: owner, admin and member, with a separate platform-admin role that is audited.
  • Scoped API keys, revocable at any time, with last-used timestamps.
  • Per-workspace exports and deletion, so one customer's request never touches another's data.

Encryption at rest and in transit

All traffic to Zigzaag is served over TLS 1.2 or higher, with HTTP redirected to HTTPS and strict transport security enabled. Internal service traffic stays on a private network.

Third-party credentials — calendar tokens, CRM keys, telephony and payment secrets — are encrypted at rest with AES-256-GCM using a key held outside the database, and are decrypted only in memory at the moment a request is made. They are never rendered back to the browser, logged, or included in exports; the interface shows only a masked prefix and the date the credential was added.

  • TLS in transit; encrypted volumes for the database and object storage at rest.
  • Integration credentials additionally encrypted at the application layer with a separately managed key.
  • Passwords hashed with a modern memory-hard algorithm; API keys stored only as SHA-256 hashes.
  • Secrets injected as environment configuration, never committed to source control.

Signed webhooks and inbound verification

Every outbound webhook Zigzaag sends is signed with an HMAC-SHA256 signature over the raw request body using your endpoint's secret, alongside a timestamp header. Verify the signature and reject requests with a timestamp outside a short tolerance window to prevent replay.

Inbound webhooks work the same way in reverse: provider callbacks from telephony and messaging platforms are verified against the provider's signature before any payload is processed, and unverified requests are rejected and logged rather than parsed.

  • HMAC-SHA256 signatures with timestamp headers on all outbound webhooks.
  • Signature verification on all inbound provider callbacks, before parsing.
  • Automatic retries with exponential backoff, and a delivery log you can inspect and replay.
  • Per-endpoint secrets that can be rotated without downtime.

Data handling and retention

Your data is stored in Australian infrastructure. Conversation content, transcripts, recordings and knowledge documents belong to you: they are not sold, not shared with other customers, and not used to train third-party foundation models. Model providers are engaged under zero-retention terms where the provider offers them.

Call recordings and transcripts are retained for the period you configure, with a default of twelve months, after which they are permanently deleted. You can shorten the window, disable recording entirely, or redact a specific conversation at any time. Deleting a workspace removes its data from primary storage immediately and from backups within thirty-five days.

  • Australian data residency for conversation content and customer records.
  • Configurable retention per workspace, with recording opt-out.
  • Automatic redaction of card numbers and government identifiers detected in transcripts.
  • Export of all workspace data in machine-readable form, on demand.
  • A Data Processing Agreement is available for customers who need one.

Access control and monitoring

  • Staff access to production is limited to a small on-call group, requires multi-factor authentication, and is logged.
  • No routine access to customer conversation content; support access is time-boxed, requires a ticket reference, and is recorded in the audit log.
  • Audit logging of authentication, permission changes, credential changes, exports and deletions.
  • Automated dependency scanning, infrastructure patching and encrypted, tested backups.

Compliance and telephony obligations

Zigzaag is designed to help you meet Australian Privacy Principles obligations, and our voice agents default to disclosing that a caller is speaking with an AI assistant. Call recording consent notices are configurable per number so you can meet the requirements of your state.

Outbound calling and messaging features include do-not-contact list enforcement, business-hour restrictions and opt-out handling to support compliance with the Spam Act and the Do Not Call Register Act. You remain the party responsible for the content of the messages you send.

Reporting a vulnerability

If you believe you have found a security issue, email support@zigzaag.com.au with the subject line "Security". We acknowledge reports within one business day and will keep you updated through to resolution. Please do not test against other customers' workspaces or perform denial-of-service testing; we will happily provide an isolated test workspace on request.

Need a security review before you buy?

Send us your questionnaire, your DPA, or your architecture questions. We answer them properly, and usually within a day.

No credit card · Free plan forever · Cancel any time