Data protection law

Introduction
Belgian data protection legislation is largely based on European General Data Protection Regulation (GDPR), which has been applicable across the EU since May 25, 2018. The AVG (called GDPR in English) has fundamentally reformed privacy rules and imposes stricter obligations on organizations, with potentially heavy fines for non-compliance (up to €20 million or 4% of global turnover).

In Belgium, the AVG is supplemented by the national Act of July 30, 2018 on the protection of natural persons in the processing of personal data. Monitoring and enforcement are done by the Data Protection Authority (GBA), Belgium's independent privacy regulator. The GBA can conduct investigations and impose sanctions ranging from warnings and reprimands to administrative fines. (Note that under the AVG, government agencies may be exempt from direct fines by the member state - in Belgium, governments are generally not fined, although other measures may be taken.

It is therefore crucial for companies and organizations to understand and comply with data protection rules. Below, we discuss key aspects of Belgian data protection law. The goal is to provide both legal interpretation and practical guidance so that organizations better understand what is expected of them and how to be compliant with privacy rules in Belgium.

AVG: Scope (personnel, material and territorial)

The General Data Protection Regulation (GDPR) has a very broad scope. We distinguish the material, the personal and the territorial scope:

• Material scope: The AVG applies to virtually all processing of personal data. A processing operation is any operation or handling with personal data, automated or manual, such as the collection, storage, access, use, sharing or deletion of data. Exceptions exist for purely personal or household activities (e.g., a private address book) - these fall outside the AVG. Certain sectors also have their own rules: for example, the processing of personal data for justice and police (criminal investigation) outside the AVG and under specific legislation (the so-called LED legislation). In practice, this means that as soon as a company or organization processes data traceable to an individual, the AVG applies.
• Staff (or personal) scope: The AVG addresses processors and processors. Simply put: any organization (company, association, government) or person who determines the purpose and means of data processing is a data controller and must follow the AVG standards. Even if you process data on behalf of someone else (you are then a processor), obligations apply. The rules protect the rights of involved, being the living natural persons to whom the data belongs. It does not include data of deceased persons or anonymous data. The AVG applies to both private companies and government agencies. (As noted above, governments may be exempt from fines, but not from compliance obligations.) In short, regardless of size or sector: if your organization processes personal data (of customers, employees, members, citizens, etc.), you are covered by the AVG.
• Territorial scope: The AVG has a broad geographical scope. All organizations based in the EU must comply with the AVG for all processing in the course of their activities, even if the actual data processing takes place outside the EU. Moreover, the AVG also binds organizations without an EU establishment if they target the European market. In concrete terms: a company outside the EU that offers goods or services to persons in Belgium (or the EU) or that monitors the behavior of EU residents (e.g., via online tracking) still falls under the AVG. This so-called "extraterritorial" effect ensures that, for example, U.S. tech companies must respect European privacy rules when working with EU citizens' data. In Belgium, the GBA is competent as the lead regulator in such a case if the company has its EU headquarters here. For example, the GBA received an international complaint against IAB Europe (an industry association) about their ad-consent system - since IAB Europe is based in Belgium, the GBA had to handle the case, despite its cross-border nature. This shows that internationally operating organizations are also subject to Belgian/EU privacy rules once they process data of Belgian/EU data subjects.

Practical importance: For Belgian organizations, this means that the AVG almost always comes into play as soon as personal data is handled. Even small SMEs, NPOs or liberal professionals have to follow the basic rules (unless it is really for private use). Foreign companies that have Belgian customers must take Belgian/EU rules into account. The territorial scope combined with cooperation between EU supervisors (the "one-stop-shop mechanism") ensures that compliance matters globally. So always check whether your data processing operations fall within the scope of the AVG - in most cases they do.

Basic concepts of data protection law

An understanding of some key concepts in the AVG is essential:

• Personal data: This is any information relating to an identified or identifiable natural person. The term is very broad. It includes not only obvious data such as name, address, e-mail address, phone number or national registration number, but also data such as IP addresses, location data, images (photographs, CCTV recordings), and even information that can be indirectly traced to someone. Identifiable means that a person can be identified directly or by combining data. Even a unique characteristic such as a customer number or license plate can constitute personal data if an individual person can be linked to it. Note that pseudonymous data (where names are replaced by codes) also fall under personal data as long as re-identification remains possible. On the other hand, real anonymous data (not traceable to an individual) and data of deceased persons are not personal data under the AVG. In addition, the AVG distinguishes special categories of personal data: sensitive info such as health data, racial or ethnic origin, political views, religion, union membership, genetic and biometric data, sexual orientation, etc. Stricter rules apply to such sensitive data (processing is in principle prohibited unless specific conditions are met - we will come back to this under legal grounds).
• Processing of personal data: An data processing is any operation or set of operations involving personal data. This includes virtually everything you can do with data: from collecting and recording, to organizing, updating, accessing, using, providing (transmitting), combining, securing and ultimately erasing or destroying data. The concept is technology neutral - it does not matter whether the processing is automated (e.g., in a computer system) or manual in a structured archive. Thus, virtually any handling of personal data within an organization is processing within the meaning of the AVG.
• Concerned: The natural person whose personal data are being processed is what the AVG calls the concerned. This is the individual around whom the data revolves - e.g., the customer, employee, patient, student, citizen, etc. Under the AVG, the data subject has several rights (see below) to maintain control over his/her data.
• Controller: This is the Party that determines the purpose ("why") and means ("how") of processing. Often this is an organization or company - for example, a web shop that collects customer data to ship orders, or an employer that processes employee personal data for payroll purposes. The data controller bears the main responsibility for AVG compliance. It may be a legal entity (e.g., a limited liability company, non-profit organization, government agency) or a natural person engaged in a professional activity. In some cases, two or more parties jointly determine the purpose and means - they are then joint controllers (joint controllers). Consider, for example, a research project between two organizations that jointly decide what data to collect and how to use it; they must then mutually agree on their responsibilities to data subjects. The AVG requires data controllers to take all kinds of measures to safeguard privacy, from providing the right legal basis to informing data subjects and implementing security.
• Processor: The processor is the party that processes personal data on behalf of a controller. This is usually an external service provider. For example: a cloud provider that hosts data on behalf of your company, a payroll firm that calculates wages based on your employee data, or a marketing firm that sends mailings to customers on your behalf. The processor does not act for its own purposes, but strictly according to the controller's instructions. Although the controller remains ultimately responsible, the AVG also imposes direct obligations on processors (such as ensuring adequate security and keeping a processing register). In addition, the relationship between a controller and processor must be contractually defined through a processing agreement (more on this later). Importantly, when outsourcing data processing, your organization should only engage processors that provide adequate privacy compliance safeguards.
• Receiver and third party: If you share personal data with other parties, the AVG names those parties recipients (whether they are processors, other data controllers or third parties). An external party that is not part of one's own organization and is not a processor is often referred to in AVG terms as a third indicated. For example: you as a company are responsible, you have a processor for IT, but you also provide customer data to a partner company for joint marketing - that partner company is an (independent) third party/responsible party and the data provision must comply with AVG rules (e.g. lawful basis, informing data subjects).

These basic concepts form the foundation: they determine to whom and what the AVG requirements apply. For any data processing, you must be able to identify whose data is involved (data subjects), who the controller is, whether processors or third parties are involved, and exactly what data is being processed.

