Security
This paper describes how Vaultivo protects your documents — written for accountants, IT reviewers, and anyone who wants to know before they commit. Every point describes what runs today. What is missing is in here too.
Version 1.2 · Effective 2026-09-06
It describes controls that are implemented in Vaultivo. It is not a certification, an attestation or an audit opinion: we hold none of those, and this paper substitutes for none of them.
Nor is it a statement of intent. Where a control is missing or unfinished, that is said where it belongs rather than left out. The section at the end collects what we do not have.
If your own procedural documentation needs a description of the process rather than the technology, there is a separate building block for that: Procedural documentation
Every account is its own business, and every record belongs to exactly one. Each query over business-owned data is constrained to the signed-in person’s business, and on top of that a separate authorisation rule decides every individual action.
The separation therefore sits in the data layer rather than in the interface. A query that lost its business scope does not return somebody else’s documents — it returns none.
A business has four roles: owner, employee, accountant and read only. What a role may do is fixed, not assembled from individual permissions.
Passwords must be at least twelve characters and are checked in production against a corpus of passwords known to have been breached. There are deliberately no rules about upper case or special characters: they force short passwords that are hard to remember and rule out long ones that are easy to.
A second factor (TOTP) is mandatory for owners and for our system administration. The other roles can switch it on.
Our system administration can sign in as a user of a business for support. That is bound to the session, time-limited and logged — every such sign-in appears in that business’s own log.
Access runs over TLS only, between the browser and our edge as well as between the edge and the application. Browsers are instructed to reach the site encrypted from then on.
Connections are accepted only from our network provider’s published address ranges; anything else is refused before it reaches the application. A request carrying a hostname we do not serve is closed without an answer.
Documents sit in a private object store with no publicly reachable address. A download runs through a short-lived signed link rather than a permanently valid URL.
Particularly sensitive individual fields are additionally stored encrypted or hashed: two-factor secrets, their recovery codes, and the token of your intake address. Session data is stored encrypted.
What we do not do: we operate no encryption layer of our own over the documents, and we offer neither customer-managed keys nor HSM or BYOK. What is named here is what we do ourselves; we assert nothing about our providers’ disk encryption.
Every incoming file is scanned for malware before anything else happens to it — before any conversion, before text extraction, before it is filed.
An inconclusive result never counts as clean. If it cannot be scanned, it is not processed.
For intake by email a per-business list of accepted senders decides, and the intake address itself is a long random token. Unknown addresses are discarded without a reply, so a valid address cannot be found by guessing.
What you upload or send in is never overwritten. Viewing versions and PDF conversions are created as additional files beside it; the original stays as it arrived.
On arrival a SHA-256 checksum is taken of every file and stored with the document, so a change could be demonstrated.
Those checksums are also recomputed. A nightly run re-reads stored originals and compares them against the recorded value — the least recently verified first, as a rolling window rather than a pass over the whole archive, so the holding is covered continuously. An unreadable object is counted separately from a mismatch, and a single failure does not end the run. What it finds appears in your own log.
Actions on a document and privileged access are logged: who, what, on which document, and when.
Log entries cannot be changed and cannot be deleted. That is not a promise the application makes but a rule in the database itself — an update or delete against the log table is refused, wherever it comes from.
Two limits, so the picture is accurate. Viewing your own document creates no entry: what is logged is privileged access, not every view. And the log has no retention period of its own — it exists as long as the account does.
If you close your account, the archive is deleted after the period stated in the terms, including its log. That is intended, and it is the other side of a right to erasure: a log that outlived a deletion would itself be a body of personal data.
Every archived original and its PDF version is copied hourly to a second, independent provider — not to a second region of the same one.
The credential that writes it cannot delete. The destination additionally carries an object lock of seven days in compliance mode, and has no lifecycle rules that could turn hidden files into deletions.
The scheduled cleanup of that copy deliberately runs outside our own environment, so that nothing running there ever holds a credential capable of deleting the backup.
The database can be restored to any point within the last seven days. Deleted objects in the primary store have a seven-day version window, and the second copy is carried forward hourly.
The procedures are drilled, not merely written down. Measured:
| Drill | Measured | Drilled on |
|---|---|---|
| Total loss — server and database | 23 min 28 s | 2026-08-21 |
| Restoring the database alone | 6 min 28 s | 2026-08-21 |
| Recovering a deleted document | 29 s | 2026-08-20 |
These are measurements of past drills, not commitments. We promise no recovery time and no availability — not here and not in the terms. They exclude the time until an incident is noticed and scoped, and for the total loss also the DNS cutover. The drill ran against a 54 MB database.
We repeat these drills annually, and sooner if the path changes — a different storage provider, a different database plan, a different way of terminating TLS. A measurement nobody refreshes becomes a claim again.
If the service is discontinued permanently, that is announced at least 90 days in advance, and throughout that period the archive stays readable and exportable. This is not a statement of intent: it is clause 8 of the terms and binds accordingly. Nor is it an availability commitment; clause 4 of the terms applies unchanged.
The way out is the export that exists today, not one that would have to be built for the occasion: the original files unchanged, a document table, a table for accounting, either as an ordinary ZIP or as an archival package following BagIt and PREMIS with a checksum for every file. There is no certification for that, and we claim none.
What does not exist belongs here just as much: no escrow with a trustee, no arrangement with a successor provider, no source-code escrow. The hourly second copy is part of running the service and is not an escrow; nobody outside Vaultivo is entitled or able to release an archive from it.
That leaves a limit, and we name it rather than let you find it: a notice period assumes somebody is able to give notice. Against the case where nobody can act any more, only an escrow helps, and there is none. If that limit is not one you want to carry, export on your own schedule; the export is available at any time and delivers the whole archive every time.
These providers are involved in running the service. The list is the same one the data processing agreement carries — it exists in one place and both documents render it from there, so the two cannot drift apart.
| Provider | Region |
|---|---|
| DigitalOcean | fra1 — Frankfurt, DE |
| Backblaze, Inc. | EU Central — Amsterdam, NL |
| OpenAI Ireland Ltd. | IE / US |
| Mailgun | EU |
| Stripe Payments Europe, Limited | IE |
| Cloudflare | EU / global |
| Sentry | EU |
| GitHub, Inc. | US / global |
A new provider is a disclosable change and appears here and in the data processing agreement together. What each one sees, and what a transfer outside the EU rests on, is stated there. (DPA)
In the event of a personal data breach we inform the affected business without undue delay after it becomes known, and support it with its obligations under Art. 33 and Art. 34 GDPR. The same undertaking is in the data processing agreement.
The roles are not interchangeable: the business is the controller and notifies its supervisory authority and the people affected. We supply what it needs for that — the log and the operational logs are the material an incident is scoped with.
Three things you would learn in a vendor review anyway. Better here than in your findings.
Every statement here is tied to a source in our own documentation, and that mapping is maintained. If a control changes, this paper changes — not the other way round.
Name the version you read in your own documentation. We answer questions about individual points; the contact page carries both routes.
Version 1.2 · Effective 2026-09-06