China Released Core National Standards, Updating Mandatory Cybersecurity Requirements under the Cybersecurity Multi-level Protection Scheme

On May 13, 2019, China’s State Administration for Market Regulation (“SAMR”) released three core national standards related to the country’s Cybersecurity Multi-level Protection Scheme (“MLPS”), describing technical and organizational controls that companies must follow when complying with MLPS-related obligations under the Cybersecurity Law (“CSL”). These standards, which are commonly referred to as the “MLPS 2.0 standards,” include: GB/T 22239 – 2019 Information Security Technology – Baseline for Multi-level Protection Scheme, GB/T 25070 – 2019 Information Security Technology – Technical Requirements of Security Design for Multi-level Protection Scheme and GB/T 28448 – 2019 Information Security Technology – Evaluation Requirements for Multi-level Protection Scheme. The MLPS 2.0 standards are set to take effect on December 1, 2019.

Background of MLPS

China’s CSL, which took effect on June 1, 2017, requires the government to implement the MLPS for cybersecurity (Article 21). This framework is designated as a fundamental scheme to protect cybersecurity in China and requires all network operators, a term broadly defined to include all entities using a network (including the Internet) to operate or provide services, to meet certain cybersecurity requirements.

To implement provisions related to MLPS in the CSL, the government, in particular the Ministry of Public Security (“MPS”), has been working since 2017 on rules and national standards that specify the networks that must to be classified under the MLPS; the classification, certification and filing process for such networks; the technical controls that must be implemented by network operators; and the compliance obligations that network operators at different levels must follow. Collectively these rules and national standards form a layered framework for cybersecurity requirements under CSL, commonly referred to as the “MLPS 2.0” framework.

The first layer of the MLPS 2.0 framework is the draft Regulations on Cybersecurity Multi-level Protection Scheme, issued by MPS on June 27, 2018 (the “Draft Regulation”, see our previous post here) for public consultation. The Draft Regulation updated the existing MLPS regulation (commonly referred to as “MLPS 1.0”), a framework dating back to 2007 that classified information systems physically located in China according to their relative impact on national security, social order, and economic interests if the system is damaged or attacked. Under both the MLPS 1.0 and the Draft Regulation, the classification levels range from one to five, one being the least critical and five being the most critical. Further, under the Draft Regulation, information systems that are classified—initially self-assessed and proposed by network operators and then confirmed by the MPS—at level 3 or above are subject to enhanced security requirements. MPS publically announced that it plans to finalize the Draft Regulation by the end of 2019.

The second layer of the MLPS 2.0 framework is the MLPS 2.0 standards, which establish the technical foundation of the framework by clarifying varying technical and organizational controls that network operators at each level should establish. The release of this core set of MLPS 2.0 standards marks an important step for MPS, which plans to roll out the MLPS 2.0 framework at a full scale nation-wide in the coming months. As the next step, MPS indicated that two more MLPS 2.0 standards, which set out the implementation process and the certification process, will be released together with the final version of the Draft Regulation. At that point, the full MLPS 2.0 framework will be completed and impose mandatory requirements on all network operators in China.

At this moment, certain aspects of the MLPS 2.0 framework, especially those are to be covered by the Draft Regulation and the two forthcoming MLPS 2.0 standards remains unclear – for example, it is still not clear what systems need to be certified or the specific legal obligations companies operating networks classified at different levels, especially at Level 3 or above, will be subject to.

What are the Key Updates of MLPS 2.0 Standards?

As explained in more detail below, the MLPS 2.0 standards (1) significantly expand the applicability of the MPLS 1.0 by broadening the definition of “information systems”; (2) establishes common controls for all types of systems; and (3) establishes extended controls for certain types of systems.

Expanded Applicability: As compared to MLPS 1.0, the MLPS 2.0 standards expand their coverage from “information systems” to a wider range of “systems,” which may include network infrastructure, cloud computing platform/system, mobile application platforms, connected devices (Internet of Things, “IoT”), and industrial control systems.
Common Controls for all Systems: MLPS 2.0 standards establish a core set of technical and organizational controls for all systems, referred to as “common controls,” regardless of the classification level of the system. Specifically, network operators are required to establish controls in the following areas: security governance, including organization, management, and personnel; physical environment security; communication network security; network boundary protection; business continuity and disaster recovery; identity management; intrusion detection; third party risk management; and security operations.
Extended Controls for Specific Types of Systems: The MLPS 2.0 standards also require network operators to implement additional extended controls at each classification level for the following specific types of systems: (i) cloud computing, (ii) industrial control systems, (iii) connected devices, and (iv) mobile network systems.

