Skip to content

Refer to the following for additional context and guidance:

Next: Implementation

Risks Assessment#

Hold "Alt" / "Option" to enable Pan & Zoom
lifecycle

Key Ideas

  • Brainstorm potential risks - Engage Subject Matter Experts, review Governance policies, and consult relevant regulatory documentation to identify possible risks.
  • Assess likelihood and impact - Evaluate how likely each risk is to occur and the severity of its potential impact.
  • Define risk indicators and controls - Identify early warning signs or indicators that a risk has materialized, and determine the controls in place to detect or prevent it.
  • Plan risk mitigation measures - Establish actions that can reduce the likelihood of each risk occurring.
  • Prepare contingency plans- Document a clear plan to manage consequences if a risk does occur.
  • Ensure identified risks, controls, and mitigation strategies are reflected in the project’s Requirements Specification.

!!! note IMPORTANT

MDM solutions risk controls are now to be handled by means of ServiceNow Risk Management system

ServiceNow

Roles Involved#

All roles contributing to the development of an MDM system should document the risks they identify at various stages of the project lifecycle.

Goals#

General purpose and clarifications:

  • Protect Novo Nordisk from financial, commercial, reputational, and other damages that may result from data-related issues or negligence.
  • Safeguard the integrity and value of the Solution being assessed.

Inputs#

GxP Requirements applicable to Novo Nordisk * GDPR (for Europe), if the Product is expected to handle Personally Identifiable Information (PII). * HIPAA (for the US), if the Product is expected to handle Personally Identifiable Information (PII).

Outputs#

  • Risk Assessment document, including:
    • List of identified risks with likelihood and impact ratings
    • Indicators and control measures for risk detection
    • Risks mitigation measures
    • Risk plans for handling consequences
    • Templates
    • Gxp-Template(Veeva)


Process Flow#

1. Listing the Risks#

Risk management best practices recommend beginning with a brainstorming session. Capture anything that arises in response to the question:
"What could potentially harm the Company or the Product, and how?"
At this stage, include all ideas, regardless of how serious or unlikely they seem. The list will be refined through subsequent likelihood and impact assessment.

When identifying risks, consider the following categories of potential impact:

  • Financial - Effects on cost, revenue, or profitability.
  • Reputational - Damage to market perception or stakeholder trust.
  • Business Ethics - Harms involving people, settlements, fines, or risk of debarment.
  • Product Quality - Risks that degrade product quality, leading to customer dissatisfaction or serious adverse events.
  • Regulatory Compliance - Exposure to sanctions from regulatory bodies, including potential suspension of product delivery.

The following aspects of data should be considered during risk analysis:

Below is a breakdown of different types of risks encountered at various stages of a Master Data Management (MDM) project, along with examples for each phase.

Inception#

Risk Category Example Risks Impact
Lack of Executive Sponsorship No C-level champion for MDM initiative Low prioritization, budget cuts
Unclear Business Objectives Conflicting goals across departments (e.g., Sales vs. Finance) Misaligned KPIs, scope creep
Incomplete Data Inventory Missing source systems in scope Surprises during data discovery
Underestimated Budget Ignoring costs for stewardship tools or licenses Project delays, compromises

Requirements Gathering#

Risk Category Example Risks Impact
Poor Data Quality Unexpected nulls, duplicates, inconsistent formats Impacts match/merge accuracy
Inaccessible Data Sources Firewalls, vendor APIs, or legacy systems are not reachable Profiling delays, incomplete models
Lack of Data Ownership No defined data ownership for certain source systems Delayed profiling/cleansing
Security Risks Exposure of sensitive data (e.g., Personally Identifiable Information - PII) during data profiling Compliance violations (GDPR, HIPAA)

Design#

Risk Category Example Risks Impact
Poor Data Model Design Over-normalized model, poor hierarchy handling Difficult integration and performance issues
Mismatch in Integration Strategy API-based integration is expected, but only batch processes are available Rework and delays
Tool Limitations Selected MDM product can't support required fuzzy matching logic Compromised match quality
Inadequate Security Architecture No role-based access or encryption for sensitive fields Data breaches
Over-aggressive Match Rules Different people with similar names merged Golden record corruption
Unscalable Cleansing Rules Hardcoded transformations per field/domain High maintenance
Lack of Error Management Failed records are not tracked or retried Data loss, incomplete loads
Inconsistent Reference Data Country codes or titles inconsistent across sources Invalid lookups, failed validations
Weak Trust Model Equal weight to unreliable sources Golden record is incorrect
Conflicting Merge Logic Frequent override of trusted data by recent data Business process breakdown
No Steward Intervention Mechanism No manual override for merge conflicts Long error cycles, user frustration

Launch#

Risk Category Example Risks Impact
Change Management Resistance Business users bypass MDM, use old systems Low adoption
Integration Failures Downstream systems reject MDM structure Transactional failures
Performance Issues Matching or API latency too high User dissatisfaction
Insufficient Monitoring No audit logs, health checks or metrics Issues undetected until too late

Adoption and Support#

Risk Category Example Risks Impact
Lack of Ongoing Data Stewardship Stewards are not funded or allocated after go-live DQ degradation over time
No Data Quality KPIs Inability to track data quality improvements or regressions over time No accountability
Changing Business Rules Product naming or ownership models change DQ rules become outdated
Audit & Compliance Gaps No lineage or traceability Regulatory non-compliance


2. Likelihood and Impact Evaluation#

To assess the likelihood and impact of a risk, the best approach is to consult a relevant Subject Matter Expert (SME). If no SME is available, rely on personal experience and professional judgment.

Likelihood should be assessed based on the following criteria:

  • Unlikely (less than 10%)
  • Possible (10-25%)
  • Likely (25-50%)
  • Very likely (above 50%)

Impact, representing the extent of damage if the risk occurs, should be assessed using the following scale:

  • Minor
  • Moderate
  • Major
  • Critical


Once likelihood and impact have been assessed for all listed risks:

  • Risks that are both unlikely to occur and have minimal impact should be excluded from further consideration.
  • Risks with minor impact should be re-evaluated - ideally with input from SMEs and stakeholders - and may also be excluded if the impact is deemed negligible.


3. Indicators and Controlling Measures#

For each risk retained after Step 2, clearly define measurable indicators that signal the occurrence of the risk event.
Additionally, outline the control mechanisms in place to detect these indicators in a timely manner.


4. Risk Mitigation Measures#

For each risk remaining after step 2, specify mitigation measures aimed at reducing the likelihood of the risk event occurring.


5. Risk Consequences Handling Plan#

Ideally for every risk remaining after Step 2, and especially for those with more than minor impact, a consequences handling plan must be prepared.
This plan should aim to minimize the impact and damage if the risk event occurs.


6. Templates#

What Happens Next?#

Risk assessment is a complex and iterative process, particularly when risks have not yet been validated by production experience.

Once the Risk Assessment Document is finalized, the identified indicators, control measures, mitigation strategies, and any items related to consequences handling should be incorporated into the Requirements Specification, ensuring traceability and alignment across project documentation.

After that, the Requirements Specification is considered complete and ready for Implementation.