Search right to access

Co-author: Valerie Jackson

While healthcare organizations are embracing new technologies such as patient portals, a recent report shows that organizations’ cybersecurity measures for these technologies are behind the times. A patient portal is a secure online website that allows patients to access their Electronic Health Record from any device with an Internet connection. Many patient portals also allow patients to request prescription refills, schedule appointments, and securely message providers. With this increased access for patients comes the risk that someone other than the patient will gain unauthorized access to the portal, and to the patient’s electronic protected health information (ePHI).

2019 has seen record numbers of patient records being breached. Halfway through 2019, around 25 million patient records have been breached, eclipsing the number of patient records breached in all of 2018 by over 66%. In this environment where hackers find patient records a valuable commodity on the black market, healthcare organizations are must balance patients’ desire for ease of use with the duty to prevent unauthorized access to patient records. To learn more about how healthcare organizations are meeting this challenge, LexisNexis® Risk Solutions in collaboration with the Information Security Media Group conducted a survey in spring 2019 asking healthcare organizations about their cybersecurity strategies and patient identity management practices. The results of the survey, which included responses from more than 100 healthcare organizations, including hospitals and physician group practices, were recently published in a report, “The State of Patient Identity Management” (the “report”).

The report concluded that healthcare organizations had a high level of confidence in the security of their patient portals, but this confidence may be misplaced based upon the security measures respondents reported they had in place. The vast majority of healthcare organizations reported that they continued to use traditional authentication methods such as username and password (93%), knowledge-based authentication questions and answers (39%), and email verification (38%). Notably, less than two-thirds reported using multifactor authentication. Multifactor authentication verifies a user’s identity in two or more ways, using: something the user knows (passwords, security questions); something the user has (mobile phone, hardware that generates authentication code); and/or something the user does or is (fingerprint, face ID, retina pattern).

While the HIPAA Security Rule does not require multifactor authentication, it does require covered entities and business associates to use security measures that reasonably and appropriately implement the HIPAA Security Rule standards and implementation specifications. Generally, the HIPAA Security Rule requires covered entities and business associates to (1) ensure the confidentiality, integrity, and availability of all ePHI the covered entity or business associate creates, receives, maintains, or transmits, (2) protect against any reasonably anticipated threats or hazards to the security or integrity of such information, and (3) protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required. The Person or Entity Authentication standard of the HIPAA Security Rule requires that covered entities and business associates implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. However, this standard has no implementation specifications. It is also worth mentioning that under the HIPAA Privacy Rule prior to a permissible disclosure, a covered entity must verify the identity of person requesting ePHI and their authority to have access to that ePHI, if either the identity or authority is not known to the covered entity. In addition, the covered entity must obtain “documentation, statements, or representations” from the person requesting the ePHI when such is a condition of the disclosure.

Healthcare organizations are not required to adopt any one cybersecurity framework or authentication method under HIPAA, however increasing cybersecurity and implementing multifactor authentication for access to patient portals certainly helps with compliance under the HIPAA Security Rule. Failure to implement reasonable and appropriate cybersecurity measures could not only lead to a healthcare data breach, but it could also result in a covered entity or business associate being fined by the HHS Office for Civil Rights. To learn more about how the firm can assist healthcare organizations with HIPAA compliance and data security, please contact your Jackson Lewis attorney.

On Thursday, New York Governor Andrew Cuomo signed into law the Stop Hacks and Improve Electronic Data Security Act (SHIELD Act), sponsored by Senator Kevin Thomas and Assemblymember Michael DenDekker. The SHIELD Act, which amends the State’s current data breach notification law, imposes more expansive data security and data breach notification requirements on companies, in the hope of  ensuring better protection for New York residents from data breaches of their private information. The SHIELD Act takes effect on March 21, 2020. Governor Cuomo also signed into law the Identity Theft Prevention and Mitigating Services Act that requires credit reporting agencies that face a breach involving Social Security numbers to provide five years of identity theft prevention and mitigation services to affected consumers. It also gives consumers the right to freeze their credit at no cost. This law becomes effective in 60 days.

Below are several FAQs highlighting key features of the SHIELD Act:

What is Private Information under the SHIELD Act?

