AI Governance, Risk and Compliance (AI-GRC)

Building a Centralized AI Management System (AIMS) on an Enterprise GRC Foundation

Aligned to ISO/IEC 42001:2023, the EU AI Act, and NIST AI RMF 1.0

Meridian Financial Group had moved from experimenting with generative AI to operating it in production, but adoption had outpaced governance: no authoritative inventory of AI systems, no consistent way to assess AI-specific risk, and no repeatable means of proving to auditors and regulators that AI controls actually worked.

42001

ISO/IEC AI mgmt standard

Frameworks mapped as one

~70%

Evidence collected automatically

50–70%

Audit prep effort reduced

Cooperating platform components

24h

Continuous assurance cycle

At a Glance

Domain AI Governance, Risk and Compliance (AI-GRC)

Reference standard ISO/IEC 42001:2023 — Artificial Intelligence Management System

Illustrative sector Regulated financial services (composite)

Prepared by Vignesh J Nathan, Senior GRC Project Manager and Solution Architect

Version / date v1.0, July 2026

Meridian Financial Group · ~8,000 employees ISO/IEC 42001:2023 EU AI Act NIST AI RMF 1.0 Platform-neutral reference architecture

Basis of This Case Study

This document is an illustrative composite. The reference architecture, component design, and end-to-end lifecycle are taken from an actual ISO/IEC 42001 solution design; the client ("Meridian Financial Group"), figures, and outcomes are representative of the target operating model rather than audited results from a single named engagement. The design is platform-neutral and maps cleanly onto an enterprise GRC platform such as Corporater BMP, ServiceNow GRC, or an equivalent.

1. Executive Summary

From Ad Hoc AI Adoption to a Governed Management System

Meridian Financial Group, a regulated financial services organization of roughly 8,000 employees, had moved from experimenting with generative AI to operating it in production: a customer-support assistant, a credit-decisioning model, and a portfolio of internal copilots. Adoption had outpaced governance. The organization had no authoritative inventory of its AI systems, no consistent way to assess AI-specific risk, and no repeatable means of proving to auditors and regulators that its AI controls actually worked.

Meridian set two board-level objectives: achieve certification against ISO/IEC 42001:2023, and stand up the operational capability to meet emerging obligations under the EU AI Act for its high-risk credit model. Rather than deploy a standalone AI point tool, Meridian chose to build a centralized AI Management System (AIMS) on its existing enterprise GRC platform, treating AI as a governed asset class alongside its established risk, control, and audit disciplines.

The delivered solution integrates AI platforms, identity, DevOps, security, data governance, privacy, and ITSM systems into a single governance layer. Its defining characteristic is a shift from point-in-time attestation to continuous control assurance: evidence is collected automatically from source systems, controls are evaluated on a schedule, and a failing control raises an AI incident without human prompting. The result is an AIMS that governs, assesses, monitors, and demonstrably assures AI across its full lifecycle.

Outcomes at a Glance

Dimension	Before	Target state with the AIMS
AI system visibility	Ad hoc spreadsheets; unknown shadow AI	Single authoritative AI Asset Register, auto-populated on deployment
Risk and impact assessment	Inconsistent, one-off, undocumented	Standardized lifecycle assessment with scored approvals
Evidence for audit	Manual screenshots and email requests	About 70% of control evidence collected automatically via integrations
Control assurance	"Is it implemented?" (design only)	"Is it operating?" (continuous effectiveness testing)
Audit preparation effort	Weeks of manual collation per audit	Evidence pre-assembled; effort reduced by an estimated 50 to 70%
Regulatory posture	Reactive, fragmented	One control mapped to ISO 42001, the EU AI Act, and NIST AI RMF simultaneously

Figure 1. Indicative before/after view. Percentages describe the designed target operating model, not audited engagement results.

2. Client Context and Business Drivers

From Shadow AI to a Board-Level Priority

Organization (illustrative). Meridian Financial Group operates retail lending, wealth management, and payments across multiple jurisdictions. Like most financial institutions, it sits under overlapping supervisory regimes and has a low tolerance for uncontrolled model risk.

