IL Appellate Court: No Duty Exists to Safeguard SSNs for Purposes of a Negligence Claim
In one of InfoLawGroup’s first blogposts to kick off 2011 we surveyed a handful of privacy lawsuits that are in the process of potentially altering the privacy and security legal risk landscape. ILG recently discovered another case (through an excellent service we use called Nymity), one of the first that we are aware of in the United States, that dives deep into the issue of whether a common law duty exists to safeguard personal information. In Cooney, et. al v. Chicago Public Schools, et. al¸ an Illinois appellate court upheld a lower court’s dismissal of a lawsuit involving the unauthorized disclosure of sensitive personal information, including names, addresses, social security numbers, marital status, dates of birth, medical and dental insurers and health insurance plan information. While we have seen plenty of courts dismissing data breach cases on motion to dismiss, most of those have focused on the lack of alleged damages. In Cooney, however, the court actually rendered a decision on whether any common law duty exists to safeguard personal information for purposes of a negligence claim. The Cooney court's ultimate answer was that no such duty exists. In this blogpost we take a closer look at the court’s rationale for dismissing the plaintiffs’ negligence claim, as well as the other interesting holdings of the court.
Background
In Cooney, the main defendants were the Chicago Public Schools and its Board (“CPS”), and a printing and mailing company known as All Printing & Graphics, Inc. (“All Printing”). All Printing was retained by CPD to print, package and mail a COBRA Open Enrollment List to approximately 1,750 former CPS employees. Unfortunately each of the 1750 employees was sent a list containing the personal information of all the other 1749 former employees, including names, addresses, social security numbers, marital status, medical and dental insurers and health insurance plan information. CPS notified the employees of the breach and offered one year of free credit protection insurance. Several of the employees filed individual and class action lawsuits, which were consolidated at the trial court level. The complaints alleged several causes of action (including common law negligence), which were all dismissed by the lower court. The appellate court set out to determine whether the dismissal was in error, and ultimately held that it was proper. One of the appellate judges, however, dissented. The following is a summary of the court’s opinion for the main causes of action alleged.
Common Law Negligence
In addressing the plaintiffs’ common law negligence claim, the court laid out the traditional elements necessary to allege negligence, and first set out to determine whether CPH was under a duty to safeguard the plaintiffs’ personal information.
First, under Illinois law, a violation of a statue designed to protect human life and property may be used as prima facie evidence of negligence (e.g. it can be used to allege a “duty” for purposes of negligence, and a violation of that duty). In this case, the plaintiffs argued that HIPAA and Illinois' breach notice law (815 ILCS 530) created a duty for negligence purposes. The court, however, rejected both arguments.
On HIPAA the court indicated that 45 CFR § 160.103 excluded “employment records held by a covered entity in its role as employer” from HIPAA coverage. According to the reasoning of the majority, since the CPH "held" the plantiffs’ health insurance elections in its role as employer, the disclosure of such records was not a HIPAA violation. Notably, however, the dissenting judge disagreed with this assessment. He indicated that the exception only applied to employment records actually “held” by the covered entity, as opposed to those disclosed (and therefore no longer held by CPH) to unauthorized third parties. In the dissent's view, then, the plaintiffs did properly plead a negligence claim based on allegations that HIPAA had been violated. If this is appealed to the Illinois Supreme Court this will likely be a key issue in the case. One important item to note here is that it appears that both the majority and dissent agreed that a data security statute can be used to establish a duty for negligence purposes even if the underlying statute does not itself provide a private right of action.
The plaintiffs also claimed that Illinois' breach notice law was violated because a “breach of the security of the system data” had occurred as defined in that law. The court rejected this argument as well, noting that Illinois' breach notice law already provided a specific and exclusive remedy for a breach of security of the system data: notice to the data subjects (which was properly provided in this case).
Second, the court considered whether a "new" duty to safeguard personal information existed in general for negligence purposes (i.e. without having to rely on a specific statute). On this issue, the court rejected the plaintiffs’ argument that the sensitivity of personal information such as birth dates and social security numbers justified the recognition of a duty. Notably the court did not consider any “foreseeability” arguments or analyze whether a duty should have existed based on something like Judge Learned Hand's risk formula. Based on the foregoing, the court found that the lack of an alleged duty justified dismissal of the common law negligence claim against both CPH and All Printing.
IL Consumer Fraud and Deceptive Business Practices Act
Section 2QQ of Illinois Consumer Fraud and Deceptive Business Practices Act (815 ILCS 505/1, et. seq.) prohibits a “person” from publicly posting or displaying an individual’s social security number. In this case the court held the CPH Board was a “body politic” and therefore not a “person” under the Act. In addition, while All Printing does qualify as a “person” covered under the Act, the plaintiffs failed to allege actual damages as required under the Act. Relying on the large body of case law on the damages issue, the Court specifically rejected plaintiffs’ contention that increased risk of identity theft, and costs to pay for credit monitoring, constitute actual damages.
Traditional Privacy Torts
The plaintiffs also alleged “intrusion upon seclusion” and “public disclosure of private facts.” In considering these theories the court indicated that both torts require disclosure of “private” matters or facts. The court held that the privacy element was not satisfied because no law existed in Illinois defining social security numbers as private information. In addition, names and dates of birth did not qualify as private facts because they are matters of public records. Finally, while Illinois law had defined social security numbers as “personal information,” the court held that personal information does not equate to “private” information. Private information, in the court’s view, means private facts that are facially embarrassing and highly offensive, if disclosed. As such, the court ruled that these claims were properly dismissed by the trial court.
Other Miscellaneous Causes of Action
The appellate court, sometimes in a very cursory fashion, affirmed the dismissal of other causes of action the plaintiffs attempted to allege, including:
- Negligent infliction of emotional distress (dismissed because traditional negligence elements had not been alleged, as required)
- Breach of fiduciary duty (dismissed because no authority found to indicate that a fiduciary duty exists based on the plaintiffs providing their personal information “in confidence” to the CPS)
- HIPAA violations (dismissed because the plaintiffs did not allege that they had been deprived of a constitutionally protected right caused by a “municipal policy”; and because HIPAA does not provide a private right of action against non-state actors like All Printing)
- 4th Amendment privacy violation (dismissed because the plaintiffs failed to properly raise the issue before the trial court)
Conclusion
This case is very interesting because it is one of the first (if not the first) to squarely rule on whether a common law duty exists to safeguard personal data. It will be very interesting to see if this case is appealed to the Illinois Supreme Court. Based on the strong dissent it appears as if the majority opinion may be at risk for an overturn. What is somewhat disappointing, however, is the lack of deep analysis by the appellate court (especially on the issue of whether a common law negligence duty existed). It may be that key issues were not raised or briefed by the plaintiffs, but it would have been nice to see a full-throated analysis of "law school 101" issues like foreseeability, reasonableness and risk reduction. InfoLawGroup will try to get a hold of the appellate briefs and other underlying documents to see if they provide additional insight as to how the court reached its decisions (and we will post them here once we have them). We look forward to your thoughts, comments and questions on this case.
Code or Clear? Encryption Requirements (Part 2)
In the last post, I talked about the role of encryption in fashioning a “reasonable” security plan for sensitive personal information and other protected data routinely collected, stored, and used by an enterprise. But lawmakers and regulators are getting more specific about using encryption and managing data that is risky from an ID-theft perspective. Here are some leading examples of this trend.
State Security and Breach Notification Laws
Since California adopted SB 1386, which went into effect in 2003, nearly all US states have enacted security breach notice laws that require notice to affected individuals, and in some cases to public authorities, when a party has reason to believe that the security of protected categories of personal data has been compromised. The protected categories are typically SSN (Social Security Number), driver’s license, financial account or payment card details (usually only if the password or access code is also compromised), and, increasingly, medical data not covered by federal HIPAA privacy protections.
All of these laws make an exemption from the notice obligation if the data were encrypted (some add that this is true only if there is no reason to believe that the decryption key was also compromised). The laws, and regulations adopted under the laws, typically do not specify the level or kind of encryption. For example, California’s Office of Privacy Protection published guidance specifically on the subject of “Recommended Practices on Protecting the Confidentiality of Social Security Numbers” in April 2007, which has only this to say about encryption, on page 11:
“Protect records containing SSNs, including back-ups, during storage by encrypting the numbers in electronic records or storing records in other media in locked cabinets.”
Partly as a consequence of these security and breach notice laws, organizations should limit their use and storage of these categories of personal data to the extent they are really necessary for business operations. Storage on servers or on archived media, and transmission over internal networks and VPN connections, may or may not be sufficiently secure without encryption, depending on the company’s risk assessment and IT security practices. Organizations should encrypt such data when it is resident on laptops or other portable devices and when it is in transit over the public Internet.
Massachusetts and Nevada have recently adopted stricter and more specific rules, however, that may become a model for other states. These increase the regulatory pressure for encrypting protected categories of personal data.
Massachusetts
The Massachusetts Personal Information Security Regulation (201 CMR 17.00) is now scheduled to take effect on March 1, 2010. The Regulation was promulgated by the Office of Consumer Affairs and Business Regulation (OCABR) under the authority of the Massachusetts personal information security law.
The Regulation will require all parties that “own or license” any of the protected categories of personal data concerning Massachusetts residents to encrypt the data in laptops or other portable devices, as well as in wireless transmissions and in transmission over public networks.
Note that the Regulation does not limit its coverage of financial account data to cases where the access code or PIN is compromised, as do most security and breach notice laws. The Regulation extends to any nonpublic financial account or payment card data, as well as to SSNs and driver’s license numbers. The Regulation does not cover medical information, however.
The Regulation mandates a number of “Computer System Security Requirements” (201 CMR sec. 17.04) for businesses that handle the protected categories of personal data. These expressly include the following:
“(3) Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly . . .
(5) Encryption of all personal information stored on laptops or other portable devices . . .”
The level and type of encryption are not specified.
Nevada
Nevada recently amended its personal information security law, which already required “reasonable” security measures as well as breach notice (Nevada Rev. Stats. secs. 603A.010 et seq.). The amendments take effect on January 1, 2010.
The law covers SSNs, driver’s license numbers, and payment card or financial account data in combination with an access code or PIN. Medical information is not covered.
Under the amended law, businesses that accept payment cards (credit cards and debit cards) must comply with the Payment Card Industry Digital Security Standard (PCI DSS). In addition, a party handling any of the protected categories of information must encrypt the data if it transfers the data electronically “outside of the secure system of the data collector” or if the data is stored on a device (laptop, USB drive, etc.) that is moved “beyond the logical or physical controls of the data collector or its data storage contractor.”
“Encryption” is defined in the amendments with reference to “established standards,” specifically including FIPS and mentioning the need for standards-based key management as well as encryption protocols:
‘Encryption’ means the protection of data in electronic or optical form, in storage or in transit, using:
(1) An encryption technology that has been adopted by an established standards setting body, including, but not limited to, the Federal Information Processing Standards issued by the National Institute of Standards and Technology, which renders such data indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data; and
(2) Appropriate management and safeguards of cryptographic keys to protect the integrity of the encryption using guidelines promulgated by an established standards setting body, including, but not limited to, the National Institute of Standards and Technology.”
Thus, while the law itself does not specify the form of encryption, it puts the burden on the user to choose an appropriate and standards-based method.
HITECH
Title XIII of ARRA, the federal economic recovery legislation adopted early in 2009, is labeled the Health Information Technology for Economic and Clinical Health Act (HITECH). It amends the HIPAA medical privacy provisions by adding a federal security breach notice requirement for nonpublic, personally identifiable health information. While HIPAA applies only to certain covered entities (healthcare providers and insurance companies and clearinghouses), HITECH also applies to “business associates” that provide services to those entities. HITECH reaches as well any employers that are covered by HIPAA because, for example, they operate company clinics or manage their own health plans.
HITECH requires notice to affected individuals when there has been a security breach exposing personally identifiable health data. HIPAA already lists 18 identifiers (names, addresses, SSNs, health plan ID numbers, etc.) that must be removed to establish that health records have been “de-identified.” Where compromised records have not been fully de-identified by removing these data fields, HITECH sec. 132400 also recognizes that the information may not be personally identifiable if it is effectively encrypted:
“(b) Implementation specifications: Requirements for de-identification of protected health information. A covered entity may determine that health information is not individually identifiable health information only if:
(1) A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable:
(i) Applying such principles and methods, determines that the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual who is a subject of the information; and (ii) Documents the methods and results of the analysis that justify such determination; . . . .”
Thus, HITECH does not specify a particular form of encryption but leaves it to IT security experts to decide whether the data are effectively unidentifiable in the hands of an unauthorized user. Note that the statute requires covered entities to maintain documentation of this professional analysis, and that the analysis must be based on “generally accepted” principles and methods – which means that professional opinions are likely to refer to published specifications and industry standards.
Red Flags
The 2007 Identity Theft Red Flags Rule (promulgated under the 2003 FACTA amendments to the federal Fair Credit Reporting Act) went into effect in November 2008, although the FTC suspended enforcement until November 1, 2009. (Similar rules were issued by the federal financial regulatory agencies, for the institutions they supervise.) The Rule requires covered entities to develop and implement written policies to prevent identity theft, including recognition of warning signs or “red flags” of suspected ID theft.
The Rule applies not only to traditional financial institutions but to “creditors,” defined as companies that “regularly defer payment for goods or services,” whether or not charging interest or finance charges, and therefore store personal information about individual debtors. Some employers, for example, sell goods or services to employees on deferred payment terms and may be treated as covered entities for that reason. (However, the Red Flag FAQs written by FTC staff take the view that an employer is not a covered entity simply because it sponsors a 401k or other qualified retirement plan that allows participants to borrow from their retirement funds.)
For covered entities, the mandatory policy to prevent ID theft must identify signs of possible security breaches involving certain data, as well as appropriate responses to those alerts. The covered data are SSNs and tax identification numbers, healthcare IDs, financial account and credit/debit card details, personally identifiable medical information, and identifying data from consumer reports (which are often used for employee background checks as well as for credit applications).
The Rule itself does not mandate encryption measures. However, most covered entities will necessarily address encryption in their written anti-ID theft policies. Their “red flags” should also include an alert if there is evidence that encryption keys have been misused, stolen, or hacked.
