Managed Service Provider (MSP) and Vendor Management System (VMS) solutions can help organizations gain control over their contingent workforce, but only if the operating model and compliance responsibilities are defined upfront. This contribution explores how to structure sourcing, contracting, and implementation so that responsibilities, pricing, data protection, and the use of AI are clear and workable. It also explains why appointing an MSP does not relieve the customer of their own obligations under Belgian labor and social security law.

An increasing number of organizations use an MSP and a VMS to gain control over their contingent workforce. This workforce includes freelancers, consultants, and other non-employees provided by suppliers or project sourcing agencies. When it is set up well, an MSP/VMS model can open access to talent, improve visibility into spending, and reduce operational hassle. It can also be a powerful enabler for “total talent management,” managing employees and contingent workers in one coherent strategy. When it is set up poorly, it can lock the business into rigid processes, unclear responsibilities, and legal risk – especially where the decision is made through a tender that focuses mainly on selecting the cheapest MSP, without a strategic, cross-functional discussion, with legal and compliance consequences treated as an afterthought.

At its simplest, the MSP is the service partner that runs its customer’s contingent workforce program. It usually takes care of sourcing candidates, managing staffing suppliers, onboarding, reporting, and invoicing. The VMS is the technology platform that supports those processes. It is the tool where requests are raised, assignments approved, timesheets submitted, and data analyzed. Some providers offer both in one integrated solution, while others focus on either the service layer (MSP) or the technology layer (VMS). Choosing an integrated offer can make coordination easier, provided one party clearly accepts end-to-end responsibility. Choosing separate contracts can give you more flexibility, but only if implementation, interfaces, service levels, and exit scenarios are aligned upfront.

From an employment law perspective, MSP and VMS solutions support compliance but do not guarantee it. Appointing an MSP does not relieve the customer - as the company that effectively uses the contingent workforce - of the obligations that apply to it under Belgian labor and social security law. The end responsibility for respecting mandatory rules and choosing the correct collaboration forms remains with the customer. The MSP may help to structure the process and flag risks, but it does not replace the role of employer or user company. Risks around misclassification of workers (bogus self-employment), prohibited employee lease (verboden terbeschikkingstelling van personeel) and illegal employment of workers still therefore sit primarily with the customer, as those assessments are made on the factual situation (i.e. who gives instructions, who integrates the worker in its organization, who benefits from the work) and not on what the MSP contract states.

Define the operating model

Before a company interacts with the market, it needs to be clear internally on both its operating model and its compliance model. Which entities and countries are in scope? Which categories of contingent workers are considered (e.g. temporary agency workers, independent contractors, consultants engaged under a statement of work (SOW), etc.)? Which existing suppliers and tools will be impacted? Which engagement models are legally allowed for the types of work and profiles it wants to source? How will the company detect and escalate potential misclassification issues?

How the underlying supplier relationships are structured also has legal consequences. In some models, the MSP contracts with staffing agencies and other suppliers in its own name and passes the cost on. In others, the MSP acts on the customer’s behalf or simply administers contracts that remain between the customer and the suppliers. Each choice affects liabilities and legal risks: who is considered the “user company”; who can be held jointly liable for wages and social security contributions under certain statutory regimes; who is exposed if the arrangement is requalified as prohibited hiring out of workers or illegal employment. A responsibility matrix that only addresses commercial and operational tasks (who approves, who pays, who monitors performance) is not sufficient. It should be reconciled with a legal view of who is regarded as employer, user company, or principal under Belgian and applicable foreign rules. Contract clauses can redistribute civil liability between the customer and the MSP (for example via indemnities), but they cannot erase or transfer criminal or administrative liability. Where supplier personnel work under a services arrangement, particular attention should be paid to which instructions the customer may give, how those instructions are documented and whether day-to-day practice respects the agreed boundaries.

Tender documents should be built around that intended operating model and compliance model. A meaningful comparison between bidders requires a sufficiently clear baseline: the organizational scope, contingent workforce categories, rough volumes, and key implementation dependencies. Requirements should separate must-have capabilities from nice-to-have features and future ambitions and explicitly address compliance support. The latter includes, for instance, whether the customer expects the MSP to perform certain checks on licenses of temp agencies, social law documentation, right-to-work checks, or indicators of bogus self-employment. Otherwise, there is a risk that the customer assumes that the MSP will handle compliance without having specified what that should mean in practice. Price comparison also needs context: headline fees should be assessed together with implementation effort, integration needs, service quality, data access, and transition costs from the as-is situation. Scenario-based demonstrations can be particularly revealing; for example, how the proposed arrangement would handle an urgent request, a disputed invoice, a supplier that fails a compliance check, or a suspected case of misclassification.

For public sector organizations, the MSP/VMS operating model must additionally fit within the applicable public procurement framework. The choice of procedure, the division into lots and any planned extensions or modifications must be considered carefully. It is a common misconception that involving an MSP automatically by default solves the procurement treatment of the underlying contingent workforce purchases. 

Translate the model into contracts

Contractually, an MSP/VMS program usually consists of multiple connected documents: a main agreement (e.g. framework agreement of master services agreement), service descriptions, implementation plans, pricing schedules, service level commitments, data protection terms and – in many cases – underlying (model) supplier agreements. These documents should work together as a coherent whole. 

In practice, we often see conflicting definitions, inconsistent obligations, and unclear precedence rules eroding protections that parties thought they had negotiated. Particular care is needed where a VMS provider’s (online) terms and conditions are incorporated by reference and may change during the contract term. 

