Security

Last updated 4 October 2026

Kinetiq is run by the organization operating this service and is designed to support your GDPR, CCPA and SOC 2 obligations. This page lists the controls built into the service today. Each one names where you can see it in the product.

Hosting and transport

• The service runs on Google Cloud in a single region, us-central1: Cloud Run for the application, Cloud SQL for PostgreSQL for data and Memorystore for queues. See subprocessors.
• All traffic is served over HTTPS, and responses carry a Strict-Transport-Security header so browsers refuse plain HTTP. The API is reachable only through the web application, not directly from the internet.
• Encryption keys and database credentials are held in Secret Manager, not in code or images.

Access control

• Role-based access control with six roles: owner, admin, manager, analyst, viewer and sponsor. Each console page and API action checks a named permission; fan email addresses are shown only to roles allowed to see personal information. Check it on the Team page, where each member's role is set.
• Sponsor contacts see only their own sponsor's workspace: its activations, recaps, offers and the leads that consented to that sponsor.
• API keys carry explicit scopes chosen from the same permissions, are stored only as a hash, show when they were last used, and can be revoked at once. Managing members, API keys, single sign-on and organization settings can never be granted to a key.
• Passwords are hashed with argon2id and must be at least 12 characters. Sign-in, password reset and invitation acceptance are rate limited per IP address.
• With dual control turned on, making someone an admin, inviting an admin, lowering data retention, turning off required two-factor authentication or dual control, and creating privileged API keys wait until a second owner or admin approves; making or inviting an owner and changing or deleting single sign-on need a second owner. Nobody can approve their own request, unapproved requests expire after 72 hours, and dual control can be turned on only with at least two owners or admins.
• Requests made with a session cookie must also carry the session's CSRF token.

Single sign-on

• Organizations can connect their identity provider over OpenID Connect, with state, nonce and PKCE on every sign-in. Only an owner can configure it, under Settings, Single sign-on.
• Each email domain must be proven with a DNS TXT record before it routes sign-ins, and a verified domain belongs to one organization only. SSO can be enforced so that members on those domains cannot sign in with a password, other than owners and sponsor contacts.
• A member's identity-provider subject is pinned on first sign-in, so the same email from a different identity is refused.

Audit trail

• Changes made in the console or through the API are recorded with who made them, what changed and the IP address, and so are sign-ins and sign-outs.
• The log is hash-chained: each entry's hash covers the one before it, so an edited or deleted entry breaks the chain. A verify endpoint recomputes the whole chain, and the Audit log page in the console shows the result.

Data protection

• Fan email addresses are stored encrypted with AES-256-GCM and matched by an HMAC-SHA-256 keyed hash, never in plain text. The application never writes email addresses to its logs.
• PostgreSQL row-level security isolates each organization's data in the database itself, in addition to the checks in application code.
• Links and tokens sent by email or shown once (sessions, invitations, password resets, preference links, offer links, recap shares) are stored only as hashes.
• Settings, Data map in the console lists every field that holds personal data, how it is protected and when it is erased.

Privacy operations

• Consent is recorded with the exact wording shown, its policy version and the fan's age confirmation. A Global Privacy Control signal is honoured as an opt-out of sale or sharing.
• Access, rectification and erasure requests are tracked with due dates on the Privacy requests page, which prepares a copy of a fan's information and carries out erasure.
• A daily retention job erases every fan profile with no activity in the organization's retention period (30 days to 10 years, set under Settings, Organization), and deletes older outcomes and records of offers issued.
• Erasure clears the email, name, postal code and consent records, removes IP addresses and device identifiers from scans, and redacts queued and delivered webhook messages.

Integrations

• Webhooks are signed with HMAC-SHA-256 over a timestamp and the body, with a per-endpoint secret stored encrypted.
• Webhook URLs must resolve to public addresses. Failed deliveries get up to nine attempts over about 20 hours, every attempt is in the delivery log, and any delivery can be replayed from the Developers page.
• Ingest endpoints accept an Idempotency-Key, so a retried request is never recorded twice.

Application security

• A strict Content-Security-Policy with a fresh nonce on every page, and headers that forbid framing, MIME sniffing and access to the camera, microphone and location.
• Rate limits per IP address on every request, per session or API key, and tighter limits on sign-in and on the public scan pages.
• Every request carries a request id that ties its log lines together; errors return a reference without internal details.

Reporting a vulnerability

There is no public intake address yet. Customers report through their account representative. To report a suspected vulnerability, give the steps to reproduce it and the address of the affected page or endpoint. Test only against your own organization's data, do not access or change anyone else's, and do not run denial-of-service tests. This page is the contact named in the site's /.well-known/security.txt.

Personal data we hold

Generated from the same data map the console shows.