Purpose limitation, data minimization and retention periods

The AVG imposes a number of basic principles on data processing (Article 5 AVG). Here we highlight three important ones: target binding, data minimization and storage limitation (retention periods). These principles force organizations to handle personal data consciously and sparingly.

• Target binding: Personal data may collected only for specified, explicit and legitimate purposes, and are not later processed in a manner incompatible with those original purposes. In other words: use personal data only for the purpose for which you obtained it. If you want to use data for a new purpose, that purpose must be compatible with the original purpose or you must ask the data subject for consent again or have another legal basis. In practical terms, this means that companies must clearly define why they collect certain data. For example: a web shop collects address data to deliver a package - that purpose is delivery. The company may not use that address data for completely different purposes (e.g. resell it to an advertiser), unless it is compatible with the original purpose or the person consents. In Belgium, we see the GBA regularly enforce this principle. For example, one school was reprimanded for sending an e-mail to parents with all e-mail addresses in CC instead of BCC, so that each address ended up with all other parents. The GBA ruled that this practice was incompatible with the purpose for which the addresses were initially collected (direct communication between school and parent), and thus violated the purpose limitation principle. The result was a reprimand and an order to modify the practice. This example illustrates that you cannot simply use data for a new purpose (here: disclosure to others) without a basis.
• Data minimization (minimal data processing): Collect and process No more personal data than necessary for the intended purpose. This principle forces critical thinking: what information do I really need? Anything unnecessary should not be asked or kept. In practice, this means, for example: for a registration form, ask yourself whether you really need date of birth, national number or other details, or will name and contact information suffice? The less data you store, the smaller the risk in the event of a data breach and the easier compliance becomes. The GBA sees data minimization as a fundamental principle. For example, one school was found in violation because a survey of students requested too much personal information that was disproportionate to the purpose of student support. That case involved sensitive information (including about other students, bullying behavior and home situations) that was unnecessary for the purpose, violating the minimization principle. The lesson from this: for every piece of data you request or store, consider whether it is strictly necessary. Collect only the minimum set of data required to achieve the goal. This also applies to data already collected: companies would do well to regularly clean their databases of excess or outdated information.
• Retention periods (storage limitation): The principle of storage limitation means that personal data are not kept longer than necessary for the purposes for which they were collected. Infinite storage "for security" is therefore not permitted. In Belgium, organizations must determine reasonable retention periods for themselves, taking into account legal obligations and recommendations. For example, tax and social laws require that certain data (e.g., accounting records, payroll records) be kept for a minimum number of years - your retention period in those cases may not be shorter than the legal obligation. But data that you collect, for example, for a one-time action or for which there is no long-term need, you must delete as soon as the purpose has been achieved. Practical example: A webshop keeps customer data. It is justified to keep order data until the order is completed and during the legal warranty period (e.g. 2 years) for any returns or disputes. After that, the personal data should be deleted or anonymized, unless there is another legitimate purpose (e.g., longer retention of invoice data for tax purposes). Many organizations work with a retention period policy: this defines for each category of data how long they are kept and when they are archived or deleted. The GBA expects organizations to be able to demonstrate this as part of their accountability. In the Belgian context, there are also specific rules, for example for camera images: the Camera Act of March 21, 2007 stipulates that ordinary surveillance images may be retained for up to one month unless they serve as evidence of an incident. General tip: establish retention periods for all your data collections (a range of criteria if necessary) and implement periodic deletion. Not having clear retention periods can be seen as a violation of the storage limitation principle.

Practical guidelines: Make sure you explicitly define and communicate the purpose for each processing (preferably in a privacy statement). Do not simply use data for new purposes without checking whether it is allowed. Only collect information you really need - set up forms and databases so that unnecessary fields disappear. And keep a schedule of retention periods: this can be part of your processing register or internal policy. Train employees to be aware of this: for example, clean up mailboxes and network drives, don't keep local copies of entire databases "just in case," etc. By adhering to these principles, you not only reduce the risk of sanctions, but also build trust with customers and employees that their data is in good hands.

Legal grounds for processing

To process personal data lawfully, you must be able to rely on one of the six permissible legal grounds under the AVG (Article 6 AVG). Without a valid legal basis, processing is unlawful. We list and explain the six bases:

1. Consent of data subject: You may process data if the person in question does so free, specific, informed and unambiguous consent. This is the case, for example, with someone who subscribes to your newsletter and explicitly checks to agree to receive emails. Consent must be an active action (not pre-ticked boxes) and may be revoked at any time. Important in Belgium: for children under 13, parental consent is required for online services offered directly to them. (Indeed, the Belgian legislator set the digital age limit at 13, while the AVG gave a standard of 16 that member states were allowed to lower). Consent is a powerful basis, but not always the most practical: it requires maintenance (tracking who gave consent, possibility of withdrawal, etc.) and is not valid if there is any coercion or disparity (e.g., employer-employee situations, where it is better to seek a basis other than consent). The GBA takes strict care to ensure that "consent" is actually valid. For example, in an investigation, the GBA stated that a company had not sought valid consent for the placement of certain cookies - the cookie banner did not meet the requirements. This was considered a breach of the consent requirement. In that case, the company escaped a fine because it quickly voluntarily adjusted the practice, but the warning was clear. Practice Advice: use consent especially when the other bases do not fit, and then make sure you have a good consent mechanism (clear information, no mandatory checkmarks, ability to opt out).
2. Necessary for the performance of a contract: Processing is permitted if it is necessary to perform a contract with the data subject or to do something at the data subject's request prior to the conclusion of a contract. For example: you process a customer's address and payment details in order to sell and deliver a product - this falls under the performance of the sales contract. Similarly, an employer may process a job applicant's data as part of a potential employment contract (pre-contractual stage). Note: Process only those data necessary for the contract. For example, if you were to ask for a national registry number when ordering online (which is not necessary to deliver or invoice), you cannot base it on this ground. In practice, this ground is very common for all services and products that someone requests themselves - the logic is that without the processing, the contract cannot be fulfilled.
3. Compliance with a legal obligation: This refers to processing operations that are necessary to comply with an obligation to which the controller is subject by law, decree or other regulation. This is often applicable in a context of employers (e.g., processing of payroll data because social and tax laws require it), finance (obligation to keep accounting records), or compliance with other sectoral laws. It must involve a binding obligation in law (not merely a contractual obligation). For example, a bank processes customer identification data because anti-money laundering laws require it; a company requests the national register number of employees because the social security law requires it. In Belgium, there are several laws that mandate or regulate data processing - such as labor laws, tax laws, the law on camera surveillance, etc. If you invoke this basis, you must be able to identify which law or provision makes the processing necessary.
4. Vital interest of the data subject (or other natural person): This basis is intended for emergencies in which lives are at stake. These are processing operations that are necessary to protect someone's vital or health protection and there is no time or opportunity to seek consent. Consider an emergency physician processing unconscious patients' personal and medical data to treat them, or a situation where someone is powerless and data must be shared to prevent serious injury or death. In practice, this is not often invoked by ordinary companies, except perhaps in very specific cases (e.g., a company passing information about an employee to emergency services in an emergency). For most ordinary processing, this ground will not apply.
5. Public interest or exercise of public authority: This is a foundation especially for government agencies or for organizations performing a task of general interest based on the law. For example: a municipality that processes personal data for issuing identity cards, a statistics agency that collects data for population statistics, or a research institution that conducts medical research in the public interest with government permission. In the private sector, this ground is not often used unless a private party performs a public task under a statutory delegation. The general interest must be clearly defined in a law or regulation; you, as a company, cannot simply declare yourself to be something of public interest. Many public data processing operations (educational institutions, government agencies, etc.) rely on this basis in combination with specific regulations.
6. Legitimate interest of the controller (or a third party): This is an important and widely used residual ground for processing that is not covered by the other five grounds, but are necessary for the legitimate interests of the responsible party or a third party, provided In doing so, the rights and freedoms of the data subject are not outweighed. So it requires a balancing of interests: you must have a legitimate (legitimate, concrete) interest in the processing, and weigh whether this interest outweighs the impact on the privacy of the person concerned. If yes, then the processing is allowed - if no, then not. Example: a company has a legitimate interest in securing its building and property; installing camera surveillance may be justified on that ground, as long as the privacy intrusion for visitors/employees remains limited (and e.g. not filming sensitive areas, clear indication that there are cameras, etc.). Other examples: preventing fraud, ensuring network security, or direct marketing to existing customers could be cited as a legitimate interest (under strict conditions). This basis is flexible, but requires documentation: you must show that you have done the balancing). Recall that at protest of the person concerned (right to object) you usually have to stop processing based on legitimate interest, especially if it is direct marketing. In addition, this basis is not available to government agencies for processing in the context of their public duties - they are then more likely to have to use the "public authority/general interest" ground. In Belgian enforcement, we see examples where companies wrongly invoked legitimate interest. A Belgian company that continued to manage a fan page about an artist after a partnership ended argued, among other things, legitimate interest to continue doing so. The GBA rejected this argument: the page focused on the person of the artist (not on a project of the company), the collaboration had ended, and there was no longer a sufficient legitimate interest that outweighed the privacy of the artist. Thus, the company no longer had a valid basis and had to remove the page; it was also fined. This illustrates that legitimate interest must be real and weighed - it is not a carte blanche.

