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

Building a Simplified Privacy Program in Business

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?

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.