Unlike other state data breach notification laws, New York’s original data breach notification law included definitions for “personal information” and “private information.” The current definition of “personal information” remains: “any information concerning a natural person which, because of name, number, personal mark, or other identifier, can be used to identify such natural person.” However, the SHIELD Act expands the definition of “private information” which sets forth the data elements that, if breached, could trigger a notification requirement. Under the amended law, “private information” means either:

  • personal information consisting of any information in combination with any one or more of the following data elements, when either the data element or the combination of personal information plus the data element is not encrypted, or is encrypted with an encryption key that has also been accessed or acquired:
    • social security number;
    • driver’s license number or non-driver identification card number;
    • account number, credit or debit card number, in combination with any required security code, access code, password or other information that would permit access to an individual’s financial account; account number, credit or debit card number, if circumstances exist wherein such number could be used to access an individual’s financial account without additional identifying information, security code, access code, or password; or
    • biometric information, meaning data generated by electronic measurements of an individual’s unique physical characteristics, such as a fingerprint, voice print, retina or iris image, or other unique physical representation or digital representation of biometric data which are used to authenticate or ascertain the individual’s identity; OR
  • a user name or e-mail address in combination with a password or security question and answer that would permit access to an online account.

It is worth mentioning that the SHIELD Act’s expansive definition of “private information” is still not as broad as the definition of the analogous term under the laws of other states. For example, California, Illinois, Oregon, and Rhode Island have expanded the applicable definitions in their laws to include not only medical information, but also certain health insurance identifiers.

How has the term “breach of security of the system” changed?

The SHIELD Act alters the definition of “breach of the security of the system” in two significant ways. First, it broadens the circumstances that qualify as a “breach” by including within the definition of that term incidents that involve “access” to private information, regardless of whether they resulted in “acquisition” of that information. Under the old law, access absent acquisition did not qualify as a breach. In connection with this change, the amendments also add several factors for determining whether there has been unauthorized access to private information, including “indications that the information was viewed, communicated with, used, or altered by a person without valid authorization or by an unauthorized person.”

Second, as discussed above, the expansion of the definition of private information effectively expands the situations which could result in a breach of the security of the system.  Notably, the SHIELD Act retains the “good faith employee” exception to the definition of “breach.”

Are there any substantial changes to data breach notification requirements? And who must comply?

Any person or business that owns or licenses computerized data which includes private information of New York residents must comply with breach notification requirements, regardless of whether the person or business conducts business in New York.

That said, there are several circumstances which would exempt a business from the breach notification requirements. For example, notice is not required if “exposure of private information” was an “inadvertent disclosure and the individual or business reasonably determines such exposure will not likely result in misuse of such information, or financial harm to the affected persons or emotional harm in the case of unknown disclosure of online credentials”. Further, businesses that are already regulated by and comply with data breach notice requirements under certain applicable state or federal cybersecurity laws (e.g., HIPAA, NY DFS Reg. 500, Gramm-Leach-Bliley Act) are not required to further notify affected New York residents, however, they are still required to notify the New York State Attorney General, the New York State Department of State Division of Consumer Protection, and the New York State Division of the State Police.

What are the “reasonable” data security requirements? And who must comply with them?

As with the notification requirements, the SHIELD Act requires that any person or business that owns or licenses computerized data which includes private information of a resident of New York must develop, implement and maintain reasonable safeguards to protect the security, confidentiality and integrity of the private information. Again, businesses in compliance with laws like HIPAA and the GLBA are considered in compliance with this section of the law. Small businesses are subject to the reasonable safeguards requirement, however safeguards may be “appropriate for the size and complexity of the small business, the nature and scope of the small business’s activities, and the sensitivity of the personal information the small business collects from or about consumers.” A small business is considered any business with fewer than fifty employees, less than $3 million in gross annual revenue in each of the last 3 years, or less than $5 million in year-end total assets.

The law provides examples of practices that are considered reasonable administrative, technical and physical safeguards. For example, risk assessments, employee training, selecting vendors capable of maintaining appropriate safeguards and implementing contractual obligations for those vendors, and disposal of private information within a reasonable time period, are all practices that qualify as reasonable safeguards under the law.

Are there penalties for failing to comply with the SHIELD Act?

The SHIELD Act does not authorize a private right of action, and in turn class action litigation is not available. Instead, the Attorney General may bring an action to enjoin violations of the law and obtain civil penalties. For data breach notification violations that are not reckless or knowing, the court may award damages for actual costs or losses incurred by a person entitled to notice, including consequential financial losses. For knowing and reckless violations, the court may impose penalties of the greater of $5,000 dollars or up to $20 per instance with a cap of $250,000. For reasonable safeguard requirement violations, the court may impose penalties of not more than $5,000 per violation.

