How can I support the IOPD and become part of the community?

• Become an Ambassador – Help spread the word and showcase your involvement with the Institute!
  • Our Founding Ambassadorship expires December 2024.  The best part of this membership is that the one-time fee covers you for the life of the IOPD and you are listed as a Founding Ambassador on the website.
  • Sustaining Ambassadorship renews annually.  Benefits for both include:
    • Access to update dashboard with the latest in updates and roadmap of the organization
    • Access to draft standards and ability to submit comments to the Standards Committee
    • Public Listing on the IOPD website
    • Discounts with training partners 
    • Stay up to date with our awesome Calendar and add your events for the community to see!
    • Check out our amazing Resources and contribute your own!
• Join as a Corporate Member – we have three tiers plus a Training Partner membership.  
  • Help recruit Corporate Members. If your company or association is interested in sponsoring the IOPD please get in touch. We’re on the hunt for forward thinking businesses that want to be on the forefront of privacy in the modern age.  Some benefits include:
  • Support your privacy engineering program by bringing them to the IOPD
  • Be recognized as a Privacy by Design innovator
  • Brand affiliation
  • Featured in IOPD social media
  • Company related privacy listings on the events and blog pages
  • Access to Privacy Engineering experts to crowdsource solutions
  • Free templates and forms used with the Standard
• Apply the standard by becoming a BETA partner.  

Help us find some first-mover companies that want to apply the standard to their organization. Contact us if that’s your company or you know one that would be a good fit.

How can organizations start the journey towards certification?

• The first step is to download the Standard and start implementing it. Oftentimes companies want certification but don’t have in place the necessary components. It’s like asking a judge to rate your cake, but you haven’t baked a cake yet. Download the Standard, make sure you’re doing everything it says, then let’s chat about certification. 

How will certification work? Who does that? What is the cost for certification?

• We’re currently looking for Beta Partners to be the first set of companies to get certified, so certification is free. This does not include any third  party consulting or assessment services. 

What kind of involvement and time commitment are you expecting from committee volunteers?

• We generally ask 3-4 hours per month, but some put in less and some put in more. 
• Generally, we are looking for:
  • People who are good at networking to help us build paid corporate membership. 
  • People who can write blogs related to privacy by design.
  • People to help promote and market the IOPD. If you love posting to social media, are passionate about privacy, and have a good network, you are our person.
  • People to help provide detailed guidance and illustrative controls and use cases for  the Standard.
  • Privacy by design experts to speak at our monthly Privacy Engineering and Technology Education Discussion (PETed) webinar.
  • Committee chairpersons.  If you have experience leading a committee, we would love to talk with you.
  • Specifically, we are looking for volunteers as part of the GDPR Article 42 and Childrens/Ed Tech Committees.

How can we volunteer?

• Apply to become an Ambassador with indication that you are interested in joining a committee!

How will the IOPD ensure compliance with new and evolving privacy laws?

• The Standard is jurisdiction agnostic. Your Risk Model may be based on the social norms of the geographies in which you operate and laws may inform you of which risks people there are most concerned about (hence, why they created the law). 

Will regulators accept the Standard as a meaningful demonstration of compliance?

• We have an Ad-Hoc Committee looking into approval as a certification schema under GDPR Article 42.

What size or type of company is best for implementing the Design Process Standard?

• Medium and large businesses are probably going to be in the best position to have the resources and formality in their design processes to incorporate privacy and the components from the Standard. 
• Some small businesses, especially startups who are creating privacy first products or services or who have business clients that are particularly privacy sensitive. 
• Companies that have an Environmental, Social and Governance (ESG) program would also be well positioned to implement the Standard.

What are the main differences between the IOPD Standard and the ISO Standard (please note you have to pay for the ISO 31700 Standard)?

• See our blog which compares and contrasts them.  https://instituteofprivacydesign.org/2023/05/08/privacy-by-design-standards-iso-v-iopd-compare-and-contrast/

What risk model would the IOPD recommend?

• The IOPD Design Process Standard leaves a risk model to the implementing corporation. The Standard is applicable across industries, jurisdictions and all types of products, services and business processes. Because of that, specifying a risk model for all would be inappropriate. The IOPD is looking into providing guidance for certain scenarios (such as in EdTech or Children’s mobile apps) of an appropriate risk model. 
• Some common models include:
  • LINDDUN
  • Solve Taxonomy
  • FAIR

