With the May 25, 2018 deadline quickly approaching, many businesses are scrambling to prepare for compliance with the EU’s General Data Protection Regulation (GDPR), and questions and conversations are heating up.  Still others are still trying to wrap their arms around what GDPR is and what it means for U.S. businesses.  For those of you still trying to wrap your heads around it, below are a few basics to help familiarize yourself with the regulation and its relevance to you.

  1. I’m a U.S. business. Why does GDPR matter to me?

The reach of the GDPR regulation extends not only to European-based businesses, but also to all companies that do business, have customers, or collect data from people in the EU.  If you even have a website that could collect data from someone visiting the site from the EU, your business could be affected. No matter where your business resides, if you intentionally offer goods or services to the European Union, or monitor the behavior of individuals within the EU, the GPDR could be applicable.

  1. What’s the risk?

In addition to the PR or brand risk of being associated with noncompliance, GDPR provides for some pretty significant monetary penalties .  Some violations are subject to fines up to 10 million EUR or up to 2% of global annual turnover, whichever is greater.  For other violations, it is double – up to 20 million euros or 4% of your global annual turnover, whichever is greater.  For large businesses, this could be a substantial amount.

  1. What should I be doing?

First, talk with your general counsel or outside law firm.  They can help you interpret the law, review contractual obligations and assess the company’s overall privacy policies to help guide your compliance strategy going forward.  They can also help create defensible interpretations within certain ambiguous language in the regulation (e.g., what is “personal data” for purposes of the GDPR?).  The Article 29 Working Party, made up of the data protection authorities (DPAs) from all EU member states, has published guidance to clarify certain provisions, which can be helpful during this process.

Second, create a cross-functional team including areas including (but not limited to): communications/PR, IT, customer experience, digital, legal and operations.  This may be fairly similar to any cross-functional teams you may have (and hopefully have) already established to prepare for data breaches.  This team can begin designing and implementing a compliance strategy.  Under certain conditions, your business may need to appoint a Data Protection Officer (DPO) (See Articles 29 and 30).

  1. What are some key points of the GDPR?

GDPR is a data privacy regulation in the EU that is aimed at protecting users’ rights and privacy online.  It requires business to assess what kinds of data they’re collecting and to make that data accessible to users.  The regulation is long and complex with several moving parts, but four key points may be worth noting.

Key Definitions:  You will see several references to controllers, data subjects, personal data, and processing.  This vocabulary may be unfamiliar in relation to U.S. law, but here is how these key terms are defined – as a business subject to GDPR, you may be a “controller” or you may be a “processor”.  The individual is the “data subject”:

  • “Controller” = “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law.”
  • “Processor” = “means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”
  • “Data subject”= “an identified or identifiable natural person (see definition of “personal data” above).”
  • “Personal data” = “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”
  • “Processing” = “any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction”
  1. Some Key Articles/Provisions:

Article 12Transparent information, communication and modalities for the exercise of the rights of the data subject.

This article creates rules around how users give consent to record their data.  The data subject must be provided with accurate information on all relevant issues, such as the kind of data to be collected or process, and for what purposes. For some particularly sensitive data, (e.g., political opinion, religion, biometric data (including photographs), health data, etc.), consent must be “explicit”.   Consent must be “freely given”, meaning that the user has a “genuine” choice and be able to withdraw consent “without detriment”.  The data subject cannot be obliged to consent to data processing that is not necessary to provide the service he or she has requested.

For these reasons, the traditional “notice and consent” may not be sufficient, and actionable forms or buttons may be necessary.  “Silence, pre-ticked boxes or inactivity,” however, is presumed inadequate to confer consent.  Recital 32 of the GDPR notes that an affirmative action signaling consent may include ticking a box on a website, “choosing technical settings for information society services”, or “another statement or conduct” that clearly indicates assent to the processing.  “Silence, pre-ticked boxes, or inactivity” however, is presumed inadequate.  For those reaching European citizens digitally, working with IT or UX experts may prove important to create a seamless, but compliant, experience.

Article 17Right to erasure

The “right to be forgotten” means that businesses must be able to remove data on a user at their “without undue delay”.  Further, the businesses have an obligation to erase personal data “without undue delay” under certain additional circumstances.

Article 20. Right to data portability.

Users have the right to receive any data that a business may have on them the firm must provide such data in a “structured, commonly used and machine-readable format”.  Further, the data subject has the right to transmit such data to another business without being hindered by the business that provide the data where the processing is either (a) based on certain consents or (b) carried out by automated means.  Where technically feasible, the data subject also has the right to have the personal data transmitted directly from one controller to another.

