On May 25, more than two years' worth of anticipation concluded when the European Union's General Data Protection Regulation (GDPR) finally reached full enforcement status. Passed by the EU Parliament on April 14, 2016 [(EU) 2016/679], it was decided to give everyone affected by the dramatic changes more than two years to prepare for the new requirements.

GDPR replaces the 1995 Data Protection Directive (the directive) and applies to all current 28 EU member states. If the UK goes through with Brexit, the GDPR consequences are a little unclear, but that won't be an issue until early 2019.[FN1] And penalties for violations are not for the faint of heart with maximums of 4 percent of a year's gross revenue or €20 million, whichever is greater.

It would be shortsighted, however, to consider the evolution of the entirety of cybersecurity concepts solely through the experience of the directive and the GDPR, for that experience has not existed solely within its own vacuum. Rather, it has been influenced, in significant part, by advances developed by other constructs of cybersecurity paradigms.

In the Beginning

When the earliest versions of these laws and regulations were enacted just before the turn of the century, it was difficult to predict the fullest impact they would have in just a few short years. For example, the directive was merely a recommendation to the EU member states. Each country could pick and choose what provisions to utilize, leading to a wide range of enforcement from one country to the next. Also, the directive only applied to enterprises physically located within the confines of the Union.

The directive was not alone in its limitations. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) was virtually unenforceable as originally enacted. Its title, alone, proves its focus was directed more at making the mobility of medical and insurance information between such businesses simpler to accomplish than demonstrating any concern about the unauthorized sharing of such data. The Gramm-Leach-Bliley Act of 1999 (GLBA) was similarly feeble in protecting personal and financial information. Nevertheless, the privacy of such critical personal, healthcare and financial information had to have its birth somewhere, and the events that unfolded shortly thereafter quickly expanded the effect of these laws and regulations.

Enter Breach Notification

The next leap forward in this evolution was the introduction of breach notification laws, first in California in 2002, and followed closely behind by sister states, including New York. This was a major step because victims of identity theft, prior to this, had virtually no way of connecting a definitive breach to the exposure of their personal information to unauthorized persons.

This summer, the last two states will have enacted their respective versions (Alabama on June 1[FN2] and South Dakota on July 13[FN3]), extending the effects of breach notification to all 50 states and 4 U.S. territories. And these laws have been far from static as each leap-frogs the other in bringing forth new requirements, such as demanding encryption or expanding its applicability to different commercial and governmental endeavors.

Nor have the federal provisions remained stagnant over the years. For example, GLBA adopted breach notification in 2002, but it was healthcare regulation that really exploded through the next major barrier.

Expanded Protections

The Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH Act) opened broad novel enforcement opportunities. It empowered state attorneys general with the ability to initiate HIPAA civil actions. Previously, that was only the province of the federal Department of Health and Human Services (HHS). Furthermore, the maximum fine per violation increased from $50,000, to $1.5 million per year of non-compliance.

The biggest advance, however, was the expanded breadth and depth of entities that must comply with HIPAA-HITECH. Prior to 2009, HIPAA applied only to “covered entities” (CEs), which is defined as: health plans, health care clearinghouses and health care providers.

The HITECH Act greatly increased HIPAA's applicability by adding “business associates” (BAs) and their sub-contractors. A BA is very broadly defined by the service or function it provides to a CE. The functions can include, among others, data analysis, claims processing, billing, benefits management, quality assurance, practice management, etc. Services are defined, among others, as legal, actuarial, accounting, consulting, financial, data aggregations, etc. Most healthcare CEs have BAs numbering in the hundreds, even thousands.

Costly Data Loss

These modifications in federal healthcare regulation enforcement soon became dramatically evident as the result of a 2011 theft from an employee's car of an unencrypted laptop belonging to Accretive Health of Chicago, a medical bill collector. In the first HIPAA action brought by a state attorney general, Minnesota's Lori Swanson sued on behalf of 23,500 of her state's citizens whom she claimed were victims of identity theft due to the loss of the laptop.

While the dollar amount of the HIPAA settlement was relatively modest, only $2.5 million, it was the penalties which followed that ballooned the total loss to as much as $150 million for the theft of a single laptop. Part of the settlement with the Minnesota AG included an agreement not to do business anywhere in Minnesota for between two to six years, at the sole discretion of the AG.

As a publicly traded company, Accretive reported the HIPAA settlement in its next public earnings statement, acknowledging the yearly loss of Minnesota revenue at between $23-25 million a year. A class action suit by the shareholders followed, which was settled for $14 million. Next, the Federal Trade Commission brought an action alleging unfair or deceptive practices, and that was settled with a 20-year agreement to undergo biennial independent auditing to ensure Accretive operated in a cybersecure manner, of course, at Accretive's expense.

Accretive's breach did not only affect its bottom-line. As a BA of its clients, which in the AG's HIPAA action involved two Minnesota hospitals, it put them at risk of regulatory violations.

And HHS made one of the hospitals pay for Accretive's loss. In March of 2016, North Memorial Healthcare System (NMHS) was fined $1.55 million, even though it had nothing directly to do with the loss of its data caused by Accretive's misconduct. The penalty was imposed because NMHS did not have the required written CE-BA agreement with Accretive and failed to appropriately oversee its handling of the hospital's patient data.

Model Replication

