Developing Privacy Engineering Requirements

Abstract

The expectations of life depend upon diligence; the mechanic that would perfect his work must first sharpen his tools.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

The expectations of life depend upon diligence; the mechanic that would perfect his work must first sharpen his tools.

—Confucius

I should live my life on bended knee; If I can’t control my destiny. You’ve gotta have a scheme; You’ve gotta have a plan.In the world of today, for tomorrow’s man.

—David Bowie, “No Control”

This chapter begins with a discussion on the topic of requirements gathering. If a business or other enterprise is required to be responsible for personally identifiable information, it’ll need to develop strong policies for managing that responsibility, and the entire process begins with determining the crucial requirements for internal and external policy development.

Requirements engineering use cases that leverage an industry-recognized approach will be introduced and applied to personal information (PI) and other data related to it. The data protection-driven fair processing principles will be leveraged to determine requirements, and a use-case metadata model that is unique to privacy engineering will be introduced.

Third-party service providers and unique distribution channels (such as cloud computing or mobile technology) for personally identifiable information can impact the engineered privacy solution. One should anticipate tumult, digital earthquakes, and continental shifts in the data protection landscape over time and build accordingly. The value in the methodology that is proposed in this chapter is in its inherent flexibility. The tools themselves are flexible as well so that, for example, if the privacy component is developed, it could be plugged into numerous applications so that any privacy rule changes will be reflected in all applications invoking the privacy component.

This chapter introduces three scenarios to be used throughout the book to illustrate the tools, techniques, methodologies, and sometime pitfalls of the requirements-driven privacy engineering discipline. The requirements use case-driven models to illustrate how a privacy framework may be fitted to a known system’s development model to suggest a privacy-driven solution.

Three Example Scenarios

These use-case examples (each explained in detail in Chapters 7, 8, and 9, respectively) should be considered expository workshops rather than a definitive formula that would extend to every data protection context. Different scenarios may require different use cases, and different use cases and policies may require components with different functionality. Nonetheless, the methodology defined in this book is designed to work in all circumstances.

Example Scenario 1: The Privacy Component

Example scenario 1 will show how a privacy management team can develop or acquire a software privacy component (mechanism or tool) that supports and maintains the privacy rules derived from the privacy policies developed to meet the requirements of the enterprise and the people impacted by the enterprise systems. (See Chapter 4 for privacy policy and notice requirements.)

The resultant privacy component can be used independently or invoked by enterprise applications where privacy rules need to be enabled. This example scenario will be discussed in more detail in Chapter 7. The implications and a few potential benefits of an interoperable privacy component will be further explored in Chapter 14 that imagines “A Vision of the Future.”

Example Scenario 2: A Runner’s App

Example scenario 2 will present a mobile application for which we developed a use case with Traver Clifford (grandson and nephew to two of the three manifesto authors). Traver was 17 years old and participating in an app development internship. He is one of the first to be trained and recruited as a young privacy engineer and to leverage the privacy engineering methodology. He was also a member of a high school cross-country team and we used his interest area for a case study. The runner’s app invokes a simplified privacy component that may be used for mobile and smaller enterprise feature development. The runner’s app will be discussed in more detail in Chapter 8.

Example Scenario 3: Hospitality Vacation Planner

Example scenario 3 will assume that the privacy component has been developed, tested, and implemented. A large hospitality company required a system to help its customer community plan a vacation at one of their hospitality sites. The system supported both a telephone call center and a web site. The privacy component was invoked by this new system to ensure that privacy policies were enforced. Further, the hospitality vacation planner example shows the privacy requirements and fair information privacy principles as they operate as functional requirement specifications and quality control measures. This example scenario will be discussed in detail in Chapter 9.

Privacy Requirements Engineering

To link the existing landscape of privacy—people, process, and technology—techniques as they exist today with the innovations that are required to manage privacy requirements of an increasingly complex world, we start by reexamining privacy policy creation as a means of requirements gathering as well as a basis for rules setting. The next step is to put those requirements into a dynamic creative cycle, as presented in Figure 5-1.

Figure 5-1.

Requirements within the privacy engineering development structure

Requirements engineering is the process of determining user needs or expectations for a new or modified solution. A solution in this context can be considered as broad as an enterprise-wide processing system architecture or as small as the addition of a new capability into one small and dedicated process. These features, called requirements, must be quantifiable, relevant, and detailed. In software engineering, such requirements are often called functional specifications.

For privacy engineers, requirements gathering and development can follow the same development path as for other functional specifications, with a twist. The art of privacy policy creation for the enterprise or for the government affairs professional is often stated in aspirational or behavioral terms: reasonable, proportional, no harm options and choices. Here, policy serves as a critical requirements-gathering source or end state upon which to draw certain functional requirements.

The policy must be explored and deconstructed to look for action words and decision trees that lead to the desired outcome. For example, a typical privacy policy may begin with the sentence “Company X respects your desire for privacy and so herein follows the way Company X will manage the personal information that it collects.” Out of this very first seemingly boilerplate or throwaway sentence arises certain possibilities for the makers, owners, or users of systems. Some such systems requirement possibilities are:

