Back to myeztoll.com
Trust Center

Security at MyEZToll

MyEZToll handles vehicle, driver and payment data for rental and fleet operators. This page describes how that data is protected, where it lives, who else touches it, and what happens when something goes wrong — in enough detail that most security reviews can be completed without a call.

Last updated August 16, 2026

Compliance

Certification status

We state where we actually are rather than implying more. Two of the four rows below are inherited from our infrastructure provider and are in force today; the other two are programmes we are running.

SOC 2 Type II

In progress

Readiness work underway against the Security, Availability and Confidentiality Trust Services Criteria. Observation window targeted for Q2 2027. Gap-assessment findings and the remediation plan are available under NDA today.

ISO/IEC 27001:2022

Planned

ISMS scoping follows SOC 2 certification, reusing the same control set and evidence pipeline. Stage 1 audit targeted for Q4 2027.

Microsoft Azure platform

Inherited from provider

All production infrastructure runs on Microsoft Azure, which maintains SOC 1/2/3, ISO/IEC 27001, 27017, 27018, FedRAMP High and PCI DSS attestations. Physical security, hypervisor isolation, hardware lifecycle and datacentre operations are inherited from that programme; the controls described on this page are the ones we own on top of it.

PCI DSS

Inherited from provider

Card data is never transmitted to or stored on our servers. Payment credentials are captured directly by Stripe (PCI DSS Level 1 Service Provider) and we hold only opaque Stripe references, so our environment is out of PCI scope for cardholder data.

SOC 2 Type II is in progress, with the observation window targeted for Q2 2027. Until the report is issued we can share our readiness assessment, control matrix and remediation plan under NDA, and we will accept contractual security commitments in the meantime.

Architecture

How the platform is put together

A single multi-tenant application, a managed relational database, and a set of background workers that talk to external toll, telematics and rental systems. There are no customer-managed servers and no on-premise components.

Web and mobile clients

Browser applications for owners and renters, plus native mobile apps. Clients hold no secrets: they authenticate against the API and receive a short-lived signed token.

Application tier

A .NET API on Azure App Service, behind Azure’s managed TLS termination and platform firewall. Instances are stateless, so scaling out and redeploying carry no data risk.

Data tier

Azure SQL Database with Transparent Data Encryption, automated backups and point-in-time restore. Azure Blob Storage holds documents and images, encrypted at rest.

Background workers

Separately deployed services handle telematics ingestion, toll retrieval and scheduled billing. They share the data tier but are isolated from inbound internet traffic.

Integration plugins

Per-agency and per-vendor connectors are loaded as isolated modules with their own credentials, so a failure or credential rotation in one integration cannot affect another.

Tenant isolation

One logical database, strict row-level ownership. Every record is bound to an owning organisation and every query is constrained to the caller’s organisation.

Controls

What protects the data

Encryption

  • All traffic to the platform is served over TLS 1.2 or higher; plaintext HTTP is redirected and never serves application data.
  • Database connections are encrypted and certificate-validated end to end — no unverified or opportunistic TLS.
  • Data at rest is encrypted with AES-256 through Azure SQL Transparent Data Encryption and Azure Storage Service Encryption, with platform-managed keys.
  • Passwords are never stored or logged in recoverable form; they are held as salted, per-user key-derivation hashes.
  • Third-party credentials that customers entrust to the platform (agency portals, telematics accounts) are encrypted at the application layer before they reach the database.

Identity and access

  • Role-based access control separates owner, employee, renter, partner and administrator capabilities; every API route asserts a role.
  • Sessions are bearer tokens signed with an asymmetric key; role membership is re-validated against the database on every request, so revoking access takes effect immediately rather than at token expiry.
  • Administrative access to production infrastructure is restricted to named personnel, protected by multi-factor authentication at the identity provider and reviewed on a defined cadence.
  • Access is granted on a least-privilege basis and revoked as part of offboarding.

Data handling and residency

  • Production data is hosted in Microsoft Azure datacentres in North America. Customer data is not replicated outside the region for operational purposes.
  • Tenants are logically separated: every record carries its owning organisation, and queries are constrained to the caller’s organisation.
  • Retention is bounded by data class — high-volume telematics positions are retained for 30 days, derived toll and billing records for the life of the account plus the statutory retention period.
  • Customers can request export or deletion of their data; deletion cascades across dependent records rather than leaving orphaned rows.
  • Production data is not copied into development or test environments.

