The role of the Data Protection Officer was one of the most debated innovations introduced by the General Data Protection Regulation when it came into force in May 2018. Seven years on, the DPO remains one of the most misunderstood elements of GDPR compliance. Many organisations appoint one because they believe they must, without fully understanding what the role demands. Others avoid the appointment altogether, incorrectly believing it does not apply to them.

This article sets out, clearly and practically, what the law requires, and how to decide whether an internal or external DPO model is right for your organisation.

Who Is Required to Appoint a DPO?

GDPR Article 37 identifies three categories of organisation for which a DPO appointment is mandatory:

• Public authorities and public bodies, with the exception of courts acting in their judicial capacity.
• Organisations whose core activities consist of processing operations which require regular and systematic monitoring of data subjects on a large scale — for example, insurance companies, telecoms providers, security firms and digital advertising platforms.
• Organisations whose core activities consist of processing special categories of data on a large scale, including health data, biometric data, data concerning criminal convictions and data revealing racial or ethnic origin.

In practice, the threshold of "large scale" is not defined by a specific number. The EDPB's guidelines on DPOs note that relevant factors include the number of data subjects concerned, the volume of data, the geographical extent of processing and the duration of processing. A regional hospital, a national retail chain with a loyalty programme, or a platform processing behavioural data for tens of thousands of users would typically meet the threshold. A small law firm or a local restaurant would not.

What the DPO Role Actually Requires

This is where many organisations underestimate the complexity of the appointment. Under GDPR Articles 37 to 39, the DPO must:

• Inform and advise the organisation and its employees of their obligations under the GDPR and other data protection law.
• Monitor compliance with the GDPR, other data protection provisions, and the organisation's own internal policies.
• Provide advice where requested and monitor the performance of Data Protection Impact Assessments (DPIAs) under Article 35.
• Cooperate with the supervisory authority — in Belgium, the Gegevensbeschermingsautoriteit (GBA/APD).
• Act as a point of contact for the supervisory authority on all processing-related matters, including prior consultations under Article 36.

Critically, Article 38 requires that the DPO must be provided with sufficient resources to carry out these tasks. They must be able to maintain their expert knowledge, and they must be able to operate independently. The DPO cannot receive instructions regarding the exercise of their tasks, and must not be dismissed or penalised for performing them.

The Case for an Internal DPO

An internal DPO is a member of your own staff appointed to the role. For larger organisations with a significant data processing footprint and the budget to sustain it, an internal appointment has clear advantages.

• Deep institutional knowledge: An internal DPO knows your systems, your culture, your suppliers and your decision-making structures. They can engage with internal stakeholders quickly and credibly.
• Availability: They are present for day-to-day questions, internal meetings and ad hoc operational issues without the friction of engaging an external party.
• Long-term continuity: An internal DPO builds relationships over time and develops a detailed understanding of your data ecosystem that deepens with experience.

However, the internal model carries significant risks that are frequently underestimated. The EDPB has been explicit that conflict of interest is one of the most common compliance failures in DPO appointments. An employee who also holds responsibilities in IT, HR, legal or marketing cannot perform the DPO role independently. Article 38(6) expressly states that the DPO may hold other tasks and duties, but only to the extent that these do not result in a conflict of interest. In practice, this rules out most senior management roles.

There is also the question of expertise. The DPO must have expert knowledge of data protection law and practice. That is a high bar. It requires not just familiarity with the GDPR text, but an ongoing understanding of EDPB guidelines, national supervisory authority decisions, case law from the Court of Justice of the EU, and the operational realities of compliance implementation. Maintaining that knowledge requires continuous professional development and, ideally, direct engagement with the regulatory community.

The Case for an External DPO

GDPR Article 37(6) explicitly permits the DPO function to be fulfilled on the basis of a service contract by a person or organisation outside the controller or processor. This is what is commonly referred to as an external DPO or DPO-as-a-Service model.

