Skip to main content
Security & data integrity

Built for the data your business runs on.

Driver licences, passenger details, payment metadata, and your accounting ledger all live behind real auth, in real backups, with a real audit trail. Here's exactly how we handle it.

Access

Auth, roles, and request-time checks.

Every API route validates the caller's identity, operator membership, and role before any read or write — checked at runtime, not at deploy time.

  • Firebase Authentication

    Email + password and federated sign-in. Future: LINE, KakaoTalk, and WeChat for global expansion.

  • Operator membership and role

    authenticateVendorRequest() validates both that the user belongs to the operator AND that their role permits the action. 5 assignable roles — Admin, Finance, Operations, Support, Driver — plus Owner, each gating a different set of surfaces. Money is the sharpest line: client rates and driver pay are stripped from the response for roles that shouldn't see them, server-side, not hidden in the UI.

  • Per-route auth middleware

    authenticateRequest() runs on every protected API route. No silent bypasses, no 'we'll add it later' endpoints.

  • Denormalised actor identity

    Every audit entry stores {uid, displayName, role} at the moment of write. Account changes don't erase the trail.

  • Client-facing tracking link

    Live ETA tracking runs on an opaque token bound to a single job, with its own expiry. Your client never gets an account, the link cannot be pointed at a different job, and you can revoke it mid-trip. Views are counted, so you can see whether it was actually opened.

  • Rate limiting

    Per-route rate limits on every public endpoint. Backed by Upstash Redis for distributed counting.

Frameworks

Benchmarked against the standards your procurement team scans for.

We're a growing company without a formal certification yet — and we're transparent about it. What we do today is structure our access management, audit, monitoring, and incident-handling against the same control families enterprise procurement teams look for, so the gap between us and an audited posture is documentation, not architecture.

  • ISO 27001 (Annex A controls)

    We use the 2022 Annex A control set as the internal benchmark for access management, asset inventory, vendor risk, cryptography, and incident response. International recognition makes it the natural target standard for a global system.

  • SOC 2 Trust Services Criteria

    The AICPA Trust Services Criteria — Security, Availability, Confidentiality, Processing Integrity — structure our internal policy. Under NDA we will walk diligence teams through current controls and where the evidence gaps still are.

  • NIST CSF 2.0

    Govern, Identify, Protect, Detect, Respond, Recover. The NIST Cybersecurity Framework is how we structure runbooks, alert thresholds, and review cadences — a free, authoritative operating model.

Inherited posture

The platforms we build on already carry the certifications.

We don't have a SOC 2 logo of our own yet, but the providers we run on do — and we use them in their compliant configurations. This is the trust posture we inherit at the infrastructure layer; your own regulatory obligations as an operator still belong to you.

  • Vercel — application hosting

    Application runtime, deployments, Edge functions, and Speed Insights. Vercel publishes SOC 2 Type 2 and ISO 27001 attestations and DPA terms on request.

  • Google Cloud / Firebase — data plane

    Firebase Authentication, Firestore, and scheduled backups run on Google Cloud. Google Cloud publishes SOC 1 / SOC 2 / SOC 3, ISO 27001 / 27017 / 27018, PCI DSS, and HIPAA attestations.

  • Cloudflare R2 — object storage

    Driver licences, supporting documents, and watermarked job photos sit in Cloudflare R2. Cloudflare publishes SOC 2 Type II, ISO 27001, ISO 27018, and PCI DSS Level 1 attestations.

  • Stripe — payments

    All card data is tokenised and held by Stripe — full PANs never touch our servers. Stripe maintains PCI DSS Level 1 (Service Provider) certification, SOC 1 Type II, and SOC 2 Type II.

Data integrity

Backups, immutability, and audit.

Three independent backup layers, immutable journal entries, denormalised actor identity, and a Firestore security-rule layer enforced at the database — not just at the API.

Backups

  • Firestore PITR (Point-in-Time Recovery) — 7-day rolling window
  • Daily scheduled backup of every collection
  • Weekly scheduled backup with an 84-day retention
  • Configured in Firebase console, not in code — outside the blast radius of a bad deploy

Immutability

  • Wallet mutations always inside Firestore transactions
  • Reversing journal entries on voids — original line is never deleted
  • Period close locks financial fields against further edits
  • GPS plausibility flags stored alongside the original point, never replacing it

Audit

  • logAuditEvent on every state change
  • Per-field amendment diffs on supplier-synced jobs and bookings
  • Activity monitor surfaces every action in near-real-time
  • Idempotent GL backfill replays history if anything drifts
Storage

Where your data actually lives.

