Please see below as a reference for further committee discussion related to Agenda item 3.

Committee members, you may wish to consider/suggest a role for subsets of the PRIPARE methodology as it relates to producing documentation in association with PbD-SE Specification conformance.

Kind regards,
Dawn.

3 Conformance

This section summarizes the requirements for meeting the PbD “Conformance Targets” of this specification.

3.1 Maturity Levels

Organizations may determine and report how mature their PbD-SE specification conformance is on a scale of 1 to 5 with conformance levels that range from ad-hoc (1) to optimized (5). Each higher level presupposes that all the documentation requirements in lower levels have been met and surpassed.

Ad-hoc Level 1: Organizations pro-actively plan for supporting software privacy. PbD-SE specification is used. Organizations assign and document privacy roles and initiate privacy programs; communicate privacy policy documentation to stakeholders. No benchmarking as yet.

Committed Level 2: Documents and communicates user-centricity, visibility, and transparency for users’ privacy; minimal benchmarking with other organizations’ privacy programs.

Established Focused Level 3: Documents the extent of embedding privacy within each stage of the software SDLC; Privacy Documentation & Compliance Dashboard is established; benchmarking is prevalent.

Improved, Managed Process Level 4: Systematically uses the OASIS PMRM Use Template and PbD-SE associated methodologies to produce documentation; identify desirable privacy properties; documents privacy architecture, controls selection, and implementation; Dashboard is managed.

Optimized Process Level 5: Software products and services exhibit Privacy-by-Default. Dashboard metrics are fully extended to measure any interacting software platforms. Privacy benchmarking often performed with partner platforms.

3.2 Targets

1. Proactive, Not Reactive: Level 1

Documentation:

a) SHALL normatively reference the PbD-SE specification

b) SHALL reference assignment of responsibility and accountability for privacy in the organization, and privacy training program(s).

c) SHALL include assignment of privacy resources to the software project, recording who are responsible, accountable, consulted, or informed for various privacy-related tasks

d) SHALL reference all external sources of privacy requirements, including policies, principles, and regulations.

e) SHALL include role(s) responsibility for privacy requirements specific to the service/product being engineered, and anticipated deployment environments

f) SHALL include privacy risk/threat model(s) including analysis and risk identification, risk prioritization, and controls clearly mapped to risks

g) SHALL document roles’ RACI chart to identify and monitor privacy and security metrics, and to report and respond to privacy issues.

2. Privacy as the Default – Level 5

Documentation:

a) SHALL list all [categories of] data subjects as a stakeholder

b) SHALL clearly record the purposes for collection and processing, including retention of personal data specific to the service/product being engineered, and anticipated deployment environments. Note related documentation and display requirements in PbD Principle 7: Respect for the User.

c) SHALL document actions taken from active (online and offline) monitoring of privacy and security metrics

d) SHALL document ALL engineering controls used for privacy within and external to the software under consideration.

I. SHALL document expressive models of detailed data flows, processes, and behaviors for use cases or user stories associated with internal software project and all data/process interaction with external platforms, systems, APIs, and/or imported code.

II. SHALL describe selection of privacy controls and privacy services/APIs and where they apply to privacy functional requirements and risks.

e) SHALL document privacy monitoring results

f) SHALL include software retirement plan from a privacy viewpoint

3. Privacy Embedded into Design – Level 4

Documentation:

a) SHALL use the Privacy Use Template (see PbD-SE Annex Section 5 [PbD-SE-Annex-1.0]) or the more comprehensive OASIS PMRM methodology [PMRM 1.0] or equivalent for identifying and documenting privacy requirements, and selection of privacy controls

b) SHALL contain description of business model showing traceability of personal data flows for any data collected through new software services under development.

c) SHALL include identification of privacy design principles

d) SHALL contain a privacy architecture

e) SHALL describe privacy UI/UX design

f) SHALL define privacy metrics

g) SHALL include human sign-offs/privacy checklists for software engineering artifacts

h) SHALL include privacy review reports (either in reviewed documents or in separate report)

i) SHALL treat privacy-as-a-functional requirement i.e. functional software requirements and privacy requirements should be considered together, with no loss of functionality.

j) SHALL show tests for meeting privacy objectives, in terms of the operation and effectiveness of implemented privacy controls or services

