Operationalizing Privacy by Design Principles in Software Engineering PbD Compliance Criteria Requirement(s) “Sub-Principles” 1. Proactive not Reactive; Preventative not Remedial Commitment to apply OASIS Documentation MUST normatively reference 1.1–Demonstrable Leadership: A clear commitment, at the Specification to software engineering specification highest levels, to prescribe and enforce high standards project Documentation MUST reference the applicable of privacy protection, generally higher than prevailing privacy policy legal requirements. 1.2–Defined Community of Practice: Demonstrable privacy Relevant stakeholders and team Project plan MUST describe privacy champ/lead/… commitment shared by organization members, user assembled for project All [categories of] data subjects SHOULD be listed communities and stakeholders. as a stakeholder Project plan MUST include RACI matrix for privacy resources OASIS Specification applied at earliest Project plan MUST include privacy section 1.3–Proactive and iterative: Continuous processes to stages of software engineering and at identify privacy and data protection arising from documents SHOULD include privacy section critical points thereafter. poor designs, practices and outcomes, and to mitigate (might be limited to saying not applicable) unintended or negative impacts in proactive and Documentation MUST define privacy metrics systematic ways. Documentation MUST include privacy review reports (either in reviewed documents or in separate report) 2. Privacy as the Default Setting (Data Minimization) See separate Appendix for Documentation MUST describe functional and 2.1–Purpose Specificity: Purposes must be specific and of methods, techniques and privacy requirements. limited, and be amenable to engineering controls Documentation MUST relate technical OASIS PbD-SE methodology and components to functional and privacy PMRM specifications applied requirements.
Operationalizing Privacy by Design Principles in Software Engineering PbD “Sub-Principles” Compliance Criteria Requirement(s) 1. Proactive not Reactive; Preventative not Remedial 1.1–Demonstrable Leadership: A clear commitment, at the highest levels, to prescribe and enforce high standards of privacy protection, generally higher than prevailing legal requirements. Commitment to apply OASIS Specification to software engineering project Documentation MUST normatively reference specification Documentation MUST reference the applicable privacy policy 1.2–Defined Community of Practice: Demonstrable privacy commitment shared by organization members, user communities and stakeholders. Relevant stakeholders and team assembled for project Project plan MUST describe privacy champ/lead/… All [categories of] data subjects SHOULD be listed as a stakeholder Project plan MUST include RACI matrix for privacy resources 1.3–Proactive and iterative: Continuous processes to identify privacy and data protection arising from poor designs, practices and outcomes, and to mitigate unintended or negative impacts in proactive and systematic ways. OASIS Specification applied at earliest stages of software engineering and at critical points thereafter. Project plan MUST include privacy section documents SHOULD include privacy section (might be limited to saying not applicable) Documentation MUST define privacy metrics Documentation MUST include privacy review reports (either in reviewed documents or in separate report) 2. Privacy as the Default Setting (Data Minimization) 2.1–Purpose Specificity: Purposes must be specific and limited, and be amenable to engineering controls See separate Appendix for of methods, techniques and OASIS PbD-SE methodology and PMRM specifications applied Documentation MUST describe functional and privacy requirements. Documentation MUST relate technical components to functional and privacy requirements.
20140411%20-%20Operationalizing%20PbD%20Principles%20-%20Overview_v42.docx