Privacy by Design: Distinguishing Domains for Central Teams

Protecting Personal information is every one’s job, and we do it to ensure we respect the privacy of individuals and grain the necessary trust to maintain a shared value relationship with those individuals. This is the Why we do it. What is good for the induvial is good for the business.

Hence GDPR calls this out in in article 25:

• Privacy by Design means that data protection must be an integral part of the design and operation of any system, service, or product that processes personal data. Organizations should implement technical and organizational measures to ensure privacy is embedded in all stages of data processing.
• It is not just about securing data but also about minimizing the amount of personal data collected, limiting its use, ensuring accuracy, and deleting it when no longer needed.

For the purposes of simplicity, we will refer to the main target of privacy to be the Consumer(b2c) and Customer (b2b) given this is where the highest risk is, although we recognise that this includes all personal data an organisation needs to process for legitimate purposes, or has consent to process e.g. Employee Data (b2e).

This blog post outlines the How (we make it part of the Operation, see definition)and What and When we will execute on the different technology elements that are necessary to establish a privacy by design environment. Sequencing and alignment with broader corporate initiatives is paramount and we can not think of this as purely a compliance requirement although compliance is the path to ensuring digital trust.

Approach to x by design

Anything by design embeds functional and non-functional requirements into the products, processes and technology of the business flow of work. In this manner we are shifting left requirements and solving it where it the problem or challenge is created or more important, where the context is. A great quote I found about vulnerability management bring this to life.

This approach will minimize building in quality after the fact into a process or increasing oversight process or tools to compensate for broken process or technology. This roadmap focuses on addressing the root cause.

Solving this addresses the most important challenge in distributed organizations, and that is the one of accountability. Accountability for Privacy, in this case needs to primarily land with the business process and technology that manages the customer and consumer data. Replace the word privacy for security and it also work. Test it.

The first key differentiator is to distinguish two separate products, whilst related, the order and sequence of design and operations is fundamental to be effective and efficient. They address a common concern (why), but focus on the how and what needs to be done in fundamentally different way and target different secondary personas within the organization.

Note this pattern can be seen in many other domains, like information Security, Compliance, financial compliance etc. Think of central control functions in general or anything we setup a central function for to get other to do things.

Differentiating Internal Privacy Products and Business-Embedded Privacy Product Features

In the context of managing privacy within an organization, it's essential to distinguish between two categories of privacy products and features:

1. Internal Privacy Products for Privacy or Privacy for Privacy. (remember this also works for Security for Security ;-))
2. Business-Embedded Privacy(or security) Products and Features

While these categories are interdependent, their roles and functionalities differ significantly. Understanding and communicating these distinctions helps ensure clarity in implementation, accountability, and governance. It helps be explicit so there are NO turf wars.🥷

This distinction also helps provide clarity for the Architecture domain and hence ensuring we have the right architecture supporting the initiatives.

Internal Privacy Products for Privacy

Definition

Internal privacy products are tools, platforms, or processes designed to provide the privacy team with oversight, governance, and control over privacy compliance across the organization. These products monitor, validate, and assess the effectiveness of privacy measures within the business, ensuring that privacy risks are managed in line with internal policies and regulatory requirements.

Key Differentiation: 

Internal privacy products should never have an operational nature or interfere with business processes and customer-facing interactions. They are not meant to replace or replicate any operational activities already conducted within the business. Instead, internal privacy products are designed to work in the background, feeding off the signals, logs, and data points provided by business-embedded privacy features.

Whilst this is the key differentiation, it is paramount that the privacy requirements are fed into the design and operation of the business process to augment it and enhance it as requirements evolve. The difference is how we do things. Do not do it for them, but help them (the business) do it themselves!

Example: Incident Management Considerations: 

Privacy incident management is not a standalone process operated solely by the privacy team. Rather, it should be a subrogated process that leverages the existing incident management frameworks already established within the business. No new incident management process should be created specifically for privacy incidents or additional reporting systems and portals. Instead, these incidents should be managed within existing channels (e.g., IT or customer support systems), escalating to the privacy team only when necessary BUT in a programmatic way, driving out subjectivity. This ensures that incidents are handled efficiently and, in a manner, consistent with other types of incidents, while still allowing the privacy team to intervene in complex or high-risk cases.

A good example of this would be to eliminate any channel with the customer that might lead to subjectivity and try be as explicit as possible. e.g. unstructured email channels here the customer might need to go back a forth n number of times to define the ask given the options where not explicit in the first place. This drives consistency and consistency drives digital trust. See Robert Cialdini six principles of influence to learn more and in particular the Principle of Commitment and Behavorial Consistency

Moreover, most privacy-related requests and incidents should be addressed through self-service platforms and tools embedded into business processes. This reduces the need for separate tools hosted by the privacy team, ensuring that privacy requests and incident handling are seamlessly integrated into the business's natural workflows.

Maximizing the self-service approach is key for multiple reasons:

1. Scale: It permits the process to scale. At potentially Millions of customer interactions this is a requirement.
2. Declarative: makes the process explicit and declarative, eliminating subjectivity in the degree possible that can creep in when people subjectivity is applied.
3. Consistency: Customers expect a consistent experience in several domains, e.g. Identity registration and login.  Privacy is just another one of these requirements.

Characteristics: 

• Oversight & Monitoring: Enable the privacy team to continuously monitor and assess privacy risks, data flows, and compliance status, using data collected by business-embedded features.
• Governance & Reporting: Facilitate reporting mechanisms, control checks, and compliance documentation for internal and external stakeholders.
• Independence from Business Operations: Operate independently of business processes, drawing information from business-embedded privacy features, and ensuring no operational activities or customer interactions take place within these tools.
• Minimal Intrusion: Avoid disrupting the natural flow of business operations, intervening only when necessary (e.g., in the case of privacy breaches or non-compliance) and escalated through established channels.

