Basic TrainingEditors: Richard Ford, rford@se.fit.eduMichael Howard, mikehow@microsoft.com

One recent study (www.rsasecurity.com/press_release.asp?doc_i=6502) found that roughly half of USconsumers have “little or no confi-dence” that organizations take suffi-cient steps to protect their personaldata. This paves the way for privacyto become a market differentiatorfor companies; respecting privacy bydefault and empowering customersto control their personal data can bea strong business proposition for newand existing customers. To avoidprivacy pitfalls and build productsand services that empower cus-tomers, companies must developholistic strategies for addressing pri-vacy in the development process.

Identify your privacygoals and objectivesThe first step in building a privacyprogram is to identify the high-levelgoals and objectives. This isn’t aneasy task—the definition of “pri-vacy” can vary greatly, depending onmarket, culture, and countless otherfactors. One obvious goal is to fulfilllegal obligations. Privacy mishapscan not only trigger scrutiny fromdomestic and international regula-tors but also have a significant andlasting impact. Besides the immedi-ate litigation costs, consumers re-member mistakes, which can hauntcompanies indefinitely.

An equally important goal is tobuild customer trust by designingprivacy-preserving products and ser-vices. Including such a goal raises thebar for companies that settle for justbeing legally compliant and can be-come a driving force for market dif-ferentiation.

Define a coreprivacy teamOnce you identify the program’sgoals, designate a core privacy team(CPT) to build and support a pro-gram that fulfills the defined objec-tives, including ratifying guidelines,identifying and improving processes,developing training collateral, anddriving privacy reviews. For largeorganizations or companies thatproduce multiple software products,it’s best to make the CPT’s role a full-time responsibility.

It’s important to build the CPTwith a balance of legal and technicalexperts. Understanding privacy lawsis necessary in creating any privacyprogram, but it’s equally important tobuild credibility with the develop-ment community by including pri-vacy professionals that understand thedevelopment process and have trackrecords of working well with devel-opers. Once the CPT is built, it canbegin to define the program, deployits processes, and enforce the rules.

Create definitionsand guidelinesNot all developers can be privacyexperts, so it’s important for theCPT to create clear, reusable guid-ance and processes that developerscan use to make sure that productsmeet privacy requirements.

The CPT should establish a base-line—defining key privacy terms andcompiling rules for how to consis-tently implement privacy-compliantproducts and services. Defining pri-vacy terms sets the tone for privacydocumentation and ensures that ruleswill be written with a common un-derstanding of their scope and mean-ing in mind. The term “personalinformation,” for example, couldmean different things to differentpeople: contact information only, aunique identifier plus behavioral data,passwords and PINs, and so on. Untilthe CPT defines the scope and con-text, a rule covering personal infor-mation could be interpreted andimplemented inconsistently.

Once the CPT documents com-mon privacy language, it shoulddefine rules based on common devel-opment scenarios within the com-pany. If the company specializes inonline services, for instance, rulesshould focus on common activitiessuch as deploying Web sites, transfer-ring data to and from customers’machines, downloading browserplug-ins and cookies to customers’machines, capturing customers’ con-tact information in Web forms, andspecial considerations for children.Companies that deploy Web sites in,for example, the US and South Korea,should capture the requirements ofthe Children’s Online Privacy Protec-tion Act (COPPA; www.ftc.gov/os/

TINA R.KNUTSON

Microsoft

In the marketplace, customer trust is paramount. As con-

sumers increasingly rely on the Internet for shopping, bank-

ing, and other daily activities, privacy is both a major public

concern and a barrier to e-commerce’s growth: fear of data

breaches and identity theft threaten to erode trust in the Internet.

Building Privacy into SoftwareProducts and Services

72 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY

Basic Training

1999/10/64fr59888.pdf ) and the Acton Promotion of Information andCommunications Network Utiliza-tion and Data Protection, respectively.If client applications are the specialty,rules should focus on installing anduninstalling software on customers’machines, transferring customers’data to or from their machines, andstoring data on customers’ machines.In all cases, the CPT should definerules for storing and handling personaland anonymous data.

