By Yair Knijn · August 5, 2025
NIS2 turned your file-transfer vendor into your personal liability
Watch a CISO scope NIS2 supply-chain obligations and you can predict the list: cloud hosting, the EDR vendor, the identity provider, maybe the MSSP. Meanwhile the platform pushing payroll files, claims data, and EDI feeds to two hundred trading partners every night sits one floor down in an ops folder, owned by an integration team nobody invited to a risk meeting. It never makes the list.
That omission is the one with a director's name on it. Under NIS2, an unreviewed managed file transfer (MFT) platform is a direct ICT supplier handling regulated data flows, and the directive routes accountability for it straight up to the management body as a personal matter.
What the supply-chain obligations actually cover
Article 21(2)(d) is blunt. Essential and important entities have to address supply-chain security, including the security of relationships with each direct supplier. There is no "do good vendor management" wiggle room. You assess the supplier's security posture, write security obligations into the contract, and keep watching them on a cadence, not just at onboarding.
An MFT vendor is a direct supplier by any honest reading. It terminates your SFTP and AS2 sessions, holds partner credentials and signing keys, and touches the payloads in transit. Scope your assessment to infrastructure and skip the system that physically carries regulated data between organisations, and you have left an Article 21 gap with your signature on the approval.
Why this is a supply-chain link, not plumbing
MFT reads as infrastructure because it has hummed along for years and nobody touches it. That invisibility is exactly what makes it dangerous in a review: it is the node where your data crosses your control boundary into someone else's hands. Trace one nightly batch. A partner drops a file; your platform authenticates them, decrypts, re-encrypts, signs, forwards downstream. Each step is a control that either exists and is evidenced or quietly does not. When the platform can't produce a per-transfer audit trail, or the vendor can't say where the data is processed and who can reach it, you are running an unmeasured dependency through a regulated pipe.
The personal-liability part
Article 20 is where the calculus shifts. It puts the management body on the hook for approving and overseeing cybersecurity risk-management measures, and lets member states hold those individuals personally liable when the oversight fails. For essential entities, authorities can reach past money and ban a person from exercising managerial functions.
- Essential entities: fines up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher.
- Important entities: fines up to EUR 7 million or 1.4% of worldwide annual turnover, whichever is higher.
- For essential entities, authorities can also impose a temporary management ban and order security audits at the entity's own expense.
The trigger is rarely a clever breach. It is a demonstrable failure to assess and oversee a dependency you already knew about. A regulator investigating a transfer incident asks for three things: the supplier assessment, the contractual security clauses, the monitoring records. "We treated it as plumbing" is the sentence that turns a board oversight gap into a personal sanction.
What closes the gap
The fix is unglamorous and concrete. Put the MFT vendor on the same Article 21 footing as every other direct supplier. Get a written answer on data residency, sub-processors, and personnel access. Require encryption in transit and at rest, signed payloads with non-repudiation where partners mandate it, and a per-transfer audit log you can export for an investigation. Push NIS2-equivalent security and incident-notification obligations into the contract instead of swallowing the vendor's stock terms, and book a review cadence so the assessment doesn't go stale the day after signing.
xEvolve was built to survive that review. Each customer runs in an isolated environment with SFTP, AS2, and HTTPS under one unified, exportable audit trail, encryption and signing enforced per partner, and a data-residency answer you can put in a contract clause. When a regulator or your board asks who handles your partner file flows and how you oversee them, the answer should already be on paper. See how the controls map at /security.