In addition to these six "ordinary" bases, there is a separate regime for the special categories of personal data (sensitive data such as health info, ethnicity, political opinion, etc.). In principle, you may not process, unless you meet one of the exception conditions of Article 9 AVG (for example: explicit consent, processing necessary for labor law or public health, processing by a physician under professional secrecy, etc.). In practice, organizations must be extra careful when handling sensitive data and often provide additional legal basis and security measures.

Practical for businesses: For all your processing operations, verify On what basis you process the data. Document this in your processing register or privacy policy. Common combinations: customer management = contractual necessity; personnel records = legal obligations (social legislation) + contract; marketing = consent (for non-customers) or legitimate interest (for existing customers, unless they object); camera surveillance = legitimate interest (security) subject to notification and consideration; employee medical data = usually legal obligation through the prevention service or employee consent for specific things (e.g. vaccination). Make sure that when you use consent, it meets all requirements. And for legitimate interest: perform and document a thorough balancing of interests. This prevents discussions afterwards with the GBA. Wrong or missing legal basis is a common violation. For example, the GBA fined a company that shared millions of personal data with commercial partners without valid consent or other basis. Thus, a robust legal basis for any processing is indispensable.

Rights of data subjects

The AVG gives individuals (the involved whose data are being processed) a set of powerful rights to maintain control over their personal data. As an organization, you should exercise these rights of data subjects respect and facilitate. We go over the most important rights and their significance:

