Security

Controls enforced by the system, not by a policy document. Tenant isolation enforced by the database, staff access on the record, and a supply chain hardened against compromised dependencies.

One identity, centrally controlled

Sign-in is centralized for every product. Bring your own SSO: Google Workspace, Microsoft Entra, Okta, or any OIDC provider. Membership is invitation-based and access is role-aware.

Tenant isolation

Every row of customer data is scoped to the account, and that scoping is enforced by row-level security in the database rather than by application code that has to remember to check.

The difference matters because application-layer isolation fails open: one query written without the right filter leaks across tenants, and nothing objects. Database-layer isolation fails closed. A static audit runs in continuous integration and fails the build if a table is reachable without a policy.

Who at Mercleo can see your data

Administrative and entitlement changes are logged. Access to personal data is recorded separately, so support activity is reviewable rather than assumed.

Records are soft-deleted rather than destroyed, which means an action can be traced after the fact instead of leaving a gap where the evidence was.

What we do not yet publish is the written access policy behind that logging: what a support engineer must do before reading tenant data and how long elevated access lasts. If your review needs it before we publish it, ask us.

Encryption

Customer data is encrypted in transit with TLS and at rest by the managed platforms that store it. Keys are held and managed by those platforms; we do not offer customer-managed keys today, and this page will say so for as long as that is true.

Backups and recovery

Databases are backed up automatically on our providers' managed schedules. We do not yet publish recovery-point or recovery-time targets, because we will not publish numbers we have not proven against a tested restore. If your diligence needs specifics, ask us and we will answer with what is actually configured.

Supply chain

Most modern compromises of a product like this one arrive through a dependency rather than through the product. Every dependency is pinned to an exact version, installed from a frozen lockfile, and scanned on every pull request.

Beyond scanning, no dependency version is adopted until it has been published for 72 hours. Malicious releases are typically pulled within a day or two of publication. The cooldown is what keeps a compromised version out of the build during the window before anyone has flagged it.

Payments

Card data never touches Mercleo. Payments are processed by Stripe.

Testing

No third-party penetration test has been completed yet. When one is, its date and a summary will be published here.

What runs today is continuous and automated: the tenant-isolation audit, architecture checks, and the supply-chain rules above, all enforced on every build.

The same thing, scannable. Because reviewers skim before they read.

SSO
Google Workspace, Microsoft Entra, Okta, generic OIDC.
Isolation
Row-level security at the database layer, per account, audited in CI.
Audit
Administrative and entitlement changes logged; personal-data access logged separately; soft deletion.
Payments
Processed by Stripe; card data never touches Mercleo.
Dependencies
Pinned exactly, frozen lockfile, scanned per pull request, 72-hour publication cooldown.
Email
Unsubscribe and preference centre on every marketing send.
Receipts
Built to CRA requirements: sequential serials, split receipting, void and reissue.

The rest of the trust centre. Everything else a reviewer asks for.

Questions a page can't answer? Send us the questionnaire.