• Company X requires certain accountability or measurement or testing to determine that it is providing information protection.

• Company X requires processes to collect information.

• Company X requires collection or awareness mechanisms regarding the desires of its users with respect to data processing in order to judge how to balance protection or collection against this desire.

• Company X requires data management processes.

• Company X requires a granular definition regarding who within Company X and its partners, affiliates, and vendors will carry the ultimate task of managing these requirements throughout the expected lifecycle of any data collected. In other words, Company X requires a specific “who” to manage now granulized “what” assets that will flow through “how” systems.

So, with the very first sentence of a public-facing policy, taking a requirements approach begins to turn nonsystems, noncomponent, nongovernance seeming legalese into functional requirements that may be implemented in a people-, process-, and technology-driven systematic fashion. The privacy engineer is a distinct practitioner because he or she may indeed be teaching the policy teams about the impact of their craft as much as they dictate aspirational requirements to them. Pretty cool stuff.

Requirements engineering involves frequent communication with system users to:

• Determine specific feature expectations

• Resolve conflict or ambiguity in requirements, as demanded by the various users or groups of users

• Avoid feature creep

• Document all aspects of the project development process from start to finish

Energy should be directed toward ensuring that the final system or product conforms to the client’s needs rather than attempting to mold user expectations to fit the requirements.

Privacy Requirements Engineering

Historically, in many organizations, requirements for systems to process personal information were set by inherent limitations, such as technical systems limitations or the lack of configurable features across applications or systems. Any data were forced to fit a system or series of systems rather than the systems adapting to reflect the user’s and management’s actual desired requirements for a task or use case.

The exponential rate of systems’ capabilities and choices that have been developed in recent years can allow the privacy engineer to flip that equation and lead with person requirements first, data second, and technical limitations third in priority for design.¹ The evolution, or indeed revolution, of data-centric and person-centric processing vs. machine-limited data-processing design potentially creates a rich and creative environment for innovation and downstream economic benefits based on new business models. In fact, a person-centric design may be a way forward beyond the buying or selling of ads or other content-independent schemas to create “value” from new algorithms and person-first services.

Additionally, many hours of frustrating double talk have transpired where a legal team member asks a development team to ensure that there are “reasonable” controls included in the system before it can launch, only for both teams to discover that neither had the foggiest idea what was really expected from the other, another oft-occurring potential pitfall. If nothing else, privacy engineering models and techniques should provide an earlier and more productive conversation starter (or finisher). The launch party for new business models and systems may even enjoy a mutual clink of the glass for the legal, design, technical, customer advocacy, compliance, risk, and other business teams—the mind reels at the remote possibilities. “Legal” becoming a friendlier term for the enterprise is, unfortunately, beyond the scope of this book.

Thus, requirements engineering must be considered a team effort that demands a combination of hardware, software, human factors, privacy knowledge, and system design engineering expertise as well as skills in interpreting and communicating with other people with differing perspectives and lexicography.

Use Cases: A Tool for Requirements Gathering

One form of requirements documentation is called a use case, ² which is a complete course of events initiated by a primary actor. Actors may be people, functional roles, or interfacing systems that interact with the enterprise (or system) under study. One or more use cases are developed for each actor to allow for scenario development and testing under different conditions. There are two levels of use cases: Business use cases describe the business process, and system use cases describe the interaction of one or more actors and the system to be developed.

Use cases are valuable to allow business personnel and technical creation teams to define and refine requirements in terms that are understood by all stakeholders. (At a large telecommunications company, we taught the businesspeople to write use cases and thus the use cases were understandable to both other businesspeople and the IT development team with few questions.) Use cases specify the interaction that takes place between the actor and a business process³ (whether automated or not).

The use-cases technique is designed to capture user needs early and fast. Enterprise requirements are captured in a form both businesspeople and developers find engaging. They can also serve as a chain of evidence from requirements to value delivered and are useful in consensus building, training, and quality testing, as discussed in Chapter 10.

Use Cases within Privacy Engineering

Another added benefit of employing use cases to add to the privacy engineering methodology is that management teams and developers can readily understand them and, in fact, have more than likely created use cases in other contexts. Here, we apply privacy requirements to this type of systems’ engineering lifecycle methodology.

In addition to creating a cohesive design plan with integrated requirements, use cases can also be used to start to understand how system interfaces actually function and perhaps how a “feature” may act as a bug in practice to introduce unwanted risk or faulty controls according to the privacy policy requirements based on FIPPS/ISO or other relevant standards.

It should be noted that the development of use cases in this context also acts to lower the probability that bad data risk will have significant overall impact. Employing use cases allows the design team to role play potential risk and value scenarios and test various game theories to create policy requirements, education, and processes, thus avoiding another pitfall. Here, the expected people, process, or technology running within the use case should reveal where the anticipated design or feature leaves a gap or creates an unexpected value. Regulators will also be looking for documented scenario testing or gaming to determine where risks are contemplated and planned before data collection and processing. [A UK example: Fines pursuant to breaches found by the ICO⁴ where no scenario testing or game play was undertaken by the data controller.]

Privacy Requirements Derived from Privacy Frameworks

