Re: [pbd-se] Comments: Privacy by Design Documentation for Software Engineers v0.1

[Dawn Jutla <dawn.jutla@gmail.com>]

Dear Frank:

Thank you for your input as one of our newest PbD-SE TC members. 

There are a few important details you may have misunderstood. Most notably PbD-SE is not what you state in" Privacy by Design for Software Engineers” deals with privacy principles, which is okay but does not make as much sense to a software engineer as having a mapping of related sw engineering “activities” that should be addressed to assure privacy safeguards for each of these principles." 

This TC's work is not at the stage to provide conformance guidance as yet. That will easily come after we go through the body of the work we still need to do.

It is immaterial whether companies are using agile or not. The need for evidence of designing in privacy into systems regardless of development cycle time is universal for the purposes of compliance.  Since most software engineers using agile methodologies have seen UML in their training or past work experience, it is not impossible to foresee a future where software engineers provide privacy-by-design evidence using UML on top of their agile processes.  One cannot expect privacy auditors (internal or external) to re-engineer code but their job can certainly be made easier via a design documentation standard.

Let's get a time to chat on a phone call so that we can get you up to speed on the TC's previous months of discussions, foci etc.

Dawn.

______________________________________
Dr. Dawn Jutla, PhD

Professor of Business and Computer Science

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

Sobey School Bio: http://www.smu.ca/academic/sobey/bios/faculty/Jutla_Dawn.html
Website: http://husky1.stmarys.ca/~djutla/

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 Wed, Jul 17, 2013 at 1:37 PM, <Frank.Dawson@nokia.com> wrote:

Hei PbD-SE Members.

 

These comments come in just in time for our conference call today. They are in regards to the v0.1 document circulated on the TC email list by Ann on July 10^th.

 

Comments:

 

1.      “Privacy”, “Information privacy” or “Digital privacy” is not defined in the terminology section. It would be very useful to software engineers to have such a term that scopes the semantics of this OASIS specification/note with their software engineering role.

2.      §2 “Privacy by Design for Software Engineers” deals with privacy principles, which is okay but does not make as much sense to a software engineer as having a mapping of related sw engineering “activities” that should be addressed to assure privacy safeguards for each of these principles. In other words, this section would be strengthened for its purpose its content was subsections for each important information privacy principle, with content of the sub-section having a summary of the principle and implication for privacy impact along with related activities and tools that could be used to assure minimal privacy impact. For example, under Purpose Specificity I would have thought that one key activity is definition of complete “Product Description” where key use cases are to be defined such that primary and secondary purposes and 1st party and 3rd party entities are defined with their roles. Tools would include pointer to UML diagram types that help to achieve the requisite evidence or documentation.

3.      §3 “Software Development Lifecycle Documentation” deals with specific application of software engineering tools such as CERT SQUARE, UML diagramming to document various product lifecycle deliverables. While these are relevant example documentation types, it occurred we have not talked about the conformance requirement that each of these will take on in this document. This gets to my earlier comments on the email list about whether this document should be formatted as a Committee Note or Committee Specification. Many companies have made an engineering investment in UML. In fact, Nokia even created a Nokia Standard UML that was used widely from around 2000-2010. However, with the adoption of SCRUM Agile software development, as we moved from large scale systems to internet/web applications and services, the lifecycle period moved from years to weeks and we have decreased the requisite documentation to that adhered to by accepted SCRUM software development practices. Many organizations build products for the single digital market place have followed similar paths. Nokia is not always a leader here but often a follower of the leaders J This section should be classified as recommendations and the conformance requirements should be a SHOULD on all the tools or documentation listed here.

4.      Add a software development lifecycle phase for the business approval for a project/product. This is very key to align the product’s privacy requirements with businesss owner/management and to get their top-level commitment for baking privacy into the product from the beginning.

5.      New section is suggested to be added. The “Software Development Lifecycle Activities” section (proposed title) would include content that is formatted as a recommendation on a list of activities that would completed prior to exiting each of the software development lifecycle phases listed in §3. For example, the following might be useful input.

f

 

-          New Business Model/Project Approval

o   Privacy Risk Identification

§  Nominate “privacy champ” within the product team to be responsible leading mapping privacy into requirements

§  Allocate a unit “privacy officer” to support the privacy champ and to oversee the Privacy Engineering as a whole

§  Identify key privacy threats and opportunities with business

§  Identify training needs

§  Align with security engineering process and legal support

§  Start documenting finding to PbD-SE templates

-          Concepting

o   Requirements Setting

§  Train relevant product teams

§  Identify and document data flows

§  Full threat assessment and mitigation planning, define requirements.

§  Apply Privacy Patterns and Designs (e.g. notices, settings) to concept

§  Verify architecture and address data management (e.g data lifecycle, access rights management)

-          Implementation

o   Coding, testing, integration

§  Support implementation teams with privacy requirements

§  Address 3rd party data processing and security issues (e.g. Audits, agreements, instructions)

§  Assess threats and define mitigations for identified new issues.

§  Manage exceptions, deviations, escalations

-          Deployment

o   Verification

§  Privacy and security  testing on Beta version

§  Fix identified issues

§  Complete Privacy and Security Impact Assessment before go-live (against go-live criteria) – OK / not OK?

-          Operations

o   Support and maintenance after release

§  Address any vulnerability,  deviation or breach identified after release

§  Repeat Privacy Engineering cycle for main new releases

§  Aim for continuous improvement release after release

Frank/