As the CPT defines rules for eachdevelopment scenario, it should payspecial attention to each of the FairInformation Practices (www.ftc.gov/reports/privacy3/fairinfo.htm):notice/awareness, choice/consent,access/participation, integrity/security,and enforcement/redress. The CPTshould carefully consider which fairinformation practice principlesapply to each scenario, ensuring thatthe final set of privacy rules has abroad scope and coverage. The “Ad-ditional Privacy Resources” sidebarlists resources to help form glossariesand privacy rules.

Once the CPT defines a founda-tional set of rules, it should assign arating to each rule indicating whetherbreaking the rule is severe enough toprevent the product or service fromshipping. This severity rating willcome in handy when a team facedwith a deadline wants to ship a prod-uct or service that breaks a privacyrule. If breaking the rule could resultin litigation or have a severe and last-ing negative impact on customer per-ception, it should be considered a“ship-stopper.” Severity ratings helpdevelopment teams understand earlyon the impact of breaking privacyrules and give the CPT a much morepowerful platform for arguing againstshipping the product.

Define the processAfter documenting the program’sdefinitions and rules, the CPT’s nextstep is to determine how to widelyand efficiently deploy and enforcethem. The process should be easy for

development teams to follow with-out demanding too much of theirtime. It should also allow the CPT toscale, so that it can touch all productsand services, yet focus on those thatcan benefit most from its expertise.

The CPT should first prioritizedevelopment projects based on theirprivacy risk. For example, projectsthat plan to transfer sensitive personalinformation, such as credit-cardnumbers from customers’ machines,would have higher risk than projectsthat don’t. To efficiently prioritizeprojects, the CPT should develop aself-assessment checklist consisting ofquestions that identify which pro-jects the development team shouldassess as high, moderate, or no identi-fied privacy risk. Assessment ques-tions should be pointed and provideguidance—most developers com-pleting the assessment won’t be pri-vacy experts. For example, thedevelopment team might not intu-itively know that something as smallas a single transfer of an IP address tothe Internet could have privacy im-plications. So asking, “Will your pro-ject transfer any data, such as an IPaddress, from the customer to the In-ternet?” instead of “Will your project

transfer data?” will yield more accu-rate self-assessment results.

The CPT can use the self-assessment results to streamline thereview process. As risk grows, soshould the amount of effort requiredto complete the privacy process.Projects with high privacy risksshould have CPT members assignedto assist the development team byidentifying potential privacy pitfallsand opportunities early in the designphase, answer questions and providefeedback throughout development,and approve the final product designand customer experience. A projectwith low to moderate risk can be“self-serve” such that, with propertraining, the development team canperform its own analysis, limitingCPT participation to auditing theresults. In all cases, to ensure consis-tency and readability, the CPTshould author the final privacy dis-closures. The process should alsoconsider the steps required for re-solving privacy concerns that mightbe raised after shipping the product.

Deploy the processDeploying the process requires thatthe privacy collateral the CPT devel-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 73

Basic Training

ops be in an easily accessible location,and that CPT members are ready tobegin working with developmentteams. If resources allow, and there’swidespread buy-in to the program,the process can be deployed acrossthe company. If not, the companycan deploy the program within ahigh-risk group and then roll it outto other groups using the initial re-sults to gain broader buy-in.

Project teams should designateone developer per project as the pri-vacy liaison who works closely withan assigned CPT member to ensurethat the process’s requirements aremet and the privacy requirements arebuilt into the project. The privacycontact doesn’t need to be dedicatedto privacy issues, but must be ac-countable for delivering privacy re-quirements. The privacy contactshould also be responsible for helpingto resolve any privacy issues that ariseafter the product or service ships.Training designated privacy contactswithin development teams helps theCPT scale as it takes on more projects.

