OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pbd-se message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments: Privacy by Design Documentation for Software Engineers v0.1


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 10th.

 

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/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]