IOPD Process Design Standard
Earlier references to Privacy by Design

History of Privacy by Design
Some people might be familiar with Dr. Ann Cavoukian’s Seven Foundational Principles of Privacy by Design.
To learn more. In 2010, Dr. Cavoukian’s idea was recognized as a fundamental component of privacy protection in a historic resolution at the International Data Protection and Privacy Commissioners (IDPPC).

PBD Timeline
Early 2012
In 2012, the U.S. Federal Trade Commission (FTC) recognized Privacy by Design as one of its three recommended practices for protecting online privacy in its report entitled, Protecting Consumer Privacy in an Era of Rapid Change. [Link to Document]
Jump to 2018
In 2018, Data Protection by Design and Default was embedded in the General Data Protection Regulation (GDPR) through Article 25. [Link to Reference]
20 Years Later
Now over 20 years later, the IOPD is creating a repeatable and comprehensive standard so companies can have confidence that they have considered privacy in the lifecycle of their products, services, and business processes. Below we have outlined the elements your company must go through to be certified.
Process Standard Components
The organization should establish data governance founded on generally accepted best principles, practices or framework endorsed by its leadership that determines the management of privacy risk and the levels of acceptable risk.
The organization must incorporate either (a) one or more privacy risk models as a basis for privacy risk analysis, (b) a process by which project-specific privacy risk models are developed as a basis for privacy risk analysis, or (c) a combination of (a) and (b).
Elements of the Lifecycle Process
The organization must describe the service or product in sufficient detail for an independent assessor to understand (a) the product mission or business problem being solved, (b) potential at-risk users, (c) categories of data being collected and how the data will be used, (d) who will have access to the data, both internally and externally, and the purpose of the data, and (e) key privacy principles, objectives and product-specific contextual privacy considerations and how the organization has addressed them.
The organization must explicitly define privacy-related functional and non-functional requirements. Functional requirements relate to those elements that directly support the project’s purposes or goals. Non-functional (also known as quality attribute) requirements relate to those elements that support privacy but do not directly contribute to achieving the project’s purposes or goals.
The organization considers a variety of solutions because there is seldom any single obvious best solution or approach in a project. These constitute trade-offs that must be taken into account when assessing the acceptability of any specific design. What is lost and what is gained with any particular design or approach must be explicitly recognized.
The organization identifies and documents the context surrounding the target product, service or business process.
The organization should establish data governance founded on generally accepted best principles, practices or framework endorsed by its leadership that determines the management of privacy risk and the levels of acceptable risk.
The organization determines whether or not they made the right decisions and tests to ensure it has mitigated risks.
The organization identifies and documents the context for monitoring changes to the product, services, or process that may alter privacy requirements, identity problems or deficiencies, and inform appropriate stakeholders of the need for corrective action.