Laws and Regulations
As there are no contracting laws specifically tailored to cloud contracts in Belgium, general contract law applies to cloud contracts (including consumer laws, specific laws for certain kinds of contracts, etc). Contractual arrangements thus need to be heavily relied on in order to cover issues not dealt with under traditional contract law, or dealt with in a way that is not readily applicable to cloud computing. In addition to contract law, a number of other laws and regulations also apply to specific issues or aspects of cloud solutions.
NIS Directive and NIS Act
The Directive on Security of Network and Information Systems (NIS Directive) mainly aims to strengthen critical infrastructure in the EU, but also contains provisions regarding cloud computing. Providers of critical infrastructure have to comply with the (national implementation of the) security requirements of the NIS Directive – ie, the requirement to adopt appropriate security measures.
The NIS Directive was transposed into Belgian law through the Belgian NIS Act of 7 April 2019, and its executing Royal Decree of 12 July 2019. Although this legislation is very recent, the European legislator has already published a proposal for a NIS II Directive, extending its scope and strengthening its rules.
The Belgian Act of 13 June 2005 on Electronic Communications (AEC) only applies to "services consisting wholly or mainly in the conveyance of signals on electronic networks, including telecommunication services". Content services, therefore, are not covered by the AEC.
In this context, the applicability of the AEC will depend on the extent to which the cloud computing service focuses on the conveyance of signals (see 8.1 Scope of Telecommunications Rules and Approval Requirements). Where this framework applies, national regulatory authorities will have certain powers over the service provider and consumers will be afforded greater protection.
Regulations in Specific Industries
To date, there are few sector-specific rules in Belgium in relation to cloud services, as several sectors have rules in relation to outsourcing in general (eg, in the banking and insurance sector).
In 2019, for instance, the National Bank of Belgium (NBB) issued a new circular on outsourcing arrangements (the Circular) that applies to a wide number of financial institutions. With the Circular, the NBB has fully integrated the European Bank Authority Guidelines on outsourcing arrangements of 25 February 2019 (the EBA Guidelines) in its supervisory practices.
In order to be compliant, financial institutions wishing to outsource part of their activities must, among other things, ensure that the outsourcing contract provides for a range of obligations and must submit a file to the regulator in certain circumstances. Similar obligations exist for (re-)insurance companies.
Processing of Personal Data
The General Data Protection Regulation (GDPR) is applicable to all processing of personal data. To the extent that the data uploaded by an organisation includes personal data, the GDPR will also be applicable to cloud solutions and will have to be taken into account by both cloud providers and users (see 6.1 Core Rules for Individual/Company Data). A number of issues tackled by the GDPR can be especially problematic with regard to cloud solutions (eg, data transfers to third countries).
For instance, the GDPR prohibits data transfers to third countries not considered to have an adequate level of data protection – that is, that do not have the appropriate safeguards (eg, binding corporate rules, standard contractual clauses, an approved code of conduct or certification mechanism) in place. If a cloud provider has data centres in such third countries, this requirement should therefore be taken into account. In July 2020, the Court of Justice of the European Union (CJEU) invalidated the EU-US Privacy Shield in the so-called Schrems II decision, which has created significant uncertainty for many companies. The European Data Protection Board (EDPB) issued FAQs regarding the Schrems II decision, providing guidance on a number of topics and indicating that more is to come.
Moreover, the obligation to notify data breaches to both data subjects and data protection authorities will typically require more extensive involvement of the cloud service provider than in the case of local IT solutions, given the typically greater reliance on the cloud service provider.
In cloud computing contracts, other aspects have to be carefully planned, such as the question of return or destruction of personal data, the question of liability of the provider, etc. In this respect, the working group on Switching Cloud Providers and Porting Data (SWIPO) presented two data portability codes of conduct to the European Council and European Commission, which were published in May and July 2020.
Risk and Liability
Heralded by some as the most important development in information technology since the internet, dismissed by others as a mere buzzword, blockchain technology, and distributed ledger technologies (DLTs) more generally, appear to form a challenge to traditional legal concepts and categories.
While it is still difficult to truly identify any regulatory trends concerning blockchain, most legal systems seem to lean towards a sector-specific approach, preferring to adapt existing legal frameworks to specific blockchain applications instead of adopting one comprehensive framework for blockchain or DLTs.
This has been the approach in Belgium so far, and there are few signs that a comprehensive framework for blockchain technology as such will be adopted in the near future. Nevertheless, some separate regulations concerning concrete applications of blockchain technology, such as cryptocurrencies or smart contracts, are currently being discussed or suggested by industry insiders or regulatory bodies. For instance, in September 2020, the European Commission issued a proposal for a regulation regarding the regulatory framework for crypto-assets, aiming at protecting cryptocurrency users and controlling financial and monetary stability.
Criteria for "money"
Like initial coin offerings (ICOs), the main challenges in Belgium for cryptocurrencies stem from the lack of legal qualification. Under Belgian law, three criteria are combined to define "money":
It is unclear today whether cryptocurrencies satisfy these three criteria, but the general tendency seems to be to consider that these criteria are not (always) fulfilled by cryptocurrencies, which thus do not constitute "money" or even "electronic money" in the sense of Directive 2009/110/EC. Indeed, to the extent that cryptocurrencies do not represent a claim on the issuer and as they are not necessarily linked to "real money", they cannot be considered as "electronic money".
The consequence of this legal vacuum is, on the one hand, that no licence or formality is legally required to issue cryptocurrencies and they are not subject to regulatory supervision and, on the other hand, that they do not benefit from any legal protection.
The FSMA and NBB have on several occasions highlighted the risks of cryptocurrencies, including the risk of hacking of trading platforms or wallets, operating risks (risk of fraud), the exchange rate risk and the lack of a legal guarantee that it can be exchanged for its face value.
Moreover, as early as 2014, the FSMA issued a regulation (approved by the Royal Decree of 24 April 2014) that bans products that essentially consist of derivatives based on "digital currencies" (with digital currencies being defined as "any form of unregulated digital currencies which are not legal tender").
Lastly, concerning questions of taxation, and in particular VAT, the Court of Justice of the European Union (CJEU) appears to consider that, for the purposes of the VAT Directive, cryptocurrencies qualify as "money".
This stems from the CJEU's judgment of 22 October 2015 (case C-264/14, David Hedqvist), in which it held that transactions consisting of "the exchange of traditional currency for units of the ‘bitcoin’ virtual currency and vice versa, in return for payment of a sum equal to the difference between, on the one hand, the price paid by the operator to purchase the currency and, on the other hand, the price at which he sells that currency to his clients" constitute a "supply of services" in the sense of the VAT Directive.
Moreover, according to the CJEU, the VAT exemption regarding "currency [and] bank notes and coins used as legal tender" also applies to the bitcoin virtual currency (and by extension, other cryptocurrencies).
Besides the above-mentioned points, several aspects of cryptocurrencies remain unregulated in Belgium. For instance, cryptocurrency mining is not a regulated activity, there are no exchange or currency control restrictions, and there is no obligation to declare cryptocurrency holdings.
Blockchain and GDPR
Data protection neutrality
In a report of 16 October 2018, the EU Blockchain Observatory and Forum (the Observatory) stated that "there is no contradiction in principle between the goals of the GDPR and those of blockchain technology" due to the technologically neutral manner in which the GDPR was drafted.
However, the Observatory added that, depending on the organisation of the network, difficulties could arise in relation to, for example, data minimisation and the rights to erasure and rectification (in particular due to data immutability), accountability (difficulties in determining the role of each person or entity involved) and international data transfers (due to the global nature of blockchain networks).
Resolving the conflict
Without genuine case law on the matter, it remains difficult to predict the level of compliance of some implementations of blockchain technology.
According to the Observatory, however, the GDPR does not mean the end of blockchain innovation or of public blockchain networks in the European Union. It adds that four principles should be kept in mind by those designing blockchain-based applications:
Smart contracts are self-executing instructions written in code that automatically execute a transaction if certain conditions set out in the code are met. The performance or non-performance of the instructions is thus in theory out of the hands of the contracting parties. Smart contracts can be blockchain-based, in which case, the contract itself exists in the blockchain and different stages of execution are recorded therein.
Concrete applications in Belgium
Blockchain-based smart contracts are often said to have a wide array of applications (ranging from service-level management to IP-right control and collection). In Belgium, however, the number of actual applications remains rather low.
So far, Belgian law is lagging behind, as there is still no regulation of such smart contracts. Until the adoption of regulation, the general contract rules will thus have to be applied mutatis mutandis, taking into account the specificities of smart contracts.
The era we are currently living in is one that is characterised by big data, machine learning and artificial intelligence (AI). Although it brings great capabilities and possibilities with it, there is a degree of uncertainty regarding the magnitude of what it can achieve, as well as the legal consequences thereof.
AI, in its broadest sense, does not only cover "Terminator"-like AI but also augmented intelligence – namely, data-powered products and services. While the idea of AI capable of replacing humans altogether raises significant future questions, the more immediate legal concerns relate to the simpler AI systems that are already present in society today, from natural language analysis tools to home assistants and automatic recommendations for music, video or other products.
As one of the characteristics of AI is that it can take decisions with a degree of autonomy, the question of liability ("who is responsible when an AI system causes damage or breaches the law?") quickly emerged. In this respect a recent report was adopted by the European Parliament on 20 October 2020 which details recommendations on how AI should be regulated with regard to civil liability.
In addition, the Report contains a draft proposal for a regulation on such civil liability regime, proposing a strict liability regime for operators of high-risk AI systems – ie, they would be liable for any harm or damage caused by physical or virtual activity, device or process driven by that AI system. Until the finalisation of these European initiatives, certain approaches may be taken under Belgian law.
Regarding non-contractual liability, Belgian law sets out three conditions that need to be fulfilled for liability to be attributable to a party: fault, damage and a causal link between the two. The burden of proof lies with the claimant. Where an AI system causes harm, however, it may be difficult to determine with precision which action or inaction led to the breach or damage and whether it was a "fault".
One possibility to increase legal certainty (also proposed in the European Parliament's resolution) would be the introduction of a strict liability regime for harm caused by robots, similar to the regime found in rules implementing the European Union's Product Liability Directive. Such rules on product liability can already be applied in cases where an AI system is considered as a tool or product that is not fully independent in its behaviour. In other cases, a regime of "objective responsibility" – which already exists in Belgium for animals and children (ie, liability for beings/things under a person's responsibility or control) – could contribute to legal certainty.
However, it remains unclear to what extent these liability regimes could stifle AI-related innovation or its take-up by end-users.
Due to the lack of rules that can appropriately cover all relevant scenarios, organisations working on projects involving AI systems must carefully regulate liability in their contractual arrangements, including matters that have an indirect impact on liability (eg, applicable law and choice of jurisdiction).
AI systems process vast quantities of data, including personal data in most cases. In accordance with the requirements of the GDPR, key requirements such as data minimisation and privacy by design have to be taken into account when creating or working with AI systems in Belgium.
There are a few exceptions under Belgian law to the GDPR, the most notable one relating to minors: if the processing is based on consent and relates to an information society service, only individuals aged 13 or older are able to give their consent without needing that of their guardian or parent.
Most relevant in this respect is copyright. The conditions of copyright – namely a "work" that is "original" – have been interpreted by the CJEU and are, to a certain extent, similarly applied throughout the EU. This means that the same issues will be faced by all the countries in the EU – eg, "who will be the author when an AI system makes a work of art?"
The first component of originality, also known as the "objective component", holds that the work must be the result of an intellectual creation. The second component, known as the "personality requirement" or "subjective component of originality", holds that a personal touch must be given to the work in order to reach the threshold of originality. From these criteria it can be deduced that human input is a prerequisite for copyright.
As AI systems are not likely to be able to claim copyright protection in the near future, the creator of the AI system (the legal or natural person) should document the process of creation and arrange internal assignment of all IP rights, including copyright, to themselves, following the principle of Belgian property law that "the fruits of a good belong to the owner of the good".
There is no strict definition of the internet of things (IoT), so for the purpose of this question the collection of devices that have the ability to sense, amass and analyse data, and to communicate through networks will be considered as the IoT.
The first important legal framework that needs to be taken into account is data protection law. Because of the nature and goal of IoT devices (ie, smart mobile applications, smart home units, wearables, home assistants, etc), large amounts of data are being collected and processed, some of which will be considered personal data under the GDPR.
The applicability of this framework has a number of consequences as to how IoT devices should be designed (in particular the overarching principle of "privacy by design").
Not all IoT devices and services are organised along the lines of traditional graphical user interfaces, so asking for consent cannot always be worked directly into the functionality. As a result, IoT manufacturers and resellers must think of alternative ways to collect consent, in such a way that it meets the requirements of the GDPR: consent must be freely given, specific, informed and unambiguous.
The GDPR requires that the personal data used is relevant and limited to what is necessary in relation to the purpose for which it is processed. This is a direct challenge to the data maximalism that is typical of IoT devices and services. One suggested way to keep this balance is edge computing, which allows the devices themselves to select the data necessary for processing further down the line.
Data protection impact assessments
The Belgian Data Protection Authority has set out a number of scenarios in which a data protection impact assessment (DPIA) is mandatory, and one of them specifically concerns the deployment of certain kinds of IoT devices (ie, large-scale processing of data generated by devices with sensors sending data over the internet or any another means for the purpose of analysing or predicting individuals’ economic situation, health, preferences or personal interests, reliability or behaviour, localisation or movements).
In addition to data protection considerations, cybersecurity also needs to be taken into account. Various authorities internationally have expressed concern regarding the security of a lot of IoT devices, as these devices have the potential to enable the misuse of information, unauthorised access or attacks on other systems.
In Belgium, there are no specific minimum-security requirements, but specific sectors have requirements in relation to data breach notifications (eg, telecommunications, critical infrastructure, finance in specific cases) and data protection rules also provide for notification obligations in relation to personal data breaches.
ePrivacy Directive (M2M)
Under the ePrivacy Directive 2002/58/EC (ePD), the question is whether machine-to-machine communications (M2M) – eg, the communications between an IoT device and the server of the vendor/service provider – are protected by the ePD's rule of confidentiality of communications.
This question was not settled based on the wording of the ePD (which refers to "parties" to a communication), or in Belgium based on the wording of the Belgian implementation (in the Criminal Code, which refers to "participants").
The draft ePrivacy Regulation, still in discussion stages at the level of EU institutions (the latest draft thereof has been released under the Portuguese EU Council Presidency in January 2021), aims to resolve this by clearly covering IoT services and devices. Current drafts would provide for confidentiality of communications, M2M included, which could impact the way in which certain organisations use IoT devices today. The latest draft also specifies that ePrivacy Regulation should apply regardless of whether the processing of electronic communications data or personal data of end-users who are in the EU takes place in the Union or not, or of whether the service provider or person processing such data is established or located in the EU or not.
Today, most companies creating IoT services or devices do so with their own separate infrastructure. As IoT devices and services become more prevalent, the question of interoperability of devices, networks and platforms will inevitably arise.
Within the ongoing efforts to create a European Digital Single Market, the EU has dedicated publications to interoperability architecture for IoT. While this is not currently a legal requirement, it is highly recommended to consider the question of interoperability with existing services, whether through adopting an open architecture, integrating a third-party architecture (eg, by way of an application programming interface or API) or making available a software development kit (SDK) for others to use for interoperability.
There are no particular requirements under Belgian law in this respect.
Qualification of Contract
"IT service agreement" is a broad term that can encompass (and combine) several kinds of IT services, such as licensing, maintenance, outsourcing or even developing of software. When concluding or reviewing an IT agreement it is important to qualify it appropriately to specify the applicable legal framework. In particular, it is important to check whether the agreement fits within the framework of one (or several) of the legally defined contracts under Belgian law.
The Belgian Civil Code (BCC) names several kinds of agreements, such as construction agreements or commercial agency agreements, and provides both mandatory rules (ie, from which one cannot deviate by contract) and supplementary rules (ie, rules that apply when the agreement does not cover that specific issue) that may apply to these kinds of agreements. If an agreement does not fit into the framework of any of the legally regulated contracts, parties enjoy a broad contractual freedom, but must ensure that they regulate all the important aspects in detail to avoid any legal gaps.
An important part of any IT agreement is the set of service levels applicable to the contract, namely the commitment in practice by the supplier or service provider – eg, to a certain percentage of delivery, accuracy, availability, etc, or to responding within a specific number of days or hours to a request or issues. Service level agreements (SLAs) typically apply to the contractual annexes on service levels.
Nature of obligations
The description of these service levels is crucial for their legal classification under Belgian law, which makes a distinction between obligations to attain a specific result (obligation de résultat/resultaatsverbintenis) and "obligations of means" (obligation de moyens/middelenverbintenis), the latter often translated into English as a "(commercially) reasonable effort" obligation.
In the case of a result obligation, the simple failure to reach the result will be viewed as a "fault" (ie, non-performance) that can trigger liability; for obligations of means, however, a higher threshold applies and the party claiming liability must be able to demonstrate that the defaulting party did not do all that was (commercially) reasonable.
SLAs: not just an IT matter
In many companies in Belgium and abroad, SLAs are often drawn up by IT teams without properly taking the actual terms and conditions of the agreement into account. One must ensure that an SLA has been checked or drawn up in consultation with the legal department to avoid legal misunderstandings.
Service levels are presumed to be result obligations, unless stated otherwise in the agreement, but service providers prefer to transform them into obligations of means – for example, by including expressions such as "to the best of its ability" or "strive" in the SLA. In that case, the service provider can only be held liable when non-compliance and fault can be proved by the customer. The customer, on the other hand, will aim for more certainty by using terms such as "guarantees", "ensures" or "result" in the SLA; in which case, the service provider can be held liable if the results and milestones set out in the SLA have not been achieved (except where this is attributable to the customer or to force majeure).
Contracting parties may limit or exclude their liability in an IT services agreement. This can be done by the incorporation of a liability clause or through the wording of the obligations, the inclusion of assumptions and a broad definition of force majeure.
Under Belgian law, however, parties cannot exclude or limit their liability for their own wilful misconduct or fraud. As a result, liability clauses typically include caveats in this respect. Should there be none, the entire agreement, or at least the liability clause, could be held void, according to the principle that if any of the terms of a contract prove to be inapplicable or contrary to a mandatory provision of the law, the validity of the entire contract must be examined. The risk of such a discussion can be mitigated by including a "severability" clause, stipulating that if any (part of a) provision is or becomes illegal, invalid or unenforceable, this shall not affect or impair the legality of any other (part of a) provision of the IT services agreement.
Intellectual property (IP) plays an important role in IT services agreements. IT services often go hand in hand with the use of pre-existing IP of the supplier, pre-existing IP of the customer and third-party IP. Sometimes an IT services agreement involves the creation of something new which might also be protected by IP.
Contrary to what is often believed, there are various options to divide the IP on a new creation between the parties, ranging from, on the one hand, full ownership for the supplier to full ownership for the customer. In an IT outsourcing agreement, the pre-existing IP typically remains with each party, with a form of cross-licensing (each party grants a licence to the other for the use of its own pre-existing IP).
In the case of a software as a service (SaaS) agreement, all IP rights on the SaaS solution are reserved for the SaaS service provider, but this party typically grants the customer a non-exclusive, non-transferable, worldwide, limited right to use and access the SaaS solution for internal business purposes.
A step-in right is a discretionary right for a customer to partially or fully take over services or appoint a third party to deliver services instead of the supplier. The foundations for step-in are Articles 1143–1144 BCC, which case law is interpreted as permitting step-in without prior court intervention, subject to certain cumulative requirements (ie, urgency, a prior determination that there is a contractual breach, a prior notice to remedy the breach, immediate involvement of the third party after expiry of the notice period, and good faith).
The step-in principle is not mandatory law and parties may contractually exclude step-in or alter its conditions by adding scenarios in which step-in is possible (for instance, if the supplier causes material interruption or disruption of services, exceeds service credit levels during a certain period, etc).
As from December 2020, a new Belgian Act regulates several aspects of B2B relationships. In essence, it prohibits:
In the context of IT services agreements, the most relevant part pertains to unfair terms. The Act foresees as a black list (presumed to be unlawful without possibility of rebuttal) and a grey list (presumed to be unlawful until proven otherwise):
Core Rules Regarding Data Protection
Under Belgian law, data is protected differently depending on the person to whom it relates. If data relates directly or indirectly to an identified or identifiable natural person, it will be considered as personal data; otherwise, it is referred to hereunder as non-personal data.
Personal data is protected by the GDPR and by its Belgian implementation, the Belgian Privacy Act of 30 July 2018 (BPA); see "Processing of Personal Data" in this section. Non-personal data, on the other hand, is not regulated in any particular way, except perhaps as trade secrets in certain cases; see "General Processing of Data" in this section.
General Processing of Data
Under Belgian law, non-personal data can benefit from protection as a "trade secret" if the holder of the data can prove that:
In such a case, the holder will be able to file cease-and-desist proceedings, to seek an order for penalty fines for non-compliance, and/or an order for publication of the judgment. Proceedings on the merits are then required within a certain period of time if the cease-and-desist proceedings are successful.
Processing of Personal Data
Under the GDPR, personal data may be processed (used, stored, transferred, manipulated, etc) subject to a number of requirements. The overarching principles of the GDPR are: lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability.
One key feature of the GDPR is the range of data subject rights – ie, the rights that an individual (the data subject) can exercise vis-à-vis the person or entity in charge of the processing (the "controller"): information and access rights; rights to rectification and erasure; rights to restriction, to object and to withdraw consent; right to data portability. Taking all of these rights into account requires careful consideration, and their implementation in IT systems is not always easy.
The BPA complements the GDPR on certain topics:
From an enforcement perspective, it is worth noting that the Belgian Data Protection Authority (DPA) has taken its role seriously by issuing almost 100 enforcement decisions in 2019 and 2020. In 19 of those decisions, the DPA imposed an administrative fine. The largest fine issued to date by the DPA was the fine of EUR600,000 imposed on Google in its decision of 14 July 2020 for several violations, including violations of transparency requirements and the right to be forgotten. The total value of fines imposed in 2019 and 2020 amounted to EUR835,500.
Personal Data and Monitoring
As soon as there is any form of monitoring of employees, the rules of the GDPR come into play. Aside from the general principles of the GDPR, it is likely that a data protection impact assessment (DPIA) will be needed in the event of employee monitoring: while the Belgian DPA has not included employee monitoring as a scenario for which a DPIA is mandatory, the core criteria ("monitoring" and employees as "vulnerable data subjects" in a power imbalance scenario) are two elements which, when combined, lead to an automatic recommendation across all of the EU to carry out a DPIA.
In addition, specifically for electronic online communication means (internet, email, etc), the Collective Bargaining Agreement No 81 (CBA 81) provides for a set of specific requirements. CBA 81 makes a distinction between the monitoring in general of employees' use of IT resources and the individualisation of the data obtained in the course of such monitoring.
"Individualisation" means the attribution of the data collected to one or more identified or identifiable individuals. For example, an employer might collect information on the number of emails sent in the course of a day; if the employer looks at the behaviour of one particular employee, there will be "individualisation".
Technologies within Local Telecommunications Rules – EU Approach
The Belgian telecoms rules are heavily influenced by EU rules. This is even more so since the adoption of the Electronic Communications Code Directive, and will be even more so if the EU adopts the long-awaited e-Privacy Regulation. Regarding the latter, however, it does not seem that the current deadlock concerning this piece of reform will be resolved soon, so that its future remains uncertain.
With the adoption of the European Electronic Communications Code (EECC), a first step towards a uniform EU-wide telecoms framework had already been taken. This has been reinforced by the adoption in December 2019 of an Implementing Regulation by the European Commission, establishing a template for the contract summary that electronic communications services operators need to provide to consumers within the EU before the conclusion of a contract. This summary must include the main conditions of the contract (eg, price, services and internet speed) and is required as of 21 December 2020.
Although the EECC imposes a transposition by 21 December 2020, the EECC has not yet been implemented into the Belgian legislative framework. Based on the draft law transposing the EECC, however, the Belgian legislator mostly seems to intend to stay as close to the text of the EECC Directive as possible. In any event, as of now, the 2002 EU telecoms framework and the interpretation issues revolving around it still remain relevant.
We will thus, for the purpose of this contribution, set out the 2002 EU telecoms framework and, where relevant, point out EECC additions, amendments and/or differences.
The Regulatory Framework for Electronic Communications, as introduced by the 2002 telecoms package (including the ePD), was in principle aimed only at the transmitter of the communications. This resulted from Article 1 of Directive 2002/21/EC of the European Parliament and of the Council of 7 March 2002 on a common regulatory framework for electronic communications networks and services (Framework Directive), which defines the scope of the Framework Directive (and thus the telecoms package) as applying to providers of "electronic communications services (ECSs), electronic communications networks (ECNs), associated facilities and associated services".
The EECC has an almost identical scope delimitation, albeit that “certain aspects of terminal equipment” are now also included in the scope of the EECC. In addition, through the broadening of the definition of ECS, the scope of the EECC has also been broadened, in comparison with the 2002 telecoms framework.
ECS and ECN
Hence, according to the 2002 telecoms framework, only services consisting wholly or mainly in the conveyance of signals – as opposed to, for instance, the provision of content – fall within the scope of the ECN/S Framework (and thus also of the ePD). As such, where no signal is being conveyed, or where this is not the main purpose of the service, the telecoms package (including the ePD) does not apply. The question thus becomes what exactly can be considered an ECN or ECS in the sense of the ECN/S Framework.
The new framework contains a new, broader definition of ECS. While this new definition still excludes “services providing, or exercising editorial control over, content transmitted using electronic communications networks and services”, certain services which were previously not subject to telecom rules, now fall within the scope of the EECC.
Traditionally, over-the-top (OTT) services have been considered to fall outside the scope of the telecoms package. Regarding the ePD specifically, this has been confirmed on numerous occasions, most notably by the Article 29 Working Party (WP29) in its Opinion 03/2016 on the evaluation and review of the ePD, where it states that the scope of the ePD "is mostly limited to traditional electronic communication services (such as internet service providers and telcos). Many of its provisions do not apply, for example, to internet telephony (VoIP) or email and instant messaging providers."
OTT and ECS under EU rules
Nevertheless, some OTT services can sometimes be considered to form an ECS in the sense of the 2002 telecoms package. While no legal definition of OTT services currently exists, in a report published in 2016 the Body of European Regulators for Electronic Communications (BEREC) defined OTT services as "content, services or applications that are provided to the end-user over the public internet", and the BEREC examined whether some OTT services could be considered to fall within the scope of the ECN/S Framework.
According to Article 2(c) of the Framework Directive, to qualify as an ECS, a service must meet three criteria:
Remuneration: this criterion is usually met for OTT services, as it essentially implies "that the service should consist of an activity of an economic nature, opposed to the social services of non-economic nature provided usually by the state". Moreover, that remuneration, according to the case law of the CJEU, in the context of information society services, must not "necessarily be provided by the recipient of the service himself" but can also (for instance) be provided by "income generated by advertisements posted on a website".
Conveyance of signals: according to CJEU case law, the defining criterion is whether the service provider is "responsible vis-à-vis the end-users for transmission of the signal which ensures that they are supplied with the service" and "the fact that the transmission of signals is by means of an infrastructure that does not belong to the [service provider], is of no relevance to the classification of the nature of the service". However, the exact application of this criterion still remains unclear, and based on the BEREC's report, this criterion appears to be the main delineating criterion for determining whether an OTT service constitutes an ECS.
No editorial control over content: this is an exclusionary criterion, and OTT services exercising editorial control over content will not be considered an ECS in the sense of the ECN/S Framework.
The CJEU has held in the context of two preliminary reference cases, that:
Through its broader definition of ECS, the EU legislator has now opted to include a number of OTT services in the scope of the EECC. For instance, "interpersonal communications services", defined as “a service normally provided for remuneration that enables direct interpersonal and interactive exchange of information via electronic communications networks between a finite number of persons, whereby the persons initiating or participating in the communication determine its recipient(s) and does not include services which enable interpersonal and interactive communication merely as a minor ancillary feature that is intrinsically linked to another service” are now explicitly included in the scope of the EECC. The Belgian draft law transposing the EECC sets out an almost identical definition, so that most OTT services will in the future be considered an ECS under Belgian law.
Technologies within Local Telecommunications Rules – Belgian Approach
As set out above, in Belgium, the EECC has not been implemented yet. Consequently the EU telecoms package, as integrated mainly within the Act of 13 June 2005 on Electronic Communications (AEC), remains relevant for the time being. As most definitions used in the telecoms package are substantially the same in the AEC, the question of what constitutes an ECS or ECN is consequently substantially the same at the Belgian and at the EU level.
The transposition of the EECC will resolve a number of interpretation questions discussed below. Even more than is currently the case, interpretation questions will thus likely be substantially the same at the Belgian and at the EU level.
VoIP Skype case
The aforementioned VoIP Skype case was submitted to the CJEU by the Belgian Court of Appeals. The main question submitted for reference concerned precisely this: must VoIP services such as Skype be considered an ECS? The court answered that they indeed qualify as ECS provided that:
Under the EECC, Skype is in principle considered an ECS.
Regarding radio-frequency identification (RFID) tags, the general consensus in Belgium seems to be that they are not subject to the telecom rules. While the "conveyance of signals" criterion seems to be met, RFID tags typically fail at the level of the "editorial control" criterion. Indeed, in the case of RFID tags, the provider of such tags seems to be the one deciding on the content that is transmitted.
However, should an RFID tag provider be found to have no such editorial control, then this service would, according to the BEREC's classification, be considered as an ECS and thus fall within the scope of telecoms rules.
As the EECC’s new definition of ECS explicitly excludes “services providing, or exercising editorial control over, content transmitted using electronic communications networks and services”, RFID in principle fall outside the scope of the EECC.
It is to be noted, however, that irrespective of their classification as ECS or not, RFID tags are considered "radio equipment" by the Belgian Institute for Postal Services and Telecommunications (BIPT) and as such are subject to the rules laid down in the AEC. In particular, they have to use Band B07-04 (865-868 MHz), and are exempt from a licence, but are subject to the prescriptions of the BIPT.
Consequence where no ECS
To the extent that these (OTT, RFID, etc) services do not fall within the scope of telecoms rules, there is in principle no requirement for approval by the regulator prior to offering any such products or services on the Belgian market.
Broader scope under the EECC
As explained above, after the transposition of the EECC, the interpretation questions mentioned above should to a large extent be resolved, as the EECC (which had to be implemented in national legislation by the aforementioned date) broadens the scope of the ECN and ECS concepts.
Similarly, the future e-Privacy Regulation, according to the latest drafts, will have the same broader scope and thus will apply to those OTT services. As previously mentioned, RFID tags, however, still seem to fall outside this new, broader scope.
Place of establishment
In Belgium, the community level of government (Flemish, French and German-speaking) is in charge of the regulation of audio-visual services in its respective territory, based on the place of establishment of the provider. By way of an exception, the federal government has the power to regulate audio-visual services established in the capital region, Brussels, unless they need to be considered as belonging to the Flemish or French community because of their activities.
Under Flemish radio and TV broadcasting rules, radio broadcasting is subject to prior authorisation (by the Flemish government), which is valid for nine years; a similar rule applies to regional (as opposed to national or local) television broadcasting. For other forms of broadcasting, no authorisation is required, but a notification process applies.
Broadcasting organisations must be established as a legal entity, and there are limitations on the number of broadcasting organisations that such a legal entity can operate. Moreover, their broadcasting station must be located in Flanders or in the Brussels region.
The Flemish decree contains various other requirements, the applicability of which depends on the nature of the service:
The Flemish government also imposes additional qualification criteria pertaining to the programme selection and transmission schedule, media experience, financial plan, business plan and technical (broadcast) infrastructure.
Pursuant to the decree of the French community, all audio-visual and radio services must be established as a legal entity and ensure that an editorial team is responsible for information programmes (with journalists who are members of a specific professional organisation).
Audio-visual services in the French community must notify the regulator (Conseil Superieur de l'Audiovisuel, CSA) before they start their activity, but the rules differ for local TV broadcasting organisations. For radio, a CSA authorisation (valid for nine years) is required.
While the Flemish decree makes a distinction between national, regional and local radio broadcasting organisations, the French community's decree makes a distinction between network radio broadcasting and independent broadcasting organisations.
As in Flanders, French-speaking radio services are subject to specific requirements in terms of language, music origin (eg, at least 30% of the music broadcast must be French-language music and at least 6% must be musical works by artists, performers or independent music producers whose domicile, head office or registered office is in the French-speaking region or in the Brussels region), own productions, etc.
Online Video Channels
In addition to these region-specific and service-specific obligations, there are certain general obligations that apply to all audio-visual services, for example, in relation to advertising and broadcasting events of great importance for society.
Specifically in relation to online video channels, on the French-speaking side, in March 2012 the CSA published a recommendation on the scope of regulation of audio-visual media services, which seems to suggest that putting a few videos online will not fulfil the relevant decree, unless there is a systematic structure to organise videos so as to make them into an audio-visual "programme".
As for video-sharing platforms themselves, their services fall under the scope of the recently amended Directive (EU) on Audiovisual Media Services. EU member states have until 19 September 2020 to bring into force the laws, regulations and administrative provisions necessary to comply with this directive. Currently, none of the legislators in Belgium has yet transposed the directive into its legislative system. The EU Commission has therefore sent a notice letter, inviting Belgium to submit additional information in that regard.
Legal Requirements Governing the Use of Encryption
Article 48 of the AEC states that the use of encryption in Belgium is free. The law guarantees the freedom to use encryption, without any restriction as to its complexity. The government is allowed to adopt a royal decree requiring notification of certain encryption services to the Belgian Institute for Post and Telecommunication (BIPT) but, to date, no such royal decree has been issued. Next to this general provision, there is no legislation (and no general policies) regarding mandatory minimum or maximum encryption strength, licensing/registration requirements, or import and export controls.
Nevertheless, where encrypted communications are involved and may be relevant to criminal investigations, Belgian law imposes obligations on providers and individuals to assist the authorities in the course of their investigations, by providing information on the encryption mechanism and on how to obtain the unencrypted information.
Data protection law contains references to encryption, which can affect the way in which the rules apply to organisations and their daily business.
Despite the fact that the use of encryption is not required, it is highly recommended in the field of data protection. More specifically, encryption is considered as a possible measure in order to comply with security obligations and is one way to implement the principles of data protection by design and by default. Moreover, encryption can help limit the chances of a personal data breach requiring notification to the data subject, or sometimes even to supervisory authorities. Encryption can also help with data minimisation, which is an important principle under the GDPR.
Encryption can also exempt a company from the duty to communicate a personal data breach to the data subjects, where encryption measures were applied to the affected personal data, making it unintelligible to any person who is not authorised to access it. Sometimes, the circumstances and use of encryption can even lead to an exemption from the obligation to notify the supervisory authority.
Encryption measures are, in practice, a form of pseudonymisation, as by encrypting the information that enables identification of the data subject to whom a set of personal data relates, the remainder cannot be attributed to the specific data subject without the use of additional information, namely the decryption key. As a result, those other data elements can be used more easily for archiving purposes, in the public interest, for scientific or historical research or statistical purposes. The BPA includes a range of rules on such processing – for example, requiring that such pseudonymisation is conducted before subsequent processing takes place.
In other words, encryption is strongly encouraged in the realm of data protection, as a measure to increase the security and confidentiality of personal data and to enable processing of data as pseudonymised data, rather than simple, freely readable personal data.
Following the COVID-19 outbreak, many emergency plans and regulations have been adopted. However, in the context of technology transactions, the main issue raised by the pandemic has been to determine to what extent a party to a contract could rely on the pandemic to justify (temporary) failure to perform its contractual obligations. Best practice would be to identify as to what extent pandemics are included in the contractual definition of "force majeure". If no clause provides for it, the analysis must be made in accordance with the standard legal criteria. This entails a legal assessment in light notably of Articles 1147 and 1148 Belgian Civil Code, and the doctrinal definition of a force majeure event. For future technology contracts, it is advisable to specifically mention "pandemic" within the contractual definition of force majeure.
Obviously, the situation in respect of the COVID-19 pandemic is subject to change – as a result of which, further emergency legislation, relief programmes and other initiatives may be adopted in the future.