Conclusion

The SHIELD Act has far reaching effects, as any business that holds private information of a New York resident – regardless of whether that organization does business in New York – is required to comply. “The SHIELD Act will put strong safeguards in place to curb data breaches and identity theft,” said Justin Brookman, Director of Privacy and Technology Policy for Consumer Reports. The SHIELD Act signifies how seriously New York, like other states across the nation, is taking privacy and data security matters.  Organizations, regardless of their location, should be assessing and reviewing their data breach prevention and response activities, building robust data protection programs, and investing in written information security programs (WISPs).

Employers, you are not out of the CCPA woods yet.

If you have been tracking the proposed amendments to the California Consumer Privacy Act (CCPA), you know that businesses and stakeholders have been clamoring to shape the new sweeping law in a number of ways. We reported earlier this year on some of the potential changes approved by the California Assembly Privacy and Consumer Protection Committee, which moved on for further consideration. Upon arrival at the Senate Judiciary Committee, several of these business-friendly changes met some resistance, including AB 25 which generally would have excluded employee personal information from being covered under the CCPA.

While employers had hoped AB 25 would amend the CCPA to exclude information gathered in the employment context outright, on July 9, 2019, the California Senate Judiciary Committee clarified that will not be the case.

As we previously noted, the Privacy and Consumer Protection Committee in April unanimously approved AB 25 which sought to modify the definition of “consumer” under the CCPA to exclude “a natural person whose personal information has been collected by a business in the course of a person acting as a job applicant to, an employee of, a contractor of, or an agent on behalf of, the business, to the extent the person’s personal information is collected and used solely within the context of the person’s role as a job applicant to, an employee of, a contractor of, or an agent on behalf of, the business.”

A coalition in opposition to AB 25 expressed concerns that the exemptions go too far in eroding the rights of employee consumers, especially in light of current and future workplace monitoring practices. In response to these concerns, the bill’s author, Assemblymember Ed Chau, agreed to amend AB 25 to clarify that while employee data would be excluded from many of the CCPA’s requirements (including permitting consumers to request: the deletion of their personal information; the categories of personal information collected; the sources from which personal information is collected; the purpose for collecting or selling personal information; and the categories of third parties with whom the business shares personal information), employers subject to the CCPA would still be required to inform consumers (including employees) as to the categories of personal information they collect and the purposes for which such personal information shall be used.

Notably, AB 25’s exemption for employee data would not apply to the CCPA’s subdivision which establishes a private right of action, including those brought as a class action, for any consumer whose nonencrypted or nonredacted personal information is subject to an unauthorized access and exfiltration, theft, or disclosure as a result of the business’s violation of the duty to implement and maintain reasonable security procedures and practices. This private right of action establishing statutory damages permitting the recovery of damages in an amount not less than one hundred dollars ($100) and not greater than seven hundred and fifty ($750) per consumer per incident or actual damages, whichever is greater.

To afford business and consumer groups time to develop additional legislation to address concerns about employee personal information, Assemblymember Chau further revised AB 25 to specify that the exemption for employee data would only be effective for the 2020 calendar year and would be inoperative on or after January 1, 2021.

As amended, AB 25 unanimously passed through the Senate Judiciary Committee and will now go to the Senate Appropriations Committee, and if passed, to a full Senate for a final vote. AB 25’s amendments highlight the growing recognition of privacy interests in the employment context and the need for businesses to continue to prepare for the CCPA’s effective date.

As we recently noted, Washington state amended its data breach notification law on May 7 to expand the definition of “personal information” and shorten the notification deadline (among other changes). Not to be outdone by its sister state to the north, Oregon followed suit shortly thereafter—Senate Bill 684 passed unanimously in both legislative bodies on May 20, and was signed into law by Governor Kate Brown on May 24. The amendments will become effective January 1, 2020.

Among the changes effected by SB 684 is a trimming of the Act’s short title—now styled the “Oregon Consumer Information Protection Act” or “OCIPA” (formerly the “Oregon Consumer Identity Theft Protection Act” or “OCITPA”). Apart from establishing a much more palatable acronym, the amended short title mirrors the national (and international) trend of expanding laws beyond mere “identity theft protection” to focus on larger scale consumer privacy and data rights.

