A policy of this magnitude should be given at least a 90 day public comment period. However, public discussion has been limited and the discussion period is almost over. Therefore, we request that the public comment period be extended for at least 30 days to facilitate more robust public discussion. We also request that subsequent public comment periods on this topic extend for at least 90 days.

We are concerned that the NSTIC is silent on an implementation timeline and other significant details currently missing from the draft. We request clarification on the agency’s proposed timeline and process. We also request an opportunity to convene an in-person discussion with an appropriate White House or DHS official to discuss this important matter and engage in further public discussion.

We look forward to supporting your efforts to engage a robust public discussion on the NSTIC.

Avoid a Legal 500 Error. Debug your privacy policy.

Legal Programming

By Aaron Titus

I’m an awesome programmer. The only thing keeping me from Python, PHP, or Ruby coding awesomeness is knowledge… and skill… and training… and, um practice. OK, I may not be a Ruby all-star, but I could be if I wanted to. Likewise, you can do anything for yourself that an attorney can do for you, including writing legal documents. Lawyers just happen to have knowledge, skill, and training. And if I wanted an iPhone app, I’d talk to a programmer. If I wanted legal documents, I’d talk to a lawyer.

In fact, lawyers are programmers. Writing legal documents—like privacy policies—is just like writing code.

Imagine that your boss tells you, “I need a widget. I’m sure other people in the open source community have done similar things. Just go grab some code and slap it together by the end of the day.” Of course, that’s crazy. You can’t just slap code together. In what language is the code written? Will it play well with existing code? How complete is the API? What are the requirements? What about security? What about debugging?

Yet this is exactly how we treat privacy policies. We go grab some “open source” or “boilerplate” privacy policy, slap it together with a boilerplate Terms of Service, and think we’re good to go. But unlike poorly-written code which will cause an error as soon as it is compiled, you won’t know whether you’ve created a Legal 500 error for months or years—long after it’s too late to fix.

Privacy Policy Principles

The purposes of a privacy policy are to: 1. Help inform and train your employees about your privacy practices, 2. Inform your customers about your privacy practices, and 3. Avoid liability and FTC action. As I explained previously, adhering to the following principles will allow you to accomplish all three goals:

• Be Honest. Your mamma was right: Honesty is the best (privacy) policy.
  • Don’t Over-Promise. Statements like “privacy is our top priority” may be enforced by the FTC as a privacy promise. Don’t box yourself into a corner.
  • Don’t Under-Promise. Under-promising can violate regulations and more importantly, scare off customers.
  • Tell the Whole Truth. Failure to talk about less-desirable privacy practices may be a misleading business practice.
• Be Complete and Conspicuous.
• Adapt to Changing Business Practices. A privacy policy which was accurate six months ago may not be today.
• Get it Right the First Time. Allowing yourself room to change will save headaches long-term, as material changes to privacy policies require additional consent.
• If you Say it, Do it. Generally no magic words are required in privacy policies. The best approach to avoid liability is to stick to your policy.
• It’s Your Business. As an executive, it’s your responsibility to make sure that your privacy policy is accurate and complete.

Custom Programming Your Privacy Policy

Nobody, especially the legislature, has solved your problems for you. If you create an innovative product or service, then it will raise new questions of law, ethics, and privacy which have never been asked or answered. You can’t expect that somebody else’s recycled privacy policy will meet your needs, any more than you can expect that recycling old code will yield innovation. Imagine for a moment that you have just developed an iPhone app. The app communicates with a smart scale using Bluetooth technology, then interfaces with the Google Health API to transfer a user’s weight history to the Weight Watchers website, then optionally posts the summarized results of the user’s weight loss to his Facebook page and Twitter account. Which of the following is true:

1. You can adopt HIPPA as your privacy policy. HIPPA privacy rules apply.
2. The FTC is interested in your privacy policy and practices.
3. You can later use the weight & contact information to market your next iPhone app, “Smart Dieter.”

The answers may surprise you:

1. False on both accounts: 1. HIPPA is not a privacy policy. Nobody, especially Congress has written your privacy policy for you. 2. Your customers are not protected by HIPPA regulations, because they probably don’t apply to you.
2. True. The FTC is always interested in your privacy policies and practices, and even passing assurances of privacy like “Privacy is our Number 1 Priority” may be enforced as a privacy promise.
3. Probably Not. Unless you have written a clear privacy policy that puts your customers on notice, you may be prohibited from reusing their personal information for any reason, even if they would have consented to such a use.

Your privacy policy must reflect your unique business processes, your unique business model, and your unique user needs. If you think that Congress (or anybody, for that matter) have answered the new questions of privacy raised by your iPhone app, then I have a bridge in Brooklyn I’d like to sell you. Even if HIPPA privacy regulations applied (which they don’t), I can guarantee that they were not written with your app in mind. Likewise, if you are doing anything truly innovative, any canned privacy will fail to meet your needs.

Boilerplate legal documents can get people and companies in trouble. Although sometimes there are magic words from a statute or regulation that should be quoted to order to protect your rights, most boilerplate is not magic—it’s lazy. Lawyers do a lot of legal debugging, because improper boilerplate language can be downright harmful. Unless you do your own legal programming to meet your individual needs, you are sure to accidentally waive a right, break the law, incur the ire of the FTC, or create a contradiction and cause a “Legal 500 Error.”

A Living Document

Because technology, business needs, and information demands constantly change, you must consistently update your privacy policy to reflect those changes. Fortunately, privacy policies are extremely flexible documents, with very few formal legal language or “magic words” requirements, so updating them is easy… if you remember to do it. CEOs often find that adapting a business plan to changing market conditions is time-consuming, and privacy policies can fall by the way side.

Before you update your privacy policy, though, keep in mind that there may be consequences to making material changes. When you revise a policy, information collected under the former policy must still be treated according to the terms of the original Privacy Policy, unless you get some sort of assent from your customers, or face the potential ire of the FTC. It is always better to get it right the first time.

Take Charge

As an executive, do these three things:

1. Read Your Privacy Policy. First, do you understand what the policy means? Second, how does the privacy policy translate to concrete business practices in each of your departments? Third, does the policy match actual practice? Fourth, what is missing from your privacy policy that a reasonable customer would want to know about? Fifth, what changes must you make to your business practices (or the privacy policy) to make them the same?
2. Regularly Update Your Privacy Policy. Many companies have internal processes to regularly review and update business plans, department objectives, security, and compliance. Make sure that your privacy policy is on your list of documents to review.
3. Do a Privacy Policy Legal Review. Avoid a “Legal 500 Error” by making sure that your privacy policy is complete and compliant.

Writing a privacy policy is a careful balance: Being realistic about what you can perform, protecting and instilling confidence in your customers, facilitating business growth and adaptation, complying with law, and above all, being honest.

Your privacy policy and security practices are the subject of federal, state and international laws, as well as FTC regulation. The FTC regulates unfair and deceptive consumer practices, and has a history of privacy policy enforcement actions. In fact, it is currently hosting a series of “Privacy Roundtable” discussions, focusing on behavioral advertising, social networking, mobile marketing, data aggregation and correlation, data brokering, cloud computing, and other now-common practices.

