Security you can check, not a badge you have to believe

The failure that ends a multi-tenant company is one customer seeing another customer’s documents. Almost every SaaS prevents it with a WHERE clause in application code, which means one forgotten filter is enough.

• Isolation is enforced by PostgreSQL Row Level Security, not by application code. Every tenant-scoped table carries a policy.
• The application connects with a database role that does not have BYPASSRLS. Even a bug that omits a filter cannot return another tenant’s rows — the database refuses.
• The tenant is never taken from the client. It is derived server-side from the session or from the API token presented.
• Each transaction sets its tenant explicitly and locally, so a connection returned to the pool cannot carry context into the next request.

A signed document is worth only as much as your ability to prove it has not changed since signing.

• Every event is written to an append-only audit trail where each record carries the hash of the one before it. Altering an old record breaks every hash that follows, and the break is detectable.
• UPDATE and DELETE on audit records are blocked by database triggers — not by convention, and with no exception for administrators.
• The evidence dossier is sealed with a hybrid signature: ML-DSA (NIST FIPS 204, post-quantum) together with Ed25519, produced by an audited cryptographic module (OpenSSL). Both must verify.
• A SHA-256 hash of the document is computed before and after each signature, so any later modification of the file is detectable.
• Anyone holding a signed document or its verification code can check integrity publicly, without an account and without trusting us as a witness.

• Passwords are stored with argon2id. API tokens are stored only as hashes — we cannot show you a token again after issuing it, because we do not have it.
• Two-factor authentication via TOTP. Mandatory for platform administrators.
• SSO with SAML 2.0 and OIDC, plus SCIM provisioning, so joiners and leavers follow your identity provider.
• API tokens are scoped, and separated between test and live environments.
• Rate limiting and CSRF protection on state-changing requests; SSH root login disabled on production hosts.

• Object storage is never exposed directly. Every access goes through a short-lived signed URL issued by the API after an authorization check.
• Documents are encrypted at rest with AES-256 using a key we hold and supply on every single read and write (SSE-C). The storage provider never stores that key: without it, the objects are unreadable even to them.
• The buckets holding originals, signed documents and evidence are created with object lock (write-once, read-many), so an object cannot be overwritten or deleted for the duration of its retention.
• Uploads fail closed: any validation failure sends the file to quarantine — no document is created and no credit is consumed. Quarantined files and generated exports expire automatically after 30 days.
• We do not read the contents of your documents, and no third party receives them. When a trusted timestamp is used, the timestamping authority receives only a hash — never the file.

Quathos LLC is a Texas company, but the platform runs in Finland: the application on a dedicated server we operate, the documents in managed object storage in the same location. If you need US residency, we are not the right vendor today, and we would rather you learn that here than three calls in.

The data center, the servers and the object storage are Hetzner’s. What is ours is the encryption key: documents are sealed with a key we supply on every read and write and that the provider never stores, so the objects are unreadable without us. The certifications the data center holds (ISO/IEC 27001 and BSI C5) cover physical and platform security only — they are the provider’s certifications, not ours, and we do not present them as if they were.

Our DPA says this list is available on request. We publish it instead — if you need it for due diligence, you should not have to ask.

SMS and identity verification are optional. With them switched off, no signer data leaves the European Union through those channels.

• Signed documents, originals and evidence sit in object-locked storage: for the length of their retention they cannot be overwritten or deleted, including by us.
• We are not publishing a recovery time or recovery point objective. We have designed for one, but we have not yet timed a full restore, and a number without a rehearsal behind it is a number you should not accept from a vendor. When we have rehearsed it, this section will carry the figure and the date it was measured.
• Known gap, stated plainly: everything lives in a single location in Finland. The object storage replicates across drives and nodes there, and object lock protects against deletion and overwriting — neither protects against losing that location. A second copy elsewhere is the next thing we owe you, and it is not in place today.
• If continuity is a contractual requirement for you, ask us before signing rather than after. We will tell you exactly where we stand.

• Customers act as controller for their signers’ data; we act as processor. A signer who asks us to erase their data is directed to the customer who sent the document — we will not destroy a controller’s records on our own initiative.
• Self-service export and deletion for portal account holders.
• What is never erased on request, and why: the signed document, its evidence dossier, the signature record and the audit trail. Erasing them would destroy the proof the document exists to provide.
• We do not sell personal data and we do not share it for behavioral advertising. No advertising or cross-site tracking cookies are used.

If you believe you have found a security issue, email security@quathos.com. Tell us what you found and how to reproduce it. We will confirm receipt, keep you updated while we work, and we will not pursue legal action against research conducted in good faith that does not degrade the service or access other people’s data.