Privacy by Design Standards: ISO v IOPD Compare and Contrast

While both standards use the term “requirements” and the importance of them incorporating privacy, the term is used differently in each standard. We think understanding this distinction is important. Using “requirements” correctly and concurrently is one of the ways these two standards can work together. The ISO Standard features 27 high-level technical and business specific privacy-related requirements for the organization wishing to apply the standard. Most of the requirements start out with “The organization shall…” One example is: 

“The organization shall determine consumer needs related to the processing of their PII by products designed and developed for consumers.”

The standard goes on to provide a detailed explanation and guidance. Some of the ISO Standard business requirements actually require specific system-level requirements. “The organization shall design consumer-configurable privacy settings and privacy management measures taking account of the capabilities of consumers and their potential disabilities.” This describes a business requirement (a part of the design process) to include a feature (a system requirement of the product or service being designed). This latter use of the word requirement comports with the use of the term in the IOPD Standard, namely to describe the functional and non-functional requirements of the system (product, service, or business process) being designed. Because the IOPD Standard states that an organization should establish requirements but doesn’t define what they are, an organization could use some of the ISO Standard’s requirements, namely those, like the one above, that require system requirements. It can get confusing, hence why it’s important to elucidate the distinction.

Note, what the ISO Standard calls a requirement (a necessary element for the organization to follow the standard), the IOPD Standard refers to as a component ( a “necessary” component the organization’s design process must have). 

Accountability is a hallmark of good business governance and a key aspect of successful privacy programs. Both standards require accountability, though they approach it slightly differently. The ISO Standard requires an accountable person for the overview of the product life cycle (4.5.1) and for each function in the design or operation of privacy controls (4.6.1). The IOPD Standard takes a little more holistic and organizational approach and requires accountability as a prerequisite at the governance level, stating that there must be “ownership or accountability for each of the design process points.” This highlights the differences and points to the compatibility of the two. The IOPD Standard presumes good governance as a prerequisite, whereas the ISO Standard includes more granular organizational features as part of their requirements set. Similar to how specific system level requirements from the ISO Standard can be used for those applying the IOPD Standard, the relevant organizational requirements could be used as evidence of meeting the IOPD Standard for governance. 

Both standards take privacy risk into consideration but, as you might suspect, approach it slightly differently. The IOPD Standard is centered on risk and avoiding or mitigating risks to individuals. The IOPD Standard bakes this concept into the standard by requiring a defined risk model at the outset that enables the organization to consistently evaluate risk across all different systems. The risk model must identify threats, vulnerabilities, adverse consequences to people, and quantitative or qualitative means of measuring the likelihood and severity of those consequences. Measurement is key because organizations must also determine their risk tolerance and appetite to compare whether the risk exceeds that tolerance. While the ISO Standard requires privacy risk management, including conducting a risk assessments, that requirement is vague and relates to its definition (“effect of uncertainty on privacy”). Here, in contrast to the above discussions, the IOPD Standard can support the ISO Standard by providing a specific approach, requiring first a risk model, then a risk assessment (contextualizing factors from the model, eliciting issues, assessing the risk) and finally, responding to the risk through system design.

The difference in the two standards reflects where they are primarily used in the SDLC. The ISO Standard primarily occurs during requirement gathering and the design phases. Whereas the IOPD Standard is an overlay across all phases of the life cycle:  requirements gathering, design, build, verification, and production.  

While taking different approaches, the two standards are complementary in nature and elements from each can be used to support the other. Obviously, we here at the IOPD have our preferences, but we’re glad to see that the two standards are not in conflict and will ultimately help to bring about a more privacy-friendly world.