Posted in International Privacy New Privacy Laws Privacy and Data Security

By Eamon Holley on

Written by Mohamed Toorani and Eamon Holley

On 12 July 2018, the Kingdom of Bahrain (Bahrain) issued Law No. 30 of 2018 on the Personal Data Protection Law (PDPL). The PDPL will enter into force on 1 August 2019, giving businesses just under one year from the date of this article to prepare for the new regime.

The PDPL will be a paradigm shift for how business is done in Bahrain. It will provide individuals with rights in relation to how their personal data can be collected, processed and stored. Conversely, it will impose new obligations on how businesses manage this, including ensuring that personal data is processed fairly, that data owners (often referred to as “data subjects” in other data protection laws) are notified of when their personal data is collected and processed and that data owners can exercise their rights directly with the businesses.

The PDPL also imposes new obligations upon businesses to ensure that the personal data they collect is kept secure.

The PDPL will set up a new authority, known as the Personal Data Protection Authority (Authority). This Authority has the power to investigate allegations of violations of the PDPL either by itself, at the request of the responsible Minister, or in response to a complaint.

The Authority can issue orders to stop violations, including issuing emergency orders and fines. Civil compensation is also allowed for any individual who has incurred damage arising from the processing of their personal data by the data manager (often referred to as a “data controller” in other data protection laws), or violating the provisions of the PDPL by a business’s data protection supervisor (often referred to as a “data protection officer” in other data protection laws). Finally, the most concerning feature of this law for businesses is that the PDPL carries criminal penalties for violations of certain provisions.

While the PDPL can be compared to laws such as the European Union’s General Data Protection Regulation (GDPR), there are important differences that need to be considered. Businesses operating in Bahrain that have recently implemented a GDPR compliance program will still need to pay close attention to these differences and should be aware of the new obligations in the PDPL.

In this article we review some of the main features of this new law.

APPLICATION

The PDPL applies to:

  • Individuals normally residing or having a workplace in Bahrain
  • Businesses with a place of business in Bahrain; and
  • Individuals not normally residing or having a workplace in Bahrain, and businesses not having a place of business in Bahrain, but processing personal data by using means available in Bahrain, unless the use of such processing means are solely for the purpose of passing data through Bahrain without any other purpose

In the last scenario, each business must appoint a local representative in Bahrain to carry out its obligations and notify the Authority of that appointment. The PDPL will therefore have extra-territorial effect. If an individual or business not in Bahrain is processing personal data within Bahrain through means such as their appointed local representatives, the PDPL would apply.

REGULATION

Personal data is defined as any information of any form related to an identifiable individual, or an individual who can be identified, directly or indirectly, particularly through their personal identification number, or one or more of their physical, physiological, intellectual, cultural or economic characteristics or social identity.

Sensitive personal data is a subset of personal data. It is personal data which reveals, directly or indirectly, the individual’s race, ethnicity, political or philosophical views, religious beliefs, union affiliation, criminal record or any data related to their health or sexual life. Sensitive personal data requires more rigorous treatment by data managers.

Processing is defined as any operation or set of operations carried out on personal data by automated or non-automated means, such as collecting, recording, organising, classifying in groups, storing, modifying, amending, retrieving, using or revealing such data by broadcasting, publishing, transmitting, making them available to others, integrating, blocking, deleting or destroying them.

Like the GDPR, the PDPL requires that personal data:

  • Is processed fairly and legitimately
  • Is collected for a legitimate, specific and clear purpose
  • Is sufficient, relevant and not excessive for the purpose of the data’s collection or for the purpose for which subsequent processing is carried out
  • Is correct and accurate, and subject to updates whenever necessary; and
  • Shall not remain in a form allowing identification of the data owner after meeting the purpose of its collection or for the purpose for which subsequent processing is carried out. The PDPL does allow the storage of anonymised data for a longer time for historical, statistical or scientific research purposes

PROCESSING

Processing of personal data can only occur with the consent of the data owner, unless the processing is necessary:

  • To implement a contract to which the data owner is a party
  • To take steps at the request of the data owner to conclude a contract
  • To implement an obligation required by law, contrary to a contractual obligation or an order from a competent court
  • To protect the vital interests of the data owner; or
  • To exercise the legitimate interests of the data manager or any third party to whom the data is disclosed, unless this conflicts with the fundamental rights and freedoms of the data owner