Article 8. Conditions applicable to child’s consent in relation to information society services.

Article 8 limits the ability of children to consent to data processing without parental authorization.  Previous drafts of the GDPR had set the age of consent at 13 years old, which would have been consistent with the age set by the United States’ Children’s Online Privacy and Protection Act (“COPPA”). A last-minute proposal aimed  to raise the age of consent to 16 years old.  In the final draft, the age of consent is set at 16 unless a member state sets a lower age no below 13 years.  Thus, unless otherwise provided by member state law, controllers must obtain parental consent when processing the personal data of a child under the age of 16. With the difference between the U.S. age of consent under COPPA set at 13 (COPPA) and the European age of consent under the GDPR set at 16 (unless otherwise lowered by a member state), this could present some challenges for U.S. businesses offering international services.

Article 32.  Security of Processing.

Firms must follow security best practices across the board when collecting and protecting data. This may include, but isn’t limited to, specific password policies, information security frameworks (e.g., NIST, ISO, COBIT/ISACA, SSAE, etc.), and data encryption.

  1. What Else Should I Know?

If you believe your business might be affected, you should already be familiarizing yourself with the GDPR regulations and be well into your compliance plan.  The above summary is a sampling of key points and not a comprehensive analysis,, which should be undertaken to better understand your compliance obligations.  You should also be aware of the ePrivacy Regulation which will be following on the heels of the GDPR.

Whereas the GDPR covers the right to protection of personal data, while the ePrivacy Regulation encompasses a person’s right to a private life, including confidentiality.  There is some obvious overlap here, but the ePrivacy Regulation is intended to particularize GDPR for electronic communications — devices, processing techniques, storage, browsers etc.  The laws are intended to be in sync, but the ePrivacy regulations are still up in the air — optimistically forecasted to be finally approved by the end of 2018, although the implementation date remains to be seen.  In sum, GDPR compliance is all you can focus on right now, and hopefully GDPR compliance should position your business well for any additional compliance obligations that could subsequently arise from the finalized ePrivacy Regulation.

On December 5, 2017, NIST published a revised version of the NIST Cybersecurity Framework (i.e., Draft 2 of Version 1.1) (“Framework”).  According to NIST, Version 1.1 of the Framework refines, clarifies, and enhances Version 1.0 of the Framework issued in February 2014, and the recently published Draft 2 of Version 1.1 is informed by over 120 comments on the first draft proposed in January 10, 2017, as well as comments and discussion by attendees at NIST’s workshop in May 2017.

Among the various revisions, they include revisions intended to: (1) clarify and revise cybersecurity measurement language; (2) clarify the use of the Framework to manage cybersecurity within supply chains; (3) better account for authorization, authentication, and identity proofing; (4) better consider coordinated vulnerability disclosure, including the addition of a subcategory related to the vulnerability disclosure lifecycle; and (5) remove statements related to federal applicability in light of various intervening policies and guidance (e.g., Executive Order 13800, OMG Memorandum M-17-25, and Draft NIST Interagency Report (NISTIR) 8170) on federal use of the Framework.

NIST seeks public comment on the following questions by January 19, 2018:

  • Do the revisions in Version 1.1 Draft 2 reflect the changes in the current cybersecurity ecosystem (threats, vulnerabilities, risks, practices, technological approaches), including those developments in the Roadmap items?
  • For those using Version 1.0, would the proposed changes affect their current use of the Framework? If so, how?
  • For those not currently using Version 1.0, would the proposed changes affect their decision about using the Framework? If so, how?

Feedback and comments should be directed to cyberframework@nist.gov.

To view a markup (.pdf) of the revised draft Framework, click here.

To view a clean version (.pdf) of the revised draft Framework, click here.

To view the draft roadmap (.pdf), click here.

To view the draft Framework Core (.xls), click here.

On August 1, 2017, the Senate introduced the “Internet of Things (IoT) Cybersecurity Improvement Act of 2017”, which aims to bolster the security of government-acquired IoT devices.  Sponsored by Sens. Mark Warner (D-VA), Cory Gardner (R-CO), Ron Wyden (D-OR), and Steve Daines (R-MT), the bill would require connected devices purchased by the government agencies to be patchable, rely on industry standard protocols, not use hard-coded passwords, and not contain any known security vulnerabilities.

