The first real test of a data protection programme is rarely an inspection. It is an email from a customer or an ex-employee that begins: "I would like a copy of all the data you hold about me." Under Law 124/2024 that email starts a legal clock, and how you answer it is one of the clearest signals of whether your compliance is real or on paper. An inspector visits once. Requests arrive continuously, and each one is a small, documented test of whether the programme works when nobody is watching.

What the law requires

Articles 12-21 of Law 124/2024 give every individual a set of rights over their own data. They are the Albanian counterpart of Articles 12-22 of the GDPR, so an organisation that already answers requests under EU rules is working from the same template rather than starting again. These are not abstractions; each right lands on someone's desk as a concrete task with a deadline attached.

  • Access. The person can ask what data you hold, why you process it, who you share it with, and how long you keep it. This is the most common request and the hardest to answer completely, because personal data sits in systems that were never designed to be searched by data subject.
  • Rectification. They can ask you to correct inaccurate data or complete data that is incomplete: a wrong address, a misspelled name, an outdated marital status on a policy file.
  • Erasure. They can ask you to delete their data, though the right yields where you have a legal duty to keep records. An ex-employee cannot erase payroll data you must retain for tax and labour purposes.
  • Restriction. They can ask you to freeze processing while a dispute is resolved, so the data stays but sits untouched.
  • Portability. Where processing rests on consent or a contract and is automated, they can ask for their data in a structured, machine-readable format, or to have it sent to another provider.
  • Objection. They can object to processing based on your legitimate interests, and to direct marketing outright. An objection to marketing must always be honoured, with no balancing test.
  • Automated decisions. They have the right not to be subject to a decision producing legal or similarly significant effects taken solely by automated means, and to ask for human review.

Article 12 sets the deadline. You must respond within 30 days of receiving the request. Where the request is complex you may extend that to 60 days in total, but only if you tell the person inside the first 30 days that you are extending and why. Before you act you must verify the requester's identity, so you are not handing one person's data to another. And you must be able to show what you did: the request, the steps taken, the decision, and the date.

The right to refuse exists but is narrow. You can reject or partly fulfil a request only on defined legal grounds, and you must explain those grounds in writing. Silence, or missing the deadline, is itself a breach.

The 30-day clock in practice

The deadline is stricter than it looks, because it is not 30 days to reply. It is 30 days to verify identity, locate the data across every system, review it for third-party information, decide the legal outcome, and deliver a response. The reply is the last step, not the whole window.

Consider an access request to a bank. A former account holder asks for everything held on them. The data lives in the core banking system, the CRM, the loan origination file, call-centre recordings, the anti-money-laundering screening logs, and email. Some of it names other customers on joint accounts. Some of it is subject to mandatory retention. Thirty days to find, review, redact and package all of that is not generous, and the clock started the day the email arrived, not the day somebody noticed it.

The extension to 60 days is real relief, but it is conditional. Extend silently and you have simply missed the deadline. The safe posture is to treat 30 days as the default and the extension as a documented exception, never as a fallback invoked after the fact.

There is a second timing trap: identity verification does not stop the clock. If you need more information to confirm who someone is, ask promptly and record the exchange, but do not treat a slow reply from the requester as an excuse for missing your own deadline. Build the verification step so it takes days, not weeks.

Grounds for refusal, and the traps in them

Refusal is where well-meaning organisations most often slip, either refusing too readily or fulfilling requests they should have questioned. Two scenarios show the shape of it.

An ex-employee sends an erasure request three months after leaving, wanting all their data deleted. You cannot simply comply. Payroll records, tax filings and social contribution data carry retention obligations that override erasure. You may delete the marketing list entry and the internal chat history, but the personnel file stays for its statutory period. The correct response is a partial fulfilment with a written explanation of exactly what was deleted, what was kept, and the legal basis for keeping it. Not a flat no, and not a blanket yes.

The opposite trap is the request that is really someone else's. An email arrives asking for a named customer's transaction history, from an address that looks plausible. Fulfil it without verifying identity and you have caused a personal data breach by your own hand. Identity verification is not bureaucratic friction. It is the control that stops the request process from becoming an attack vector.

Where organisations go wrong

Three failures recur. The first is the deadline: requests arrive in a shared inbox, sit unnoticed for three weeks, and the 30 days are gone before anyone has verified identity or gathered the data. The second is the audit trail: the request is handled informally over email and chat, so when the Commissioner asks how you dealt with it, there is nothing to show. The third is identity verification, either skipped, which is a breach in itself, or handled so clumsily it delays a legitimate request past the deadline.

None of these is a knowledge problem. They are process problems, and they are solved with a defined workflow rather than with more effort from busy people.

How PrivaxisOS handles this

The data subject requests module turns the obligation into a controlled workflow. A public request form sits on your website, in Albanian by default, so any person can submit a request without an account. Identity verification confirms the requester is genuine before any data moves. An internal dashboard shows every request, who owns it, what stage it is at, and how many days remain on the legal clock, so the deadline is visible rather than remembered.

Your team can ask for clarification, request further identity evidence, extend the deadline with a recorded justification, or fulfil, reject or exempt the request, each with defined legal grounds, so a partial erasure or a refusal carries its reasoning on the record. A complete timeline logs every action with user, timestamp and notes, while visibility controls keep internal notes private from the requester.

The point is not the software for its own sake. It is that the deadline, the identity check and the audit trail stop depending on somebody remembering, and start being enforced by the system. When the Commissioner asks how you handled a request from eight months ago, the answer is a timestamped record rather than a search through inboxes.

The same discipline scales. One access request is manageable by hand. Twenty concurrent requests, each on its own clock, each at a different stage, each needing a different combination of verification, redaction and legal judgement, are not. A controlled workflow proves its worth precisely when volume rises: a public incident, a marketing campaign that irritates a segment of customers, or a wave of ex-employees exercising erasure at once. That is exactly the moment an inbox-and-memory process collapses.

A short readiness check

Do you have a clear channel for people to submit requests? Can you verify identity before disclosing data? Does someone own each request, with the deadline visible? Do you know which requests you can lawfully refuse, and can you explain the grounds in writing? Could you produce, on demand, a record of how a past request was handled? If any answer is uncertain, the next request is a risk rather than a routine.