AI footprint. At project initiation, Meridian had three categories of AI in production or near-production:

Customer-facing GenAI: a support assistant built on Azure OpenAI, exposed to prompt-injection, hallucination, and data-leakage risk.

High-risk decisioning: a credit-scoring model that materially affects individuals and is in scope as a high-risk system under the EU AI Act.

Internal copilots: a growing set of productivity tools built by business units with little central oversight ("shadow AI").

Business Drivers

Four forces converged to make AI governance a board priority rather than a technical nicety:

Driver	What It Demanded
Certification mandate	A demonstrable, auditable AIMS conformant with ISO/IEC 42001:2023.
Regulatory exposure	Readiness for EU AI Act high-risk obligations: risk management, logging, human oversight, transparency.
Board-level risk visibility	A single view of AI risk, incidents, and assurance status for the risk committee.
Operational efficiency	An end to the manual, evidence-gathering fire drill that preceded every audit.

3. The Challenge

Capable Tools, No Governance Layer Above Them

The core problem was not a lack of AI tooling; Meridian had capable MLOps, security, and privacy platforms. The problem was the absence of a governance layer that could sit above them and answer, on demand, three questions: what AI do we run, what could go wrong, and can we prove our controls work?

Pain Point	Business Impact
No authoritative AI inventory	Impossible to scope certification or regulatory obligations; shadow AI unaccounted for.
Inconsistent risk and impact assessment	AI-specific risks (bias, hallucination, prompt injection) assessed unevenly, if at all.
Manual, fragile evidence collection	Every audit triggered weeks of screenshotting and chasing owners; evidence went stale immediately.
Design-only control view	Controls were documented as "implemented" but no one knew if they were still operating.
Siloed frameworks	ISO, EU AI Act, and NIST managed separately, duplicating the same underlying controls.
No board-level assurance	Executives could not see AI risk posture or incident status in one place.

4. Solution Objectives

A Centralized Capability to Govern, Assess, Monitor, and Assure

The AIMS was chartered to deliver a centralized capability to govern, assess, monitor, audit, and continuously assure AI systems in accordance with ISO/IEC 42001. Concretely, it had to enable Meridian to:

Maintain a complete, authoritative inventory of all AI systems.

Assess AI risks and impacts across the full AI lifecycle.

Implement and monitor AI governance controls.

Collect control evidence automatically from enterprise systems.

Demonstrate compliance with ISO 42001 and related regulations.

Provide executive dashboards for AI assurance and reporting.

Scoping principle — what the platform does and does not do: the GRC platform does not train models, run fairness tests, or perform drift detection. Those remain in specialized AI, MLOps, security, and monitoring tools. The platform's role is to govern, assess, orchestrate workflows, collect evidence, and demonstrate assurance. This separation of responsibilities is what keeps the design scalable and audit-efficient.

5. Solution Architecture

A Four-Layer Governance Stack

5.1 High-Level Design

The architecture is a four-layer governance stack. Enterprise systems act as sources of truth; an integration layer brokers data between them and the GRC platform; the ISO 42001 module governs and assures; and role-based users consume the outputs. Evidence flows up the stack; governance, controls, and reporting flow down.

Layer	Contents
External enterprise systems	AI platforms (Azure OpenAI, AWS Bedrock, Vertex AI, OpenAI, Databricks, MLflow); Identity (Entra ID, Okta); DevOps (GitHub, Azure DevOps, Jenkins); Security (Sentinel, Splunk, QRadar); Data governance (Purview, Collibra); Privacy (OneTrust); ITSM (ServiceNow, Jira)
Integration layer	API gateway, connectors, webhooks, event bus
GRC platform: ISO/IEC 42001 AI Management module	AI Asset Register; AI Risk Management; AI Impact Assessment; AI Control Library; Control Assurance Engine; Evidence Repository; AI Incident Management; AI Audit Management; AI Vendor Risk; Compliance Mapping; Executive Dashboard; Policy and Workflow Engine
Platform users	Risk managers, auditors, compliance team, data scientists, executives