In Chapters 2 and 3, we explained how the privacy frameworks provide guidance as to which privacy requirements should be included in the requirements statements, be they in a use case, in the user-experience definition, or in the data-model metadata. The following outline provides some privacy requirements to be considered:

• Purpose: Collect and process for purposes that are relevant to the services being provided. PI must not be collected or used for purposes that are materially different from the original purpose for which the data were provided:

  • What purposes do the PI data perform?

  • Does each data attribute, related to personal information, have a direct relationship to the purpose for which it was collected and processed?

  • What privacy rules are needed to ensure that the purpose principle is satisfied? Are there other metadata that support the purpose principle?

  • Is there a chance that a data subject, whether an individual or an enterprise, would be embarrassed or damaged by the processing or publication of the personal data?

• Notice: System creators, owners, and fiduciaries must explain to users how their information will be used, collected, protected, retained, kept accurate, accessed, corrected, or otherwise processed before any processing occurs:

  • Does the requirements statement define a complete notice that satisfies the notice principle?

  • Is the intended processing included in the notice (some types of processing may require supplemental or just-in-time notices)?

  • How and when will the notices be presented to the user (and how or if will the user need to acknowledge or accept these notices)?

  • Are there statutory or common law requirements concerning notice in all jurisdictions wherever the system impacts?

  • Is the notice clear, consistent, relevant, and current?

  • Can innovative presentation techniques be used to explain the notice requirements in a way that encourages review and facilitates understanding (for instance, would animation or a pop-up video make the notice more appealing and clearer)?

• Choice/consent: Data subjects must consent to the collection and use of their personal information:

  • Choices must be shown clearly.

  • Choices must not be easily bypassed or ignored.

  • Defaults most be explained clearly.

  • Prechecked boxes should be avoided.

  • Defaults should be set to either lessen the sharing of PI or that default must be so clearly tied to the notice and the context so that the only reasonable expectation any user would have would be that the information is shared (a form of implied or informed consent).

  • Tools for the privacy engineer regarding choice should be considered during all phases of the data lifecycle of PI so that choices made by the data subject may be recorded, audited, and corrected along the way.

  • Limit the types of data allowed to be collected and segmenting more sensitive PI (or disassociating identifying attributes from aggregate data) are technical, managerial, as well as policy and legal decisions.

• Transfer : Data should not be transferred to third parties for their own use without the data subject’s permission:

  • Data transferred to and from a third party must be “adequately protected” by contract, administrative, technical, logical, and physical means.

  • The transfer of data to different geographic areas, such as member-states of the European Union, may require an additional legal mechanism (such as Safe Harbor Certification or Model Contracts) to make the transfer legitimate.

  • PI should not be transferred to third parties without the proper procedures included as part of the overall architecture. Are the proper procedures in place for all types of third-party transfers and all impacted jurisdiction?

  • No PI should be transferred to a third party or geographic area without appropriate agreements and approved security provisions that detail how the data will be processed and how they will protected. As part of vendor management and the sourcing or procurement process, ensure third parties are vetted from a privacy and security controls perspective before data feeds are enabled.

  • Encryption and obfuscation techniques are the obvious tools to leverage when a system owner wishes to prevent an attack of data in motion.

• Access, correction, deletion: Data subjects must have a means of accessing the personal information that has been collected about them. They also are entitled to delete or amend false or inaccurate data:

  • Can data be segmented (group together) so that different segments can be handled with different privacy, encryption, or security rules?

  • Can roles be defined so that privacy risks can be managed by means of privacy rules?

  • Are rules concerning correction and deletion in compliance with the laws or regulations of all jurisdictions impacted by the system or process or by the enterprise policies?

  • Although there is currently heavy debate over proposals to include a yet to be defined “right to be forgotten,” a right of deletion is not absolute as of this date. (We will approach this subject again in Chapter 14 in our discussion of how the future may look on a broad scale.⁵) For the privacy engineer, engineering tactics that allow for search and removal of common media such as photos or video and some ability to add metadata would be a wise addition as this debate widens.

• Security: Use appropriate technical, logical, and administrative measures to ensure only authorized access and use of data:

  • Do you leverage ISO and other standards for information and physical security (see ISO framework as discussed in Chapter 3) and work with information security teams within your enterprise?

  • Are the security and encryption rules defined for each data attribute?

  • Are security rules covered for data transfers, especially across jurisdictional lines?

• Minimization : Collect and process the minimum necessary data to achieve the identified, legitimate intended purposes. The minimization principle is closely related to the purpose limitation requirement where only the necessary PI is collected and processed to achieve a legitimate purpose:

  • For each piece of personal information data being collected, the following statement must be true: Without X data attribute, I cannot do Y legitimate task and I need no less than X to do Y. Is each personal information data attribute being collected needed to accomplish the solution being designed or is it being collected “just in case”?

  • If data are being collected for potential big data purposes, can big data analysis be used to identify a person, thus raising a potential privacy issue?

