# Setting up a data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → council that regulators trust
A state insurance examiner asks a claims director: "Who approved the March update to your claims scoring model, and what data changed?" The director pauses, checks with IT, checks with the actuarial team, and three days later sends a partial answer. That delay, not the model change itself, is what triggers a formal inquiry. Regulators do not expect perfection. They expect traceability. This lesson builds the committee structure that makes "who approved this" a five-minute answer, not a three-day scramble.
Insurance runs on data that is simultaneously sensitive (health, driving records, credit-based insurance scores) and consequential (it decides who gets coverage and at what price). Two regulatory pressures converge here:
Both pressures ask the same underlying question: can you show your work? A data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → council is the structure that produces that evidence continuously, not just when asked.
A governance council that regulators trust has clearly separated roles, not a single "data team" doing everything.
1. Data Governance Council (the body itself)
Meets monthly (or on-demand for urgent changes). Cross-functional: actuarial, claims, underwriting, IT/data engineering, compliance, legal, and a board-level sponsor. This is the body that approves material changes to data sources, model inputs, and scoring logic.
2. Data Owner
A named business leader (e.g., Head of Claims) accountable for a specific dataset's accuracy and appropriate use. Not the same as the person who technically manages the database.
3. Data Steward
Operational role, usually within the data/analytics team, responsible for day-to-day data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.Voir la définition complète → checks, lineage documentation, and flagging anomalies to the Data Owner.
4. Model Risk Officer or Validation Lead
Independent from the team that builds the claims scoring model. Reviews model changes for bias, drift, and performance before they go live. This separation of "builder" from "validator" is what examiners look for first; the NAIC bulletin and most state exams explicitly check for independence between model development and model validation.
5. Privacy Officer / DPO (Data Protection Officer)
Required under GDPR for many insurers processing large-scale sensitive data. Reviews whether new data uses (e.g., adding telematics driving data to a claims model) require a new legal basis or a Data Protection Impact Assessment (DPIA).
6. Escalation Owner
A designated executive (often the Chief Data Officer or Chief Risk Officer) who takes decisions the council cannot resolve by consensus, e.g., a disagreement between actuarial and compliance about whether a variable is a proxy for a protected class.
Here is what should happen when someone proposes adding a new variable to the claims scoring model, say, a third-party "household stability" score:
1. Proposal logged in a change register with business justification, data source, and intended use.
2. Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Voir la définition complète → checks lineage: where does this score come from, is it licensed, does the vendor have its own bias documentation.
3. Privacy Officer checks: is this personal data under GDPR/CCPA, do we have a lawful basis, does it need a DPIA.
4. Model Risk Officer runs a disparate impact test: does the new variable correlate strongly with protected characteristics (race, and in many US states now, proxies for race in credit-based scoring).
5. Council vote: majority approval logged with names, dates, and dissenting opinions recorded, not discarded.
6. Sign-off ritual: Data Owner and Model Risk Officer both sign a change record before production deployment.
7. Escalation Owner is only pulled in if step 5 fails to reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → agreement.
The critical artifact is the change register: a structured log, not meeting minutes buried in email. A simple version:
change_id | date | model | field_added | proposer | data_source |
bias_test_result | privacy_review | council_decision | approver | sign_off_dateEvery row of that table should be answerable in under a minute during an exam. This is the single most valuable habit a council can build: write the decision down at the moment it's made, not reconstructed later from memory.
For a practical template on documenting AI/model governance decisions, the NIST AI Risk Management Framework offers a free, sector-neutral structure many insurers adapt: NIST AI RMF.
Three habits separate councils that survive an exam from ones that don't:
Vérification des acquis
1. In the opening scenario, what actually triggers the regulator's formal inquiry?
2. Why do insurers face a distinctly compounded governance burden compared to many other industries handling personal data?
3. What is the core underlying question that both privacy law and model governance regulations are ultimately asking insurers?
4. Select ALL correct answers describing regulatory pressures that specifically apply to insurers' use of data and predictive models, according to the lesson.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about what a data governance council is meant to accomplish, based on the lesson's framing.
Sélectionnez toutes les réponses correctes.
Different regimes, same underlying question, phrased differently:
| Regime | What they ask | What proves it |
|---|---|---|
| NAIC Model Bulletin (US, state-adopted) | Do you have documented governance over AI/predictive models used in underwriting or claims? | Council charter, change register, validation reports |
| Colorado SB21-169 | Have you tested for unfair discrimination in rating/underwriting algorithms? | Bias testing logs, methodology documentation |
| GDPR (EU) | Is there a lawful basis and documented impact assessment for personal data use? | DPIA records, DPO sign-off |
| EU AI Act (high-risk systems, phased application through 2026-2027) | Is there a risk management system and human oversight for the AI system? | Risk logs, human-in-the-loop sign-off records |
Note the pattern: none of these regimes demand a specific software platform or a specific committee name. They demand evidence of a decision-making process that a third party can reconstruct after the fact. That's the actual deliverable of a governance council: an audit trail, not a meeting.
Many insurers build an impressive council on paper, then let it approve changes retroactively: the model team ships an update, then brings it to the next scheduled council meeting weeks later "for record." This is worse than no council at all, because it creates a paper trail showing governance was bypassed. Regulators have flagged this exact pattern in market conduct exams. The fix is simple but organizationally hard: no production deployment without a prior, dated approval record. Build the technical deployment pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → to require a sign-off ticket number before it will push to production. Make the control physically impossible to skip, not just policy-discouraged.