• Structural independence: An external provider has no employment relationship with the organisation, eliminating the most common source of conflict of interest. They can advise and challenge without the career risk that can inhibit internal appointees.
• Depth of expertise: A specialist privacy consultancy brings the expertise of a team, not a single individual. Complex questions on DPIA methodology, cross-border transfers, supervisory authority procedures or AI governance can be escalated internally within the provider, ensuring the quality of advice is not limited by one person's knowledge base.
• Cost efficiency: For most small and medium-sized organisations, a full-time senior privacy professional is a significant overhead. An external DPO service provides the same formal compliance and advisory function at a fraction of the cost.
• Regulatory credibility: A DPO service provided by a law firm or specialist compliance practice carries weight with supervisory authorities. In the event of an investigation or inquiry, having a legally qualified DPO on record is a significant advantage.

Making the Right Decision for Your Organisation

The honest answer is that there is no universal right answer. The correct model depends on the size, complexity and sector of your organisation, and on the specific nature of your data processing activities. A large public hospital processing health data of hundreds of thousands of patients has different needs from a 50-person fintech startup processing payment and identity data.

What is non-negotiable, regardless of model, is that the DPO must be genuinely independent, adequately resourced and sufficiently expert. An internal appointment that boxes those requirements is perfectly sound. An external appointment that meets all three is equally valid. What is not acceptable, and what enforcement action increasingly targets, is a nominal appointment that satisfies the letter of Article 37 while failing the substance of Articles 38 and 39.

Ask any compliance officer whether their organisation is GDPR compliant and the answer will almost always be yes. Ask them to walk you through their Records of Processing Activities, show you their data processor agreements, or explain the legal basis for their marketing emails, and the answer frequently becomes far less certain.

This is not a criticism. GDPR compliance is genuinely complex. The regulation consists of 99 articles, 173 recitals and a growing body of guidance from the European Data Protection Board, national supervisory authorities and the Court of Justice of the European Union. The gap between believing you are compliant and demonstrating compliance is, for most organisations, considerable.

A GDPR compliance audit is the structured process of closing that gap. This article explains what a proper audit covers, what the most common findings are, and how to think about prioritising remediation.

The Foundation: The Accountability Principle

Before looking at individual audit areas, it is worth being clear about the legal standard that underpins all of them. GDPR Article 5(2) establishes what is known as the accountability principle: the controller shall be responsible for, and be able to demonstrate compliance with, the principles of Article 5(1).

With this principle in mind, a GDPR audit is essentially an exercise in evidence gathering and gap identification. For each area of the regulation, the auditor asks: do you comply, and can you prove it?

What a GDPR Audit Covers

1. Data Mapping and Records of Processing Activities

Article 30 requires most organisations to maintain Records of Processing Activities (RoPA). The RoPA must document every processing activity, the purpose of the processing, the categories of data subjects and personal data involved, any recipients or transfers, retention periods and, where possible, a description of security measures.

In practice, many organisations either have no RoPA at all, or have one that was created several years ago and never updated. A data mapping exercise at the start of an audit frequently reveals processing activities that no one in the organisation is fully aware of, data flows to third-party processors that are not documented, and retention practices that bear no relation to any written policy.

2. Legal Bases for Processing

Every processing activity requires a valid legal basis under Article 6. The six legal bases are: consent, contract, legal obligation, vital interests, public task and legitimate interests. The choice of legal basis is not arbitrary. It determines the rights available to data subjects, the conditions that must be met, and the organisation's exposure if processing is challenged.

Common issues found in audit include: reliance on consent for processing where contract or legitimate interests would be more appropriate and easier to maintain; consent mechanisms that do not meet the Article 7 standard of freely given, specific, informed and unambiguous; and processing activities for which no legal basis has been identified at all.

3. Privacy Notices and Transparency

