Celebrating Data Privacy from A to Z

In honor of Data Privacy Day and its spirit of education, I thought it might be appropriate (and fun) to celebrate some (but certainly not all) of the A, B, Cs of Data Privacy.  Would love to see your contributions, too!

A is for Advance Encryption Standard or AES, approved by NIST.  Are you encrypting transmissions of sensitive data and portable storage devices?  See more below.

B is for Breach Notification Laws, including the 45 state laws, District of Columbia, Puerto Rico, Virgin Islands, HITECH Act, and international regulations.  (Also Behavioral Advertising.)

C is for . . . what to Choose? -- Contracts? Cloud Computing?  How about  California - the first state to enact a breach notification law, California Civil Code sections 1798.29, 1798.82 et seq. (SB 1386), and the first state Office of Privacy Protection

D is for Data Protection Authorities in the European Union

E is for the EU Data Protection Directive.  Oh, and Encryption, of course.  See above and below.

F is for Financial Institutions, regulated by (wait for it . . . after the jump . . .)

 

G is for the Gramm-Leach-Bliley Act and the new model privacy notice form

H is for HIPAA and the HITECH Act, which impose privacy and data security obligations on health care providers and their business associates

I is for the International Association of Privacy Professionals, IAPP

J is for John and Jane Doe, anonymity - is there any such thing?

K is for Kearney v. Salomon Smith Barney Inc, California Supreme Court (2006), requiring two-party consent for recording or eavesdropping on telephone conversations, even if only one of the participants is in a two-party consent state

L is for Legislation -- will there be a federal breach notification law in 2010 (other than HITECH) that will preempt the state data breach notification laws?

M is for Massachusetts and its new data security regulations, 201 CMR 17.00 et seq., effective March 1, 2010

N is for Nevada and its new encryption law, SB 227, effective January 1, 2010

O is for Outsourcing, and the need for due diligence and contractual provisions to safeguard personally identifiable information (and other kinds of sensitive information) shared with third parties.  See, e.g., Massachusetts 201 CMR 17.00 et seq. and California Civil Code section 1798.81.5.  Oh yes, and don't forget the Cloud in this context - are you putting data in the cloud?  Have you done your due diligence?

P is Personally Identifiable Information or PII -- what IS it anyway?  Depends where you live.

Q is for Questions, Q & A, and the Q in FAQ:  ASK QUESTIONS early and often about how your organization will use personal information of customers and/or employees in its business operations.

R is for Radio Frequency Identification or RFID and locational privacy issues - should organizations be able to use RFID to track customers/products?

S is for SO many things -- Social Networking, Social Security numbers, Surveillance, Spam, . . .

T is for Telemarketing, Text Messages, and the TCPA -- do you have opt-in for your mobile marketing campaigns?

U is for the UK ICO, which will order companies to pay up to £500,000 as a penalty for serious breaches of the Data Protection Act

V is for the Video Privacy Protection Act or VPPA, the basis for a recent privacy class action filed against Netflix in the Northern District of California

W is for Website Privacy Policies, required under California law for any website that collects information from California residents, Cal. Bus & Prof. Code section 22575 et seq.  When was the last time you updated yours?  Is it accurate?

X is for XXXXX -- Redact the information!

Y is for Yes, You can implement a successful data protection program in Your organization

Z is for Zango, the adware distributor that settled FTC charges that it used unfair and deceptive methods (FTC Act Section 5)  to download adware and block consumer efforts to remove it

Happy Data Privacy Day!

 

The New Health Care Breach Notification Landscape -- HHS Rules

On February 17, 2009, Congress signed into law the Health Information Technology for Economic and Clinical Health or “HITECH” Act (“HITECH” or the “Act”) as part of the American Recovery and Reinvestment Act. The HITECH Act requires entities covered by the Health Insurance Portability and Accountability Act (“HIPAA”) to provide notification to affected individuals and to the Secretary of Health and Human Services (“HHS”) following the discovery of a breach of unsecured protected health information. HITECH also requires business associates of HIPAA-covered entities to notify the covered entity in the event of the breach.  The Act required HHS to issue interim final regulations with respect to the new breach notification requirements. On August 24, 2009, the HHS interim final regulations were published in the Federal Register.  This post addresses some of the requirements of the HHS rules -- it does not address the FTC's rules for personal health records.

The HHS Rule was effective, and compliance was required, for breaches occurring on or after September 23, 2009. However, HHS will not impose sanctions for failure to provide the required notification for breaches discovered before 180 calendar days from August 24, 2009 (publication in the Federal Register).

When Is Notification Required?

Organizations subject to the HHS Rule can follow three steps to determine whether there has been a breach requiring notification:

1. Has there been an impermissible use or disclosure of unsecured PHI under the Privacy Rule?

2. Has the impermissible use or disclosure compromised the security or privacy of the PHI? That is to say, is there a significant risk of financial, reputational, or other harm to the individual?

