Time is running out for lawyers representing certain types of business entities, specifically, those in the financial sector and those doing business in the European Union (EU), and there is still much work left to do. The window is closing regarding when critical personal data belonging to those businesses that are in a lawyer's possession must be shielded from unauthorized access over the lawyer's computer systems. Incidentally, if your clients are involved in health care, that same window closed a few years ago.

What does this mean to the practice of law in this country? The continually evolving nature of cybersecurity is increasingly making lawyers and law firms as mandatorily required to comply with modern cyber-safety practices as is required of the businesses they represent.

How can this be? This coming May, regulations issued in the EU in April 2016, known as the General Data Protection Regulations (GDPR) go into full force and effect. In March 2017, regulations issued by the New York State Department of Financial Services (DFS) became effective (23 NYCRR 500), but the start of compulsory compliance of various portions are staggered for a two-year period through March 2019 (23 NYCRR 500.22). Both the DFS and EU privacy regulations not only mandate that their respectively designated businesses keep certain personal data in their possession protected, but the regulations' application extends to all entities, including lawyers, who service these businesses and possess such personal data.

More importantly, businesses covered by the rules and regulations either have been or will soon be required to certify that all vendors providing services to them are cyber-compliant. Hence, these businesses will be forced to seek legal counsel only from those who can demonstrate sufficient in-house cybersecurity practices.

Genesis

This concept of expanding cybersecurity rule requirements to those who provide services to the businesses primarily covered by those requirements started in the health care industry, although that has only been recently true. For when the Health Insurance Portability and Accountability Act of 1996 (HIPAA) was first enacted, it was virtually unenforceable for several reasons.

One method used by health care organizations covered by HIPAA (labeled “Covered Entities”[1]) to evade compliance was to outsource functions (billing, accounting, legal, etc.) to other entities not covered by HIPAA. When HIPAA-protected data was lost by these outsourced businesses, the respective Covered Entity could say, “We didn't lose it, so we can't be held accountable.” And since the businesses losing the data didn't fit within the definition of a Covered Entity, they also could not be held accountable.

Business Associates

Congress eventually had enough of this shell game and included a requirement in the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH) that a process be developed by the federal Department of Health and Human Services to counter this. Ultimately, a solution was set forth in the Omnibus Final Rules (OFR), published on Jan. 25, 2013 (78 Fed Reg 17), made effective March 26, 2013, and made compulsory 180 days later on Sept. 22, 2013.

Included in the OFR was a novel concept that not only would the Covered Entity be liable for any of its mishandling of protected data, but also liable for any “Business Associate” assisting the Covered Entity and losing that data. Additionally, the Business Associate itself would be independently and equally liable in its own right.

What constitutes a Business Associate? It is a little premature to answer that with total certainty, for that term is defined in the HIPAA/HITECH provisions by function (see 45 CFR 160.103) and not type of business. It will ultimately be left to the courts and regulatory agencies to establish precisely what entities fit that definition.[2] One thing is certain, however, that any provider of legal services to a Covered Entity is considered a Business Associate because such service is specifically listed in the statutory language. (See paragraph (ii) of subsection (1), under the definition of Business Associate in 45 CFR 160.103.)

DFS Regulations

The overall schemata of NY's DFS regulations fairly closely aligns with that of HIPAA/HITECH. Here, a Covered Entity is defined as “any Person operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the Banking Law, the Insurance Law or the Financial Services Law.” 23 NYCRR 500.01(c). Considering the fact that New York City is the global epicenter of the worldwide financial community, these regulations should have effect far beyond the geographical boundaries of New York state.

Instead of the term Business Associate, the DFS regulations use “Third Party Service Provider.” 23 NYCRR 500.01(n). Its definition (“provides services to the Covered Entity, and maintains, processes or otherwise is permitted access to [protected information] through its provision of services to the Covered Entity”) is far more generic than HIPAA/HITECH's definition of Business Associate, but should clearly cover legal services.

GDPR

The EU looks at personal data privacy differently. While in the United States, privacy is tied to a particular industry or activity, it is considered a fundamental right of every EU citizen regardless of activity or industry. As a result, the protections afforded that privacy are constructed differently.

Once common thread with DFS and HIPAA/HITECH regulations is that any EU entity with personal information of EU citizens that shares that data outside the EU, must gain assurances that the outside entity will comply with GDPR. Likewise, any U.S. entity “doing business” in the EU comes within the jurisdiction of the GDPR and must apply those protections as any EU entity would.

