Figure 1: The Essential Elements of Information Privacy
Legal and regulatory environments, quite rightly, are of utmost concern to privacy professionals because they shape the debate about what companies and individuals must do to ensure compliance. Law also drives many administrative decisions about how to implement processes that protect customer information, insure proper governance and guard the corporate brand.
The final side in this triad is the technology that puts privacy and security into action. The technology can be as diverse as programs, storage, transmission protocols, and access controls. One of the most important technical considerations is the way that sensitive information is modeled, stored, and archived in enterprise databases. This is an area that offers many opportunities for both intentional and accidental breach of law and procedure.
One of the greatest challenges at the data level is that most companies developed and implemented large numbers of databases before there was a common understanding of what privacy requires. At most companies, privacy controls have been retrofitted or added-on to these databases without a fundamental rethinking of the overall requirements.
In most companies, sensitive customer data is spread across many departmental databases such as those in marketing, sales, finance, order processing and service. In government organizations, sensitive data may reside in multiple databases, in many departments, within diverse agencies. Integrating, storing and archiving this information can be a never-ending technical challenge.
A strategic question for many companies is how and where to store sensitive information and the privacy preferences that determine how it may be used. In practical terms, however, these two kinds of information are very different. A privacy profile may be required to determine how to access sensitive information, but is not, in itself, particularly sensitive. A customer's telephone and credit card numbers are highly sensitive and must be carefully protected. The fact that he or she does not wish to be contacted at home by telephone is much less sensitive because it is much less useful to another party. Steal a person's Social Security number and you have the keys to the financial kingdom; steal a privacy profile and you experience only a slight frisson of naughtiness.
One key idea in privacy modeling is a "privacy profile of record" that consolidates customer preferences, codifies company responsibilities, and can be shared as required across various databases. Defining such a standard can be difficult. In the U.S., for example, the sectoral approach to privacy has meant that companies think about this issue in terms of communications through a specific channel (telephone, direct mail, retail store, etc.), to a certain demographic (age, geography, citizenship, etc.), at a specific time (point of sale, before 8 pm, when a contract term expires, etc.), for a specific product or service (credit card, pharmaceutical, toy, etc.). Each of these dimensions may be regulated separately and be supported by a unique company database. Taking a holistic view of privacy goes against years of corporate practice.
Database professionals often use an approach called dimensional modeling to develop analytical databases (for data warehouses, decision support systems, business intelligence, etc.). The following discussion uses this modeling terminology to look at some key decisions in implementing a privacy sensitive data model. Throughout this article, we will consider a marketing database as an example of such a model. Other corporate databases have different design centers and functionality, but most of the following considerations remain relevant.
Figure 2 illustrates some of the common security and privacy issues in any customer communication in a marketing context.
Figure 2: Common Database Privacy Issues
At a fundamental level, privacy concerns inbound and outbound communications between a company and a current or prospective customer. Inbound communications from a customer (or data subject) may involve many things. One of these may well be a requested change to the customer's privacy preferences. In light of current privacy laws, these changes must be made quickly, and in most cases, they must be confirmed to the customer.
Outbound communications, on the other hand, must check known privacy preferences to ensure compliance with the data subject's wishes. Inbound and outbound communications are often related (an inbound customer response to an outbound marketing offer, for example) as the diagram illustrates. Companies often think about checking a customer's privacy profile before sending an outbound communication. However, they less frequently scan inbound communications to check for any customer changes to his or her privacy preference.
Checking for permission to send an outbound message is not all that must be done. Security is also an issue. Many customers (both individuals and companies) have preferences or requirements about the method of communication. This is not simply a matter of accepting communications by email but not telephone; it also involves the message protocol. Is it encrypted or clear text? Can the message be sent to a work address? Is a return receipt permissible? Can it be sent to a mobile telephone? Privacy preference and security configuration go hand-in-hand in most customer communications.
At the database level, privacy and security are not simple entities or lists of facts. Figure 3 illustrates some of the typical dimensions of a privacy profile.
Figure 3: Typical Dimensions of a Privacy Profile
At the bottom of the diagram are the obvious aspects of privacy: the customer's preferences, the date and time they were captured and last updated, and compliance information that must be compiled for corporate and legal governance reports. Moving up the diagram illustrates some of the growing complexity of managing privacy information.
