Widest possible project scope adopted Scope MUST include functionality” 3.1–Holistic and Integrative: Privacy commitments must be “privacy (relates to PMRM functions/services) embedded in holistic and integrative ways The OASIS PMRM Privacy Use Case Template is Documentation MUST describe data RECOMMENDED for describing privacy and behavioural requirements for requirements. each use case/user story, and Documentation MUST include identification possible misuses of data. of privacy architectural design principles Documentation MUST describe Documentation MUST contain a Privacy selection of privacy Architecture controls/services and they Documentation MUST contain description of apply to functional requirements. the Business Model showing personal data flows for software services Acknowledged software engineering Architecture documents SHOULD include privacy 3.2–Systematic and Auditable: A systematic, principled process/methodology adopted view (this does not apply only to software approach should be adopted that relies upon accepted engineering do standards and process frameworks, and is amenable to Metrics applied Documentation MUST identify the software external review. Privacy Metrics, e.g. effectiveness, engineering process/methodology used monitored Documentation SHOULD contain evidence of monitoring of privacy metrics Completed PIA and/or TRA Documentation MUST contain a PIA 3.3–Review and Assess: Detailed privacy impact and risk Completed Priority Matrix of Privacy assessments should be used as a basis for design Documentation SHOULD contain TRA for privacy Controls/Threats from Risk Analysis decisions. Appropriate privacy failsafe mechanisms Documentation SHOULD describe configuration The privacy risks should be 3.4–Human-Proof: adopted parameters and their impact on privacy risks demonstrably minimized and not increase through use, misconfiguration, or error. Software SHOULD warn about events that increase privacy risks (including misconfiguration, errors or misuse). These warnings MUST be documented Documentation MUST contain identification and description of privacy controls. 4. Full Functionality Positive-sum, Not Zero-sum —
3.1–Holistic and Integrative: Privacy commitments must be embedded in holistic and integrative ways Widest possible project scope adopted Documentation MUST describe data and behavioural requirements for each use case/user story, and possible misuses of data. Documentation MUST describe selection of privacy controls/services and they apply to functional requirements. Scope MUST include “privacy functionality” (relates to PMRM functions/services) The OASIS PMRM Privacy Use Case Template is RECOMMENDED for describing privacy requirements. Documentation MUST include identification of privacy architectural design principles Documentation MUST contain a Privacy Architecture Documentation MUST contain description of the Business Model showing personal data flows for software services 3.2–Systematic and Auditable: A systematic, principled approach should be adopted that relies upon accepted standards and process frameworks, and is amenable to external review. Acknowledged software engineering process/methodology adopted Metrics applied Privacy Metrics, e.g. effectiveness, monitored Architecture documents SHOULD include privacy view (this does not apply only to software engineering do Documentation MUST identify the software engineering process/methodology used Documentation SHOULD contain evidence of monitoring of privacy metrics 3.3–Review and Assess: Detailed privacy impact and risk assessments should be used as a basis for design decisions. Completed PIA and/or TRA Completed Priority Matrix of Privacy Controls/Threats from Risk Analysis Documentation MUST contain a PIA Documentation SHOULD contain TRA for privacy 3.4–Human-Proof: The privacy risks should be demonstrably minimized and not increase through use, misconfiguration, or error. Appropriate privacy failsafe mechanisms adopted Documentation SHOULD describe configuration parameters and their impact on privacy risks Software SHOULD warn about events that increase privacy risks (including misconfiguration, errors or misuse). These warnings MUST be documented Documentation MUST contain identification and description of privacy controls. 4. Full Functionality — Positive-sum, Not Zero-sum
20140411%20-%20Operationalizing%20PbD%20Principles%20-%20Overview_v42.docx