Key substantive changes to the data breach notification law include:

  • Expanding the definition of “breach of security” to cover personal information that a person “maintains or possesses” (where previously only information a person “maintains” was covered);
  • Adding an individual’s account username and password (or other means of account identification and authentication) to the definition of “personal information” sufficient to trigger breach notification obligations—whether or not combined with the individual’s real name;
  • Defining the terms “covered entity” and “vendor,” to replace the cumbersome language in the current statute (e.g., “A person that owns or licenses personal information that the person uses in the course of the person’s business, vocation, occupation or volunteer activities and that was subject to a breach shall give notice . . . .” becomes “A covered entity that was subject to a breach shall give notice . . . .”).
  • Creating new obligations for “vendors,” including a requirement to notify the applicable covered entity within 10 days of discovery of a breach, and a requirement that the vendor notify the state Attorney General if said breach affects more than 250 consumers or an undetermined number of consumers (notification to the covered entity was previously only required “as soon as is practicable” after discovery, and vendors had no obligation to notify the Attorney General); and,
  • Specifying that covered entities or vendors in compliance with HIPAA or the GLBA (and subject thereto) are exempt from the state’s data breach notification requirements, and adding that compliance with the data security safeguards set forth in HIPAA or the GLBA may be raised as an affirmative defense in any action alleging that a covered entity or vendor has failed to comply with OCIPA’s own data security safeguarding requirements.

For organizations subject to the new law, including anyone that “owns, licenses, maintains, stores, manages, collects, processes, acquires or otherwise possesses personal information” in the course of business, the biggest change to note is that the disclosure of usernames and passwords alone is now sufficient to trigger breach notification obligations. Companies should also make an effort to determine whether they may be acting as a “vendor” under OCIPA’s new definition (“a person with which a covered entity contracts to maintain, store, manage, process or otherwise access personal information”), as vendor entities will have new obligations when the amendments go into effect on January 1, 2020.

The GDPR is wrapping up its first year and moving full steam ahead. This principles-based regulation has had a global impact on organizations as well as individuals. While there continue to be many questions about its application and scope, anticipated European Data Protection Board guidance and Data Protection Authority enforcement activity should provide further clarity in the upcoming year. In the meantime, here are a few frequently asked questions – some reminders of key principles under the GDPR and others addressing challenges for implementation and what lies ahead.

Can US organizations be subject to the jurisdiction of the GDPR?

Whether a US organization is subject to the GDPR is a fact-based determination. Jurisdiction may apply where the US organization has human or technical resources located in the EU and processes EU personal data in the context of activities performed by those resources. In cases where the US organization does not have human or technical resources located in the EU, it may be subject to the GDPR’s jurisdiction in two instances: if the organization targets individuals in the EU (not businesses) by offering goods or services to them, regardless of whether payment is required, or if it monitors the behavior of individuals in the EU and uses that personal data for purposes such as profiling (e.g. website cookies, wearable devices). The GDPR may also apply indirectly to a US organization through a data processing agreement.

If we execute a data processing agreement, does that make our US organization subject to the GDPR?

When an organization subject to the GDPR engages a third party to process its EU data, the GDPR requires that the organization impose contractual obligations on the third party to implement certain GDPR-based safeguards. If you are not otherwise subject to the GDPR, executing a data processing agreement will not directly subject you to the GDPR. Instead, it will contractually obligate you to follow a limited, specific set of GDPR-based provisions. Your GDPR-based obligations will be indirect in that they are contractual in nature.

Does the GDPR apply only to the data of EU citizens?

No, the GDPR applies to the processing of the personal data of data subjects who are in the EU regardless of their nationality or residence.

Is our organization subject to the GDPR if EU individuals access our website and make purchases?

If your organization does not have human or technical resources in the EU, the mere accessibility of your website to EU visitors, alone, will not subject you to the GDPR. However, if your website is designed to target EU individuals (e.g. through features such as translation to local language, currency converters, local contact information, references to EU purchasers, or other accommodations for EU individuals) your activities may be viewed as targeting individuals in the EU and subject you to the GDPR.

Are we required to delete an individual’s personal data if they request it?

If your organization is subject to the GDPR, an individual may request that you delete their personal data. However, this is not an absolute right. Your organization is not required to delete the individual’s personal data if it is necessary

  • for compliance with a legal obligation or the establishment, exercise or defense of a legal claim
  • for reasons of public interest (e.g. public health, scientific, statistical or historical research purposes)
  • to exercise the right of freedom of expression or information
  • where there is a legal obligation to keep the data
  • or where you have anonymized the data.

Additional consideration should be given to any response when the individual’s data is also contained in your back-ups.