For example, network operators are required to implement a series of extended controls for cloud computing systems, regardless of the classification level of a particular cloud computing system, in the following areas: physical environment security (e.g. localized infrastructure in China, possibly referring to the use of local data centers); communication network security (e.g. localized storage of customer data and personal information in China; if cross-border data transfers are needed, such transfers must be in compliance with unspecified Chinese laws and regulations); network boundary protection (e.g. access control, non-invasive security and security audit); computing environment security (e.g. identity authentication, data recovery, data backup, etc.); and maintenance (e.g. localized maintenance in China, unless oversea maintenance can follow unspecified Chinese rules and regulations).

In addition, if a network operator will use a vendor to run a cloud computing system, the network operator is required to include a number of additional controls in its vendor management program, such as: requiring the vendor to comply with applicable Chinese laws and regulations; confirming that the MLPS classification level of the vendor is not lower than the classification level of the network operator’s system that will be run on the cloud; and ensuring the service level agreement specifies the service scope, technical details, rights and obligations, access control, privacy protection and other key terms.

Further, network operators classified Level 2 or above are also required to request their cloud service providers return the complete set of customer data and delete such data after the termination of the cloud service agreement. Network operators of systems classified Level 3 or above, are required to enter into a confidentiality agreement with the cloud service provider to prohibit unauthorized disclosure of customer data.

* * *

In sum, the MLPS 2.0 standards introduce different technical and organizational controls for companies at different classification levels and provide important technical guidance for companies that are making efforts to comply with the MLPS requirements. Some of the extended controls, such as localized infrastructure, storage, and maintenance for cloud computing systems, could raise compliance issues for both global cloud service providers and their customers, if they become mandatory requirements. Additional guidance is expected to be provided by MPS in the coming months, and companies who are or may be subject to the MLPS requirements should closely monitor the developments.

Washington State Lawmakers Reach Deadline Without Passing Privacy Act, But Reach Agreement on Amendments to Breach Notification Law

By Inside Privacy on May 8, 2019 Posted in Data Privacy

The Washington Privacy Act stalled this April in the state’s House of Representatives, and will likely not reappear again for discussion until the 2020 legislative session.

The bill overwhelmingly passed the Senate, but failed to come to a floor vote in the House of Representatives before the April 17th deadline for state lawmakers to consider non-budget related matters. This delay appears to stem from a lack of consensus on key issues, such as the regulation of facial recognition technologies and potential enforcement mechanisms.

If the House had passed the bill, Washington would have become the second state in the United States to enact significant privacy legislation. Mirroring the GDPR in several respects, the bill provided access, correction, and deletion rights to consumers, and imposed disclosure and risk assessment obligations on covered businesses.

Although state lawmakers failed to pass the Washington Privacy Act, they reached a consensus on a separate bill that expands Washington’s breach notification law. The Senate and the House of Representatives passed the bill in their respective chambers in the latter half of April. The bill amends the state’s data breach notification requirements in three ways:

Definition of Personal Information: The law expands the definition of “personal information” that triggers notification to include: full date of birth; private key to authenticate or sign an electronic record; biometric data; student, military, or passport ID numbers; certain health insurance information; medical histories; and online account credentials.
Timeline for Notification: The law reduces the timeline for issuing notifications from 45 days to 30 days after discovery of a breach.
Content Required for Notification: The law requires additional information to be included in breach notification letters, such as the date of the breach and the discovery date. In addition, for breaches of usernames and passwords, the notice must inform consumers to change their passwords and security questions and answers, and to take appropriate steps to secure their account. Notifications to the Attorney General also must include the types of personal information subject to the breach, the timeframe of exposure, and steps taken to contain the breach.

The new requirements are scheduled to take effect on March 1, 2020.

HHS Updates Maximum Annual Penalty Limits for Some HIPAA Violations

By Lindsay Brewer on May 6, 2019 Posted in Health Privacy

On April 30, 2019, the Department of Health and Human Services (HHS) published in the Federal Register a notification of enforcement discretion indicating that it will lower the annual Civil Money Penalty (CMP) limits for three of the four penalty tiers in the Health Information Technology for Economic and Clinical Health Act (HITECH Act). The HITECH Act categorizes violations of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) in four tiers based on the violators’ level of culpability for the violation: the person did not know (and, by exercising reasonable diligence, would not have known) that the person violated the provision (Tier 1); the violation was due to reasonable cause, and not willful neglect (Tier 2); the violation was due to willful neglect that is timely corrected (Tier 3); and the violation was due to willful neglect that is not timely corrected (Tier 4).

