Trust and Security Center
Compliance by architecture, not a policy page.
Your clients' data is some of the most sensitive a Dutch agency holds: their leads, their contracts, their revenue. Metiva is built so the safe version is the only version you can ship. Each client's data is isolated by design and fail-closed, every request binds to a verified tenant claim, and the AVG controls live in the code, not in a disclaimer.
Pre-launch and honest about it: this page describes the architecture, not a list of certifications we have not yet earned.
The guarantees
Five things that are true on day one, not on the roadmap.
Most tools treat security and the AVG as settings you remember to switch on. Metiva treats them as structure: built into how data is stored, identified and isolated, so you cannot ship the non-compliant version by accident.
Isolated per client
Each client company's data is isolated by design, and every query runs inside that company's own tenant context. No shared pool a filter could miss.
Fail-closed by design
Every request binds to a tenant from a verified company claim inside the signed token. Headers the browser sends are ignored, and if the claim cannot resolve, the request fails closed.
Centralised, secure sign-in
One central login service verifies credentials with bcrypt and constant-time comparison, then mints a signed token. The gated app never serves its own login form.
Consent, deny-by-default
Person-level identification stays off until a visitor opts in. Without consent we stay at the company level, IPs are truncated and encrypted, and right-to-erasure is built in.
EU data, by default
Client data is stored and processed in the EU. Production refuses to start without an encryption key configured, so the non-compliant build never reaches a client.
Isolation
Isolated by design, not a filter you can forget.
Most multi-tenant software keeps every customer in one shared pool and separates them with a filter on each query. Metiva keeps each client's data isolated by design and fail-closed: every query runs inside that one company's tenant context, enforced by the architecture instead of remembered by the developer.
- Every query runs inside one client's tenant context, so another client's data is never in scope.
- A mistake or a breach in one client's workspace cannot surface another client's data.
- Each client's data can be exported or erased on its own, which keeps right-to-erasure and offboarding clean.
Tenant binding
The claim always wins.
- The tenant is read from a verified company claim inside the signed token, never from a header the browser controls.
- If the claim is missing, tampered with, or cannot resolve to a client, the request is refused rather than guessed.
- Member access caches are invalidated on role-change, suspend or removal, so revoked access takes effect immediately.
How a request binds to a tenant
Sign-in
One secure front door for every client.
Sign-in is centralised in a single identity service, separate from the app it protects. It verifies the password, mints a signed token, and hands the browser back with the company claim that every later request is bound to.
The sign-in hand-off
Hashed, never stored in the clear
Passwords are hashed with bcrypt. The app never sees or stores a plaintext password, and the token secret stays on the backend.
Constant-time verification
Credential checks run in constant time, so an attacker cannot learn whether an email or password was close by timing the response.
One front door, no local forms
The gated app never serves its own login form. Every sign-in flows through the central identity service, the same hand-off ServiceTitan and Procore use.
AVG by architecture
The privacy controls live in the code, not in a disclaimer.
A Dutch agency answers to the AVG, and so does Metiva. Consent-first handling is a reason to buy, not a paragraph nobody reads. Here is what is enforced, mechanism by mechanism.
Consent, deny-by-default
Targeting and forwards stay suppressed until a visitor decides and grants consent. Nothing leaves before the visitor says yes.
Company-level by default
Where person-level consent is not present, we surface who is on the site at the company level. We never invent a named individual without a lawful basis.
Person-level only on consent
An anonymous visitor resolves to a named person only on consented form capture, and from there onto the deal, on one record.
IP truncated and encrypted
IP addresses are truncated and encrypted at rest, with reveal audited. The raw address is not sitting in a column for anyone to read.
Right to erasure, built in
Delete a visitor's or a person's data on request, with configurable retention. Because each client's data is isolated by design, erasure stays clean and scoped.
EU data residency
Client data is stored and processed in the EU, so a Dutch agency can answer the where-does-our-data-live question with one word.
Production hard-fails without an encryption key. The token and IP encryption-at-rest key is mandatory: the backend refuses to start without it. There is no quiet fallback to storing sensitive data in the clear.
The stack
A modern, boring-on-purpose stack.
Trust is easier to reason about when the architecture is simple. Metiva runs on widely understood, well-supported technology, chosen so the security story is short enough to explain to a client.
Three Next.js frontends
The marketing site, the gated dashboard and the login service are separate apps, each with its own scope, deployed independently.
A NestJS modular monolith
One backend is the single source of truth that every frontend calls, with clear module boundaries instead of a sprawl of microservices to secure.
Neon Postgres, isolated per client
Client data sits in Neon Postgres, reached through the Drizzle ORM with typed, reviewable queries and migration-gated schema changes, and isolated by design so one client is never in scope for another.
BullMQ background jobs
Retries with backoff, SLA breach sweeps, recurring retainer billing and conversion uploads run off the request path, so the app stays responsive.
Cloudinary for files
Branded invoice and contract PDFs, signature images and client uploads are stored as files, kept out of the operational database.
Adapters at the edge
Stripe, Twilio and the ad platforms sit behind signature-verified, retrying adapters, so a third party going down never takes the agency down with it.
These are architectural facts and capability counts, not certifications. Metiva is pre-launch, so we will not display a SOC 2 or ISO badge we have not earned, and we will not publish a de-anonymisation match-rate we cannot stand behind. What we will do is show you the isolation model, the consent flow and the data handling, in detail, on your own data.
Want the legal and processing detail?
The privacy policy and processing terms spell out retention, sub-processors and your rights.
Questions
Straight answers on trust and security.
Each client's data is isolated by design and fail-closed. Every request binds to a verified company claim inside the signed token, and every query runs inside that one company's tenant context. This is deliberately not a single shared pool separated only by a filter, where one missed filter on one query could leak another client's data.
Every request binds to a tenant from a verified company claim inside the signed token. Headers the browser sends are ignored, and if the claim cannot resolve to a client, the request fails closed rather than guessing. From there every query is scoped to that one client's context, so another client's data is never in scope.
We build for the AVG by architecture: consent deny-by-default, IPs truncated and encrypted at rest, person-level identification only on consent, company-level otherwise, and right-to-erasure. We are pre-launch, so we do not display a SOC 2 or ISO certification we have not yet earned. We would rather show you the mechanisms than wave a badge.
In the EU. Data is stored and processed in the EU by default, which is the answer a Dutch agency needs to give its own clients.
Only with consent. Without person-level consent we surface who is on the site at the company level, and resolve to a named person only on consented form capture. We do not publish a person-level match-rate, because it is not a number we can stand behind.
Sign-in is centralised in a separate login service. Passwords are hashed with bcrypt and verified in constant time, the token secret stays on the backend, and the gated app never serves its own login form. It is the same hand-off pattern ServiceTitan and Procore use.
It is on the roadmap. Metiva is built to connect to Dutch accounting tools, but we will not list them as live integrations until they are. Today, invoicing and payments run through Stripe with signature-verified webhooks.
Trust, demonstrated
See the isolation, consent and sign-in model on your own data.
Bring your AVG questions. In 30 minutes we walk the isolation model, the fail-closed tenant binding and the consent flow, with the product open, no slides.
Dutch or English. Speak to the people building it, not a sales script.