Legal
Security
Effective 9 August 2026 · Last updated 9 August 2026
This page describes how Zappush LLP protects the data our customers trust us with. It is written for the person who has to sign off on bringing us in, and it describes what we actually do rather than what we intend to do one day.
If you have found a security problem in our platform, or you need answers for a vendor review, write to [email protected]. We would rather have the conversation than not.
Where your data lives
The Zappush platform runs on Google Cloud Platform, in Google's United States region. Application services, databases, analytics storage, encryption keys, and backups all sit inside that one environment.
We deliberately do not spread the platform across several cloud vendors. Keeping it in one place keeps the number of systems your data can be in, and the number of people and services that can reach it, small enough to reason about.
Our team accesses the platform from India.
Encryption
In transit. Every connection to our services runs over TLS: the tracking script on your storefront, the dashboard, our API, and every call we make out to an advertising platform on your behalf.
At rest. All data is encrypted on the underlying storage.
Credentials. The access tokens for the platforms you connect, along with the other secrets the platform needs, are encrypted with Google Cloud's managed key service. Each token is bound to the record it belongs to, so a token lifted out of its context cannot be decrypted, including by us. Credentials are never written into source code or configuration files; they are held in a managed secret store, and we maintain a map of which service is allowed to reach which secret so that no service holds a credential it has no reason to hold.
Separation between customers
Every read and every write in the platform is scoped to a single workspace. The workspace identifier is a required argument on data access, not an optional filter, so a query that forgets it does not run at all rather than quietly returning someone else's rows.
This is enforced in the code itself and covered by tests, because the failure it prevents, one customer seeing another customer's data, is the one we are least willing to take a chance on.
Access control
Access to production systems is limited to the small number of people who need it to do their jobs, granted on a least-privilege basis, and reviewed as roles change. Every one of them is under a confidentiality obligation that continues after they stop working with us.
We do not access your data to browse it. We access it to fix a problem you have reported, to investigate a fault or a security event, or where you have asked us to.
Personal data governance
We keep an internal register of every field in the platform that holds personal information, and of every place that field is stored. Automated checks run before any change ships and block a change that would write personal information somewhere the register does not know about.
The point of this is that our understanding of where personal data lives is maintained by the build rather than by anybody's memory. It is the difference between believing you know where the data is and being able to prove it.
Privacy mode
Some businesses cannot have their customers' contact details held in readable form by an outside party at all. For them we offer privacy mode.
With it on, identifying details are converted to an unreadable one-way value at the moment they arrive, and the readable version is never written to disk. The platform still recognises a returning shopper, still counts their orders, and still reports accurately. It simply never holds a name, email address, or phone number that anyone could read, including us.
Privacy mode is set up with our support team rather than from a self-serve toggle, because it changes what some features can do and we would rather walk you through the trade-offs first.
Data sent to advertising platforms
When we send conversion data to an advertising platform for you, contact details are converted to an unreadable one-way value using SHA-256 before they leave us, in the format that platform requires. The platform receives a hash, not an email address or a phone number.
You choose which platforms are connected, which events they receive, and you can disconnect any of them at any time.
Monitoring and recovery
We log activity across our services with a correlation identifier that lets us follow a single request end to end, and we monitor for failures and unusual behaviour. Backups run on a schedule, are encrypted, and expire automatically rather than accumulating indefinitely.
Reporting a vulnerability
If you believe you have found a vulnerability, email [email protected] with enough detail for us to reproduce it. We will acknowledge your report, keep you updated on what we are doing about it, and we will not pursue you for reporting something you found in good faith.
Please do not access, modify, or delete data belonging to another customer, and do not run anything that degrades the service for other people. If you need a safe place to test, ask us and we will arrange one.
What we do not claim
We think being straight about this is more useful than implying otherwise.
Zappush does not currently hold SOC 2, ISO 27001, or any comparable certification, and we do not have a formal external audit programme. We are a small team. What we have is the set of controls described above, built into the platform rather than bolted on, and a willingness to answer specific questions in detail.
If your review process needs something we have not covered here, ask. We will tell you what we do, and where we do not do something, we will say so.
Questions
For security questions, vendor reviews, or a vulnerability report:
Zappush LLP Desk No. WSA43, First Floor, B128, B Block, Sector 2, Noida Uttar Pradesh 201301, India Email: [email protected]