How to Map Policies to Controls With an Agent, and Check the Mapping It Proposes

To map policies to controls with an agent, break each policy into atomic obligations, let the agent propose a control for each one against your control catalog, then check every proposal before it counts. Check the logic (does the control actually do what the policy needs), check it a second way (a critic or a second framework), and have a named person approve, adjust or reject it. This guide gives the four-step workflow, the proposal table, the checks and the metrics. Madison, Lyzr’s agentic GRC product for US banks and credit unions, is built on this principle: agents propose, people approve.

TL;DR

• The problem: mapping policies to controls by hand is slow and inconsistent. An agent speeds it up, but a confident wrong mapping is worse than a gap you know about.
• Step 1, deconstruct: split each policy into atomic obligations with an ID, a domain and a risk tier.
• Step 2, propose: the agent matches each obligation to your control catalog and returns a structured proposal: control, mapping type (direct, partial or compensating), explanation and evidence.
• Step 3, check: test the logic, triangulate with a second method, then a named person approves, adjusts or rejects.
• Step 4, test plan: for each accepted mapping, generate how and how often the control will be tested.
• Our answer: Madison does the mapping and shows the gaps. Opencontroller governs the agents behind it with an owner, approvals and an audit trail.

What does it mean to map policies to controls?

Policy-to-control mapping is the practice of linking what your policies say you must do to the controls that make it happen, so every requirement has something behind it and every control has a reason to exist. A policy states the intent. A control is the activity that enforces it: a review, a limit, a reconciliation, a system setting. The mapping is the thread between them that an examiner or auditor pulls on.

Without that thread you cannot answer two basic questions: which requirement does this control serve, and which control proves this requirement is met. Both gaps matter. A policy with no control is a promise nobody keeps, and a control with no policy is effort with no stated purpose.

Why use an agent, and where does it go wrong?

The job is large and repetitive. A mid-size bank holds thousands of obligations, dozens of policies and hundreds of controls, and the links between them change whenever a rule or a process does. Reading a policy clause and finding the right control in a catalog is exactly the kind of semantic matching an agent does well and a person does slowly.

The risk is that the output looks finished. An agent can return a tidy table of mappings that is wrong in ways that are hard to see:

• A plausible control for the wrong reason. It matches on shared vocabulary, such as “access” or “review”, rather than on what the control actually does.
• A control that cannot do the job. A read-only report is mapped to a policy that needs a record of every change.
• An invented control. Output that is well-formed but refers to a control that is not in your catalog.

So the design question is not “can the agent propose a mapping” but “what stands between its proposal and your record”. The rest of this guide is that answer. For how this differs from governing the agent itself, see AI in compliance vs AI governance.

What is the four-step workflow for mapping policies to controls?

The workflow separates the work the agent does well from the judgment that stays with people.

Step 1: How do you break policies into obligations?

Agents map short, single-purpose statements far more reliably than long paragraphs. A policy clause that says “the bank will review access quarterly, remove leavers within a day and log all privileged activity” holds three requirements. Map it as one and you will get one control that covers part of it and a record that says all of it is covered.

So the first step is decomposition. The agent reads the policy, pulls out the clauses and splits each into atomic obligations: one requirement, one testable idea. It gives each an ID and tags it with a domain and a risk tier, so later steps know how much scrutiny to apply.

Illustrative example. IDs and clauses are invented to show the format.

Keep a link from every obligation back to the exact clause it came from. When a policy is revised, you then know which obligations to re-derive and which mappings to re-check.

Step 2: How does the agent propose a control?

Give the agent the thing it must choose from: your control catalog, with each control’s ID, name, description, type and what evidence it produces. The agent compares the meaning of each obligation with the meaning of each control, rather than matching keywords, and returns a structured proposal. Because it can only pick from the catalog, it cannot invent a control. If nothing fits, the right answer is “no match”, which becomes a visible gap.

Illustrative example of a proposal table. A proposal is a recommendation, not a record.

