Choosing a TMS Vendor Under NIS2: 6 Checks That Matter

If you run TMS procurement for a shipper, carrier, port operator or freight forwarder in the EU, the decision in front of you isn't "is my organisation in scope for NIS2." It's narrower and more useful: which six checks do you actually run on a shortlisted TMS vendor before you sign, so that when (not if) something goes wrong, your contract and your vendor's posture hold up. This is a TMS vendor NIS2 compliance question, not a legal memo question, and procurement teams keep conflating the two. Small logistics companies that act as subcontractors or technology suppliers to larger covered entities will face indirect pressure to improve their cybersecurity posture through supply chain requirements imposed by their clients. So this applies whether you're a designated essential entity yourself or just a mid-market shipper whose biggest customer is one.

Why this matters on your 2026 buying timeline

The first compliance audit deadline was extended from December 31, 2025, to June 30, 2026 across several Member States, giving organisations additional preparation time. That extension is running out. If you're mid-way through a TMS RFP right now, your vendor security questionnaire is effectively feeding straight into that audit file, whether your procurement team has framed it that way or not.

The harder operational problem for multi-country shippers is fragmentation. Multi-country organisations need a country-by-country view of scope, registration, incident reporting channels, supervisory authority, and sector-specific guidance. A TMS vendor that hosts your German operation's data in Frankfurt and your Polish operation's data on a shared instance in Dublin isn't automatically non-compliant, but it does mean your incident reporting obligations may route through two different national CSIRTs on two different clocks. Ask the vendor to show you, not tell you, which authority they'd notify first.

Six checks that matter, in order

1. Incident reporting capability and contractual notification clock

This is the one that gets you fined, not the vendor's downtime. Your obligation to your own regulator runs on a fixed clock, and if your TMS provider's breach-notification clause to you takes five business days, you've already blown your own reporting window before you even know what happened. Ask for the exact number of hours between "vendor detects incident" and "vendor notifies you," in writing, in the contract, not in a sales conversation. Cross-check it against your own national reporting deadline before you sign anything.

2. Sub-processor and component transparency

NIS2 pushes this from best practice to expectation. Maintaining a detailed list of software components used (and their suppliers) allows organizations to always know what is inside their software and react quickly to new vulnerabilities. Practically: ask the vendor for their current sub-processor list as a standalone document, updated on a schedule, not buried in a 40-page DPA appendix that changes without notice. If they can't produce one on request within a week, that's your answer about how mature their internal tracking actually is. Subcontracting rules should ensure that sub-suppliers adhere to the same security standards as the primary supplier, so check whether that obligation flows down contractually or is just assumed.

3. Hosting jurisdiction and data residency

Where the platform actually runs matters more than where the vendor is headquartered. A vendor selling into the EU from a US-based cloud region introduces a data residency question your legal team will eventually ask anyway. Get the specific region names (not "EU-based," get "eu-west-1, Frankfurt") in writing, and ask whether failover or backup regions sit outside the EU. Many vendors don't volunteer the failover answer unless you ask directly.

4. Certification scope, not the badge

An ISO 27001 certificate tells you almost nothing on its own. What matters is the audit boundary: does it cover the specific product modules and data centres your shipment data will actually touch, or just the vendor's corporate HQ network? Ask for the Statement of Applicability and the certificate scope statement, not the marketing page logo. This single request filters out more vendors than any other question on this list, because a lot of them haven't looked at their own scope statement in years.

5. Published uptime SLA with real financial remediation

Uptime still belongs on the checklist, just lower than most RFPs place it. What matters is whether the penalty for missing the SLA is a service credit worth anything, or a rounding error against your annual contract value. Ask for the actual remediation formula, run the numbers against a realistic outage scenario, and compare that figure to what a multi-hour TMS outage actually costs your operation in rebooking and manual dispatch.

6. Vendor financial stability as a security-investment proxy

A vendor that's cash-constrained tends to defer security spend before it defers feature development, because security work is invisible to prospects until something breaks. This one is the hardest to verify from an RFP answer alone. For private vendors, ask about headcount growth in security/compliance roles over the last two years rather than asking for financials they won't share.

What procurement teams overweight, and why

Headline uptime percentages get overweighted because they're the easiest number to put in a comparison spreadsheet: 99.9% looks better than 99.5%, done, next row. But NIS2 penalises reporting failures and containment speed, not raw downtime minutes, so a vendor with a slightly lower advertised uptime and a genuinely fast, contractually enforceable breach notification clause is the safer buy, not the riskier one.

The ISO 27001 logo suffers the same problem. It's a binary yes/no that's easy to score in an RFP matrix, so it gets full marks whether the certificate covers the vendor's entire product suite or just their invoicing system. Almost nobody on the buying side asks to see the scope statement, which is exactly why it's worth the extra ten minutes.

Net Promoter Score and generic customer satisfaction ratings, the kind that dominate "best TMS" listicles, are close to irrelevant here. A vendor's customers can love the user interface and still have no idea what the vendor's sub-processor chain looks like. Don't let a high satisfaction score on a comparison site substitute for the six checks above.

Matching the checks to your shipper profile

Not every buyer needs the same depth of scrutiny. The table below maps profile to what to prioritise and a realistic shortlist, drawn from vendors tracked on independent comparison sites such as RFP.wiki's 2026 TMS vendor list.

Cargoson shows up across all three rows because it's positioned as an EU-native, connectivity-first platform rather than a single enterprise suite, which changes the shape of the security conversation: fewer legacy modules to scope-check, but you still need the sub-processor list for every carrier integration it brokers on your behalf. Worth a look if speed of documentation matters more than depth of enterprise feature set: cargoson.com.

What to actually put in the RFP and the contract

Turn the six checks into contract language rather than RFP small talk. At minimum, request:

• A named incident notification deadline to you, in hours, not "promptly" or "without undue delay"
• A standing sub-processor list, delivered in writing, with a commitment to notify you before adding a new one
• Named hosting regions for primary and failover environments, not a generic "EU" claim
• The certificate scope statement or Statement of Applicability for any ISO 27001 or SOC 2 claim, attached as an exhibit
• The actual SLA remediation formula, expressed in currency terms against your contract value, not just a percentage target

Score these five items as a weighted block worth at least as much as functional fit in your evaluation matrix. If your current scorecard gives uptime percentage more weight than incident notification speed, that's the one line item worth changing before your next vendor round goes out.

The decision, restated

Pick the TMS vendor whose contract you can actually enforce at 2am during an incident, not the one whose sales deck has the highest advertised uptime number. Run the sub-processor list request and the certificate scope check before you shortlist, not after you've already fallen in love with the demo. Those two habits alone will filter out most of the vendors who'd otherwise leave you explaining a missed reporting deadline to your national regulator.