The controls are in the product, and the gaps are on this page

Retention, an append-only audit trail, an organisation-held key escrow and server-enforced consent gates all ship as part of push.tt rather than as a tier you upgrade into. What we do not have is listed just as plainly, because a compliance page that only lists strengths is not one a procurement team can use.

Ask us a hard question What we do not have

Partly shipping. The controls below are built and running. The certifications further down are not — we hold none of them today, and we would rather you learn that here than three weeks into a review.

What is actually built

Each of these is enforced by the server, not by the app being polite about it.

Audit trail, always on and append-only. Sign-ins, user provisioning, channel and key-grant events, policy changes, retention purges — and every Message Vault access, so our own reach is recorded alongside yours
Retention with a defined window. Off by default. Members see a notice in affected channels, because a recorded conversation people think is ephemeral is the problem retention is supposed to solve
Message Vault. Encrypted history readable by your admins through your organisation's escrow key — the mechanism that makes discovery and legal hold possible without giving us the ability to read anything
Consent gates the server enforces. Four settings change who can read what, and each is refused with HTTP 428 until an admin explicitly acknowledges the consequence. They fire on enabling only
Honest deletion. Content is genuinely destroyed and a tombstone keeps sender, kind and timestamps for the audit trail. If retention is set to keep deleted content, affected channels say so in the app — otherwise the word "delete" would be a lie
Per-device keys and revocation. A lost handset is revoked individually rather than by rotating a shared account key

What we do not have

No certifications, stated without hedging. If any of these is a hard requirement, we are not a fit today and it costs you nothing to find that out now.

No SOC 2 — no Type I, no Type II, no audit under way
No ISO 27001
No HIPAA BAA. Do not put PHI in push.tt
No FedRAMP, no CJIS, no StateRAMP
No third-party penetration test or code audit has been performed
No SLA with financial remedies, and today the service runs on a single node — one process, one database file, no replication, nightly backups. Worst-case data loss is about 24 hours

Some of these are achievable and some are a serious investment. If one is blocking a deal, tell us which — it is a far more useful conversation than a questionnaire, and the honest answer to "when" depends entirely on which one you mean.

What end-to-end encryption changes about compliance

This is where push.tt differs from every other product in the category, and it cuts both ways. Being clear about it matters more than making it sound good.

We cannot produce your message content. If someone serves us a legal demand for it, we can hand over metadata and ciphertext, because that is all we hold
You can. Your escrow key lives with your admins, so discovery, legal hold and internal investigation run through you rather than through us
Which makes the key your responsibility. Lose every copy and the history is gone — we cannot recover it, and no support ticket changes that
Metadata is not encrypted. Who spoke to whom, when, for how long, and on which channel is visible to us and would be disclosable. We can hide content; we cannot relay traffic while being blind to its existence
Some features trade it away on purpose. Server-side transcription and the AI assistant both require plaintext, both are off by default, and both are gated — the app labels affected conversations rather than letting the badge stay green

Where the data actually is

Concrete facts a data-protection assessment needs, rather than a reassurance.

One region today — a single hosted server in the United States. There is no region picker, and EU-only hosting is not something we can switch on for you this week
Backups nightly, retained fourteen days, including the key that makes non-E2EE media readable
Sub-processors are few and named on request: the host, the card processor for payments, and the eSIM supplier for data plans. No analytics or advertising SDK is in the app
On-premise removes us entirely, which is the real answer for an organisation that cannot place voice on someone else's hardware — and that page is equally direct about what is still missing from it

If you are filling in a questionnaire

We will answer it, and we will answer "no" where the answer is no. Things that usually come up early, so you can rule us in or out fast:

Data processing agreement — we can sign one; we do not have a pre-audited standard form
Sub-processor list and breach notification terms — available on request
SSO / SAML / SCIM — not built. Accounts are provisioned in the console or by API
Password self-service and admin reset — built; a configurable policy and forced rotation are not
Customer-managed encryption keys for at-rest media — not built; the master key is ours to hold unless you self-host

Send us the requirement, not the brochure

Name the standard you are held to and the control that worries you. We will tell you whether it exists, whether it is planned, or whether it is genuinely out of reach for us right now — which is the answer most often missing from this kind of page.

Talk to us