Security & Trust

Version 1.0 · 8 November 2026

This page answers the questions an IT or operations person asks before putting company data into a new system — including the ones whose honest answer is “not yet”. If something you need is missing, ask and we will tell you plainly whether it exists.

The short version

• Hosted in the European Union — Amsterdam, Netherlands.
• One deployment per organisation. Your data is not in a shared multi-tenant database with other customers.
• TLS 1.2 and 1.3, HSTS for one year, HTTP and www both redirect to HTTPS.
• No third-party services. No analytics, no CDN, no email provider, no AI service, no integrations in the application.
• Not yet: multi-factor authentication, single sign-on, encryption at rest, a backup service, or an independent security certification. They are listed below rather than omitted.

Where the data is stored

• On a shared hosting account provided by site.eu, in Amsterdam, Netherlands. The underlying network and data centre belong to LeaseWeb Netherlands B.V.
• Each deployment has its own SQLite database file and its own session directory, both outside the public web root so they cannot be fetched over HTTP even if the web server configuration were bypassed. File permissions are 0600 for the database and 0700 for sessions.
• Uploaded CSV files are read into memory to validate and import them, and are not stored on the server.
• No backup copies are taken automatically (see below).

Encryption

In transit

• TLS 1.2 and TLS 1.3 are served, both with forward-secret cipher suites; the certificate is issued by Let’s Encrypt.
• HSTS is sent with a one-year lifetime, so a browser that has visited once will not silently fall back to plain HTTP.
• Plain http:// and www. requests are redirected to https://metricahq.com before any content is served.
• Session cookies are marked Secure, so they are never sent over an unencrypted connection.

At rest — stated plainly

• The database file is not encrypted at rest. It is protected by file permissions, by sitting outside the web root, and by the isolation of your deployment from every other account on the host.
• If your policy requires encryption at rest, say so early — it is a deployment decision, not something we can claim today.

Access model

Access is decided per person and per organisation, on the server, on every request — not by hiding buttons in the interface.

• Tenant isolation. Every record carries an organisation identifier, and every query filters on it. Cross-organisation reads are tested end to end.
• Accounts are invited, never self-registered. A link is single-use, expiring and role-scoped; only a hash of its token is stored, so a copy of the database cannot be used to redeem an invitation.
• Weak controls are not the control. Hiding a link is cosmetic; the page itself answers 403 to a role that may not open it, and every write re-checks the role.
• Audit trail. Who changed what, when, on which record, with a short summary. Field-level before/after values are not stored — the trail is for accountability, not surveillance.

Authentication and sessions

• Passwords are stored as a one-way hash (bcrypt today), with no way to recover the original; the hash is upgraded automatically when the algorithm changes.
• Session identifier regenerated at sign-in, at invitation acceptance and after a password reset — the usual defence against session fixation.
• Sessions expire after 8 hours of inactivity or at sign-out, and live in files outside the web root.
• Repeated failures are throttled at 5 attempts per 15 minutes for the same email and network address, and the attempt log holds a salted hash of the IP, never the address itself, for at most 24 hours.
• Every write requires a CSRF token; forms posted without one are rejected.

What is deliberately not in place yet

Listed because a security questionnaire is worthless if it only lists strengths.

What the browser is told

Who else touches the data

That is the whole list. The application has no integrations, no analytics and no third-party requests, so there is no other processor to name.

Backups and recovery

• No scheduled backup runs. A snapshot is taken by hand during maintenance and deleted as soon as it has been used.
• A copy of a deployment’s data can be provided on request.
• If a nightly restore is part of your continuity plan, say so before the pilot — it changes the hosting arrangement, and it is better discussed than assumed.

If something goes wrong

• We tell affected customers without undue delay, in plain language: what happened, what data was involved, what we have done, and what you should do.
• Where the law requires notification to a supervisory authority, we make it — see the Privacy Policy.
• Security reports and questions: andrei@metricahq.com with “Metrica security” in the subject. If you believe you have found a vulnerability, tell us before publishing it; we will acknowledge it and tell you what we intend to do.

Keeping this page true

This page describes the system as it is, and it changes when the system does — not when a marketing calendar says so. The cookie inventory is on the Cookie Policy; what is collected, why and for how long is in the Privacy Policy.