11 Security Questions Freight Forwarders Should Ask ERP Vendors

A freight ERP holds information that can expose both customer relationships and daily operations: customs declarations, invoices, banking details, shipment records and credentials used across a global network. Its connections to customer portals, EDI, APIs, mobile apps and outside services widen the number of routes into that data. Security therefore belongs in vendor selection alongside functionality, automation, usability and price.

No platform can promise that vulnerabilities will never emerge. A more useful measure is how its architecture limits exposure, how the vendor finds and reports weaknesses, and how quickly it responds. Freight forwarders, customs brokers and logistics providers can use these 11 questions to make those practices concrete during an ERP evaluation.

Data protection and customer access

1. How do you encrypt sensitive data, and are keys unique to each customer?

Ask where encryption applies and how the keys are managed. Keys should be generated for each customer environment rather than embedded in application code. If customers share a key, a single compromise could put multiple deployments at risk. The vendor should be able to explain how keys are stored, protected and handled through their lifecycle.

2. How is the customer portal separated from the core ERP?

Shipment tracking, booking and document access may run through a portal with its own code and authentication. Ask how that interface is secured, tested and isolated from the main system, and what limits a breach of the portal from reaching other functions.

Check whether the portal is part of the same engineered platform or a separate component with its own security model. Customer permissions should restrict each login to the right shipments, rates, invoices and actions. Logs should record who viewed or uploaded a document, approved it or created a booking, and when. A useful audit trail lets the forwarder reconstruct access after an issue.

3. How do you disclose vulnerabilities and deliver patches?

Weaknesses may be found by the vendor, customers or external researchers. Ask for the vendor’s typical time from disclosure to a fix, how it alerts affected customers and whether it provides a security contact or runs a bug bounty program. A clear process says more about readiness than a claim that no vulnerability has ever been found.

Ask which secure development standards guide the work and how the vendor verifies them. The source identifies the OWASP Top 10:2025 and OWASP Application Security Verification Standard (ASVS) as reference points. A vendor should be able to describe how its development and testing practices address these standards, including risks such as broken access control.

4. Can you provide current independent audit or certification evidence?

Request recent SOC 2 Type II reports, ISO/IEC 27001:2022 certification or comparable independent evidence, and check the dates and scope. A certificate or report only helps buyers assess current practices if it covers the relevant service and has been kept up to date. Ask how often assessments occur and what evidence the vendor can share during procurement.

5. How are passwordless links and other login methods protected?

One-click links in shipment notifications can make access easier, but their safety depends on the token. Ask how tokens are generated, how long they work, whether they can be reused and whether they expose anything beyond the shipment named in the message.

Also ask about multi-factor authentication for sensitive tasks, bot protection such as CAPTCHA, and password rules covering strength, rotation and lockout after repeated failed attempts. These details show whether convenient access has limits that match the sensitivity of the information.

Architecture, response and internal controls

6. Is the platform one integrated system or a collection of older components?

Products expanded through acquisitions or add-on modules can have inconsistent controls. Authentication or access rules in the core ERP may not match those in a visibility tool or an older integration layer. Ask how the platform was assembled and whether encryption, authentication and permissions work consistently across operations, finance, portals and integrations. A coherent design is easier to assess than a collection of components with different security models.

7. What happens when an incident occurs, and have you rehearsed the response?

Ask the vendor to explain how it detects an incident, notifies customers, investigates the cause and fixes the problem. Find out whether staff run tabletop exercises or simulated attacks. A response plan should be documented and practiced before it is needed.

The source points to ISO/IEC 27001:2022 controls A.5.24 through A.5.27, which address preparation, assessment, response and learning. Ask to see the vendor’s written process and understand the customer-notification timelines it follows.

8. How is customer data separated in a shared cloud environment?

When multiple customers use the same cloud infrastructure, ask how their data is isolated at the database and network levels. The vendor should explain which controls prevent one customer from accessing another’s records and what failures could undermine that separation. Ask how those controls are tested and monitored.

9. Which vendor employees can access our data, and how is their access controlled?

Ask how employee access is approved, recorded and reviewed, and whether customers are notified when an internal access rule is violated. Access should be limited to the task and time required, then expire automatically where possible. Permanent access creates more exposure than permissions granted for a defined need.

10. Which security duties belong to us, and which belong to the vendor?

The vendor operates and protects the platform; the forwarder manages matters such as user provisioning and internal permissions. Ask for the division of duties in writing so neither side relies on an assumption about who handles an account, configuration or response.

Ask whether the vendor verifies employees who can reach customer information and maintains a data-classification scheme. Classification should set handling expectations for different records, from public tracking milestones to confidential commercial invoices. That gives both parties a clearer basis for deciding who may see each type of information.

Keeping freight operations available

11. How do you restore service and data, and how often do you test?

A recovery plan matters only if the vendor can demonstrate that it works. Ask whether it runs failover drills, what recovery time objective (RTO) and recovery point objective (RPO) it guarantees, and whether the platform can switch automatically between regions or data centers. Find out whether backups are encrypted, immutable and tested through restoration exercises.

Also ask which freight activities can continue during an outage and how customers will be informed as an incident unfolds. These answers connect technical recovery measures to the forwarder’s practical need to keep shipments, documents and customer communication moving.

Put these questions in the request for proposal and ask vendors to support their answers with current documentation. The comparison should cover the complete service, including portals, mobile access and integrations, as well as the core ERP. A vendor that can explain its controls, boundaries and response process gives freight teams a clearer basis for judging how the system will handle sensitive data and operational disruption.