k) SHALL be produced for all stages of the software development lifecycle from referencing applicable principles, policies, and regulations to defining privacy requirements, to design, implementation, maintenance, and retirement.

l) SHALL reference and document requirements, risk analyses, architectures, design, implementation mechanisms, retirement plan, and sign-offs with respect to privacy and security.

m) SHALL include security and privacy metrics designed in and/or deployed in the software, or monitoring software, or otherwise in the organization, and across partnering software systems or organizations.

n) SHALL demonstrate designs and implementations that satisfy state-of-the-art privacy properties.

4. Full Functionality: Positive Sum, not Zero-Sum – Level 4

Documentation:

a) SHALL treat and document privacy-as-a-functional requirement, i.e. functional software requirements and privacy requirements should be considered together, with no loss of functionality.

b) SHALL show tests for meeting privacy objectives, in terms of the operation and effectiveness of implemented privacy controls or services

5. End to End Safeguards: Full Lifecycle Protection – Level 3

Documentation:

a) SHALL be produced for all stages of the software development lifecycle from referencing applicable principles, policies, and regulations to defining privacy requirements, to design, implementation, maintenance, and retirement.

b) SHALL reference requirements, risk analyses, architectures, design, implementation mechanisms, retirement plan, and sign-offs with respect to privacy and security.

c) SHALL include security and privacy metrics designed in and/or deployed in the software, or monitoring software, or otherwise in the organization, and across partnering software systems or organizations.

d) SHALL demonstrate designs and implementations that satisfy state-of-the-art privacy properties.

6. Visibility and Transparency: Keep It Open – Level 2

Documentation:

a) SHALL reference the privacy policies and documentation of all other collaborating stakeholders

b) SHALL include description of contextual visibility and transparency mechanisms at the point of contextual interaction with the user/data subject and other stakeholders for data collection, use, disclosure, and/or elsewhere as applicable

c) SHALL describe any measurements incorporated in the software, or monitoring software, or otherwise to measure the usage and effectiveness of provided privacy options and controls, and to ensure continuous improvement.

d) SHALL describe placement of privacy settings, privacy controls, privacy policy(ies), and accessibility, prominence, clarity, and intended effectiveness

7. Keep it User-Centric – Level 2

Documentation:

a) SHALL describe user/data subject privacy options (including access), controls, user privacy preferences/settings, UI/UX supports, and user/data subject-centric privacy model.

b) SHALL describe notice, consent, and other privacy interactions at the earliest possible point in a data transaction exchange with a user/data subject or her/his automated agent(s) or device(s).

__________________________________________________________________________________
Dr. Dawn Jutla, PhD

Professor of Technology Entrepreneurship, Strategy, and Computer Science

MTEI Program Founder and Director

Department of Finance, Information Systems, and Mgmt. Science

SOBEY SCHOOL OF BUSINESS
Saint Mary's University, Halifax, NS, B3H 3C3

Phone: 1 902 491 6441

Website ; Twitter: @DNJutla

Connect with Sobey MTEI

CONFIDENTIALITY NOTICE: This email and any attachments may contain confidential information that is protected by law and is for the sole use of the individuals or entities to which it is addressed. If you are not the intended recipient, please notify the sender by replying to this email and destroying all copies of the communication and attachments. Further use, disclosure, copying, distribution of, or reliance upon the contents of this email and attachments is strictly prohibited.

On Tue, Jun 9, 2015 at 5:05 PM, Gershon Janssen <gershon@qroot.com> wrote:

Privacy by Design Documentation for Software Engineers (PbD-SE) TC
10 June 2015, 1:30-3:00 PM EDT / 19.30-21.00 CET

---

Please find below the draft agenda for the OASIS PBD-SE TC meeting.

---

* Call-In Information:

See separate email from Gershon with call-in information. [Same call-in as previous meetings]

* PROPOSED DRAFT AGENDA

1. Call to Order

2. Approval of Agenda

3. PbD-SE compliance levels

4. Use case contexts

5. Call for comments by NIST on its draft report, "Privacy Risk Management for Federal Information Systems," NIST-IR 8062
John Sabo / Richard Grow

6. Other Business

7. Next Meeting / Adjourn

__________

Kind regards,

Dawn.

pbd-se message

3 Conformance

3.1 Maturity Levels

3.2 Targets

Connect with Sobey MTEI