The maximum penalty per violation for all four tiers was previously $1.5 million. HHS’s new policy states that the annual penalty limit for Tier 1 violations has now been decreased from $1.5 million to $25,000. The new annual penalty limits for Tier 2 and 3 violations are now $100,000 and $250,000, respectively. The penalty limit for Tier 4 violations will remain at $1.5 million. Continue Reading

German DSK publishes guidance on the applicability of the German Telemedia Act to telemedia services

By Liza Herberger and Lars Lensdorf on May 6, 2019 Posted in Advertising & Marketing, EU Data Protection, European Union, Privacy Policies

On April 5, 2019, the association of German Supervisory Authorities for data protection (‘Datenschutzkonferenz’ or ‘DSK’) published a guideline regarding the applicability of the German Telemedia Act (‘TMG’) to telemedia services – including, for example, the use of website cookies for targeted advertising post-GDPR. The guideline aims to “clarify and concretize” a previous statement on the topic released by the DSK in April 2018 and to serve as guidance for the implementation of data protection requirements when processing users’ data through telemedia services. This guideline is the result of a stakeholder consultation carried out by the different German Supervisory Authorities last year.

In line with its previous paper, the DSK confirmed in its opinion that Sections 12, 15(1) and 15(3) TMG ceased to be applicable when the GDPR came into effect. Hence, in the absence of a lex specialis, the provisions of the GDPR apply by default. The main difference between the two laws is that the TMG provides for a specific legal basis under which online tracking may be lawfully carried out by a website operator. According to Section 15(3) TMG, so long as the website operator uses pseudonyms, it may create user profiles for purposes of advertising, market research or for the demand-oriented design of telemedia services, provided that the user does not object to this (typically through an opt-out solution like unticking a pre-selected checkbox on a cookie banner).

The DSK argues that Sections 12, 15(1) and 15(3) of the TMG do not implement the ePrivacy-Directive’s[1] ‘cookie requirements’ and therefore are not covered by Art. 95 GDPR, which leaves (national) laws like the TMG unaffected if they constitute an implementation of the ePrivacy Directive. With regard to Section 15(3) the DSK also rejects an interpretation in line of the GDPR. Finally, the DSK points out that the ePrivacy-Directive is not directly applicable. Hence, according to the DSK, online tracking must be based on one of the legal bases listed in Article 6 GDPR (or Article 9 for sensitive data) and if consent is sought, this it must comply with the requirements for consent under Article 4(11) GDPR.

The DSK then sets out the various legal bases in Art. 6(1) GDPR that a website operator may rely on for processing personal data collected via website cookies. According to the DSK, in most use cases online tracking requires the user’s prior consent in the form of an opt-in solution whereby the user must actively demonstrate consent (typically by ticking a checkbox on a cookie banner). When the collection of sensitive data is involved, consent shall always be required.

With regards to consent, the DSK clarified that if personal data collected from the user is combined and evaluated by the website operator across websites, the user must be informed in advance of all processing activities and of all recipients of the data. Furthermore, the user must be given the opportunity to give his/her specific consent to the various forms of data processing. In cases where multiple data controllers wish to rely on the same consent (either as joint controllers or because of a transfer between co-controllers), all controllers must be named and their different processing activities must be sufficiently described. In these cases, all data controllers must check whether there is effective consent for their processing activities and whether this can be proven by them. With reference to Recital 32 GDPR the DSK points out that an opt-out procedure does not comply with the consent requirements of the GDPR.

Notably, the DSK also said that it must be possible to view a website without consenting to non-essential cookies – this appears to be a prohibition on the use of cookie walls. Obtaining consent through an “OK” button is also not GDPR compliant in the eyes of the DSK if users are not given an opportunity to refuse the cookies.

The guidance sets out a three-step balancing process that website operators should carry out if they intend to rely on legitimate interest as their legal basis for using cookies. Here, the DSK describes what it considers to be acceptable and unacceptable examples of (overriding) legitimate interests. For the DSK, it would be acceptable for a website operator to collect information about (i) the number of website visitors over a specific period of time, (ii) the devices they used to access the website, and (iii) their language preferences, in furtherance of the website operator’s legitimate interest to maximize the website’s reach. However, it would not be acceptable for the website operator to use an analysis tool for this purpose that passes on the browsing behaviors of website visitors to third parties (e.g., social networks or other services which merge usage data with data from other sources). According to the DSK, a user does not reasonably expect that user history is shared with third parties or that web browsing behavior (e.g., the manner in which one touches a screen or types on the keyboard) is recorded. The DSK recommends alternatives such as collecting less data and/or utilizing an in-house software solution for certain website analytics purposes.