Can the Standard be tracked back to the Privacy by Design Principles?

• There is not a one to one mapping as the Standard was not developed with the Principles as a blueprint. However, many of the principles can be found in some of the Standard’s components:
  • Proactive not reactive; preventive not remedial
    The objective of the  Standard is meant to drive organizations to consider privacy risks up front, to be proactive. 
  • Privacy as the default setting
    This will be more appropriately applied for our second standard which will require that the initial configuration consider and reduce privacy risks. 
  • Privacy embedded into design
    The  Standard covers the ideation and development phases of a product or service lifecycle, requiring mitigations for privacy risk to be included in those phases. 
  • Full functionality – positive-sum, not zero-sum
    Trade off analysis requires looking for optimal solutions to resolve tension between different system qualities. 
  • End-to-end security – full lifecycle protection
    The design process requires considering risks from ideation, to development to deployment. 
  • Visibility and transparency – keep it open
    The point of the  Standard and certification to the  Standard is to allow companies to be transparent about their development process, providing assurance to customers, be they businesses or consumers, of their incorporation of privacy. 
  • Respect  for Users
    Risk model requires that the organization must focus on risk to individuals and not just to the organization. 
• Ann Cavoukian, Privacy by Design Developer “I’m delighted about the approach being taken by the Institute of Operational Privacy Design and how they can further the cause of getting organizations to proactively build privacy into their products and services. Many people at the IOPD have been tireless advocates for Privacy by Design and it is wonderful to see their vision come to realization.”

Is there a registry of case studies and lessons learned from applying this?

• Not yet, we hope to build this in the future. In fact, we have a committee working on applying the Standards to the Children’s and EdTech markets, trying to develop guidelines and appropriate risk models for products and services in those spaces.  

Does this piece of work tie to a maturity model or proposed methods to be used to evaluate over time?

• The Standard covers a companies’ design process. As a process, it is subject to and independent of the maturity of that process. We recommend the MITRE Privacy Maturity Model. 
• Your design process could be ad-hoc, not documented or consistent, however you could still be applying all the process components of the Standard: system identification, requirements, trade off analysis, risk management, verifying assumptions and monitoring context. You’d benefit though from having a more mature process, having all the components documented in policy and procedure documents. In fact, if you were applying for certification, you’d most certainly need to produce these documents to get certification. 

Are there some quality attributes that should be considered?

• There are dozens of quality attributes and many companies already establish them to a degree, but often they are unstated or implicit. Ones that are related to privacy include securability, useability, transparency and confidentiality. One key to successful implementation of the Standard is the ability to articulate these attributes and acceptable levels, especially to the extent they have conflicts or support the quality attribute of privacy.  

What are some privacy requirements? What would a Requirements Document Policy look like?

• We don’t use the term privacy requirements in the Standard. In the Identify Requirements Component, we’re talking about requirements for your product, service or business process unrelated to privacy. For instance, maybe you require that your service have registration functionality, allowing consumers to register an account. Another requirement might be to have the system send birthday notifications.  These are functional requirements of what you’re building.  You then have non-functional requirements, such as useability or interoperability. These are often called quality attributes. The component of the Standard requires you to explicitly articulate your requirements. This allows you to perform trade off analysis (one of the other components) and has implications for privacy risks which may require mitigations. 

Do you plan to do a crosswalk between this  Standard and the NIST Privacy Framework?

• We have not planned it, but it is certainly a possibility. If you would like to volunteer to work on this, please let us know. 

Can you provide more context on threat modeling? 

• Threat modeling is part of the Contextualizing Risk Factors component of the Standard. A model is a simplification of the real world. Threat modeling is the idea of identifying and categorizing certain types of threats, privacy threats in this case. Generally, for a threat you have an actor and a means. For instance, one threat might be a company, through its mobile app, collects data on users of the app. Another, might be, an advertiser aggregates data from multiple apps into a dossier about an individual. Lets say your risk model included SPAM as a risk of concern. Threat modeling would help you uncover opportunities by threat actors to SPAM.  In other words, who in your system has contact information and an incentive to send out unsolicited commercial messages. 

Will detailed guidance and illustrative controls be developed and shaped?

• We would like to, but need volunteers willing to work on this.