The 7-Column Risk Register: A Board-Ready Template for AI Oversight

The 7-Column Risk Register: A Board-Ready Template for AI Oversight

Why a Risk Register?

A risk register is a simple document — a table with rows for each risk and columns for key attributes. For AI governance, a well-designed risk register does three things:

1. Makes governance concrete: Instead of abstract talk about "AI oversight," it creates a living inventory of which systems exist, what they do, and what governance they get.
2. Enables measurement: You can track whether 100% of high-risk systems have second-line review. You can measure coverage over time.
3. Provides the board visibility: The board needs to see the register quarterly. It becomes the centerpiece of the governance conversation.

The Seven Columns are designed for audit committee comprehension and completeness. Each column answers a specific governance question.

The 7 Columns Explained

Column 1: AI Application Name

Question it answers: What systems do we have?

What to put here: A clear, human-readable name for the AI system. Examples:

• "Hiring Recommendation Engine (HR Tech)"
• "Credit Risk Scoring (Finance)"
• "Supply Chain Demand Forecasting (Operations)"
• "Customer Service Chatbot (Customer Support)"

Why it matters: You can't govern what you can't name. Many companies have shadow AI — systems deployed without formal inventory. Naming forces disclosure.

Common pitfall: Being too vague ("Analytics Platform") or too technical ("ML-Model-7b-v3"). Use business-facing names that a director would recognize.

How to populate: Ask each business unit: "What AI systems do you operate?" Go beyond the official list — ask data teams, engineering teams, and consulting partners. Shadow AI is common.

Column 2: Exact AI Function

Question it answers: What does this system actually do?

What to put here: A one-sentence description of the system's function and primary use case:

• "Recommends candidates to recruiters (not auto-rejects)"
• "Assigns credit score (inputs to loan decision)"
• "Predicts demand and suggests inventory levels (operations team reviews)"
• "Responds to customer inquiries (routed to human for complex issues)"

Why it matters: "Exact function" reveals whether the system is advisory (informs human decision) or consequential (makes or directly causes outcome). This determines risk level.

A recommendation engine is lower-risk (humans decide). An auto-approval system is higher-risk (AI decides).

Common pitfall: Describing what the data scientists built, not what the business user sees. Focus on impact, not mechanism.

How to populate: Ask the business owner, not the engineer. "What does a user see when they interact with this system?"

Column 3: Data Sources Touched

Question it answers: What data goes into this system, and where did it come from?

What to put here: List the primary data sources:

• "Internal hiring records (5 years), LinkedIn profiles, resume text"
• "Customer credit history, payment records, income verification, credit bureau data"
• "Historical sales data, market data, weather data, promotional calendar"
• "Customer service tickets, product documentation, FAQ database"

Why it matters: Data governance is foundational to AI governance. If the data is biased, incomplete, or from a problematic source, the system is at risk. Directors need to know what raw materials go into consequential decisions.

Also, this reveals privacy and compliance risks. If the system uses sensitive data (health, financial, biometric), that's material.

Common pitfall: Listing 50 sources in acronym soup. Stick to the top 3-5 sources that drive the system's behavior.

How to populate: Ask the data science team. Request a data lineage diagram. Then translate it for an audit committee.

Column 4: Access Level (Read-Only vs Read/Write)

Question it answers: Who can change the system's decisions?

What to put here: One of three categories:

• Read-Only: System output is advisory. Final decision is made by a human, separately. Human can override without accessing the system itself.
• Read/Write with Audit Trail: System makes an initial decision, but humans can approve/reject with documented justification.
• Read/Write without Audit Trail: System makes a decision, humans rarely override, and override reasoning is not formally captured.

Why it matters: This determines the system's power and the control environment around it. A read-only recommendation system is lower-risk. An auto-approval system with no override audit trail is higher-risk.

Also, this reveals human-in-the-loop (HITL) governance. Strong HITL means operators are actively reviewing outputs. Weak HITL means the system is automated.

Common pitfall: Not distinguishing between "a human is involved" and "a human can override." Involvement without override power is theater.

How to populate: Ask operational teams: "How often do you override the system's recommendation? When you do, is it documented?" If overrides are rare and undocumented, mark as Read/Write without Audit Trail (higher risk).

Column 5: Risk Category

Question it answers: What are the primary risks this system poses?

What to put here: Check 1-3 from this menu:

• Regulatory Risk: Regulatory violation (EU AI Act, FCRA, ECOA, fair lending)
• Fairness/Bias Risk: Disparate impact on protected groups
• Safety Risk: Physical harm or critical system failure
• Privacy Risk: Unauthorized data use or exposure
• Operational Risk: Model drift, data quality failure, or system downtime
• Reputational Risk: Brand damage from adverse incidents

Why it matters: Different risks require different mitigation. A system with bias risk needs fairness auditing. A system with regulatory risk needs compliance review. This column forces clarity on what you're guarding against.

Common pitfall: Checking "regulatory" for everything. Be specific: is it fair-lending risk, privacy risk, or discrimination risk? Different mitigations apply.