• Proportionality : Data collection should be legitimately proportional to need, purpose, and sensitivity of data. This requirement can be one-step further abstracted to connect those data to quality and value:

  • As with minimization and purpose, can collection be limited wherever possible to only what is required?

  • Think in terms of a Venn diagram that parses the proposed data, asking what is the minimum data needed that is proportional to the purpose intended?

  • Is the amount of data and the character of data itself proportional to the purpose, the sensitivity of the data, or the risk to a data subject should it be compromised?

  • Do the data subject and data fiduciaries keep a common perspective where risk and value are balanced? The following formula for proper weight of data comparison may be considered for overall data protection and governance efforts, but it also fits well into the discussion regarding proportionate collection and use, where Data Value (DV) > Data Risk (DR) = Success.

• Retention : Retain data only as long as they are required:

  • Are archiving rules for each data attribute well established?

  • Instead of determining how long data can be kept, determine how soon (in whole or in part) it can be deleted and act accordingly; wherever possible, define controls to automate deletion. If this is not feasible from a business or technical perspective, have data inventory review and deletion processes been created (archiving rules)?

  • Have data destruction tactics such as degaussing, permanently encrypting, and destroying keys or overwriting data after specific deadline been considered?

• Act responsibly : Put a privacy program in place:

  • Is the privacy team included on the project team?

  • Has a privacy-oriented data governance or data stewardship program been established?

DEFINING PRIVACY REQUIREMENTS IN AN EVER-CHANGING WORLD

By Peggy Eisenhauer, Founder of Privacy & Information Management Services—Margaret P. Eisenhauer, P.C.

In 2008, my son received a fun game, Fluxx, for his birthday.⁶ Fluxx calls itself “The Card Game with Ever-Changing Rules!” It could also call itself “The Card Game that Provides a Perfect Metaphor for Privacy Requirements!”

Fluxx game play is quite simple. There are four kinds of cards: Actions, Rules, Keepers, and Goal. The Basic Rule says that, on each turn, you draw one card from the deck and play one card. To win, you collect the Keepers and meet the requirements of the Goal.

The twist with Fluxx is that everything can change while you’re playing. Players take Actions, such as stealing a Keeper. Players change the Rules. Instead of draw 1, you have to draw 3. Or play all the cards in your hand. One possible Rule prevents you from winning unless you meet the Goal and have the Radioactive Potato card. Some of the Actions change the Rules. For example, one Action card lets you “Trash a Rule.” Any player can change the Goal as well. Instead of needing the “Milk” and “Cookies” Keepers, now you need the “Rocket” and the “Moon.” And nonplayers can join game at any time by picking up three cards from the top of the deck.

The ever-changing nature of Fluxx illustrates the challenges that we face in defining privacy requirements. When setting privacy requirements, we consider the data elements and proposed processing activities and establish rules to address four sets of mandates: (1) specific legal requirements for privacy and security, (2) requirements driven by internal policies, (3) requirements driven by industry standards, and (4) requirements that likely exist as a matter of stakeholder expectations for appropriate processing. At a particular point in time, the first three types of requirements can be objectively known. The fourth type of requirement (addressing consumer and regulator expectations for appropriate use) is subjective. For example, consumers generally feel that processing to prevent fraud is appropriate, but they disagree as to whether it is appropriate for companies to scan all the data off their driver’s licenses in connection with a retail product return. Nonetheless, privacy professionals can collaborate with their product design teams to document a solid set of privacy requirements for any proposed activity.

As is always the case with requirements engineering, however, the requirements change over time. This is especially true for privacy requirements, due to the rapid evolution of legal standards and industry codes, mercurial consumer and regulatory views about privacy, and the dynamic nature of internal policies (which have to keep up to date with at least the laws). Privacy requirements are also challenged by changes within the business itself. Within any given company:

Business objectives constantly evolve, creating new goals. Companies want to wring every last ounce of value from their data, leading to new uses for existing databases, novel types of analytics and business intelligence processes, and increasing pressure to leverage customer or consumer data assets to benefit partners and create incremental revenue streams.

Business requirements evolve, requiring new rules. Companies move from controlled technology deployment to BYOD (bring your own device) programs. Customer and consumers are increasingly empowered to engage via social media platforms and mobile apps.

Routine actions have consequences. Companies outsource, requiring new rules for vendor management and data transfers. They enhance data and create inferred data, pushing the boundaries of what may be considered appropriate by consumers and requiring new rules for notice, choice, and access. Companies have security breaches. Even the actions of other entities can have consequences, as we know from revelations about government programs that demand access to consumer data.

Privacy professionals and product designers also need to recognize that some business attributes hinder achievement of some privacy objectives, and even privacy objectives sometimes compete. Let’s consider a real-life scenario: a company may be committed to providing more transparency, but this may trigger an expectation that consumers will have additional choice. For example, the company may disclose that it is using cookies to recognize consumers’ devices, but consumers will then want the ability to opt out of having the cookies placed. However, providing additional choice may make it more difficult to meet security requirements, for instance, if the cookies are used as part of a multifactor authentication process.

