Most organisations underestimate how much of their personal data lives outside their own four walls. The payroll bureau holds every employee's salary, bank account and family details. The cloud host stores the database. The CRM carries the entire customer list. The email platform has every subscriber's address and behaviour. The support desk captures whatever customers type when they are frustrated, sometimes including ID numbers, health complaints or payment details they should never have sent. Each of those vendors processes personal data on your behalf, and under Law 124/2024 handing them the data does not hand them the responsibility.
This is the point most managers get wrong. They assume that once the data is with a professional supplier, the supplier owns the risk. The law says the opposite. You remain the controller, the party that decides why and how the data is processed, and the vendor is your processor, acting on your instructions. If your processor loses the data, leaks it, uses it for its own purposes, or sends it somewhere it should not go, the exposure lands on you. You chose them, you instructed them, and you answer for them.
What the law requires
When you engage a processor, the relationship must be governed by a written processing agreement. Article 26 of Law 124/2024 sets out what that agreement must contain, with nine mandatory clauses at Art. 26(3). It is the Albanian equivalent of Art. 28 of the GDPR, and the numbering is worth pausing on: material written for a GDPR audience routinely cites Article 28, which under Albanian law governs security of processing instead.
The agreement has to do real work. A defensible one sets out, at a minimum:
- The scope of processing: the subject matter, purpose, duration and nature of the operations, and the categories of personal data and of data subjects involved. An agreement that could describe any vendor is describing none of them properly.
- Processing only on documented instructions. The processor acts on your instructions and does not decide on its own to repurpose, mine, enrich or monetise the data.
- Confidentiality. Everyone the processor authorises to touch the data is bound to it.
- Security measures proportionate to the risk. Promises to take security seriously are not measures; encryption, access controls, logging and backup discipline are.
- Sub-processor control. The processor may not bring in a sub-processor without your authorisation, must flow the same obligations down by contract, and remains liable to you for what that sub-processor does.
- Assistance with data subject rights, because the data you need to answer an access or erasure request is often sitting in the processor's system rather than yours.
- Assistance with your own obligations: security, breach notification, impact assessments and prior consultation, again because the processor holds facts you cannot see.
- Breach notification to you without undue delay, so that your own 72-hour clock under Art. 29 can start on time.
- Deletion or return at the end of the engagement, at your choice, including existing copies unless the law requires retention.
- Audit and demonstrability. The processor makes available what you need to show compliance, and submits to audits you or an auditor you mandate carry out.
Two further duties sit around the contract. You must carry out due diligence before engaging a vendor, because the law expects you to use only processors offering sufficient guarantees, and sufficient is something you check rather than assume. Proportionate diligence means looking at security posture, certifications and track record, the sub-processor chain, where data is stored and routed, and whether the vendor has suffered a breach. A payroll bureau handling salary and family data warrants harder questions than a tool that sees only a mailing list.
And where a processor sits abroad, or routes data abroad, the transfer needs its own lawful basis under Arts. 39-42, the Albanian equivalent of GDPR Arts. 44-49. Where the destination is covered by the Commissioner's adequacy decision the transfer rests on that; otherwise you need appropriate safeguards such as standard contractual clauses or another legally recognised mechanism.
The transfer question you cannot skip
Most Albanian organisations use at least one processor whose servers, support desk or sub-processors sit outside the country: a global cloud provider, a US email platform, a helpdesk routed through the EU or India. That is not forbidden, but it is not free either. Every cross-border flow needs a basis for the transfer itself, layered on top of the processing agreement.
In practice that means identifying, for each vendor, where the data actually goes, including where the sub-processors sit, which mechanism covers the transfer, and whether that mechanism is genuinely in place rather than named in a policy nobody signed. A CRM that quietly replicates data to a data centre on another continent, with no documented safeguard, is a gap even if the contract looks tidy. The uncomfortable part is that the transfer question is usually answered by the vendor's architecture rather than by your intentions, so you have to go and look.
Why this is easy to get caught on
An inspector does not need forensic tools to test this. They ask for the list of vendors that handle personal data, then ask to see the processing agreement for each one. What surfaces is predictable: a payroll relationship running for years on a service contract that never mentions data protection; a marketing platform onboarded by the marketing team with click-through terms nobody in legal read; a support tool whose sub-processors were never authorised because nobody knew they existed; a cloud host sending data abroad with no transfer mechanism anyone can point to.
The deeper problem underneath all of it is simply knowing who your processors are. Vendors get onboarded by different teams. HR signs the payroll bureau, marketing signs the email tool, IT signs the cloud host, support signs the ticketing platform. The contracts sit in different drives and inboxes, nobody holds the complete picture, and you cannot govern a relationship you have never inventoried. This is why the register comes first: the contract, the due diligence and the transfer analysis are all downstream of knowing the vendor exists.
How PrivaxisOS handles this
The processor register gives you one place to inventory every vendor and sub-processor that touches personal data, with the details that actually get tested: what they process, under which agreement, with what security, and whether data crosses borders and under what safeguard.
It connects to the vendor risk assessment, so due diligence is recorded rather than assumed. You can show that you checked a vendor before signing, and what you found, instead of hoping the file exists. It connects to clause tracking, so the terms of each agreement are captured and visible. You can see at a glance which contracts carry sub-processor controls, breach-notification duties and deletion terms, and which are missing them, rather than re-reading a signed PDF nobody has opened since the day it was executed.
And because the register links back to the ROPA, a processor is never an orphan record. You can see which processing activities each vendor supports, so an unused vendor or an undocumented data flow stands out instead of hiding. When someone asks who has your data and on what terms, the answer is a report rather than a search, and one you can defend clause by clause.
A short readiness check
Do you have a complete list of vendors that process personal data for you, across every team that buys tools? Does each one have a current agreement that reflects the Art. 26(3) clauses rather than a generic service contract? Did you assess each vendor before signing, and can you show it? Do you know which vendors send data abroad, and their sub-processors too, and under exactly which mechanism? Are sub-processors authorised and accounted for, or did they arrive by default? If any answer is "not sure", that vendor is an unmanaged risk sitting on your data right now.