RE: [pbd-se] OASIS Specification Approach

[<Frank.Dawson@nokia.com>]

Hei Stuart.

 

“…accomplish the first one…”

 

I looked through the January minutes and it clearly identifies the “wd03” draft as the basis of our work. I did not read anything in the minutes that indicated we would define normatively, in this specification what privacy activities apply to software engineering PbD.

 

If you look at this draft of the specification (https://www.oasis-open.org/apps/org/workgroup/pbd-se/download.php/50989/pbd-se-v1%200-wd03.doc) it is clear to me that the outline and content, as draft as it may have been, was focused on identifying what privacy engineering activities need to be accounted for in software engineering to follow Privacy by Design.

 

The 2^nd topic in my email was specific to the codification of templates that will be endorsed by the specification. My understanding has been that we should include an informative annex of examples and their usage but that these were not a part of the normative clauses.

 

My comments and contribution on “checklist” are specific to forging a structure that lends itself for software engineers use of the specification to understand what activities, documentation they should have at various stages of the product creation lifecycle. The checklist that I contributed is agnostic of PDLC method but specific to what an engineer should focus on at the start of a project, in the implementation phases and as the product is released.

 

My thought was that Section 4 would be a set of annexes with example templates/formats and that section 3 would outline the principles that a software engineer will have to comprehend in applying privacy engineering. Then a new section 4 would consist of a normative description of the privacy engineering activities to be completed to support the principles in section 3 using the templates from the informative annexes. This is where the checklist might be provided in the new section 4, as a diagram/illustration, to show when the status and documentation for these privacy engineering activities needs to be revisited and verified.

 

Checklists do not define process/methodology, such as a PIA does, but instead act as a flexible tool to communicate to the team and verify amongst the team status of activities, so miscommunication and undone actions do not lead to baking lack of privacy into products.

 

Frank/

 

 

 

From: pbd-se@lists.oasis-open.org [mailto:pbd-se@lists.oasis-open.org] On Behalf Of ext Shapiro, Stuart S.
Sent: 11 February, 2014 15:15
To: pbd-se@lists.oasis-open.org
Subject: Re: [pbd-se] OASIS Specification Approach

 

I wasn't aware that we were trying to accomplish the first one. Inevitably, we have to refer to life cycle activities to situate various types of documentation, but I don't think we're trying to specify privacy engineering activities per se. Reaching back to our last telecon, I thought we were trying to come up with a normative specification for privacy documentation that is agnostic with respect to the specific notation or representational scheme. If so, this addresses the concern regarding template/format preferences, as we should not be specifying templates and formats (though we can offer examples) but rather attributes or properties that indicate that a particular notation has the capacity to capture and communicate the necessary information.

 

Stuart

On Feb 11, 2014, at 12:16 PM, Frank.Dawson@nokia.com wrote:

Hei PbD-SE-ers.

The latest draft of the TC specification seems to be trying to accomplish two separate things. One – To provide guidance on privacy engineering activities to complete throughout the product development lifecycle. Two – To provide guidance on templates/formats for particular artifacts/evidence of good practices for privacy engineering. I wonder if these should be separated into two deliverables? One argument is that the first deliverable objective could be specified in a normative way, based on leading and best practices. However, the second deliverable objective is elusive because of personal and organizational preferences for the templates/formats for such artifacts/evidence. In fact, even within on particular template/format there can be broad differences in deployment/usage.

Lastly, in regards to the first deliverable objective, we do not yet have what I think is a useful arrangement for conveying the guidance on privacy engineering activities. I have a “privacy architect” colleague Ian Oliver who has written public blogs about how the aviation and medical fields have leveraged “checklists” to reduce risk within their fields (i.e., pilot checklist and surgical team checklists). The latter has been documented extensively because of the significant reductions in surgical theatre mishaps and post-surgery morbidity. Dr. Oliver has applied surgical checklist best practices to privacy engineering in the form of development team checklists. Whether you are using waterfall PDLC or agile PDLC forms, you have the same three-phases around a milestone or sprint/release. You have the Pre-Event, In-Event and Post-Event stages around the milestone. The purpose of industry checklists is two-fold; one – to make sure all the team involved in the event are aware of their roles and are prepared for the event and, two – to make sure proper activities are conducted and adequate evidence of accountability is recorded of completion of those activities.

Here is a good overview of how checklists are applied in the medical/surgical context, from a publication of the World Health Organization.http://www.who.int/patientsafety/safesurgery/ss_checklist/en/

My suggestion is that OASIS PbD-SE team look at using the checklist approach to formatting the privacy engineering activities that need to be addressed during the PDLC, by creating such a checklist for the basic milestones we identify.

Frank/