TMS security usually becomes a procurement priority after someone asks a simple question: what happens if the system holding our loads, customer records, carrier information, documents, rates, and invoices becomes unavailable or compromised?
On this page
By that point, the TMS may already be deeply embedded in operations.
Dispatch depends on it. Customer service needs shipment status. Drivers or carriers may submit events through it. Finance relies on delivery documents and charges. Integrations continuously exchange data with accounting, visibility, telematics, load boards, and customer systems.
Therefore, security and uptime should be tested before the contract reaches final approval.
The process does not require your transportation team to become cybersecurity auditors. Instead, buyers need to know what evidence to request, which questions expose risk, and which promises belong in the contract rather than the sales presentation.
NIST’s newly finalized 2026 supplier due-diligence guidance makes the same broader point: organizations acquiring technology should investigate supplier risk before making the acquisition decision. Its framework includes resilience and foundational cybersecurity practices among the areas buyers should assess. Read NIST SP 1326 supplier due-diligence guidance
Why TMS Security Deserves Transportation-Specific Due Diligence
A TMS has an unusually broad operational footprint.
It can contain customer locations, carrier information, shipment histories, negotiated rates, delivery documents, invoices, driver activity, contact information, and integration credentials.
Moreover, transportation software often extends beyond employees.
Customer portals create external access. Driver applications collect field data. Carrier onboarding introduces documents and third-party users. APIs and EDI connections exchange records with systems outside the TMS.
That means the effective security boundary is larger than the application login page.
Start with the blast radius
Ask what operations lose if access disappears for four hours.
If the TMS is unavailable for four hours, can dispatch still identify active loads, drivers continue submitting PODs, customers receive updates, and finance retrieve delivered shipment documents? Will integration transactions queue and recover, or disappear?
Next, ask the security version of the same question:
If one account is compromised, what can that account actually see, change, download, or export?
Those two questions quickly expose whether the vendor has designed around operational resilience and controlled access.
TMS Security Starts With the Architecture
Before asking about individual controls, understand where the software actually runs.
Request a current architecture and data-flow diagram.
It should make clear:
- Where application data is stored
- Which infrastructure or cloud platform hosts it
- Whether customers share infrastructure
- How users authenticate
- Which systems receive data
- Where documents are stored
- Which third parties process data
- How portals and mobile applications connect
- Where API credentials are held
- Which components the TMS vendor controls directly
Architecture matters because every additional data copy, middleware service, connector, portal, and credential creates another component that must be secured and monitored.
For companies already evaluating platforms, this belongs alongside the broader questions in FTM’s guide to choosing a TMS and the practical testing process in How Shippers Should Prepare for a TMS Demo.
What TMS Security Evidence Should You Request?
A questionnaire is useful. Evidence is better.
Independent assurance
Ask whether the vendor can provide current independent assurance such as a SOC 2 Type II report, relevant ISO certification, or another framework appropriate to your organization.
Then review the scope.
A certificate belonging to the vendor’s hosting provider does not necessarily cover the vendor’s own application, engineering processes, or support controls.
Likewise, a report from several years ago says less about the environment you are buying today.
Therefore, ask:
- What systems are covered?
- What period was examined?
- Were material exceptions found?
- Have important systems changed since the assessment?
- Can the vendor provide a bridge letter when needed?
The goal is to understand the evidence, not collect compliance logos.
Vulnerability and security testing
Ask how the application is tested for vulnerabilities.
Depending on your risk requirements, evidence may include penetration-testing summaries, vulnerability-management practices, secure development procedures, and remediation policies.
Also ask how customers report suspected security issues and how the vendor handles critical vulnerabilities discovered after deployment.
Identity and Permissions Need a Live Test
Role-based access sounds reassuring until every employee receives nearly identical privileges.
During the demo or proof of concept, create more than one user type.
For example, test:
- Dispatcher
- Operations manager
- Finance user
- Customer portal user
- Carrier or driver user
- System administrator
Then attempt actions those users should not be able to perform.
A customer should not see another customer’s shipment. A dispatcher may not need access to every financial field. A driver should not gain broader operational access merely because the account can update a load.
In addition, ask about:
- SSO
- MFA
- User provisioning and deprovisioning
- Role and permission administration
- Field-level access
- Session controls
- API authentication
- Audit logs
- Privileged administrator activity
For external-facing workflows, examine access particularly carefully. FTM’s Customer Portal, for example, is designed around Salesforce permission controls so customer access can be scoped to relevant shipment, document, and invoice information.
Integrations Are Part of TMS Security
A secure core application can still participate in an insecure workflow.
Transportation systems frequently connect to accounting platforms, load boards, carrier-compliance services, tracking providers, ERP systems, telematics platforms, mapping services, and customer applications.
Consequently, each critical integration should have an owner and an authentication model.
Ask:
- Does it use OAuth, API keys, certificates, or shared credentials?
- Where are secrets stored?
- Who can rotate them?
- What permissions does the integration receive?
- Are transactions logged?
- What happens after repeated authentication failures?
- Can an integration account access more data than it actually needs?
FTM currently documents integrations across transportation, financial, visibility, compliance, routing, and business systems on its integrations hub. Regardless of vendor, the important security exercise is to evaluate the connections your own implementation will actually use.
TMS Uptime Is More Than One Percentage
A salesperson saying “we have 99.9% uptime” should begin the discussion, not end it.
First, determine whether that figure represents a contractual SLA, an internal target, or historical performance.
Then ask how availability is calculated.
Read the exclusions
An SLA can exclude:
- Planned maintenance
- Customer-caused incidents
- Third-party failures
- Internet or telecom failures
- Force majeure events
- Certain integrations
- Beta functionality
- Specific service components
Therefore, two vendors advertising the same percentage can provide materially different protection.
Understand how much downtime the number permits
Over a 365-day year, approximately:
- 99.9% availability: 8 hours 46 minutes of downtime
- 99.95% availability: 4 hours 23 minutes
- 99.99% availability: 53 minutes
Those figures are mathematical availability equivalents, not guarantees that outages will be distributed evenly.
One four-hour disruption during a major shipping window can matter far more than several brief incidents overnight.
Historical Uptime Is More Useful Than a Marketing Number
Ask for at least 12 months of service history when possible.
Review:
- Service disruptions
- Degraded-performance incidents
- Planned maintenance
- Incident duration
- Affected functionality
- Communication timing
- Recurring failure patterns
Most importantly, determine whether customers can inspect this history without opening a support ticket.
Salesforce, for example, operates a public Trust service that publishes current and historical availability, performance information, incidents, and scheduled maintenance by service and instance. View Salesforce Trust status and availability
Transparency itself is useful evidence.
A status page does not prove that outages will never happen. However, it allows customers to verify what happened rather than depending entirely on a vendor’s retrospective explanation.
Recovery Matters When TMS Uptime Fails
Every serious availability discussion should eventually reach recovery.
Ask for the vendor’s:
RTO: Recovery Time Objective
How quickly does the organization target restoring the service after a major failure?
RPO: Recovery Point Objective
How much data loss is considered acceptable when restoring from a recovery point?
These answers matter differently in transportation.
Losing several hours of brochure-site data may be inconvenient. Losing several hours of dispatch updates, POD activity, carrier assignments, or financial changes can create a reconciliation project.
Therefore, ask how backups are created, protected, tested, and restored.
Also determine whether disaster-recovery exercises are actually performed. A backup that has never been tested for restoration provides weaker evidence than a documented recovery process.
Do Not Ignore Incident Response
An outage and a security incident are different problems, although they can occur together.
Ask the vendor what happens after a suspected breach.
The process should identify:
- Who investigates
- How customers are notified
- What communication channel is used
- When legal or security contacts become involved
- How affected data is identified
- How evidence is preserved
- How remediation is communicated
In addition, put notification obligations that matter to your organization into the contract or associated security terms.
“Support will contact you” is not a sufficient incident-response plan for an enterprise transportation system.
TMS Security and Uptime Due-Diligence Scorecard
| Area | Ask the Vendor | Evidence to Request | Investigate Further If… |
|---|---|---|---|
| Architecture | Where does our data live and which systems process it? | Architecture and data-flow diagram | Data movement or system ownership cannot be explained clearly. |
| Access | How are employees, customers, carriers, and administrators isolated? | Live role and permission demonstration | Testing is performed only with an administrator account. |
| Security assurance | Which independent assessments apply to the service? | Current reports or certifications and their scope | The evidence covers only a hosting provider or an outdated environment. |
| Vulnerabilities | How are security weaknesses found and remediated? | Testing process, remediation policy, relevant assessment summary | No clear owner, testing cadence, or remediation process exists. |
| Availability | What uptime is contractually committed? | SLA plus historical availability | The only evidence is a marketing percentage. |
| Recovery | What are the RTO and RPO? | Business continuity and recovery documentation | Backups exist but restoration has not been tested. |
| Integrations | How are credentials and external connections secured? | Authentication model and permission scope | Shared passwords or unnecessarily broad access are required. |
| Incidents | How and when will customers be notified? | Incident-response and contractual notification process | Escalation responsibilities are unclear. |
One important rule applies across the scorecard:
An answer supported by evidence should score higher than the same answer given verbally.
Look Beyond the Core TMS Vendor
Modern SaaS availability is a dependency chain.
Your operational workflow might depend on:
TMS → cloud platform → identity provider → tracking provider → mapping API → accounting platform
If the tracking provider fails, the TMS may technically remain online while shipment visibility stops updating.
Similarly, a broken integration can make customer data appear stale even though both applications report 100% availability.
Therefore, map critical dependencies and ask how the vendor distinguishes application incidents from provider incidents.
This is particularly important for an integration-heavy transportation environment.
What Changes With a Salesforce-Native TMS?
A platform-native application changes some of the due-diligence questions, but it does not eliminate them.
FTM runs inside Salesforce rather than maintaining a separate TMS application database synchronized to Salesforce. Its current platform materials describe transportation records using the Salesforce data model, identity, roles, permissions, and field-level controls. See the FTM Salesforce-native platform architecture
That architecture can remove a separate synchronization and identity layer between CRM and TMS.
However, buyers should still evaluate the specific implementation.
Customer configuration, integrations, portals, user permissions, retention requirements, external providers, and business continuity still require review.
In fact, FTM’s own technical reference explicitly notes that security, compliance, data residency, retention, and regulatory requirements should be validated for each Salesforce environment, selected integrations, and implementation scope.
That is the right mindset for any vendor assessment.
TMS Vendor Red Flags to Investigate
One weak answer should trigger another question rather than an immediate rejection.
Still, several patterns deserve attention.
“Our cloud provider handles security”
Hosting infrastructure is only one layer.
Ask what the application vendor handles itself.
“We’ve never had downtime”
Request the historical status data.
An organization with meaningful operating history should be able to explain how it measures incidents.
“Everyone uses role-based access”
Ask the vendor to demonstrate it.
Configuration matters more than terminology.
“We have SOC 2”
Request the appropriate report under NDA and verify scope, period, and exceptions.
“Backups run every day”
Ask when restoration was last tested.
“That integration is secure”
Ask how it authenticates, what permissions it has, where credentials live, and how access is revoked.
Good due diligence replaces reassuring adjectives with observable controls.
What Should Be in the Contract?
By the final negotiation stage, security and availability requirements should stop being sales questions.
Document the important commitments.
Depending on your organization, these may include:
- Availability target
- SLA measurement methodology
- Planned-maintenance treatment
- Service-credit process
- Security incident notification
- Data ownership
- Data return or deletion at termination
- Backup and recovery responsibilities
- Support escalation
- Subprocessor obligations
- Security documentation access
Meanwhile, keep operational requirements separate from legal boilerplate.
If dispatch requires an urgent escalation path during an outage, identify the actual support process your team will use at 2:00 a.m.
Final TMS Security Checklist Before Signing
Security
Confirm the architecture, hosting model, authentication controls, permissions, auditability, encryption approach, vulnerability management, independent assurance, integrations, and incident-response process.
Resilience
Review historical availability, contractual uptime, maintenance exclusions, backup strategy, RTO, RPO, disaster recovery, and critical third-party dependencies.
Data governance
Confirm who owns the data, where it resides, how long it is retained, how it can be exported, and what happens after termination.
Operational proof
Finally, test the system.
Create users with different permissions. Disable a user. Inspect audit history. Trigger an integration error. Ask how failed transactions recover. Review the status page and incident history.
A security questionnaire can tell you what the vendor says.
A controlled test shows you how the system behaves.
The Best TMS Security Review Connects IT Risk to Freight Operations
TMS security is not simply an IT checkbox.
A failure can affect carrier assignments, customer communication, shipment visibility, documents, billing, reporting, and the people trying to move freight while the system is unavailable.
Therefore, the strongest vendor evaluation connects each technical question to an operational consequence.
Ask what happens when authentication fails during dispatch. Determine how loads are recovered after an outage. Test whether customer permissions actually isolate records. Verify how an integration failure becomes visible to the team responsible for fixing it.
For organizations evaluating FTM, the FTM transportation platform and integration architecture provide useful starting points for that discussion.
Security claims matter.
Verifiable architecture, controls, resilience, and contract language matter more.
Frequently Asked Questions
Make Security Part of the TMS Demo
Bring your IT, security, integration, and operational requirements. FTM can walk through its Salesforce-native architecture, permissions, data model, integrations, and transportation workflows against your actual environment.
Book an Architecture Review