In implementing the process, theCPT must recognize each project’sbusiness objectives so that it can col-laboratively work with the projectteam early in the design phase to bal-

ance business objectives, customerusability needs, and potential privacyimpacts. Although many productsmight need to collect data, the CPTand the privacy process can act as areminder to build into the projectthe appropriate customer consent,control, and access mechanisms,minimize the amount of data col-lected, and limit data retention. TheCPT can also act as a valuable con-tact for product planning as a trustedresource for designing products thatprovide more robust privacy con-trols than the competition.

Drive incrementalimprovementsThe CPT’s work doesn’t end withdeploying the process. Privacy col-lateral must be continually updatedand improved based on changinglaws and technologies, as well as newbusiness strategies. The CPT shouldmeet regularly to discuss issues thataren’t covered in the current collat-eral; the agenda should includebuilding consensus on new rules andguidance, and updating the com-pany’s privacy rules, if necessary.

The CPT should also considerbuilding and maintaining strong ties inthe broader privacy community; con-

tributing to standards working groupslets the CPT provide its perspectivesand consider those of others. More-over, such efforts will help establishthe company as a privacy leader.

Building a robust training curricu-lum is also greatly beneficial. TheCPT should teach the privacy pro-gram’s basic concepts and objectivesacross the company, with targeted,scenario-based training made avail-able to project development teamsthat need it. Based on its experience inresolving privacy challenges withinproject reviews, as well as after prod-ucts have shipped, the CPT will beuniquely qualified to provide training.

T o respond to the increasing de-mand for software products and

services that respect customers’ pri-vacy, companies must build andmaintain a robust framework of pri-vacy guidance and collateral that isintegrated into the developmentprocess. Designating a CPT to craft,deploy, and maintain a scalable pri-vacy program not only helps ensurethat products won’t commit well-known privacy pitfalls but also posi-tions a company to create productsthat are differentiated from theircompetitors in helping protect cus-tomer privacy.

Tina R. Knutson is a senior privacy pro-gram manager in the Corporate PrivacyGroup at Microsoft. She is the coauthorof Privacy Guidelines for DevelopingSoftware Products and Services (http://go.microsoft.com/fwlink/?LinkID=75045,2006) and a Certified International Pri-vacy Professional (CIPP). Contact her attina.knutson@microsoft.com.

74 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

For our readers

Do you have real-world privacy

lessons learned during software

implementation? Have you ever

retrofitted a privacy policy to a

shipping product? Tell us about

your experiences. Send your stories

to Richard Ford at rford@se.fit.edu.

Additional privacy resources

The following resources provide guidance

and information to help you form glos-

saries and privacy guidelines:

• Privacy Guidelines for Developing Software

Products and Services (http://go.microsoft.

com/fwlink/?LinkID=75045). This set of

guidelines is based on Microsoft’s internal

guidelines and experience incorporating pri-

vacy into the development process.

• Privacy: What Developers and IT Professionals

Should Know (Addison-Wesley, 2005). Mi-

crosoft privacy expert J.C. Cannon covers the

technical and organization facets of protect-

ing customer privacy. Cannon shows you

how to systematically build privacy into any

application, Web site, or enterprise system.

• Electronic Privacy Information Center (EPIC;

www.epic.org/privacy/). EPIC is a public-

interest research center established in 1994 to

focus public attention on emerging civil liber-

ties issues in the US and to protect privacy, the

First Amendment, and constitutional values.

• Anti-Spyware Coalition (ASC; www.antispy

warecoalition.org). ASC is a group of software

companies, academics, and consumer groups

dedicated to building a consensus about defi-

nitions and best practices in the debate sur-

rounding spyware and other potentially

unwanted technologies.

• TRUSTe (www.truste.org). TRUSTe certifies

and monitors Web sites’ privacy and email

policies and resolves thousands of consumer

privacy problems every year.