HR is the part of an organisation where the most personal-data processing concentrates — and often the most sensitive. GDPR Article 30 requires you to keep a record of those processing activities, and the CNPD asks for it among the first items in a review. Kept well, it becomes a map of your compliance; kept badly, it exposes everything that is missing.

What Article 30 requires

Article 30 of the GDPR requires every controller — the employer, here — to maintain a record of processing activities (the ROPA). This is not a communication document: it is an internal, up-to-date inventory that you must be able to produce for the supervisory authority on request.

For each processing activity, the record describes at least the purpose, the categories of individuals and of data involved, the recipients, any transfers outside the EU, the envisaged retention periods, and a general description of the security measures. In Luxembourg, the competent authority is the CNPD (Commission nationale pour la protection des données). Where a personal-data breach occurs, notification to the authority must generally be made within 72 hours — a window you only meet if you already know which processing activities are affected and where the data lives.

The HR processings to record

The temptation is to record "HR" as a single activity. That is a mistake: an HR function actually hosts a series of distinct processing activities, each with its own purpose and legal basis. At a minimum, separate:

  • Recruitment. Applications, CVs, interview notes, tests. How long unsuccessful applications are kept is a perennial question in reviews.
  • Payroll. Remuneration, tax withheld at source, social declarations, payslip history. The most regulated processing, connected to the ACD's Bureau RTS and to the CCSS.
  • Working time. Clocking, leave, absences, schedules — behavioural data generated continuously.
  • Health data. Medical certificates, fitness for work, workplace accidents. A special category under the GDPR, to be isolated and given stronger protection.
  • Evaluation and career. Annual reviews, objectives, progression, promotion decisions. Sensitive both on a human level and under employment law.

Each deserves its own line in the register. That granularity is what later lets you assign the right legal basis and the right retention period, instead of one rule wrongly applied to the whole function.

The most common error is to tick "consent" everywhere. In the employment relationship, consent is fragile: the subordination between employer and employee casts doubt on how freely it is given. Most HR processing therefore rests on other grounds.

  1. Performance of the contract. Paying wages, managing leave and keeping the personnel file follow directly from the employment contract. Often the strongest basis for the core of the relationship.
  2. Legal obligation. Declarations to the CCSS, tax withheld at source for the Bureau RTS, and the retention of certain documents arise from obligations imposed by law.
  3. Legitimate interest. Some internal-management processing can rely on this, provided you document the balancing test against employees' rights.
  4. Consent. Reserve it for genuinely optional cases (a photo on the intranet, opt-in perks) where refusal has no bearing on employment.

The legal basis is not a cosmetic field: it drives retention periods, the rights an employee can exercise, and the very legitimacy of the processing. Where a specific case is unclear, confirm it with your DPO or advisor.

"An Article 30 register is not a document you write once. It is a living reflection of what the system actually does with the data — and it should update when the system changes, not six months later."

Luxapps product team

The columns that trip people up

Once the activities are listed, a few specific columns are what actually sink registers in practice:

  • Retention. HR and payroll documents carry statutory retention periods. They vary by document type; it is safer to write "statutory retention periods apply" and lean on your advisor than to invent a number of years. The real trap is leaving this column blank or filling it "indefinite".
  • Recipients. You must name who receives the data: authorities (CCSS, ACD), providers (outsourced payroll, hosting), and any processor. An undeclared recipient is a classic finding.
  • Security. A general description of the measures is enough, but it must be real: access control, encryption, logging. The measures then have to genuinely exist behind the sentence.
  • Transfers outside the EU. The most revealing column. An HR tool hosted with a non-EU cloud provider often creates a transfer that must be framed and safeguarded. Hosting data in Luxembourg, with no non-EU dependency, makes this column simple: "no transfer outside the EU".

Why a spreadsheet ROPA fails a CNPD review

The register nearly always starts life in a spreadsheet. That is a fine starting point but a poor destination. The problem is not the format: it is that the spreadsheet drifts away from reality. A new field added to the HR tool, a new provider, a changed retention period — none of it flows back into the file automatically. After a few months, the register describes a system that no longer exists.

In a review, the authority does not merely compare columns: it tests the register against the reality of the system. A ROPA that claims a retention period the application does not enforce, or that omits a real recipient, works against the organisation — it shows that compliance governance is theoretical. That is where a disconnected register becomes a risk rather than a protection.

Keeping the register current through automation

The only way to keep a register trustworthy is to bring it close to the system that produces the data. At Luxapps, compliance is not a module you switch on: it is built into the architecture of the HR software. Processing activities, legal bases, recipients and retention periods live in the data itself, which lets a register be derived that reflects the real state of the system rather than a stale snapshot.

Three architectural choices help: hosting in Luxembourg, with no non-EU cloud dependency, which simplifies the transfers column; a native audit log, which documents the access and changes actually made; and role- and resource-based access control, which gives concrete content to the "security measures" column. On the payroll side, the same logic applies to Luxembourg payroll obligations — tax withheld at source, CCSS declarations, payslip history — whose retention periods are carried by the data.

None of this replaces a DPO's judgement. But a register that updates with the system turns Article 30 from an annual chore into a permanent, defensible view of your processing. It is the same idea we set out in our piece on an HRIS designed for Luxembourg compliance.

Want an Article 30 register that stays true? Explore our approach to HR compliance software in Luxembourg, built so that compliance is proven rather than merely declared.

Discuss your GDPR register Request a demo →