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

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.

 
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