Most obligations under Law 124/2024 are about keeping an honest record of what you already do. The impact assessment is different in kind. It asks you to stop before you launch something risky, work out whether it is safe, and write the answer down. That order matters. When the Commissioner examines a high-risk activity after the fact, the first question is rarely "was your system flawless?" It is "did you assess the risk before you started, and can you put the assessment in front of me?" An organisation that can answer yes is in a fundamentally stronger position than one that merely got lucky.

What Article 31 requires, and when it is triggered

Article 31 of Law 124/2024 requires a data protection impact assessment before processing that is likely to result in a high risk to individuals. It is the Albanian equivalent of Article 35 of the GDPR. The assessment must describe the processing, evaluate the likelihood and severity of the risks to data subjects, and document the technical and organisational measures that reduce those risks to an acceptable level.

The practical difficulty is not the concept but the trigger: how do you know a given activity is high-risk? You will not always have a definitive answer, but the following are the classic indicators, and each on its own is usually enough to justify an assessment:

  • Profiling and automated decision-making. Scoring, ranking or predicting behaviour - creditworthiness, performance, health, reliability - especially where it feeds a decision that affects the person.
  • Large-scale processing of special category data. Health, biometric, religious, political or trade union data processed at volume: a clinic, an insurer, an HR function that records sickness absence.
  • Systematic monitoring. Continuous or repeated observation of people, particularly in a space they cannot easily avoid: workplace monitoring, location tracking, or CCTV covering public or semi-public areas.
  • A new HR system. Onboarding a platform that centralises employee records, performance data and possibly monitoring features touches several triggers at once.
  • New technologies or novel combinations of data whose effects on individuals are not yet well understood.
  • International transfers to a destination not covered by the Commissioner's adequacy decision, where the protection travelling with the data is uncertain.

If two or more are present, treat the assessment as effectively mandatory and stop debating it. If one is present, the safe and cheap move is to run it anyway and record why the risk turned out to be manageable. An assessment that concludes "low risk, no further action" is still worth having, because it proves you looked.

The family of assessments

The impact assessment is the one the law names, but it is not the only review a serious programme runs. The others address adjacent risks and often feed into, or fall out of, a DPIA.

  • DPIA, data protection impact assessment. Use it when processing is likely to be high-risk under Article 31: profiling, large-scale special category data, systematic monitoring, a major new system, or a risky transfer.
  • PIA, privacy impact assessment. Use it when an activity has a privacy dimension worth reviewing but does not clearly cross the Article 31 threshold. A lighter check that can escalate into a full DPIA if the risk turns out higher than expected.
  • VRA, vendor risk assessment. Use it before you hand personal data to a processor, to test their security, sub-processing, location and contractual guarantees - before you sign.
  • TIA, transfer impact assessment. Use it when personal data will leave Albania for a destination outside the adequacy perimeter, to check whether the safeguards actually protect the data.
  • SRA, security risk assessment. Use it to evaluate the controls around a system or process - access, encryption, resilience, incident response - often as the security backbone a DPIA relies on.

These are not competing forms. In a single project they stack: a new HR platform hosted abroad might need a DPIA for the processing itself, a VRA on the vendor, a TIA for the hosting location, and an SRA on the controls. Running them as linked pieces rather than four disconnected exercises is what turns compliance from theatre into a coherent risk picture.

A worked example: a new HR system

Suppose an organisation is replacing spreadsheets and shared drives with a single cloud HR platform. It will hold contact details, contracts, payroll, performance reviews, sickness absence records and a leave module. The vendor is EU-based and the data is hosted outside Albania.

The assessment moves through recognisable stages. Describe the processing: what data, whose, for what purpose, on what legal basis, kept for how long, shared with whom. Assess necessity and proportionality: does the payroll module really need to store the reason for a sickness absence, or only its duration? Trim what you cannot justify. Identify the risks: unauthorised internal access to sensitive records; the special category nature of health data; the transfer to the hosting location; the monitoring features some HR platforms bundle in. Document the mitigations: role-based access so a line manager sees leave dates but not medical detail; encryption at rest and in transit; a processing agreement with the vendor meeting Article 26(3), the Albanian equivalent of GDPR Article 28(3); a transfer assessment; retention rules that purge leaver records on schedule. Reach a conclusion: with these measures the residual risk is medium and acceptable.

Notice what the assessment produced beyond a yes or no. It forced HR to justify collecting the sickness reason and quietly killed a needless data point. It surfaced the transfer question early enough to solve it in the contract rather than after launch. And it left a dated record showing exactly who decided what. That is the assessment doing its real job.

Assessment as evidence, not paperwork

A persistent misconception is that an assessment is a form to complete and file. Its real value is evidential. Two organisations can make the identical decision, deploy the same system, and one is defensible while the other is exposed, purely because one wrote down the risk analysis and the mitigations and the other kept it in someone's head. Accountability under Law 124/2024 is not only doing the right thing; it is being able to demonstrate that you did, on a date, with reasons.

There is a second reason the documentation is the point: assessments are collaborative. A DPIA on the HR system above genuinely needs input from HR on what data and why, from IT on where it lives and who can reach it, and from security on how it is protected. Gather that across scattered emails and a shared document nobody owns, and it evaporates the moment you need it. Capture it in one structured record and you get two things at once: a better analysis, because the right people actually answered, and a defensible file, because the record shows they did.

When the risk stays high: prior consultation

Most assessments end inside the organisation. The risks are identified, mitigations bring them to an acceptable level, and the processing proceeds on the strength of a documented decision. Article 32, the Albanian equivalent of GDPR Article 36, anticipates the harder case: where the assessment shows that residual risk remains high even after mitigation, the route is prior consultation with the Commissioner before going live rather than launching and hoping.

Two things follow. First, this is a reason to run the assessment early, long enough before launch that a consultation does not derail the timeline. Second, the quality of your documentation is exactly what a consultation turns on. You are showing the regulator that you understood the risk and did everything reasonable to contain it. A thin, boilerplate assessment is a weak position in that conversation; a thorough, honest one is a strong one.

Note that the impact assessment duty and prior consultation sit among the provisions deferred to January 2027. That is not a reason to wait. The processing they govern is happening now, the risks are real now, and an organisation that starts building the habit in 2027 will be assessing systems it deployed years earlier.

How PrivaxisOS handles this

The assessments module supports five types out of the box - DPIA, PIA, VRA, TIA and SRA - each built from a customisable template so the questions match your reality rather than a generic checklist. An assessment can be assigned to the right people, the IT lead, the business owner, the security team, who answer their own sections while the platform saves progress, so the collaborative input the analysis depends on lands in one place instead of a dozen inboxes.

The DPO reviews the consolidated responses, the platform calculates a risk level, and the result is a documented record, dated and attributed, ready to show a regulator. Because assessments link to the same processing activities recorded in the ROPA and the vendors in the processor register, the analysis sits in context: an assessment of the HR system points to the register entry it concerns and the vendor review behind it, rather than floating as an isolated document.

The outcome is simple but decisive. "We assessed the risk" stops being a claim and becomes a file with a date, named contributors, and a conclusion.

A short readiness check

Do you know which of your activities count as high-risk under Article 31, and can you name them? Do you run the assessment before you launch rather than after the fact? Is the analysis actually written down, showing who contributed and what was decided? Could you produce a completed assessment today if the Commissioner asked about one specific system? And when residual risk stays high, do you know that prior consultation is the route rather than a quiet launch? If your assessments live only in conversation, they will not survive scrutiny.