With increasing scrutiny on privacy policies and practices, here are six things every CEO should know about their company’s privacy policy.

Be Honest

Your mamma was right: Honesty is the best (privacy) policy. Be up front about what you do (or may do in the future) with your customer’s personal information. Many privacy policies make one of three “honesty” mistakes: 1. Over-Promising, 2. Under-Promising, 3. Omission. Each carries liability, so it is better to avoid any of the three.

Don’t over-promise. Your company may be held responsible for the representations in your privacy policy. Look out for phrases like “state-of-the-art,” “everything in our power,” or “our highest priority.” If your company really does use “state-of-the-art” technology to protect privacy, good for you. But you probably don’t, so be honest about it. While you may think that such phrases are just feel-good fluff, the FTC has brought actions against companies who fail to provide the state-of-the-art consumer protections they promised, even though they used otherwise reasonable practices.

Don’t under-promise. FTC guidelines and many state laws require that your company takes reasonable and appropriate measures on a case-by-case basis. It may be tempting to try and disclaim all duties to protect your customers, especially if you’ve had a breach. But this approach has pitfalls. First, it is impossible to disclaim all duties to your customers’ privacy. Second, you may scare away potential customers, or invite scrutiny (as Facebook well knows). Third, FTC actions have indicated that businesses cannot take a “wait-and-see” approach to consumer privacy. Instead, companies have a duty to act reasonably and detect problems before they cause loss, particularly if the they have made privacy promises to their employees or customers.

Tell the whole truth. Another temptation is to remain conveniently silent on a privacy issue you’d rather not talk about. This is also a risky strategy, because state laws (such as California, Texas, and soon-to-be Massachusetts, to name a few) impose specific disclosure requirements. Whether or not required by law, failure to disclose important privacy practices can spark FTC enforcement action as a deceptive consumer practice.

Be Complete & Conspicuous

Aside from potential FTC action, California law requires any company which holds personal information about a Californian to identify the types of information it collects about customers, explain how the consumer may change or update the personal information, and identify an effective date. The law also imposes an affirmative duty to disclose whether information will be disclosed to third parties for marketing purposes. California law also requires that a link to your company’s privacy policy be conspicuous. Most of the time, a link from the home page or in the footer will be sufficient.

A privacy policy is legally compliant when it addresses all of the various legal and regulatory requirements, but it is only complete when it addresses the full range of your unique business practices. For some organizations, that may be broader than you think. For example, a typical University engages in educational, financial, healthcare, network provider, non-profit, and goods and services activities on behalf of their students. That’s why there can be no such thing as a “boilerplate” privacy policy.

Privacy Policy Must Reflect (Changing) Practices

Like Ying and Yang, privacy Policy and Practice are complementary and inseparable. One consistent pattern of FTC actions is that updated information security practices are necessary to protect consumers’ privacy. As FTC guidelines indicate, “Good security is an ongoing process of assessing risks and vulnerabilities… Your business practices and privacy policy must be consistently updated to reflect current best practices and available technology.”

Get it Right the First Time

