Category: CCPA

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.

 

 

CCPA, CDO, CPO, GDPR, IAPP, Privacy

Organizational Placement of Privacy

James Howard

Question for the community: where should a Chief Privacy Officer (or more broadly, the privacy function)?  Some alternatives include:

  1. Counsel’s office: Since privacy is a legal matter, it stands to reason that compliance would benefit from being embedded with the general counsel.  On the other hand, counsel is often positioned as a separate function to demonstrate objectivity and independence from operations.  Moreover, since lawyers are trained to look at situations through a legal-risk lens, they are sometime less able to “get to YES” and truly embed privacy in operations.  Operations folks may look at their Legal colleagues in general as someone providing “sign-off” and that perception might extend to privacy compliance.
  2. Risk Management & Compliance: again, the alignment has some logic, since privacy provides a set of requirements that overlaid on operational processes, and one should manage the risk of non-compliance.  However, similar to assigning privacy to the Counsel’s office, Risk and Compliance are often organizationally separate to maintain objectivity and independence.  As a result, there will likely be challenges in embedding privacy into operational processes to achieve Privacy/Data Protection by Design.
  3. Office of the Chief Data Officer: The CDO is tasked with understanding the full breadth of data for purposes of deriving value and helping the organization leverage data in existing and new initiatives.  As a result of developing and maintaining the inventory of an organization’s data, the CDO is in a natural position to assess the applicability of privacy requirements and embed privacy requirements in business processes.  The challenges include that the CDO may be perceived has having a conflict of interests by owning privacy compliance as well as data leverage goals (in much the same way as a CIO has a conflict of interests by owning the CISO function).  Another challenge is that CDOs don’t always own all data in the organization, instead focusing on the data to be leveraged or monetization.  This leaves key gaps – such as employee data.
  4. Office of the CIO or CISO: The CISO is tasked with protecting data and is often looked to when there are data incidents.  As a result, the CISO has operational processes as it relates to embedding security requirements as well as monitoring/responding to issues, so adding privacy requirements would seem like a logical extension.  Moreover, the CIO and CISO are very well versed at implementing tools and extensions, which will be required for an effective program.  Privacy professionals will be quick to point out that privacy requirements extend well beyond security, and compliance requires a different level of understanding of the nature of data and how it’s used; a privacy breach may exist where no “traditional” security breach has occurred.  Moreover, privacy requirements apply to information and processes across an organization – not just those within scope of the CIO.  You could have an entire privacy awareness curriculum that never mentions technology, instead focusing on how people handle information. 
  5. Operations (COO): Having privacy report of the COO can make sense, depending on the organization.   Whereas privacy has been around for many years, the passage of landmark privacy legislation – with significant consequences for non-compliance – has very quickly elevated its importance in organizations, making it a Board-level or C-suite priority in some cases.  Having it report to the COO gives it prominence and positions it as aligning with the entire company.  This helps enable the implementation of privacy processes as embedded components in business process.  If done right, the result is a less disruptive but more effective program.   The downside is that unless the organization is a very data-focused company, privacy may get lost among the COO’s other priorities, and may be the target of political struggles.

To be sure, any of these models can work, if provided with the appropriate leadership, support and oversight.  Moreover, the culture of the company and the nature of their business can also influence an appropriate structure.

Privacy is at a crossroads.  One the one hand, the emerging interest and concern from consumers (and therefore legislators) puts pressure on companies to acknowledge their responsibilities handling personal information properly.  On the other hand, since privacy has been around for a while and is conceptually familiar to executives, is there a level of privacy fatigue being felt?  As a result, are companies less motivated to address the risks, instead adopting a wait-and-see attitude?

CCPA, CPO, GDPR, IAPP, Information Management and Governance, Privacy

How effective are privacy programs?

James Howard

Background:

In September 2019, A group of 100 data leaders from respectable NY financial institutions were asked whether they’d heard of the General Data Protection Regulation (GDPR – the far-reaching European law governing how EU citizen’s personal information is handled around the world); 5 hands went up.  When asked a follow-up question: how many had heard of the California Consumer Privacy Act (CCPA), 2 hands went down.

