[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [pbd-se] Uber review of the reviews of wd04 R2
Having spent the first half of my career building systems and designing processes and the second half of my career in data protection/privacy, I have found that those Privacy Officers and Programs that address data protection/privacy from a holistic perspective are those that are the most successful in their implementation efforts.
Chapter 4 (the mapping between the seven PbD principles and the documentation that software engineers must or should produce or reference throughout the software development lifecycle - from software conception to retirement) provides a very succinct summary of the documents (or information) that are required throughout the design processes (of products, business processes and technologies).
This takes me to two other overall observations and thoughts about the work, which I find extremely comprehensive and impressive.I was expecting Chapter 5 to be ordered by the documents listed in Chapter 4 with samples.
The first is the overall challenge to compress the requirements identified in Chapter 2 and 4 into more simplified, actionable and achievable processes for data protection/privacy professionals and their business partners
The second is to take advantage of the existing design and implementation tools/information that are available to business process and systems engineers and integrate data protection/privacy into those tools, rather than the reverse
Respectfully, I have not been a part of the overall dialog and development of this work, so my additional suggestions might not be applicable. They are:
I might suggest that you consider moving Chapter 3 to follow Chapters 2 & 4 for two reasons. The first is that the that the operational requirements are very demanding. The second, is that you might find that you might find following this order that Chapter 3's contents might become more streamlined
Folks,
I've looked at the comments circulated, at the time of this email (ss, sabo and sf). Broadly I support them (easier where proposed text has been provided!)and they more than cover my main areas of concern which were the normative text in Section 2, and Section 5 moving to an appendix.
The only area that does not seem to be covered is the Introduction, where on the call, we agreed that the text needs to be modified to recognize the role of the organization's governance processes in overseeing the efforts of the software engineer in respect of PbD.
To that end, I offer a start on the following..
From 1: Introduction: The PbD-SE specification helps engineers to visualize, model, and document PbD requirements and embed the principles within software engineering tasks. Add..**It also helps inform those organizational governance processes that oversee the engineers**.
From 1.1: The protection of privacy in the context of software engineering requires normative judgments to be made on the part of software engineers, add..**in the context of organization-wide governance of privacy protection**.
1.2 and 1.3 seem to be OK as is.
Cheers
Colin
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]