Processing of sensitive personal data is also prohibited without the consent of the data owner, unless one of the exceptions in Article 5 of the PDPL apply.

However, it is prohibited for data managers to process the following personal data types without the prior written authorisation of the Authority:

  • Automatic processing of sensitive personal data of persons who cannot provide consent
  • Automatic processing of biometric data
  • Automatic processing of genetic data (except for treatment provided by physicians and specialists at a licensed medical establishment, where the treatment is necessary for purposes of preventative medicine or diagnostic medicine, or for the provision of treatment or healthcare)
  • Automatic processing that entails the connection of personal data files that are in the possession of two or more data managers that are processing personal data for different purposes; and
  • Processing that consists of visual recording to be used for monitoring purposes

CONSENT

Like the GDPR, the PDPL has specific requirements about how consent must be given. For consent to be valid it must be:

  • Issued by an individual of full eligibility
  • Written, explicit and clear; and
  • Issued based upon the data owner’s free will and consent, after being fully informed about the purposes of the processing of their personal data

The data owner has a right to withdraw consent at any time. The Authority’s Board of Directors must issue a resolution outlining these procedures for withdrawing consent and the data manager’s decision on requests for withdrawal of consent.

RIGHTS OF DATA OWNER

The PDPL introduces several concepts that data managers will need to become very familiar with. Again, those familiar with the GDPR will see similarities here with the GDPR’s data subject rights.

Where the data is collected, directly or indirectly, from the data owner, the data manager at the time of registering such data, must notify the data owner of the following information:

  • The full name of the data manager, their field of activity or profession and address
  • The purpose for which the data is to be processed
  • Names or categories of the recipients of the data
  • Details about the data owner’s rights in respect of the data; and
  • Whether the data will be used for direct marketing

This notification is important, because it alerts data owners of their rights regarding their personal data. These rights include:

  • To be notified of when their data is being processed
  • To object to direct marketing
  • To object to processing that causes harm or distress to data owner or others
  • To object to decisions made based upon automated processing; and
  • To rectify, block or erase personal data in certain circumstances

SECURITY

The PDPL requires that data managers apply technical and organizational measures capable of protecting the data against unintentional or unauthorized destruction, accidental loss, unauthorized alteration, disclosure or access, or any other form of processing.

The PDPL requires that the Authority’s Board of Directors issues a decision specifying the terms and conditions that the technical and organizational measures must satisfy. The decision may require specific activities by applying special security requirements when processing personal data.

Data managers must also use data processors who will provide sufficient guarantees about applying the technical and organizational measures that must be adhered to when processing the data. Data managers must also take reasonable steps to verify that data processors comply with these measures.

Interestingly, there is no mandatory data breach notification provision in the PDPL requiring the data managers to notify the Authority or data owner in the event that there is a breach of personal data held by the data manager.

TRANSFERS OF PERSONAL DATA OUTSIDE OF BAHRAIN

Transfers of personal data out of Bahrain is prohibited unless the transfer is made to a country or region that provides sufficient protection to personal data. Those countries need to be listed by the Authority and published in the Official Gazette.

Data managers can also transfer personal data to countries that are not determined to have sufficient protection of personal data where:

  • The data owner has consented to the transfer
  • The data is from a public register
  • The transfer is necessary for:
    • Executing a contract between the data owner and data manager, or taking preceding steps at the data owner’s request for the purpose of concluding the contract
    • Executing or concluding a contract between the data manager and a third party for the benefit of the data owner
    • Protecting the data owner’s vital interests
    • Fulfilling a non-contractual obligation imposed by law, or an order of the court, public prosecution, an investigating judge or military prosecution; or
    • Preparing, executing or defending a legal claim

Transfers can also be made with the permission of the Authority, issued on a case-by-case basis, if it deems that the data will be sufficiently protected.

APPOINTMENT OF A DATA PROTECTION SUPERVISOR

Data managers may voluntarily appoint a data protection supervisor. The Authority’s Board of Directors may also issue a decision requiring specific categories of data managers to appoint data protection supervisors. However, in all instances, the data manager must notify the Authority of such an appointment within three (3) days of its occurrence.