Figure 2. High-level architecture of the ISO/IEC 42001 AI Management System. The continuous assurance loop: evidence flows up from integrated systems; governance, controls, and reporting flow down to users.

5.2 Integration Layer

The integration layer is the mechanism that makes continuous assurance possible. Through an API gateway, pre-built connectors, webhooks, and an event bus, the platform both discovers AI systems and pulls control evidence on a schedule: deployment logs from DevOps, security events from the SIEM, privacy assessments from OneTrust, and model metadata from the AI platforms themselves.

5.3 Platform Components

The ISO 42001 module comprises twelve cooperating components. Each maps to specific clauses and Annex A controls of the standard.

#	Component	Purpose
1	AI Asset Register	Authoritative inventory of every AI system: owners, model type, data sources, environment, risk rating, lifecycle status. Auto-registers new models on deployment.
2	AI Risk Management	Identifies and scores AI-specific risks (hallucination, bias, prompt injection, data leakage, explainability) and drives treatment and approval.
3	AI Impact Assessment	Evaluates organizational impact before deployment across human rights, privacy, fairness, transparency, safety, and regulatory dimensions.
4	AI Control Library	The heart of the AIMS: governance, security, operations, compliance, and privacy controls mapped to ISO 42001 Annex A.
5	Control Assurance Engine	Tests whether each control is continuously operating (not merely implemented) via monitoring rules and evidence evaluation.
6	Evidence Repository	Automatically stores time-stamped evidence collected from GitHub, Splunk, Sentinel, OneTrust, and other systems.
7	AI Incident Management	Dedicated workflow for hallucination, bias, prompt injection, model failure, unauthorized access, and data-leakage incidents.
8	AI Audit Management	Plans audits, selects controls, draws on pre-collected evidence, records observations, and drives CAPA to closure.
9	AI Vendor Risk	Tracks AI vendors, contracts, certifications, and SLA reviews; integrates with SecurityScorecard, BitSight, and OneTrust.
10	Compliance Mapping	Maps one control to ISO 42001, the EU AI Act, NIST AI RMF, and internal policy, eliminating duplicate control management.
11	Executive Dashboard	Board-level KPIs across governance, risk, controls, incidents, audits, and compliance.
12	Policy and Workflow Engine	Orchestrates approvals, notifications, and lifecycle transitions that bind the other components together.

5.4 Logical Data Model

At the centre of the model is the AI Asset. Every other entity hangs off it, which is what allows an auditor to start from a single system and traverse to its risks, controls, evidence, incidents, and compliance obligations without leaving the platform.

Entity	Key Attributes	Relationship to AI Asset
AI Asset	Owners, lifecycle, model details, environment, risk rating	Root entity
Risk	Likelihood, impact, treatment, residual risk	Asset has many Risks
Control	Objective, status, test frequency, evidence source	Asset has many Controls
Impact Assessment	Questionnaire responses, scores, approvals	Asset has many Assessments
Evidence	Source system, timestamp, status, API/attachment reference	Asset (via Control) has many Evidence records
Incident	Severity, root cause, corrective actions	Asset has many Incidents
Audit Finding	Scope, findings, recommendations, CAPA	Asset has many Findings
Compliance Requirement	ISO clause, Annex A control, related regulation	Asset maps to many Requirements

6. Implementation Approach

Inventory First, Assurance Last

Delivery was phased to produce governance value early and defer the heavier automation until the foundation was stable. Rather than a big-bang rollout, the programme sequenced inventory first and assurance last.

Phase	Focus	Key Deliverables	Indicative Duration
1: Foundation	Inventory and governance	AI Asset Register live; ownership model; AI policy set; asset discovery from AI platforms	4 to 6 weeks
2: Assess	Risk and impact	Risk register, impact-assessment questionnaires, scoring and approval workflows	4 to 5 weeks
3: Control	Control library	Annex A control library, control-to-asset assignment, manual evidence baseline	5 to 6 weeks
4: Assure	Continuous assurance	Integrations, monitoring rules, automated evidence, incident automation, dashboards	6 to 8 weeks

