Category: Risk management

CCPA, CDO, CPO, GDPR, IAPP, Information Management and Governance, Privacy, Risk management

Beyond the Blind Spots: How a Privacy Partner Operationalizes Compliance

James Howard

In mid-sized organizations, privacy responsibilities are often assigned to the IT Director, CISO, or General Counsel. These roles bring deep expertise in technology, security, and legal compliance. However, privacy introduces an additional discipline that focuses on how information is used, whether that use aligns with stated purposes, and how those decisions are operationalized across systems.

Two structural challenges commonly emerge:

  1. Privacy governs data use, not only data protection.
    As privacy regulations expand and organizations increase their use of AI and data-driven systems, compliance depends on clearly defined purposes, permissions, and lifecycle controls—not solely on security safeguards.
  2. Regulatory obligations require repeatable operations.
    Many privacy requirements depend on consistent execution (e.g., responding to individual rights requests, maintaining processing records). When these activities are handled manually or distributed across functions, they create operational risk and inefficiency.

As a result, privacy increasingly functions as an operational capability rather than a policy-only responsibility.

In this environment, organizations often supplement internal expertise with external privacy partners to address gaps between regulatory interpretation and system-level execution. These partners do not replace internal accountability, but support leadership by translating privacy requirements into operational processes aligned with existing IT, security, and business workflows.

In this context, privacy is no longer limited to published notices or contractual language. It is a data lifecycle and systems management challenge requiring coordinated execution across legal, technical, and business teams.

Governance Context: Roles and Accountability

From a governance perspective, privacy responsibilities typically align with a Three Lines of Defense model:

  • First Line (Business & IT Operations):
    Own data use, system design, and day‑to‑day processing activities.
  • Second Line (Privacy, Risk, Compliance):
    Define requirements, provide guidance, monitor adherence, and maintain oversight documentation.
  • Third Line (Audit / Independent Assurance):
    Validate that privacy controls and processes operate as designed.

Where organizations lack a dedicated internal privacy function, an external privacy partner commonly supports the second line by providing subject‑matter expertise, standardizing processes, and supporting oversight without assuming operational ownership.

1. Operationalizing Privacy Requirements

Regulatory requirements must be translated into documented, repeatable processes. Without this translation, organizations rely on ad hoc responses when regulators, customers, or partners request information.

In practice, external privacy expertise is often used to help establish these processes in a consistent and auditable manner.

Key operational areas include:

• Record of Processing Activities (ROPA)
A compliant ROPA requires more than an inventory of systems. It must link data sets to processing purposes, legal bases, and retention decisions. Where internal teams maintain fragmented documentation, external privacy support can help normalize ROPA structures and ensure alignment with actual system behavior. When purposes change or expire, associated data should be reviewed and disposed of to reduce long-term risk.

• Data Subject Requests (DSRs)
Rights such as access, deletion, and correction are time-bound and resource-intensive when handled manually. Standardized workflows—often designed with external privacy input—can support consistent intake, identity verification, and fulfillment across systems while improving response reliability and cost predictability.

• Consent Management
Consent requirements span websites, mobile applications, CRM systems, and marketing platforms. Effective consent management depends on synchronized preferences and a consistent source of record. External privacy expertise is frequently used to help define consent governance models and ensure downstream systems respect user choices across platforms.

• Privacy Impact Assessments (PIAs / DPIAs)
PIAs are most effective when conducted early in the system development lifecycle. Privacy specialists—internal or external—can assist development and product teams by identifying risks at design time, enabling mitigation through architectural decisions rather than post‑deployment remediation.

• Data Minimization and Disposal
Retention decisions affect legal exposure, breach impact, and discovery obligations. Operationalizing retention and disposal policies often requires coordination between legal, IT, and security teams. External privacy support can help align retention rules with technical enforcement mechanisms to ensure policies are applied consistently.

2. Privacy Technology and Tool Selection

When privacy responsibilities are distributed across functions, tool selection is often fragmented. Different stakeholders may prioritize integration, reporting, or usability, leading to overlapping or underutilized solutions.