A data protection supervisor must help the data manager in exercising its rights and fulfilling its obligations prescribed under the PDPL. The data protection supervisor also has a number of other roles, including liaising with the Authority, verifying that personal data is processed in accordance with the PDPL, notifying the Authority of any violations of the PDPL that the supervisor becomes aware of and maintaining a register of processing operations that the data manager must notify the Authority about.

The Authority must create a register of data protection supervisors. To be accredited as a data protection supervisor, an individual must be registered in that register.

ORDERS, CIVIL, COMPENSATION AND CRIMINAL PENALTIES

The Authority can issue orders to stop violations, including emergency orders and fines. Civil compensation is also allowed for any individual who has incurred damage arising from the processing of their personal data by the data manager, or arising from the data protection supervisor’s violation of the PDPL. Appeals can be made against decisions of the Authority.

Finally, the PDPL also carries a range of criminal penalties and administrative fines for violating certain provisions.

Criminal penalties of imprisonment of not more than one (1) year and/or a fine between BHD 1,000 (circa US$ 2,645) to BHD 20,000 (circa US$ 52,910), can be issued against any individual who:

  • Processes sensitive personal data in violation of the PDPL
  • Transfers personal data outside Bahrain to a country or region in violation of the PDPL
  • Processes personal data without notifying the Authority
  • Fails to notify the Authority of any change made to the data of which they have notified the Authority
  • Processes certain personal data without prior authorization from the Authority
  • Submits to the Authority or the data owner false or misleading data to the contrary of what is established in the records, data or documents available at their disposal
  • Withholds from the Authority any data, information, records or documents which they should provide to the Authority or enable it to review them in order to perform its missions specified under the PDPL
  • Causes to hinder or suspend the work of the Authority’s inspectors or any investigation which the Authority is going to make; and/or
  • Discloses any data or information which he is allowed to have access to due to his job or which he used for his own benefit or for the benefit of others unreasonably and in violation of the provisions of the PDPL

NEXT STEPS

Businesses that have already implemented a data protection compliance program under the GDPR may have developed some of the infrastructure that will apply under the PDPL; however compliance with the GDPR will not guarantee compliance with the PDPL. For example, businesses that are data managers will need to:

  • Recognise the right of Bahraini data owners to object to processing of personal data that causes harm or distress to the data owner or another person (this is not a data subject right found in the GPDR)
  • Notify the Authority of their processing; and
  • Obtain prior written approval of the Authority to process certain types of personal data (this is not found in the GDPR)

Finally, the risk of criminal penalties is a risk that is not found in the GDPR (although it is possible that Member States of the European Union may have specific laws that may be similar).

As a first step, a business will need to determine if its activities mean that it falls within the definitions of data manager. If it does, then it will need to determine what sort of personal data it is collecting, from who, and for what purposes. Data managers need to ensure that they are collecting and processing personal data and, in particular, sensitive personal data, in accordance with the PDPL, including notifying the Authority of their processing activities, or preparing submissions for permission to process certain types of personal data.

DLA Piper’s Middle East data protection team has deep experience in assisting clients in assessing their data protection compliance risks, and developing remediation and compliance programs.

Although the PDPL will become effective on 1 August 2019, our experience with the GDPR has shown us that data mapping exercises are often complex and resource intensive exercises. Early preparation for commencement of the PDPL will pay off in the longer term.

Posted in Cybersecurity EU Data Protection Privacy and Data Security Strategic Sourcing

Where Next for Outsourcing?

By Kit Burden on

As we look around in the mid part of 2018, the outsourcing industry is in something of a state of flux. There are certainly plenty of challenges. In the UK at least (and particularly vis-à-vis the public sector), a harsh spotlight is being shone on outsourcing. Similarly, the wider global movement towards protectionism and national insularity is also affecting outsourcing (with visas for workers becoming ever more difficult to come by). The technical foundations for many outsourced services have also shifted, with automation and AI making far-reaching changes to the mode of service delivery, and cloud-based offerings increasingly competing with more traditional managed service models.