Operational data in Firestore. Media and documents in Cloudflare R2. Caching in Upstash Redis with a 5-minute TTL. Each layer is chosen for the job, not bolted on.

  • Firestore

    Operational records (jobs, drivers, clients, ledgers). Security rules enforced at the database — your API can't bypass them.

  • Cloudflare R2

    Driver licences, supporting documents, watermarked job photos. The bucket is private — nothing is served from a public URL. Every read is a presigned link minted per request and scoped to one object: 15 minutes for sensitive documents, an hour for UI images. Guessing a path gets you nothing, because the path is not the credential.

  • Upstash Redis cache

    Operator settings on a 5-minute TTL, with a 30-second negative TTL so a freshly created operator isn't cached as missing. Invalidated on every operator record write, and it fails open — if Redis is unreachable the read falls through to Firestore rather than serving something stale.

Privacy

What we collect, why, and for how long.

Operating a chauffeur system means handling personal data on three sides — passengers, drivers, ops staff. Our privacy policy walks through what each party gives us and how it's used.

  • Driver licences

    Licences and supporting documents reviewed by an AI pipeline (DeepSeek primary, Moonshot Kimi vision fallback). Held in the private R2 bucket and released only through 15-minute presigned links. Retention follows the operator's compliance requirements.

  • Client details

    Booking clients give us name, contact, and pickup address — used for dispatch and milestone emails. Never sold, never shared outside the booking chain (the operator and the assigned driver).

  • Cookies & analytics

    First-party session cookies for auth. Product analytics via PostHog (EU Cloud) — opt-in on marketing pages via the cookie banner, ToS-covered for signed-in users; sensitive UI masked from session replay. Errors via Sentry; capture policy: skip 403, error on 5xx, warning on 4xx/network.

Incident response

What happens if something goes wrong.

Small team, fast escalation. Every critical bug or security issue routes to the same engineer who built the surface — no triage purgatory.

  • Live monitoring

    Sentry for application errors. The Vercel dashboard for build and deploy status. Firebase console for database health. All checked daily.

  • Secret rotation

    API keys (Stripe, Firebase Admin, R2, Resend, Twilio, Upstash, Voyage, DeepSeek, Moonshot, AeroDataBox, FlightRadar24, Google Maps) live in Vercel environment variables. Rotation when exposure is suspected.

  • Forensic-friendly audit log

    If we have to investigate, the audit log + reversing-entry GL + immutable photo evidence give us the same forensic trail you have. We can show our work.

Regions & privacy law

Global by default, regional in the details.

Fusion Link is built to operate worldwide. The country you register in sets your billing currency, your locale, and your invoice tax default. Each driver's own country sets their licence, bank, and document requirements.

  • Global by design

    Single deployment, per-country configuration. Your registered country sets your billing currency, locale, and invoice tax default, and cross-border work keeps them. Your drivers are configured from their own countries, so their ID labels, licence types, bank lists, and required documents match where they actually drive.

  • Per-country tax defaults

    Tax defaults ship for 23 markets, among them SG GST 9%, MY SST 6%, UK VAT 20%, and JP consumption tax 10%. A taxed invoice stores the rate it was issued at, so historic invoices never drift when rates change. The remaining 23 countries issue with no tax row. That covers no-VAT markets like the US and Hong Kong, and markets where we have not set a default yet.

  • GDPR, UK GDPR, Swiss FADP

    Lawful basis for every processing purpose is named in the privacy policy, with Art. 28 GDPR data-processing agreements available on request and explicit consent flows for special-category data. Coverage expands per market as we onboard.

  • Domain allowlist sync

    When an operator adds a custom domain, three GCP lists (Firebase authorizedDomains, Firebase Web key, Maps key) auto-sync — no manual GCP-console toggling, and no half-configured booking sites.

Responsible disclosure

Found something? Tell us first.

Independent researchers are part of how a small team stays honest. If you find a vulnerability, a privacy issue, or a way to misuse the platform, here's how to reach us and what to expect back.

  • How to report

    Email support@fusionlink.pro with the subject prefix "Security disclosure". Include reproduction steps, affected endpoint or screen, and any proof-of-concept material that demonstrates the issue.

  • Safe harbour

    We will not pursue legal action against researchers who follow a good-faith disclosure process: report privately, give us a reasonable window to remediate, don't exfiltrate data beyond what's needed to demonstrate the issue, and respect user privacy.

  • How we respond

    We aim to confirm receipt within 72 hours and keep you updated on remediation. Once a fix ships we're happy to credit you — or keep things anonymous if that's what you'd rather.

Ask anything you need to do diligence.

We're happy to share architecture documents, infrastructure topology, and security policies under NDA. Email us and we'll set up a call — or report a security issue directly using the subject "Security disclosure".