Secure development

  • Changes reach production only through version control and an automated build-and-deploy pipeline; there is no manual file editing on production servers.
  • Environments are separated: development and production run as distinct applications with distinct databases and distinct credentials.
  • Dependencies are tracked and patched; security advisories affecting the stack are triaged on receipt.
  • Secrets used by production workloads are supplied by the platform configuration store, not committed alongside source.

Availability and continuity

  • Azure SQL provides continuous point-in-time restore within the configured retention window, backed by geo-redundant backup storage.
  • Application instances are stateless and can be redeployed from source at any time; a lost instance is a redeploy, not a recovery.
  • Restore procedures are documented and exercised; recovery objectives are stated in the customer agreement.
  • Platform telemetry and alerting cover error rates, job queue depth and integration failures.

Monitoring and logging

  • Application, integration and delivery events are logged centrally with bounded retention.
  • Authentication and administrative actions are recorded for investigation and audit.
  • Alerting escalates stalled processing, elevated failure rates and integration outages to on-call staff.
Subprocessors

Who else processes customer data

This is the complete list. Each vendor is engaged under a data processing agreement, receives only the data its function requires, and is reviewed before onboarding. Customers on an active agreement are notified before a new subprocessor is added.

VendorPurposeData processedRegionAssurance
Microsoft AzureApplication hosting, managed database, object storage, telemetryAll platform dataUnited States / CanadaSOC 2 Type II, ISO 27001, FedRAMP High
StripeCard processing, ACH, payouts to owners and partnersPayment credentials, billing contact, transaction amountsUnited StatesPCI DSS Level 1, SOC 2 Type II
TwilioSMS notifications and inbound message handlingMobile number, message bodyUnited StatesSOC 2 Type II, ISO 27001
Twilio SendGridTransactional email delivery and inbound relayEmail address, message body, attachmentsUnited StatesSOC 2 Type II
PlaidBank account verification for ACH billingBank account tokens, account holder nameUnited StatesSOC 2 Type II, ISO 27001
AnthropicDocument understanding, classification and text extractionDocument images and extracted text submitted for processingUnited StatesSOC 2 Type II, ISO 27001; zero data-retention terms for API traffic
Google Cloud (Document AI, Vision)Optical character recognition of driver licences and documentsDocument imagesUnited StatesSOC 2 Type II, ISO 27001
Managed network egress providersReaching toll and violation agency portals from a stable regional address on the customer’s behalfAgency portal session trafficUnited StatesContractual confidentiality; traffic is TLS-encrypted end to end
Incident response

What happens when something goes wrong

Every incident is triaged against a fixed severity scale and follows the same four stages. Notification is a commitment, not a judgement call.

  1. 1

    Detect and triage

    Immediate

    Automated alerting, customer reports and the disclosure address all feed the same intake. An incident is assigned a severity and an accountable owner at intake.

  2. 2

    Contain

    Within hours of confirmation

    Affected credentials are rotated, affected access paths are closed, and the blast radius is established before remediation begins.

  3. 3

    Notify

    Within 72 hours of confirming a breach of customer data

    Affected customers receive written notice describing what happened, what data was involved, what we have done, and what — if anything — they need to do. Notification is not delayed pending root-cause analysis.

  4. 4

    Remediate and review

    Post-incident

    Root cause is documented, corrective actions are tracked to completion, and a written post-incident summary is made available to affected customers on request.

Severity scale

SEV-1
Confirmed unauthorised access to customer data, or total loss of service.
SEV-2
Partial outage, or a vulnerability exploitable without authentication.
SEV-3
Degraded functionality or an integration outage with a workaround.
SEV-4
Low-impact defect with no security or availability consequence.
Responsible disclosure

Reporting a vulnerability

Send findings to security@myeztoll.com. We acknowledge reports within two business days and will keep you updated until the issue is closed. We will not pursue legal action against researchers who act in good faith, stay within their own account’s data, avoid degrading the service, and give us a reasonable window to remediate before disclosing.

For procurement

Documents available on request

  • Completed CAIQ Lite and SIG Lite security questionnaires
  • Data Processing Agreement and subprocessor notification terms
  • SOC 2 readiness assessment and remediation plan (under NDA)
  • Architecture and data-flow diagram for security review
  • Business continuity and incident response summary
Request documents