11 Questions Every Freight Forwarder Should Ask Their ERP Vendor About Security

Security Isn't a Feature. It's the Foundation of Your Freight ERP.

Today's freight forwarding ERP suite is far more than an operational system. It stores critical and confidential data, including customs declarations, commercial invoices, banking information, customer records, shipment documentation, and the credentials of employees, agents, and partners across your global network.

At the same time, these platforms are more integrated than traditional systems ever were. Customer portals, EDI integrations, APIs, mobile applications, and third-party services have significantly expanded the attack surface.

Despite this, security is still treated as an afterthought during ERP evaluations. Most buying decisions focus on features, automation, ease of use, and pricing, while security becomes a checklist item discussed only after the product demo.

That approach is becoming increasingly risky.

Every software platform will eventually encounter vulnerabilities and shortcomings. What separates a mature ERP vendor is not whether vulnerabilities exist, but how securely the platform is architected, how vulnerabilities are disclosed, how quickly they are resolved, and how transparently the vendor communicates throughout the process.

If you're evaluating a freight forwarding ERP, these are the ten questions every vendor should be able to answer with confidence.

Here are ten questions every freight forwarder, customs broker, and logistics service provider should ask any freight forwarding ERP vendor, whether current or prospective, before trusting them with operational and customer data.

1.  How is sensitive data encrypted, and are encryption keys unique per customer?

Encryption alone doesn't guarantee security. The real question is how cryptographic keys are managed. Keys should be generated uniquely for each customer environment, never hardcoded into the application. A shared key creates a single point of failure where one breach has the potential to impact every deployment.

2. How are customer-facing portals (tracking, booking, document access) secured separately from the core system?

Many forwarders don’t realize that the portal their customers use to track a shipment, book cargo, or access documents often runs on a different codebase, with different authentication logic, than the core ERP. Ask how that portal is hardened, tested, and isolated, and whether a compromise of the portal could ever be used to reach anything beyond it.

Push further on three things. First, the codebase: Is the portal engineered as part of the same platform, or is it bolted on with its own separate security model that must be maintained? Second, role-based access control: Can you define exactly what each customer login is allowed to see and do, ensuring that one customer can never view another's shipments, rates, or invoices? Third, the audit trail should include versioning. Does the system log every portal action, including who viewed a document, who uploaded or approved it, who created a booking, and when, so that any access can be reconstructed after the fact?

3.  What does your vulnerability disclosure and patching process actually look like?

Every serious freight forwarding vendor will have vulnerabilities found in their products over time, whether by internal QA, by customers, or by external security researchers. What separates a mature vendor isn’t a perfect record; it’s a fast, transparent, well-practiced response. Ask: what is your average time from disclosure to patch? Do you proactively notify affected forwarders? Is there a public security contact or a bug-bounty program?

Then ask which secure-coding standards they actually build and test against. The current industry baseline is the OWASP Top 10:2025, the latest edition of the most widely recognized list of critical web application risks, now led by broken access control, alongside the OWASP Application Security Verification Standard (ASVS) for verifiable testing. A vendor that can name the standards it codes to, and show how it tests against them, is treating security as engineering, not marketing.

4.  Are you independently audited or certified (SOC 2, ISO 27001), and can we see evidence?

Self-reported security claims are easy for any software vendor to make. Third-party attestations are not. Ask for current SOC 2 Type II reports, ISO/IEC 27001:2022 certification, or equivalent independent audit evidence, and check the dates. A certification from three years ago with no recent renewal tells its own story.

5.  How is authentication handled for “passwordless” or email-link login features?

Many shipment tracking and notification emails sent by freight platforms include a one-click login link so customers don’t have to remember a password. Convenient, but only as secure as the token behind that link. Ask how those tokens are generated, how long they remain valid, whether they can be reused, and whether they grant access to anything beyond the specific shipment referenced.

