If you ask an inspector from the Commissioner's office where they begin, the answer is almost always the same: show me your register of processing activities. The ROPA is the map of everything an organisation does with personal data. Without it, every other question - what is your legal basis, how long do you keep this, who do you share it with, where does it go - has no anchor. With it, an inspection becomes a structured conversation rather than a fishing expedition.

What the law requires

Article 27 of Law 124/2024 requires controllers, and processors within their own sphere, to maintain a written record of their processing activities. This is the Albanian equivalent of Article 30 of the GDPR, and it is worth noting the numbering carefully: material written for a GDPR audience often cites Article 30, which under Albanian law governs something else entirely.

Written includes electronic form, and the record must be made available to the Commissioner on request. This is not advisory. It is a standing obligation that exists whether or not anyone has ever asked to see the document, and its absence is itself a finding an inspector can make on the first morning.

What a register entry must actually contain

A useful entry is not a one-line label. For every processing activity the record needs to capture, at minimum:

  • The controller, with joint controllers and processors where relevant, and contact points including the data protection officer or whoever owns the activity internally. If a foreign controller relies on an Albanian representative, that appointment belongs here too.
  • The purpose, stated concretely. "Administering employment" is a purpose; "HR stuff" is not. Where one activity serves several purposes, each is named, because each may carry its own legal basis and its own retention clock.
  • The legal basis, mapped to a specific ground: consent, performance of a contract, a legal obligation, vital interests, a public interest task, or legitimate interests. Where the ground is legitimate interests, the entry should point to the balancing assessment that justifies it. Where special category data is involved, the entry must also name the additional condition that permits it.
  • The categories of data subjects: employees, candidates, customers, website visitors, suppliers' staff, children, and so on.
  • The categories of personal data, described precisely enough to reveal risk. "Contact details, national ID number, bank account, salary, performance ratings, health leave records" tells a reader far more than "employee data", and it is the difference between an entry an inspector accepts and one they interrogate.
  • The recipients: internal departments, processors such as payroll bureaux, cloud hosts and email platforms, and public authorities such as the tax administration or the social insurance body.
  • International transfers: whether data leaves Albania, to which country and recipient, and on what safeguard under Articles 39-42, the Albanian equivalent of GDPR Articles 44-49. An empty field here is a claim that nothing leaves the country. Make sure it is true, because a US-hosted SaaS tool is a transfer.
  • The retention period: the actual period, or the criterion used to set it, such as "the duration of employment plus the statutory limitation period". Not "as long as necessary", which documents nothing.
  • The security measures, described at a level that shows they are real: access controls, encryption at rest and in transit, role-based permissions, logging, backup and recovery.

That is the anatomy of one row. The register is many such rows, kept current as a matter of routine.

A worked example: payroll

Abstractions are easy to nod along to and hard to reproduce, so here is a single activity documented the way an inspector wants to see it.

  • Activity: payroll administration. Owner: HR Manager. Oversight: the DPO.
  • Purposes: calculating and paying salaries; withholding and remitting income tax and social and health insurance contributions; producing payslips and statutory reporting.
  • Legal basis: performance of the employment contract for salary payment; compliance with a legal obligation for tax and contribution reporting. Two grounds, because the same data serves two purposes with different rules.
  • Data subjects: current employees, and recently departed employees within the retention window.
  • Data categories: name, national identification number, address, bank account, gross and net salary, tax withholdings, contributions, and where sick leave is processed, health-related absence data, which is special category and permitted under the employment law condition.
  • Recipients: the external payroll provider as a processor under a written agreement; the bank executing transfers; the tax administration and the insurance authorities.
  • International transfers: none, if the payroll system is hosted in Albania or in a destination covered by the Commissioner's adequacy decision. If the provider hosts elsewhere, the transfer and its safeguard are named here rather than left blank.
  • Retention: the period required by tax and labour law after employment ends, then deletion or anonymisation.
  • Security: access limited to HR and finance on a need-to-know basis; encryption in transit and at rest; multi-factor authentication; audit logging; regular backups.

Notice how much of this only the HR Manager knows precisely, and how quickly it dates. A new payroll vendor, a change of bank, a new statutory report, and three fields are stale. That decay is the real subject of this article.

Why the annual spreadsheet fails

The difficulty with a register is rarely any single entry. It is that the information lives in different heads. HR knows payroll and recruitment; marketing knows the email list and the analytics tags; IT knows the systems and the vendors; finance knows debt collection and archiving. A DPO building the register alone, by interviewing everyone once a year, ends up with a snapshot that is out of date the moment a new tool is adopted or a vendor is swapped.

So the spreadsheet decays. It is accurate on the day it is made, quietly wrong within months, and worse than useless in an inspection, because it documents a reality that no longer exists. It confidently attests to processing the organisation has stopped while omitting the three tools it started using in the spring. An inspector who catches one stale row stops trusting the rest of the document, and the register meant to demonstrate control instead demonstrates its absence.

The annual refresh model does not fail because people are careless. It fails because it fights the grain of how organisations actually change: continuously, in the business units, without routing every change past the DPO.

How PrivaxisOS handles this

The ROPA module treats the register as an ongoing, distributed workflow rather than an annual chore. Each processing activity is a structured entry capturing owner, purpose, legal basis, data categories, data subjects, collection and storage, processors, retention, security and international transfers - the full anatomy above, in fields rather than free text, so nothing quietly goes missing.

Ownership is distributed. The DPO holds oversight of the whole register, but the detail is maintained where the knowledge is. Each business unit assigns a liaison: the HR Manager owns HR's activities, the marketing lead owns marketing's, IT owns the systems and vendor entries. The people who run a process keep its record, because they are the only ones who know the day it changes. The DPO stops being a bottleneck re-interviewing the whole organisation and becomes the reviewer and the authority rather than the sole author.

A formal workflow governs every change. Each entry moves through defined states, from draft to submitted to approved. A liaison drafts or edits an activity and submits it; the DPO reviews and either approves it, which locks the entry as the authoritative version, or returns it with a reason. Nothing enters the official register unreviewed, and no change is invisible. The register carries an accountability trail: who owns each activity, who last changed it, and who signed it off.

Review is scheduled rather than improvised. Review cycles prompt each liaison to confirm or update their entries, closing with a final sign-off, so "current" is a maintained state rather than a hopeful assumption. And when the Commissioner asks, the whole register exports for a regulatory submission or an internal audit, with no scramble and no reconstruction.

What an inspector actually checks

An inspector rarely reads every row. They probe. They pick an activity they can see from the outside - the CCTV at the door, the newsletter you sent them last week, the job posting on your careers page - and ask to see its entry. Then they test whether the document matches reality: does the legal basis make sense for the purpose, is there a retention period that is an actual period, are the processors you obviously use listed, and does the transfers field admit the cloud tool whose logo is on your login screen?

A register that survives that test is one where the entries were written by the people who run the processes and kept current between inspections. That is precisely the register a distributed, workflow-governed model produces, and precisely the one an annual spreadsheet cannot.

A short readiness check

Do you have a single, complete inventory of your processing activities? Does each entry name a legal basis and a real retention period? Do the people who run each process keep their own entries current? Is there a review and sign-off someone is accountable for? Could you export the register today if the Commissioner asked? If the honest answer is "we have a spreadsheet somewhere", the register is a liability rather than an asset.