• Right of access: A person has the right to know or you process personal data about him/her, and if so, to access that data and be informed of the "what, why and how." Specifically, a person may have a copy of his personal data request, as well as get additional info on the purposes of processing, categories of data, recipients, origin of data, retention periods, etc. (Article 15 AVG) . In principle, you must respond to this within one month respond (extendable once to up to three months in complex cases), and in most cases free of charge. This right is very broad: for example, someone may request their full customer profile, or an employee may view their personnel file. Exceptions: The right is not unlimited - for example, you do not have to provide access to other people's personal information (it may appear in documents and you may have to anonymize it), and repeated or excessive requests may be refused or paid for. Sectoral restrictions also exist (e.g., in health care: the right of inspection sometimes goes through a doctor). Still, the general rule is: transparency. The GBA has taken organizations to task for failing to comply. In one case, an employer refused to show parts of the personnel file (including evaluation notes) to a former employee, arguing that this would violate the privacy of managers. The GBA disagreed: the company could anonymize the names of third parties and had to allow the employee to see them; after all, there is no Belgian law limiting an employee's right to see his data. In that case, the employer finally had to prove that the notes in question had been erased after the employee had asked for them. Another example: two bank customers had requested, through their lawyer, access to all the data the bank had on them, but the bank only responded after 4 months and requested unnecessary clarifications. For this, the GBA reprimanded the bank for late and improper handling of the right of inspection. Practical: Make sure you have a procedure for access requests. Verify the identity of the requester (to prevent data misuse) but don't make it unnecessarily difficult. Compile a clear file of all data sources and prepare understandable explanations. Prompt and complete answers prevent complaints to the GBA.
• Right to rectification: Data subjects may leave incorrect or incomplete personal data correct or complete (Article 16 AVG). As an organization, you must implement such requests without unreasonable delay. For example: a customer discovers that his name is misspelled in your system or his address is out of date - he can request correction. You must then update the data and ideally also ensure that any third parties to whom you passed on the old data are informed (to the extent possible) of the correction. This right seems simple, and for most organizations it is routine (people get their data amended through customer services, HR, self-service portals, etc.). Note that sometimes someone challenges the accuracy of data that is not objectively "wrong" (e.g., someone's expression of opinion in a file). You must then weigh whether a rectification is warranted. In the context of evaluations or opinions, this can be tricky - the AVG does not require you to change your opinion, but the data subject can add an explanation. Tip: Keep your data files up-to-date and facilitate a way for users/customers to report changes.
• Right to data erasure ("right to be forgotten"): In certain cases, a person may request that his/her personal data be deleted (Article 17 AVG). This right applies, among other things, if the data is no longer needed for its original purpose, or if the processing was based on consent and that consent is withdrawn, or in the case of unlawful processing, etc. It is not absolute - there are important exceptions. For example, an organization need not delete data if the retention is necessary to comply with a legal obligation or to establish or defend legal claims. For example, a customer can ask to delete their account (and generally you must do so if the data is no longer needed), but you may not, for example, delete billing data that you are legally required to keep for 7 years before then. The right to be forgotten was made famous by Google search results: people can, under circumstances, request that search links to privacy-sensitive information be removed. Indeed, in Belgium in 2020, Google was required by the GBA to dereference certain search results based on this right, coupled with a fine (one of the higher fines then imposed by the GBA). For most companies, however, this right revolves around their own data files: you should be able to delete personal data upon request unless you have a valid reason to keep it. Practical: Establish internal guidelines for when you honor an erasure request and when you may deny it (e.g., honor customer requests unless retention requirements apply). If you have made data public (e.g., a photo online), take reasonable steps to get it away from others if the data subject requests it.
• Right to restriction of processing: This right (Article 18 AVG) means that a data subject may, in certain situations, request that the processing temporarily freeze. For example: someone disputes the correctness of data - during the period that you check it, you must restrict the processing on request (still keep the data but not use it further for a while). Or if the processing proves to be unlawful but the person does not want everything deleted (e.g. because he needs the data for legal proceedings), he can request restriction instead of deletion. With restriction, you may only store the data and no longer actively process it, except with the data subject's consent or for specific legal purposes. This right is exercised less frequently, but you must enable it. In practice: mark the data in question as "blocked" in your system if someone asks for it with reason.
• Right to data portability: A relatively new right (Article 20 AVG) is that a person may disclose the personal data he itself provided to an organization, in a structured, commonly used digital format, in order to transfer them to another service provider, if necessary. This only applies to data you process based on consent or contract, and where the processing is automated. In consumer practice, this means, for example: a customer should be able to download and reuse their transaction history or profile data with a particular service. Think of a music streaming service from which you want to export a list of all your songs, or a social network where you want to download all your photos and posts. The data subject can also request that you transfer the data directly to a new provider (if technically feasible). Although this right is not very often invoked in practice (yet), it can come into play when switching providers (e.g., from one cloud app to another). An interesting Belgian example of the creativity surrounding this right: the GBA ruled in a decision that an artiste had the right to transfer the admin rights of a Facebook fan page about herself to be transferred from the former administrator, on the basis of data portability. In other words, the data (fans, content) on that page related to her, and she was entitled to demand to "take" it with her. This goes a long way, but shows that this right is more than just a CSV table - it's about real control over your personal data.
• Right to object: Data subjects have the right to object against certain processing of their personal data (Article 21 AVG). This applies in particular to processing based on legitimate interest or public interest, as well as to direct marketing. In direct marketing, the right to object is absolute: any person can object at any time and free of charge to the use of their data for marketing, after which you can use that use must stop. That's why you see an unsubscribe link by default with newsletters, and with call centers the option to have you removed from call files. For legitimate interest processing, if you object, you have to consider whether your interests might outweigh your interests after all; in principle, you have to stop the processing, unless there are compelling legitimate grounds that outweigh the rights of the data subject (in practice, that's a high threshold, except for e.g. anti-fraud). An example: someone may object to his employer posting his photo on the intranet - here, privacy usually outweighs the employer's interest (if any), so the photo must be removed upon request. In Belgium, we see strict enforcement of the right to object, especially in marketing. For example, the GBA investigated telecom operator Telenet after complaints that it was difficult to opt out of their marketing. The GBA found that Telenet was forcing customers to per channel (email, phone, text, mail...) to object separately and did not offer a simple, general opt-out. Moreover, there was no easy option online, only through store or customer service. The GBA found this unacceptable and reprimanded Telenet for violation of the right to object, recommending that a simple web form be provided for all forms of marketing. This shows that companies should take the right to object seriously and provide customers with a low-threshold "unsubscribe" option. Notice: in the case of processing for scientific/historical or statistical purposes, objection is also possible, but one must prove that there are compelling personal reasons.
• Right not to be subject to automated decisions (including profiling): This right (Article 22 AVG) protects people from decisions made entirely by computers/algorithms without human intervention, if those decisions have legal consequences or similarly significant effects. For example: an algorithm that automatically refuses a loan, or excludes a job applicant, without a human still reviewing it. Such decisions are only allowed under certain conditions (necessary for a contract, legally permitted or based on explicit consent, and with additional safeguards). Data subjects have the right to seek human intervention in such cases, to express their views, and to challenge the decision. This right is less directly relevant to all companies, except those employing heavy automation. Still, it is good to know: if your organization deploys AI or profile analysis that binds individuals, you should take extra care and perhaps facilitate this right.

Finally, stakeholders have also discussed the right to file a complaint with the supervisory authority (i.e., in Belgium, the GBA) or go to court if they feel their rights have been violated. This is not a "request to the controller" but a right of escalation.

