Trucking cybersecurity readiness checklist.

Any change to remittance details, factoring instructions or a carrier's banking gets verified by calling a number you already hold, not a number from the email or the new rate confirmation. The rule is written down, applies to everyone including the owner, and has no exception for a load that has to move now.

The written procedure, the call-back log or ticket for the last three changes, and the settlements screen showing the change was made after verification.

The rule exists in someone's head. Under deadline pressure, the dispatcher or the settlements clerk verifies using the phone number printed on the document that is itself the forgery.

Security keys, passkeys or certificate-based sign-in on the accounts that move money and freight. SMS codes and plain push approvals are treated as a stopgap, not the destination, because an adversary-in-the-middle page relays both.

The policy showing which methods are allowed, a sign-in report for the billing and dispatch group, and the list of accounts still on SMS with a date to move them.

Email is protected, but the load board, the factoring portal and the TMS each have their own login with a password the whole desk knows.

Every dispatcher, planner and after-hours cover has an account in their own name across email, the TMS and the load boards. Access is removed within one shift of a departure, including load board seats and the factoring portal.

A user list per system with a named owner, the offboarding checklist, and the last three completed offboardings with timestamps.

One shared dispatch login is the standard answer to weekend coverage. When a rep leaves, nobody can tell which loads that seat touched.

SPF, DKIM and DMARC published for every sending domain, and DMARC moved past p=none to quarantine or reject. Lookalike domain and executive impersonation protection turned on for dispatch, billing and the owner.

Current DNS records, a DMARC aggregate report showing your senders pass alignment, and the anti-impersonation policy covering the dispatch and billing mailboxes.

DMARC sits at p=none for years because nobody wants to break the TMS notification emails or the marketing platform, so anyone can still spoof the domain.

Alerts fire when a rule forwards mail outside the company, hides a folder, or deletes rate confirmations automatically. Someone owns the alert and knows what to do with it at 6 a.m.

The alert policy, the last alerts with what was done about them, and a tenant report of external forwarding rules.

The attacker's first move after taking a mailbox is a rule that hides the replies. Nothing is watching for it, so the fraud runs for weeks.

Onboarding verifies MC and DOT numbers against the federal record, checks that contact details match what is registered rather than what the packet says, and re-checks when a carrier suddenly changes phone, email or remittance. Double-brokering red flags are written down and taught.

The onboarding packet with its verification steps, the record of the last carriers onboarded, and the process that triggers when contact details change mid-relationship.

Vetting happens once at onboarding. Then a stolen carrier identity reuses clean authority with new contact details, and the load is gone.

One list of every system that touches loads, hours of service or customer data: TMS, ELD and telematics, load boards, factoring, EDI and API integrations. Each has a named internal owner, an admin account list, and a record of who at the vendor can reach your data.

The inventory with owners, admin lists per system, and the API keys or integration accounts with creation dates and last review.

The ELD and telematics portals were set up by whoever installed the units. Nobody knows how many admin accounts exist, and integrations from a vendor you left last year still hold valid tokens.

For the systems that would stop the operation or expose customer data you hold current security evidence: a SOC 2 Type II report or a documented control mapping, a breach notification clause with a deadline in it, and a written answer on what happens to your data when the contract ends.

The evidence file per vendor with the date received, the contract clause, and the review date in the calendar.

The TMS contract has no notification deadline, so the first you hear about the vendor's incident is from a customer or from the news.

Endpoint detection on every machine, including the shop PC that runs diagnostics, the yard kiosk and the after-hours dispatch laptop. Driver tablets and phones are enrolled in management with screen lock, encryption and remote wipe.

The coverage report compared against the asset list, the enrollment report for tablets and phones, and the list of exceptions with a reason.

Office laptops are covered. The shop machine with the diagnostic software and local admin rights is not, and it sits on the same network as everything else.

Backups an attacker holding your admin password cannot delete, covering servers, the data you are responsible for in the TMS, and the Microsoft 365 tenant. A restore was actually tested in the last twelve months and the test is documented.

Backup configuration showing immutability or an air gap, the last restore test with date and result, and the retention period written down.

Microsoft 365 is assumed to be backed up by Microsoft. It is not, in the sense people mean, and a ransomware or deleted-mailbox scenario proves it at the worst time.

A written answer to one question: how do we cover loads, reach drivers and produce hours-of-service records if the TMS or the portal is unavailable for two days. Contacts, the load list and customer notification are reachable offline, and the plan has been walked through with the people who would run it.

The continuity procedure, the offline contact and load export with its refresh cadence, and notes from the last walkthrough.

The plan is the owner's phone. Driver contact details and hours-of-service records live only in the system that is down.

Sign-ins, endpoints and the money-moving systems are monitored outside business hours, because freight does not stop at 5 p.m. The plan names who declares an incident, who calls the insurer, the customer and law enforcement, and which channel the team uses when email cannot be trusted.

The plan with version and date, the named contacts, the out-of-band channel, and notes from the last tabletop exercise.

There is monitoring but no owner after hours, or a plan written for an office that never mentions loads in transit, cargo claims, or the customer who has to be told.