Security and incident response

Last updated 24 September 2026.

Funelyze is run by a small team. This page says plainly what we do to protect data, what we do when something goes wrong, and how to tell us about a problem. It describes practices we actually follow. Where we do not hold a certification, we do not claim one.

How data is protected

Everything is served over HTTPS. Data is encrypted in transit and at rest.
The database is managed Postgres with automated backups and point-in-time restore. Backups are encrypted.
Production data stays in production. It is not copied to laptops, and development runs against a separate local database and test stores.
Credentials and API keys live in the hosting platform's encrypted environment, never in the repository.
Access to production is limited to the people who need it, through individual accounts with two-factor authentication. There are no shared logins.
Access happens through logged surfaces: application requests and database connections are both recorded, and the app keeps its own record of emails sent and data synced to third parties.
Third parties that process data on our behalf are listed in the privacy policy.

What counts as an incident

Any event that puts the confidentiality, integrity or availability of customer or visitor data at risk. That includes a credential being exposed, unauthorised access to an account or database, data reaching the wrong recipient, a dependency vulnerability being actively exploited, and loss or corruption of data.

We grade incidents into three levels, because the response differs:

Critical. Personal data has been, or may have been, accessed or lost. Response begins immediately.
Significant. A real weakness with no evidence of data being reached, such as an exposed credential we rotate straight away. Response begins the same working day.
Low. A theoretical or low-impact issue. Scheduled into normal work.

How we respond

Contain. Cut off the exposure first: rotate the credential, revoke the token, disable the affected path. Containment comes before investigation.
Assess. Establish what data was involved, whose it was, and over what period, using request and database logs.
Notify. We tell affected merchants without undue delay and, where the incident involves personal data, within 72 hours of becoming aware of it. The notice says what happened, what data was involved, what we have done and what they should do. Merchants are the controllers of their visitors' data, so we support them in telling the people affected rather than contacting shoppers ourselves. Where a store's Shopify data is involved we notify Shopify as well, and we notify the relevant supervisory authority where the law requires it.
Fix. Remove the root cause, not only the symptom, and ship the fix with a test that would have caught it.
Review. Write up what happened and what changes, and make those changes. We keep the record.

Reporting a vulnerability

Email security@funelyze.com with what you found, how to reproduce it and what you think the impact is. We reply within two working days and keep you updated until it is closed.

Please test only against your own account or a store you control, do not access anyone else's data, and give us a reasonable chance to fix the issue before publishing. We will not pursue legal action against good-faith research that follows those lines.

Deleting data

Merchants can delete any quiz or lead from the dashboard at any time, which removes the visitor data that came with it. Stores that installed our Shopify app are erased on Shopify's privacy webhooks: an individual shopper on customers/redact, and the whole workspace on shop/redact, which Shopify sends 48 hours after an app is uninstalled.