GDPR principles have started to influence law in the U.S. In fact, many have been watching developments regarding the California Consumer Privacy Act (CCPA), which shares a right to delete as it pertains to the personal information of a California resident. Similar to the GDPR, it is not an absolute right and in certain cases an exception may apply. For instances, both law contain an exception from the right to have personal information deleted when the information is needed to comply with certain laws.

Does the GDPR apply to an EU citizen who works in the US?

If your organization is not subject to the GDPR and you hire an EU citizen to work in the US, the GDPR may not apply to the processing of their personal data in the US. However, depending on the circumstances, the answer may be different if the EU citizen is in the US on temporary assignment from an EU parent. In that scenario, their data may be subject to the GDPR if the US entity’s relationship with the parent creates an establishment in the EU, and it processes this data in the context of the activities of that establishment. To the extent the EU parent transfers the EU employee’s personal data from the EU to the US entity, that transfer may require EU-US Privacy Shield certification, the execution of binding corporate rules, or standard contractual clauses. These measures are designed to ensure data is protected when it is transferred to a country, such as the US, that is not deemed to have reasonable safeguards.

Do we need to obtain an EU individual’s consent every time we collect their personal data?

If your organization is subject to the GDPR and processes an EU individual’s information, you must have a “legal basis” to do so. Consent is just one legal basis. In addition to consent, two of the most commonly used legal basis are the “legitimate interests” of your organization and the performance of a contract with the individual. A legitimate interest is a business or operational need that is not outweighed by the individual’s rights (e.g. processing personal data for website security, conducting background checks, or coordinating travel arrangements). Processing necessary to the performance of a contract is activity that enables you to perform a contract entered into with the individual (e.g. processing employee data for payroll pursuant to the employment contract or processing consumer data for shipping goods under a purchase order.)

Should we obtain an employee’s consent to process their personal data?

Continue Reading The GDPR – One Year and Counting

Many health care providers, including small and medium-sized physician practices, rely on a number of third party service providers to serve their patients and run their businesses. Perhaps the most important of these is a practice’s electronic medical record (EMR) provider, which manages and stores patient protected health information. EMR providers generally are business associates under HIPAA, subjecting them to many of the same requirements under the HIPAA privacy and security rules applicable to covered healthcare providers. HIPAA-covered healthcare providers should not assume their EMR providers comply with HIPAA and HITECH.

According to a federal Office for Civil Rights (OCR) press release, Medical Informatics Engineering, Inc. (MIE) has paid $100,000 to OCR and has agreed to a detailed corrective action plan to settle potential violations of the HIPAA privacy and security rules. MIE provides software and EMR services to healthcare providers.

According to reporting by the Chicago Tribune,

about 82 percent of hospital information security leaders surveyed reported having a “significant security incident” in the last 12 months, according to the 2019 Healthcare Information and Management Systems Society Cybersecurity Survey.

Yet, according to the same report, spending on information security only takes up about 5% of healthcare providers’ data security budgets, which is well below industry average. Additionally, some have estimated that in 2018, 20% of the breaches suffered by healthcare providers was caused by their third-party service providers. An excellent article by HIPAAJournal outlines a number of statistics illustrating the growing data security risk in healthcare.

In 2015, MIE reported to OCR that it discovered a breach which compromised user IDs and passwords enabling access to electronic protected health information (ePHI) of approximately 3.5 million people. OCR claims that, according to OCR’s investigation, MIE did not conduct a comprehensive risk analysis prior to the breach. The HIPAA rules require entities to perform an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of an entity’s ePHI. This is a basic requirement in the HIPAA security rules that all covered entities and business associates need to perform.

OCR Director Roger Severino noted,

The failure to identify potential risks and vulnerabilities to ePHI opens the door to breaches and violates HIPAA.

So, what is a healthcare provider to do?

A required element of HIPAA compliance includes having business associate agreements in place with business associates, including EMR providers. Under these agreements, business associate agree that they have satisfied the risk assessment requirement under HIPAA. However, in addition to making sure that compliant agreements are in place, covered healthcare providers may want to go a step further. That is, they may want to better assess the compliance efforts of their vendors as represented in the business associate agreement, particularly for those vendors that process and maintain so much of their patients’ ePHI. Providers might, for example, require such vendors to complete a detailed questionnaire about their data security practices, visit the vendor’s facilities, and/or request to review a copy of the vendor’s risk assessment. Similar practices can be applied to all vendors, not just EMR providers or business associates, based on the risk they pose.