Articles 13 and 14 set out extensive requirements for the information that must be provided to data subjects at the point of collection or, for indirectly obtained data, within one month of collection. The list includes the identity of the controller, the purposes and legal bases for processing, retention periods, data subject rights and the right to lodge a complaint with the supervisory authority.

In audit, privacy notices are one of the most frequently deficient areas. Common problems include: notices that are copied from templates and do not accurately reflect actual processing; notices that list a legal basis of "consent" for processing that is actually carried out on a different basis; and notices that have not been updated following changes to processing activities or regulatory guidance.

4. Data Processor Agreements

Article 28 requires that any engagement of a processor — any third party that processes personal data on behalf of the controller — must be governed by a contract or other legal act that contains the mandatory clauses set out in Article 28(3). This includes cloud providers, payroll processors, marketing platforms, IT service providers, accountants and any other third party with access to personal data.

The audit finding here is almost always the same: many processor relationships exist without any compliant agreement in place. The processor may have provided their own terms of service, which rarely meet Article 28 requirements. Or the relationship may have no data-specific terms at all.

5. Data Subject Rights

Chapter III of the GDPR grants data subjects a comprehensive set of rights: access, rectification, erasure, restriction, data portability, objection, and rights related to automated decision-making. Each of these rights has specific conditions and timeframes. Subject access requests, for example, must be responded to within one month, extendable by two further months for complex cases.

Audit findings in this area typically include: no documented process for receiving and handling rights requests; no log of requests received; staff who are unaware of how to handle a request when it arrives; and, in some cases, past requests that were not handled correctly.

6. Security Measures

Article 32 requires the implementation of appropriate technical and organisational measures to ensure a level of security appropriate to the risk. This is not a prescriptive standard — it requires a risk-based assessment. Relevant measures include encryption, pseudonymisation, access controls, data minimisation, resilience of systems, and the ability to restore data availability following an incident.

7. Data Retention

The storage limitation principle in Article 5(1)(e) requires that personal data is kept in a form that permits identification of data subjects for no longer than is necessary for the purposes of processing. In audit, the absence of a documented retention policy, or a policy that exists on paper but is not enforced in practice, is among the most common findings across all sectors.

8. Breach Response Procedures

Articles 33 and 34 require prompt notification of reportable breaches to the supervisory authority (within 72 hours) and to affected individuals (without undue delay). Having these obligations met in practice requires a documented breach response procedure, awareness training for staff, and a clear escalation path. Most organisations, when asked, have none of these.

Every week, somewhere in Europe, an individual writes to their bank, their employer, their health insurer or their social media platform and asks a simple question: what data do you hold about me? Under GDPR Article 15, that question triggers a legal obligation. The organisation must respond, within one month, with a copy of the personal data being processed, together with a substantial list of accompanying information.

In theory, the right of access is one of the clearest and best-defined rights in the GDPR. In practice, it is one of the most frequently mishandled. Supervisory authorities across the EU consistently report that failure to respond to access requests, or responding inadequately or late, is one of the top categories of individual complaint. The Belgian GBA/APD is no exception.

This article sets out what Article 15 requires, the most common mistakes organisations make, and the practical steps to build a compliant access request procedure.

What Article 15 Actually Requires

The right of access under Article 15 gives a data subject the right to obtain from the controller confirmation of whether or not personal data concerning them is being processed and, where that is the case, access to the personal data and the following information:

• The purposes of the processing.
• The categories of personal data concerned.
• The recipients or categories of recipient to whom the data has been or will be disclosed.
• Where possible, the envisaged period for which the data will be stored, or the criteria used to determine that period.
• The existence of the right to request rectification, erasure, restriction or to object to processing.
• The right to lodge a complaint with a supervisory authority.
• Where the data was not collected directly from the data subject, any available information about its source.
• The existence of any automated decision-making, including profiling, and meaningful information about the logic involved and the significance and envisaged consequences.

Who Can Make an Access Request?