How to populate: Ask the second-line governance team (risk, compliance, or audit) to assess each system.

Column 6: Impact × Probability Score

Question it answers: How risky is this system, really?

What to put here: A risk score, typically a 3×3 or 4×4 matrix:

• Impact: High (>$1M loss, major regulatory fine, safety incident), Medium ($100K-$1M loss), Low (<$100K loss)
• Probability: High (>30% annual), Medium (10-30%), Low (<10%)
• Score: Impact × Probability. High-High is highest risk. Low-Low is lowest.

Why it matters: Not all AI systems are equally risky. A recommendation engine is lower-risk. An auto-approval system touching lending decisions is higher-risk. This column quantifies it so the board can prioritize.

Also, this creates accountability. If you say "Medium probability," the second line needs to justify why. If an incident occurs later, the board can ask whether the assessment was reasonable.

Common pitfall: Inflating probability to justify larger governance budgets. Be realistic: what's the actual probability of a fairness violation, given your controls?

How to populate: Risk team conducts the assessment. Base it on historical incident data, industry benchmarks, and control maturity.

Column 7: Mitigation Status

Question it answers: What is the second line doing about this risk?

What to put here: One of four statuses:

• Covered: Active mitigation in place. E.g., "Quarterly fairness audit + bias testing" or "Monthly compliance review."
• Partial: Some mitigation, but gaps. E.g., "Fairness audit quarterly, but only for hiring subgroup A."
• Planned: Mitigation to be implemented. E.g., "Fairness audit planned for Q3."
• Accepted: Risk acknowledged but deliberately not mitigated. E.g., "Regulatory risk accepted due to cost; escalated for board approval."

Why it matters: This column shows whether the second line is actually doing its job. It's the difference between a nominal governance structure and an active one.

Also, "Accepted" risks are important. Sometimes the cost of mitigation exceeds the benefit. But that decision must be conscious and board-level.

Common pitfall: Everything marked "Covered" because the risk owner is defensive. Push back: what exactly is being done? Is there evidence of testing? Is it recent?

How to populate: The second-line owner (Chief Risk Officer, Chief Compliance Officer, or audit committee member) fills this in. It should be updated quarterly.

Populating the Register: A Workflow

Week 1: Inventory

• Business units list all AI systems (name + function)
• Identify data sources for each
• Determine access level (read-only vs write)

Week 2: Risk Assessment

• Risk team assesses regulatory, fairness, safety, and operational risks
• Assign Impact × Probability scores
• Identify risk categories

Week 3: Mitigation Planning

• Second-line team (compliance, risk, audit) designs mitigation for each high-risk system
• Some systems get robust mitigation (quarterly audits). Others get lighter mitigation (annual review) if low-risk.
• Establish timeline for "Planned" mitigations.

Week 4: Board Presentation

• Present the register to the audit committee
• Highlight high-risk systems and mitigation status
• Set quarterly update schedule

Ongoing: Quarterly Reviews

• Update as systems change, incident data appears, or mitigations complete
• Board reviews quarterly

Total time to baseline: 2-4 weeks for a mid-size company. Then ~2-4 hours per quarter for updates.

Red Flags in a Risk Register

When audit committees review a risk register, watch for:

• No high-risk systems: Unlikely. Most companies deploying AI at scale have at least 3-5 high-risk systems.
• All systems marked "Covered": Defensiveness. Push back on what "covered" means.
• No compliance or fairness risk checks: Governance may be incomplete.
• Quarterly mitigation status unchanged for 6+ months: Governance may be stalled.
• Data sources marked "Unknown" or "TBD": Data governance is weak.

Template Download & Implementation

The 7-column register fits on a single spreadsheet. Headers:

| AI Application Name | Exact AI Function | Data Sources Touched | Access Level (Read-Only / R-W) | Risk Category | Impact × Probability | Mitigation Status | |---|---|---|---|---|---|---| | (Example: Hiring Recommendation Engine) | (Example: Recommends candidates to recruiters; final hire decision by human) | (Example: Internal hiring records 5-yr, LinkedIn) | (Example: Read-Only; recruiter can request explanation) | (Example: Regulatory, Fairness/Bias) | (Example: Medium Impact × Medium Prob = Medium Risk) | (Example: Covered — Quarterly fairness audit + monthly bias testing) |

Key Takeaways

1. Concreteness matters: An abstract "AI governance framework" is easy to ignore. A specific risk register with names, scores, and mitigations is harder to dismiss.
2. Measurement enables accountability: You can track whether high-risk systems are covered. You can report progress to the board.
3. Second-line ownership is critical: The register is useless if risk and compliance don't own it. They must fill it out, update it, and defend the assessments.
4. The board needs visibility: The register is the board's primary control — the one document that shows whether AI governance exists and is active.

A risk register doesn't guarantee perfect governance. But a company without one has admitted it has no baseline AI governance at all.

---

Word count: ~1,200 | Reading time: 10 minutes