Of course, healthcare providers should make sure they themselves are in compliance with the HIPAA privacy and security rules. This includes, among other things, conducting and documenting their own risk assessment. Simply having a set of policies and procedures is not sufficient.

A district court in Tennessee recently concluded in Wachter Inc. v. Cabling Innovations LLC that two former employees who allegedly shared confidential company information found on the company’s computer system with a competitor did not violate the Computer Fraud and Abuse Act (CFAA). The CFAA expressly prohibits “intentionally accessing a computer without authorization or exceeding authorized access, and thereby obtaining… information from any protected computer”.

The two former employees in question worked for Wachter Inc., a Kansas-based communications equipment provider, during which time they allegedly sent confidential company information to their personal email accounts and to email accounts of Wachter’s competitor, Cabling Innovations. In addition the former employees allegedly used Wachter’s resources and confidential information to obtain and perform work for Cabling Innovation.

In its reasoning, the Court emphasized that the CFAA does not define the term “without authorization” and some courts have found that “an employee may access an employer’s computer ‘without authorization’ where it utilizes the computer to access confidential or proprietary information that he has permission to access, but then uses that information in a manner that is inconsistent with the employer’s interest”. Moreover, the Court highlighted that “the CFAA was not meant to cover the disloyal employee who walks off with confidential information. Rather, the statutory purpose is to punish trespassers and hackers”.

The Court went on to state that the CFAA is primarily a criminal statute, and although it also permits “any person who suffers damage or loss by reason of a violation … [to] maintain a civil action against the violator to obtain compensatory damages and injunctive relief or other equitable relief,” the rule of “lenity” directs the Court to construe the CFAA coverage narrowly. The Court reasoned, “the rule of lenity limits the conduct that falls within the criminal prohibitions, it likewise limits the conduct that will support a civil claim”.

The CFAA has generated much debate among the courts regarding the scope of its application. Some forms of “unauthorized access” are obvious – e.g. a hacker breaking into a protected computer system resulting in data theft is clearly a CFAA violation and is the type of event the CFAA was originally designed to protect against. However, other circumstances, particularly in the employment context, can blur the lines of what is considered “unauthorized access” under the CFAA.

The court in Wachter is under the jurisdiction of the Sixth Circuit, which has not addressed the issue of a potential CFAA violation where an employee who has permission to access company information then misuses or misappropriates that information. That said, most districts courts in the Sixth Circuit have concluded that there cannot be a CFAA violation where an employee had permissible access to the computer system. Similarly, the Fourth Circuit held in WEC Carolina Energy Solutions LLC v. Miller that an employee who allegedly downloaded proprietary information from an employer’s computer system for the benefit of his subsequent employer did not violate the CFAA.

Other circuits, however, have taken a much more expansive approach to what employee activity is considered “without authorization” under the CFAA. For example, in U.S. v. John, the Fifth Circuit held that an employee violated the CFAA when she retrieved confidential customer account information she was authorized to access and transferred it to her half-brother for the purpose of committing a fraud. The First, Seventh and Eleventh Circuits have all taken a similarly expansive view that an employee violates the CFAA when he/she accesses the computer system in violation of the employer’s data use policies.

The U.S. Supreme Court has avoided addressing issues of CFAA vagueness. Most recently, the Supreme Court denied certiorari in Nosal v. United States, 16-1344, declining to weigh in on the scope of unauthorized access under the CFAA. The Ninth Circuit held in Nosal that David Nosal violated the CFAA by using his past assistant’s password to access his former employer’s computer system after his access credentials were expressly revoked.

Given the conflicting jurisdictional interpretations of the CFAA, companies should review their policies and procedures to ensure access rights and limitations to their information and information systems are clearly defined and effectively communicated to their employees. Taking these steps will help protect company data and may be useful in preserving a potential CFAA claim.

 

A security lapse has exposed the data of at least 13.7 million user records of the high-end job recruitment site, Ladders. The company left a cloud-hosted search database exposed without a password. Ladders took the database offline less than an hour after the news website TechCrunch alerted the company after learning about the potential breach from a security researcher, Sanyam Jain.

Each record included names, email addresses, addresses, phone numbers, their employment histories and even exact geolocation based off of individual IP addresses. The user profiles also contain information about the industry they’re seeking a job in and their current compensation in U.S. dollars.