3. Does the incident fall under one of three exceptions?

Is There a Breach?

The Rule defines a breach as the acquisition, access, use, or disclosure of PHI in a manner not permitted under the Privacy Rule which compromises the security or privacy of such information.

Is There a Significant Risk of Financial, Reputational, or Other Harm to the Individual?

Importantly, the HHS Rule incorporates a harm threshold into the definition of breach by requiring that the incident “[c]ompromise[] the security or privacy of” PHI. HHS interprets that language to mean that the incident “poses a significant risk of financial, reputational, or other harm to the individual.” Thus, covered entities and business associates facing a potential breach incident must perform a risk assessment to determine whether the breach triggers a notification obligation.

Risk assessments must be fact-specific inquiries. A risk assessment performed pursuant to the Rule should determine who impermissibly used the information and/or to whom the information was impermissibly disclosed, and should address the type and amount of PHI involved in the impermissible use or disclosure.

Covered entities and business associates bear the burden of proof of demonstrating that no breach occurred because the impermissible use or disclosure did not pose a significant risk of harm to the individual.

What Are the Three Exceptions?

There are three exceptions to the HHS Breach Rule. They are:

1. Certain unintentional acquisition, access, or use by workforce members or persons acting under the authority [i.e., on behalf] of a covered entity or business associate, if made in good faith, within the course and scope of employment or other professional relationship, and that does not result in further use or disclosure in violation of the Privacy Rule;

2. Certain inadvertent disclosures among similarly situated persons authorized to access PHI at the same covered entity, business associate, or organized health care arrangement, if the information is not further used or disclosed without authorization; or

3. Where the covered entity or business associate has a good faith belief that the unauthorized person to whom the disclosure of PHI was made would not reasonably have been able to retain the information.

Notice to Individuals

If notice is required, covered entities must provide notice to affected individuals in written form by first-class mail at the last known address of the individual without unreasonable delay and in no case later than 60 days following the discovery of a breach. Notice may be in the form of electronic mail, provided the individual agrees to receive electronic notice and such agreement has not been withdrawn.

If the covered entity lacks sufficient contact information for some or all of the individuals, or if some notices are returned as undeliverable, the covered entity must provide substitute notice as soon as reasonably possible after it becomes aware that it has insufficient or out-of-date contact information for one or more affected individuals.  Substitute notice must be reasonably calculated to reach the affected individuals. If there are fewer than 10 affected individuals, the covered entity can provide substitute notice through an alternative form of written notice, by telephone, or other means. If 10 or more individuals are affected, the covered entity must provide substitute notice by either (a) conspicuous posting for a period of 90 days on the home page of its website; or (b) conspicuous notice in major print or broadcast media in the geographic areas where the individuals affected by the breach likely reside. This notice must include a toll-free phone number active for 90 days where the individual can learn whether unsecured PHI may be included in the breach.

Content of the Notice

Notices must be in plain language. The notice must include the following:

1. a brief description of what happened, including the date of breach and date of discovery of the breach, if known;

2. a description of the types of unsecured PHI that were involved in the breach;

3. any steps the individuals should take to protect themselves from potential harm resulting from the breach;

4. a brief description of what the entity involved is doing to investigate the breach, to mitigate harm to individuals, and to protect against any further breaches; and

5. Contact procedures for individuals to ask questions or learn additional information, including a toll-free telephone number, an e-mail address, web site, or postal address.
Notices must comply with any other applicable laws.

Notice to the Secretary of HHS

Covered entities must notify the Secretary of HHS immediately following the discovery of a breach of unsecured PHI involving 500 or more individuals. HHS must post a list identifying each such covered entity on its website.  For breaches involving less than 500 individuals, the covered entity must maintain a log and annually submit the log to the Secretary documenting the breaches occurring during the year involved. The log must be provided to HHS no later than 60 days after the end of each calendar year. These logs must be kept for six years (like other records subject to HIPAA records retention requirements). Covered entities must make the records available to the Secretary upon request.

Notification of the Media

Covered entities must notify prominent media outlets serving a State or jurisdiction without unreasonable delay and in no case later than 60 calendar days after discovery of the breach, if unsecured PHI of more than 500 residents of such State or jurisdiction is the subject of a breach. This notice should include the same information provided in notices to individuals. This can be done by a press release. “Jurisdiction” is defined as a geographic area smaller than a state, such as a county, city, or town.

Business Associate Notice Obligations