The bill would also require each executive level agency head to inventory all connected devices used by the agency.  OMB and DHS would establish guidelines for the agencies based on DHS’s Continuous Diagnostics and Mitigation (CDM) program.  Specifically, the bill directs OMB to develop alternative network-level security requirements for devise within limited data process and software functionality.  It also directs DHS to issue guidelines regarding cybersecurity coordinated vulnerability disclosure policies to be required by contractors providing connected devices to the U.S. Government.  Finally, researchers would be exempted from liability under the Computer Fraud and Abuse Act and the Digital Millennium Copyright Act when engaging in good-faith research pursuant to adopted coordinated vulnerability disclosure guidelines.

This legislation follows calls for more security and standards addressing IoT devices to further safeguard information from potential attacks. For example, the Government Accountability Office (GAO) recently recommended that the Department of Defense update its policies to address IoT risks that leave them vulnerable to attacks.  In addition, Trump’s executive order on cybersecurity called for reports with recommendations to reduce the threat of botnets and other automated distributed attacks.

In a press release, Senator Warner, co-chair of the Senate Cybersecurity Caucus (SCC), states that the bill would provide “thorough, yet flexible guidelines for Federal Government procurements of connected devices.”  In the same statement, the SCC’s co-chair, Sen. Garner, states the bill would “ensure the federal government leads by example and purchases devices that meet basic requirements to prevent hackers from penetrating our government systems.”

To view the introduced legislation, click here.

To view the public statement, click here.

To view the fact sheet summary, click here.

Earlier this month, the new cybersecurity regulation from the New York Department of Financial Services (“DFS“) took effect. The new regulation requires banks, insurance companies and other financial services institutions regulated by the DFS to establish and maintain a cybersecurity program designed to protect consumers and ensure the safety and soundness of New York State’s financial services industry.

The final cybersecurity regulation is very similar to the proposed regulation, which we reported on in a previous post, but contains a few notable changes:

  • Record retention requirements for audit trails designed to detect and respond to Cybersecurity Events were reduced from five years to three years.
  • Clarification that Covered Entities’ policies and procedures regarding notice to be provided by Third Party Service Providers of Cybersecurity Events cover only Covered Entity’s Nonpublic Information being held by the Third Party Service Provider.
  • Clarification of the circumstances under which a Covered Entity must provide notice of Cybersecurity Event to the Superintendent.
  • The limited exemptions have been revised to specifically include the number of employees and the gross annual revenue of a Covered Entity’s affiliates located in New York.
  • Clarification on the exemptions available for companies regulated under New York’s Insurance Law.

Financial institutions in other states may wish to pay particular attention to this “first-in-the-nation cybersecurity regulation” issued by a state financial regulator, particularly as it may be only a matter of time before other states follow New York’s lead.

The DFS regulation, 23 N.Y.C.R.R. Part 500, is available here.

On January 10, 2017, NIST issued an update to the NIST Cybersecurity Framework (v.1.1).  After reviewing public comment and convening a workshop, NIST intends to publish a final version of this Version 1.1 in the fall of 2017.

Key updates the framework include:

  • Metrics.  A new section 4.0 on Measuring and Demonstrating Cybersecurity to discuss correlation of business results to cybersecurity risk management metrics and measures.
  • Supply Chain.  A greatly expanded explanation of using the framework for supply chain risk management purposes.
  • Authentication, Authorization and Identify Proofing.  Refinements to the language of the Access Control category to account for authentication, authorization, and identify proofing.  A subcategory has been added, and the Category has been renamed to “Identity Management and Access Control (PR.AC) to better represent the scope of the Category and corresponding subcategories.
  • Explanation of Relationship between Implementation Tiers and Profiles.  Adds language on using Framework Tiers in Framework implementation, to reflect integration of Framework considerations within organizational risk management programs, and to update Figure 2.0 to include actions from the Framework Tiers.

More detail on the changes can be found in Appendix D.  NIST seeks public comment on the following questions:

  • Are there any topics not addressed in the draft Framework Version 1.1 that could be addressed in the final?
  • How do the changes made in the draft Version 1.1 impact the cybersecurity ecosystem?
  • For those using Version 1.0, would the proposed changes impact your current use of the Framework? If so, how?
  • For those not currently using Version 1.0, does the draft Version 1.1 affect your decision to use the Framework? If so, how?
  • Does this proposed update adequately reflect advances made in the Roadmap areas?
  • Is there a better label than “version 1.1” for this update?
  • Based on this update, activities in Roadmap areas, and activities in the cybersecurity ecosystem, are there additional areas that should be added to the Roadmap? Are there any areas that should be removed from the Roadmap?

A redline version of the framework can be found by clicking here.  A clean version of the Framework may be found by clicking here.