Any natural person whose personal data is being processed by your organisation can make an access request. This includes current employees, former employees, job applicants, customers, former customers, website visitors, newsletter subscribers, and any other individual about whom you hold data. Requests can be made verbally or in writing, formally or informally. There is no prescribed format under GDPR.

An organisation may not refuse a request on the basis that it was not made using their designated form or channel, though they may ask the data subject to use a specific channel where this makes it easier to identify them and locate their data.

The One-Month Deadline

Article 12(3) requires a response to a data subject request without undue delay and in any event within one month of receipt. This period can be extended by a further two months where the request is complex or where a large number of requests have been received. If you extend, you must notify the data subject within the first month, explaining the reason for the delay.

The clock starts running from the day the request is received, not from the day you acknowledge it, not from the day the data subject provides identification, and not from the day the request lands in the right inbox. Organisations that have no internal procedure for routing and tracking access requests are constantly at risk of missing this deadline.

Identifying the Data Subject

Before responding, an organisation may take reasonable steps to verify the identity of the requester. Article 12(6) permits this where there are reasonable doubts about the identity of the natural person making the request. However, this is a proportionality test. Asking a long-standing customer who emails from their registered account for extensive identity documentation is unlikely to be proportionate. Asking someone who provides only a name and claims to be a former employee for some form of verification is entirely reasonable.

Organisations should not use identity verification as a delaying tactic. The EDPB has been clear that verification requests must be proportionate to the circumstances and must not create unnecessary barriers to exercising rights.

The Most Common Mistakes

• Missing the deadline. The one-month clock is absolute. Missing it, even by a day, without having invoked the extension procedure, is a breach of Article 12.
• Providing incomplete data. Organisations frequently overlook data held in email archives, backup systems, or by third-party processors acting on their behalf. The obligation is to provide all personal data you hold, not just what is in your primary database.
• Charging a fee. Article 12(5) requires responses to be provided free of charge. A fee may only be charged where requests are manifestly unfounded or excessive, and even then only after careful consideration.
• Refusing requests on the basis of internal policies. A data subject's right of access cannot be refused because it is inconvenient, because the request is broad, or because internal policies do not anticipate it. The grounds for refusing or limiting access are strictly defined in Article 23 and in specific legislative provisions.
• No internal process. Without a documented procedure, a designated inbox, an internal log of requests, and staff training, organisations will handle requests inconsistently and will frequently miss deadlines.

Third-Party Data and the Rights of Others

A common complication arises where the data being accessed contains information about third parties. For example, an employee's subject access request may include emails in which colleagues are mentioned. Article 15 does not override the rights of other individuals. An organisation may redact information about third parties where providing it would involve disclosing their personal data, provided the redaction does not make the response so limited as to be meaningless.

At 11:47 on a Tuesday morning, your IT team discovers that customer data has been exfiltrated from your CRM system. The attacker has had access since Friday. By the time the incident is confirmed, you have approximately 60 hours left before your notification deadline under GDPR Article 33 expires.

This scenario, or some variation of it, plays out hundreds of times across Europe every month. How an organisation responds in those first hours determines its legal exposure, its relationship with the supervisory authority and, ultimately, whether the incident becomes a headline.

This article provides a clear, practical guide to GDPR breach response. It is written for the people who will actually manage the response: senior management, legal counsel, IT leads and DPOs.

The Legal Framework: Articles 33 and 34

GDPR Article 33 requires that, in the event of a personal data breach, the controller must notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

Article 34 adds a second obligation: where a breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller must also communicate the breach to the affected individuals without undue delay. This is a higher threshold than Article 33, but it applies more often than many organisations expect.

Step One: Contain and Assess (Hours 0 to 6)

The first priority is containment — stopping the breach from getting worse. Depending on the nature of the incident, this may mean taking a system offline, resetting credentials, revoking access tokens, or isolating a network segment. Speed matters, but not at the expense of forensic integrity. Where possible, preserve logs and evidence before making changes to affected systems.