Additionally, as in Fluxx, the actions of various stakeholders (and the orders of actions) are not predictable. Nonplayers (such as regulators) routinely take actions that affect the business. Nonplayers (especially regulators) can also change the rules. It is thus critical to have a deep understanding of not only the legal requirements for data processing but also the more subjective opinions about appropriateness of the processing held by the myriad stakeholders: employees, consumers, industry groups, regulators. Because the rules are rapidly changing, companies must anticipate new requirements so they can implement new rules effectively and efficiently.

Consider, for example, the legal requirements for collecting children’s data. The “Basic Rule” in the United States under the Children’s Online Privacy Protection Act (COPPA) required verifiable parental consent in order to collect personal information from children under 13 years old via a commercial web site. COPPA regulated web sites that targeted kids as well as general interest web sites, if the site operators knew that kids were submitting personal information. Although COPPA was one of the most effective (and enforced) privacy laws, concerns persisted about the collection of personal information from children. These concerns intensified when studies revealed that web sites targeting children were collecting vast amounts of data via passive technologies, such as cookies, without triggering COPPA requirements.

In 2012, the Federal Trade Commission revised COPPA rules to add new requirements. The new rule expands the definition of “personal information” to include persistent identifiers, device IDs, geolocation data, and images. It also expands the definition of “website or online service directed to children” to clarify that a plug-in or ad network is covered by the Rule when it knows or has reason to know that it is collecting personal information through a child-directed web site or online service. All web sites that appeal to children must age-gate users. Companies operating general interest web sites online are now playing a very different game.

Like every great game, Fluxx has expansion packs and variant versions, such as Eco-Fluxx, Zombie Fluxx, and (our personal favorite) Monty Python Fluxx.

Expansion packs for “Privacy Fluxx” should be coming as well. Information security requirements are constantly evolving and becoming more prescriptive. The “InfoSec Monster Mandate Fluxx” will require very specific types of security controls and impose even stricter liability for data breaches. We can see this trend today in jurisdictions such as Russia and South Korea.

“Consumer Protection Fluxx” is already imposing new rules based on evolving concepts of privacy harm. Expect new purpose limitation requirements and “minimum necessary” standards as well as opt-in consent for secondary uses of personal information. Additional limits on the collection, use, and disclosure of personal information based on the nature of the technology used (such as cookies) are also featured in this version.

Companies that operate in a multijurisdictional environment know the challenges associated with “Global Data Protection Fluxx” quite well. These companies will face exponentially greater complexity as they define privacy requirements for systems and processing activities that touch data from multiple countries. These companies must account for all possible local requirements and implement controls to meet the most restrictive requirements. As in the United States, international data protection authorities are focused on data security and consumer protection. International regulators seek to achieve privacy goals by limiting data retention periods and cross-border data transfers.

Develop Privacy Requirement Use Cases

Use cases reflect the requirements of business processes, and business processes are supported by information systems and automated business processes. Figure 5-2 shows a simple set of privacy use cases that could be used to develop a privacy engineering program.

Figure 5-2.

Privacy requirements use cases

These use cases may contain explanatory elements that may be developed into use cases themselves, for instance, to:

• Determine and maintain privacy policies and procedures:

  • Develop privacy policy

  • Develop privacy procedures, standards, and guidelines

  • Design privacy notice

  • Develop archiving rules

• Determine security requirements:

  • Develop authentication rules related to privacy

  • Develop authorization rules related to privacy

• Determine data requirements:

  • Determine proportional PI and related data collection and maintenance requirements

  • Determine privacy processing requirements

  • Developed backup strategy

  • Develop third-party transfer rules

• Develop and build class and data models:

  • Include privacy indicators in the model metadata

  • Include encryption indicator in the model metadata

• Develop privacy component specifications, including:

  • Enter privacy rules

  • Test for authorization rules

  • Present privacy notice

  • Enter opt-in/opt-out rules

  • Allow user to opt in or opt out depending on rules

  • Test for privacy indicator in database metadata

  • Test for encryption indicator in database metadata

  • Test for privacy rules

  • Test or third-party transfer rules

Use cases will usually be used to gather requirements as part of a project system’s engineering development lifecycle. The information gathered as a part of use-case development should be entered into use-case metadata.

USE CASES AS THE UNIVERSAL TRANSLATION TOOL

By Virginia Lee, Senior Attorney, Privacy and Security Legal, Intel Corporation

Engineers and lawyers may be speaking the same language, but you wouldn’t know it when it comes to communicating about privacy. Imperfect communication leads to enmity between the two groups. It is as if they were living on opposing alien planets. Successful communication can be achieved between these seemingly disparate factions. It’s not rocket science, but it may feel as difficult. It comes down to peeling back the jargon and teasing out the essence of what is being communicated.

What are the issues that crop up when engineers and lawyers try to communicate over privacy issues? The first critical impediment to good communication between the two are the perceptions held by each. Engineers have the perception that lawyers only say no. Lawyers believe that engineers don’t really care about privacy. These perceptions are rooted in some truths. There are relentless calls from legislators and regulators about the need for more restrictions around the collection and use of consumers’ data. All of us are bombarded by news articles about how some app developer surreptitiously collected a user’s personal information without any concern as to whether the user would approve. So it is no wonder that there is a disconnect between the two groups.