Three columns carry most of the value. The mapping type says how complete the link is. The explanation lets a reviewer judge the reasoning in seconds. The required evidence turns a mapping into something testable. A proposal without those is a guess in a table.

Direct, partial or compensating: what do the mapping types mean?

Not every link is equal, and the type is what stops a half-covered requirement being reported as covered.

Step 3: How do you check the mapping the agent proposes?

This is the step that decides whether the whole exercise can be trusted. Checking happens in three layers, each catching what the one before misses.

Layer 1: automated logic and traceability checks

Before anyone reads a proposal, test it against simple rules that do not need judgment. These are deterministic, so they can run on every proposal.

Layer 2: triangulate with a second method

A mapping the agent produced and then agreed with itself is weak evidence. Ask something independent to challenge it. Two approaches work well together:

• A critic agent. A separate agent, with different instructions, reads the proposal and tries to argue why the control does not satisfy the obligation. Disagreements go to the human queue.
• Cross-framework triangulation. Derive the same link another way, for example through a published crosswalk between frameworks, and compare. If the direct mapping and the derived one disagree, one of them is wrong. A recent Cloud Security Alliance analysis of LLM-generated control mappings calls this convergent validity.

The same analysis also recommends testing with near-identical pairs of controls that differ in one functional way, and checking that rewording a control does not change its label. Those are useful tests of the agent, not of any single mapping, so run them when you set the agent up and whenever its model or prompt changes.

Layer 3: a human review gate

Some things only a person with context can judge: whether a compensating control is acceptable, whether the risk tier is right, whether the evidence is realistic in your environment. This is covered in the review gate section below.

What are the failure modes to test for?

Accuracy on average can hide the cases that matter. Four failure modes deserve their own tests:

1. Topic over function.

The agent maps by subject (“access”, “vendor”) rather than by what the control does. Test with controls that share words but differ in function, such as monitoring and prevention.

2. Partial passed as direct.

A control covers one part of a compound requirement and is reported as full cover. Decomposition in step 1 and the scope check in step 3 are the defenses.

3. Well-formed but invented.

A tidy row that cites a control, a clause or a framework path that does not exist. The existence check catches it. Never skip it because the table looks clean.

4. Unstable answers.

The same obligation gets a different control on a second run, or when it is reworded without changing meaning. Run each test more than once and compare.

What does the human review gate look like?

The gate is where a proposal becomes a record. A named reviewer, usually the control owner or a compliance lead, sees the obligation, the source clause, the proposed control, the type, the explanation, the evidence and the results of the checks above. They then take one of three actions.

Bulk actions have a place for high-confidence, low-risk items once you have evidence the agent earns it, but the choice should be deliberate and sampled. Some GRC tools surface AI suggestions in a review queue where a user maps or ignores them, and one vendor’s help article describes exactly that pattern, with suggestions never mapped automatically. Whatever tool you use, confirm that a suggestion is not a mapping until a person accepts it.

Step 4: How do you generate a test plan for each mapping?

A mapping says a control should satisfy an obligation. A test shows that it does. Once a mapping is approved, the agent can draft the test: what to inspect, how big a sample, how often, and who should do it. A person approves the plan the same way as the mapping.

Illustrative example. Frequencies should follow your own risk tiers.

The test plan closes the loop. A failed test goes back to the obligation it was meant to prove, so a person can see which requirement is now exposed and which policy sits behind it.

Which metrics show the mapping is trustworthy?

Do not report one accuracy figure. A high overall score can sit alongside poor agreement on the hard cases. Track a few measures that each answer a different question, and compare the agent with your own reviewers on a sample you have already mapped by hand.

Set thresholds before you run the sample, and decide what happens when a measure fails. For how to build the test set and stage trust, see how to evaluate a regulatory change agent, which uses the same approach.

Where do Madison and Opencontroller fit?

