Security
Where your data lives, and who can reach it.
Tresora holds balances, statements, ledger entries and payment instructions for whole groups. This page describes how that is built: where the data sits, what separates one customer from another, how sign-in is controlled, what has to happen before anything reaches a bank, and what is written down afterwards.
On this page
- 01Where your data lives
- 02Whose machines it runs on
- 03How your data is kept from another customer’s
- 04Who can sign in, and how you control it
- 05What has to happen before anything reaches a bank
- 06What is recorded, and how far a figure can be traced
- 07What we hold, and what comes next
- 08Reporting something you have found
Residency
Where your data lives
In the European Union, and it stays there.
That is a property of where the platform runs rather than a setting somebody remembers to tick. There is no screen, no flag and no support ticket that puts a group’s balances outside the European Union.
Data your entities generate in Europe is processed in Europe, so there is no transfer out of it for you to review before you can sign.
Infrastructure
Whose machines it runs on
OVHcloud, in France.
The platform runs on OVHcloud, a European provider operating its own data centers in France. That sits upstream of the residency answer above: the machines, the disks and the backups are in the European Union because the French regions are where this deploys, not because a region field happens to hold a European value and could hold another one.
Knowing whose hardware holds your balances is what lets you assess the layer that actually stores them. Plenty of vendors will not tell you, and you did not have to ask us.
Nothing reaches those machines in the clear. The web application and the API are served over TLS, and a file that arrives by SFTP arrives under credentials issued to your organization alone rather than a shared drop point several customers can see. On the machines, production storage and the backups taken from it are encrypted at rest. The cryptography is standard and widely reviewed — we do not write our own — and the keys and credentials behind it live in controlled storage, never in source code, a configuration file, a ticket or a message, rotated on a schedule and replaced immediately if anybody who could reach them leaves.
The software we run the service with is ours as well. Support requests, and the history of what was said in them, are handled in a tool we built and operate ourselves — there is no third-party help desk holding a copy of what you wrote to us, and no support vendor for you to add to a sub-processor review.
Backups run automatically, are kept for thirty days, and are stored apart from the production infrastructure they protect — so whatever takes out production does not take the copy with it. Restores are tested on a schedule rather than assumed to work. Development, test and production are separate environments, and a customer’s production data does not leave the production one. The continuity plan behind all of that is exercised at least once a year and after any significant change, and an exercise that turns up nothing is treated as a badly designed exercise rather than a pass.
What OVHcloud holds for that infrastructure
OVHcloud maintains ISO/IEC 27001, 27017, 27018 and 27701, SOC 1, SOC 2 and SOC 3 reports, the Spanish ENS scheme and a CSA STAR registry entry, among others, across its data centers and cloud infrastructure. Those are published, independently verifiable, and we hand over the freely distributable ones with the rest of the document set.
Separation
How your data is kept from another customer’s
By the database, not by application code remembering to filter.
Every table holding customer data carries a row-level policy. A query that has not established its context returns nothing at all — not a partial answer, not somebody else’s rows, nothing.
In most systems separation is a condition somebody remembered to write into a query, so the one query that forgets it exposes another customer. Here the rule lives on the table itself and is applied to every statement, whatever the application asked for. A forgotten filter cannot leak a row, because the row was never visible to the query in the first place.
-- the application's own database role, no organization context set
SELECT count(*) FROM cash_flows;
count
-------
0
(1 row)Access
Who can sign in, and how you control it
Through the identity provider you already run.
Single sign-on is how Tresora expects to be signed in to. Any identity provider that speaks OpenID Connect connects to it — the one your organization already uses for everything else — and the connection is made with you during onboarding rather than left to you as a form and a support address. From then on your provider is what decides who gets in.
Access follows the groups your directory already maintains. Somebody who joins gets Tresora when they get everything else, and somebody who leaves loses it at the same moment — there is no second list of people for anyone to keep up to date, and no leaver who keeps an account because a form was missed.
Inside a workspace, what a person can see and do follows the role you give them. A role is a set of explicit permissions rather than a level, so somebody who needs one screen gets one screen — and the role is checked on every operation rather than once at sign-in.
A direct sign-in to Tresora always takes a second factor — a passkey on your own device, or a code from an authenticator app. It is required rather than offered: there is no setting that turns it off, on your accounts or on ours, so a password on its own opens nothing. Where sign-in goes through your identity provider instead, that is where the factor policy belongs: the rules you already enforce there are the rules that apply.
Who on our side can reach production is a short list of named people. Each signs in under their own account with their own credentials — there are no shared or generic accounts anywhere — and administrative work uses a separate named administrative account rather than an ordinary one with rights added to it. Access is granted against a defined role, on a request somebody else approves; nobody approves their own; and the list is reviewed on a schedule rather than left to grow. Inside the product, a role carries the least it needs to do its job and nothing beside it.
Authority
What has to happen before anything reaches a bank
The approvals you configured, every time.
Tresora instructs your banks on your behalf, and the funds stay in your own accounts. Thresholds, approvers and release rules are yours: nothing reaches a bank without the approvals you require, and nothing moves that you did not authorize.
That is a control worth checking rather than believing, so it is built somewhere you can check it. The approval path is configuration you can read back, and every release is recorded with the person who made it.
The record
What is recorded, and how far a figure can be traced
Every change, with the person who made it.
A rule edited, an approval given, a correction posted, a payment released: each is written down with who did it and when. That record is what an incident review reads, and it is what tells you a quiet Tuesday was quiet.
Figures get the same treatment. Amounts are stored and computed as whole numbers of the currency’s minor unit rather than in binary floating point, so a total does not drift as it is added up — and every figure opens onto the statement line or journal entry underneath it, with the file it arrived in and the date it arrived. Your auditor reproduces it from your own data instead of taking ours.
What a person is shown when something fails is written by us as well. A raw exception message is a description of the inside of a system handed to somebody who did not ask for one, and it is a well-worn way for a system to say more than it meant to. The text on the screen names what happened and what to do about it.
Oversight is not only a trail to follow afterward. The same events raise the alerts your team configures — the conditions are yours to set, so a threshold crossed or an approval missed reaches the right person while it can still be acted on, rather than turning up in a review a week later.
That trail is append-only. Entries are added and never edited or removed, and there is no application path and no administrative path that can alter one — ours included, which is the point: whoever makes a change to production is not somebody who can change the record of it. And it is yours to read — the Auditor role opens it to your own people, scoped to your organization, so checking what happened does not begin with a request to us.
Certification
What we hold, and what comes next
Two certificates you can open right now, and a named program for the rest.
A standard is a written account of how a system is supposed to be put together. This one was built that way from the start, which is why every control above is a mechanism you can go and test today rather than a line item waiting for an audit to make it real.
That extends to how the platform itself changes. A change reaches production only after the automated checks that run against it pass and a designated person approves the deployment; every deployment can be rolled back to the version before it; and a change to the shape of stored data is rehearsed in a test environment before it goes near your book.
Keeping it current is continuous rather than periodic. The dependencies and the platform underneath them are scanned on every build and on every change; what comes back is scored for severity and for what it actually exposes here, then fixed against internal targets and tracked until it is closed. A report from an outside researcher enters that same queue rather than a different one.
The thing an outside auditor brings is not the controls themselves. It is a management system wrapped around controls that already exist, and somebody independent confirming they run the way the documentation says. That confirms what was already true — which is why the controls came first here and the paperwork is catching up to them, rather than the other way round.
In place, and under way
Cyber Essentials — the UK scheme that fixes a verifiable floor: firewalls, secure configuration, permissions, anti-malware and patching kept current, checked by an accredited body.
CSA STAR — the Cloud Security Alliance’s public registry for cloud services. Our entry carries the full Consensus Assessments questionnaire, so a reviewer reads our answer to each control rather than a summary of the answers.
ISO/IEC 27001 — the management-system standard for information security, and the first certificate an enterprise procurement team asks about.
Under way
ISO/IEC 27017, 27018 and 27701 — three extensions on that same management system: security in the cloud, personal data in the cloud, and privacy run as a managed program.
Under way
SOC 2 — what US and multinational buyers usually ask for. It comes off the same management system as the standard above rather than being run as a separate exercise.
Under way
None of this asks you to wait for anything. Ask for the document set, send us the questionnaire you send everyone, or get your own engineers on a call and we will take them through how the isolation is enforced and what the audit trail records, on a system that is actually running. Ask where any of the certifications above stands and you get the stage it is at and the people on it.
Disclosure
Reporting something you have found
There is a published address for it, in the place your tooling looks first.
This site serves /.well-known/security.txt — the file RFC 9116 defines, and the first thing a researcher or their scanner reads. It carries the mailbox to write to, the languages we read, and the date the file itself expires.
A report made in good faith is welcome and nobody who makes one hears from a lawyer for it. Tell us what you found and how to reproduce it, and a person answers.
When we are the ones who find something, a documented incident response plan takes over: severities are classified, the roles are assigned in advance rather than improvised on the day, and the channels we reach you on are written down. Knowing who does what before anything happens is most of what makes a response fast.
The rest of it, written down
Ask the hard question first.
A security team gets straight answers here, including the ones that are no. If a control you need is not on this page, ask rather than reading something into the silence.
Send your own questionnaire if you have one. Answering yours is more use to you than asking you to read ours.