A coordinated approach to privacy tooling—frequently supported by external privacy advisors—focuses on selecting and integrating platforms that support:

  • Governance, risk, and compliance reporting across jurisdictions
  • Automated data discovery and classification
  • Scalable fulfillment of individual rights requests
  • Integration with development, security, and IT service workflows

The primary objective is not tool adoption itself, but operational integration. Privacy activities should surface within existing workflows and control environments so that compliance obligations are met as part of normal operations rather than through parallel processes.

3. Privacy in AI and Advanced Analytics

As organizations deploy AI and machine learning systems, privacy considerations increasingly intersect with model development, data governance, and risk management.

Key considerations include:

  • Documenting data provenance and permissible use
  • Assessing whether training and inference data align with stated purposes
  • Evaluating risks related to repurposing, bias, and downstream use

Given the evolving regulatory environment, organizations frequently rely on specialized privacy expertise to support AI impact assessments and governance reviews. These assessments help leadership determine whether proposed data uses are permissible, defensible, and sustainable over time.

Summary 

Assigning privacy responsibility without dedicated operational ownership can introduce long-term compliance and operational risk. Whether delivered internally or supported by external expertise, a structured privacy function enables:

  • IT teams to design and operate systems with clear data‑use constraints
  • Security teams to reduce exposure through minimization and controlled access
  • Legal and compliance teams to rely on documentation that reflects actual operational practices

When privacy requirements are embedded into systems, governance structures, and risk frameworks, organizations are better positioned to respond to regulatory inquiries, support data‑driven initiatives, and adapt to evolving legal standards.

CCPA, CDO, CPO, GDPR, IAPP, Privacy, Risk management

Building a Simplified Privacy Program in Business

James Howard

The rules around protecting the privacy of customer and employee data are becoming one of the most complex business risks (not necessarily highest risk). With no single federal law, organizations face a complicated patchwork of state regulations (like those in California and Virginia), all while new Artificial Intelligence (AI) rules are beginning to overlap and add even more complexity.

This paper cuts through that complexity. It presents a simple, practical framework for a modern privacy program, focusing on the essential “what” must be achieved, not the highly detailed “how.” The goal is a program that is easy to understand, aligned with business strategy, and nimble enough to keep up with the law.

Three Pillars of a Resilient Privacy Program

To ensure continuous compliance, managing risk, and ready to respond, privacy programs can be thought of as built on three essential, functional pillars: Steady State, Change Management, and Response.

I. Steady State: The Foundation of Continuous Compliance

This pillar is about maintaining a clear, current understanding of what data is on hand and what can be donr with it. It focuses on the recurring activities that maintain compliance day-to-day.

Key ComponentWhat It Does for the Business
Inventory of Data and ProcessesWhat personal data is collected, why, and where is it stored. What permissions are attached to it? This is the single most critical piece of information, as it dictates all other requirements (e.g., disposal deadlines, security needs).
Inventory of ObligationsA clear view is needed of all applicable regulatory requirements (e.g., state laws) and contractual agreements (e.g., what promises are made to clients or what vendors commit to do).
Third-Party Risk Management (TPRM)Vendors and partners are a disproportionate source of privacy risk. A formal process is needed to assess how they handle data, which is often overlooked in favor of standard IT security checks.
Risk and ControlsAreas of greatest exposure must be identified and proportionate safeguards in must be put in place. This includes employee training and technical controls to limit who can access sensitive data.
Incident ResponseA formal plan for responding to privacy breaches or misuse of data is essential. This allows for quick action, remediation of vulnerabilities, and the ability to meet strict regulatory notification deadlines to minimize reputational and financial harm.

II. Change: Integrating Privacy by Design

This pillar proactively manages new risks that emerge in connection with new products, services, or large projects. It ensures that privacy is a fundamental design element, not a reactive checklist at the end.