Madison is Lyzr’s agentic GRC product for US banks and credit unions, and it is where this workflow lives. It holds obligations, policies, procedures and controls as one connected model, shows what covers what, and puts agents to work proposing the links for your team to approve. Opencontroller by Lyzr is the control plane that governs the agents doing that work: a registry with a named owner for each, approvals with separation of duties, and an audit trail.

Use them together, or use Opencontroller to govern a mapping agent from any vendor.

How Madison approaches policy-to-control mapping

What Opencontroller adds around the agent

It complements, rather than replaces, your GRC and model risk tools. Agents hosted elsewhere register as external entries. For the concept in depth, read our AI agent registry guide and AI agent inventory for banks.

See the mapping on your own policies

Bring your policy library and a sample of controls to a working session. We will show what Madison proposes, where it sees gaps and how Opencontroller keeps the agent accountable.

Book a demo

Explore Madison

Take the sprawl audit

Frequently asked questions

How do you map policies to controls with AI?

Break each policy into atomic obligations, give the agent your control catalog, and have it propose a control for each obligation with a mapping type, an explanation and the evidence required. Then check every proposal with automated logic tests and a second method, and have a named person approve, adjust or reject it before it is recorded.

What is policy-to-control mapping?

It is the practice of linking each requirement in a policy to the control that enforces it, so every requirement has something behind it and every control has a stated purpose. It is the thread an auditor or examiner follows to see how a policy is put into practice.

What is the difference between a policy and a control?

A policy states what the organization requires and why. A control is the specific activity, limit or system setting that makes the requirement happen and can be tested, such as a quarterly access review. One policy usually depends on several controls.

What is an atomic obligation?

An atomic obligation is a single, testable requirement taken from a policy clause. A sentence with three requirements becomes three obligations, each with its own ID, so a mapping cannot claim full cover when a control only addresses one of them.

What do direct, partial and compensating mappings mean?

A direct mapping means the control fully meets the obligation. A partial mapping means it covers only some of it, and the remainder is a gap. A compensating mapping means a different control reaches the same risk outcome by another route, which needs a documented rationale and an explicit approval.

How do you check an AI-generated control mapping?

Use three layers. First, automated checks that the control exists, its capability fits the obligation, and the scope, frequency and evidence fit. Second, an independent challenge, such as a critic agent or a derivation through a framework crosswalk. Third, a named reviewer who approves, adjusts or rejects.

Can AI map controls to frameworks like SOC 2 or NIST accurately?

It can propose useful mappings quickly, but accuracy varies and an overall score can hide weak spots. Cloud Security Alliance analysis of LLM-generated control mappings recommends measuring agreement beyond chance, structural validity, convergence with an independent mapping, resistance to near-identical controls and stability under rewording.

Why do AI control mappings go wrong?

Common causes are matching on topic words rather than on what a control does, treating a partial match as full coverage, producing well-formed output that cites something that does not exist, and giving different answers when the input is reworded. Each can be tested for.

Should a human approve every AI control mapping?

For anything that enters your record, yes: a named person should approve, adjust or reject each proposal, and the decision should be recorded with their role. Over time you may sample low-risk, high-confidence items instead, but that should be a deliberate choice backed by measured agreement.

How many mappings should you review to trust the agent?

There is no standard number. A practical approach is to map a sample by hand first, compare the agent against it, and set thresholds for reviewer agreement, logic failures and stability before you begin. Grow the sample with every error you find.

How does Madison map policies to controls?

Madison is Lyzr’s agentic GRC product for US banks and credit unions. It holds obligations, policies, procedures and controls as one connected model, shows coverage gaps, and has agents propose links that people approve. Every output traces to rule text, and Madison never remediates on its own.

Where does Opencontroller fit alongside Madison?

Opencontroller by Lyzr governs the agents behind the work. It registers each agent with an immutable ID and a named owner, enforces approvals with separation of duties and keeps an audit trail, in your own cloud account. It complements GRC and model risk tools, and can govern an agent from any vendor.

Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here