Sign off with PbD-SE methodology check list This step verifies that proper documentation exists. A checklist MAY be useful for managers and responsible stakeholders to assess, at a glance, whether PbD principles are considered and privacy documentation generated and/or referenced. Table 3.1 shows an example RACI chart that can act as a checklist. It is expected that organizations will have different RACI assignments according to their specific contexts (e.g. size and organization). Table 3.1 RACI Chart for Software Engineers PbD-SE Methodology Step Documents to be referenced/produced Privacy Resource Project Mgmt. Third Party item 3.1 Reference Organization-al Readiness Privacy Policy Document CI RACI CI ACI I CI ✓ Privacy Program in Organization I RACI CI AI I I ✓ 3.2 Privacy Requirements & Reference Architecture Functional Privacy Requirements, preliminary controls identification & hooks to Reference Architecture RA RACI ACI AI RAI CI ✓ 3.3 Conduct Risk and Privacy Property Analysis Traceability diagrams and other documentation to show consideration of privacy properties CI RACI CI AC CI - ✓ Risk analysis Final controls identification CI RACI CI ACI CI - ✓ 3.4 Identify Privacy Resource Allocation Privacy resource allocation to SE team I RACI RI AI I - ✓ 3.5 Create RACI for Producing Artifacts RACI assignment to artifact production RCI CI RACI AI - - ✓ 3.6 Customize Privacy Architecture Privacy Architecture (incl. services identification) RA ACI A CI AI I - ✓ 3.7 Conduct Periodic Review Review of Artifacts throughout the SDLC RA CI RACI AI - - ✓
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 SHALL include software retirement plan from a privacy viewpoint 3. Privacy Embedded into Design 3.1–Holistic and Integrative: Privacy commitments must be 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 basis 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 Template or the more comprehensive OASIS PMRM methodology [2013] for identifying and documenting privacy requirements. 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 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 should be published for others to emulate and become best practices. 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 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. SHALL reference requirements, risk analyses, architectures, design, implementation mechanisms, retirement plan, and sign-offs with respect to privacy and security. SHALL 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
throughout the development lifecycle and communicated to project members and relevant stakeholders. 6.2–Open to Review: The design and operation of software systems should demonstrably satisfy the strongest privacy laws, contracts, policies and industry norms (as required). 6.3–Open to Emulation: The design and operation of information technologies and systems should be open to scrutiny, improvement, praise, and emulation by others. SHALL include description of contextual visibility and transparency mechanisms at the point of contextual interaction with the data subject (user) and other stakeholders for data collection, use, disclosure, and/or elsewhere as applicable SHALL describe any measurements incorporated in the software, or monitoring software, or otherwise to measure the usage and effectiveness of provided privacy options and controls, and to ensure continuous improvement. SHALL describe placement of privacy settings, privacy controls, privacy policy(ies), and accessibility, prominence, clarity, and intended effectiveness. 7. Respect for User Privacy 7.1–Anticipate and Inform: Software should be designed with user/data subject privacy interests in mind, and convey privacy attributes (where relevant) in a timely, useful, and effective way. 7.2–Support Data Subject and Direction: Technologies, operations and networks should allow users/data subjects to express privacy preferences and controls in a persistent and effective way. 7.3–Encourage Direct User/Subject Access: Software systems should be designed to provide data subjects direct access to data held about them, and an account of uses and disclosures. SHALL describe user privacy options (including access), controls, user privacy preferences/settings, UI/UX supports, and user-centric privacy model. describe notice, consent, and other privacy interactions at the EARLIEST possible point in a data transaction exchange with a user/data subject or her/his automated agent(s) or device(s).