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!
Massachusetts' Revised Personal Information Security Regulation (201 CMR 17.00)
Massachusetts' Office of Consumer Affairs & Business Regulation (OCABR) recently released a revised version of its "Standards for the Protection of Personal Information of Residents of the Commonwealth" (the "Regulation"). This August 2009 version modifies the February 2009 version of the Regulation. The press release and the FAQs released by OCABR appear updated to address some of the changes in the regulations.
UPDATE (082509): On his blog, Uncommon Sense Security, Jack Daniel shares his insight from the security perspective.
For ease of reference, ILG has taken the time to create a REDLINED VERSION showing the revisions in the new Regulation. The redlines indicate changes between the February 2009 version and the August 2009 version of the Regulation. Also included below is a summary of some of the more significant changes.
- Owns and Licenses v. Stores and Maintains Personal Information.
In the prior version of the regulation, companies that "owned, licensed, stored or maintained" personal information were subject to the Regulation. Now, only companies that own or license personal information are within the scope of the Regulation. The Regulation defines "owns or licenses" as follows:
Owns or licenses, receives, maintains, processes, or otherwise has access to personal information in connection with the provision of goods or services or in connection with employment.
As such, it appears that organizations that handle personal information when not in connection with the provision of good or services, or in connection with employment, would not be subject to the Regulation. This could perhaps encompass a person or company holding personal information for purely personal reasons.
- Written Information Security Program.
The new Regulation builds in some flexibility with respect to the requirement of a written security program. Now such program must contain:
administrative, technical, and physical safeguards that are appropriate to (a) the size, scope and type of business of the person obligated to safeguard the personal information under such comprehensive information security program; (b) the amount of resources available to such person; (c) the amount of stored data; and (d) the need for security and confidentiality of both consumer and employee information.
This appears to be designed to provide leeway for smaller organizations and other companies that do not pose much risk with respect to personal information. In fact, this is confirmed to some degree by the FAQs released by OCABR, which indicate:
the most recent regulation issued in August of 2009 makes clear that the rule adopts a risk-based approach to information security, consistent with both the enabling legislation and applicable federal law, especially the FTC's Safeguards Rule. A risk-based approach is one that directs a business to establish a written security program that takes into account the particular business' size, scope of business, amount of resources, nature and quantity of data collected or stored, and the need for security. It differs from an approach that mandates every component of a program and requires its adoption regardless of size and the nature of the business and the amount of information that requires security. This clarification of the risk based approach is especially important to those small businesses that do not handle or store large amounts of personal information.
- "Technically Feasible."
In the prior version of the Regulation, companies were required to encrypt files containing personal information transmitted across public networks or wirelessly only if it was technically feasible to do so. The new Regulation expands the concept of "technically feasible" to apply to all of the items listed in the "Computer System Security Requirements" subsection of the Regulation.
What this means in practice is that none of those specific controls of this section of the Regulation are now required unless it is "technically feasible" to implement them. Again, this appears to be an attempt to provide some flexibility for small companies. However, it also may provide cover for larger businesses that have complex IT environments.
The key issue here is the meaning of "technically feasible." One problem with the term for organizations subject to the Regulation is that it focuses on technical aspects rather than "cost feasibility" or "business feasibility." One could argue that practically anything is technically feasible if you don't take price into account or potential disruptions or problems with business practices and activities.
While the term is not defined in the Regulation for some reason, the FAQs define "technically feasible" as follows:
“Technically feasible” means that if there is a reasonable means through technology to accomplish a required result, then that reasonable means must be used.
This definition does not necessarily help because it is not clear what is meant by "reasonable means" in this context, and whether resource and business constraints factor into the analysis. Significantly, unlike in the context of a written infosec program, the Regulation does not explicitly reference the "resources available" to the company as one of the factors for determining whether something is "technically feasible." ISC believes that this concept is vague and the OCABR would have been better served using an approach similar to the one used for the WISP.
- New Service Provider Definition and Obligations.
The Regulation now includes a specific definition of "service provider":
Service provider, any person that receives, maintains, processes, or otherwise is permitted access to personal information through its provision of services directly to a person that is subject to this regulation; provided, however, that "Service provider" shall not include the U.S. Postal Service.
It appears that by using the word "directly" they wanted to eliminate companies that might incidentally receive personal information. However, based on the language of the statute these companies would still be directly subject to the regulation if they "own or license" personal information. As such, service providers may have both contractual obligations and direct obligations to comply with the Regulation.
Significantly the duties with respect to service providers have also been narrowed. Previously the Regulation imposed an obligation to take reasonable steps to "verify" that service providers could implement the required security. The word "verify" has been dropped. Added to the new Regulation is an obligation to have a contract in place with service providers requiring them to implement and maintain appropriate security measures around personal information. This requirement only applies to contracts entered into after March 1, 2010 (it does not indicate what is to happen with contracts that renew after March 1, 2010). Notably, the old version of the Regulation required companies to "ensure" that their service providers complied with the Regulation.
- Deleted Specific WISP Requirments.
The old version of the Regulation required the WISP to impose a "minimum necessary use" limitation with respect to personal information, and a mandated "personal information" inventory be performed. Those specific obligations have been deleted (however, they could still be required in general with respect to a WISP).
In all, by attempting to impose a "risk-based" framework, the Regulation appears to provide more flexibility and leeway. Nonetheless, the Regulation is still vague in some areas and companies of all sizes and complexities will have to analyze whether and how the law applies to their organization. The Regulation will also complicate relationships with service providers, who are likely to have to go through a more rigorous "due diligence" process and also enter into more stringent contracts imposing security obligations.
There are additional changes that you can observe in the redlined version. If you have any additional input on the potential impact of these changes, please provide a comment so we can further discuss (and I can update this post as necessary).
Johnson, et al. v Microsoft: Court Docs on Motion Ruling IP Address Does Not Equal PII
For those interested in digging deeper into the recent ruling in the UNITED STATES DISTRICT COURT FOR THE WESTERN DISTRICT OF WASHINGTON, SEATTLE DIVISION that IP addresses do not constitute "personally identifiable information," I have complied all of the relevant pleadings, motions, and response/reply/surreply briefs for your viewing pleasure....
- 2nd Amended Complaint
- Microsoft's Motion for Summary Judgment
- Plaintiffs' response to MSJ
- Microsoft's reply to plaintiffs' response
- Plaintiffs' surreply to Mircosoft's reply
- Court Order Granting MSJ (holding IP address is not PII)
For some more interesting reading on this issue, check out Truste's Amicus Brief in the Klimas case. How about some insightful comments in this blog to save me some reading time!
By the way, how to advise clients doing business in both the United States (where at least some courts dont consider IP as PII) and EU (where IP is considerd PII)?


