Delivery software touches everything sensitive in an operation: customer addresses and phone numbers, driver locations, cash amounts, order values, and increasingly the prompts that feed AI copilots. Yet most buyers evaluate on features and price and discover the security posture later, usually through a questionnaire from their own customers. This logistics software security checklist turns that around. It gives you 12 questions to ask any dispatch, routing or fleet vendor before the contract, with the reason each one matters and what a good answer sounds like.
Use it as a vendor security questionnaire for logistics platforms, as an internal readiness check for the system you already run, or as the basis for the security schedule in your contract. Each question is written so that a non-specialist ops lead can ask it and judge the answer.
How to use this logistics software security checklist
Send the 12 questions in writing and ask for written answers. Verbal reassurance on a sales call is not evidence. Ask for documents wherever they exist: an access-control policy, a sub-processor list, a data processing agreement, an incident-response summary. Then score each answer 0 (missing or unacceptable), 1 (partial or vague) or 2 (specific, documented, verifiable) and apply the weights in the scoring table at the end.
Do not confuse certifications with answers. A SOC 2 or ISO 27001 report is useful supporting evidence, but it tells you the vendor has controls, not which ones apply to your data or whether the driver app encrypts its local cache. The questions below get at the specifics.
Theme 1: Identity and access
1. Do you support MFA and SSO, and can we enforce them?
Why it matters: a dispatch console exposes customer PII, live driver positions and the ability to reroute goods. A password alone is not enough protection for that. Single sign-on lets you control who can log in from your identity provider; multi-factor authentication proves it is really them.
A good answer: MFA is available for every user and can be enforced by an administrator for the whole tenant or for specific roles, with authenticator-app support and a documented reset path. SSO via SAML or OIDC is available or on a dated roadmap. We covered the factor choices in detail in our guide to multi-factor authentication for fleet software.
2. How granular is role-based access control?
Why it matters: least privilege limits what a compromised or careless account can do. A customer-service agent should see order status, not payout configuration or API keys.
A good answer: predefined roles (viewer, dispatcher, hub manager, finance, admin) plus the ability to scope users to specific hubs, zones or Shippers. Sensitive actions such as exports, payout changes and integration edits are limited to named roles.
3. What is in the audit log, and can we export it?
Why it matters: when something goes wrong you need to know who did what and when. Audit logs are also the evidence your own customers will ask for after a disputed delivery or a data-subject request.
A good answer: logins, failed logins, permission changes, exports, order edits, reassignments, integration changes and AI-agent actions are all logged with user, timestamp and source. Logs are retained for a stated period and can be exported or streamed to your SIEM.
Theme 2: Data handling
4. Where is our data stored, and can we choose the region?
Why it matters: data residency is a legal requirement in many markets and a customer requirement in more. Regulated industries such as pharmacy delivery may need delivery records to stay in-country.
A good answer: the vendor names the cloud provider and regions, offers a choice of region at onboarding, and can explain what (if anything) leaves the region, including backups, analytics and AI processing. For a deeper treatment see our post on AI data residency for logistics.
5. How is data encrypted in transit and at rest?
Why it matters: this is table stakes, but the details separate mature platforms from demos. Encryption at rest with keys managed by the cloud provider is common; the interesting questions are about key management, database backups and the driver app.
A good answer: TLS 1.2 or higher for every connection including webhooks and the driver app, encryption at rest for databases, object storage and backups, and a statement on how keys are managed and rotated. Bonus points for customer-managed keys.
6. Where do AI prompts and delivery data go when the platform uses language models?
Why it matters: dispatch copilots and AI agents send order details, addresses and sometimes customer messages to a model provider. If that provider is chosen by the vendor, your data is now with a sub-processor you did not pick, under terms you have not read.
A good answer: the vendor tells you exactly which providers are used, confirms that prompts are not used for model training, and ideally lets you bring your own LLM: you pick the provider (OpenAI, Azure OpenAI or another supported option), enter your own API key, and prompts run under your account and your data agreement. Ask also what guardrails stop an agent from leaking data across tenants; our guide to agentic AI without data leakage lists the controls to look for.
The question vendors are least ready for
Question 6 is new enough that many sales teams do not have a written answer. That is fine. What is not fine is a platform that cannot say which model provider receives your customer addresses.
Theme 3: Integrations and devices
7. How are API keys and webhook secrets issued, scoped and rotated?
Why it matters: integration credentials bypass the login screen entirely. A leaked API key in a GitHub repository or a shared Slack channel gives full programmatic access with no MFA in the way.
A good answer: keys are issued per integration with scoped permissions, can be rotated without downtime, are shown once and stored hashed, and every call is logged against the key. Webhooks are signed with a per-endpoint secret so your systems can verify the sender. Our webhooks and batch API guide shows what this looks like in practice.
8. How is the driver app secured on the device?
Why it matters: driver phones are lost, shared and occasionally sold with the app still installed. The app holds today's manifest, customer phone numbers, proof-of-delivery photos and, for cash-on-delivery, the amounts collected.
A good answer: local data is encrypted, sessions are bound to the device and expire, an admin can sign a device out remotely, cached data is wiped on logout, and the app does not expose customer numbers beyond what the current stop needs (masked calling where available).
Theme 4: Resilience and governance
9. What are your backup, RPO and RTO commitments?
Why it matters: a dispatch outage at 7am is a missed delivery day. Recovery point objective (how much data you could lose) and recovery time objective (how long you could be down) are the two numbers that describe what a bad day looks like.
A good answer: automated backups at a stated frequency, stored in a separate region, restore-tested on a schedule, with RPO and RTO figures written into the SLA. Ask when they last ran a restore test and what they learned.
10. Can we see the sub-processor list and sign a DPA?
Why it matters: every cloud host, SMS gateway, mapping provider, email service and model provider that touches your data is a sub-processor. Under GDPR and similar regimes you are responsible for them, so you need to know who they are.
A good answer: a published, dated sub-processor list with locations and purposes, a commitment to notify you before adding one, and a standard data processing agreement the vendor will sign without a fight.
11. What is your incident-response process and how will you notify us?
Why it matters: breaches happen to good vendors. What distinguishes them is whether you hear about it from them within the window your own regulators require, with enough detail to act.
A good answer: a documented process with named roles, a notification commitment in hours (not "without undue delay"), a named contact on both sides, and a post-incident report. Ask whether they have exercised the plan.
12. What happens to our data when we offboard or a user leaves?
Why it matters: at the user level, ex-employees with live logins are one of the most common breach paths in operations. At the contract level, your customer data should not outlive the relationship.
A good answer: user deactivation takes effect immediately across console and driver app, with remote device sign-out. On termination, data is exported in a usable format on request and deleted from production and backups within a stated period, with written confirmation.
Scoring table: compare vendors on the same 12 questions
Score each answer 0, 1 or 2, multiply by the weight, and total. The maximum is 60. Treat any 0 on a Critical question as a blocker regardless of the total; a platform with no enforceable MFA or no incident-notification commitment does not get better because it has excellent backups.
| # | Question | Weight | Full marks (2) looks like |
|---|---|---|---|
| 1 | MFA and SSO | Critical (x3) | Enforceable MFA per tenant or role; SSO available |
| 2 | Role-based access | Critical (x3) | Roles plus hub/zone/Shipper scoping; sensitive actions restricted |
| 3 | Audit logs | High (x2) | Full event coverage, stated retention, exportable |
| 4 | Data residency | High (x2) | Named regions, customer choice, documented data flows |
| 5 | Encryption | High (x2) | TLS everywhere, encrypted at rest incl. backups, key management stated |
| 6 | AI prompt handling | High (x2) | Named providers, no training on your data, bring-your-own-LLM option |
| 7 | API keys and webhook secrets | Critical (x3) | Scoped, rotatable, hashed, logged; signed webhooks |
| 8 | Driver app device security | High (x2) | Encrypted cache, device-bound sessions, remote sign-out |
| 9 | Backups, RPO and RTO | High (x2) | Figures in the SLA; restore-tested; separate region |
| 10 | Sub-processors and DPA | High (x2) | Published list, change notification, standard DPA |
| 11 | Incident response | Critical (x3) | Documented process, notification in hours, named contacts |
| 12 | Offboarding and deletion | High (x2) | Immediate deactivation; deletion from prod and backups with confirmation |
- 48 to 60: strong. Proceed and write the answers into the contract security schedule.
- 36 to 47: workable. Negotiate dated commitments on every question scored 1.
- Below 36, or any Critical question at 0: do not sign until it is fixed.
What to do with the answers
The scoring is only useful if the answers become obligations. Attach the vendor's written responses to the contract as a security schedule, with dates for anything promised on a roadmap. Set a 12-month review so the questionnaire is re-issued as the platform and your operation change. And run the same 12 questions against your own internal practices: a vendor with enforceable MFA does not help if your hub still shares one login.
"We sent the twelve questions to four vendors. Two answered in a day with documents attached. One took three weeks and answered in adjectives. That told us more than any demo did."
— IT lead, multi-city pharmacy delivery operator
Ask about the roadmap, not just the present
A vendor that cannot yet offer SSO but can show you a dated plan and a named engineer is a better bet than one that says "soon". Write the date into the contract.
Related reading
Frequently asked questions
What should a delivery software security checklist include?
At minimum: MFA and SSO, role-based access, audit logging, data residency, encryption in transit and at rest, how AI prompts are handled, API key and webhook secret management, driver app device security, backup and recovery objectives, sub-processors and a DPA, incident response, and offboarding and data deletion.
Is a SOC 2 report enough to approve a logistics vendor?
It is useful evidence that controls exist and are audited, but it does not tell you which controls apply to your data or how the driver app behaves on a lost phone. Use it alongside specific written answers to the questions above, not instead of them.
Why does it matter which AI provider a delivery platform uses?
Dispatch copilots send order details, addresses and customer messages to a language model. If the vendor picks the provider, your data sits with a sub-processor you did not choose. Platforms that let you bring your own model provider and API key keep prompts under your own account and data agreement.
How do you score a vendor security questionnaire?
Score each answer 0 (missing), 1 (partial) or 2 (specific and documented), multiply by a weight that reflects how critical the control is, and total. Treat a zero on any critical question such as MFA, API key handling or incident response as a blocker regardless of the total score.
What are the most common gaps in delivery software security?
Shared logins with no MFA, over-broad roles, API keys that are never rotated, driver apps that cache customer data unencrypted, no written incident-notification commitment, and ex-employee accounts left active. Most are process gaps rather than technology gaps.
Should we ask these questions of the software we already use?
Yes. Running the checklist against your current platform and your own internal practices usually surfaces one or two fixes you can make this week, such as enforcing MFA for admins or rotating a webhook secret that has not changed since go-live.
