Metricward

Legal

Processor terms

What we commit to as a processor, and the technical measure behind each commitment.

The signable document is not published here yet

A data processing agreement is a legal instrument and it should be reviewed by a lawyer before anybody signs it, including us. Publishing a generated PDF that looks executable would be worse than publishing nothing. Ask and we will send the current draft with its version number. Everything below describes the system as it actually runs today.

Roles

You are the controller.

You decide why your visitors are measured and what is collected. The retention period, the collection mode, whether identify() is called and what your privacy notice says are all yours.

We are the processor.

We process visitor data on your instructions, expressed through your project settings, and for no other purpose. We are a controller only for your own account data, meaning your colleagues' names, emails and billing details.

Commitments, and how each is enforced

A commitment with no mechanism behind it is a sentence. Each of these names the mechanism.

CommitmentThe mechanism
We process only on your instructionsCollection mode, consent mode, retention, masking and exclusions are project settings. There is no code path that collects something a project has not enabled.
We do not sell or share your dataThere is no export to any third party, no advertising integration, and no cross-customer identity graph. The per-project hashing salt makes one impossible to build rather than merely prohibited.
We help you answer subject requestsA DSAR console in the product exports or erases everything held for a visitor hash or a user id, then re-counts the rows and issues a receipt.
We delete on your scheduleRetention is a per-project setting enforced by a nightly job that drops expired partitions and verifies the result, rather than a policy nobody runs.
We restrict who can see your dataNo standing staff access, and no support access flow: there is currently no supported route for us to view your analytics. When one is built it will be customer-granted, time-limited and recorded in your audit log.
We tell you about a breach without undue delayA documented response runbook with a 72 hour notification clock that starts at awareness, drilled twice a year.
We tell you before a subprocessor changes30 days notice with a right to object, and the current list published rather than sent on request.
We return or delete on terminationCSV export of raw events and of every report, at any time, from inside the product. JSON and Parquet are specified and not built. After cancellation the account is read-only, then deleted according to your retention setting.

Technical and organisational measures

The Annex II list. Every item is implemented, not planned.

  • Visitor IP addresses are used in memory and never written to disk. No column exists in any table that could hold one.
  • Visitor identifiers are HMACs of a per-project salt that is destroyed every 24 hours, held on a Redis instance with persistence disabled so it cannot survive in a backup.
  • Query strings pass an allowlist before storage, so credentials and email addresses in URLs are never received.
  • Identifier-shaped path segments are masked before storage.
  • Encryption in transit with TLS 1.3, and full-disk encryption at rest.
  • Tenant isolation enforced in code: every analytical query is refused unless it carries a project predicate, and a test asserts one tenant cannot read another.
  • Role-based access control, with session replay and subject access as separate grants that no role includes by default.
  • Append-only audit logging of subject access requests and project setting changes, readable in the product. Membership, key and billing changes are not logged yet.
  • Passkeys, two-factor authentication and enterprise SSO available on the account.
  • Backups encrypted and restored in a scheduled drill, because an untested backup is a hypothesis.
  • Secrets kept out of the repository, with automated scanning on every commit.

Not yet in place, so that a reviewer does not have to work it out: an external penetration test, SOC 2 or ISO 27001 certification, and a formal bug bounty. All three are planned and none of them exists today.

Related: subprocessors, what we collect, security.

Nothing on this page is legal advice, and it is not a substitute for your own assessment.

Processor terms