Examples:

• Privacy Incident Management Integration: Integrated as a sub-process within the broader incident management system, where privacy incidents are flagged and automatically escalated to the privacy team when necessary. For instance, data breaches reported through a central IT system will notify the privacy team for assessment and response, but initial incident handling occurs through the existing IT channels.
• Data Inventory & Mapping processes: Captures data flows, processing activities, and data sharing across the organization. The privacy team uses this tool to understand where personal data is stored, used, and shared, without affecting customer-facing systems or business workflows. NOTE Ideally this would be incorporated into the Customer Data processing domain as standard documentation and not need to be a privacy function
• Automated Compliance Assessment Tools: Periodically checks compliance against regulatory requirements (e.g., GDPR, CCPA) and internal policies by analysing data fed from business processes, without requiring ongoing manual input from business units. These NEED to be aligned with the broader compliance Tools and platforms in the GRC functional domain. Remember tomorrow we will have AI compliance teams spin up, then Xyz Regulation Team etc etc.

2. Business-Embedded Privacy Features

Definition: 

Business-embedded privacy features are the privacy-enhancing measures, controls, and functionalities integrated directly into business platforms, systems, or processes. so basically as the GDPR definition states it , be an integral part of the design and operation of any system, service, or product that processes personal data. These features ensure that privacy considerations are embedded into the design and operation of products and services, minimizing risks at the source.

Key Differentiation: 

Business-embedded privacy features must reside within the existing business processes and customer channels. This includes interfaces like websites, customer chatbots, mobile apps, customer care, case management processes, and customer communications. They are responsible for ensuring that privacy is preserved at the point of interaction, enabling compliance without requiring direct oversight from internal privacy products during real-time operations because it is already embedded into the process.

A critical aspect is that the management of customer privacy requests (such as data subject access requests or consent management) and privacy-related incidents should be handled through self-service platforms and tools directly embedded into business processes, rather than separate tools hosted by the federated teams. This approach ensures that the business processes remain the primary point of interaction for customers, with privacy considerations built into the channels that customers are already familiar with.

Characteristics:

• Integrated Design: Incorporated into the platforms or processes that handle personal data, ensuring that privacy-by-design principles are followed at every customer touchpoint.
• Proactive Risk Mitigation: Address privacy risks at the point of data collection, use, or sharing, preventing issues before they escalate and ensuring customer interactions are privacy compliant.
• Seamless Business Operation: Designed to work within the business processes without additional intervention or oversight
• Interoperability: Provide necessary data and signals to internal privacy products for oversight and monitoring purposes, but never assume a governance role.

Examples:

• Automated Data Minimization: A feature in customer-facing systems, such as websites or mobile apps, that only collects necessary data fields for the intended purpose, minimizing the collection of personally identifiable information (PII) in real time. This would be a data domain feature and not a specific capability we would build out by a central privacy programme
• Consent and Preference Management Platform: Embedded in customer-facing platforms, allowing users to provide or withdraw consent for different types of data processing activities. The system then signals the consent status to internal privacy products, enabling compliance tracking without interfering in customer interactions
• Self-Service Privacy Requests: A mechanism that allows customers to directly submit privacy-related requests (e.g., data deletion, access requests) through existing interfaces like websites or mobile apps. This avoids the need for the privacy team to host separate tools, as the business processes remain the primary point of contact or more important to flip between teams. Privacy teams will be activated declaratively when a new pattern arises, and this pattern will be used to enhance the self-service flow.

Interaction Between the Two Categories

While business-embedded privacy features are designed to be a part of the natural workflow of the business, internal privacy products provide the mechanisms for oversight and assurance. Internal privacy products rely on signals, logs, and reports from the business-embedded privacy features to function effectively. This relationship allows the privacy team to maintain governance without disrupting business operations, ensuring privacy controls are functioning as intended and compliance is maintained.

Internal privacy products serve as the second line of defence, supporting governance without encroaching on business operations or directly interacting with customers. This ensures that privacy management is robust yet unobtrusive, maintaining the integrity of both business functions and customer experiences.

The approach is to improve the “first line of defence” to minimize the second line. See Three Lines of Defense 2.0? for more insights on how investment should also reflect this line of defence strategy. if 99% of your investment is going to second line then do not expect a by design outcome!

The above diagram shows how you need to play wiht the natuarl team tension that can arise while you move the dial to the right or left of this specttrum. What is right in one moment is not for another, but what is clear is if we shift accountability to the right to second line functions this will spell that we have not done enough to build the control requirement in from the get go in the operations and hence are ineffective. Giving up this power to the centrals teams does not come naturally and requires strong competency based leadership that truly understand these domains. In particular for the privacy domain Mitre articulated this clearly in there Privacy Engineering Framework and Lifecycle Adaptation Guide already in 2019!

Articulating the Relationship

Business-embedded privacy features handle all operational aspects of privacy within the business processes and customer channels. They act as the first line of defence, ensuring privacy risks are managed at the source through direct engagement with customers or consumers. Internal privacy products, on the other hand, provide the second line of defence—focused solely on oversight and governance, never assuming an operational role or customer-facing responsibilities.

This layered approach allows the privacy team to support business operations in a manner that minimizes direct involvement in day-to-day activities, enabling proactive and efficient privacy management while preserving the efficiency and flow of business processes.

This articulation, along with examples, should provide a clear distinction between the two types of privacy tools, emphasizing their distinct roles and operational boundaries within the organization.

Conclusion

Finding the right mix a the right time in the organization is not easy hence agreeing the WHY is paramount with the different stakeholders.

Privacy by Design is complex to do it right but it is a people challenge and not a technology one.