Why Does a Logistics Company Need Its Own SOC?
A Security Operations Center (SOC) is a team and technology responsible for continuous monitoring, detection, and response to cybersecurity threats. For logistics companies, SOC is particularly essential because:
24/7 operations — logistics never sleeps, and neither do attacks. Night transport, shift warehouses, drivers on the road — an incident at 3 AM requires immediate response.
Distributed infrastructure — warehouses at various locations, vehicles on the road, remote workers, partner integrations — centralized monitoring is the only way to manage this ecosystem.
NIS2 requirements — the NIS2 directive requires significant incidents to be reported in three steps: an early warning within 24 hours, an incident notification within 72 hours, and a final report no later than one month after the notification (Article 23(4)). The clock starts when you become aware of the incident — and awareness comes from detection.
Cascading incident impact — an attack on a TMS system paralyzes not just the company but the entire supply chain. Fast detection and response minimize the cascade effect.
Why Does a Template Monitoring Scope Fail in a Transport Business?
A monitoring scope copied from a generic template covers the corporate network and stops there, which in a transport business leaves out most of what an attacker would target. The systems that decide whether goods move are the transport and warehouse management platforms, the telematics feeding vehicle positions, the EDI links to customers and carriers, and increasingly the yard equipment that speaks industrial rather than office protocols.
Those sources are also harder to onboard: several are supplier-hosted, some emit no usable logs at all, and a few can only be observed from the network rather than from an agent. Establishing what can realistically be collected — and what compensating visibility to build where it cannot — is the practical first step, and it belongs to infrastructure monitoring rather than to the detection platform itself.
How Is Monitoring the Supply Chain Different From Monitoring the Supplier?
In that you do not monitor the supplier and you never will. You have no access to their network and no right to their logs, and their security team does not report to you. An offer promising “supply chain security monitoring” in the sense of watching someone else’s infrastructure describes something that cannot be bought — at most a risk score derived from external reputation data, which is not detection.
The monitoring a SOC actually performs means observing your own contact points with the supplier. Those are what comes in through the chain. If the supplier is compromised, the attacker does not materialize inside your network — they come in through a service account, an integration, an update package, or a remote support session. Each of those channels sits on your side, produces telemetry, and can be covered by detection without asking the supplier for permission.
This difference has a practical consequence. The question “is our TMS supplier secure” cannot be turned into a detection rule. The question “what is the TMS supplier’s service account doing in our Active Directory at two in the morning” can be — and the answer is an alert.
Which Logistics Systems Must a SOC See First?
The order follows what stops goods from moving — not what is easiest to onboard.
Layer 1: Critical systems (highest priority)
- TMS — logins, data changes, planning anomalies
- WMS — warehouse operations, inventory changes, admin access
- Telematics systems — GPS anomalies, unauthorized configuration changes
- Active Directory / IdP — logins, privilege escalation, new accounts
- VPN/ZTNA — remote connections, geographic anomalies
Layer 2: IT infrastructure
- Firewalls and WAF — blocked attacks, traffic anomalies
- Servers and workstations — EDR alerts, malware detection
- Email — phishing, malware in attachments
- DNS — queries to suspicious domains
Layer 3: Integrations and IoT
- EDI/API — communication anomalies with partners
- IoT devices — scanners, sensors, terminals
- Label printers, scales — devices often overlooked in security
Which Contact Points With a Supplier Must Be Monitored?
There are four classes, and each needs a different log source and a different rule. This is the operational expansion of what MITRE ATT&CK describes as the Supply Chain Compromise (T1195) technique with three sub-techniques: compromise of software dependencies and development tools (T1195.001), of the software supply chain (T1195.002), and of the hardware supply chain (T1195.003); technique version 1.7, last modified 24 October 2025, retrieved 2026-09-18.
1. Supplier service and technical accounts. The TMS integrator has an account in your directory that it uses to reach the application server; the warehouse system vendor has a second one for nightly jobs. Such accounts are often exempted from password expiry policies and from multi-factor authentication, because “otherwise the integration breaks”. Log: account authentications (successes and failures), source address, time of day, processes launched, group membership changes. Detect: use of the account outside the agreed maintenance window, authentication from an address outside the supplier’s range, the first interactive logon in the history of an account that has only ever run non-interactively.
2. Integrations and APIs. EDI with carriers, the freight exchange API, shipment status exchange with the customer, the TMS↔WMS bridge. Log: message volume and types per partner, source addresses of calls, response codes, response size. Detect: a new message type from a known partner, calls from outside the declared address range, a step change in data retrieval volume while order volume stays flat.
3. Software update channels. This is the vector MITRE emphasizes most for this technique, and it says so plainly: “adversaries looking to gain execution have often focused on malicious additions to legitimate software in software distribution or update channels” (MITRE ATT&CK, T1195). Log: where the update is pulled from, its signature and checksum, what the installer writes to disk, which child processes it spawns on first run. Detect: installation from a source other than the approved repository, a signature or hash mismatch, binaries written to unexpected paths, outbound traffic to a new destination immediately after first run.
4. Remote support access. Support sessions on the sorter controllers, on the weighbridge, on the EDI gateway. Log: who, when, to which asset, for how long — and whether the session was preceded by a service ticket. Detect: a session with no linked ticket, access to an asset outside the scope of the contract, a session running past the agreed time.
| Contact point | What the supplier sees | What you see | Signal for the SOC |
|---|---|---|---|
| Service account | their side of the connection | directory and server logs | use outside the maintenance window |
| Integration / API | the content of their own calls | the API gateway and application logs | a new call type or a new source |
| Update channel | their own release process | the download, the signature, the first run | signature mismatch, unexpected write path |
| Remote access | their own support session | the access gateway and session recording | a session with no service ticket |
The “what the supplier sees” column is there to show something uncomfortable: there is no field in which you both see the same thing. That is why the contract is part of the monitoring architecture rather than an accessory to it.
What Does Detecting an Entry Through a Trusted Integration Look Like?
The scenario is always similar, and it is worth walking through step by step, because it shows where detection actually gets a grip.
Step 1 — initial signal. At 02:14 the TMS integrator’s service account authenticates interactively on the application server. The “service account outside its window” rule raises a low-priority alert. On its own it means little: there could have been an outage.
Step 2 — enrichment. The analyst checks two things the rule does not know: whether an open service ticket exists for that night, and whether the source address belongs to the supplier’s range. No ticket and an address outside the range raise the priority.
Step 3 — correlation. The SOC queries the API gateway to see whether the same account made calls in that period. It did — and they were customer list retrievals, not the order operations this integration handles day to day. Order volume did not change. This is where the alert stops being a hypothesis.
Step 4 — response. Block the account, terminate the session, preserve gateway and directory logs, contact the supplier through a channel other than the one the compromise came in on. In parallel, assess whether the incident meets the significance criteria of Article 23(3) NIS2 — that determines the reporting clock.
Step 5 — conclusion. The entry point was not a flaw in your infrastructure but the trust granted to an account. The conclusion is not “change supplier”, but: the account gets a time window, an address range, and multi-factor authentication, and a session without a ticket becomes technically impossible rather than merely prohibited by contract. What shortens the time it takes to reach step 3 is covered in our article on how to reduce mean time to detect (MTTD).
What Does NIS2 Require of You Towards Your Suppliers?
The directive does not tell you to monitor the supplier — it tells you to account for the supplier in your own risk management. Article 21(2) lists a minimum set of measures, and point (d) states explicitly:
“supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”
— Directive (EU) 2022/2555 (NIS2), Article 21(2), point (d), OJ L 333, 27.12.2022.
Paragraph 3 of the same article says what specifically must be taken into account when choosing those measures: entities are to consider “the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures”, as well as the results of the coordinated security risk assessments of critical supply chains carried out under Article 22(1).
Three things follow from this directly. The scope is direct suppliers and service providers — not the entire multi-tier chain, which makes the task feasible. The obligation sits with your entity and outsourcing does not transfer it: contracting TMS maintenance out to another firm does not move your accountability towards the supervisory authority onto them. Finally, paragraph 4 requires an entity that finds itself non-compliant with the measures in paragraph 2 to take corrective measures without undue delay — so discovering a gap in supplier oversight itself triggers an obligation to act. Where the service provider’s role ends and yours begins is unpacked in our article on which obligations stay on your side with SOC as a service.
What Should You Demand From a Supplier to Make Monitoring Feasible at All?
Since you will not get the supplier’s telemetry, what remains is the contract. CIS Controls v8.1 calls this area Control 15: Service Provider Management and defines it as follows: “Develop a process to evaluate service providers who hold sensitive data, or are responsible for an enterprise’s critical IT platforms or processes, to ensure these providers are protecting those platforms and data appropriately” (CIS Controls v8.1, retrieved 2026-09-18). The key word is process, not a one-off questionnaire at signing.
In contracting practice this comes down to five demands:
- Notification of an incident at the supplier — within a deadline counted from the moment they become aware, on a named channel, with a contact person by name. Without it, your Article 23 NIS2 clock only starts when you read about the incident in the press.
- Access to integration logs — at least on your side of the gateway, and for a managed service also an export of security events from the supplier’s console.
- An agreed maintenance window and address range — so that the “outside the window” rule has something to refer to. A rule with no agreed baseline is a false-positive generator.
- Named accounts instead of shared ones — a single “tms_service” account used by eight of the supplier’s engineers is undetectable by definition.
- Right to audit and periodic review — with the scope written into the contract, so the review does not depend on goodwill.
This list is about making detection feasible, and it ends where the procurement process begins. Contract clauses, SBOM, and acceptance testing of a new device before it is connected to the network are a separate topic, unpacked in our article on supply chain security in OT.
The mechanics of software supply chain attacks themselves — from dependency substitution to a signed but malicious release — are the subject of a separate article on software supply chain attacks; here we are interested in what is visible of them from your side of the gateway.
How Do You Implement a SOC Step by Step?
Implementation breaks into four phases, and supplier contact points enter the scope in the very first one — at the inventory stage, not as a later extension.
Phase 1: Preparation
- Log source inventory (TMS, WMS, firewalls, servers, EDR)
- An inventory of supplier service accounts, integrations, and remote access channels
- Monitoring priority definition (what is critical)
- Model selection: internal SOC, outsourcing (MSSP/MDR), hybrid
- Definition of response SLAs per incident priority — values written into the contract and reconciled with actual staffing, not copied from marketing material
Phase 2: Technology integration
- SIEM deployment or connection to SOC provider’s SIEM
- Log collection configuration from all sources
- EDR deployment on endpoints
- Integration with telematics and IoT systems
Phase 3: Tuning and optimization
- Logistics-specific detection rule configuration
- Alert tuning — false positive reduction
- Incident response playbook development
- Team training on escalation procedures
Phase 4: Operations (ongoing)
- 24/7 monitoring with alert analysis
- Regular detection rule reviews
- Proactive threat hunting
- Management reporting (monthly/quarterly)
Which Detection Rules Are Specific to Logistics?
A SOC for a logistics company requires rules beyond standard IT:
Operational anomalies:
- Route changes in TMS outside working hours
- Mass customer data export from TMS/WMS
- TMS login from unusual geographic location
- Rate/price changes in the billing system
Telematics anomalies:
- GPS spoofing — sudden vehicle location change
- GPS signal loss lasting longer than the agreed stop window for a given route
- Telematics device configuration changes
- Communication with unknown servers
Integration anomalies:
- Unusual EDI message volume from a partner
- API calls from unauthorized IPs
- New EDI message type from an existing partner
- Transmissions outside agreed time windows
It is worth noting that the platform alone will neither write nor work these rules — why deploying a SIEM without a team to receive the alert does not produce detection is unpacked in Why a SIEM Without a SOC Does Not Work.
Internal SOC or Outsourcing — Which Should You Choose?
| Criterion | Internal SOC | Outsourcing (MDR) |
|---|---|---|
| Annual cost | 24/7 team salaries, SIEM/EDR tooling, development | Subscription dependent on scope and SLA |
| Implementation time | Months | Weeks |
| Team | Own analysts working in shifts | Dedicated provider team |
| Coverage | Shift-dependent | 24/7/365 |
| Industry knowledge | Built internally | Depends on provider |
| Control | Full | Limited (SLA) |
| Scalability | Difficult (recruitment) | Easy |
In the global SANS SOC Survey 2025 (July 2025), a fully staffed SOC most often had 2–10 people, and 79% of the surveyed SOCs operated 24/7. For logistics companies that cannot sustain their own team of analysts around the clock, SOC outsourcing is typically optimal. nFlo offers SOC services with experience in the logistics sector.
How Do You Measure That the SOC Actually Works?
Operational metrics:
- MTTD (Mean Time to Detect) — a target value written into the SLA, reported as a trend
- MTTR (Mean Time to Respond) — measured from alert to incident containment, against the target in the contract
- False Positive Rate — the share of false alarms, which should fall after each round of tuning
- Alert-to-incident ratio
Business metrics:
- Number of prevented incidents
- Downtime caused by incidents (target: 0)
- Incident cost vs. SOC cost
- NIS2 compliance (reporting deadlines met)
The supply chain metric that usually gets forgotten: the share of supplier service accounts covered by a time window and an address range, and the share of remote support sessions linked to a ticket. Both are computed from your own data, and both are direct evidence that the measure in Article 21(2), point (d) of NIS2 has been implemented.
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
Related topics
See also:
Related services and products
- OSINT (Open Source Intelligence)
- 24/7 Monitoring - Proactive Infrastructure Oversight
- Bitdefender GravityZone Integrity Monitoring
Frequently asked questions
Should a logistics company build an internal SOC or outsource?
For most logistics companies, SOC outsourcing (MDR/MSSP) is optimal. Building an internal SOC requires a team of analysts working 24/7 shifts, SIEM, EDR, and a standing budget for staff, tooling and development. The price of SOC outsourcing depends on the number of endpoints, log volume, sources, SLA level and compliance requirements, and the service provides full 24/7 coverage.
Which logistics systems should a SOC monitor?
Critical: TMS, WMS, telematics systems, VPN/ZTNA, Active Directory, mail servers. Important: EDI, API integrations, IoT systems, scanner terminals. Recommended: cameras, physical access control systems.
How long does SOC implementation take in a logistics company?
SOC outsourcing: weeks (onboarding, log source integration, alert tuning). Building an internal SOC: months (recruitment, technology, processes, tuning).
Can a SOC monitor a supplier's security?
No — you have neither the right nor the access. A SOC monitors your own contact points with the supplier: service accounts, integrations and APIs, software update channels, and remote support sessions. The quality of the supplier's own practices is assessed through the contract and periodic review, not through telemetry.
What does the NIS2 directive require regarding the supply chain?
Article 21(2), point (d) lists supply chain security among the minimum risk-management measures, and Article 21(3) requires entities to take into account the vulnerabilities specific to each direct supplier and the overall quality of its products and practices. The obligation sits with your entity — outsourcing does not transfer it.
