Menu
Home
Log in / Register
 
Home arrow Computer Science arrow The Privacy Engineer’s Manifesto
< Prev   CONTENTS   Next >

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?

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.

 
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >
 
Subjects
Accounting
Business & Finance
Communication
Computer Science
Economics
Education
Engineering
Environment
Geography
Health
History
Language & Literature
Law
Management
Marketing
Philosophy
Political science
Psychology
Religion
Sociology
Travel