Obligations for organizations: You must have the rights listed active support. This starts with giving data subjects accurate and complete information about their rights and about the processing (information provision/transparency is itself a duty under Articles 13 and 14 AVG). Many organizations do this through a privacy notice. Next, you should have internal procedures in place to handle requests efficiently: a point of contact (preferably the DPO or privacy officer), templates for responses, a record of requests and handling deadlines. Important: Respond timely (usually within 1 month) and give reasons. If you reject a request (e.g., because a legal exception applies), explain why and refer to the option of going to the GBA. Also ensure security in handling - for sensitive requests, ask for proof of identity so that data is not given to the wrong person. Inadequate handling of these rights can lead to sanctions, as we saw with the bank example (4 months' delay was too long. Conversely, good procedure can prevent escalations: many people only go to the GBA when they are not heard at the organization.

Cooperation with other parties: processor agreements and joint responsibility

In modern data processing practices, organizations rarely work alone - often there are other parties involved in processing personal data. Think outsourcing (IT services, cloud software, payroll, marketing agencies) or collaborations (partners, sister organizations, projects). The AVG provides two key concepts for such situations: the processing agreement and the regulation of joint controllers.

Processor Agreement (Data Processing Agreement, DPA): If your organization as controller engages an outside party to serve as processor process personal data for you, then you are required to enter into a written agreement that meets specific AVG requirements (Article 28 AVG). This is called the processor agreement. It must specify, among other things: the subject and duration of the processing, the nature and purpose, the type of personal data and categories of data subjects, the obligations and rights of the controller, and especially the data protection obligations of the processor. For example, provisions that the processor may only process data on the instructions of the controller, implement appropriate security measures, not engage sub-processors without consent, cooperate with the rights of data subjects, return or delete data at the end of the service, etc. These contracts are crucial to delineate clear responsibilities and ensure that the processor also acts AVG compliant. Practical: Establish such a contract for all your vendors who handle personal data (or work with their standard DPA provided it is satisfactory). Many cloud and software vendors offer a DPA as part of their terms of service - check that it is complete. In at least one case, the GBA has explicitly increased a penalty because a processor agreement was not in place where one should have been. In the Family Service case (the company behind the "pink boxes"), the GBA found that the company shared data with partners without the required contracts in place, which contributed to the finding of violations. In short: no processor contract is asking for trouble. Also, be sure to subject your processors to due diligence: choose vendors that offer sufficient safeguards (certifications, good reputation, security measures) and also stipulate audit rights or periodic reviews in the contract. Remember that if the processor violates the rules, you as the controller remain ultimately accountable to the data subject.

Joint Processing Responsibility (Joint Controllers): Sometimes your organization determines together with another organization the purpose and means of a processing operation. In such a case, the AVG refers to joint controllers of processing (Article 26 AVG). This means that both parties are responsible for compliance with the AVG for that specific processing. For example: a municipality and a research institute jointly organize a survey of citizens and jointly decide which data are collected and how results are used - they are joint controllers. The AVG requires joint controllers to transparently determine which of them takes on which obligations. In practice, they enter into a common scheme or agreement, agreeing, for example, who provides information to data subjects, who handles requests from data subjects, who takes what security measures, how they maintain DPA contact, and so on. This arrangement does not necessarily have to be public, but the essence (in particular, how the exercise of rights and provision of information is arranged) must be communicated to data subjects. Joint responsibility means joint liability: an affected party can hold both of them accountable for a miss. Among themselves, the parties can then divide who reimburses what, but externally they stand strong together in responsibility. Practical: Take stock of whether there are situations where your organization actually makes joint decisions about data with another. Sometimes this is obvious (a joint project, co-sponsoring an event where you share the list of participants and use it together), sometimes less obvious (e.g., third-party plugins on your website - there you can also be seen as jointly responsible, as previously ruled by the Court of Justice in cases about Facebook Like buttons, etc.). When in doubt: consult with the partner and establish a joint controllership agreement. It is better to arrange that than to ignore it, as the GBA will still check the responsibilities when investigated.

Sharing data with independent third parties: If you transfer personal data to another data controller (i.e. not a processor and not jointly), for example a business partner who uses the data for its own purposes, there is no mandatory AVG agreement as with processors. However, you must ensure a valid basis for that transfer (e.g. consent or legal provision, or own legitimate interest provided conditions are met) and you must inform the data subject that you are providing their data to that third party. In effect, you treat the third party as its own new responsible step: that party is itself responsible for further processing. Notice: a notorious example is that of companies "renting out" or selling their customer database to marketing partners. In the Family Service case, the company shared millions of young parents' data with commercial partners without valid consent, which was unlawful. The €50,000 fine underscores that this cannot be done without clear information and consent from those affected. Such data sharing must therefore be done with extreme care. Ensure transparency (mention in your privacy policy which third parties receive data), and preferably use pseudonymization or minimal data if you pass anything on.

Summary Practical: close always processor agreements with your IT service providers and other data processors. Make clear agreements if you act jointly with a partner in a data processing operation - record who does what regarding AVG. And when transferring data to third parties: check your basis and inform the data subjects. These contractual and organizational measures are part of accountability and can be requested during audits. The GBA looks into this, especially if incidents show that it was unclear who was responsible or that there were no proper contracts.

Transfer of personal data to third countries

The protection of personal data does not stop at EU borders. When you transfer personal data forwards outside the European Economic Area (EEA) - these are the EU member states plus Norway, Iceland and Liechtenstein - we speak of a transfer to a third country. The AVG sets strict conditions for such transfers (Chapter V AVG). The underlying idea is that data exports should not lead to a lower level of protection than applies within Europe.

Situation: For example, your company uses a U.S. cloud platform, or you transfer customer data to a partner in India, or your parent company in the U.S. wants access to Belgian HR data. All of these cases are international data transfers.

Main rule: Personal data may be sent to a country outside the EEA only if there are sufficient guarantees be that the data there remain protected according to EU standards. The AVG provides a few mechanisms for this:

• Adequacy decision: The European Commission may officially grant certain countries the designation "adequate level of protection" give. Data can then flow freely to those countries, just as if it were within the EU. Examples: Canada (for commercial organizations), Japan, Switzerland, the UK (after Brexit, the EU declared the UK adequate). Recently, the EU-US Data Privacy Framework created (2023) to restore an adequacy arrangement with the U.S., following the invalidation of the previous arrangement (Privacy Shield) in 2020. Companies certified in the U.S. under that framework are allowed to receive data from the EU. Thus, if you transfer data to a party in an adequacy declared country, you do not need to take any additional measures - though of course continue to follow the general AVG rules.
• Appropriate safeguards: If there is no adequacy decision for the country in question (e.g., China, India, Brazil, etc.), you must use other legal instruments to legitimize the transfer yourself. By far the most commonly used are the Standard Contractual Clauses (SCCs). prepared by the European Commission. These are model clauses that you include in a contract with the recipient in the third country, committing it to comply with EU privacy rules (including data subjects' rights, security, limitation of onward transfers, etc.). Since 2021, updated SCCs are available that are modular and reflect the GDPR. Other options for appropriate safeguards include Binding Business Rules (BCRs). - internal privacy rules for multinationals, approved by regulators, to exchange data among themselves - or sectoral codes of conduct and certification mechanisms (although the latter are still little used in practice). Whatever safeguard you choose, it usually comes down to contractual obligations for the recipient to adequately protect the data.
• Exceptions for specific situations: If there is no adequacy and no time or opportunity for appropriate safeguards, in certain cases you can still make a transfer based on exceptions (Article 49 AVG). For example, with the explicit consent of the data subject for the specific transfer, or if the transfer is necessary for the performance of a contract (e.g. a hotel booking in a country outside the EEA), or for the pursuit of legal claims, vital interests, etc. However, these exceptions are meant to be limited - structural, large-scale transfers should actually be arranged through the safeguard route and not always through such an exception.

After Schrems II: An important development is the "Schrems II" judgment of the EU Court of Justice (2020), which invalidated the Privacy Shield (the then EU-US regime) and emphasized that when standard contractual clauses are used one must verify whether the laws of the receiving country do not undermine contractual protections (especially looking at government and intelligence access). Organizations using SCCs have since been required to obtain a so-called transfer impact assessment do: investigate whether the data in the destination country is safe from e.g. government interference, and if necessary take additional measures (such as encryption, pseudonymization) if they still want to transfer. This has led many companies to take a closer look at, among other things, cloud services in the US. With the new EU-US framework, some of those concerns have been alleviated, but not all - privacy activists are already contesting the new mechanism.

Belgium: The GBA is following the European line. It has published guidelines together with the EDPB on international transfers. In practice, the GBA is relatively often asked whether e.g. the use of American tools (mailing software, CRM, etc.) is allowed. The answer is: yes, provided the described conditions (SCCs + possibly additional measures) are in place. As an organization, you should Knowing where your data goes. Map your data flows: do you host everything in the EU or not? Does your software vendor have servers or support outside the EU? Do you transfer personal data to a parent company outside Europe? For each such flow, you must ensure that an adequacy decision or contractual safeguard applies. Failure to arrange this correctly could result in a breach. Although so far the GBA is mostly advising and warning on this issue, enforcement actions are not out of the question, especially as time goes on since Schrems II and companies are expected to have their affairs in order.

Practical Tips:

• Inventory international dataflows: Know what personal data your organization ends up with outside the EEA.
• Use model clauses where appropriate: Enter into the latest standard contract clauses with any partner outside the EEA without adequacy. Many major service providers offer this standard (check their Data Processing Addendum).
• Assess the risk: Do a transfer impact assessment if required, especially for sensitive data or for countries with question marks around supervision (e.g. China, Russia, ... and also the U.S. if you are not covered by the new framework).
• Consider encryption: Encrypt personal data before you send it internationally so that even if accessed by third parties, the content is protected.
• Be transparent: Inform data subjects in your privacy policy about any transfers outside the EEA, including which countries and under what safeguards.
• Keep up with developments: International data regimes are changing (see U.S. regulations). Follow the GBA/EDPB's guidance on this. If in doubt, you can also seek advice from the DPO or even in advance from the GBA.

In short, cross-border data flows are permissible, but not optional. You must have legal-technical "the paperwork" and security in place to ensure that personal data remains secure across borders.

Data security and data breaches (duty to report)

Security (information security): The AVG requires organizations to implement appropriate technical and organizational measures take steps to secure personal data (Article 32 AVG). This includes protection against unauthorized or unlawful processing, against loss, destruction or damage. What is "appropriate" depends on the state of the art, the cost of implementation, the nature of the data and the risks. Specifically, one expects you to take reasonable steps: e.g., IT measures such as firewalls, antivirus, encryption, backups, access control (passwords, two-factor authentication), pseudonymization of data, etc., as well as organizational issues such as a secure data handling policy, staff training, physical security of paper files and server rooms, limiting access to data to those who need it, etc. There is no one-size-fits-all: a hospital must take tougher measures (medical data) than a local sports club (membership list), but both must do something. Accountability comes into play here, too: you should be able to demonstrate that you have thought about security (e.g., through an IT security policy, risk analysis, ISO27001 certification, or the appointment of a security officer). In Belgium, there is also horizontal legislation (such as cybersecurity law for essential services, NIS2 directive for certain sectors) - but for personal data, Article 32 remains the core. The GBA does not view security breaches lightly: if an incident shows that there was poor security, that in itself can be grounds for sanction (regardless of any damage caused by the incident).

Data breaches: Despite all precautions, something can go wrong - a lost USB drive, a hack, a misdirected email, an employee copying data unauthorized, etc. The AVG defines a data breach (data breach) as a security breach that accidentally or unlawfully results in the destruction, loss, alteration, unauthorized disclosure of or access to personal data. Thus, this includes hacking attacks as well as silly mistakes (e.g., a spreadsheet containing personal data becoming publicly available online).

The AVG imposes a reporting requirement up for serious data breaches:

• You must have a data breach report to the Data Protection Authority without unreasonable delay and within 72 hours after you become aware of it, unless the leak is unlikely to pose a risk to the rights and freedoms of individuals (Article 33 AVG). In practice: is there a real risk of harm to people (privacy, financial, reputation)? Then report. When in doubt: better report - the GBA would rather see proactive reporting than concealment. Reporting to the GBA is done via an online form and should include info on the nature of the leak, number of people affected, data affected, likely consequences and measures already taken.
• Communication to stakeholders: If the leak is likely to be a high risk involves the individuals (e.g., sensitive data has been leaked, or data that could be misused for identity fraud), then you must also inform the affected individuals themselves without delay (Article 34 AVG). You then explain what happened in understandable language and what they can do to protect themselves (e.g. change password, be alert to phishing). You do not have to inform if you took measures afterwards that eliminate the high risk (e.g. stolen laptop with heavy encryption - the data is unreadable, so not a high risk), or if informing takes disproportionate effort (then a public disclosure may suffice).

Report culture: In Belgium, the reporting requirement applies directly from the AVG; the GBA is designated as the authority to which reports go. Companies must have a procedure internally to recognize, escalate and report data breaches within 72 hours (3 days). Note that 72 hours is short - it includes weekends and holidays. Therefore, it is important that staff is trained to handle potential incidents immediately to the appropriate person (e.g., DPO or IT/security team). Better to escalate an incident too much than to notice a critical hack too late.

Consequences for violations: If a data breach occurs because security measures were missing or failed, the GBA can intervene afterwards. For example, in one case, a telecom provider was fined €25,000 because a lack of identity checks allowed a customer number to be taken over by a third party, leading to unauthorized access to a person's communications. The GBA argued that this was a breach of integrity and confidentiality and that the provider also failed in its responsibilities around data breaches. In that case, the company had failed to build in adequate security (identity verification) AND the leak (misuse of the number) came to light in a way that pointed to poor internal controls. Such incidents are exactly what the mandatory notification aims to address.

Practical tips for security and data breaches:

• Invest in a sound IT security infrastructure (firewall, encryption, updates, access management) appropriate to your risks.
• Train your employees in privacy and security basics: don't share passwords, recognize phishing, clean desk, etc. Human error is a major cause of leaks.
• Set a incident response plan on: who does what in the event of a (suspected data breach)? Make sure everyone knows who to contact (e.g. the DPO or IT manager).
• Document every security incident, even if it is small and not reportable. The AVG requires you to record all breaches (so the GBA can verify that afterwards).
• If there is a potential reportable leak: be transparent internally, get facts as soon as possible and decide on reporting within 72 hours. If necessary, report provisionally with info you have; you can update details later.
• Learn from incidents: After each leak, evaluate how to prevent recurrence (patch processes, additional training, tighter settings).
• Realize that do not report if you should have reported, is itself a violation. The threshold for reporting was therefore deliberately kept low ("only do not report if unlikely risk").

By being proactive about security and leaks, you protect not only those affected but also your organization from reputational damage and enforcement. The GBA understands when things go wrong despite precautions - no one is 100% immune to hackers or human error - but will be less lenient if it turns out that they were negligent or wanted to cover up an incident.

Data Protection Officer (DPO) - Data Protection Officer.

The Data Protection Officer (DPO)., in Dutch also called Data Protection Officer (FG) called, is a designation in the AVG for a privacy advisor/supervisor within the organization. Not every organization is required to have a DPO, but many choose to do so voluntarily because it pays to have someone knowledgeable monitor privacy policies.

Commitment to Appointment: Article 37 AVG requires certain organizations to mandatory need to appoint a DPO:

• All government agencies and bodies (with some exceptions, such as courts in their judicial functions) must have a DPO. This means that all ministries, municipalities, government departments, as well as educational institutions and public companies must typically have a DPO on board.
• In addition, non-government organizations must also appoint a DPO if their core activities consist of (a) large-scale, regular and systematic observation of data subjects (e.g., a company that widely tracks people online, a marketing data broker, or perhaps a security firm with numerous cameras) either (b) large-scale processing of special categories of data or criminal data. The latter would apply, for example, to hospitals (lots of medical data), certain laboratories, large insurers (health info), or perhaps a social media company (large-scale profiling). It could also include a company that processes location data on a large scale.
  In practice, many organizations are unclear about whether they "must" have a DPO. Doubts include SMEs that are not core data dealers - they are usually not required. But large multinationals, tech companies, financial institutions, etc. are. Belgium has not extra extended this criterion in national law (some countries, such as Germany, have set a lower threshold, e.g. from 20 employees regularly processing data is already DPO obligation - Belgium has that not, we purely follow the AVG criteria).

Voluntary DPO: Even if you are not required to, you may of course always appoint a DPO. This shows good will and ensures that there is someone internally with a focus on privacy. Please note: if you appoint one voluntarily, the AVG provisions regarding the DPO must also be complied with (so do not just call someone DPO without giving the guarantees).

Position and role of the DPO: The DPO is actually an internal (or external) privacy supervisor/consultant. Key features:

• Independence: The DPO may not receive instructions on how to perform data protection duties, and may not be disadvantaged or dismissed for performing those duties (Article 38(3) AVG). The DPO usually reports to senior management.
• No conflict of interest: The DPO must not hold a position that leads to a conflict of interest. Specifically, this means that the DPO may not itself determine the purposes and means of processing within the organization. So combining roles such as CEO, IT manager, HR manager, or marketing director with DPO is conflicting: after all, those positions determine data processing. The GBA has emphatically confirmed this. In one case, telecom operator Proximus was fined €50,000 because their DPO was at the same time director of the Audit, Risk & Compliance departments - such a person (partly) determines the means/purposes of processing operations and cannot independently audit himself. The GBA stated that a managerial position within a department is incompatible with being a DPO. So make sure the DPO has a role that is sufficiently independent in the structure.
• Expertise: The DPO must have professional qualities, especially in data protection law and practice. No formal degree is required, but experience or training in privacy law and information security is recommended.
• Duties: Article 39 AVG lists the duties. The DPO informs and advises the organization and employees about their obligations under the AVG and other privacy laws. He monitors compliance of it (auditing, monitoring processes, etc.). He Advises on data protection impact assessments (DPIAs) and oversees its implementation. Furthermore, the DPO serves as point of contact for the supervisor (GBA) and for data subjects (individuals can contact the DPO with questions or complaints). The DPO must also confidentiality can keep about his work.

External or internal DPO: A DPO does not have to be an employee; it may also be an external consultant or firm that performs this role through a service contract. Especially for SMEs that do not need a full-time DPO, an external specialist is often appointed. The advantage is expertise and part-time deployment; the disadvantage may be that the external DPO is less in touch with internal processes unless properly integrated.

Reporting requirement: In Belgium, you must report the appointment of a DPO to the GBA (you can register the DPO details via their website). This is both so that the GBA knows there is a point of contact, as well as a legal requirement from the national implementing law.

Engagement in the organization: The DPO must be "timely and properly" involved in all matters involving personal data (Article 38(1) AVG). This means, for example, that in the case of new projects, IT systems or policy changes that impact privacy, the DPO must be consulted. Similarly, in the event of a data breach, the DPO must be immediately involved in the assessment and notification. In the past, things have gone wrong when the DPO was involved too late or insufficiently. In the Proximus case, the GBA also signaled that the DPO was not involved in discussions about a specific data leak - they had handled an incident without knowing the DPO in it, which showed that the DPO was not serious about the process.

Practical for companies that have/appoint a DPO: Ensure that the DPO has a clear positioning (charter or job description), direct access to management, and most importantly that there is a culture of timely involvement of the DPO. The DPO should have access to all necessary information and systems to do his job. Also give the DPO enough resources (time, budget for training, support). And communicate to your staff who the DPO is and that they can contact him/her with privacy questions or suspected incidents. Externally, mention the DPO in your privacy statement as a point of contact.

For organizations without a DPO: Consider whether a voluntary DPO would be helpful, or at least designate someone internally as privacy officer. After all, even if you don't formally need a DPO, you still need to follow all the rules - so someone needs to take the lead. A DPO (mandatory or not) is often a good investment to avoid fines and reputational damage through proactive compliance.

Accountability and register of processing activities

The AVG introduces the principle of "accountability" or accountability (Article 5(2) AVG): organizations must not only comply with the rules, but also be able to demonstrate that they comply with them. This has resulted in a number of documentation and organizational obligations that are essential for compliance.

Processing Register: A central tool for this is the register of processing operations (Article 30 AVG). Each controller (and processor) must keep such a register, which includes a description of what happens for each data processing operation. For the controller, the register includes, among other things: the name and contact details of the organization (and DPO if applicable); the purposes of each processing; the categories of data subjects and personal data; the categories of recipients to whom data is provided; whether data is transferred to third countries (and what safeguards are in place); the intended retention periods for each category of data; and a global description of the security measures in place. For processors, the list is somewhat more limited (their principals and the categories of processing they do for them). Exception: organizations with fewer than 250 employees need to not necessarily keep a register, unless the processing is not incidental, contains sensitive data or poses a risk to the rights of data subjects. In practice, almost every organization falls under one of these exceptions (because hardly anyone now really processes "incidentally" - customer and employee data are already ongoing). It is strongly recommended that SMEs also have a register, concise if necessary.

The register is intended internally, but the regulator may ask for it during an audit. It is actually the backbone of your privacy administration: it provides overview and forces you to think about all processing. Moreover, it helps meet other obligations (keeping track of legal grounds, setting retention periods, etc.). The GBA has taken organizations to task for not having a register. For example, during an investigation into camera use, it was found that the controller did not have a register of processing, which is required under both the AVG and the specific Camera Act - this was deemed a violation. A reprimand followed, making it clear that the register is a must.

Documentation of assessments and procedures: In addition to the register, accountability requires you to document a variety of choices and analyses. Some important ones:

• Data Protection Impact Assessment (DPIA): For likely high-risk processing (e.g., deployment of new technology for large-scale monitoring, large-scale processing of sensitive data, high-impact profiling), you must conduct a data protection impact assessment in advance (Article 35 AVG). In Belgium, the GBA has compiled lists of situations that definitely require a DPIA (such as large-scale processing of location data, use of biometrics for identification, etc.). The DPIA documentation describes the intended processing, assesses the necessity and proportionality, analyzes risks for data subjects and formulates measures to mitigate those risks. If a DPIA shows that a high risk remains despite measures, you must consult the GBA before you begin. DPIAs must be in writing (and can be shown to the GBA upon request).
• Policies and procedures: You would do well to have internal privacy and security policies in writing. For example, an information security policy, a data breach procedure, guidelines for retention periods, protocol for dealing with the rights of data subjects, etc. This demonstrates your systematic approach to privacy.
• Training and awareness raising: Keep track of when staff receive privacy training, what instructions have been distributed. This can help prove that you are "in control."
• Proof of bases and consents: Document the legal basis of any processing (e.g., in the registry). If you work with consent, keep records of consents given (e.g. logs of login forms).
• Contracts and agreements: As mentioned earlier, make sure processor agreements are in place and filed. For joint processing responsibility, document agreements. These documents also demonstrate accountability.
• Notifications and communication: Record when you have provided mandatory information to data subjects (e.g. copy of privacy statement versions). Keep track of when data breaches have been reported (in an incident register).

Actually, if you do anything in the area of privacy, write it down. This sounds bureaucratic, but in audits it is invaluable.

Accountability to the GBA and proactive controls: The GBA can always ask for proof of compliance. It can ask for your register in an investigation, evidence of DPIAs conducted, security policies, etc. Recently (2022), the GBA announced it will be more actively checking whether organizations have a processing registry, precisely because it is such a basic requirement. So make sure this is in order before the question comes up.

National nuances: In addition to the AVG obligations, Belgium has a few specific registry obligations in laws. For example, the aforementioned Camera Law requires a register/log for camera security; telecom legislation has obligations for telcos around data traffic, etc. But if you keep the AVG register neatly updated, it often already largely covers these aspects (although sometimes additional information is required, such as locations of cameras in the camera register).

Briefly practical: Set a processing register on - list all your processing, fill in the required columns. This need not be novel; a table or spreadsheet often suffices as long as the information is complete. Update this register when you start new processing operations or change existing ones. In addition: keep an internal privacy file with all relevant documents (policies, agreements, DPIAs, notifications). Think of it as your "evidence folder" for privacy. This helps not only for the regulator, but also internally to maintain oversight and manage compliance. Many companies integrate this into a compliance tool or just shared folders that legal/IT/HR can access. Remember to use the register and related documents as well, not just have them: for example, consult the register when someone requests access (is that person in our register, what data do we have?), use it in DPIAs, etc. That way it becomes a living tool rather than a paper tiger.

Public enforcement: the role of the GBA, sanctions and Belgian decisions

The Data Protection Authority (DPA) is responsible in Belgium for monitoring the application of the AVG and additional national provisions. The GBA (formerly the "Privacy Commission") is an independent body with investigative and sanctioning powers. It is important for organizations to know how the GBA operates and what consequences there may be for violations.

Organization of the GBA in a nutshell: The GBA includes the First Line Service (for questions/complaint advice), the Inspection Service (which conducts investigations, similar to an investigation cell) and the Dispute Chamber (which acts as a quasi-court and makes decisions, including sanctions). There is also a knowledge center that provides recommendations and advice (e.g., on new laws). A citizen's complaint can lead to mediation or advice, or to a formal investigation. The GBA can also initiate investigations on its own accord (e.g., thematic audits).

Powers: The GBA has far-reaching powers that are largely unified by the AVG (Article 58 AVG): it can issue warnings, suspend or prohibit processing operations, issue orders to adjust practices within a certain period of time, and impose administrative fines. Fines can be high (maximums of €10 million/2% turnover or €20 million/4% turnover depending on the breach category, as stipulated in Article 83 AVG). In practice, the GBA - like other regulators - looks at proportionality and employs an escalation model: minor initial breaches can be dealt with with a warning or reprimand, while serious or persistent breaches receive fines. The GBA also has the power to impose periodic penalty payments (for example, "adjust your practice within 1 month, otherwise x euros per day of delay").

Sanctions policy and Belgian cases: Since the AVG went into effect, the GBA has already made a series of guideline decisions. Some notable Belgian enforcement examples:

• Fine for unlawful direct marketing ("pink boxes" case): One of the first major fines was €50,000 for Family Service, which collected data from (future) mothers through "pink boxes" and resold that data to advertisers without valid consent. The GBA saw violations of transparency, legal basis (consent was missing or invalid), insufficient measures and no processor agreements. In addition to the fine, the company was also ordered to bring its processing operations in line with the AVG within six months. This case emphasized that trafficking of personal data without a clear basis will be dealt with harshly.
• Penalty for DPO conflict of interest (Proximus case): As mentioned earlier, the GBA €50,000 fine on Proximus because their internal DPO also held other positions that constituted a conflict of interest. Moreover, the DPO was not properly involved in incidents. The GBA thus gave a clear signal that the role of DPO must be taken seriously and that independent position is not an empty demand. Proximus also had to rectify the situation within 3 months.
• Fine for poor security (telecom number case): A telecom provider received €25,000 fine because a customer's phone number had been taken over by a third party due to lack of identity verification at the provider. This was seen as a violation of the principle of integrity and confidentiality and the obligation to take appropriate technical and organizational measures. It was also charged that this incident indicated failure in dealing with data leaks. The provider had to review its procedures (especially around customer identification)
• Reprimand for violation of purpose limitation (BCC e-mail case): In the case of a school that mailed parents in CC instead of BCC, the GBA ruled that this was unlawful processing in violation of purpose limitation and data minimization. The school received a reprimand and an order to amend it. While no fine followed here, it shows that even fairly mundane mistakes can lead to an official sanction (albeit mild in this case).
• Right to object and cookies (Telenet case): Telenet was not fined but was warned/warned for shortcomings: the right to object to direct marketing was set up too cumbersomely and the original cookie consent was not validly obtained. Because Telenet cooperated and improved, it was left with a reprimand (and it was seen as a breach of transparency). This case shows the graduated action: the GBA gives opportunity to improve if the organization is willing.
• Government/politics: Politicians and governments have also already been in the picture. For example, a list leader was fined €5,000 because he used addresses from an internal municipal database (personnel list) instead of the official voters' list for election propaganda - this was incompatible with the purpose for which the personnel data had been collected (i.e., personnel administration) and there was no valid basis for such processing. This involved misuse of public information for private (political) gain and was punished.
• Small organizations and individuals: Even private individuals or small associations can fall under GBA surveillance if they commit systematic violations. For example, there is a case where a couple was fined €1,500 for installing cameras that also filmed the public road and sharing those images with third parties - thus violating the camera law and AVG (no legitimate interest to film the public road continuously, violation of passersby's privacy). This illustrates that the GBA also acts in neighborhood squabbles where privacy is at stake.

Procedure and rights: In an investigation, the organization involved usually gets questions or an inspection first. You have a right of defense: you can submit your point of view and justification. The final decision of the Dispute Chamber is delivered to you and may be published (anonymously or sometimes by name if it is in the public interest). There is the possibility of appeal against GBA decisions to the Market Court (Brussels Court of Appeal). In the Smartschool survey case, for example, the fine was partially revised after appeal (from €2,000 to €1,000), although the finding of violations remained intact (and the obligation to comply).

Sanctions policy: When determining fines, the GBA takes into account factors such as the severity of the breach, number of people involved, degree of intent or negligence, previous breaches, measures taken, degree of cooperation, etc. In Belgium to date, we see fines that are relatively moderate compared to some other countries (where sometimes tens of millions are imposed). This does not mean laxity - but the GBA sometimes opts for reprimands or moderate fines to correct behavior, especially for smaller actors or first offenses. For repeat or serious violations (e.g., deliberate data trading in violation of the law), a hard line will follow.

Guidelines and recommendations: In addition to the punitive component, the GBA also issues guidance (e.g., recommendations on direct marketing, cookies, use of cameras, etc.) and advises legislators on new regulations. These publications are useful to follow because they indicate how the GBA views certain topics. For example, there is a famous recommendation on the use of cameras by police forces, or guidelines on cookies developed jointly with the other EU authorities (in the EDPB).

Conclusion for organizations: Be sure to before works, not at the GBA. This means: be compliant and transparent, then you have little to fear from the regulator. If the GBA does come knocking (e.g. in response to a customer complaint), respond promptly and completely. Show that you are willing to correct what is wrong. Often the GBA will then be lenient in its handling. However, if you ignore requests or knowingly violate the rules, the penalties can be very sensitive - financially and in terms of reputation (decisions are often published, which can generate media attention).

Some final tips:

• Follow the GBA website and news: this keeps you abreast of new decisions and allows you to learn from the mistakes of others. The GBA publishes summaries of rulings and press releases.
• Document your efforts. Should you ever find yourself in litigation, it is important to be able to show that you take privacy seriously, even if something has gone wrong somewhere.
• When in doubt, consult your DPO or legal counsel. Sometimes preventive advice is cheaper than a fine afterwards. The GBA itself is also approachable for informal questions through the front-line service.

Data protection law in Belgium is thus a combination of strictly legal requirements and practical measures. The AVG provides the framework, supplemented by local emphases and enforced by the GBA. By respecting principles such as purpose limitation and data minimization, having an appropriate legal basis for any processing, smoothly facilitating the rights of data subjects, making good agreements with partners, following international rules when exporting data, implementing strong security, having an alert attitude around data breaches, and organizing internal accountability (with a DPO if necessary), companies and organizations can remain compliant. This is not only a legal duty, but also an investment in the trust of customers, employees and the public. Privacy anno 2025 is a value that no company can ignore - in Belgium, the contours are clear, and with the knowledge of regulations as well as the lessons from GBA cases, organizations can adequately arm themselves. Compliance is an ongoing process, but with the right mindset, it is manageable and prevents problems. As the GBA likes to emphasize, data protection is not meant to thwart businesses, but to promote safe and fair use of information - something that ultimately benefits everyone.