Simultaneously, begin a factual assessment. What data was affected? Which systems? How many individuals? Was the data encrypted? What is the likely cause? You do not need complete answers at this stage — you need enough information to make a preliminary risk assessment.

Step Two: Risk Assessment (Hours 6 to 24)

Not every personal data breach triggers a notification obligation. Article 33 applies only where the breach is likely to result in a risk to the rights and freedoms of natural persons. The EDPB's guidelines on data breach notification identify the key risk factors:

• Type of breach: confidentiality breach (unauthorised access or disclosure), integrity breach (unauthorised alteration), or availability breach (accidental loss or destruction).
• Nature of data: special categories of data (health, financial, identity documents, passwords, data of vulnerable individuals) carry significantly higher risk.
• Number of individuals affected: scale matters, but a small breach involving highly sensitive data may carry higher risk than a large breach involving low-sensitivity data.
• Ease of identification: encrypted or pseudonymised data that cannot reasonably be attributed to individuals carries lower risk.
• Consequences for individuals: could the breach lead to identity theft, financial loss, discrimination, damage to reputation or physical harm?

Step Three: Notify the GBA/APD (By Hour 72)

If your risk assessment concludes that the breach is likely to result in a risk, you must notify the Belgian Data Protection Authority (GBA/APD) by completing the notification form available on their website. The notification must include, to the extent possible:

• A description of the nature of the breach, including categories and approximate number of data subjects and records affected.
• The name and contact details of the DPO or other point of contact.
• A description of the likely consequences of the breach.
• A description of the measures taken or proposed to address the breach, including mitigation measures.

Article 33(4) permits the notification to be provided in phases where it is not possible to provide all information at the same time. In practice, the GBA/APD expects an initial notification within 72 hours even if incomplete, followed by supplementary information as the investigation progresses. Do not wait for a complete picture before notifying — partial information submitted on time is far better than complete information submitted late.

Step Four: Individual Notification (Where Required)

Where the breach is likely to result in a high risk to individuals, Article 34 requires you to notify those individuals directly. The communication must be in clear and plain language, describe the nature of the breach, include the contact details of the DPO, describe the likely consequences, and describe the measures taken or proposed to address the breach and mitigate its possible adverse effects.

The obligation to notify individuals can be waived in three circumstances: the data was subject to appropriate technical protection measures (encryption, for example) that render it unintelligible; subsequent measures have been taken to eliminate the risk; or individual notification would involve disproportionate effort, in which case a public communication may be acceptable. The last exception is genuinely exceptional.

Step Five: Internal Documentation

Article 33(5) requires every data breach to be documented, regardless of whether external notification was required. The documentation must include the facts of the breach, its effects and the remedial action taken. This is not optional, and it is not limited to reportable breaches. A breach that did not require notification still requires documentation.

There is almost no large organisation in Europe today that is not using artificial intelligence in some form. The use cases range from the mundane — email filtering, customer service chatbots, spell-checking tools — to the consequential: automated credit scoring, AI-driven hiring tools, medical diagnostic support systems, and large language models processing sensitive client communications.

What most of these organisations have in common is that their AI deployment decisions have been made primarily by technology and commercial teams, with legal and compliance functions brought in late, if at all. The result is a growing gap between what companies are doing with AI and what GDPR requires them to do.

This article sets out the primary GDPR obligations that apply to AI use, the specific issues raised by large language models, and the emerging interaction with the EU AI Act.

The Core Problem: AI Processes Personal Data

The starting point is deceptively simple. Any time an AI system processes personal data — data that directly or indirectly identifies a living natural person — the GDPR applies in full. There is no AI exception, no technology exemption, and no minimum scale threshold for most of the regulation's core obligations.

For most companies, this means that a significant proportion of their AI use cases involve personal data. Customer service chatbots log interactions that contain names, account details and health information. HR automation tools process CVs, performance reviews and payroll data. Marketing AI analyses behavioural data tied to identifiable users. LLMs are being given access to client files, internal communications and confidential business information.