The DSK expressly highlights that this guidance is subject to the interpretation of the European Data Protection Board and any changes that may result from the finalization of the long-awaited ePrivacy Regulation.

[1] Directive 2002/58/EG as amended by the Directive 2009/136/EG.

HHS Extends Comment Period for Proposed Rules on Patient Access and Interoperability

By Sanchi Khare on April 30, 2019 Posted in Department of Health and Human Services, Health Privacy

On April 19, 2019, the Department of Health and Human Services (HHS) announced a 30-day extension, until June 3, 2019, to the comment period for two rules proposed by the Centers for Medicare & Medicaid Services (CMS) and the Office of the National Coordinator for Health Information Technology (ONC).

The CMS proposed rule aims to increase patient access to their personal electronic health information. The rule proposes new requirements for federal government payors, such as requiring the adoption of application programming interfaces (APIs) to better enable the transfer of electronic health information between health networks. The CMS rule also proposes requirements for providers, such as affirmative attestations that they are not engaging in information blocking activities and publicly disclosing those providers who fail to attest in the affirmative.

The ONC proposed rule focuses on technical changes to increase interoperability between disparate systems. Among the ONC rule’s proposals are standardized criteria for API development and seven exceptions to the prohibition against information blocking.

Additional information about these proposed rules can be found in Covington Digital Health’s March 7, 2019 blog post, as well as our April 25, 2019 blog post.

HHS Clarifies HIPAA Liability for EHR System Developers that Transfer Data to Health Apps

By Lindsay Brewer on April 26, 2019 Posted in Department of Health and Human Services, Health Privacy

On Friday, April 19, 2019, the Office for Civil Rights of the U.S. Department of Health and Human Services (HHS) explained in an FAQ the circumstances under which electronic health record (EHR) systems may be subject to the Health Insurance Portability and Accountability Act of 1996 (HIPAA) liability for an app’s impermissible use or disclosure of electronic protected health information (ePHI). As long as the app is independent of the covered entity and its EHR system and is instead controlled by the individual patient, the covered entity and its EHR system have no HIPAA liability once ePHI is delivered to the app at the patient’s request.

In its FAQ, HHS specified that if, at the request of a patient, a HIPAA covered entity’s EHR system transfers ePHI to an app that is not developed by or specifically provided to the covered entity by the EHR system, neither the covered entity nor the EHR system developer would face HIPAA liability for the app’s subsequent impermissible use or disclosure of the information. But if an EHR system transfers patient data from a covered entity to an app that the EHR system provides “through, or on behalf of, the covered entity (directly or through another business associate)” and either owns the app or has a business relationship with the app developer, the EHR system developer may be subject to HIPAA liability for subsequent impermissible use or disclosure of the ePHI.

This attempt to clarify the boundaries of HIPAA liability will likely be welcomed by a wide range of covered entities, EHR systems, and developers of apps that process ePHI, including apps that connect patients with doctors, pharmacy apps, and apps that focus on fertility, mental health, smoking cessation, and more. Patients, on the other hand, should be aware that the information being collected by an app (which can be substantial and sensitive, depending on the nature of the app) has no protection under HIPAA unless the app was offered to them by a covered entity as part of its overall EHR system.

U.S. Supreme Court Affirms the Necessity of Express Authorization for Class Arbitration

By Micha Nandaraj Gallo on April 25, 2019 Posted in Data Breaches

On April 24, 2019, the Supreme Court issued its opinion in Lamps Plus, Inc., et al. v. Varela, addressing the question of whether an ambiguous arbitration agreement can be read to compel class arbitration under the Federal Arbitration Act, 9 U.S.C. §§ 1-16 (2000). Underscoring the controversial nature of this decision, the case was decided by a 5-4 split that included dissenting opinions authored by Justices Ginsburg, Breyer, Sotomayor, and Kagan. The majority opinion, authored by Chief Justice Roberts, held that contract ambiguity did not suffice to compel class arbitration.

Coercive and Non-Coercive Surveillance Authorities

By Trisha Anderson and Alexander Berengaut on April 25, 2019 Posted in Surveillance

When the U.S. government conducts electronic surveillance, there are a variety of legal authorities on which it relies. The Wiretap Act, for example, authorizes the government to conduct live telephone wiretaps in certain criminal investigations; for electronic data, the Act also permits the government to acquire electronic communications in real time. The Stored Communications Act (“SCA”) authorizes the government to obtain stored electronic data, including the content of email messages hosted online for criminal investigations.