Key takeaways
- Compliance and governance are not two parallel domains; they are two faces of one operating model that turns strategic intent into auditable evidence.
- Governance sets direction and authority; compliance proves the organization stayed inside the lines it agreed to follow.
- The OCEG GRC Capability Model 3.5, the NIST Cybersecurity Framework 2.0, and the NIST AI Risk Management Framework all share the same architecture: govern, then translate down to controls.
- The 2024 addition of the GOVERN function to NIST CSF 2.0 and the parallel publication of
ISO/IEC 42001and theEU AI Actmark the moment compliance and governance fused into a single accountable workflow. - A working compliance and governance system can be measured by one test: can it trace an external obligation, line by line, to a control, an owner, and a piece of evidence inspectors could audit tomorrow morning.
What compliance and governance actually mean
Most explainers on the first page of Google start with a tidy Venn diagram, and most of them stop there. The lesson buried under the diagram is more useful: governance and compliance are sequential functions of the same operating model, not separate disciplines.
Governance: setting direction
NIST groups governance, risk, and compliance into a single discipline because they share the same purpose: aligning what an organization does with what its leadership has decided it should do. Governance is the upstream half of that work. It decides who is allowed to make which decisions, on what evidence, and against which boundaries. In a typical enterprise, governance shows up as charters, delegated authorities, board committees, policies, and the calendar of decisions those bodies have to make in a given year. The defining characteristic of governance is that it sets direction. It does not check that direction was followed. That is the job of the second half of the model.
Compliance: proving you stayed on course
Compliance is the downstream half. It accepts the direction the governance layer has set, then produces the evidence that the organization stayed inside that direction. The evidence is what auditors, regulators, and counterparties consume. In a regulated environment, compliance has two audiences. Internal audit looks at evidence to confirm controls operated as designed. External regulators look at the same evidence to confirm the legal obligation has been met. The two often inspect the same artifacts. The labelling differs because the audience differs.
The Venn diagram the top ten stops at
Most pages on this topic draw governance and compliance as overlapping circles, with risk as the bridge between them. That image is not wrong, but it hides the part that matters. The two functions are not just adjacent: they are designed to feed each other. Governance produces obligations and rules; compliance produces evidence those obligations were honored; that evidence flows back to governance to inform the next cycle of decisions. When the loop is broken, organizations end up with policies no one operationalizes and controls no one mapped to a policy. That is the failure mode that every modern governance framework, from OCEG GRC 3.5 to NIST CSF 2.0 to ISO/IEC 42001, is trying to prevent.
Why they merged into GRC: a 20-year arc
The acronym GRC was coined in 2002 by the Open Compliance and Ethics Group (OCEG), and the first OCEG Red Book describing the capability model arrived in 2004. The proximate driver was the Sarbanes-Oxley Act of 2002, which forced US-listed companies to produce auditable evidence that their internal controls over financial reporting actually worked. Companies that already had governance, risk management, and compliance functions discovered that running them as silos made the SOX evidence chain almost impossible to assemble. OCEG’s contribution was to name a unified capability, then publish an open-source model of what good looks like. The Red Book defined Principled Performance as the goal: reliably achieving objectives, addressing uncertainty, and acting with integrity. Every capability OCEG describes is an instrument for that single outcome. Two decades later, the architecture has been adopted almost universally. The next inflection point arrived in February 2024, when NIST released CSF 2.0. The change was less about cybersecurity than about governance: NIST added GOVERN as a sixth core function, alongside Identify, Protect, Detect, Respond, and Recover. The same year, ISO published ISO/IEC 42001, the first international management-system standard for artificial intelligence. The two events ratified the same idea from different angles: govern first, then translate down to controls. Compliance is the audit trail of that translation.
The integrated operating model: one stack, three frameworks
The three frameworks most commonly stitched together by enterprise GRC teams look superficially different. They share the same skeleton.
OCEG GRC Capability Model 3.5
The current OCEG model groups its capabilities under four components: LEARN the context, the culture, and the stakeholders that should shape objectives; ALIGN strategy with those objectives and actions with strategy; PERFORM actions that promote desired outcomes and prevent undesired ones; and REVIEW to detect what worked and feed the next cycle. Each component decomposes into capabilities, each capability into practices, and each practice into artifacts a real organization can produce. The model is deliberately scope-neutral so it can host any obligation, from financial reporting to information security to AI.
NIST CSF 2.0’s six functions
NIST CSF 2.0 organizes its work around six functions: Govern, Identify, Protect, Detect, Respond, and Recover. The GOVERN function, added in 2024, sits at the center. It is the function that articulates the organization’s cybersecurity risk strategy, expectations, and policy, then makes sure they show up in the other five. The choice was deliberate: cybersecurity controls without a governance layer produce activity, not assurance.
NIST AI Risk Management Framework’s four functions
The NIST AI Risk Management Framework ships with four functions: GOVERN, MAP, MEASURE, and MANAGE. GOVERN comes first by design. It scopes accountability, defines tolerable risk, and assigns the resources the other three functions need. MAP catalogues context and impact. MEASURE quantifies. MANAGE applies the chosen treatments. The shape is intentionally familiar to any organization already running CSF or COBIT: govern first, then translate down.
One skeleton, three scopes
These three models are not in competition. They are the same operating system applied to different scopes: enterprise risk, cyber risk, AI risk. The work of a modern compliance and governance team is to recognize the shared architecture, then stop maintaining three parallel control libraries when one well-structured library would do.
The control architecture: from obligation to evidence
The piece almost no top-ranked page on this keyword covers in depth is also the piece that decides whether a compliance and governance program is real or theatre: the four-link chain that runs from an external obligation to a piece of evidence.
Obligation, control, evidence, assurance
An obligation is the binding statement an external authority makes the organization accountable for. It can be a clause of a regulation, a contractual commitment, a standard the organization elected to certify against, or a board-imposed policy. The wording is rarely operational. EU AI Act Article 9(2)(a) says providers of high-risk AI systems shall establish, implement, document, and maintain a risk management system. That sentence is binding, not implementable. A control is the operational restatement of the obligation. It names a behavior the organization performs, often on a recurring schedule, and identifies who performs it and what artefact it produces. For Article 9, the control might be: the AI Risk Committee reviews the model risk register quarterly, signs off on the residual risk classification, and updates the risk treatment plan within five business days. The evidence is the artefact the control produces. The signed sign-off form, the dated register, the updated treatment plan, the chair’s email confirming the decision. Evidence has provenance, a timestamp, and a custodian. Assurance is the independent check that controls operated as designed and that the evidence is what it claims to be. Internal audit produces assurance for the board; an external certifier produces assurance for a market.
Worked example: EU AI Act Article 9 translated end-to-end
Take the same obligation through the chain. The obligation: EU AI Act Article 9(2) requires providers of high-risk AI systems to maintain a continuous risk management process across the lifecycle. The control: every model in the high-risk inventory has a named risk owner, a quarterly review cadence anchored in the Risk Committee charter, and a documented treatment plan that references the impact-and-severity matrix the governance layer approved. The evidence: the Risk Committee minutes, the inventory entry with the latest review date, the treatment plan with version history, the sign-off email from the risk owner. The assurance: an internal audit sample of three models per quarter, plus the annual notified-body assessment that confirms the QMS clause of Article 17 is operating. Once the chain is built for one obligation, the same shape is reused for every other one. That reuse is the whole point.
Where most GRC tools stop, and what an AI-governance platform adds
Most general-purpose GRC tools handle the first two links of the chain reasonably well: they let you store obligations and map them to controls. The third and fourth links, evidence and assurance, are usually offloaded to ticketing systems and shared drives. That setup worked when an obligation pointed at a static control. It breaks when the asset under governance is a machine-learning model whose behavior changes with every retraining cycle. An AI-specific governance platform closes the loop by tying the evidence chain directly to the model lifecycle, so the fact that a model was retrained on Tuesday automatically triggers the control owner’s quarterly review on Wednesday. That coupling is what AI Sigil’s AI governance platform was designed to provide on top of an existing GRC stack.
Roles, accountability, and the three-line model
Most large organizations operationalize governance through the three-line model: the first line owns and operates the controls; the second line oversees risk and compliance functions and challenges the first; the third line, internal audit, provides independent assurance to the board. The model has been around long enough to be uncontroversial. What is changing is the cast list. The Chief Compliance Officer remains accountable for the regulatory inventory. The Chief Risk Officer still owns the risk-appetite statement. The board’s audit committee still consumes the assurance. Two roles have been promoted in the AI era: the Chief Information Security Officer increasingly owns the controls that protect AI training data and model weights; and a Head of AI Governance, often reporting jointly to the CCO and the CTO, is now the natural owner of the AI-specific control library. Where this role does not exist yet, the practical sign is that no one can answer the question of who reviews the latest model card before deployment. The model adapts gracefully when the asset under governance is an AI system. The first line includes model owners, data scientists, and MLOps engineers; the second line adds an AI risk function alongside operational risk; the third line audits the model risk inventory the same way it audits the loan-loss provision register.
The AI-era inflection: why GRC is being rebuilt around AI workloads
For the last twenty years, GRC programs absorbed new regulations by extending the existing control library. The AI wave is forcing a structural reset because AI workloads break two assumptions the legacy GRC architecture rests on: the asset is static between audits, and the supplier chain is bounded by procurement.
EU AI Act timeline
The EU AI Act entered into force on 1 August 2024, with phased applicability dates that already constrain operating budgets. Prohibitions on unacceptable-risk practices and AI literacy obligations applied from 2 February 2025. Rules for general-purpose AI models, notified bodies, governance, confidentiality, and penalties applied from 2 August 2025. The Annex III high-risk obligations were deferred from 2 August 2026 to 2 December 2027 under the Digital Omnibus on AI agreed in May 2026. The deferral changes the deadline; it does not change the work.
ISO/IEC 42001 as the operational layer
ISO/IEC 42001, published in December 2023, is the first management-system standard dedicated to AI. The standard answers the question the EU AI Act does not: how. According to ISACA’s 2025 mapping, the standard maps directly to seven core Act articles: risk management (9), data and data governance (10), technical documentation (11), record-keeping (12), transparency (13), human oversight (14), and quality management systems (17). The overlap covers an estimated forty to fifty percent of high-level requirements, which means evidence produced for one regime accelerates work for the other.
NIST AI RMF’s GOVERN function in detail
The GOVERN function of the NIST AI RMF is the bridge between an organization’s existing enterprise risk culture and its new AI-specific control library. It defines the cultural, structural, and procedural conditions for the other three functions to work. It also explicitly recognizes that AI risk is socio-technical: the framework asks organizations to assess not just whether a model performs as designed but whether its deployment is compatible with the values and obligations of its operating context.
Why AI exposes the limits of generic GRC tooling
Three properties of AI systems break generic GRC tooling. First, the asset changes between audits: a retrained model is not the model the previous control evidence described. Second, supply chains are wider: a single deployed system may depend on a foundation model, a fine-tuning dataset, an inference platform, a feature store, and a feedback loop each owned by a different party. Third, the consequence space is larger: failures range from biased outputs to autonomous actions a human did not request. A compliance and governance program built for static IT services needs an extension layer designed for these properties.
Implementing compliance and governance: a 90-day starter blueprint
Mature programs were built incrementally. The first ninety days exist to get the architecture right before the inventory grows.
Days 0 to 30: map current state and inventory obligations
Build the obligation inventory first. List the regulations, contractual commitments, certifications, and board policies the organization is bound by. Capture the binding text, the regulator or counterparty, the in-force date, and the named accountable executive. Then list the controls that already exist, regardless of how they are stored today. The output is a two-column register: obligations and existing controls, with the gaps and orphans visible.
Days 31 to 60: instantiate the control architecture for two pilot obligations
Pick two obligations that matter. One should be familiar territory (a SOX, GDPR, or ISO 27001 clause); one should be AI-specific (an EU AI Act article or an ISO/IEC 42001 clause). Build the full four-link chain for each: obligation, control, evidence, assurance. Time the work. The first chain typically takes a week; the second takes two days. That ratio is the proof of concept the rest of the program will build on.
Days 61 to 90: define the evidence cadence and the assurance loop
Decide how often each control produces evidence, who reviews the evidence, and what triggers an exception. Build the cadence into the calendar of the responsible team, and define the path an exception takes before it lands on the Risk Committee agenda. Stand up the first internal-audit sample of the two pilot controls before day 90. By the time the sample is complete, the organization has lived through one full compliance and governance cycle for two obligations and has the evidence to scale the model.
Compliance and governance in practice: an SME and an enterprise
The operating model scales down and up.
SME using one ISO 27001 plus one EU AI Act obligation pair
A 200-person fintech with a single AI-powered fraud detection model can run a credible program with ten controls. The obligation list is short: ISO 27001 for information security, the relevant EU AI Act articles for the AI system, the local regulator’s outsourcing rules. The control library inherits SOC 2 evidence the company already produces and adds three AI-specific controls: model risk register, retraining sign-off, and post-deployment monitoring threshold review.
Multinational mapping SOX, GDPR, EU AI Act, and sector regulations
A global bank operates on a different scale. SOX evidence underwrites the quarterly earnings release. GDPR controls protect customer data across thirty jurisdictions. EU AI Act controls cover the high-risk credit-scoring model and the prohibited-practices screen on the marketing stack. Sector-specific rules such as EBA model risk guidance overlay all of the above. The control library counts thousands of items. The architecture is the same as the fintech’s: obligation, control, evidence, assurance. Only the volume changes.
Frequently asked questions
What is meant by compliance and governance? Governance sets the direction an organization commits to follow, through charters, policies, and delegated authorities. Compliance produces the evidence that the organization stayed inside that direction. Together they form the operating model that turns external obligations into auditable controls and the artefacts those controls produce. What are the 4 Ps of governance? The 4 Ps most commonly cited in public-sector and corporate governance literature are People (who holds authority and accountability), Purpose (the mission or objectives the organization commits to), Process (how decisions get made and reviewed), and Performance (how outcomes are measured and reported). The exact list varies by source; the underlying point does not. Governance frameworks succeed when they make the four explicit and the relationships between them auditable. What are the 4 phases of compliance? A compliance lifecycle typically runs through four phases: Identify the obligation and the scope it applies to; Implement the controls that satisfy the obligation; Monitor the controls so deviations are caught early; and Report the evidence to internal and external audiences. Each phase produces artefacts the next phase depends on. Programs that skip the monitor and report phases produce policies but not assurance. What are the three Cs of compliance? The three Cs most often cited are Culture, Communication, and Controls. Culture is what shapes day-to-day decisions when no one is watching. Communication is what keeps obligations visible to the people whose work touches them. Controls are the behaviors and artefacts that translate policy into evidence. The three reinforce each other; an organization that invests only in Controls without Culture and Communication will rebuild the same gaps every audit cycle. Is GRC the same as compliance and governance? Almost. GRC is a superset that adds risk management as the third pillar. Compliance and governance describe the direction-setting and evidence-producing halves of the model; risk management is the function that decides which obligations and controls deserve the most attention. Most modern frameworks treat the three as inseparable, which is why OCEG, NIST, and ISO 42001 all wire them together. Is ISO 42001 mandatory under the EU AI Act? No. ISO/IEC 42001 certification is not legally required by the EU AI Act. The two are designed to complement each other. The Act tells regulated organizations what they must achieve; the standard describes how to run, evidence, and continuously improve an AI governance program in a way that satisfies regulators, certifiers, and the board. Certifying to 42001 does not by itself prove EU AI Act compliance, and compliance with the Act does not require 42001 certification. Most organizations are pursuing both because the underlying work overlaps by about half. Does AI Sigil replace our existing GRC tool? No. AI Sigil is designed to sit above an existing GRC stack as the operating layer dedicated to AI systems. It uses the same obligation, control, evidence, assurance chain, then connects the evidence side directly to the AI model lifecycle so a retraining event automatically triggers the relevant control reviews. The existing GRC tool keeps the enterprise control library; AI Sigil owns the AI-specific extension and feeds evidence back.
Conclusion
Compliance and governance are one operating model, not two domains. The frameworks the SERP keeps describing in side-by-side definitions are in fact rehearsing the same architecture: govern first, then translate down to controls, evidence, and assurance. NIST CSF 2.0’s GOVERN function, ISO/IEC 42001, and the EU AI Act did not invent that architecture; they ratified it for the AI era. The work for governance leaders today is to recognize the unified shape and stop maintaining parallel programs that produce duplicate evidence and conflicting decisions. The shortest path from where most organizations are today to where regulators and boards now expect them to be is to build one four-link chain, prove it on two obligations, then scale the architecture to the rest of the inventory. If you want to see what that operating layer looks like for AI systems specifically, the AI Sigil platform was built to slot in on top of the GRC stack you already run.