Security & Sub-processors

This page is written for the person doing your security review. It says what we run, who else touches your data, what is encrypted, and — in the last section — what we do not have yet. If something you need is missing, email support@ggrify.com.

The architecture, in one paragraph

We are push-only. Your platform sends us events and player attributes over HTTPS to a REST endpoint, authenticated with a bearer token you generate and can revoke. We do not connect to your database, we do not poll a replica, we do not require a VPN, and we do not need an inbound firewall rule on your side. You choose which fields to send; we never reach in and take more.

This is a deliberate difference from how this category usually works. The common pattern — a read replica polled several times a minute, or a nightly ETL built by the vendor’s engineers — requires your DBA, your network team, and a standing credential into your estate. Ours requires an API key and an HTTP client.

Where it runs

Compute: Fly.io, primary region fra (Frankfurt, EU).
Database: Neon (managed PostgreSQL), encrypted at rest.
Transport: TLS on every endpoint. HTTP is redirected, not served.

Sub-processors

The complete list of third parties that may process data on our behalf. Each is named with what it actually touches, rather than a generic category.

Fly.io — application hosting and compute (EU region). All data in transit through the app.
Neon — managed PostgreSQL. All application data, including player attributes and events you send us.
Clerk — authentication for your team’s logins. Names and email addresses of your users. No player data.
Tigris — object storage for images you upload to use in campaigns. No player data.
Stripe — subscription billing. Your billing contact and payment method. We never store full card numbers. No player data.
Anthropic — AI generation and translation. Processes the campaign content you submit, to return your result. Player data is not sent to it.
Upstash — Redis, used for API rate limiting. Request metadata only.

Not on this list, deliberately: your email and SMS providers. Sending credentials are configured per workspace and per brand and belong to you — we hold them encrypted and use them to send on your behalf. We do not resell a sending relationship, and we are not in the delivery path of any provider you have not chosen.

Encryption

In transit: TLS.
At rest: full-database encryption via our database provider.
Secrets you give us — SMTP passwords, SMS provider tokens, your own AI API key — are encrypted at the application layer with AES-256-GCM, a fresh initialisation vector per value, before they are written to the database. They are never returned to the browser; the UI shows a masked preview only.

Access and isolation

Every query is scoped to a workspace. There is no cross-workspace read path in the application.
Roles and permissions are per workspace, and API keys are workspace-scoped and individually revocable.
Deleting a workspace cascades to its contacts, events, campaigns, media and configuration.

Responsible gambling and suppression

Suppression is enforced by the platform, not by campaign configuration. Events that mean a player must not be marketed to — self-exclusion, cooling-off periods, reality checks, account closure — are marked as suppressing in our event vocabulary, and every outbound message passes through a single gate that reads it. The gate fails closed: if a contact’s status cannot be established, nothing is sent, and the reason is recorded against the dispatch.

Above that, you can author your own send rules — jurisdictional freezes, KYC requirements, risk flags — which apply to every campaign and journey rather than having to be remembered on each one. Those also fail closed on missing data by default.

The honest limit: today our suppression is as current as the last event your platform sent us. Verifying a player’s status against your system at send time is on the roadmap and is not shipped. If your compliance posture requires it, say so and we will discuss timing rather than imply we already have it.

Data retention

Data you create — campaigns, brand kits, templates, media — is retained for the life of the workspace.
Ingested events and player attributes are retained for the life of the workspace.
You can delete contacts, campaigns and media at any time from the product.
Deleting a workspace removes its data on a rolling basis.

We do not currently operate an automated retention window that expires old events on a schedule. If your licence requires a specific retention period, that is a contractual term we should agree rather than something to assume.

What we do not have yet

Stated plainly, because you will find out anyway and because a vendor who hides one gap has probably hidden others.

No SOC 2 Type II report and no ISO 27001 certification. Both are on the roadmap and neither is in progress today. Some vendors in this market hold them; we do not.
No independent penetration test report to share.
No dedicated egress IP addresses. Not currently needed — we are push-only, so there is nothing for you to allowlist — but if a future integration requires outbound calls into your estate, dedicated egress can be provisioned and we will publish the addresses here.
No customer-managed encryption keys and no single-tenant deployment option.
No automated retention expiry, as above.
No published uptime SLA.

A Data Processing Agreement is available on request. Ask and we will send the current version for your legal team to review.

Reporting a vulnerability

Email support@ggrify.com. Please include enough detail to reproduce. We will acknowledge receipt, and we will not pursue action against good-faith research that avoids privacy violations, service degradation and data destruction.