data privacy

Data Privacy Must be Part of Your Data Strategy

Complying with a landscape of changing requirements and expectations is harder when your approach is piecemeal. Companies, big and small, invite pain when they consider privacy as an afterthought.  Privacy becomes a janky bolt-on, implemented inconsistently and without cross-function coordination. This often leaves substantial gaps in privacy programs, allowing everything from the accidental (the emergency software patch that led to sensitive data to be logged in plain text) to the intentional (how do we circumvent the privacy program to get back to business?). Most visibly it manifests in degraded customer experiences (who hasn’t sat through multiple, often meaningless, variations of the same “important privacy notices…” in a single call).

The road to piecemeal privacy programs begins when privacy is understood solely through the lense of compliance. Leaders who delegate the formulation of a company’s privacy response to compliance and legal functions risk creating a culture of complacency. Everyone’s responsibility is to tick the privacy box. Critical decisions are made at distance to the customer experience and business objectives. Opportunities for efficient, innovative and pragmatic responses to privacy are missed.

article continued below

register for our upcoming virtual event

Is there a better way?

Caserta’s view is that there are three key ingredients to embedding a successful privacy program:

  1. Understanding privacy as respect
  2. Embracing Privacy-by-Design
  3. Building capability in privacy engineering

We feel that these three suggestions comprehensively address privacy across people, processes and platforms. These are not intended to replace the need for compliance checks and balances measured through a mature audit framework. What they provide is forming the basis for a whole of organization culture around privacy that can drive customer centric outcomes in ways that compliance programs cannot.

 

Data Privacy as Respect

At the core of GDPR and CCPA are notions of respect for individuals. To respect customers, organizations need to be up front with customers about the data that they collect, the reasons why they need that data, and who else might have access to it. But respect requires that going beyond one-time disclosure statements. It means having a clear commitment to respecting customer privacy from the board down. It means being intentional: customers should never be shocked to discover that their data is being used in a particular way or sold downstream. It also means acknowledging that your organization and your customer will change.  When your customers change, it shouldn’t be painful to adjust or withdraw their consent; and there should be systemic guarantees that their wishes are acted upon without delay. When you change, those changes should be easy for the customer to understand and should accommodate “the spirit” of the consents already provided: assuming opt-in isn’t a solution.

Data Privacy-by-Design

Privacy must be incorporated into systems and products by default. This means building privacy controls, protocols, standards and measures into both the parts of systems that customers can see (eg. settings and preferences) and the parts they can’t (your people, platforms and processes). Privacy-by-Design provides 7 principles to help organizations achieve this:

  1. Proactive not Reactive; Preventative not Remedial: privacy comes before-the-fact, not after.
  2. Privacy as the Default Setting: customers shouldn’t have to take any action to protect their privacy
  3. Privacy Embedded Into Design: seeing privacy as an essential components of core functionality
  4. Full Functionality – Positive-Sum, not Zero-Sum: taking the time to identify “win-win” outcomes rather than false dichotomies
  5. End-to-End Security – Full Lifecycle Protection: strong security as an essential element of systems and cradle-to-grave lifecycle management
  6. Visibility and Transparency – Keep it Open: consider independent verification and default to visibility of processes (such as access to data) by default
  7. Respect for User Privacy – Keep it User-Centric: empower users through user friendly and privacy protecting defaults

Building Capability in Privacy Engineering

Design patterns alone are insufficient. A full appreciation of privacy from a systems and engineering perspective is needed. Privacy understood as a system of actors, components and constraints is the domain of the burgeoning field of privacy engineering. Like security engineers, privacy engineers bring deep technical skills, a wealth of practical experience and domain expertise to bear. Privacy engineers are familiar with:

  • Regulatory context: what privacy laws and frameworks aim to achieve and their minimum expectations
  • Industry context: how the regulatory context applies to a particular industry or technical domain, and how edge cases are handled
  • Organizational context: awareness of the cross-functional who, what, where and why
  • Architecture best practices: industry best practices from the structure of review boards to specific implementations with a particular focus on delivering transparency to solutions
  • Design considerations: how to conceptualize privacy from the consumer’s point of view
  • Technical solutions: awareness of specific products and frameworks that can assist

Privacy engineers help organizations to identify sensible and pragmatic patterns to ensure that mature approaches to privacy are adopted across the organization; from low level application development up to the design of products and support.

Early investments to build capability in and around privacy engineering will help organizations to stay in front of regulatory innovations and maturing consumer expectations.

Thinking about data projects

Engineering solutions that satisfy the need for privacy requires a broad knowledge of the technical capabilities of the platform components available to you. This knowledge is needed during solution conception, architecture, design and build phases of a project. Without this awareness, you can engineer yourself into a corner. Equally important is being aware of Privacy-by-Design principles even if your organization hasn’t yet adopted them.

For example, a core tenant of good data ecosystem architecture is immutable data. Once we store data, we put controls in place to ensure that it doesn’t change. Immutability of data isn’t just an architectural principle, it’s a feature at the foundation of many of the core technologies that make analytics at scale possible.

On the surface, data immutability creates a conflict in the application of the right to be forgotten (that is, a customer’s ability to have themselves completely removed from an organization’s system unless there is some other overriding legitimate interest such as a statutory requirement). As a result, it might be tempting to split the architecture so that data which is materially private is kept mutable, while everything else utilizes the immutable store. But this complicates the architecture and introduces problems at scale.

Data immutability vs the right to be forgotten is an example of a false dichotomy. The answer is creative use of encryption. This allows us to protect customer data and render it unreadable as and when the need arises.. An additional benefit is hardened security and privacy across the platform. Through considered and intentional design we can leverage all of the advantages that immutable data provides while protecting organizations and respecting customers.