A data leak of information such as social security numbers, phone numbers, credit history or other more sensitive information “would be a gold mine for cyber criminals who would have everything they need to steal identities, file false tax returns, get loans or credit cards,” according to Bob Diachenko, online publisher for TechCrunch. In contrast, most of the information affected in the Ladders’ data leak, while personal and sensitive, does not amount to personally identifiable information which could be used for identity theft.

Additionally, an important distinction should be made between data leaks and data breaches: data leaks are usually incidents in which data was unintentionally made public as the result of an accident or misapplication of a system’s features, however the data has not actively been accessed or exfiltrated; data breaches are incidents involving active threats which compromise a database.

The recent abundance of high-profile data leaks as of late emphasize the need for organizations today to be proactive rather than reactive. The legal landscape of the data privacy world also reflects this approach. For example, the General Data Protection Regulation (GDPR) enforces a “Privacy by Design” system, which requires any action a company undertakes that involves processing personal data must be done with data protection and privacy in mind at every step. Similarly the much anticipated California Consumer Privacy Act, requires a business to “implement and maintain reasonable security procedures and practices appropriate to the nature of the information to protect the personal information”, and similar frameworks are mandates in other states such as Colorado, Massachusetts and Oregon.

This wave of data leaks/breaches, combined with the growing public awareness of data privacy right and concerns, and legislative activity in the area, makes the development of a meaningful data protection program an essential component of business operations.

Image result for secret surveillanceThe New York Times newly established Privacy Project, recently highlighted the extent to which our society has created a “facial recognition machine” – cameras are everywhere, even in doorbells. Segments of society have accepted widespread surveillance on public streets, shopping malls, and in common areas of office buildings, apartment complexes, schools and similar places. But there are limits.

Early this month, 131 patients (and counting) of a women’s hospital in San Diego, California filed a lawsuit against the hospital after discovering that there was secret video surveillance in three labor and delivery operating rooms, recording medical procedures without patients’ consent. Patients were recorded during Cesarean sections, birth complications, treatment after miscarriage, hysterectomies and other medical procedures from July of 2012 to July of 2013.   Approximately 1,800 patients were recorded during this period. The patients are suing the hospital for invasion of privacy, breach of fiduciary duty, negligence, negligent infliction of emotional distress and unlawful recording of confidential information.

In addition to not informing the patients of the hidden cameras, the lawsuit alleges that the hospital was “grossly negligent” in its storage of the recordings. The lawsuit claims that recordings were stored on employee computers, often without password protection and that the hospital “destroyed at least half the recordings but cannot say when or how it deleted those files and cannot confirm that it took the appropriate steps to ensure the files were not otherwise recoverable.”

This is not the first lawsuit against the hospital regarding the hidden cameras. Since 2016, the hospital has faced several lawsuits alleging privacy violations and other claims stemming from the video records.

The hospital said in a statement on April 4th to the San Diego community that the cameras were installed as part of an investigation regarding drugs and other equipment missing from several anesthesia carts in hospital operating rooms, and it was not intended for patients to be visible on the recordings, although ultimately that was the case.

The issue of hidden cameras is particularly common in elder care facilities, where for example family members secretly install a “granny cam”, to step in and help protect their elderly loved ones from abuse in the facility, including neglect, physical abuse, unexplained serious injuries and thefts. A study published in 2011 found that an estimated 260,000 (1 in 13) older adults in New York had been victims of one form of abuse or another during a 12-month period between 2008 and 2009, with “a dramatic gap” between elder abuse events reported and the number of cases referred to formal elder abuse services. Clearly, states are struggling to protect a vulnerable and growing group of residents from abuse. Technologies such as hidden cameras may help to address the problem, but their use raises privacy, security, compliance, and other concerns.

Whether installed by a concerned family member in a nursing home, or a medical professional or a hospital administrator, the use of video surveillance devices can pose a number of issues and potential risks, particularly when the devices are hidden and/or record audio as well as video. Here are just a few questions these devices raise:

  • Has the organization addressed federal and state laws establishing consent requirements when recording communications?
  • Are there state laws that specifically addresses hidden cameras or similar privacy rights? For “granny cams”, at least five states (Illinois, New Mexico, Oklahoma, Texas, and Washington) have laws specifically addressing the use of cameras in this context. While state “granny cam” laws are not applicable to the hospital case, in California, for example, the California Invasion of Privacy Act (CIPA) protects against recording of an individual’s confidential information without prior consent.
  • In general, if the organization installs such a device, what rights and obligations does it have with respect to the scope, notice, content, access, security, storage, deletion and other aspects of the recording?
  • For surveillance likely to capture protected health information, have the HIPAA privacy and security regulations been addressed? This includes assessing the risk of making the recordings, controlling access to the recording, and securing that information.
  • What record retention, chain of custody, and record destruction requirements and best practices should be implemented?
  • How do the features of the device, such as camera placement and zoom capabilities, affect the analysis of the issues raised above?