On December 26, 2019, CNN published a story explaining why consumers are all of a sudden receiving so many privacy notices, which goes on to summarize CCPA, including the activity that triggered it.  The article explained – at a high level – the events that led legislators to pass the law. 

Over the summer, a small group of CFOs were interviewed and felt that GDPR is a mess, readiness was a waste of money, and that compliance is being addressed by “someone else”. 

Problem statement: 

Companies want to increase the degree to which they store and process personal information, but in an effort to protect the rights of individuals, law-makers are seeking to reduce the number and severity of incidents by imposing regulations.

Companies are making big investments in initiatives to take advantage of the transformative potential of data.  This covers an incredible array of opportunities, from simply using data and analytics to enrich their products and services, all the way to inventing algorithms to mimic human thinking to improve the lives of millions.  

The initiatives all have one thing in common: they depend of high quality data.  Vast amounts of it.  Increasingly pertaining to people.  Companies are building systems that pull together and combine data from a myriad of sources – internal and external. 

Breaches are happening – bigger and more impactful.  In 2019, records containing personal data were being stolen at a rate of over 15,000,000 per day.  The consequences to organizations are significant – financial and reputational.  Regulators are stepping up their actions, conducting investigations, and imposing fines.  Companies are having to pivot to correct issues and address new requirements reactively because many have failed to implement a data management framework efficiently adapt to regulatory changes.

Many companies don’t have a prominent leader assigned responsible for privacy – a Chief Privacy Officer (CPO) or equivalent.  Privacy is managed by legal or compliance groups as an adjunct to operations.  As a result, the people doing the day to day business of the company are not aware of their privacy responsibilities.  So is there any wonder why companies are mishandling personal data?

It’s time to act

More to the point, it has been “time to act”, but the regulatory requirements around data privacy are not going to get simpler, and companies should consider implementing an operational framework, with appropriate tools, enabling them to adopt new requirements in a time and cost effective manner.

An effective program to enable business to use data while also managing risk and ensuring compliance must reflect 3 interlocking components: Privacy, Data Governance and Risk Management.  Together, they can protect an organization while serving as a catalyst to accelerate forward.

Privacy

Most companies have a Privacy compliance program.  However, the informal poll referenced above revealed that privacy compliance is not embedded in the data programs.  This gap is very significant, since provisions of the laws speak very specifically to plans data scientists are pursuing,  The result is certain initiatives will have to slow down or get re-tooled.

And it’s not just data science teams who are dangerously disconnected.  Data science is probably a key area where data is being handled outside the boundaries set by the regulations (kept and processed for purposes beyond why it was collected, for example), but the breaches are mostly tied to weak controls on the operational side of companies – ranging from how and where it is tracked and stored, to how it is processed or disclosed for business purposes.

“Privacy by design” has eluded organizations since it was first envisioned in 1995, in part because it is frequently promoted by an under-resourced parallel organization, trying to apply one-size-fits-all techniques.  It doesn’t have to be like this.  Privacy programs can be structured to bridge to data users in an foundational sense, where privacy obligations are taken into account through-out project or operations lifecycles.  Risk goes down.  

Addressing the challenge begins by assessing the current state of the privacy program against a privacy template or framework, such as the latest draft NIST Privacy Framework, and creating a gap analysis.  The framework is useful because it breaks down the objectives of a privacy program in a way that aligns in with both regulations and the way organizations use data.  To be fair, the full Framework can be overwhelming for many companies – especially those not familiar with the NIST Security Framework, on which the Privacy Framework is based.  But this can be addressed by first distilling the NIST framework down to a more manageable version that still preserves the key elements. 

