Legal / Security

Security

How Uplift Funnel protects your data: encryption, access control, backups, and how to report a vulnerability.

Effective 2026-07-25

Uplift Funnel sits in the revenue path of your app and holds analytics about your users, so this page describes what we actually do rather than what sounds reassuring.

Report a vulnerability

Email security@upliftfunnel.com with enough detail to reproduce the issue. We will acknowledge within three business days and keep you updated until it is resolved.

We will not pursue legal action against anyone who reports in good faith, avoids accessing or modifying data belonging to others, does not degrade the service, and gives us a reasonable window before disclosing. We do not currently run a paid bug bounty, and we will credit you if you want to be credited.

Encryption

  • All traffic is served over HTTPS with TLS. HTTP is redirected.
  • Data is encrypted at rest by our managed database and storage providers.
  • Credentials for services you connect are stored under authenticated envelope encryption (AES-256-GCM), not in plain text.

Authentication and secrets

  • Dashboard passwords are stored only as salted hashes. Email verification is required before an account becomes usable.
  • API keys are stored only as SHA-256 hashes. The full key is shown once at creation and cannot be retrieved afterwards — if you lose it, you rotate it. We keep a short prefix so you can tell your keys apart in the dashboard.
  • Keys are scoped to a single app, can be revoked at any time, and can be pinned to your app bundle identifier so that a leaked public key is not usable from another app.
  • Inbound webhooks are authenticated: revenue provider webhooks by a per-integration token compared in constant time, and payment webhooks by HMAC signature over the raw request body with a replay window.

Tenant isolation and access control

  • Every record is scoped to an app, and every request is checked for membership of that app before anything is read or written. Roles are owner and member; only the owner can manage billing or delete an app.
  • Changes to flows and experiments are written to an append-only audit log with the actor, the action, and the target.
  • Access to production systems is limited to the operator of the service, over multi-factor authenticated accounts.

Availability and abuse controls

  • Rate limits protect authentication, event ingestion, AI endpoints, and inbound webhooks, backed by the database so limits hold across instances.
  • Request bodies are size-capped to prevent resource exhaustion.
  • Your SDK caches the last known good version of a flow on the device, so your onboarding keeps working even if our API is unreachable. This is the single most important availability property for you, and it does not depend on our uptime.

Data minimisation in the SDK

The SDK does not read the advertising identifier, the vendor identifier, or any cross-app tracking identifier. It generates its own anonymous identifier, scoped to your app. This is a deliberate design constraint, not a default we might quietly change: it is what lets your App Privacy declaration say that no data is used for tracking.

Backups and recovery

The database is backed up by our managed provider with point-in-time recovery. Backups inherit the same encryption at rest as the primary data.

Incident response

If we become aware of a breach affecting your data, we will notify you without undue delay and in any event within 72 hours of becoming aware, with what we know, what we are doing, and what you may need to do. The contractual form of this commitment is in our Data Processing Agreement.

What we do not claim

We are a small team and we would rather be accurate than impressive. We hold no SOC 2, ISO 27001, or HIPAA certification, we do not offer single sign-on or a contractual uptime guarantee today, and we have not commissioned an external penetration test. If your procurement process requires any of these, write to us and we will tell you honestly where we are rather than where we would like to be.