What we build, what you run, and where the line is.

Your operational data — customers, contracts, invoices, fleet — is written to a database on your machine. We hold no copy of it and have no live connection to it. There is no shared database, no pooled tenancy and nothing to segment, because each agency runs its own installation.

That is the strongest isolation guarantee available: not a permission check between tenants, but no shared surface to check.

Details are in the Data Processing Agreement, including the three narrow cases where we handle anything at all.

Passwords are hashed with bcrypt at cost factor 12 and are never stored, logged, or recoverable — a reset issues a new one rather than revealing the old.

Sessions use short-lived access tokens with a separate refresh token held in an httpOnly cookie, so a script on a page cannot read it. Sign-out revokes the refresh token server-side rather than only clearing the browser.

Sign-in attempts are rate-limited far more tightly than ordinary traffic — ten attempts per fifteen minutes against two thousand for general requests — which is what makes credential-stuffing impractical rather than merely slow.

There is no two-factor authentication today. We would rather list that as a gap than let its absence be discovered during a procurement review. It is on the roadmap; if it is a requirement for you, say so and it moves.

Five roles, checked on the server for every request: super-admin, agency owner, agency staff, customer, and a devops role that exists for infrastructure work and cannot read booking data.

Authorisation is enforced in the API, not in the interface. Hiding a button is a convenience; the endpoint behind it refuses anyway.

A staff account sees the agency it belongs to and nothing else. Where an owner runs several branches, the active agency is resolved server-side per request rather than taken from anything the browser sends.

Actions that move money or produce a document — confirming a booking, issuing an invoice, generating a contract — are written to an audit trail with the actor, the action and the record, kept for 90 days.

A scheduled job dumps the database every 24 hours and keeps the last 14 archives, on the box, alongside the uploaded documents.

A separate check watches the age of the newest archive and raises a warning at 30 hours and a critical alert at 50 — because a backup job that has silently stopped looks exactly like one that is working.

Restores are tested, not assumed. The procedure is documented, we have exercised it, and it is what you would follow at two in the morning.

One thing you must do: copy the archives off the machine. Backups on the same disk as the database survive a bad deployment but not a lost server. We will tell you this again during onboarding, because it is the single most common gap we see.

In transit: TLS on every hostname, with certificates issued and renewed automatically. There is no plain-HTTP path into the platform.

Credentials: application secrets, database passwords and API keys live in an encrypted vault, decrypted at deploy time. They are not in the repository, not in the image, and not in environment files committed anywhere.

At rest: the database is protected by the disk encryption your hosting provider offers and by the access controls on the server. We do not add field-level encryption on top, and we say so plainly — a claim of "encrypted at rest" that means only "the disk is encrypted" is the kind of half-truth this page exists to avoid.

One agency, one server, one database, one set of containers. Nothing is shared between customers — not a database, not a cache, not a queue.

Everything is deployed from version-controlled automation rather than by hand, so a rebuild produces the same box rather than an approximation of it. Images are pinned by digest, so "the same version" means the same bytes.

Every release passes a full test suite and a vulnerability scan before it can be published. A release that fails either does not ship.

The server itself is yours: its operating system, its firewall, who holds SSH keys, and your hosting provider's own security. We supply the runbook and will walk it with you.

Your platform runs on your infrastructure, so we cannot promise a percentage — and an SLA that did would be measuring something we cannot see. The Service Level Agreement explains what we commit to instead: response times, security patches, and releases that install.

What the software does on its own: health checks on every container, automatic restart on failure, and operational timers for certificate renewal and backups.

Tunisian Organic Law n° 2004-63 on the protection of personal data applies to the agencies running the platform, and the software is built to let you meet it — data minimisation in what we ask for, an audit trail, export and deletion of a customer record.

For agencies serving EU customers, the GDPR roles are set out in the Data Processing Agreement: you are the controller and, for the ordinary running of your platform, there is no processor.

Invoicing follows Tunisian requirements, including the fiscal stamp and VAT presentation on the documents your customers receive.

We hold no certification — not ISO 27001, not SOC 2. We are a small company and buying a certificate we could not sustain would tell you less than this page does. If a certification is a hard requirement for your procurement, tell us early so neither of us wastes the other's time.

If you find a vulnerability, write to contact@rentivofleet.com with enough detail to reproduce it. We will confirm receipt the same working day, tell you what we found, and credit you if you want the credit.

We will not threaten you for reporting in good faith. That should not need saying, and it does.