Another roadblock to a mutual understanding are the concepts used by each. Engineers are accustomed to working in a deterministic environment. Most things are black or white for an engineer. On the other hand, lawyers tend to deal in the gray spaces. The issues they deal in are much more “squishy,” lacking clear definitive answers. Additionally, both sets of concepts tend to be very complicated to outside parties.

There is hope for developing a middle ground where engineers and lawyers can meet and dialogue. To do this, both lawyers and engineers should more frequently use plain spoken language. A tool in the engineer’s toolkit can accomplish this task. Use cases can provide a bridge for reaching this plain spoken middle ground without using technical or legal jargon.

Engineers are adept at creating use cases for defining the features and functionality in a product release. These same use cases can be drafted to describe to a lawyer what the flow of events is for a user. Use cases can also be used in defining how privacy legal concepts or rules can be applied to the functionality of a product or service. Lawyers need to understand how the user’s information will be collected, used, and shared. The user flow described in a use case is a great tool for providing this information.

One major benefit of use cases is that they make difficult concepts more concrete and comprehensible. Scenarios can be created that define privacy issues in a manner that is understandable by both parties. With these more simple descriptions comes a clearer view of the user interaction that lawyers can more easily grasp.

Another advantage is that use cases help create a shared glossary. Engineers and lawyers should develop a shared privacy glossary that aligns with the company’s privacy policies and principles. This glossary needs to be based on the company’s own business practices. A shared glossary will provide the necessary definitions that can bridge the language gap. For example, what does the company mean by the term “personal information”? There are numerous definitions of this term used in rules and regulations, as well as by companies in their privacy policies. A company’s definition of “personal information” will impact the way information is collected from users. Engineers and lawyers should work together to develop an appropriate definition through use cases and provide guidelines that are used throughout the company’s development cycle.

Use cases move teams to speak a shared language. Lawyers need to limit the legalese and try to distill the legal concepts into more understandable concepts. Engineers need to limit the techno jargon to more simple concepts. So often the legal rules or regulations are written so obtuse that it can drive an engineer crazy. Working with the lawyer, this “legalese” can be deciphered into something more palatable. As an example, the phrase “data only used for the purposes for which it was collected” crops into rules surrounding the appropriate collection of personal information from users. Translated this means only using the information collected from the user for the reason you told the user you were collecting it. As an illustration, an app developer collects a piece of data to provide recommendations to a user but then decides to use the information for serving targeted ads, without letting the user know beforehand. Lawyers can provide these types of real-world examples through use cases to better describe confusing legal concepts.

Ultimately, use cases help to develop rapport and understanding between the two factions. The best way to develop affinity with an opposing side is to find ways to interact using less formal methods. In order to work in harmony, engineers and lawyers need to develop rapport with each other. We all tend to face similar challenges and can find solidarity.

A successful privacy engineering engagement between an engineer and a lawyer is possible. Engineers and lawyers will always look at privacy issues differently due to how they frame the issues. However, by developing use cases to define concepts, these differences can be lessened. Both sides need to be cognizant of the other’s point of view and approach any engagements with a jargon-free approach. Engineers and lawyers working in unity to mitigate the privacy issues will make for a successful and privacy-enhanced product.

Use Case Metadata

Metadata is business information that information technology needs to design and develop databases and the systems that satisfy business objectives and requirements. Whereas, mathematics is the language of science, metadata is the language of data, business, application, and technology architecture. Metadata is the who, how, where, when, and why of things we manage and the activities performed in managing them. Metadata is crucial to quality solution design and to maintain data quality and consistency in the operational environment.

The following are pieces of information (metadata)⁷ gathered during use-case development:

• For each use case:

  • Use-case name

  • Use-case description

  • PI involved in use case:

    • Intended uses

    • Related use cases

  • Expected use-case results

  • Measures of success

  • Primary actor performing the use case

  • Support actor(s) performing the use case

  • Location of the use case

  • Frequency of the use case

  • Related use case(s)

  • Ideal course of action:

    • Event name and description (iterated for all events):

      • Decision 1 name and description

        • Business rule 1 description (If . . . Then . . . Else)

          • Business rule data entities/attributes required

      • . . . (iteration)

        • Business rule and description (If . . . Then . . . Else)

      • Decision and name and description

        • Business rule 1 description (If . . . Then . . . Else)

        • . . . (iteration)

        • Business rule and description (If . . . Then . . . Else)

    • Business processes triggered by event

      • Process data entities/attributes required

  • Alternative courses of action (extension use case)

For privacy engineering, use cases are key to understanding which events or behaviors have privacy impacts. By including privacy indicators and related privacy rules in the use-case metadata, the privacy engineer can easily index issues and understand where to focus attention.

WHEN IS METADATA NOT METADATA?

The answer is “when it’s not.”

Metadata can be defined as business information that information technology needs to design and develop databases and the systems that satisfy business objectives and requirements. Others give an even more terse definition: Metadata is data about data. Both definitions define metadata as something that is descriptive of other data. But when data initially identified or initially collected and processed as metadata are used not to describe other data but as data itself, such data may be considered content and not metadata, that is, either proprietary as in trade secret or other confidential data or personal data where it identifies an individual human. The fact that such collections of metadata may not name an individual by his or her legal surname is not determinative for legal and process based consideration.

