Security Overview

1. Separation between operators

Every record belongs to exactly one operator, and isolation is enforced by the database itself through row-level security rather than by application code remembering to filter. A request made with another operator's identifier returns nothing, whether it comes from the interface, a crafted API call or a report. Exports, evidence packs and search are all scoped the same way.

2. Access control

• Named accounts only, with role-based permissions and, where the operator uses them, operating-centre restrictions.
• Permissions are evaluated on the server on every request. Hiding a button in the interface is treated as presentation, never as security.
• Sensitive commercial figures are withheld from responses to users whose role does not include them, rather than merely hidden on screen.
• Privileged roles — owner, administrator and Transport Manager — must complete two-step verification.
• Access ends immediately when a membership is ended, while the historical record of what that person did remains attributable.

3. Authentication

• Passwords are stored only as salted hashes by the authentication provider, and are checked against known-breached password databases at the point they are set.
• Time-based one-time-password two-step verification, with ten single-use recovery codes issued once and stored only as hashes.
• Trusted devices expire after 30 days and can be revoked individually or all at once.
• Repeated failed sign-ins throttle and then lock the address for a period; the response wording never reveals whether an account exists.
• Password reset uses a single-use, short-lived link, and the response to a reset request is identical for registered and unregistered addresses.

4. Data protection in transit and at rest

• TLS for all traffic; HTTP Strict Transport Security at the edge.
• Encryption at rest for the database, backups and object storage.
• Customer data hosted in the European Union (Ireland).
• Evidence files and documents are never publicly addressable; each download is a short-lived signed link tied to a permission check made at that moment.
• Offline data on a device is limited to work in transit and is cleared on sign-out.

5. Audit and integrity

Changes are recorded with who, when, the previous value, the new value and the stated reason. The audit trail is append-only: administrators can read it, and nobody — including the operator's owner — can edit or delete an entry. Signed declarations, quality-control reviews and legal acceptances are made immutable by database triggers rather than by convention.

6. Operational security

• Separated production and development environments with least-privilege service credentials.
• Secrets held in managed secret storage, never in source control, and never returned to the browser.
• Automated dependency and configuration scanning, with prompt patching of known vulnerabilities.
• Scheduled processing is monitored by a watchdog that raises an incident if a run is missed or fails.
• Backups with tested restoration, and documented incident-response and continuity procedures.

7. Reporting a vulnerability

If you believe you have found a security issue in FleetVerified, please tell us at security@fleetverified.co.uk with enough detail to reproduce it. We will acknowledge within two working days, keep you updated, and will not pursue anyone who reports in good faith, avoids privacy violations and data destruction, and gives us reasonable time to fix the issue before disclosing it. Please do not run automated scanning or load testing against the production service without written permission.

8. What this overview is not

This is a description of the controls in place, not a certification. Where we hold independent certifications or penetration test reports we will say so explicitly and provide them under NDA on request. We do not claim certifications we do not hold.