PII 2011: Implementing a Privacy Program

This session is a “behind the scenes look at Micrsoft’s internal privacy program.” See the agenda for more information. Participants: Kim Howell, Reese Solberg, Michelle Bruno.

Kim Howell, (one of) Privacy Directors at Microsoft: When you’re doing a privacy review (practical, intuitive), you need to ask questions. Role playing with Reese as new company seeking a “privacy policy.” First questions (from our table discussions): what does site do, how do they collect info and what do they do with it? What’s their info flow path (is it resold?)? What’s their business model? How do you protect what you’ve collected? Controls by the individual (can visitors remove their data? remediation? transparency?)? Cookies? Other passive data collections? Countries involved (collection, use, storage)?

From Kim: Website: is this a new domain, link to privacy statement? existing privacy statement and does it match/make sure it covers everything? Data collection (see above). Send questions to new site/organization, get information, iterate. More questions: authentication, communication, vendors. Are people creating new accounts? use of email? data access requests? Vendors? Next round of questions: how well does IT + PR + Lawyers work together? Does privacy statement match the service? where’s plausible deniability? Make sure what’s required is clear, what’s optional. Provide better notice about use of information, data retention. Using HTTPS? How easy/obvious is it to obtain informed consent when signing up? Companies often think that writing a privacy statement at the last minute. (Wrong)

Next iteration: What new data is being collected? being sent where? other (new) features coming up? what info is shared? location: is it always being sent, or only in use when app is open? what other info (unique device ID, cell tower info, gender, etc.) is being sent with location data? data retention? If services changes, company may need to re-opt in application users. Privacy controls? (example of circulating the data within different departments of the company, “accounting department loves this data.”) Who needs access? for what use? access to raw data or aggregated statistics? Have data handlers been trained? Unique identifiers are not the only way of identifying a person. What’s intended use of collected data?

Michelle Bruno, Technical Privacy Manager: see printed case study (not online). Focus areas:

  1. Level setting: focus on use of customer data, customer expectations, opting out
  2. Author guidance: “how to” guides, privacy review checklist, company activities, data sharing, research and betas
  3. Position yourself: pro-business privacy message, culture of privacy as a value-add
  4. Piggyback: identify existing processes that you can take advantage of: spec templates, guidelines, bug tracking, testing, release management…
  5. Analyze and assess: comprehensive data-gathering plan to understand company’s risk
  6. Educate: pro-privacy contacts in each group to help succeed, spread work to peers about new process/resources
  7. Identify triage partners: incident handling, partnerships in legal, customer support, operations, PR
  8. Measure: what are your success metrics?

Questions: tension between user controls and corporate collections? Make sure value matches, is understood by both sides. Look at what business can put in place to allow better user controls. Microsoft has a federated privacy team, Kim’s team defines what compliance looks like.

Not mentioned in this panel but of some related interest (about Terms, not Privacy Policies): TOSAmend and EFF‘s TOSback.