Following discovery of a breach of unsecured PHI, a business associate must notify the covered entity of the breach without unreasonable delay and in no case later than 60 days following the discovery of a breach.  As with covered entities, the breach is discovered as of first day on which it is known or, by exercising reasonable diligence, would have been known. The business associate is deemed to have knowledge if the breach is known, or by exercising reasonable diligence would have been known, to any person, other than the person committing the breach, who is an employee, officer or other agent of the business associate, determined in accordance with the federal common law of agency. If the business associate is an agent, then the business associate’s discovery of the breach is imputed to the covered entity and the covered entity must provide notifications based on the time of the business associate’s discovery of the breach. However, if the business associate is an independent contractor, then the covered entity must provide notification based on the time the business associate notifies the covered entity. For this reason, it is important that covered entities and business associates address timing of notification in their contracts.

To the extent possible, the business associate must provide the identity of each individual whose unsecured PHI has been or is reasonably believed to have been breached. In addition, the business associate must provide the covered entity with any other available information that the covered entity is required to include in notification to the individual, either at the time it provides notice to the covered entity of the breach, or promptly thereafter as information becomes available.
Of course, covered entities and business associates can still set forth specific obligations in contracts, provided that all required notifications under the Rule are provided and that the other requirements of the interim final rule are met. Indeed, HHS encourages the parties to ensure that individuals do not receive notifications from both the covered entity and the business associate.

Law Enforcement Delay

Like some state breach notification laws, the HHS Rule requires covered entities to temporarily delay notification if instructed to do so by a law enforcement official. Such a request tolls the time within which notification is required.

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.
 

Legal Implications of Cloud Computing -- Part Two (Privacy and the Cloud)

Last month we posted some basics on cloud computing designed to provide some context and identify the legal issues.  What is the cloud?  Why is everyone in the tech community talking about it?  Why do we as lawyers even care?  Dave provided a few things for our readers to think about -- privacy, security, e-discovery. 

Now, let's dig a little deeper. 

I am going to start with privacy and cross-border data transfers.  Is there privacy in the cloud?  What are the privacy laws to keep in mind?  What are an organization's compliance obligations?   As with so many issues in the privacy space, the answer begins with one key principle -- location, location, location.  For those of you who prefer to listen, check out my recent webinar on International Regulatory Issues in the Cloud, or you can download the slides (PPTX). For everyone else, read on after the jump.

In the world of the cloud, location appears to be irrelevant.  In the cloud, data effortlessly flows around the globe, ignoring boundaries and time zones, and magically appears on demand.  Not surprisingly, the existing legal structure is far from prepared for the reality of existing technology.  Every jurisdiction has its own laws, and its own compliance requirements.  As that data instantaneously circumnavigates the globe, it may already be too late to comply with privacy laws in every jurisdiction.

You have undoubtedly heard that the laws of this country are like a patchwork quilt.  They have popped up in certain sectors (financial, health) and with respect to certain types of sensitive information (e.g., kids' data).  There are federal laws like Gramm-Leach-Bliley (applicable to financial institutions), HIPAA (applicable to health care providers and others dealing with health information and related entities), COPPA (applicable to data of children under 13 collected online), and the USA Patriot Act (may be applicable to foreign companies that work with cloud providers that allow data to reside in or flow through the US).  In addition, we have a panoply of state laws requiring notification in the event of a breach of sensitive information and, in some cases, requiring the implementation of safeguards to protect sensitive information and/or secure disposal of such information.

By contrast, the European Union has a comprehensive privacy framework, the EU Data Protection Directive.  Each member state has its own unique law implementing the Directive.  The most notable thing about the EU Directive and member state laws for purposes of cloud computing is this -- in the absence of specific compliance mechanisms, the EU prohibits (yes, you read correctly, prohibits) the transfer of personal information of EU residents out of the EU to the US and the vast majority of countries around the world.

What does this mean for cloud computing?  If you want to put data in the cloud that includes personal information of EU residents (and that might be something as simple as an email address or employment information), and the data will flow from the EU to almost anywhere in the world, you cannot simple throw the data in the cloud and hope for the best.  You need to have, at a minimum, one or more of the following:

  • International Safe Harbor Certification (which allows data transfer from the EU to the US, but not from the EU to other countries);
  • model contracts (which allow data transfer from the EU to non-US countries, but do not always work well with multi-tiered vendor relationships); or
  • Binding Corporate Rules (which are designed for a multinational company and therefore may not function well for cloud provider relationships).

So what, what does this tell us?  All of the stakeholders within an organization should be part of the cloud discussion and due diligence -- IT, legal, information security, and all of the relevant business groups.  And those stakeholders, in investigating a potential cloud relationship and in negotiating the terms of a relationship with a cloud provider, should consider and pose the following questions internally and to the vendor long before any contract is signed: 

  • What kind of data will be in the cloud?
  • Where do the data subjects reside?
  • Where will the data be stored? 
  • Where are the servers? 
  • Will the data be transferred to other locations and, if so, when and where?
  • Can certain types of data be restricted to particular geographic areas?
  • What is our compliance plan for cross-border data transfers?

Is that the end of the inquiry?  No, it is just the tip of the iceberg, but it is a good start.