How do we build and maintain a multi-framework AI risk register?

The most common architecture for multi-framework risk registers — building one tab per framework and populating each independently — creates as many problems as it solves. It duplicates effort when frameworks share requirements, creates confusion about which framework's version of a requirement controls when they differ, and produces a register that is difficult to present to anyone who needs to understand overall risk posture rather than framework-specific compliance status.

A system-first architecture avoids these problems. Start by listing every AI system in scope. For each system, identify the material risks it presents: the harms it could cause, the obligations it triggers, and the controls that are or should be in place. Then map each risk to the frameworks that address it. A loan scoring model's automated decision-making risk maps to GDPR Article 22, EU AI Act Title III, and ECOA/Reg B simultaneously. A single risk entry with cross-framework notation is more actionable than three separate entries for the same underlying issue.

The system-first approach also makes accountability clearer. The system owner is accountable for managing that system's risks across all applicable frameworks. They do not need to understand the nuances of each framework — they need to understand the risks and the controls. The GRC team manages the framework mapping; the system owner manages the risk.

Most requirements in major AI governance frameworks have analogs in other frameworks. NIST AI RMF's GOVERN function overlaps substantially with ISO 42001's management system requirements. EU AI Act Article 9 risk management obligations share structure with NIST's MANAGE function. GDPR Article 22 automated decision-making requirements overlap with EU AI Act prohibited and high-risk system provisions for the same use cases. Mapping these overlaps explicitly is essential to avoiding duplicate remediation effort.

Build a cross-reference map as a companion to the register: a matrix showing which requirements in each framework address the same underlying risk category. When a control remediates a risk for one framework, the cross-reference map tells you which other frameworks the same control addresses. This prevents the common pattern of a team building an audit trail for GDPR compliance, then separately building an essentially identical audit trail for EU AI Act compliance — without realizing the two efforts are addressing the same underlying requirement.

Where frameworks genuinely conflict — where satisfying one framework's requirement would put you out of compliance with another — escalate to Legal for a documented resolution. These cases are less common than they appear; most apparent conflicts resolve when requirements are read carefully against their underlying purposes.

A risk register that is not actively maintained is worse than no register — it creates false confidence, misleads auditors, and fails to surface new risks as they emerge. The maintenance process is not complicated, but it requires discipline.

Designate a register owner responsible for keeping it current. Establish a quarterly review cycle: review each open item, update status, flag overdue remediations, and add any new risks identified since the last review. Integrate register review with your AI governance committee meeting cadence — a summary of open items by owner and target date should be a standing agenda item.

New risks enter the register through three channels: new regulatory developments (a new regulation or guidance adds requirements not previously tracked), system changes (a model update or use case expansion creates new risk exposures), and incidents (an incident reveals a risk that was not previously identified). Assign responsibility for each channel: regulatory monitoring feeds new regulatory risks, system change management feeds system change risks, and incident post-mortems feed incident-identified risks.