in compliance with applicable and where they apply to privacy laws and regulations functional requirements and risks. 2.3–Engineering Controls: Strict SHALL include software retirement limits should be placed on each plan from a privacy viewpoint phase of data processing lifecycle engaged by the software under development, including: Limiting Collection; Collecting by Fair and Lawful Means; Collecting from Third Parties; Limiting Uses and Disclosures; Limiting Retention; Disposal, Destruction; and Redaction 3. Privacy 3.1–Holistic and Integrative: The OASIS PMRM Privacy Use Case Embedded into Privacy commitments must be Template RECOMMENDED for Design embedded in holistic and identifying and documenting privacy integrative ways. requirements. 3.2–Systematic and Auditable: SHALL contain description of A systematic approach should be business model showing traceability of adopted that relies upon accepted personal data flows for any data standards and process collected through new software frameworks, and is amenable to services under development. external review. include identification of SHALL 3.3–Review and Assess: privacy design principles Detailed privacy impact and risk SHALL contain a privacy architecture assessments should be used as a SHALL describe privacy UI/UX design for design decisions. SHALL define privacy metrics 3.4–Human-Proof: The privacy risks should be demonstrably SHALL include human minimized and not increase checklists for software through operation, engineering artifacts misconfiguration, or error. SHALL include privacy review reports (either in reviewed documents or in separate report) 4. Full Functionality: 4.1–No Loss of Functionality: treat privacy-as-a-functional Positive Sum, not Embedding privacy adds to the requirement (see section XXX), i.e. Zero-Sum desired functionality of a given functional software requirements and technology, process or network privacy requirements should be architecture. considered together, with no loss of functionality. 4.2-Accommodate Legitimate Objectives: All interests and SHALL show tests for meeting privacy objectives must be documented, objectives, in terms of the operation desired functions articulated, and effectiveness of implemented metrics agreed, and trade-offs privacy controls or services. rejected, when engineering software solutions. 4.3–Practical and Demonstrable Results: Optimized outcomes
in compliance with applicable laws and regulations 2.3–Engineering Controls: Strict limits should be placed on each phase of data processing lifecycle engaged by the software under development, including: Limiting Collection; Collecting by Fair and Lawful Means; Collecting from Third Parties; Limiting Uses and Disclosures; Limiting Retention; Disposal, Destruction; and Redaction and where they apply to privacy functional requirements and risks. SHALL include software retirement plan from a privacy viewpoint 3. Privacy Embedded into Design 3.1–Holistic and Integrative: Privacy commitments must be embedded in holistic and integrative ways. 3.2–Systematic and Auditable: A systematic approach should be adopted that relies upon accepted standards and process frameworks, and is amenable to external review. 3.3–Review and Assess: Detailed privacy impact and risk assessments should be used as a for design decisions. 3.4–Human-Proof: The privacy risks should be demonstrably minimized and not increase through operation, misconfiguration, or error. The OASIS PMRM Privacy Use Case Template RECOMMENDED for identifying and documenting privacy requirements. SHALL contain description of business model showing traceability of personal data flows for any data collected through new software services under development. SHALL include identification of privacy design principles SHALL contain a privacy architecture SHALL describe privacy UI/UX design SHALL define privacy metrics SHALL include human checklists for software engineering artifacts SHALL include privacy review reports (either in reviewed documents or in separate report) 4. Full Functionality: Positive Sum, not Zero-Sum 4.1–No Loss of Functionality: Embedding privacy adds to the desired functionality of a given technology, process or network architecture. 4.2-Accommodate Legitimate Objectives: All interests and objectives must be documented, desired functions articulated, metrics agreed, and trade-offs rejected, when engineering software solutions. 4.3–Practical and Demonstrable Results: Optimized outcomes treat privacy-as-a-functional requirement (see section XXX), i.e. functional software requirements and privacy requirements should be considered together, with no loss of functionality. SHALL show tests for meeting privacy objectives, in terms of the operation and effectiveness of implemented privacy controls or services.
pbd-se-v1_0-wd04R2-sabo.docx