On a more positive note (and it is good to keep a sense of balance!), the capabilities of these new technologies are also opening new doors and making outsourcing viable in relation to organizations and types of services which previously might not have been considered as potential outsourcing candidates. At the same time, the potential returns are increasing for providers and customers alike; the scope of BPO offerings continues to expand, and there are more geographic options available than ever before (not just because of the growth of service capabilities in places like South Africa, but also because the move towards digital rather than carbon labor means that labor arbitrage – and the bias toward such locations as the Philippines or India – is less of a factor than it used to be.

At the same time, we are seeing some interesting challenges in the negotiation of contract terms for such deals.

Perhaps the most obvious candidate is the apportionment of responsibility and risk associated with data and data privacy. This is at its most acute in the EU owing to the arrival of the General Data Protection Regulation (GDPR) and its much publicized 4 percent/2 percent of global turnover fines. It would be a mistake to consider just the GDPR: laws and regulations around cybersecurity and protection of both personal and non-personal data are also high on the scale as board-level concerns. We are seeing far greater levels of attention being given to data breaches that attack prominent companies, and inevitably such breaches make people ask who has the means to help guard against such breaches, and who should bear responsibility if they arise.

This is a particularly difficult issue, because no system is ever 100 percent secure. Unfortunately, during such a stressful time, hindsight has its attractions; it is easy to look back and claim that if a breach of security occurred, then the steps taken to prevent it must have been defective or insufficient.

While customers are looking to raise their levels of protection in this regard (eg, arguing for unlimited liability, and potentially on an indemnity basis), the service provider community has understandably been moving in the opposite direction. Even though data protection losses might historically have featured in some of the lists of unlimited liabilities, they now tend to be either lumped with the more general limit of liability, or (more frequently) proposed to be subject to a separate data-specific cap.

There are a number of aspects of this separate cap which remain to be worked out in terms of what might ultimately become a market norm, including:

  • How does the cap deal with other interlinked liabilities (eg, does it cover just claims from data protection regulators, claims from data subjects, internal rectification and remediation costs? Does it cut across the confidentiality obligations? And does it cover solely personal data, or other data related liabilities as well?)|
  • What should the cap’s quantum be? Is it to be set as an absolute figure, or by reference to some multiple of the contract charges?
  • Would the cap then be separate and free standing, or operate as an uplift to the normal limit of liability, which would have to be exhausted first?

Another key challenge: the impact of the cloud, not so much in terms of cloud offerings taking the place of traditional outsourcing arrangements, but more in the context of the use of cloud-based services as part of the supply chain (such as where an outsourced service provider uses the services of a third party to provide IaaS or PaaS capacity and flexibility as part of the foundation for the end-to-end outsourced service).

The issue in this regard is that the providers of such services – and they are becoming ever more prominent and powerful – tend to be very restrictive in their contract terms, not just regarding liability-related provisions such as limits of liabilities, warranties and service levels (on which an outsource service provider could in any event take a view as to what degree of “prime contractor risk” it is willing to bear), but also regarding the kinds of provisions that the outsource service provider might actually need to flow down, if it is to be able to strictly comply with its own obligations to its end customer (with audit rights being a particular example).

We increasingly see outsource service providers trying to limit their liabilities and obligations in this regard to apply only to the extent that they have in fact been able to flow them down to the relevant cloud provider. This is clearly a somewhat unpalatable position for the customer. Resolving the related negotiations will be a matter of bargaining leverage as opposed to whether one party is “right” or “wrong” regarding the way the issue should be addressed. This trend, however, also is giving rise to an increase in more multi-source style arrangements, whereby the customer itself may enter into the contract with the cloud service provider rather than having the main outsource service provider acting as prime contractor in relation to those services (ie, on the principle that if the customer gets no additional contractual benefit from having the outsource service provider in the contract chain, it might as well retain the flexibility of having a direct link to the cloud provider and also avoid any potential margin on costs that the outsource service provider might otherwise have levied).

And so we come to liability provisions. From one point of view, and with the possible exception of data-related liabilities as referred to earlier, one could argue that there is no particular reason why the contractual approach to liability provisions in outsourcing agreements should be subject to any substantial revisionist thinking. However, there are solid reasons why one should keep an open mind in this regard. After all, the setting of liability limits has historically always been (at heart) about balancing risk and reward, and that balance is certainly shifting, not least in the light of some of the factors mentioned in this post. Just as outsource service providers might be looking to reduce or limit more of their potential liabilities, sophisticated customers are also reviewing their approaches. Blanket exclusions of loss of profit, for example, while still very common, are more often challenged. Customers with operations in both civil and common law jurisdictions are also inclined to ask why they can potentially recover uncapped liabilities when due to “gross negligence” in one country, but not another, even though the services are the same and are even potentially provided by the same supplier. As a further step, one might imagine that a similar challenge might be made in respect of absolute exclusions of indirect loss (a common law concept which is not similarly viewed in civil law jurisdictions).

So, this is all good news for those of us engaged in the negotiation of outsourcing contracts (for both supply and buy sides) – after all, coming up with solutions for new problems and challenges is how we keep our minds young!

 

Posted in Asia Privacy EU Data Protection International Privacy Privacy and Data Security

EU & JAPAN: Free flow of personal data from EU to Japan soon possible

Anne FriedmanBy Anne Friedman on

On 17 July 2018 the European Union and Japan agreed to recognize each other’s data protection systems as ‘equivalent’ and to adopt reciprocal adequacy decisions.

What is an adequacy decision?

An adequacy decision is a decision establishing that a third country provides a comparable level of protection of personal data to that in the European Union. As a result, personal data can flow from the European Economic Area (EEA) (the 28 EU Member States as well Norway, Liechtenstein and Iceland) to that third country without being subject to any further safeguards or authorizations.

Adequacy decision is one of the tools provided for under the General Data Protection Regulation to transfer personal data from the EU to third countries.

What does it mean for business?

Continue Reading

Posted in Telecoms

Co-Investment Models for Broadband Infrastructure – an explanation and short critique

By Mike Conradi on

The new European Communications Code (the “Code” – which we have blogged about here) will introduce a mechanism allowing investments in fibre networks made by operators with significant market power (SMP), in some circumstances, to be excluded from the normal access rules that are usually imposed by national regulatory authorities (NRAs). This blog piece will discuss this further and look at some possible models that could qualify for the exemption before concluding with some comments critiquing this new approach on the basis of its deviation from the well-respected (and broadly successful) approach that would otherwise have applied. For the reasons explained below the new rules could even act as a disincentive to new investment over the next two (plus) years.

The Exemption – Commitments and the “cumulative conditions”.

The rules on co-investment are contained at Article 74 of the Code. The latest (through not-necessarily final) draft says that:

Undertakings that have been designated as having SMP may offer “commitments” to open the deployment of a new very high capacity network (that consists of optical fibre elements up to the end-user premises or base station) to co-investment.

The first point to note, then, is that this applies only to optical fibre and would not apply to other technologies (such as satellite) irrespective of their merits. This is of course a deviation from the normal principles of technology-neutrality that usually govern EU telecoms regulation.

Continue Reading

Posted in Telecoms

The new European Electronic Communications Code

By Mike Conradi on

It is now almost two years since the European Commission proposed a new “European Electronic Communications Code” (the “Code”) which would amend and consolidate the current regime (dating from 2002). [i]

On 29 June 2018 a new, amended, draft was published. This is expected to go to a final vote in the Autumn of this year.

The Code will, when finalised, repeal the existing 2002 Directives and replace them with a single, consolidated text, for implementation in Member States within two years. Having spent some time reading through the (c.450) pages the main changes or issues appear to be as follows:

Continue Reading

Posted in Internet of Things Technology and Commercial Telecoms

Germany: Roaming Regulation and IoT services

By Mike Conradi and Christoph Engelmann on

By Christoph Engelmann, Senior Associate, Hamburg

DLA Piper recently advised a client (Transatel) on a very interesting matter leading to the German telecommunications regulator Bundesnetzagentur (BNetzA) issuing a landmark decision on the applicability of the Roaming Regulation on so-called 901 International Mobile Subscription Identities (IMSI). In this decision BNetzA ruled that the defendant in that case, a German Mobile Network Operator (MNO), has to provide the applicant, Transatel, a French Mobile Virtual Network Enabler/Aggregator (MVNE/A), with a draft contract for wholesale roaming access pursuant to Art. 3 par. 5 sentence 2 of the Roaming Regulation even if the applicant uses non-geographic numbering on its SIM cards (so-called 901 IMSI).

The decision is based on a dispute resolution procedure started by the applicant after the defendant refused to grant wholesale roaming access with regulated charges as set out in the Roaming Regulation. The defendant is of the opinion that the Roaming Regulation does not apply to the applicant’s business model because the applicant uses the shared or non-geographic Mobile Country Code (MCC) 901 awarded by the International Telecommunication Union (ITU) for numbering its SIM cards instead of using geographic MCCs awarded by the regulatory authorities of the individual countries (e.g. MCC 208 for France).

Before making its decision BNetzA requested the Body of European Regulators for Electronic Communications (BEREC) to adopt an opinion with regard to the action to be taken in accordance with the Roaming Regulation. In its opinion BEREC considers that the Roaming Regulation covers roaming services provided by the applicant via 901 IMSI for customers with a home network that is located in an EU Member State. BEREC also refers to its report “Enabling the Internet of Things” BoR (16) 39 where it pointed out that the MCC 901 could be used for the addressing in Internet of Things (IoT) services.

With its decision BNetzA follows up on BEREC’s opinion ordering the defendant to provide the applicant with a draft contract for wholesale roaming access. The draft contract has to enable the applicant to use IMSI with the MCC 901. BNetzA based its decision on the fact that the Roaming Regulation does not contain any provision concerning numbering with regard to SIM cards or end users. Instead it focuses on the Roaming Regulation’s definitions of “roaming customer” and “home network” that do not exclude the MCC 901. In addition, BNetzA points out that the BEREC’s Wholesale Roaming Guidelines BoR (17) 114 mention that a roaming customer could for example be identified by numbering resources from European Economic Area (EEA) Member States which are in accordance with the E.212 ITU Recommendation and BNetzA notes that the MCC 901 is part of that recommendation.

In order to make sure that the roaming services are provided in accordance with the Roaming Regulation, BNetzA notes that the defendant may include specific measures that the visited network operator may take to prevent permanent roaming or anomalous or abusive use of wholesale roaming access as well as the objective criteria on the basis of which such measures may be taken in its reference offer that is used as the basis for the requested draft contract. However, according to BNetzA this may only be based on information on roaming traffic in an aggregated form but not on specific information relating to individual roaming traffic.

In BNetzA’s official press release Jochen Homann, President of BNetzA, explains that the decision “provides an important boost to competition and innovation on the wholesale markets, particularly in respect of the Internet of Things or communication between machines”. The decision is the first of its kind in Germany and BNetzA invited the three MNOs in Germany to participate in the procedure. The decision enables Mobile Virtual Network Operators (MVNOs) that are operating globally to use the international numbering with MCC 901 for all of their SIM cards instead of applying for a local number in each country while still benefiting from the regulated charges in the Roaming Regulation for the parts of their business that covers roaming customers with a home network in the EEA.

Following this decision, the defendant is obliged to provide a draft contract to the applicant within one month. If the parties are not able to agree on the contract terms, BNetzA may rule on the terms in a separate dispute settlement proceeding. In addition, it is up to the parties to file an action against BNetzA’s decision with the competent administrative court.

Posted in EU Data Protection Privacy and Data Security

Germany: first court decision on GDPR

By DLA Piper on

By Jan Spittka and Kiana Mirzaei

Only five days after the GDPR became applicable, the first German court, the Regional Court (Landgericht) Bonn (in a decision dated 29 May 2018, case number 10 O 171/18 – in German only), issued a ruling on the practical application of the GDPR. This probably makes the court’s ruling the first GDPR court decision worldwide, and the decision addressed the hot-button issue of public availability of ICANN “WHOIS data”.

The court was called upon to rule in an interim injunction proceeding about the data minimization principle set forth in Art. 5 (1) lit. c) GDPR.  The Parties to the proceeding were the Internet Corporation for Assigned Names and Numbers (ICANN) against the German-based, ICANN-accredited Registrar EPAG Domainservices GmbH. ICANN sought to obligate EPAG to comply with the ICANN “Registrar Accreditation Agreement”, which requires registrars to collect administrative (Admin-C) and technical (Technical-C) contact information for a new domain name registration (“WHOIS data”). The court ruled that ICANN could not show credibly that the collection of Admin-C and Technical-C is necessary pursuant to Art. 5 (1) lit c) GDPR and therefore that EPAG is not obligated to collect such data.

