4. Full Functionality: 4.1–No Loss of Functionality: SHALL treat privacy-as-a-functional Positive Sum, not Embedding privacy adds to the requirement (see section 2.1.4), 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 should be published for others to emulate and become best practices. 5. End-to-End 5.1–Protect Continuously: SHALL be produced for all stages of Lifecycle Protection Personal data must be the software development lifecycle continuously protected across the from referencing applicable principles, entire domain and throughout the policies, and regulations to defining data life-cycle from creation to privacy requirements, to design, destruction. implementation, maintenance, and retirement. 5.2–Control Access: Controls on access to personal data should be reference requirements, risk commensurate with its degree of analyses, architectures, design, sensitivity, and be consistent with implementation mechanisms, recognized standards and retirement plan, and sign-offs with practices. respect to privacy and security. 5.3–Security and Privacy reference security metrics AND Metrics: Applied security privacy properties and metrics standards must assure the designed and/or deployed in the confidentiality, integrity and software, or monitoring software, or availability of personal data and otherwise in the organization, and be amenable to verification across partnering software systems or organizations. Applied privacy standards must assure user/data subject comprehension, choice, consent, consciousness, consistency, confinement (setting limits to collection, use, disclosure, retention, purpose), and context(s) around personal data at a functional level, and minimized identifiability, linkability, and observability; maximized traceability, audibility and accountability at a systems level, and be amenable to verification. 6. Visibility and 6.1–Open Collaboration: Privacy SHALL reference the privacy policies Transparency requirements, risks, and documentation of all other implementation methods and collaborating stakeholders outcomes should be documented
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 should be published for others to emulate and become best practices. SHALL treat privacy-as-a-functional requirement (see section 2.1.4), 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. 5. End-to-End Lifecycle Protection 5.1–Protect Continuously: Personal data must be continuously protected across the entire domain and throughout the data life-cycle from creation to destruction. 5.2–Control Access: Controls on access to personal data should be commensurate with its degree of sensitivity, and be consistent with recognized standards and practices. 5.3–Security and Privacy Metrics: Applied security standards must assure the confidentiality, integrity and availability of personal data and be amenable to verification Applied privacy standards must assure user/data subject comprehension, choice, consent, consciousness, consistency, confinement (setting limits to collection, use, disclosure, retention, purpose), and context(s) around personal data at a functional level, and minimized identifiability, linkability, and observability; maximized traceability, audibility and accountability at a systems level, and be amenable to verification. SHALL be produced for all stages of the software development lifecycle from referencing applicable principles, policies, and regulations to defining privacy requirements, to design, implementation, maintenance, and retirement. reference requirements, risk analyses, architectures, design, implementation mechanisms, retirement plan, and sign-offs with respect to privacy and security. reference security metrics AND privacy properties and metrics designed and/or deployed in the software, or monitoring software, or otherwise in the organization, and across partnering software systems or organizations. 6. Visibility and Transparency 6.1–Open Collaboration: Privacy requirements, risks, implementation methods and outcomes should be documented SHALL reference the privacy policies and documentation of all other collaborating stakeholders
pbd-se-v1_0-wd04%20R4.docx