Run an HRIS selection :
the RFP template.

Choosing an HRIS commits a company for five to ten years : payroll, personnel files, working time, health data. Deciding on the strength of a demo tour alone lets the vendor write your criteria for you. A structured selection flips that : you write the requirement, and the vendor proves it can meet it.

Why a structured selection beats a demo tour

A demonstration shows what the vendor wants to show, with clean data and a rehearsed script. It says nothing about migrating your history, about French-language support, or about how the tool handles an index tranche on a Friday evening. Lining up three or four demos without a shared grid almost always produces the same bias : you pick the most convincing salesperson, not the best-fitting product.

A structured selection — usually formalised as an RFP (request for proposal) — puts every candidate in front of the same questions, in the same order, on the same scoring scale. You compare written, binding answers rather than impressions. And you keep a decision trail, which matters when a committee or an audit later asks why you chose as you did.

The effort also pays off after signature. The requirements you write become the acceptance criteria for the project : what the vendor committed to in the RFP is what you test at go-live. A demo tour leaves you with nothing to hold anyone to ; a structured selection leaves you with a contract that names the payroll, indexation and data-hosting behaviours you actually need.

Gathering requirements, with the Luxembourg specifics

Before writing a single line of the RFP, collect the real requirements — not a brochure's feature list. Talk to payroll, HR, management, IT and, where relevant, employee representatives. In Luxembourg, some topics are not negotiable and must be written down explicitly :

• Payroll and CCSS declarations. The system must produce Luxembourg payroll and feed declarations to the Centre commun de la sécurité sociale (hires, departures, monthly contributions). Ask how, and how often.
• Tax at source (RTS). Withholding on salaries by tax class (1, 1a, 2), managed as family situations change. The tool must track those classes and the applicable brackets.
• Automatic wage indexation. The sliding wage scale (+2.5% per tranche) is a public-order rule ; the most recent indexation took effect on 1 June 2026. The HRIS must apply it automatically, with no manual step.
• Multi-CCT. Several collective agreements can coexist within one company, with different pay scales, seniority steps and bonuses per population. Confirm the tool handles that diversity, not a single agreement.
• GDPR and the Article 30 record. HR processing must appear in the record of processing activities : purpose, legal basis, categories, recipients, retention, security measures. The CNPD is the supervisory authority ; breach notification is generally within 72 hours.
• Data hosting. Where does the data live? Hosting in Luxembourg, or at least in the EU, with no dependency on a non-EU cloud, simplifies compliance — especially for financial-sector entities subject to the CSSF's outsourcing expectations.

The RFP structure — sections to include

A good RFP is brief in its intentions and precise in its requirements. Break it into clear sections so each vendor answers point by point :

• Context and objectives — headcount, populations, agreements, timeline, indicative budget, what the project must solve.
• Functional scope — payroll, time, leave, files, appraisals, expenses : required, desired or out of scope.
• Legal and compliance requirements — CCSS, RTS, indexation, multi-CCT, GDPR, statutory retention.
• Security and hosting requirements — data location, encryption, role- and resource-based access control, audit log, reversibility.
• Integrations — accounting, time clocks, directory/SSO, regulatory exports.
• Service and support — language, response times, upgrades, maintenance.
• Commercial model — billing model, implementation costs, reversibility and exit.
• Response rules — expected format, deadline, criteria and weighting, next steps.

Evaluation criteria and scoring

Set the grid before the responses arrive, so you do not bend the criteria to the candidate you already prefer. Give each axis a weight and score each answer on a simple scale (say 0 to 5). A reasonable starting weighting :

1. Functional coverage (25%). Does the tool cover the required scope without heavy custom development?
2. Luxembourg compliance (25%). CCSS, RTS, indexation, multi-CCT, GDPR : concrete commitments, not ticked boxes.
3. Security and hosting (15%). Data location, access control, audit, reversibility.
4. Integration and migration (15%). Loading history, connections to the existing IT landscape.
5. Total cost over time (10%). Licences, implementation, maintenance, exit — not just the sticker price.
6. Vendor and support (10%). Solidity, language, comparable Luxembourg references.

Score as a committee, average, then discuss the gaps. The table does not decide for you, but it exposes the candidates that dazzle without convincing — and the reverse.

Common pitfalls

• Letting the demo lead. A rehearsed script hides real cases : insist on a test using your data and your agreements.
• Confusing "GDPR-compliant" with EU hosting. A vendor can tick GDPR while relying on a non-EU cloud ; ask about data location explicitly.
• Forgetting reversibility. Verify full data export at contract stage, not when you are leaving.
• Underestimating multi-CCT and indexation. Two areas where "configurable" global tools most often give way.
• Comparing on licence price alone. Implementation, migration and maintenance often weigh more than the licence.
• Overlooking employee representatives. Some processing — performance monitoring, HR decision-support tools — requires informing them.

A ready-to-use RFP outline

Copy the outline below and adapt it to your context. Each bullet becomes a question the vendor answers, ideally with a written commitment :

1. Company overview: sector, headcount, sites, applicable collective agreements, timeline and indicative budget.
2. Project objectives: problems to solve, expected gains, success criteria.
3. Functional scope: payroll · time and leave · personnel files · appraisals · expenses · employee portal — required / desired / out of scope.
4. Luxembourg legal requirements: payroll and CCSS declarations · RTS withholding and tax classes · automatic indexation · multi-CCT handling · statutory document retention.
5. Data protection: GDPR compliance · Article 30 record · data-subject rights · breach procedure (72h) · sub-processors and data location.
6. Security and hosting: hosting location (Luxembourg / EU) · encryption in transit and at rest · role- and resource-based access control · native audit log.
7. Integrations: accounting · time clocks / attendance · directory and SSO · regulatory exports · available APIs.
8. Migration: loading payroll history and files · support provided · duration and responsibilities.
9. Service and support: languages · response times · update cadence · maintenance and roadmap.
10. Commercial model: billing · implementation costs · reversibility and exit terms · guaranteed data export.
11. Response rules: format · deadline · criteria and weighting · contacts · next steps (demo, test on real data, references).

This outline is deliberately neutral : it exists to compare, not to steer. To go deeper on what an HRIS must cover in Luxembourg, our HRIS for Luxembourg page details the expected functions, and our HR compliance software for Luxembourg pillar frames the regulatory requirements. The story of our HR platform reaching more than 25,000 users shows these choices in production.