Legal Basis for AI Processing

Every processing activity carried out by an AI system requires a valid legal basis under Article 6. The most common approach — relying on legitimate interests under Article 6(1)(f) — is not automatically available. It requires a genuine balancing test, weighing the controller's interests against the data subject's rights and expectations. Where that test has not been conducted, the processing lacks a valid legal basis.

Consent is an option, but a difficult one in many AI contexts. For consent to be valid under Article 7, it must be freely given, specific, informed and unambiguous. Broadly worded terms of service provisions that include hidden consent to AI processing do not meet this standard. The EDPB and multiple national supervisory authorities have rejected this approach in enforcement decisions.

Automated Decision-Making and Article 22

Article 22 of the GDPR creates specific protections around automated decision-making, including profiling, where the decision produces legal effects or similarly significant effects on the data subject. This provision is directly relevant to AI use cases including automated credit decisions, automated recruitment screening that determines whether a candidate progresses, insurance pricing algorithms, and fraud detection systems that result in account restrictions.

Where Article 22 applies, the data subject has the right not to be subject to the decision, the right to obtain human intervention, the right to express their point of view, and the right to contest the decision. The controller must also provide meaningful information about the logic involved and the significance and envisaged consequences of the processing — requirements that are frequently not met in practice.

Data Protection Impact Assessments for AI

Article 35 requires a DPIA before any processing that is likely to result in high risk to individuals. The EDPB has confirmed that AI systems that use personal data for profiling, automated decision-making, large-scale processing or the processing of sensitive data will typically require a DPIA.

A DPIA for an AI system must address not only the standard GDPR risk factors but also AI-specific risks: algorithmic bias and discriminatory outputs, opaqueness of decision logic, data quality issues affecting the accuracy of outputs, risks arising from model drift over time, and the possibility of re-identification from model outputs. These are not hypothetical risks. They have been the basis of enforcement action by the GBA/APD and other EU authorities.

Using Third-Party AI Tools: The Processor Question

When a company uses an AI tool provided by a third party — whether a general-purpose LLM like those from OpenAI, Anthropic or Google, or a sector-specific AI platform — and personal data is processed through that tool, the third-party provider is typically acting as a data processor under Article 28. This means a GDPR-compliant Data Processing Agreement must be in place before any personal data is shared with the tool.

In practice, many companies are routing client communications, HR data or financial information through AI tools without having reviewed the provider's data processing terms, without having determined where data is processed and stored, and without having assessed whether cross-border transfer mechanisms are in place. Each of these failures creates direct legal exposure.

The EU AI Act: The Emerging Layer

The EU AI Act, which entered into force in August 2024, adds a parallel regulatory layer to AI governance. While the AI Act and the GDPR operate independently, they interact closely, particularly in the context of high-risk AI systems as defined in Annex III of the Act. High-risk AI systems include those used in employment decisions, credit scoring, biometric identification and law enforcement.

For organisations operating in Belgium and the EU, compliance now increasingly requires a dual analysis: GDPR compliance for the data processing dimension, and AI Act compliance for the system governance, transparency and conformity assessment dimension. DPIAs under GDPR and fundamental rights impact assessments under the AI Act are distinct but overlapping exercises.

Every day, banks make decisions about who they will do business with. They approve accounts, reject applications, close existing relationships, and restrict access to financial services. Many of these decisions are not based on the bank's own assessment of the customer. They are based on data obtained from third-party risk intelligence providers.

These providers — Refinitiv World-Check, Dow Jones Risk and Compliance, LexisNexis Risk Solutions, ComplyAdvantage, and others — maintain vast databases of individuals and entities flagged as potential risks for money laundering, terrorism financing, fraud, sanctions violations and other financial crimes. Financial institutions subscribe to these databases as part of their AML and KYC (Know Your Customer) compliance programmes.