6.1 Workstreams

Governance and policy: AIMS scope, roles, AI policy, review board charter.

Platform configuration: data model, registers, workflows, dashboards.

Integration engineering: connectors to AI platforms, DevOps, SIEM, privacy, and ITSM.

Control and assurance design: control library, monitoring rules, evidence mapping.

Change and enablement: training for risk, audit, compliance, and data-science users.

7. Continuous Control Assurance

From Point-in-Time Attestation to Always-On Operating Effectiveness

The design's central differentiator is the Control Assurance Engine. A conventional GRC deployment asks whether a control is implemented and records a periodic attestation. This AIMS asks a harder question: is the control continuously operating? It answers that question with evidence pulled directly from source systems.

The Continuous Assurance Loop

Control
definition

Automated
monitoring rule

API call to the
source system

Collect and
store evidence

Evaluate pass
or fail

Pass → evidence retained for audit

Fail → AI incident auto-raised, control owner notified

Figure 3 — The continuous control assurance loop: from point-in-time attestation to always-on operating effectiveness. A failing test auto-generates an AI incident.

7.1 A Worked Example

Consider a control requiring human review of high-impact chatbot responses. Instead of an annual sign-off, the engine tests it continuously:

Element	Configuration
Control	Human-in-the-loop review is enforced for flagged high-impact responses.
Monitoring rule	Every 24 hours, sample flagged interactions and confirm a reviewer action exists.
API call	Query the AI platform and ITSM system for review records.
Evidence	Time-stamped review logs stored in the Evidence Repository.
Pass	Control marked operating; evidence retained for the next audit.
Fail	AI incident auto-raised; control owner notified; CAPA initiated.

8. End-to-End Assurance Scenario

One Chatbot, Through the Full Lifecycle

The following walkthrough shows the components cooperating across the lifecycle of a single AI system: Meridian's customer-support chatbot built on Azure OpenAI.

Discovery. The Azure OpenAI integration registers the chatbot in the AI Asset Register the moment it is deployed, with no manual entry.

Assessment. The business owner completes an AI Impact Assessment covering privacy, bias, and human oversight; the system produces an impact score and approval recommendation.

Risk identification. Prompt injection and hallucination risks are linked to the asset, scored, and given treatment plans.

Control assignment. Controls for human review, API-key management, logging, and monitoring are assigned from the Control Library.

Continuous assurance. Monitoring detects a rise in hallucination rate and forwards evidence to the platform.

Issue creation. The failed control automatically raises an AI incident and notifies the control owner.

Audit. During the ISO 42001 audit, the auditor reviews the asset, its assessments, evidence, incidents, and control performance, without requesting a single screenshot.

Reporting. Executives see compliance status, high-risk AI systems, open incidents, and assurance metrics on one dashboard.

9. Multi-Framework Compliance Mapping

One Control, Tested Once, Counted Everywhere

A single well-designed control typically satisfies obligations in several frameworks at once. The Compliance Mapping component makes that relationship explicit, so a control tested once counts everywhere. The table below illustrates the pattern for a representative set of controls.

AIMS Control	ISO/IEC 42001	EU AI Act	NIST AI RMF
AI human oversight	Annex A: human oversight of AI systems	Art. 14: human oversight	MANAGE / GOVERN functions
AI risk management process	Clause 6: risk and impact planning	Art. 9: risk management system	MAP / MEASURE functions
Logging and traceability	Annex A: operational logging	Art. 12: record-keeping / logs	MEASURE: traceability
Transparency to users	Annex A: information to interested parties	Art. 13: transparency	GOVERN: transparency and accountability
Data governance and quality	Annex A: data for AI systems	Art. 10: data and data governance	MAP: data and input controls

Figure 4. Illustrative control-to-framework mapping. Clause/article references are indicative and should be confirmed against current published texts during implementation.

10. Outcomes and Value Realised

Measurable Improvements and a Qualitative Shift