Additionally, the U.S. Department of Commerce and the European Commission have agreed to a privacy framework between the two jurisdictions called the “Privacy Shield.”[3] Participation by U.S. companies is voluntary, but by joining, a company self-certifies to the Commerce Department that it is in compliance with EU privacy standards and further agrees to submit to numerous other guidelines designed to assure: (1) transparency of data exchange, (2) adherence to EU privacy concerns and (3) the existence of mechanisms for EU citizens to seek cost-free redress for alleged violations.

Common Privacy Standards

The privacy standards set pursuant to HIPAA/HITECH, DFS and GDPR greatly overlap and are the result of modern, commonly-shared cybersecurity practices. While there are not insignificant differences among these statutes and regulations, they share many basic concepts.

Among the most important is the ultimate goal of data identification and location. Personal information possessors must know what data they possess and where on their network the data is located, which is no small feat since such data can reside in some very hard-to-find places on any computer network.

One of the reasons why this is so important is because when an entity's network is breached, as it inevitably will be, rapid decisions must be made whether the breach includes access to protected data and under whose law and jurisdictions is the lost data governed. Post-breach is not the ideal time to be combing an entire entity's network looking for where critical data is located.

Identification and location is only the start of a very involved security process. Once identified and located, the vulnerabilities of such data must be evaluated via what is commonly referred to as a “risk assessment.” Some risk must be addressed and eliminated or, at the very least, minimized. Some risk should be avoided or outsourced. Some should be tolerated, possibly supported by cyber-insurance.

Written policies and procedures must be created, formalized and approved by all of the entity's stakeholders (meaning those who might lose their jobs if the procedures are inadequate or easily violated). Included in those documents should be a procedure for remediation when breaches occur and a general description of potential penalties to employees for disobeying internal guidelines.

Extensive training of employees as to these policies and procedures is, obviously, absolutely required. Additionally, a system of unannounced security-checking must also be installed (usually described as “penetration testing”) to verify that employees understand what is expected of them and are in compliance.

Industry-standard technological safeguards must be installed, such as encryption for both data-at-rest and data-in-transit. Multi-factor authentication must be deployed requiring employees to utilize at least two independent methods to access the company's system. It is no longer an acceptable security practice for employees to merely log into a network containing sensitive company data merely through the use of a password because they are usually too easy for hackers to crack.

Recognized methodologies must be instituted to respond to potentially successful attacks on an entity's network. An incident response team must be created, trained, and given practice dry-runs of various infiltration scenarios. Audit trails of daily system network activity must be generated and maintained so that in-house security staff, and in particular, the incident response team can most efficiently diagnose the source of an attack and determine an adequate response.

Lastly, a public relations team should be assembled to field security complaints made to the entity, address the press and public when breaches occur, and notify the necessary authorities and identity theft victims as required by law or the needs of engaging law enforcement.

Conclusion

It should be painfully obvious that such a privacy paradigm cannot be generated overnight. Even less practical is waiting until the breach of protected personal data occurs and trying to back-fill required security procedures after the fact.

Unquestionably, this overall task of becoming cybersecure and cyber-compliant can seem horribly daunting, particularly to those new to these mandates. The better news is that the community of cybersecurity experts, technicians and lawyers has been growing for more than a generation so that industry-accepted practices have developed and are more robust now than ever. It is no longer the day when such practices must be created from scratch, but it also means burying one's head in the sand is no longer an acceptable option.

Endnotes:

[1] Defined in 45 CFR 160.103 as a “health care provider” (think doctors, dentists, nurses, hospitals, clinics, etc.), a “health plan” (think medical insurance), or a “health care clearinghouse” (think an entity that translates and transfers data from one health care entity to another).

[2] Be aware that under HIPAA/HITECH it is specifically stated that a Covered Entity can be a Business Associate of another Covered Entity, further supporting the concept that it is an entity's function, not its self-designation, that decides the appropriate definition for HIPAA/HITECH purposes.

[3] It should be noted that the Privacy Shield is presently under extensive litigation in the EU. Its survival in its current construct is uncertain.

Stephen Treglia is the former head of the cybercrime unit at the Nassau County district attorney's office and is currently a Cyber & Information Security Consultant at Cordium, a Manhattan-based international cybersecurity and cyber-compliance company.