Even though your privacy policy must adapt to changing business needs, privacy policies cannot be retroactively modified. This issue is important in the following scenario: Suppose that your company decides it wants to sell customer personal information to marketers, but your privacy policy states that personal information “will not be shared with third parties without [customers'] explicit consent.” Changing the policy to allow you to sell personal information may apply prospectively, but new policy provisions will not apply to existing customers, without their consent. This can even apply to a transfer of personal information in a bankruptcy proceeding.

That’s why it’s important to get it right the first time. Your company’s privacy policy must allow you enough wiggle-room to adapt to future conditions, be complete, and still protect your customers. If you need to materially change your policy, make sure that you have the infrastructure to determine which version of your policy applies to which customer. It matters.

If You Say it, Do it

We’re all familiar with the Miranda phrase, “anything you say can and will be used against you …” by the FTC. If you make a representation in your privacy or security policy, you’d better be able to live up to it. FTC enforcement actions demonstrate that website owners must adhere to any statements of privacy or security, whether the statement is made online or offline.

Each representation about privacy or security is treated as a “privacy promise.” Feel-good marketing fluff does not belong in a privacy policy, because even “fluff” can create duties or liability, even if the duty is not required by law. Explicit security-related promises (such as a promise to use “state-of-the-art technology”) requires that the company take affirmative and ongoing steps to ensure that sufficient security is provided.

For example, in 2004 Gateway Learning Corp found itself the target of an FTC Deceptive Practice enforcement action for renting its customer list to marketers, even though their privacy policy said they wouldn’t. In recent years the FTC has taken similar action against Eli Lilly & Co., Microsoft, Guess, Inc., Tower Records, and Petco.com to name a few.

If your privacy policy says it, then do it.

It’s Your Business

As a soon-to-be attorney, I can say that you should have a lawyer review your privacy policy. Lawyers help the privacy policy comply with legal and regulatory requirements, but it’s your responsibility to make sure that the policy is complete. In fact, I would go so far as to say that 30% of a privacy policy is compliance, and the other 70% is completeness.

If those numbers are any indication, they mean that your privacy policy should have 70% of its input from the Customer Service Department, the Accounting Department, Sales, Marketing, and perhaps even R&D. Without their feedback it will be impossible to document your important privacy practices and create a complete privacy policy. Privacy policies are not legalese and magic words. They are a blueprint of vital business processes. There is one sure way to get in trouble: Relegate your privacy policy to the legal department, and fail to get cross-departmental participation in its drafting. Banishing your privacy policy just to the lawyers may get you in trouble because the end result may be compliant, but incomplete And ironically, an incomplete privacy policy is a non-compliant policy.

Take Charge

As a CEO, COO, or Managing Director, you should do three things:

1. First, read your privacy and security policy. If it confuses you, it will confuse your customers. If it confuses your customers, it might be interpreted as deceptive by the FTC.
2. Second, make sure you can live up to your privacy policy. Watch out for buzzwords like “state-of-the-art,” “everything within our power,” “always,” and “never.” Make sure that you haven’t painted yourself, your customers, or your employees into a corner.
3. Third, update your privacy policy to reflect your business practices, or update your business practices to match your policy. Being honest and complete about your business practices is tough work, but will pay dividends long-term.

This is part 3 of highlights from the FTC’s December 7th Privacy Roundtable. Part 1 covered the panel on "Exploring Existing Regulatory Frameworks," and Part 2 covered the panel on "Benefits and Risks of Collecting, Using, and Retaining Consumer Data" This post highlights comments from "Consumer Expectations and Disclosures" and "Information Brokers."

Disclaimer: I took notes using my Twitter account. About halfway through the "Benefits and Risks" panel, Twitter decided that I was a spammer, and shut down my account. I was mad, and it meant that I did not cover the whole session.

Benefits and Risks of Collecting, Using, and Retaining Consumer Data

• Lorrie Faith Cranor,Associate Professor of Computer Science, Carnegie Mellon University commented on consumers’ state of ignorance regarding how information flows, much like an unseen underground river. "Most people do not understand how information flows," or "what a third-party cookie is."
• Alan Westin Professor Emeritus of Public Law and Government, Columbia University referenced several of his studies which indicated that "…people are not prepared to equate [the need for] behavioral marketing with [funding] free services, and that "most people believe that they’re being abused," but there was general consensuses that most people surveyed also believed that they were protected by law and regulations that do not actually exist. In the meantime, Mr. Westin’s research also indicates that most people are no longer willing to trade privacy for freebies on the internet, because of the disconnect between "free" services and the fact that personal information pays for most of it.
• Alan Davidson, Director of U.S. Public Policy and Government Affairs for Google emphasized that the industry is trying to educate consumers and give them the tools they need in order to control their privacy, as evidenced by Google’s dashboard, for instance. He suggested that the audience Bing "Google Dashboard" for more information.
• Jules Polonetsky Co‐Chair and Director of the Future of Privacy Forum made reference to the results of several large surveys conducted by his organization. For instance, one indicated that there is a substantial public misconception about what "Behavioral Advertising" is. Among the handful of survey respondents who had heard the term, all of them mistook "Behavioral Advertising" for the concept of subliminal advertising. His organization is also attempting to generate symbols explaining how personal information is used, an approach endorsed by Privacy Commons and other groups.
• My apologies to Joel Kelsey, Policy Analyst for the Consumers Union, and Adam Thierer, President of University of Pennsylvania, Annenberg School for Communication. Each of these individuals actively participated, but unfortunately I was unable to capture their thoughts because I was under a temporary Twitter ban at the time.

Information Brokers

Short editorial: This session was by far the least enlightening.

• Jennifer Barrett, Global Privacy and Public Policy Officer for Acxiom started off the panel by discussing what constituted "sensitive personal information." She replied that Acxiom classifies "sensitive information" is any information which could contribute to identity theft, whereas "restricted information" is an unlisted phone number, for example.
• Rick Erwin, President of Experian Marketing Services explained that they consider information on children, older Americans, and self-reported ailment data to be "sensitive," adding that Experian has "three decades of experience using sensitive information for marketing," and is able to adequately balance the interests of marketers and consumers. Mr. Erwin also discounted the harms of marketing, saying "we can’t point to deep consumer harm based on bad advertising."
• Pam Dixon, Executive Director of the World Privacy Forum disagreed. She contended that the definition of "sensitive information" is difficult at best because otherwise benign information can be aggregated to create sensitive information. In regards to health information, getting consent from consumers is almost illusory because consumers have no way of knowing how the information will be used in the future. Informed consent is impossible without telling consumers what "boxes" they will be put in. Consumers need the right to know on what lists they will appear, for how long, and they must have the right to revoke their consent. Pam Dixon contended that "we need to make Opt Out work for consumers," and that opting out should always be free.
• In response, Jennifer Barrett insisted that the Information Broker industry needs no further regulation: "We’re already very regulated," she said.
• Jim Adler, Chief Privacy Officer and General Manager of Systems for Intelius explained that they offer special opt-out services to government officials.
• Chris Jay Hoofnagle, Lecturer in Residence at the University of California Berkeley School of Law was scheduled to participate but was unable due to technical difficulties.

The FTC has posted the webcast if you missed it.  The next Roundtable is scheduled for January 28, 2010 in Berkeley, CA and will also be broadcast online.

This is part 2 of highlights from the FTC’s December 7th Privacy Roundtable. Part 1 covered the panel on "Exploring Existing Regulatory Frameworks." This post highlights comments from "Benefits and Risks of Collecting, Using, and Retaining Consumer Data." This session was moderated by Jeffrey Rosen of The George Washington University Law School and Chris Olsen, of the FTC’s Division of Privacy and Identity Protection.

• Leslie Harris, President and CEO of the Center for Democracy & Technology emphasized that information taken out of context can be used to unfairly judge a person, such as a search for "marijuana" or a medical condition. The danger increases when a rich profile of search terms and surfing data is constructed over time.
• Susan Grant, Director of Consumer Protection for the Consumer Federation of America, said that "privacy is a fundamental human right."
• Alessandro Acquisti of Carnegie Mellon University, Heinz College, explained that the definition of "sensitive information" continues to change with technology, new uses for information, and new ways to correlate and aggregate personal information. Technology cannot stop re-identification or de-anonymization, but should be used to increase the transaction costs for re-identifying personal information. He also spoke about how companies are bypassing consumer efforts to maintain privacy and anonymity through technologies such as flash cookies.
• Richard Purcell, CEO of the Corporate Privacy Group, emphasized that citizens’ health depends on anonymized health data used for research, and that privacy must be weighed using a cost-benefit analysis. He further
• Michael Hintze, Associate General Counsel for Microsoft, explained that companies use log and use information for a number of legitimate reasons, such as security analysis, and search result optimization. However, he admitted that search terms can reveal individuals’ "innermost thoughts," and that anonymization is not a silver bullet to protecting users. Instead, retention and deletion policies such as Microsoft’s policy of deleting IP addresses and cross-cookie session information is designed to truly anonymize search data.
• David Hoffman, Director of Security Policy and Global Privacy Officer for Intel, stressed that we should focus on data minimization. "We have wasted time arguing about what constitutes PII," when the question should be, "what information will have an impact on an individual?"
• Jim Harper, Director of Information Policy Studies for The Cato Institute, argued that regulating too early can stifle innovation and prevent consumers from determining what they want themselves. Instead, we should attempt to define the problem set first. Mr. Harper explained that "there is a role for trial and error in determining what the real problems are," and that intellectualizing what consumers really want can lead to problems. Instead, we should "let a thousand flowers bloom" and let the social systems and advocacy draw out and solve the real issues.
• David Hoffman generally agreed that we don’t want to frustrate innovation, and that we are not currently in a position to understand all of the problems ourselves. He explained that it took a room full of experts the better part of a day to map out data flows. "We can’t expect consumers to understand how the data flows if experts can’t understand it now."
• Leslie Harris and Alessandro Acquisti said that Notification and transparency is necessary but not sufficient. Mr. Acquisti noted that consumers make decisions which are harmful to long-term privacy because humans are bad at making decisions when the benefits are short-term but harm is long-term. He compared privacy erosive behavior to smoking, since each smoker realizes that smoking causes cancer, but any individual cigarette doesn’t hurt much.
• Susan Grant explained that consumers don’t realize that their information can be used for other purposes, and that the benefits of marketing do not outweigh privacy concerns and fraud and abuse. Jim Harper countered that advertisers can introduce a new medication to vulnerable populations, and that denying them that opportunity can create silent harms. Michael Hintze added that niche ads aren’t good or bad- they’re responsible or irresponsible
• Richard Purcell also argued that companies should spend the time and money to train their customers, and create "privacy by design" rather than "privacy by default." Finally, the FTC should "regulate the hell out of" lazy companies and bad actors.
• Richard Purcell further emphasized that we lack a cohesive taxonomy for discussing privacy, and that we need to better define concepts such as "anonymity," "deidentification," and "sensitive data."
• The panel was asked to consider widespread customer blacklisting. Susan Grant said that consumers need tools to discover and amend secret "bad customer" lists, since they have none now. Distinctions based upon invisible information is bad for consumers. Leslie Harris agreed, saying that we need a law that provides access and correction for data brokers as well. She also criticized the FTC for failing to investigate privacy violations, saying that all of our bad examples are "accidental," not intentional long-term decisions to violate privacy, outed by the FTC.
• In the larger context, Jim Harper said that Government access to personal information is the elephant in the room that nobody has yet addressed. Governments are beginning to discover "the cloud" for their own purposes, and when data is available to government on the current terms, it constitutes surveillance on a massive scale.

I’ll do a few more installments in the coming days.

The FTC has posted the webcast if you missed it.  The next Roundtable is scheduled for January 28, 2010 in Berkeley, CA and will also be broadcast online.

The FTC’s December 7th Privacy Roundtable assembled a Who’s Who of privacy luminaries, academics, advocates, and industry players. This post highlights some of the more interesting comments from the meeting. I also tweeted the event (@aarontitus, #FTC #Privacy or #ftcpriv) and the FTC has posted the webcast if you missed it.  The next Roundtable is scheduled for January 28, 2010 in Berkeley, CA and will also be broadcast online.

The meeting consisted of five panels. This posts highlights "Panel 5: Exploring Existing Regulatory Frameworks:"

• During Session 5, Intuit’s Chief Privacy Officer Barbara Lawler posited that existing regulatory frameworks unfairly place the entire burden on consumers to protect themselves. "Consumers should expect a safe marketplace. They shouldn’t be the ones to police the marketplace," she said.
• Barbara Lawler also noted that "Data is never really at rest," because it’s moving between data centers and backups in multiple locations throughout the globe. It is therefore incorrect to think of data, especially Cloud data, as being in one place. Instead, "data is in one place and many places at the same time," potentially in multiple jurisdictions.
• Evan Hendricks of Privacy Times and Marc Rotenberg of EPIC suggested that the current model of "Notice and Consent" has failed to protect consumers, and that the FTC (and legislation in general) should return to well-established Fair Information Practices (FIPs), including a prohibition on "secret databases." Mr. Rotenberg went so far as to conclude that Notice and Choice principles are not a subset of FIPs, but instead "stand in opposition to fair information practices." He also joked that "the best part of Graham-Leach-Bliley Act is that you get paper notices you can tape on your window and get more privacy."
• Ira Rubinstein of New York University School of Law proposed that self-regulation is not binary or "monolithic," and that a self-regulatory scheme would be preferable, especially if viewed as a "continuum, based on government intervention." He argued that self-regulation would be especially appropriate in the United States, which has traditionally been very friendly to e-commerce.
• Michael Donohue of OECD gave an overview of international legal concepts of privacy which generally agreeing with Marc Rotenberg’s observation that "most countries have come to surprisingly similar conclusions about privacy."
• J. Howard Beales of the GWU School of Business argued in favor of a "harm-based model," because it is impossible to reach the best solution without first defining the harm. Marc Rotenberg responded that privacy harms are almost never financial.
• Several panelists emphasized that privacy can be highly (and appropriately) subjective. One cited an example from a balding friend of his, "I don’t care if anyone knows that I use Rogaine, but my 70-year-old grandmother would."
• Fred Cate of the Center for Applied Cybersecurity Research emphasized that the Notice and Consent model is flawed because some activities should not be consentable. For example, one may not "consent" to be served fraudulent or misleading advertising. Likewise, some uses of personal information should be prohibited and non-consentable. Most importantly, Notice and Choice are only tools- not the goal of privacy.
• After Panel 5 was done, Bureau of Consumer Protection Director David C. Vladeck said the FTC would investigate whether it is better to give consumers notice how their personal information may be used: 1. At the time of collection, or 2. At the time of use.
• David C. Vladeck also said that the data broker industry warranted FTC attention because it is "largely invisible to the consumer."

More highlights on the other sessions to come.

Some Problems With Privacy Policies

As Christopher, myself, and many others have pointed out, the problems with privacy policies are myriad. Here are a few:

• Inaccessible or Unintelligible. many privacy policies are not easily understood or even physically accessible; so complicated and wrapped in legalese that they are “nigh useless” to the average consumer.
• Complicated Solution. Unless we’re careful, a Privacy Commons may end up equally or more complicated than the status quo.
• Non-Standard. Privacy Policies are not standardized, making it impossible to compare apples-to-apples.
• Incomplete. They often fail to address important privacy issues or fail to consider all potential parties
• Unsophisticated. Many boilerplate privacy policies demonstrate a fundamental lack of understanding of how privacy policies translate to privacy and business practices. Some simply don’t address the most salient issues, which may be unique to their industry. Consequently, many of the policies never translate to practice.
• Treated as Only Legal Documents. Privacy policies are often treated as “compliance” documents and relegated to the legal department. Consequently, many fail to address or actually contradict field practices.
• Privacy Waiver. Many privacy policies waive, rather than confer, privacy rights. The medical industry is extremely efficient at this practice.
• Technology-Dependent. Privacy policies which strictly enumerate technologies quickly become outdated in the face of emerging technologies.
• Non-Binding. Most importantly, US courts have consistently interpreted privacy policies to be unbinding notices, rather than contracts. As a result, privacy policies generally create no enforceable rights or enforceable expectations of privacy. In this sense, privacy policies can create a false expectation of confidentiality, privacy, or even fiduciary responsibility.

Some Assumptions About Privacy Policies

Based on my experience in technology, advocacy, and the law, I want to air some of my basic assumptions about Privacy Policies. Of course, I invite challenges to these assumptions:

1. Mitigate Liability. Privacy is the subject of dozens of laws and regulations. The present primary business case for developing, maintaining, and conforming to a privacy policy is to mitigate liability.
2. Inform Data Subjects. Data Subjects include consumers, employees, or any individual about whom information is collected, stored, or aggregated.
3. Empower Data Subjects. Mere information is not enough. A privacy policy which produces information overload without actionable intelligence is counter-productive.
4. Articulate Privacy Practices. For the benefit of both data subjects and the data stewards who must execute the privacy policy, it must explain and reflect real business practices.
5. People Don’t Read. Anything more than about two paragraphs will never be read. That’s why high-level iconography is so appealing (and achievable).
6. Must Be Easy-to Understand. Because people don’t read. Fewer words and easy-to-grasp iconography are better.
7. Short Policies Are Inherently Incomplete. Two paragraphs and pretty pictures may be sufficient to inform consumers on the portions of the privacy policy they find most important, but will always be incomplete. More on this below.
8. Adoption & Enforcement. A Privacy Commons must be optimized for adoption, rather than enforcement. That’s simply because despite the Federal Government, the states and the FTC’s regulation in the area, a privacy commons must be market-driven to be successful.
9. Sector-Specific. Different sectors/activities collect different sets of personal information, are regulated differently. In order to ensure that privacy policies are relevant, they must be taylored to specific activities.
10. Living Documents. A privacy policy which was correct six months ago may not be correct today.
11. Privacy Policies are Complex. Deal with it. Privacy Policies are complex, just like Creative Commons or the Telephone. More on that below.
12. Business Documents. Privacy Policies are business documents with legal, practical, business, and ramifications for corporations, their agents and employees, and data subjects.

Thinkers like Christopher Parsons worry that a Privacy Commons will be unnecessarily complex. Non-attorneys are often (justifiably) baffled at why lawyers take 3,000 words to say what can be said in 300 and a handshake. It turns out that a simple handshake is not as simple as most people think. Behind each handshake there is a wide range of assumptions which are not as standard as one might believe. Many (if not most) disputes arise when there is a misunderstanding about an unspoken assumption—the meaning of a word, or silence on a particular issue. That’s why it takes lawyers so many words to say something so simple; simple things are not as simple as we thought.

To demonstrate this point, we need look no further than Creative Commons. While the human-readable version of the “Attribution Non-Commercial Share Alike” creative commons license consists of 5 images and 286 words, the legal version contains 3,384 words. Clearly the unnecessary work of a verbose lawyer who needed to justify his existence, right?

Not so fast. The full Attribution Non-Commercial Share Alike license covers a whole bunch of other stuff that consumers don’t usually take time to think about, unless of course there is a dispute. It’s only at that point that we’re glad we included it. The legalese version covers essential topics like media and language translation, public performance, DRM, collections of works, waiver of compulsory license fees, preservation of moral rights, representations and warranties, limitation on author’s liability, termination, severability, waiver, and entire agreement, just to name a few. Consumers don’t (and shouldn’t) think about this kind of stuff when they proverbially “shake hands” with a licensee. Creative Commons is simple on the surface, but look under the hood and you’ll see the complexity necessary to create the elegance that most people associate with the CC licenses. Saying that the legalese version of a Creative Commons License (or Privacy Commons Policy) is a “necessary evil” is incorrect and misses the point. It’s not evil at all; it’s just necessary.

It’s like a telephone—an elegant piece of equipment which is exceedingly easy to use. The end-user only cares about a few things: Connectivity, line quality, cost, and accessibility. Yet the infrastructure and technology supporting telephony and networking is extremely robust and complex. Consumers pay the telcos to worry about all of the other stuff so they can focus on the four or five things that consumers care about. The millions of miles of copper, routers, substations and central offices aren’t a “necessary evil,” they’re just necessary.

Some Conclusions About Privacy Policies

We’re just going to have to deal with the fact that privacy policies are complex, and will continue to be complex. The best solution (as I see it) is to do three things: ID c.

• Require Thoroughness. A Privacy Commons-compliant policy is thorough
• Identify Cultural Notions of Privacy. Identify culturally important notions of privacy, and embody them in easy-to-understand iconography. Christopher Parsons suggests these notions might center on Data Collection, Data Sharing, Data Identification, Data Tracking, Data Deletion, and Aggregation, which I think is a good start. And Ralf Bendrath offers these excellent icons, which are more elegant than any I’ve seen.
• Embody the Cultural Notions of Privacy in Iconography. Then let the legalese version fill in the (necessary) gaps.

A privacy policy which conforms to Privacy Commons requirements will be complete, informative, easy to understand, and easy to adopt. Like Creative Commons, Privacy Commons seeks to identify common cultural notions of privacy, and embody them in easy-to-understand policy frameworks, with simple high-level iconography.

Note: I usually blog on securitycatalyst.com and jeffreyneu.com, but this post doesn’t fit very well on either.

This rule, issued in response to ARRA, goes into effect on Wednesday. At that point, all HIPPA-covered entities and their business associates must notify individuals and HHS when personal health information has been breached. HIPPA-covered entities include health plans, health care clearinghouses, or health care providers. The rule also covers “business associates” which include billing companies, transaction companies, lawyers, accountants, managers, administrators, or anyone who handles health information on behalf of a HIPPA-covered entity.

A breach is when individually identifiable health information is acquired, used, accessed, or disclosed to an unauthorized party, in a way that compromises its security or privacy. A “breach” does not include inadvertent disclosures among employees who are normally authorized to view protected health information. A breach also does not include exposure of encrypted personal health information, for example.

When a breach occurs, the covered entity must notify victims and the Secretary of Human Services “without unreasonable delay,” and within 60 days of the discovery of the breach. The covered entity must notify the individual directly if possible (ie, by mail), and must also post a notice on its website if the breach involves 10 or more victims who are not directly reachable. If the breach involves more than 500 residents of a single state, the covered entity must also notify statewide media.

In certain limited circumstances a vendor might be subject to HHS and FTC notification rules. In this case, a vendor which serves the public and HIPPA-covered entities may comply with both rules by providing notice to individuals and the HIPPA-covered entity. In many instances, entities covered by this rule must also comply with applicable State notification laws. The test for pre-emption is whether the State law is “contrary,” to the federal law or whether “a covered entity could find it impossible to comply with both the State and federal requirements.”

Compliance

Of course, the best way to comply with the law is to avoiding breaches altogether. The most straightforward way to avoid having a breach is to encrypt personal health information. But if a breach does occur, complying with the law is straightforward. In addition to the requirements above, the notification must include a brief description of the incident, including the following information:

• Date of the breach;
• Date of discovery;
• Description of the types of protected health information breached;
• Steps individuals should take to protect themselves from potential harm resulting from the breach;
• A brief description of the investigation, efforts to minimize losses and prevent future breaches;
• Contact information for individuals who wish to ask questions or learn more information, including a toll-free phone number, e-mail address, website, or postal address.

Beyond that, you’ll have to minimize your losses by repairing your company’s public image, regaining your customers’ trust, and mitigating civil liability.

References: 45 CFR parts 160, 162, and 164.

Note: This article was originally published on the J.C. Neu & Associates Blog.

~IDENTITÄT – The »Gestalt« of digital identity

~IDENTITÄT – The »Gestalt« of digital identity is the bachelor’s thesis of Jonas Loh and Steffen Fiedler. The students at University of Applied Sciences Potsdam, Germany crawled more than 100,000 personal raw data sets on the web and analyzed their contents, including parameters of time. They developed methods for visualizing and comparing the data, resulting in a series of “personal interpretation[s] of the dig­ital identity as an amorphous sculpture.”

The results are striking embodiments of complexity, movement, incongruity, and finiteness; much like the average identity. These sculptures are successful because they capture the movement and growth of one’s identity, convoluted and tied in messy knots of contradictions, incompleteness, and experimentation.

~IDENTITÄT is a reminder of the simultaneous complexity and finiteness of human identity, and a warning that our digital identities are nothing more than a collection of credit reports, Facebook pages, Google results, bank account numbers, and archived e-mails.

As an odd mashup of Geek, Identity Guy, and Architect/Designer, I couldn’t help but give this project a shout-out. And though I think that the description “gestalt” is a little overstated, the provocative sculptures teach us new ways to abstract something as indeterminate and personal as your identity. Bravo, Jonas and Steffen.

Hat tip: Identity Woman.

As a privacy and consumer advocate, it ruffles my feathers when otherwise legitimate companies force the public to disregard common-sense online safety practices in order to use their services. Among the many safety tips are:

1. Only give confidential personal information to people you affirmatively contact, never to anyone who spontaneously contacts you.
2. Don’t click on URLs in unsolicited e-mails.
3. If you want to click on an e-mail link, never click “dishonest” links – links that don’t match the displayed URL.

Bad Practices

American Student Assistance (ASA) is a non-profit organization which helps students keep track of their student loans. It’s also an example of a legitimate organization with some irresponsible privacy practices.

Earlier this year I received an unsolicited e-mail from the ASA. I had never heard of the ASA, but the e-mail insisted that they were “the guarantor of [my] federal student loans.” To this day my bank has not introduced me to the ASA. Of course, this spontaneous contact from an “authoritative” organization made me suspicious. Red Flag 1: Unsolicited e-mail claiming to be from an authoritative source.

The letter instructed me to follow a link to log in with my FAFSA PIN. I was also notified that I have a “Profile,” and was invited to Update my profile by clicking on a link. The link took me to an insecure and unbranded website which automatically filled out my name, e-mail address, and indicates that I have been opted-in to receive a newsletter. Red Flag 2: Unsolicited authoritative e-mail, requesting that you “log-in” using sensitive information on an unsecured, no-name server. Spam newsletters are a bonus.

But before clicking on the links, I moused over each of them to see where they led to. A link which purported to go to “www.amsa.com/bor” actually links through “http://click.email-asa.org/?qs=33c40ef691b275c8d3b7e7d0430ce34d0980241c6c7eb313b745465bb515d8d5″. In fact, each of the eight links in the e-mail were “dishonest,” in that the actual URL was different from the displayed URL. Red Flag 3: Dishonest links.

This e-mail screamed “Phishing Scam,” so I called the toll-free phone number listed in the e-mail. A woman answered the phone. She immediately asked for sensitive personal information. I gave her my first and last name, but refused to give her any additional information since they had contacted me and I had no way to verify who they were. Red Flag 4: Unsolicited third party requesting personal information over the phone.

ASA’s Privacy Policy contains the following promises:

We do not disclose any nonpublic personal information about you or our other current or former customers, except as permitted by law…. We restrict access to nonpublic personal information about you to our employees, contractors, and agents who need to know the information in order to provide service to you…. We maintain physical, technical, and administrative safeguards in compliance with federal regulations to safeguard your nonpublic personal information. (Accessed August 27, 2009.)

But ASA’s privacy policy didn’t translate to privacy practices. After I refused to share personal information the lady on the phone asked, “Is your name Aaron [X] Titus, or Aaron [Y] Titus?” Uncomfortable, I replied, “Aaron [X]…” She asked for my date of birth. When I refused to give it to her, she read it to me over the phone. When I refused to give her my address, she repeated my full address including street, number state and zip code. She told me which school I attended and that she had access to my social security number on her screen. Red Flag 5: A representative sharing sensitive personal information over the phone without first authenticating.

Since I had no idea who this organization was I asked, but never got a straight answer. She and her supervisor variously described the organization as a “government agency,” “not a government agency,” “a non profit government agency,” and a “non profit organization which receives federal funds.” They relied on some relationship with the federal government to gain credibility. Red Flag 6: A fishy and inconsistent story designed to earn your trust.

My Advice: Quit it

After filing a complaint with the company, I talked with ASA’s Privacy and Compliance Director, Betsy Mayotte. Ms. Mayotte was kind enough to apologize for the behavior of her organization, and convinced me that the ASA is a legitimate organization, albeit one with uneducated and dangerous privacy practices. Apparently the representative was re-trained. But they did not plan to change anything else.

The dishonest links were designed to measure click-throughs: A common marketing practice. The unbranded and insecure server which asked me to update my “profile” was the result of bad practices, laziness or poor training. The other blatant violations of their privacy policy and outrageous behavior by the representative was more of the same.

I wish I could say that this is an unusual event. But unfortunately I’ve seen similar behavior by my bank, and even former employers. When legitimate companies force consumers to be irresponsible, the online public becomes irresponsible. Forcing consumers to ignore common-sense safety practices may save you a buck in the short run, but they make your customers irresponsible and erode overall online public safety. So here’s my advice to legitimate companies who behave like phishing rings:

Quit it.

Seriously, stop training the public to be irresponsible. If you want to track click-throughs for an e-mail marketing campaign, set up a virtual redirect on your main server. If you got sensitive personal information through a third party, make sure to have that third party introduce you to the customer. Don’t send unsolicited e-mail, and don’t cold-contact potential customers to request that they share personal information. Once and for all, encrypt your website. If your marketing department isn’t all that tech-savvy, hire someone who is. Train your customer service representatives never to give out personal information without first authenticating the identity of the person on the other end of the line.

Privacy policies are not just legal boilerplate which you can write and forget. Make sure that your privacy policy matches your privacy practices. This means that your customer service representatives should be as familiar with it as your general counsel.

Note: This article originally appeared on Security Catalyst.

by Aaron Titus

Georges-Pierre Seurat was a 19th century French painter credited with starting Neo-impressionism and developing a painting technique called “pointillism.” His famous painting, La Parade, contains the detail on the right: A complicated series of blue, orange, pink, red, black, and yellow dots that together create a man’s profile.

This detail is the single best visualization of your “Data Self” I have seen. Your Data Self is a collection of your credit report, Facebook page, Google results, Bank account numbers, archived e-mails, and an endless parade of other data. Like pointillism techniques, which juxtapose contrasting dots to create vibrant masses of shaded tones, each piece of personal information is a single dot. Perhaps one is your address, your middle name, your pet’s name, or your favorite color. Maybe some represent your family, and others represent your friends or religious beliefs. Some represent your travels, magazine subscriptions, and purchase habits. Still others are intimate thoughts.

Taken individually or in small groups, they do not mean much- they may even seem to contrast or contradict one another. But all together they form your profile, or Data Self: A pretty good, but not 100% accurate representation of who you are. And this profile is exactly what data brokers, government actors, and marketers (among others) are trying to determine.

We leave trails of dots as we interact with others, especially online. As Gregory Conti, a computer science professor at the United States Military Academy at West Point, explained, “Free Web services aren’t free. We pay for them with micropayments of personal information.”

Since your Data Self is a digital alter-ego, with the power to enter contracts, grant access to your financial assets, have surgery, or commit crimes, you should actively shape and control access to your Data Self.

If you have nothing to hide, why do you need privacy? This question, famously attributed to the McCarthy era, has gained currency again in this era of terrorism and national security. The question implies that privacy is a form of dishonesty, that the things people want to hide are the very things others should know about.

I admit that I bristle every time I hear someone say, “You have nothing to worry about if you have nothing to hide.” Baloney. I have everything to hide! When someone says, “I have nothing to hide,” it’s simply not true. What he really means is, “I have nothing to be ashamed of,” which may be true. But shame is only one, limited reason for confidentiality. Confidentiality is not an admission of guilt.

I have much to hide, for one simple reason. I cannot trust people to act reasonably or responsibly when they are in possession of certain facts about me, even if I am not ashamed of those facts. For example, I keep my social security number private from a would-be criminal, because I can’t trust that he’ll act responsibly with the information. I’m certainly not ashamed of my SSN. Studies have shown that cancer patients loose their jobs at five times the rate of other employees, and employers tend to overestimate cancer patients’ fatigue. Cancer patients need privacy to avoid unreasonable and irresponsible employment decisions. Cancer patients aren’t ashamed of their medical status—they just need to keep their jobs.

A person may share intimate secrets with an ecclesiastical leader that they would keep private from parents, because they fear the parents may not act reasonably or rationally when presented with the same information. During World War II, the government acted unreasonably and irresponsibly with Census data about the location of Japanese-American citizens. Privacy from government entities is paramount.

In addition, can you imagine how much damage you would impose on innocent people if you spoke every thought that came into your head? Or if doctors, lawyers, and accountants disclosed everything they knew about you?

The need for privacy is the recognition that most individuals, organizations, or institutions cannot be trusted to act reasonably, responsibly, in the best interest of the person, or in the best interests of society, when in possession of certain types personal information. Humans are biased. We have limited cognitive and analytical abilities, and never know all of the facts. We are infamously poor judges of character. We change our minds, and come to conflicting conclusions. So, the next time someone asks whether you have something to hide, do not hesitate to say, “Yes, of course I do.”

“We’ve had a breach.” It’s a sentence nobody wants to hear, but when it happens to you, what to you do? If you’re in the healthcare industry, new federal regulations probably require you write a letter to the victims of the breach, or more. When and how quickly do you have to send a HIPAA/ ARRA notification? And what does it have to say?

The American Recovery and Reinvestment Act of 2009 (ARRA) requires HIPAA-covered entities to notify breach victims when protected health information has been disclosed to an unauthorized person. The legislation gives liberal exceptions for good faith and inadvertent disclosure. Redaction or encryption is an absolute defense to a breach.

“Protected Health Information” is any stored or transmitted health information which can be tied to an individual. It may include information not directly related to health, such as a full name, social security number, date of birth, home address, account number, or disability code. The law also requires third-party contractors or “business associates” to report breaches to the covered entity.

When a breach occurs, the covered entity must notify victims and the Secretary of Human Services “without unreasonable delay,” and within 60 days of the discovery of the breach. The covered entity must notify the individual directly if possible (ie, by mail), and must also post a notice on its website if the breach involves 10 or more victims who are not directly reachable. If the breach involves more than 500 residents of a single state, the covered entity must also notify statewide media.

A breach notification letter must meet differing but complementary legal and economic goals. They include:

1. Complying with law
2. Minimizing Losses
   • Repairing your company’s public image
   • Regaining your customers’ trust
   • Mitigating civil liability

Compliance with Law

Complying with the law is straightforward. In addition to the requirements above, the notification must include a brief description of the incident, including the following information:

• Date of the breach;
• Date of discovery;
• Description of the types of protected health information breached;
• Steps individuals should take to protect themselves from potential harm resulting from the breach;
• A brief description of the investigation, efforts to minimize losses and prevent future breaches;
• Contact information for individuals who wish to ask questions or learn more information, including a toll-free phone number, e-mail address, website, or postal address.

Repairing your Company’s Image

Avoid the natural tendency to clamp up. Of course, the best way to protect your company’s image is to keep bad news out of the public eye. But once the cat’s out of the bag, several studies indicate that more than two-thirds of economic losses arising from a data breach are due to brand diminishment and lost customer trust, rather than litigation or identity theft expenses.

Above all, your company must maintain credibility. Be honest, open, and share enough detail to convince an educated person that you know what you’re talking about, and that you’ve actually fixed the problem. Consider hiring an outside security consultant who can 1. Give you genuine feedback on your security practices, and 2. Vouch for your credibility when you say that your customers are safe.

Rebuilding Customer Trust

Consider your last trip to the Department of Motor Vehicles. It probably consisted of waiting for hours in multiple serpentine lines without any direction, followed by more waiting, followed by spending money. The best part is riding away in your car when you’re done. Surprisingly, Disneyland and the DMV have a lot in common: Long lines, spending money, and rides. What sets the DMV apart from the happiest place on earth? One important ingredient is Customer Empowerment.

One way the Disney folks empower customers is by posting periodic signs in long lines: “Wait Time: 45 minutes from this point.” Though the sign does not decrease wait time, it informs and empowers customers. And as Disney knows, empowered customers are happy customers. Frustrated, angry customers are far more likely to cause trouble or leave altogether.

The best way to rebuild your customers’ trust is to empower them. Too many breach notifications include the unhelpful statement, “We have no reason to believe that anyone has accessed or misused your information.” The statement is faulty because it does not empower the customer to take action. Also, if the statement isn’t completely true, or if it changes in the future, it may inadvertently induce liability under certain circumstances. Further, these types of statements tend to frustrate rather than empower customers, causing some to conclude that the notification is incomplete or disingenuous.

Instead, consider these options:

• Say, “Although we have no reason to believe that anyone has accessed or misused your information, if you think your personal information has been misused as a result of this breach, please call 1-800-XXX-XXXX so we can investigate…”
• Include statistics on typical rates of harm for similar breaches, where possible.
• Actually investigate the breach.
• Create a website where customers can get up-to-the minute updates on the investigation directly from you, rather than from the media (and update it after the media buzz has subsided).

Mitigating Civil Liability

ARRA does not expressly create a private right of action for a HIPAA breach. Other theoretical sources of liability exist, though. For example, an individual may be able to rely upon a notification statute as the basis for a suit alleging negligence per se, where the breach of the duty to notify causes proximate harm to the plaintiff. Next, failure to correct statements (such as privacy policies) which have become false or misleading in light of new events, may create a tortious cause of action if the company fails to warn customers about foreseeable risks to personal information.

In contrast, most breaches are not likely to create privacy liability. Privacy tort actions usually require the breached information to cause extreme emotional distress, or a dilution of the property value of reputation or prestige. In addition, most courts have consistently failed to force companies to pay for credit monitoring services unless:

1. A person has become an actual victim of identity theft.
2. The person has found the thief
3. The person can prove that the thief’s copy of their SSN or other personal information came from the breaching entity, and
4. The person proves that the entity had a legal obligation to keep that information private.

Instead, it’s important to remember that businesses stand to loose more money from brand diminishment and lost customer trust than from litigation.

Streamlining medical records has been a recurring theme of the Obama administration. Tucked away in the pending economic stimulus legislation, known as the American Recovery and Reinvestment Act (ARRA), is a provision which would create a breach notification requirement for health information breaches.

Starting in Subtitle D, ARRA takes an unprecedented foray into federalizing data breach notifications. Although ARRA regulates breaches of health information, this legislation will no doubt be front and center of future debates about creating a Federal Breach Notification Law.

Synopsis

Here is a quick analysis: ARRA mirrors most state breach notification laws, in that it requires “covered entities” (ie, Health Plans, Health Care Providers, and Health Care Clearinghouses) to notify each individual if their “unsecured protected health information has been, or is reasonably believed by the covered entity to have been, accessed, acquired, or disclosed as a result of [a] breach.” Business Associates, or subcontractors, must alert the Health Care Provider of a breach. The statute also places additional limits on how health information can be sold and shared.
The statute dramatically broadens the ambiguous state-law concept of “data owners,” and applies to any HIPPA-covered entity that “accesses, maintains, retains, modifies, records, stores, destroys, or otherwise holds, uses, or discloses unsecured protected health information.”

As expected, the Federal law takes a lowest-common-denominator approach to duties. For example, although notifications must be made “without reasonable delay,” the statute allows up to 60 calendar days to comply. This is substantially longer than the longest state requirement, which requires notification within 45 days.
Each state notification law requires direct (ie mail) notification to affected individuals unless the person can’t be found, and allows “Substitute Notice” in cases of large breaches. “Substitute Notice” usually comprises posting an announcement on the organization’s website and notifying the media. Some states do not permit Substitute Notice unless the breach is extremely large (250,000+ in some cases). But ARRA allows substitute notice if the breach involves just 500 people in a single state.

The statute also reaches well beyond traditional “covered entities” to any service provider or vendor of personal health records. Presumably, this would include data warehouses like Google or Microsoft, each of which has or has announced plans to create online consumer health records warehouses. However, these vendors need only report the breach to the FTC, which will treat it as a deceptive trade practice. Individuals should not expect a letter from Google or Microsoft if their health care records are breached.

On one hand, this federal legislation will plug holes in several states statutes by regulating health information. Arizona, California, Hawaii, Michigan, Oregon, and Rhode Island, for example, regulate health care providers and insurers differently from other companies, and may even completely exempt them from notification requirements.

This bill will no doubt spur the national discussion about breach notification laws. But because they mimic existing state laws, the bill comes up short. Breach Notification Laws were a step in the right direction when California passed the first one almost seven years ago. But since that time, they have displayed several shortcomings, which I critique here. Instead of fixing these problems, ARRA will exacerbate many of them.

Colleges and universities store employment data, financial records, transcripts, credit histories, medical histories, contact information, social security numbers and other types of personal information. Although higher-education institutions should be forums where information and knowledge are easily exchanged, “sometimes the free flow of information is unintentional.” Here are eight policies and behaviors that put personal information at risk:

1. Administrative Decentralization
2. Naive Office Culture
3. Unprotected “Old” Data
4. Shadow Systems
5. Unregulated Servers
6. Unsophisticated Privacy Policies
7. Improper Use of the SSN
8. Unsanitized Hard Drives

Administrative Decentralization

In a university setting each college, each department, and often each professor operates nearly autonomously. In an environment where knowledge must flow freely, decentralization is a must. However, it means that new centralized policies to address information security are difficult to implement.

Naive Office Culture

A closely related risk factor is office culture. Staff turnover makes training an ongoing struggle, despite strict policies governing information control. Accidental information leaks can occur, even in the most secure IT environment. In addition, all office cultures resist changing any process, no matter how inefficient. In one example, I called my law school to discuss financial aid. After identifying myself by only my last name, the staff member automatically read my social security number over the phone.

Unprotected “Old” Data

Colleges do a pretty good job of guarding current personal information, but fail to protect older information, which is especially risky if the old data includes social security numbers.

Almost every week a faculty member backs up an old hard drive to his personal web space, unaware that the hard drive contained legacy student grades and social security numbers. Occasionally the professor is aware of the information but mistakenly believes that his university-provided Web space is not available to the public. Often the data sit on the institutional server for up to five years undetected and forgotten—until the information turns up on Google.

Shadow Systems

“Shadow Systems” are copies of personal information from the core system which professors, colleges, departments, and even student organizations maintain independently. Shadow systems can be sophisticated databases under high security or simple Excel spreadsheets on personal laptops. They multiply at an alarming rate because faculty members with administrative access can create their own databases at any time.

Thus, even though a small army of information-technology professionals may guard a college’s core systems, the security perimeter extends much further. And despite strict policies governing information control, employee turnover makes training about privacy and security issues a continual struggle.

Unregulated Servers

Often faculty members and third-party vendors also set up their own unregulated servers outside university firewalls, often for legitimate academic use. Those servers are particularly vulnerable to hackers and accidental online exposure. In one security audit, a private university uncovered 250 unauthorized servers connected to its public internet network, each containing sensitive student information.

Unsophisticated Privacy Policies

Colleges’ privacy policies often demonstrate a basic lack of understanding of the law and, more importantly, how the institution carries out the law through internal processes. Many policies basically say nothing more than “We follow the law,” without explaining what the law is or how they follow it. Even worse, some simply say, in essence, “Trust us, we’ll be good.”

Many institutions’ privacy policies also erroneously mimic commercial policies, which are narrowly tailored to cover only information collected online. Those policies are deficient in a college setting because just a small fraction of personal information that colleges maintain is collected online.

Further, a single institution may have dozens or hundreds of separate privacy policies, each dealing with a different, and incomplete, set of issues. For example, at some highly decentralized institutions, each college, department, and even some facilities like student unions have their own privacy policies. While privacy policies should reflect the practices of each group, inconsistent policies can create confusion among staff members who must explain or carry them out.

Improper Use of the SSN

Even though many colleges don’t now use social security numbers to identify students, they once did. Those old records sit like land mines on old servers. In addition, some universities print them on academic transcripts and official documents. Even though the American Association of Collegiate Registrars and Admissions Officers recommends printing the social security number on transcripts, my January 2007 study indicates that fortunately, most don’t.

Unsanitized Hard Drives

Deleted files remain almost unchanged on the hard drive until it is overwritten or physically destroyed. Once unsanitized hard drives are re-sold, sensitive personal and corporate information can be easily retrieved. Though most universities have a sanitization protocol when retiring old hard drives, enforcing the policy can be challenging.

Solutions

College administrators should consider the following:

• Regularly scan institutional networks for sensitive information, such as social security numbers, grades, and financial information. Use a combination of public search engines, and internal text- and file-scanning software.
• Automatically retire “old” data on institutional servers but allow faculty members to un-retire old data they still use. Forgotten information is dangerous information.
• Establish a “radioactive date,” which is when your institution last used social security numbers as an identifier. Files last modified before this date should be presumed dangerous.
• Create permissions-based access to core systems. Sensitive personal information should be available to faculty members and departments only on a need-to-know basis.
• Establish a data-retention-and-access policy by balancing threat, benefits and risks of maintaining the data.
• Coordinate interdepartmental privacy and security practices with a special committee of information security professionals.
• Update your privacy policy to reflect all privacy issues arising in a university setting. Explain privacy rights and practices that protect offline employment information and sensitive student records. Also explain work-flow protections (for example, “only director-level employees have access to social security numbers”) and technical practices (for example, “employee data is stored on encrypted hard drives”). Privacy policies should deal with more than just cookies and Web forms.
• Eliminate social security numbers from official records where possible, or establish a policy whereby students can opt to omit their numbers from transcripts or other records.
• Physically destroy all old hard drives.

Institutions of higher education must promote the free exchange of ideas while protecting sensitive personal information. Although the academic environment can seem at odds with information security, appropriate practices and procedures can balance information freedom and personal privacy.

Aaron Titus is the Privacy Director for the Liberty Coalition, and runs National ID Watch. A version of this article originally appeared in the October 24, 2008 edition of the Chronicle of Higher Education, and is republished here by arrangement.