Key ComponentWhat It Does for the Business
Privacy Impact Assessments (PIAs)This is the mandatory checkpoint for “Privacy by Design.” It’s a formal analysis to determine if a new initiative poses a high risk, ensuring the Privacy team is engaged early in the development cycle, long before launch.
Regulatory Change ManagementThe legal landscape is constantly changing. It suggests a formal process to monitor new laws, determine their impact, and implement necessary control changes before they take effect.
Process and Control ChangesA mechanism to engage the privacy team when business or IT process changes impact how personal data is handled. This prevents unauthorized, or “shadow,” changes from introducing new vulnerabilities.

III. Response to Inquiry: Demonstrated Accountability

This pillar focuses on the auditable evidence and response mechanisms that prove the program is working and demonstrate transparency to both regulators and data subjects (i.e., customers/employees).

Key ComponentWhat It Does for the Business
Data Subject Rights (DSR) ManagementPeople have a legal right to ask us what personal data an organization has have on them and how they’re using it.  This drives the need for a streamlined, auditable workflow to intake these requests, verify identities, and fulfill them within strict regulatory deadlines.
Regulator RequestsOn occasion, a regulator may inquire about a privacy program. Having a clear response plan is necessary to efficiently provide the required evidence and documentation, often leveraging the data from the Inventory and the DSR process.
Measurement and Continuous ImprovementTracking certain operational metrics is key (e.g., number of incidents, time to fulfill DSRs) to monitor the effectiveness of the program and identify areas that require management focus and resource investment.

Executive Summary

The growing complexity of US privacy law demands a highly organized and resilient compliance framework. To navigate this challenge, we must focus on structure (the three functional pillars), process management, and enabling technology.

By proactively investing in and leveraging specialized privacy technology platforms, management of these intricate requirements can be automated. This approach achieves defensible compliance while keeping operational costs managed, allowing the business to drive forward with reduced risk.

CCPA, CPO, GDPR, IAPP, Information Management and Governance, Information protection, Privacy, Risk management

Why do we have such a hard time understanding, assessing and managing risk?

James Howard

Introduction

Risk is a real concept that manifests across life.   Within a business context, risk management is a valuable tool to help improve the probability of success.  This paper explores the role of a risk manager, and is applicable across the board – whether business processes, technology, security, privacy, information or enterprise.  The reader can easily extrapolate the ideas to any aspect of life.

Definition and Reporting

Definition of risk: The probability or threat of quantifiable damage, injury, liability, loss, or any other negative occurrence that is caused by external or internal vulnerabilities, and that may be avoided through preemptive action.

The key word is “probability” – the likelihood that the event will occur.  In some instances, that can be calculated empirically, if all inputs and effects are known, where triggers can be identified – even if random (roll of the dice).  Other times, probability can be estimated based on historical data around similar conditions (50% chance of rain).

Other times, especially in business settings, there are more variables than can be practically tracked and quantified.  In those settings, Risk Managers use judgment to assess the risk of an event occurring.  The risks are usually classified in a 3 or 5 point scale – say, red, yellow, green or severe, major, moderate, minor and insignificant.   And the more knowledgeable the Risk Manager, the more insightful their assessment of risk, but it still remains a probability.

Challenges

Communicating risk gets complicated when we start factoring in risk mitigating strategies – avoid, reduce, transfer, accept—and reduction techniques – controls, TOD/TOE, residual risk, control risk, etc.

Even within the mitigating strategies there are grey areas – avoiding has consequences (lost opportunities), acceptance doesn’t mean the adverse event will occur, reduction doesn’t mean eliminate.

While some leaders claim they are comfortable navigating uncertainty, there is no question that business hates risk: markets react to uncertainty, and “punish” companies that operate with too many unknowns, and reward those that demonstrate clarity.

People publish dashboards and discuss numbers of controls, as though they were currency – more controls must be better – even though one good (strong) control could replace many poor (weak) controls.  Even auditors are reluctant to rely on process controls and would rather verify every transaction instead (assuming they could).

So what’s the issue?

To some extent, we, as Risk Managers, are the issue.  When asked about risk, we articulate it in our own language:

Risk Manager to Client (or internal business stakeholder): “there is a risk that such-and-such could happen that has these consequences”

Client: “how likely?”

RM: “moderate”

Client: (thinks: “huh?”) “what can we do about it”

RM: “implement x-y-z control”

Client: “will that make it go away”

RM: “implementing this control will reduce the risk, but it leaves a residual risk”

Client: (thinks: “huh?”) “Is that a ‘yes’?  Why wouldn’t you just do it?  And what’s that mean?”

RM: “here – sign this ‘residual risk acceptance document’”

Client: “ok – done”.  (thinks: “thank god that’s over!”) Back to business as usual.

Let’s face, this exchange isn’t very helpful.  The Client clearly doesn’t understand the risk as a potential impact to his/her business, and the “residual risk acceptance document” is a rubber-stamp.

Who owns the risk?  Risk Managers say that their business process stakeholders own the risk, and the Risk Manager’s role is to explain the risk, options for control, and residual risk.  However, it’s fair to say that the business process stakeholders often doesn’t truly accept their role, or if they did, they would engage in a more meaningful dialog.  And the residual risk acceptance document effectively nullifies the dialog.

If the controls are effective, or for whatever reason, the risk fails to manifest, then what?  How often does the client step back and acknowledge that RM did their job and issues were avoided?  Or does the client question why the risk management exercise was undertaken?  On the other hand, if an adverse event takes place, despite controls, does the client look at RM as though they failed?  The cynical reader would point out that if the on-going processes of managing risk management were part of core operations, then you wouldn’t see a spike in RM funding after an event takes place; you might see some refinement or realignment, but not a huge uptick in funding…

An alternative approach

So the challenge is how to meaningfully communicate risk to leadership in a way that puts risk in a business context.

First, one must keep clear: generally speaking, risk can’t be eliminated if the business wants to undertake the activity that introduces the risk.  That said, the Risk Manager can keep the following in mind as these points might promote meaningful communication:

  1. Articulate the risk in familiar business terms (“speak English!”). Explain what would have to happen to trigger the risk.  If you describe a chicken-little event without explaining the triggers, you might get dismissed.
  2. Be realistic when describing the risk and the likelihood. The likelihood should include realistic related events.
  3. Propose options for mitigating the risk, including avoid-reduce-transfer-accept. Bring a reasonable amount of research to present viable options, and be able to articulate the residual risk.
  4. Understand appetite for risk at an appropriate level. A mid-level manager may have a different appetite for risk than the CEO.
  5. Consider what kinds of risks needs to be escalated and to what level: Don’t present a risk to a CEO in a “Enterprise Risk Management” setting that should be addressed by a mid-level manager.
  6. Be realistic in evaluating the consequences of the risk. Walk the stakeholder through understanding the various consequential outcomes to help determine an appropriate mitigating strategy.
  7. Make clear who owns the risk. Get rid of “risk acceptance” documents – if a risk is significant enough to warrant action, it should be pursued.  Risk Acceptance documents are an attempt to shift/assign responsibility, and if they are needed, then they will also be ignored in the post-mortem.
  8. Acknowledge that business environments are dynamic, and events rarely unfold negative risks occur. People intervene.  Processes engage.  The outcome is rarely what was predicted when the risk was recorded.  And the more catastrophic the risk, the more it morphs as it unfolds.

Many of these considerations apply in the post-mortem stage.  One of the big challenges in the risk management community is one of appropriate hindsight.  When evaluating changes to make in risk management in light of an event, it’s important to remember what was known and considered at the time risks were assessed.

The overarching themes in this article is that risk managers need to be realistic when articulating risks, consequences and controls.  Risk managers must recognize they need to bridge the communications gap to their stakeholders by describing risks in business terms that will resonate.

Risk is a fact of life in every aspect of business.  Bad stuff happens, and risk management is not risk “elimination”.  Risk managers play a critical role, and by thoughtfully supporting their stakeholders, they can help business accelerate forward.