Then ask what protects the login itself. Multi-factor authentication (MFA) for users handling sensitive operations, CAPTCHA or equivalent bot protection to blunt automated credential attacks, and an enforced password policy covering complexity, rotation, and lockout after repeated failed attempts are the difference between a convenient login and an exposed one.

6.  Is the platform built as one integrated system, or assembled from multiple acquired or legacy codebases?

This is an architecture question with real security implications. Systems that grew through years of acquisitions or bolt-on modules often have inconsistent security models between components: what is secure in the core ERP isn’t necessarily secure in the bolted-on visibility tool or the older integration layer. Ask vendors directly whether the platform you are evaluating was engineered as one system or stitched together from several. One coherent platform, with the same encryption, authentication, and access rules across operations, finance, the customer portal, and integrations, is structurally easier to secure than a decade of assembled parts.

7.  What is your incident response plan, and have you ever had to use it?

A vendor that says “we’ve never had an incident” isn’t necessarily reassuring; it may just mean they haven’t been tested, or haven’t disclosed. A more useful answer describes a real, rehearsed process: detection, customer-notification timelines, root-cause analysis, and remediation. Ask whether they run tabletop exercises or simulated attacks internally.

A mature vendor won’t be improvising this. Under ISO/IEC 27001:2022, incident management planning and preparation is a required, documented control. Controls A.5.24 through A.5.27 cover planning, assessment, response, and learning from incidents, written into the information security policy rather than left to goodwill. Ask to see that it exists on paper before an incident, not after.

8.  How do you isolate customer data in a multi-tenant cloud environment?

If the platform is cloud-hosted and multi-tenant, your data technically shares infrastructure with other forwarders’ data. Ask how that isolation is enforced, logically, at the database level, and at the network level, and what would have to fail for one customer’s data to become visible to another.

9.  Who can access our data internally, and how is that access logged and controlled?

External attackers aren’t the only risk. Ask how the vendor controls and audits its own employees’ access to customer data, whether that access is logged, and whether you would be notified if an internal access policy were ever violated. Ask specifically about time-based access: is internal access granted only for the window it is actually needed and then automatically expires, rather than left standing open indefinitely? Standing, permanent access is a far larger attack surface than access scoped to a task and a timeframe.

10.  What security responsibilities are ours, what are yours, and is that written down?

Security is shared between vendor and forwarder: the vendor secures the platform, but you are responsible for things like user provisioning, password policy, and who in your organization gets access to what. Ask for that split in writing. A vendor that can’t clearly state where its responsibility ends and yours begins, probably hasn’t thought it through.

Two vendor-side practices are worth asking about by name. Background verification (BGV) of the employees who can touch customer data, so trust in your data is backed by vetted people rather than assumed. And a documented data-classification scheme, so that every category of information, from a public tracking milestone to a confidential commercial invoice, has a defined handling rule. When data is classified, “who can see what” stops being a judgment call.

11. What is your disaster recovery strategy, and has it been tested?

A disaster recovery plan is only valuable if it works when needed. Ask how the vendor ensures your operations stay online during outages or cyber incidents.

Key questions to ask:

• Is the disaster recovery plan regularly tested through failover drills?

• What are the guaranteed RTO (Recovery Time Objective) and RPO (Recovery Point Objective)?

• Does the platform support automatic failover across multiple regions or data centers?

• Are backups encrypted, immutable, and tested for successful restoration?

• Can critical freight operations continue during a disruption?

• How and when will customers be notified during an incident?

Why This Belongs in Every Freight Forwarder’s RFP

None of these questions assumes bad faith on any vendor’s part, including ours. They are simply the questions that separate vendors who treat security as a marketing line from those who treat it as an engineering discipline. A platform built as one coherent system, with consistent authentication, encryption, and access practices across every module, from the core ERP to the customer portal, mobile access, and integrations, is structurally easier to secure than one assembled from a decade of bolted-on parts.