Privacy By Design Draft Privacy Use Case Template

Slides:



Advertisements
Similar presentations
Module N° 4 – ICAO SSP framework
Advertisements

Module N° 7 – Introduction to SMS
Privacy By Design Sample Use Case
EMS Checklist (ISO model)
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
1 Brief Descriptions of CMM KPAs CEN 6070 Summer 2004.
© 2005 by Prentice Hall Appendix 2 Automated Tools for Systems Development Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F.
Overview of OASIS SOA Reference Architecture Foundation (SOA-RAF)
OASIS Reference Model for Service Oriented Architecture 1.0
Fluff Matters! Information Governance in an Online Era Lisa Welchman.
Architecture is More Than Just Meeting Requirements Ron Olaski SE510 Fall 2003.
Security Extensions to the DOD Architecture Framework Kevin Richardson Information Assurance Lab Auburn University Computer Science and Software Engineering.
Lesson-10 Information System Building Blocks(2)
9/6/2001Database Management – Fall 2000 – R. Larson Information Systems Planning and the Database Design Process University of California, Berkeley School.
Chapter 10: Analyzing Systems Using Data Dictionaries Instructor: Paul K Chen.
Fundamentals of Information Systems, Second Edition
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
Software Architecture in Practice
Chapter 2: IS Building Blocks Objectives
1 Objective of today’s lesson S oftware engineering occurs as a consequence of a process called system engineering. Instead of concentrating solely on.
Database Administration Chapter 16. Need for Databases  Data is used by different people, in different departments, for different reasons  Interpretation.
Privacy By Design Sample Use Case Privacy Controls Insurance Application- Vehicle Data.
Object-Oriented Analysis and Design
PMRM Overview and Privacy Management Analysis Tools Development John Sabo Gershon Janssen
Bina Nusantara 2 C H A P T E R INFORMATION SYSTEM BUILDING BLOCKS.
OASIS PRIVACY MANAGEMENT REFERENCE MODEL EEMA European e-identity Management Conference Paris, June 2012 John Sabo, CA Technologies Co-Chair, OASIS.
System Analysis & Design Introduction: System Analysis and design course intents to help students understand its importance in developing systems that.
Company Confidential How to implement privacy and security requirements in practice? Tobias Bräutigam, OTT Senior Legal Counsel, Nokia 8 October
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design.
The Architecture Business Cycle. Software Architecture Definition The software architecture of a program or computing system is the structure or structures.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
Gershon Janssen 11 th October 2011 London Privacy Management Reference Model International Cloud Symposium 2011.
DRAFT – For Discussion Only HHSC IT Governance Executive Briefing Materials DRAFT April 2013.
Session ID: Session Classification: Dr. Michael Willett OASIS and WillettWorks DSP-R35A General Interest OASIS Privacy Management Reference Model (PMRM)
Presentation annotated by Gail Magnuson LLC with permission from Using Information Technologies to Empower and Transform.
IEEE SCC41 PARs Dr. Rashid A. Saeed. 2 SCC41 Standards Project Acceptance Criteria 1. Broad market application  Each SCC41 (P1900 series) standard shall.
1-1 System Development Process System development process – a set of activities, methods, best practices, deliverables, and automated tools that stakeholders.
Overview Privacy Management Reference Model and Methodology (PMRM) John Sabo Co-Chair, PMRM TC.
Lecture 7: Requirements Engineering
Enterprise Architecture, Enterprise Data Management, and Data Standardization Efforts at the U.S. Department of Education May 2006 Joe Rose, Chief Architect.
Information Systems Engineering. Lecture Outline Information Systems Architecture Information System Architecture components Information Engineering Phases.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
ANKITHA CHOWDARY GARAPATI
Database Administration
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
State of Georgia Release Management Training
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
Connecting for Health Common Framework: the Model Contract for Health Information Exchange Gerry Hinkley com July 18, 2006 Davis Wright.
PMRM Revision Discussion Slides Illustrations/Figures 1-3 o Model, Methodology, “Scope” options Functions, Mechanisms and “Solutions” Accountability and.
Business Challenges in the evolution of HOME AUTOMATION (IoT)
1. Scope of Application 2. Use Case Actors Data Flows Touch Points Initial PI 3. PI - at Touch Points In Internal Out 4. PI - Operational Privacy Policies.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Requirement Elicitation Nisa’ul Hafidhoh Teknik Informatika
eHealth Standards and Profiles in Action for Europe and Beyond
The Components of Information Systems
Software Quality Control and Quality Assurance: Introduction
Fundamentals of Information Systems, Sixth Edition
INTERCONNECTION GUIDELINES
The Systems Engineering Context
UNIT V QUALITY SYSTEMS.
CMMI – Staged Representation
Software Requirements analysis & specifications
The Components of Information Systems
Goal, Question, and Metrics
Introduction to Systems Analysis and Design Stefano Moshi Memorial University College System Analysis & Design BIT
Privacy Management Reference Model (PMRM) A formal reference model for data privacy.
Information System Building Blocks
Presentation transcript:

Privacy By Design Draft Privacy Use Case Template

Privacy Template Purpose Standardized format enabling description of a specific Privacy Use Case in which personal information or personally identifiable information is involved and the focus is on software developers Provide an inventory of Privacy Use Case components and the responsible parties that directly affect software development for the Use Case Segment Privacy Use Case components in a manner generally consistent with the OASIS PMRM v1.0 Committee Specification Enable understanding of the relationship of the privacy responsibilities of software developers vis-à-vis other relevant Privacy Use Case stakeholders Bring insights to the privacy aspect when moving through the different stages of the privacy life-cycle May be extended to address predicates for software developers (training, privacy management maturity, etc.) Does not specify an implementer’s SDLC methodology, development practices or in-house data collection, data analysis or modeling tools Overall value as a tool to increase opportunities to achieve Privacy by Design in applications by extracting and making visible required privacy properties

Where are boundaries of software engineers/developers responsibilities with respect to other stakeholders for Privacy by Design? Use case template can help answer this question.

Privacy Use Case Template Privacy Use Case Title Systems Privacy Controls Functional Services Description Data Subjects Application(s) PI/PII Regulatory and Business Policies Data Flows Touch Points Domains, Owners, Roles Products

Foundational Information Use Case Title and Description Data subject(s) associated with Use Case (Include any data subjects associated with any of the applications in the use case) Application(s) associated with Use Case (Relevant applications and products where personal information is communicated, created, processed, stored or deleted and requiring software development)  

Foundational Information (continued) 4. PI and PII covered by the Use Case (The PI and PII collected, created, communicated, processed, stored or deleted within privacy domains or systems, applications or products) [Note: per domain, system, application or product depending on level of use case development] 5. Legal, regulatory and /or business policies governing PI and PII in the Use Case (The policies and regulatory requirements governing privacy conformance within use case domains or systems and links to their sources)

Stakeholder Information 6. Domains, Domain Owners, and Roles associated with Use Case – Definitions: Domains - both physical areas (such as a customer site or home) and logical areas (such as a wide-area network or cloud computing environment) that are subject to the control of a particular domain owner Domain Owners - the Participants responsible for ensuring that privacy controls and functional services are defined or managed in business processes and technical systems within a given domain [Note: This should cover the different views and perspectives of the Use Case by identifying those stakeholders (business person and/or privacy person may have a different perspective) Roles - the roles and responsibilities assigned to specific Participants and Systems within a specific privacy domain  

7. Data Flows and Touch Points Linking Domains or Systems Use Case Development 7. Data Flows and Touch Points Linking Domains or Systems Touch points - the points of intersection of data flows with privacy domains or systems within privacy domains Data flows – data exchanges carrying PI and privacy policies among domains in the use case

Use Case Development 8. Data Flows and Touch Points Linking Domains or Systems – Example Hudson Motors Communications Division Vehicle Backend Data Operations Vehicle Web Portal Vehicle Communications System

Systems under Development 9. Systems supporting the Use Case applications (System - a collection of components organized to accomplish a specific function or set of functions having a relationship to operational privacy management)

Privacy Controls 10. Privacy controls required for developer implementation Control - a process designed to provide reasonable assurance regarding the achievement of stated objectives  [Note: to be developed against specific domain, system, or applications as required by internal governance policies and regulations]

Use Case Development 12. Functional Services Necessary to Support Privacy Controls Service - a collection of related functions and mechanisms that operate for a specified purpose  

“Responsibilities” Table Stakeholder/Domain Owners Data Subjects Applications PI/PII Legal/Regulatory Policies Domains Data Flows/Touch points Privacy Controls Services CPO x IT Architect Business Analyst Team Privacy Champion Senior Developer