The MSP agreement should make explicit how far the MSP’s responsibility extends for supplier selection, compliance checks (including labor law checks), onboarding, performance monitoring, invoicing, and escalation. If the MSP contracts directly with suppliers, key customer requirements and standards need to be flowed down, backed by appropriate enforcement rights, including rights to suspend or terminate relationships where legal non-compliance is identified. 

For the VMS, the contract should clarify who can use the platform, what functionality is included, how integrations and support will work, and what happens when the platform changes. Rights to use configurations, interfaces and documentation should be sufficient to support day-to-day management of the contingent workforce and any transition to a new solution later.

Making implementation measurable

Implementation deserves its own discipline. Data migration, system integrations, supplier onboarding, workflow configuration, and user training are often where MSP/VMS programs succeed or fail. This is also where labor law compliance can be either embedded or forgotten. 

The implementation plan should specify how compliance-critical data and processes will be handled: for example, how right-to-work checks are documented, how licenses of temporary agencies are verified, how contract types for contingent workers are recorded in the VMS, how approvals are routed when an assignment looks like it might cross into prohibited employee leasing or bogus self employment. Acceptance criteria should focus on whether the solution works in the customer environment, with customer data and customer users, and whether it supports the customer’s compliance processes. Defect management and delay handling should consider the risk of operating a partially implemented system that allows sourcing contingent workers without proper checks. 

From there, operational performance indicators can be tailored to the different roles: MSP metrics might focus on fulfillment times, compliance checks, reporting accuracy, and invoice quality, while VMS metrics might cover system availability, incident response, restoration times and user support. Remedial actions and financial remedies should be proportionate to the impact of failures, with an escalation path for repeated issues that individually look minor but cumulatively undermine the program.

Align pricing and incentives

The pricing model also shapes behavior. A fee calculated as a percentage of contingent workforce spend creates different incentives from a fixed fee or a fee linked to demonstrable savings. 

The agreement should make clear who pays the MSP, how fees are calculated and whether the MSP receives rebates, commissions, or other benefits from suppliers. Where the MSP or a group company also supplies contingent workers into the program, the agreement should address conflicts of interest, transparent selection criteria and safeguards against preferential treatment of affiliated suppliers. 

Savings commitments are attractive, but require an agreed baseline, a transparent calculation method and verification that savings do not result from reduced service quality, changes in scope or non-compliance with applicable law. Pricing should also cover implementation, integrations, minimum commitments, indexation, additional functionality and exit support, so that the total cost over the life of the contract is clear and later disputes about what was included in the agreed fees can be avoided.

Address data protection and AI use

Data protection and AI require specific attention in MSP/VMS environments, which typically involve large volumes of candidate data, assignment details, timesheets, and potentially sensitive information about the customer’s contingent workforce. 

GDPR roles need to follow the actual processing activities. In most cases, the customer will be a controller for its contingent workforce management. An MSP may consequently act as a processor when administering workflows on the customer’s behalf, while acting as an independent controller for processing activities for which it determines the purposes and essential means. The VMS provider will typically act as a processor engaged directly by the customer or as a sub-processor engaged by the MSP. Any processing of personal data for the provider’s own purposes, such as certain benchmarking, product improvement or AI training activities, requires a separate assessment of its role and the lawfulness of that processing. Staffing suppliers often have their own controller responsibilities for recruitment decisions. A blanket designation for the entire relationship can be misleading and simply declaring that parties are not joint controllers does not override the reality if they jointly decide on purposes and means. Contractual arrangements should therefore cover processing instructions, transparency towards workers and candidates, security, sub-processors, international transfers, retention periods, data subject rights, and incident cooperation. 

Where AI functionality is used – for matching candidates, ranking applications, recommending rates or automating workflow decisions – visibility is required over what is in place and how it may evolve. Depending on their intended purpose and functionality, AI systems used for recruitment, selection, or worker management may qualify as high-risk under the EU AI Act. The agreement should identify the parties’ respective roles as provider or deployer and specify the information, assistance, and controls needed to meet the obligations applicable to each party. Contracts should address permitted uses, human oversight, documentation, logging, testing, and cooperation with compliance assessments, as well as who pays for required changes and what happens if a feature needs to be suspended. A general promise to “comply with applicable law” is not enough, especially not if the AI solutions and outcome influences hiring decisions and could be scrutinized under both non-discrimination rules and the AI Act.

Plan for exit

Finally, a workable exit strategy is part of the foundation, not an afterthought. Replacing an MSP should not inadvertently cut off access to the VMS, the supplier network, or historical records on the customer’s contingent workforce. Switching platforms should not make it impossible to continue managing ongoing assignments. Exit provisions should therefore cover continued service during transition, data export formats, migration assistance, knowledge transfer, cooperation with incoming providers, and the treatment of active supplier arrangements. Transition timelines, assistance, and any permitted charges should be agreed in advance. 

Where the VMS qualifies as a data processing service under the EU Data Act, the contract must also reflect the applicable switching requirements, including those concerning contractual terms, exportable data and digital assets, and the removal of obstacles to switching. 

When procurement, HR, IT, and legal teams align early on the operating model and the compliance model, and carry those decisions through sourcing, contracting, and implementation, MSP and VMS arrangements can become powerful solutions to manage contingent workforce strategically and compliantly. Without that alignment, they risk becoming rigid systems that the organization has to work around and that give a false sense of security on labor law compliance. The difference lies in the groundwork.

If you require further information or legal advice in this respect, please contact us!

This article was written by Julie Van Kerckhoven and Raf Schoefs.