Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

June 28, 2002

Making Your Privacy Policy Work

With the right planning, analytic infrastructure can be surprisingly effective in enabling your privacy policy

by Mark Madsen

Continued from Page 1

The next part of the evaluation is to match this information to your current business practices. Which of them make use of the data you're trying to control? Determining the answer may require a cursory review of the business, or it may mean lengthy interviews with management in various departments.

Tracing Information Flow

Sometimes matching the policy to business practices can be too difficult. It may be easier to learn about business practices by tracing the data you care about as it flows from the systems where that data is collected through all the associated applications in the company. This approach will quickly highlight the scope of your effort. Expect to discover a number of departments and applications that use personal data in unexpected ways.

For example, one of our client's privacy policies stated that no data collected online would be shared outside the firm. We discovered that clickstream data was used to build behavior profiles for internal use. This wasn't a violation of the policy, but one group combined the online profile with data from the offline customer database and fed that data into a campaign management system. This still wasn't a problem. However, the campaign management system was also used by another group within marketing to rent out customer profile and address lists. Because the online data was combined into the customer profiles, the company was violating its stated policy.

When it comes to Web-based data, these problems are common. In large part, that's because the IT group that manages Web applications and data is usually separate from the rest of the IT organization. Firms that integrated clickstream data with existing data warehouses are generally in better shape, because in these cases the data all flows to a single place where it's used or disseminated to the rest of the organization or outside entities.

The Scope of the Problem

After you've listed the business processes that use affected data and traced the flow of that data through your systems, the next step is to determine what applications might be affected by the privacy policy.

Knowing the important data and the systems through which it flows is the first step in determining the impact of integrating a privacy policy with your data warehousing infrastructure. At this stage, examine systems based on key aspects of the policy. For this purpose, you can divide the requirements of a privacy policy into four parts and determine which of the systems you identified earlier are going to require changes:

Data collection affects not only the systems where user data is entered but also analytic applications that enhance or integrate user data. If the policy says you don't collect demographic data, integrating the directly collected data with an offline demographic data source may not be permitted.

Data collection opens up a set of interesting questions. For example, is there a distinction between an identified and an anonymous user, and does making the data anonymous mean that the policy doesn't apply? What happens if through a transaction, such as a purchase, you now learn the user's identity?

The scope of data collection issues can range into third-party providers of site functionality. Some ad networks profile users targeted through a Web site. If you have banner ads on your site, who owns the data the ad network gathers about your users based on ads served to your site?

Data retention likely affects every system through which user data flows. Your primary concern is likely to be limiting how long data is held. This isn't always simple because online backup and archival policies may supercede the privacy policy. In these cases, one of the policies usually requires a change.

Data use is less straightforward. Depending on how the policy is written, you may be allowed to do anything that isn't specifically excluded. Rating system compliance is then a simple matter of ensuring that it doesn't perform any excluded actions. If the policy lists what you do now as the total set of uses with no option for future use, then it can prohibit you from doing anything new without a policy change. This should be cleared up in the policy rather than trying to police every one of your systems.

Sometimes even simple business practices can be precluded. For example, outsourcing is a common practice. The data-sharing clause of the privacy policy may state that no personal data will be shared with third parties without a user's consent. If you use an outsourcer to handle your email marketing, some of the users' personal data must be shared with this company, even though it may not retain the data when processing is complete.

Sending this data from the data warehouse to the partner could be violating your privacy policy. Depending on the contract's specifics, you may find that the data you were supposed to manage is no longer under your control. The biggest problem is that the user typically has no legal recourse against the third party, but may have legal recourse against your firm for violating the policy.

Even more problematic may be outsourcing Web analytics. In this case, all the data is processed and managed by a third party that provides information back to your company. These services usually utilize mechanisms that send data directly to them rather than via your Web site's logs, so which privacy policy is legally in force?

When data use is involved, you have to follow the data to every place it's used and see what the implications might be.

Data sharing is the most contentious area because it's where most of the perceived abuses occur and is, therefore, the target of most legislation. It's also a highly ambiguous process. The questions start with the scope of sharing: Is there a problem sharing data internally across departments? How about across divisions within the company? Within a related family of companies? Are outsourced services included?

Some of the biggest privacy conflicts stem from user profiles and data sharing. Because many Web sites are free to users, they support themselves by selling targeted advertising whenever possible, and advertising can only be truly targeted if personal data is obtained by the site and then shared with advertisers.

Similarly, in order to enjoy personalized services, users must provide information about themselves. There's no conflict if that data is only used for personalization, but if the Web site shares this personal data with any third parties, there will be conflicting priorities. Users may want the convenience of personalization, but they may not want to pay the price of their online privacy for this convenience.

Even simple user profiling, such as referring site information, can create problems. For example, if users visit medical sites before visiting your site, you may be able to infer something about their health. If you were to add this to their profile, you might unintentionally expose the company to privacy legislation.

If your company's interest in a privacy policy is driven by legal requirements such as HIPAA, then an entirely separate set of decision criteria will apply. For example, HIPAA specifies that personal health data may only be used for specific treatment, healthcare, and payment purposes. This obviously applies to any company dealing with patients, whether a hospital or an insurance company. Less obvious is that HIPAA's data privacy rules can apply in any industry to any company that provides a health benefit plan to its employees and manages that plan via an internal system.

Your best bet in this case is to look for help from qualified consultants who perform privacy and compliance audits. You'll want consultants who specialize in the law's specific requirements and who can provide a legal review of both policies and how you're implementing them in your systems.

Implementing a Privacy Solution

At this point in the process you should have a good grasp of which business processes and systems are affected, and how they're affected. The final task is to determine what to do about these systems and processes.

The first, and probably simplest, step is to decide whether the privacy policy should be revised. Often, a few simple revisions will save considerable development time and internal procedure changes. You should be careful to make sure that the revisions aren't pushed too far, creating a sham of a policy that does nothing for users. There are plenty of examples available of privacy policy changes just like this. In legal cases, as with HIPAA, changing the policy may not be an option.

Only after revising the privacy policy and communicating it to all of the affected parties should you worry about whether any applications need modifications, and whether you need to revise any business processes.

Rate This Article

Comments:

Optional e-mail address:

In general, there will be technical and nontechnical elements to the work. The latter includes defining internal policies and processes for using, storing, accessing, and sharing data. Implementing data security practices is often a component of integrating the privacy policy into your operations.

On the technical side, you may need to make database or application changes, limit internal access to applications, or add features to your systems. For example, does your privacy policy offer an opt-out clause allowing users to prevent data from being shared? If so, you'll need a mechanism to allow them to opt-out. But that's just the beginning. The opt-out must follow the user data through all of your internal systems, which may mean changes to business rules in many applications.

Finally, you should define an audit process that specifies the frequency with which you'll review the privacy policy and internal operations, how you'll measure and monitor compliance, and who signs off on the results.

Because privacy policies can be binding contracts, the statements made about the collection and use of user data should be built into the business processes and applications. A solid data warehousing architecture makes this work easier by forming the foundation for the collection of user data, and integrating the disparate clickstream, user contact, and CRM data and processes.

Mark Madsen [mmadsen@clickstreamdatawarehousing.com] is an award-winning IT architect who has been working in the data warehouse field for 10 years. He is one of the principal authors of the new book, Clickstream Data Warehousing (Wiley, 2002). For more information, visit the book Web site at www.clickstreamdatawarehousing.com.