For example, the US National Security Agency (NSA) collects telephone call and e-mail envelope metadata so it can more easily access large databases to determine end points where possible terrorists may be calling within the United States. This would be a correct use of the word “metadata.” Where such data are used to create analytics and patterns to show anomalies or help predict known threatening behavior, they may also be used to build a case of probable cause for further individual inspection. Due process principles and protections apply under existing law to prevent further message content inspection without such process. Where this process is not followed or where overcollection of metadata capable of individual identification takes place, an inevitable political and social backlash is unleashed.

But what if this so-called metadata is analyzed as data itself to gain an understanding of calling patterns or some purpose other than that described to a court or other reviewing body that allowed the correction of the data? Then the metadata itself may be considered content (and is not metadata) and thus is separately subject to data protection and other cyber security rules and regulations. In other words, the expectation of privacy in the United States and in other countries may be broader than initially considered by law enforcement agencies and international policing requirements. Metadata, like all other forms of raw data, is subject to the reengineering and new protection requirements implied by the jargon “big data.”

Use Case Metadata Model

Figure 5-3 presents a metadata model showing the metadata that needs to be collected for any use case being developed (see also Appendix A).

Figure 5-3.

Use-case metadata model

As discussed previously and later in Chapters 6, 7, 8, and 9, it is helpful to understand the various elements that need to be covered in each use case:

• An event (the when) may require one or more decisions to be made.

• Each decision event pairing may have a decision event actor (the who) who is involved in making the decision.

• A decision event may be governed by one or more decision event rules, including one or more privacy rules, which are a type of a business rule, as discussed later.

• Each decision event rule will require one or more data attributes (the what) needed to determine the decision criteria. For example, if the decision event rule is IF role name = Guest THEN invoke Guest Privacy Rule processing, “role name” is a data attribute used as part of the rule.

• Once the decision event rules have been processed, a decision event action (the how) may be taken by the system.

• This decision event action may impact a decision event action actor.

• The decision event action may be motivated by a goal or objective (the why) form of motivation.

• A decision event action will take place in a location (the where).

All this information that has been gathered within the use cases would then be put into a metadata repository based on this metadata model.

The Privacy Engineer’s Use of Use Case Metadata

In this section, we show an example of use-case metadata. This use case will be repeated in Chapter 7, as it reflects the requirements of what we call the privacy component (example scenario 1)

• Motivation (Why): How does the project, procedure, or process address issues concerning privacy that involves the authorized, fair, and legitimate processing of personal information?

• Actors (Who):

  • Decision event actors: Which parties of interest are making decisions and which decisions are made concerning personal information and information related to it?

  • Decision event action actors: Who is impacted by actions taken within the project, program, and process and how is their personal information impacted by the actions taken?

  • Privacy team, including legal advisor(s)

  • Data stewards

  • Business stakeholders

  • Developers

  • Data analysts

• Events (When):

  • Is a Privacy Notice needed? If so, who are the data subjects from whom personal information will be collected? How will personal information be used? Will personal information be shared within or outside the enterprise? How long will the data be kept?

  • Where is encryption needed?

  • What are the data archiving rules, especially related to personal information?

  • Which data, especially personal information and data related to it, are collected? How are these data protected? Is it proportional to the data need? How are the data to be processed? How will the data be backed up?

  • Will data, especially personal information and data related to it, be transferred to third parties? How will such data be protected? Are there jurisdictional issues concerning transfer?

  • What are the authentication and authorization security rules? Are there any special rules due to personal information?

• Behavior (How):

  • When the system is invoked, authenticate the user and determine whether the role of user allows authorization.

  • Display the Privacy Notice, if needed or requested.

  • Collect only data, especially personal information or data related to it, proportional to need.

  • Allow maintenance of data, according to privacy principles and regulations.

  • Present data for use and for reporting reasons, according to privacy principles and regulations.

  • Archive data, according to privacy principles and regulations.

• Data classes (What):

  • Privacy Policy

  • Privacy rules

  • Role

  • Individual person

  • Organization

  • Data classes, as needed for the application that is covered by the project

• Location (Where):

  • Where are the users? Are there any jurisdictional problems?

  • Where are the data being processed? Are there any jurisdictional problems?

  • Where are the data being transferred? Are there any jurisdictional problems?

USER EXPERIENCE REQUIREMENTS AND PRIVACY ENGINEERING REQUIREMENTS: MAKING THE TWO MESH

Privacy engineering requirements and decisions will inform, influence, create, and determine user experience requirements and vice versa. Therefore, it is important to review privacy engineering requirements from a user’s experience perspective, as well as to review and understand the impact of user-interface design and user-experience requirements on privacy engineering, and in both cases resolve disparities where detected.

This issue extends from the idea of what is being engineered to the fine points of user-interface design and packaging and requires a high degree of interactivity between the engineering team and the user experience team.

The comparison starts with the notion of transparency. Will the user of the application, system, or process understand how and in what context his or her personal information will be used and processed?