The gap analysis forms the basis for discussing how to enhance existing privacy efforts to achieve compliance, in a deliberate, sustainable, pragmatic way.  If done right, it can be scaled – whether down to a small privacy team of, say 2-3, or up to a full enterprise-level team.  This also allows a more focused approach to address specific pain points, including:

  • Compliance with GDPR or CCPA, which might range from early stage assistance, to specific process solutions (e.g., data subject access requests, data inventory upkeep, privacy-by-design, training and awareness, etc.)
  • Consideration for placement of the program, to integrate into company culture; companies are struggling with where to assign privacy, if not in Legal, and it’s landing with the CISO, who often needs help getting ramped up
  • Operationalizing Privacy, making the program resilient and sustainable, incorporating activities such as: 
    • Strategic oversight and stewardship, including obtaining executive and Board support
    • Monitoring for legislative changes, 
    • Updating and implementing policy,
    • Risk assessment, 
    • Process and control documentation and testing, 
    • Integration with business and IT change management, 
    • Incident management, escalation and resolution, 
    • Vendor management, and 
    • Contract review.

Data Management

Data programs are high priority for CEOs – over 95% believe that leveraging data is key to continued success and to defend against external disruption.  Yet Gartner concludes that 85% of data projects fail.  How is this possible?  Oftentimes, data initiatives are launched without implementing basic management and governance techniques.  Objectives are not defined at the outset, C-levels and the Board aren’t clear in what they are asking for, and may not understand the path to get there – or the cost.  

Introducing data management and governance discipline to create the data equivalent of “scientific method” can dramatically reduce risk and increase the chance of success.  Many companies – especially those in regulated industries – have records management programs that can be adapted to provide a management framework for data to be leveraged for monetization or through analytics or AI initiatives.  

The value proposition is to implement sufficient management and governance activities to

  • Provide transparency and accountability in to the program, including ethics and legality,
  • Ensure that data is handled in a way that doesn’t violate compliance obligations, whether contractual or regulatory
  • Provide shared-service capabilities, including inventory, procurement, tracking and disposition.
  • Create logical interface and touch-points into privacy, security, internal audit, compliance and legal programs
  • Triggers and objectives are to close the gap between CEO expectations and the practical success rate of data projects.
  • Expose the relative value and sensitivity of data to enable proper risk and threat management, in collaboration with others, such as a Chief Information Security Officer.

Information Risk Management

In a metaphorical sense, data programs are taking the jewels out of the safe and passing them around.  Handling high value assets definitionally increases the risk of theft or breach, when compared to keeping them locked up.  But they must be handled in order to derive value.  Many companies have built information risk or IT risk management capabilities over the last several years; the question is how well are they tied into data initiatives or aligned with the way data is used?  Given that 15,000,000 records are breached every day, one might suggest “not very”.  

In the context of the increased use of data for market-facing benefit, Information-related risk needs to be assessed in a more focused way.  As a discipline, IT RM has created a good foundation, however it frequently aligns with core IT process like strategy, architecture, change management, and security, and not to data.  

Information risk management can provide a critical interface between a data leverage program and a privacy/compliance program.  The techniques used to assess information risk result in key insights into the nature, relative value, uses and threats to information.  This helps direct risk-mitigation resources to align with the risk.  Specifically, it helps to recognize whether risk can be mitigated through, say, security controls, or whether the employee community needs tools that better align with their jobs (obviating the need for them to find their own solutions to business problems), or whether increasing awareness can help people make better judgements.  

Companies should consider identifying, categorizing and managing risk by looking at initiatives through an information lens – as opposed to a technology lens.  This changes the dialog with business stakeholders, which increases their understanding and appreciation of what could go wrong, what is acceptable residual risk, and the steps needed to bridge the gap.  

As indicated, IT RM in the marketplace has achieved a level of maturity, and there exists opportunities to adjust the scope and approach to more effectively identify and manage information-related IT risks, which arguable, can help manage overall financial, regulatory and brand exposure for companies.

Summary

Companies are increasing their use of data at a tremendous rate – and they should.  The opportunities to gain competitive benefit are exploding.  But the risk and consequences of missteps are growing as well.  By implementing data governance and integrating risk management and compliance in a pragmatic way, organizations can continue to explore the ways data leverage can provide benefits, while taking proportional measures against events that can impede progress.