Security

Separation between organisations

Every table holding customer data carries its owning organisation, and the database enforces isolation itself — it is not the application that filters, it is Postgres refusing the other tenant's row. An automated test creates two organisations and proves non-leakage on every code change, before it is accepted.

Access and authentication

Passwords are never stored; what remains is an irreversible derivation of them. The session lives in a cookie the page's JavaScript cannot read and that never travels to another site. Two-step verification is available and can be required of everyone in the organisation by whoever administers it.

An API key is shown ONCE, at creation, and afterwards exists only as a cryptographic digest — not even whoever runs the server can read it back.

Record of what was done

Every meaningful change leaves an audit line with who, what and when. The record is append-only by database design: no role may alter or delete an individual line, not even the server's own administrative role.

What this document does NOT claim

There is no SOC 2 or ISO 27001 certification, and no independent penetration test has been performed. Claiming otherwise would be easier, and it is exactly the kind of sentence that turns a security page into legal exposure. When any of those steps exists, it will be described here with its date and scope.

Reporting a flaw

Report it through the contact page, describing how to reproduce it. All that is asked is that the flaw not be exploited beyond what is needed to demonstrate it, and that no third party's data be accessed. A good-faith report never triggers action against the reporter.

An incident affecting personal data is reported to those affected and to the competent authority within the deadlines the applicable law sets.