Jun 23 / James Kavanagh

How I map compliance expectations to common controls and mechanisms

How to map the requirements, obligations and practices from multiple compliance artifacts into a common control map, and on to operational mechanisms
I'm just back from a couple of weeks in Dublin and Italy. Part work, part holiday, and the kind of trip where the work conversations happen over coffee rather than in meeting rooms, which is usually when people tell you what they actually think.
Unsurprisingly, a lot of those conversations came back to the EU AI Act. But there wasn't really any anxiety or worry about the Act itself. These were practitioners in organisations that have been around a while, and they all said some version of the same thing: the Act isn't landing on a blank page. They already carry a substantial body of compliance obligations and compliance machinery to support it, whether it all works well or not. Privacy law, security standards, sector regulation, quality management systems, client contracts. AI governance doesn't arrive into a vacuum. Mostly, it arrives into an organisation that already has years of accumulated compliance machinery, and the real challenge is working out how the new requirements relate to what's already there.
And that points at the work that I think matters most here: finding the common expectations. They're the requirements that show up again and again across all the various regulatory, standards, framework and contract sources. Fortunately, they aren't going to change much.
The conversations took me straight back to Amazon, where we had to juggle exactly this problem: hundreds of regulations, standards, frameworks, and internal policies, in different stages of implementation, spanning security, privacy, resilience and eventually AI. You can't go to engineering teams every other week with a new law from somewhere in the world and ask them to re-engineer around it. So one of the enduring disciplines was finding the expectations that stayed invariant, and aiming at the right level when you did. By that, I mean not the lowest common denominator, not the legal minimum that technically satisfies everyone, but also not always the most extreme. The highest pragmatic common set of expectations in each domain. They're the demanding stable requirements that, if you design around them, satisfy the strict sources and the lenient ones at once, and keep satisfying them as new sources arrive. Find those, design around them, and what you build endures. You put anchors in place, so when the next regulation lands, you're already satisfying it or you're extending something solid, rather than starting over.
That's what this article is about. It's the second in my short series on how to approach compliance for AI governance when you face a complex set of regulatory, standards and other sources of requirements. That is - in the real world, not a textbook or a professional certification. The last article was about scoping: how you figure out which external requirements actually apply to your organisation and its systems. This one is about what you do next. 
So let's say you've got your pile of applicable artifacts. They speak different languages but a lot of them point at the same governance territory. How do you turn that into something coherent you can actually build and run as a compliance program?
Well, here's my method and it starts with four concepts in sequence: 
Artifact → Expectation → Control → Mechanism
I've previously written about Artifacts and Mechanisms, so this is bridging between them. I'll walk you through each step. But let me start with why you'd want a single framework in the first place, rather than just working through each regulation one at a time.