The problem is that these databases contain errors. They contain outdated information. They contain information about individuals who have never been convicted of anything, who appeared in a media article years ago that was later retracted, or who share a name with someone who has. And in many cases, the individuals concerned have no idea that a record about them exists, or that it is the reason their bank account was closed.

How Risk Databases Affect Real People

The consequences of appearing in a risk database can be severe and wide-ranging. Banks, payment processors, law firms, insurance companies and other regulated entities conduct database checks as part of their onboarding and ongoing monitoring. A hit — even a potential match, even a false positive — can result in:

• Refusal to open a bank account or close an existing one.
• Termination of a business relationship without explanation.
• Delays or rejections in payment processing.
• Refusal of insurance, credit or other financial products.
• Difficulties obtaining legal representation (some law firms screen clients against these databases).
• Reputational damage if the existence of a record becomes known.

The GDPR Framework Applied to Risk Databases

Risk database providers who maintain records about EU data subjects are data controllers under the GDPR, regardless of where the provider is based. If they offer services to EU-based subscribers (banks, financial institutions, regulated entities operating in the EU), they process personal data within the scope of the GDPR by virtue of Article 3(2), the territorial scope provision.

This means that individuals appearing in these databases hold the full suite of GDPR rights against the database provider, including the right to know whether a record exists, the right to access that record, the right to correct inaccurate information, the right to erasure in appropriate circumstances, and the right to object to processing.

Your Right of Access Against Risk Database Providers

Under GDPR Article 15, you have the right to ask any risk database provider whether they hold data about you and, if so, to receive a copy of that data. The right applies regardless of how the provider obtained the data, regardless of what it says, and regardless of whether you have any direct relationship with the company.

Exercising this right requires knowing which database to approach. This is itself a challenge, because banks and financial institutions are generally not required to tell you which databases they have consulted. However, there are practical approaches: you can make a data subject access request to your bank asking them to identify the specific sources and providers they used in making the decision affecting you. The bank's response may not always be complete, but it provides a starting point.

Once you have identified the relevant database, submit a formal Article 15 request to the provider. Major providers have designated procedures for this. They are required to respond within one month.

The Right to Rectification and Erasure

If a risk database record is inaccurate, incomplete or no longer current, Article 16 gives you the right to demand rectification. If the processing of your data lacks a valid legal basis, or if the data is no longer necessary for the purpose for which it was collected, Article 17 gives you the right to demand erasure.

These rights are not absolute. Risk database providers typically rely on legitimate interests under Article 6(1)(f) as their legal basis, arguing that the prevention of financial crime is a compelling legitimate interest. This is a defensible position in principle, but it does not justify maintaining inaccurate data, does not justify retaining data indefinitely, and does not override the interests and rights of individuals where the data quality is poor.

Challenging Automated Decisions Based on Database Hits

Where a financial institution has made an automated or semi-automated decision based on a database hit — for example, using an automated AML screening system that flags your name and triggers an account closure — Article 22 may apply. The right to human review of automated decisions, the right to express your point of view, and the right to contest the decision are all potentially relevant.

In practice, banks often resist acknowledging that their decisions involve automated processing. They describe the process as involving human review, while in reality the human review is of limited scope and the automated system's output is rarely overridden. The EDPB and multiple national authorities have challenged this characterisation.

Filing a Complaint with the GBA/APD

If a risk database provider fails to respond to your access or rectification request, refuses to correct inaccurate data without adequate justification, or if a financial institution has made a decision based on inaccurate or unlawfully processed data and refuses to remedy the situation, you have the right to file a complaint with the Belgian Data Protection Authority under GDPR Article 77.

The GBA/APD has jurisdiction over controllers and processors established in Belgium and can investigate and take enforcement action. For controllers based in other EU member states, the one-stop-shop mechanism under Article 56 applies, and the GBA/APD can act as a concerned supervisory authority.