The CE-BA blueprint initiated by the HITECH amendments to HIPAA were soon followed by other cybersecurity regulations. When New York's Department of Financial Services (DFS) instituted its regulations last year (23 NYCRR 500.00, et. seq.), it made it applicable to all of its version of “covered entities” [defined as “any person operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorizations under the Banking Law, the Insurance Law or the Financial Services Law,” see 23 NYCRR 500.01(c)], as well as all “third-party service providers” (23 NYCRR 500.11), again, a very broadly defined term.

The DFS regulations brought a new cybersecurity dimension to the regulatory matrix in the way its jurisdictional applicability applies. Rather than limit itself only to financial institutions physically located in New York, it extends to all businesses subject to the three New York statutory/regulatory regimes regardless of where they are.

GDPR has similarly adopted the broad geographical and substantive jurisdictional precepts of HIPAA-HITECH and DFS. Under the directive, an enterprise had to be physically within the borders of one of the EU states, regardless of the citizenship or location of the personnel information data it possessed, to come within its jurisdiction, and that will continue under GDPR. The big difference now is that GDPR will also apply to any enterprises anywhere in the world that possesses or processes data of EU citizens.

And the compliance requirements for controllers under GDPR are stringent, pretty much just as they are for CEs under DFS and HIPAA/HITECH. Personal information data must be protected via such processes as: data identification and mapping, data protection impact assessments, physical security, written policies and procedures, encryption, employee training, penetration testing, business continuity and incident response plans, incident response team creation and test practicing, breach notification, privacy officer appointment, just to name some of the required activities.

Ground-Breaking Paradigm

GDPR, however, further evolved the regulatory schemata by expanding the types of functions performed by persons that it covers, for it has constructed an importantly alternate formula. While data privacy in America is funneled into specific buckets based on type of business, such as finance or healthcare or credit card information, etc., the EU views personal data privacy much differently. There, it is a right of citizenship. This will have some interesting ramifications.

Rather than structured as CEs and businesses that supply CEs certain services, GDPR labels parties as either “controllers” (those that direct how personal data shall be processed) and “processors” (broadly defined as doing virtually anything with the personal data, such as, storing, transporting, categorizing, etc., at the direction of a controller).

One of the difficulties with the new EU privacy paradigm is that it will be very easy to act in the role of processor one moment and then a controller with the same data set. And the legal profession is a perfect scenario in which this could occur. Data a client initially sends to a lawyer solely for holding purposes could be utilized by the attorney and transferred elsewhere in the form of a contract or other type of negotiation, thereby turning the lawyer into a controller.

The significance is that the processor is solely liable, under the EU provisions, to the controller for handling citizens' private data strictly at the direction of the controller. But once a processor becomes a controller of the data, he or she is now answerable, just as every other controller, to the citizens whose private information originated with the lawyer's client.

GDPR also creates other novel and unique demands on controllers, again mostly as the result of the EU's mindset of the right to privacy. No longer can a controller bury a consent to process data in a lengthy terms of use agreement full of complex legalese. Consent must be unambiguous, informed and clearly given freely. Also sole reliance on consent as the basis of lawful processing is a bit risky because the consenting party can withdraw it at any time.

The other lawful bases of processing (GDPR Article 6) are legal obligations, contractual obligations, legitimate interests of the controller, vital interests of the data subject or another person, or a task carried out in the public interest. Unless processing meets at least one of these bases, processing of a citizen's personal data cannot occur.

In addition, consistent with the EU privacy rights philosophy, citizens are recognized as having specific controls over the use and possession of their personal information, called “data privacy rights” under GDPR (Articles 13-22). These include the rights to access, rectification, erasure (“to be forgotten”), portability, etc.

Conclusion

What should concern every entity that possesses someone else's personal data is the fact that the rapid recent evolution of cybersecurity laws and regulations so soon after the start of the 21^st century readily implies the dust is, as of yet, far from settled. With every new advance in technology or viewpoint of how to best protect sensitive personal data, the serious likelihood exists that those constructs will be adopted by those paradigms that currently do not utilize them.

But even the current reality presents much danger for those attorneys who have yet to fully perceive the risks lurking in the shadows. For the clock is long-past ticking for any entity to prepare for data security and compliance. The enforcement dates for all provisions described in this article have either passed or will go into effect very soon, and fulfilling all of the requirements cannot be accomplished overnight. They typically take weeks, even months.

If your firm, company or enterprise has not yet started down this path, time is of the absolute essence. It used to be said that your business computer systems have either been hacked or will soon be. For the past several years, that saying has been changed to you are either aware that your systems have been hacked or you don't know they already have been.

Of even greater importance, businesses are demanding law firms sign written agreements affirming their compliance with whatever regulatory requirements are faced by the client. As part of a HIPPA, DFS, GDPR relationship, clients will increasingly insist law firms assure their cybersecurity and cyber-compliance capabilities or those clients will seek legal representation elsewhere.

ENDNOTES:

1. https://www.independent.ie/business/data-sec/gdpr-will-the-uk-still-be-a-safe-place-for-your-data-postbrexit-36741468.html
2. https://www.huntonprivacyblog.com/2018/04/03/alabama-becomes-final-state-enact-data-breach-notification-law/
3. https://www.huntonprivacyblog.com/2018/03/23/south-dakota-enacts-breach-notification-law.

Stephen Treglia, the founder and first Chief of the Cybercrime Unit at the Nassau County District Attorney's Office, is currently a Cyber & Information Security Consultant at Cordium in New York City.