In detail: The court stated, that an obligation to comply with the requirements of the Registrar Accreditation Agreement exists only in so far as the Agreement is in accordance with applicable law. Article 5 (1) lit b) and c) GDPR dictate that personal data may only be collected for specified, explicit and legitimate purposes and shall be adequate, relevant and limited to what is necessary in relation to the purpose. Per the court, ICANN could not show credibly  the necessity to collect the Admin-C and Technical-C. Instead, the collection of the domain name registrant data should suffice to fulfill ICANN’s purposes, especially with regard to criminal activity, infringement or security problems, as the domain name registrant is the main person responsible. According to the court, the fact that a registration is also possible by naming the registrant (and not a third party) as Admin-C and Technical-C underlines this argumentation.

WHOIS directories are valued by rights owners and law enforcement authorities for providing transparency as to who registered a domain and ICANN has been struggling with GDPR compliance regarding WHOIS directories and services.  They therefore entered into a dialogue with the Article 29 Data Protection Working Party (WP29, since 25 May 2018: the European Data Protection Board).  The WP29 stated concerns regarding ICANN’s GDPR compliance, outlined recommendations and announced to monitor ICANN closely (see WP20 letter from 11 December 2017 and  WP29 Letter from 11 April 2018 ). ICANN requested a moratorium on enforcement action by DPAs until a revised WHOIS policy is developed and implemented. This request was denied several days after the GDPR effective date by the European Data Protection Board on the ground that the GDPR does not allow national supervisory authorities nor the European Data Protection Board to create an “enforcement moratorium” for individual data controllers. However, the Board noted that this does not preclude data protection authorities to take into consideration the measures which have already been taken or which are underway when determining the appropriate regulatory response upon receiving complaints (see Statement from 27 May 2018). Click here for more details on processing of WHOIS information.

