Cyber Risk Advisory

Privacy by design: Building customer trust

Paul Sonntag png

Paul Sonntag

Director, Privacy

Blog Images 2022 04 20 Tile

Historically, the question of privacy has been the domain of the legal community. This makes perfect sense, because privacy has its roots almost exclusively in laws and regulations. The EU General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and similar regulations that are cropping up with increasing frequency around the world create a thorny regulatory environment, and figuring out how this network of laws applies to their respective organizations is a task best suited to the legal profession.

Historically, the question of privacy has been the domain of the legal community. This makes perfect sense, because privacy has its roots almost exclusively in laws and regulations. The EU General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and similar regulations that are cropping up with increasing frequency around the world create a thorny regulatory environment, and figuring out how this network of laws applies to their respective organizations is a task best suited to the legal profession.

More recently, some companies are incorporating privacy principles more deeply into their compliance and risk management programs because they understand the need to demonstrably meet these regulatory requirements. However, organizations that treat privacy strictly as just another compliance obligation are likely to miss key privacy-related risks and are also forsaking a significant competitive opportunity.

History of the problem

Privacy regulation and compliance have a long and spotty history, particularly in the United States. Regulations such as the Privacy Act of 1974, the Children's Online Privacy Protection Act of 1998 (COPPA), the Health Insurance Portability and Accountability Act (HIPAA), and a few others, were niche concerns from a consumer's perspective, and they were too sector-specific to make a measurable impact on the public conversation. This resulted in a free-for-all stampede to collect personal data. Many companies took the attitude that if a particular data collection activity wasn't specifically illegal, or that the risk of being caught and sanctioned was low, then it was fine to proceed without further consideration.

The 2016 ratification of the EU GDPR in changed everything. The GDPR was developed in response to three major issues:

  1. The rise of data-intensive digital services driven by online advertising. Life was migrating online, creating opportunities for data collection and use that didn't exist in 1995 when the previous EU regulatory framework, the Data Protection Directive, was enacted.
  2. The need for a level marketplace to prevent larger companies from dominating a market by locking up customer data.
  3. The problem of enforceability by creating a consistent penalty structure.

By the time the GDPR went into effect in 2018, privacy was rapidly becoming a mainstream topic. The growing discussion of its potential impact by "GDPR Day" in May 2018 raised the profile of the privacy topic just as the Cambridge Analytica scandal was breaking. Consumers were becoming increasingly wary of the number and variety of companies collecting their data and using it for unclear purposes. The rapid passage of the CCPA the following year was testament to that growing backlash.

Why regulation isn't the biggest problem

In the years that Coalfire has worked with various organizations to develop their privacy programs, we've noticed that while our clients typically start the conversation with regulatory worries, the real problem surfaces as deteriorating customer trust. Our B2C clients have seen a sharp uptick in customer support cases concerning personal data, and the impact to sales is noticeable because customers believe our clients' products are "stealing" data, or that it's being sold without their knowledge. Our B2B clients feel the residual effects, because B2C customers are reluctant to use their services unless they're also backed with strong privacy measures.

Designing for privacy

For those organizations that sell data-intensive products with privacy implications, Coalfire typically finds product lifecycles that look like this:

  1. New product or feature is proposed
  2. Technical and feasibility analysis is completed
  3. Product timelines and budgets are determined and approved
  4. Functional requirements or user stories are developed and refined
  5. Product is developed and tested
  6. The pre-release code undergoes some manner of security and compliance checkpoint
  7. Release authorization is granted via change control or something similar
  8. Marketing and sales materials are completed and propagated
  9. Product is released to production

Slightly more sophisticated organizations might touch on security and compliance earlier in the process, possibly when functional requirements and/or user stories are being developed, and those concepts may also show up in coding standards and style guides. Regardless, if user privacy is considered at all, it's only after the product design is complete. That leaves the project team to fit the product in around existing privacy controls, or more often, find a workaround . The result is a shipped product that doesn't behave the way target customers find easy to trust.

True privacy by design is not strictly a compliance problem, but rather a product design problem. It requires a broader range of skills and disciplines, including marketing, product development, and legal counsel, and each needs to be involved earlier in the product lifecycle. Expanding on the first step of our sample lifecycle:

  1. Marketing: Determine market potential. What would customers want from this new product or feature? How much personal information would customers be comfortable providing, and how would they expect that information to be used?
  2. Legal: What are the legal and jurisdictional requirements?
  3. Product development: How might the product achieve its objectives in a way that matches customer expectations and legal requirements? What is the least amount of data the product could collect and still meet the requirements?
  4. Marketing: How do we describe the product’s use of personal data to the customers in a way that enables them to trust the product and form an attachment to it? Note: this is not the privacy policy!

This change confers two advantages: First, it simplifies privacy compliance, because the product has been designed to meet the regulatory bar before the functional requirements are determined or the first line of code is written. Second, and most importantly, it results in a product that customers can trust and which makes privacy both an inherent feature and a product differentiator. In a market where customers are increasingly distrustful of companies they believe harvest data against their wishes, building that trust can be a powerful differentiator.