The value of the AIMS is best understood in two registers: measurable operating-model improvements, and qualitative shifts in how the organization governs AI. The figures below describe the designed target state and should be validated against each organization's baseline.

Outcome	Mechanism	Indicative Effect
Audit effort reduced	Evidence pre-collected via integrations rather than gathered per audit	About 50 to 70% less manual preparation
Evidence automation	Direct API collection from DevOps, SIEM, and privacy tools	About 70% of controls evidenced automatically
Faster time-to-certification	Standardized assessments and a mapped control library	Weeks removed from the certification cycle
Reduced control duplication	One control mapped to three frameworks	Single test satisfies ISO, EU AI Act, and NIST
Shadow-AI reduction	Auto-discovery from AI platforms	Previously unknown systems brought under governance
Faster incident response	Auto-raised incidents on control failure	Detection-to-owner notification in near real time

10.1 Qualitative Outcomes

AI governance moved from a periodic, document-driven exercise to a continuous, evidence-driven capability.

The risk committee gained, for the first time, a single defensible view of AI risk and assurance posture.

AI was absorbed into the organization's existing GRC discipline rather than managed as a disconnected special case.

11. Key Success Factors and Lessons Learned

What Made the Design Hold Up

Inventory first

Nothing downstream, risk, control, or audit, is trustworthy without a complete, auto-maintained asset register.

Automate evidence, not judgement

The platform should collect and evaluate evidence, but human accountability for approvals and treatment must remain explicit.

Keep the platform in its lane

Resisting the temptation to build model-testing into the GRC platform kept the design scalable and maintainable.

Map once, satisfy many

Investing early in framework mapping paid back across every subsequent audit.

Design for the auditor

Every design decision was tested against one question: can an auditor retrieve this without asking a human?

12. Conclusion

From Claiming AI Governance to Evidencing It

By building its AI Management System on an enterprise GRC foundation, Meridian turned AI governance from an aspiration into an operating capability. The platform governs AI through policy, ownership, and lifecycle management; assesses risk and impact before and after deployment; orchestrates approvals, incidents, and audits; collects evidence automatically; and, crucially, demonstrates that AI controls are designed, implemented, and operating effectively over time.

That last point is the essence of ISO/IEC 42001. The standard does not reward organizations for owning AI policies; it rewards them for proving those policies work. A GRC-anchored AIMS, with continuous assurance at its core, is how an organization moves from claiming AI governance to evidencing it, continuously and at scale.

Appendices

Reference Schemas and Catalogues

Appendix A: AI Asset Register (Core Schema)

Field	Description
AI System Name	Human-readable identifier of the system
Business / Technical Owner	Accountable business owner and responsible technical owner
Vendor and Model Type	Provider and model family (for example, Azure OpenAI, GPT-class)
Purpose and AI Category	Business use case and classification (for example, high-risk decisioning)
Risk Rating	Current inherent/residual rating
Data Sources	Datasets and feeds consumed by the system
Deployment Environment	Where the system runs (cloud/platform)
Status and Version	Lifecycle status and deployed version
Integrations	Connected systems (Azure OpenAI, MLflow, Databricks, AWS Bedrock)

Appendix B: Sample AI Control Library

Domain	Representative Controls
Governance	AI policy; AI committee; AI review board
Security	Authentication; encryption; API-key rotation
Operations	Drift monitoring; hallucination monitoring; human approval
Compliance	Model documentation; impact assessment; audit logging
Privacy	Consent validation; PII detection

Appendix C: Executive Dashboard KPI Catalogue

Category	KPIs
Governance	Total AI systems; high-risk AI; critical vendors
Risk	Open risks; critical risks; residual risk
Controls	Operating controls; failed controls; automated controls
Incidents	Open incidents; hallucinations; prompt injections
Audits	Audit findings; CAPA; overdue actions
Compliance	ISO 42001 %; EU AI Act %; NIST AI RMF %

"The standard does not reward organizations for owning AI policies; it rewards them for proving those policies work. A GRC-anchored AIMS, with continuous assurance at its core, is how an organization moves from claiming AI governance to evidencing it, continuously and at scale."

Categories