Facilities considering this technology, even when well intentioned, must assess the privacy and security implications. Practices and procedures considered and implemented, as applicable, not only for what happens prior to device installation (i.e. notice, consent, device placement, scope etc.), but also for what happens after recordings occur, including lawful and effective data storage and deletion policies.

Following recent examinations of SEC-registered investment advisers and broker-dealers, the Securities and Exchange Commission’s (SEC) Office of Compliance Inspections and Examinations (OCIE) published a privacy risk alert on April 16, 2019. OCIE is hoping to remind advisers and broker-dealers about providing compliant privacy and opt-out notices, and adopting and implementing effective policies and procedures for safeguarding customer records and information, under Regulation S-P.

Privacy Notices. During the examinations, OCIE observed advisors and broker-dealers were not providing initial privacy notices, annual privacy notices and opt-out notices to their customers. When these notices were provided, many did not accurately reflect firms’ policies and procedures and/or notify customers of their right to opt out of having their nonpublic personal information shared with nonaffiliated third parties. OCIE’s risk alert, thus, reminds advisors and broker-dealers that Regulation S-P requires that they:

  • provide a clear and conspicuous notice to customers that accurately reflects privacy policies and practices generally no later than when a customer relationship is established,
  • provide a similar notice not less than annually during the continuation of the customer relationship, and
  • deliver a clear and conspicuous notice to its customers that accurately explains the right to opt out of some disclosures of non-public personal information about the customer to nonaffiliated third parties.

Written Policies and Procedures to Safeguard Customer Information. OCIE also observed during these examinations that some advisors and broker-dealers had not adopted written policies and procedures as required under the Safeguards Rule. According to the risk alert, some firms simply:

restated the Safeguards Rule but did not include policies and procedures related to administrative, technical, and physical safeguards.

And, other policies

contained numerous blank spaces designed to be filled in by registrants.

Given the OCIE’s observations, purchasing sample privacy and data and security policies and procedures, perhaps online, without more, would likely be inconsistent with Regulation S-P. Data security compliance is more than simply having a policy document. OCIE explained that written policies and procedures under Regulation S-P must be “reasonably designed to ensure the security and confidentiality of customer records and information, protect against any anticipated threats or hazards to the security or integrity of customer records and information, and protect against unauthorized access to or use of customer records or information that could result in substantial harm or inconvenience to any customer.” Thus, the general approach for advisors and brokers-dealers should be to assess the threats and vulnerabilities to customer records and information, and then craft administrative, physical, and technical policies and procedures to address those threats and vulnerabilities.

OCIE also detailed data security practices that it found troubling under Regulation S-P. Examples include:

  • Personal devices – employees storing and maintaining customer information on their personal laptops without policies and procedures address how to protect the information on those devices.
  • Electronic communications – the absence of policies designed to prevent employees from regularly sending unencrypted emails to customers containing PII.
  • Training and monitoring – a lack of training for employee about encryption, password-protection, and transmission of PII through company-approved methods.
  • Outside vendors – advisors and broker-dealers maintaining policies that required outside vendors to contractually agree to keep customers’ PII confidential, but not following their own policies.
  • PII inventory – not maintaining an inventory of all systems on which PII is maintained leaving advisors and broker-dealers unaware of the categories of customer PII that they maintain, and limiting the ability to adequately safeguard customer information.
  • Incident response plans – plans failed to address role assignments for implementing the plan, actions required to address a cybersecurity incident, and assessments of system vulnerabilities.
  • Departed employees – former employees of advisors and broker-dealers retained access to restricted customer information rights after termination of employment.

Many of the observations noted above are common gaps to data security policies and procedures, particularly for small and medium-sized enterprises in any industry. For advisors and broker-dealers, the consequences of compliance lapses could result in data breaches, enhanced scrutiny by the SEC and OCIE, and reputational harm. Thus, as OCIE suggests following its recent examinations, advisors and broker-dealers should review and update, as needed, their written policies and procedures to mitigate the issues identified by OCIE staff.