Over the past few weeks, commentators have dissected and analyzed the new Israeli data security regulations. Quoting the Israeli Minister of Justice, I characterized them as a landmark piece of legislation due to their scope, level of detail and legal effect. This post addresses several frequently asked questions with respect to the new regulations, including to whom they apply, what is the effective date of their implementation, and how they affect the potential sanctions and powers of the data protection authority. Unfortunately, an English version of the regulations does not exist yet, though given their impact on multinationals doing business in Israel, the Ministry of Justice will likely publish an official translation soon (see Hebrew version here).
To whom do the regulations apply?
The Privacy Protection Regulations (Data Security), 5777-2017, implement the data security requirements of Israel’s Privacy Protection Act, 5741-1981. Like many laws, neither the PPA nor the data security regulations has an explicit geographical scoping provision; rather the PPA applies to database “owners,” the Israeli equivalent of controllers, and “possessors,” i.e., processors of data. Clearly, however, Israeli law doesn’t aspire to regulate the entire world. Hence, to assess the geographical reach of the new regulations, Israeli courts and the regulator will have to apply general choice of law principles.
These will likely lead to application of the regulations to any organization established in Israel that is controller or processor of a database, regardless of where the data subjects may be and whether they are Israelis. However, the regulations will likely also extend to foreign-based entities purposefully processing data about Israeli citizens, consumers or employees. To be sure, a car rental agency in Kansas City will not have to comply with Israeli law based on a random Israeli customer walking into its offices. But a U.S.-based parent company of an Israeli subsidiary, which manages a global HR database including rich data about Israeli employees, or a London-based app developer collecting social networking information about thousands of Israeli users, will have to comply with the new regulations despite a lack of physical presence in Israel.
Of course in these cases, the enforcement powers of the Israeli regulator may be limited. Foreign entities could fly under the radar or choose to assume the legal risk in a country in which they are not present. But as a matter of law, if tested in court, the regulations will likely apply.
Which regulations apply?
As explained in my original piece, the regulations adopt a risk-based approach, applying different rules to databases according to their risk profile. The regulations set up three main risk categories:
- Databases subject to a basic level of security (a residual category under the regulations).
- Databases subject to an intermediate level of security, including, for example, databases containing medical, genetic, biometric or financial data, criminal records or communications metadata.
- Databases subject to a high level of security, comprising those intermediate-level databases that include information about more than 100,000 data subjects or provide authorized access to more than 100 individuals.
In addition, the regulations set forth specific rules for databases maintained by individuals or sole proprietorships, unless these databases cross a certain risk threshold, in which case they are categorized in one of the three buckets.
The first thing a covered company should do is to assess which tranche of regulations applies to it based on three parameters:
- What kind of data does it process; specifically, does it hold any of the data types specified in Section 1(3) of Annex A to the Regulations, placing a database in the “intermediate risk” category?
- How many data subjects are included in its database (more or less than 100,000)?
- How many individuals are authorized to access its database (more or less than 100)?
Next, it should take count of which regulations apply. Reading the relevant provisions in the regulations can leave your head spinning. For example, Section 21(3) of the regulations provides: “The following provisions apply to databases subject to the basic level of security: 1-3, 4(a), (b), (c), (e) and (f), 5(a), (d) and (e), 6(a), 7(a) and (b), 8, 9(a) and (c), 11(a) and (b), 12-15, 17, 19, 20, 22 and 23.”
So one good answer to the question “does this regulation apply to me” is “get yourself a decent lawyer.” But here’s a tip: Usefully, every provision in the regulations actually starts by explicitly saying to which risk category it applies. By default, all regulations apply to databases subject to a basic level of security; but regulations that apply strictly to higher risk databases state so explicitly in the text.
When do the regulations come into force?
May 8, 2018.
How will data breach notification work?
For the first time under Israeli law, the regulations impose an industry-wide data breach notification requirement (Israeli banks have had certain reporting obligations under sector specific rules).
Looking at the breach notification provisions, the first obvious takeaway is what does not appear. The regulations do not require breach notification to data subjects. They state that “upon the occurrence of a serious security incident, a database owner will immediately report the incident to the Database Registrar as well as any steps taken in mitigation.” A “serious security incident” is defined as: “(a) in a database subject to a high level of security, an incident where data from the database was used without authorization or in excess of authorization or where there was a breach of data integrity; (b) in a database subject to an intermediate level of security, an incident where data constituting a material part of the database was used without authorization or in excess of authorization or where there was a breach of the integrity of data constituting a material part of the database.”
Thus, the notification requirement applies to strictly databases of the intermediate or high-risk level. The regulations do allow the regulator to request – after consulting with the Head of the Israel National Cyber Authority – that notification be made to “a data subject who may be harmed by the incident.” Critics argued that the regulations should have gone further, requiring companies to notify data breaches to affected data subjects as well. The GDPR, for example, defaults to individual notification unless “the personal data breach is unlikely to result in a risk for the rights and freedoms of natural persons” (Article 33(1)). In parliamentary hearings, however, the Ministry of Finance cited concerns about the “stability of the economy” (no less) if such a requirement would take hold, resulting in the current notification obligation.
Do the regulations require any special hire or appointment?
The regulations do not require organizations to appoint a chief information security officer (CISO). In fact, such a requirement already exists in Section 17B of the PPA, but only with respect to public sector entities, financial institutions, and organizations that own more than five databases that are subject to database registration requirements (under Section 8 of the PPA). However, if an organization does appoint a CISO, whether under Section 17B or voluntarily, the regulations now require the CISO to report directly to senior management, to be independent and free of conflicts, and to be sufficiently resourced.
What are the sanctions for violating the regulations?
The regulations position the Israeli Law, Information and Technologies Authority (ILITA), in its formal title as the Database Registrar, as an important regulator of data security by Israeli public and private sector organizations. In addition to its authority to receive and expand security breach notifications, the Database Registrar is empowered to exempt a certain controller from the regulations or expand certain obligations to apply to an otherwise uncovered controller.
Importantly, the Database Registrar can certify compliance with an Israeli or international standard, such as ISO 27001, or the data security instructions of another regulator, such as the Supervisor of Banks or the Israel Security Agency (“Shabak”) (under the Act for Regulation of Security on Public Entities, 1998), as satisfying the regulations (Section 20).
At the same time, ILITA’s enforcement powers under the regulations remain very limited. Besides “declaring” a violation of the regulations, ILITA cannot impose any additional sanction in case of a breach. ILITA’s authority to impose fines, as Database Registrar, is grounded in the Administrative Offense (Administrative Fine – Privacy Protection) Regulations, 5764-2004. These regulations, in turn, tailor administrative fines to violations listed in Section 31A of the PPA, including failure to register a database or to appoint an information security officer if required to do so under Section 17B of the PPA; insufficient notice; breach of access and rectification rights; or violation of the direct marketing provisions of the PPA. Conspicuously, these regulations do not set forth an administrative fine for violation of the data security requirements of Section 17 of the PPA, which the regulations now expand.
Failure to comply with the regulations does constitute a civil tort under Section 31B of the PPA, and the regulator’s announcement of a breach could prove invaluable for a plaintiff who chooses to pursue redress in court. Moreover, if violation of the regulations is viewed as a privacy invasion under Section 2 of the PPA, a plaintiff would also be able to sue for statutory damages in an amount up to 50,000 NIS ($13,500).
So, what should I do?
For companies with sophisticated data governance programs, the regulations will not entail a significant lift. Many of the provisions codify best practices and data security standards that have been in the market for years. This includes setting forth and documenting internal policies and procedures for data security; instituting data mapping and managing vendors and vendor contracting; documenting and reporting security incidents; performing risk analyses and – for high risk databases – periodic penetration testing; training employees; carefully managing access controls and authentication procedures; encrypting data in traffic; restricting access to connected devices; initiating audits; and more.
For companies that are behind the curve, the regulations can provide a useful roadmap to effective security, which at the end of the day serves businesses no less than it does their customers and employees.
Photo credit: Israel Flag via photopin (license)