One example is notice and choice. Decisions to collect and process certain types of data may require notice and consent. The question then becomes when such notice should be presented and how consent is collected. This is both an engineering issue and a user experience or design issue. What is easiest from an engineering perspective may not be best or the most satisfactory from a user experience or design point of view.

Another fair information factor is consideration of proportionality or relevancy. Are the data being requested from the user proportionate to the required use or truly relevant to the service being provided, or is the collection just opportunistic or assumptive? An example of this would be collecting geolocation information through a mapping app on a mobile device. It may be easiest from an engineering perspective to begin routing as soon as a destination is entered into the system. However, in reality, someone might be just looking to see where a street address is—not how to get there. If this is the case, then turning on and collecting location information from the device falls into the assumptive or opportunistic bucket, and it may be neither necessary nor relevant to the task being contemplated. Think how the issues might be seen differently if the button the user clicked to find the location of the address said “locate and route” and not “find”? Although the functionality is privacy engineering, the labeling of the buttons is user-experience design.

For this reason, it is important to review both privacy engineering requirements and how those requirements are being met from user-experience and user-interface perspective using such things as privacy policies, privacy governance frameworks, and common sense so that how a process, products, or system uses personal information does not come as a surprise to a user, is perceived as invasive or creepy, or creates an air of mistrust or uncertainty.

Determining Data Requirements

As we will be discuss in more detail in Chapter 6, a business data model reflects the data requirements complementary to the use case. The model shows the items managed by the enterprise and the relationship between the classes and the data entities.

As an example, a high-level business model focusing on privacy (Figure 5-4) shows that more than one privacy rule may be derived from each privacy policy (the diamond icon in UML indicates an aggregation or one to many). Each of the various roles that a party of interest plays may have multiple privacy rules. In Chapter 6, the fact that detailed (logical) data models will be derived from the business data models and that the database will be designed from the detailed data model will be explained. In Chapter 7, the detailed class or data model derived from this privacy business data model will be shown and explained as the class or data model for the privacy component.

Figure 5-4.

Privacy business data model

How Does the Distribution Channel Impact Privacy Engineering Requirements?

The privacy component may be an app within a mobile app, a web service invoked by a system, or a component object included within a database or cloud-utilizing system. The privacy component will be programmed with a programming language able to be run on a broad range of platforms. The privacy code will be encapsulated with an input/output interface that can be adapted to the file or database system on which the PII and the data related to it are stored. In this regard, the cloud has become a very significant distribution channel.

Cloud Privacy Requirements

Cloud computing is the practice of using a network of remote servers hosted on the Internet to store, manage, and process data rather than a local server. There are a number of privacy issues in the cloud:

• How does the cloud provider handle encryption and encrypted data?

• Does our user have exclusive access to his or her data?

• Do our data get commingled with other people’s data?

• Can our user access all of his or her data whenever needed?

• Does the cloud provider satisfy all compliance requirements including OEDC, FIPPS, and GAPP, specific statutory regulations for all jurisdictions or all enterprise privacy policies?

• Are data stored so as to be physically protected?

• Can data be transferred without the knowledge of the cloud provider?

• Are the laws of all relevant jurisdictions satisfied?

• Can our archiving strategies be enforced within the cloud?

• Can we be assured that appropriate data are deleted wherever they are stored so as not to be subject to a subpoena or a search warrant?

• Does the cloud provider mine the data that it stores for its own or someone else’s purposes?

• Is the cloud provider fully auditable?

• Does the cloud provider provide breach notification according to our privacy policies as well as statutory requirements of all jurisdictions affected?

• Is the overall cloud provider security sufficient?

• Can a cloud provider provide data transfer capability and sufficient security to satisfy data transfer?

All relevant questions and the appropriate answers to each may be considered requirements and thus covered or implicated by privacy policies or other processing rules as well as business use cases. Privacy components may be designed for these environments at the cloud provider as well as the recipient of the cloud services following the privacy specific UML models and architectural approach. In this particular data use case, contractual, procedural, and additional roles at the organizational and individual levels may be considered and leveraged as part of the overall solution where, in a single organizational or single purpose cloud environment or structure, technology components may have sufficed alone. In other words, distributed computing techniques such as cloud computing may create additional modeling requirements, but the techniques underlying the premise of privacy engineering as a practice remain relevant and quite powerful.

Conclusion

This chapter introduced use cases as a vehicle for defining and documenting overall requirements, including privacy requirements. This is a form of requirements engineering. We presented detailed use-case metadata, which answered the who, what, where, when, how, and why questions regarding the privacy component. We then covered user experience and distribution channel requirements. We began introducing the Unified Modeling Language (UML) Class Model showing a simple business data model. We will discuss use of the class model in chapters 6, 7, 8, and 9.

You might be concerned that this process is too time consuming or too difficult to accomplish, but if you develop your requirements, especially the privacy requirements, with care, you’ll have a smoother development and testing process. You’ll also be able to deal with auditors and regulators with much greater ease. Actually, the requirements process does not have to be time consuming or difficult, as we will show with our runner’s app scenario in Chapter 8. Chapter 6 will discuss the Privacy Engineering Methodology.