Why you need a common control framework (before it's too late)

The organic way to handle multiple compliance sources is to manage each one separately. The legal team tracks the EU AI Act. Someone in assurance handles ISO 42001 certification. Privacy specialists own GDPR. Client success handles the contractual requirements. Each source gets its own workstream, maybe with some ad-hoc consolidation later. It rarely starts as a deliberate choice. It just grows that way, one source at a time, each owned by whoever was closest when it landed.
Each source ends up with its own owner, its own workstream, its own way of describing more or less the same thing. And it fails over time in three ways that get worse with every source you add.
It duplicates effort. The EU AI Act expects providers of high-risk systems to maintain a risk management process. ISO 42001 expects something similar in a management system. So does the NIST AI RMF. Security teams need a threat and risk management process, as do the teams focused on privacy and supply chains. Manage these all separately and you build multiple risk assessment approaches, multiple sets of documentation, multiple review cycles, all for what could be a consolidated governance capability. Multiply that across every area where sources overlap, and you've multiplied a lot of work for no benefit. 
It creates gaps. Without a unified view, the expectations that fall between your separate programs go unnoticed. Each program looks complete within its own scope, so the organisation believes it's covered. But nobody's looking at the space between the programs, and that's exactly where the gaps emerge. At the boundaries.
It papers over conflicts nobody resolves. Sources sometimes pull in different directions. A transparency obligation under legislations might sit awkwardly against a client's confidentiality requirement. A US state's definition of "high-risk" might not line up with the EU's. Managed in separate silos, these conflicts surface late, during an audit or a client dispute, when they're expensive to sort out.
Here's the thing that makes the alternative worth the effort: the overlap between these frameworks is substantial. This isn't wishful thinking. NIST has published an official crosswalk mapping every AI RMF subcategory to ISO 42001 clauses, and vendor and practitioner analyses consistently put the control overlap between ISO 42001 and the EU AI Act somewhere in the 40 to 60% range. To give a real example: a single well-designed human oversight control can speak to the EU AI Act's Article 14 oversight provisions, the relevant NIST MEASURE and MANAGE subcategories, and ISO 42001's oversight controls at the same time. All of these frameworks are circling the same foundational ideas about what responsible AI governance looks like: manage your risks, oversee your systems, document what you do, respond when things go wrong.
The alternative is a single internal framework, organised by what governance actually does, not by where the requirements came from. No "EU AI Act domain", no "ISO 42001 domain." Functional domains like risk management, security, incident management and so on. External expectations from every source map into that framework. When a new regulation arrives, the framework doesn't change. The regulation just becomes another set of inputs to map.
And I'm not joking about needing to do this before it's too late. Done wrong, the burden only ever accumulates. Sources don't retire. Every new regulation, standard, framework, and contract adds another layer to the pile, and the duplication, the gaps, and the conflicts all compound with it. Left alone, it grows past the point where anyone can hold the whole picture in their head, and that's the point where I've seen well-meaning compliance quietly become theatre: a lot of documents, a lot of activity, a lot of workstreams, and no real confidence that the organisation is actually doing what it's supposed to. At some point you have to bite the bullet and deal with it properly, because the longer you leave it, the more expensive and the more entangled the eventual reckoning becomes.
Now I know the idea of a unified control set isn't new, and I'm not pretending it is. I've talked with lots of practitioners about how they approach this. There are established efforts out there: the Unified Compliance Framework, the Secure Controls Framework, the NIST crosswalks themselves. I've used several of them over the years. The trouble is that most are either built for general security and privacy rather than AI, or they're so large and abstract that they're hard to actually pick up and use. Their methodology - especially in something like the UCF - becomes so academic and at times pedantic as to make them practically unusable. What I use is something narrower in focus but more usable: fit for AI governance, sized to be learnable, and connected through to the mechanisms that make controls real rather than stopping at the mapping. It works for me, and I know it's worked at the scale of some of the largest and most complex organisations out there.

Artifacts and expectations

So let's walk the spine, starting from the left.
Artifact → Expectation → Control → Mechanism
An artifact is a source document. The EU AI Act is an artifact. ISO 42001 is an artifact. A client contract is an artifact. In the first article, scoping told you which artifacts are actually in scope for your organisation. Now we go inside them..
Artifacts contain expectations. An expectation is a specific thing the artifact expects you to do. The discipline here is parsing: pulling the expectations out explicitly rather than treating a whole article or clause as one undifferentiated blob.
Take Article 9 of the EU AI Act. It's tempting to read it as a single expectation, "do risk management," and move on. But Article 9 actually contains several distinct expectations: establish a risk management system, run it as a continuous iterative process, identify and analyse known and foreseeable risks, estimate and evaluate those risks, adopt appropriate risk management measures, and test the system to find the right measures. Those are different governance activities. If you parse Article 9 as one lump and map it to "risk management" as a domain, you've got a mapping too coarse to act on. Which part needs a mechanism? All of them? That doesn't tell you what to build. Parse it properly and each expectation points at specific work.
The rule of thumb is to parse to the level that drives action. Not so granular you're mapping every sentence structure (as you might do in UCF), but granular enough that each expectation tells you something concrete about what your governance needs to do.

Why the type matters

Not all expectations carry the same weight. A "shall" in the EU AI Act and a "should" in the NIST AI RMF are both expectations, but ignoring one of them has very different consequences from ignoring the other. I classify expectations into four types based on where they come from and how binding they are.
An obligation comes from legislation. It's legally binding and you have no discretion. The EU AI Act creates obligations. GDPR creates obligations. Ignore one and you face fines, enforcement, or loss of market access.
A requirement comes from a standard, and it becomes binding once you commit to certification. ISO 42001 creates requirements. Nothing compels you to pursue certification, but the moment you do, every applicable "shall" in the standard becomes something an auditor will hold you to.
A practice comes from a voluntary framework. The NIST AI RMF creates practices. No regulator will fine you for not following it. But practices increasingly define what competent AI governance looks like, so they carry real weight through professional expectation, even without legal force.
A commitment comes from a contract. Its binding force is contract law. A client agreement requiring 48-hour incident notification or annual bias audits is a commitment, and breaching it can cost you the relationship faster than a regulator would ever move.
The reason classification comes before mapping is that the type determines how you calibrate your response. The method is the same for every expectation. What changes is the rigour, formality, and precision you bring to it. You don't gold-plate a voluntary practice with the full apparatus you'd build for a legal obligation, and you certainly don't treat a legal obligation with the informality you might apply to a framework you adopted for guidance. You set the type early and every downstream decision is calibrated correctly from the start.

A common control framework

Then the expectations map into a control framework. The framework I've developed and use in practice has twelve domains, each owning a distinct territory of governance. The organising principle is governance function, which is what lets the framework stay stable while regulations come and go.
Just over a year ago I published a first version of this framework on my blog, a "mega-map" that crosswalked forty-four master controls across six sources: ISO 42001, ISO 27001, ISO 27701, the NIST AI RMF, the EU AI Act, and SOC 2. I built it the hard way, by printing out more than a thousand pages of regulatory text, physically cutting them into individual controls, and sorting the scraps into natural families on the floor of the biggest empty room I could find. It was painful and analogue and genuinely useful, and I know some people have built on it since. 
It has moved on a great deal since then, both the framework itself and, more importantly, the tooling that supports actually using it. Especially because I've been working with clients and practitioner who have adopted this in part or wholly. The version I'll describe here is where that work has landed right now.
Each domain breaks down into topics, and each topic into specific controls, so when you map an expectation it lands on a precise target: a control, within a topic, within a domain.
So there are the twelve domains and their topics:

AI Governance Common Control Framework

The crosswalk

The map from expectations to controls is the crosswalk. Mappings fall into three patterns.
One-to-one is the simple case. A discrete expectation maps to a single control. The Act's registration obligation maps to the regulatory registration control and nowhere else. Clean boundary, self-contained expectation.
One-to-many is where a single article spans several governance functions. EU AI Act Article 9, for example, maps across multiple risk management controls and reaches into the development lifecycle for the testing parts. This is exactly why parsing matters: without it, you can't see that one article touches several controls.
Many-to-one is where the framework proves its value. When multiple expectations from different sources all map to the same control, that control becomes a common control: one governance capability satisfying several external authorities at once. Risk assessment is the clearest example. The EU AI Act obligation, the ISO 42001 requirement, and the NIST AI RMF practice all converge on the same risk assessment control. Those are the anchors we're looking for.
Mapping is a matter of judgment, not just a mechanical lookup. Two competent practitioners might place the same expectation in slightly different controls at a boundary, and that's fine. What matters is that the decision is explicit, recorded, and defensible, so that anyone reviewing the crosswalk later understands why an expectation landed where it did.
Once you've mapped enough, patterns appear. Some domains become dense convergence zones where every source has substantial expectations: risk management, incident management, human oversight. Those are where common controls save you the most. They're also where a single mechanism failure is most costly, because failing one mechanism in a convergence zone means failing several authorities at once, not just one.

From control to mechanism

The last step is the one that I find separates real and effective compliance programs from paperwork. It's the mapping from controls to real, operational governance mechanisms.
A control that exists only in a policy document is not a functioning control. You can write the most elegant risk assessment control in the world, file it, and have absolutely nothing happening in practice. The mechanism is what makes a control real. It has inputs, outputs, an owner, tooling, and it actually runs.
This is where this series loops back to where it started. The first article I wrote, before this compliance series, was about diagnosing and fixing broken governance mechanisms using the seven components that make a mechanism function. The crosswalk tells you which controls need mechanisms. The diagnostic tells you whether those mechanisms actually work. They're two halves of the same picture.
And there's a quiet payoff in getting the mechanism right. A functioning mechanism produces evidence as a natural byproduct. The risk assessment mechanism produces risk assessment records. The incident mechanism produces incident logs. When the auditor or the regulator asks you to demonstrate compliance, you're not scrambling to assemble evidence after the fact, because the evidence is what the mechanism produces every time it runs. Build the mechanism well and the evidence takes care of itself.

Doing this work in Balcony

The crosswalk and the mechanism work can be done on a whiteboard and a spreadsheet, and that's a perfectly good place to learn the method. But it doesn't scale, for exactly the reasons the people I spoke with were grappling with: too many artifacts, too many expectations, too much change to track by hand.
This is the work that we've been building and piloting our Balcony platform for. It's a platform for AI Governance practitioners to do their work, designing and improving their governance practices. You bring in your artifacts, and their expectations are parsed and typed. You map those expectations onto the unified framework, and the crosswalk grows incrementally with each source you add. The convergence and divergence patterns become visible: where a new regulation overlaps with what you've already covered, and where it opens a genuine gap. And it stays living. When the next regulation lands, you add the artifact and map its expectations against the framework you've already built, rather than starting a new program.

Building a crosswalk in the Balcony Nexus platform

The tool structures the analytical work. It doesn't replace the judgment. The quality of the governance still depends on the quality of the thinking that drives the mapping. But once you're dealing with real volume, having the crosswalk held in one place, kept current, and visible across the whole organisation is the difference between a method you understand and a method you can actually run.
Truth is, the crosswalk is never really finished, but that's not a flaw. It's kind of the point. A new regulation doesn't break the framework; it's just another artifact to parse, type, and map. Sometimes new controls come in, sometimes they get adjusted, but as more and more artifacts get mapped, the changes get less and less. But I won't pretend that mapping is free. It's real analytical work, and although you can use a tool like Balcony (and the embedded AI mapping), there's still a great deal of nuance and professional judgment needed. The value isn't that change becomes effortless. It's that change becomes incremental and visible.
That's what I think a lot of practitioners doing this work are reaching for. Not a way to perfect or automate compliance, but a way to build on stable foundations so each new requirement extends something solid. The anchors are the common controls, the governance functions every framework converges on, and they're what the unified framework is built around.
So the spine I use, one more time: Artifact → Expectation → Control → Mechanism. I identify the source, parse and type the expectations, map them to your unified controls, then build the mechanisms that make those controls real. It's a method that I know holds regardless of which regulation you're facing, which standard you pursue, or which contract you sign.
This is the heart of what we teach in the Compliance Speciality of the AI Governance Practitioner Program, a course we launch in the coming weeks. It's a long way on from that paper-scraps-on-the-floor mega-map I published last year. Across the course, practitioners build a working crosswalk and mechanism portfolio across all twelve domains and the major regulatory sources. Every participant gets access to the Balcony tool to support their learning. If you want to learn to do this work properly, that's where I can help you learn to do it. You can find out more about what we cover and join the waiting list at https://governance.aicareer.pro/specialty-courses
In the next and final article of this short series, I'll try to bring the scoping and the crosswalk together to show how I run a rapid compliance gap analysis. Once you know what's applicable and you've mapped it to your framework, you'll be surprised how quickly you can find the gaps that matter. 
Hope you find this useful, and hope to see you join the 1200+ practitioners of all backgrounds and proficiencies, learning and building their skills within our program.
This approach to compliance scoping is part of what we teach in the AI Governance Practitioner Program, particularly in the Compliance speciality track. If you'd like to learn the scoping methodology, the decomposition, and the rapid gap analysis, you can find out more about the program here.