This article first appeared on DLA Piper’s Privacy Matters blog.

Posted in Health Privacy

Guide for Accessing and Using Medical Records Breaks No New Ground and Instead Doubles Down on Old Processes

By Jim Halpert on

Written by Anna Spencer and Milton Gregory

On April 4, 2018, the US Department of Health and Human Services’ (“HHS”) Office of the National Coordinator for Health Information Technology (“ONC”) released a new web-based resource – the ONC Guide to Getting and Using your Health Records – that promotes individual access to medical records by educating patients on their rights of access and amendment under HIPAA and provides detailed instructions on how patients should request their records. As ONC acknowledges, access to health information can empower patients and enable them to take control of their own health, well-being, and safety.  Although the guidance does not have the force of law, it offers valuable insight into how the Trump administration seeks to further patient rights under HIPAA.

The web-based guide is meant to help individuals, patients, and caregivers better understand how to access, review, and use their electronic (and paper) health information by providing instructions as well as tips, links and quizzes to test the individual user’s knowledge. Among other steps, individuals are told to collect the full names, physical addresses, phone numbers, and fax number or secure email (through any patient portal) for all of the doctors whom an individual wants to send and receive his or her medical record. The resource goes on to state that individuals may be required to complete forms when they request their records. The resource describes a potential form that contains at least twenty three data points.  Clearly, collecting this much information and completing a form for every health care provider will prove too burdensome to many patients.

The resource also suggests that individuals that follow through with accessing their health information utilize mobile apps to manage the data. It encourages individuals to select secure apps and provides a link to an FTC webpage with instructions on how to protect personal information, but it does not explain the privacy and security issues inherent in mobile health apps.  Individuals should understand that mobile health apps typically are not afforded the protections provided by HIPAA, unless the app is offered by a HIPAA covered entity or business associate.

The 21st Century Cures Act (“Cures Act”) amended federal law to permit business associates, (i.e., vendors of covered health care providers that process Protected Health Information (“PHI”) on behalf of health care providers) to provide access to PHI that they maintain in certain records.  However, ONC’s new resource does not include any guidance on what a business associate’s role is in the expansion of patients’ rights under the Cures Act.  Some business associates, such as health care clearinghouses, have PHI from multiple health care providers and health plans.  As such, they could serve as convenient supplemental sources of health records for individuals in addition to health care providers.

Covered entities and business associates should monitor the implementation of these provisions by the Office for Civil Rights. Covered entities will potentially need to revise their Business Associate Agreements to avoid interfering with business associate obligations and business associates will want to ensure that they comply with regulatory requirements.

 

LexBlog