Control mappingThe hardest part

Ask anyone who has run a GRC programme
what actually killed it.
It was the mapping.

Not the policy library, not the dashboard, not the workflow. It was the spreadsheet where somebody once wrote down which control covers which system, for which obligation. It was accurate for about a quarter. Then a subsidiary was acquired, a platform was retired, a team was renamed, and nobody could say any more why a given control existed or what it was protecting. Every governance tool sells you the screens around that spreadsheet. None of them fix the spreadsheet.

Nobody maps
You are never asked which control covers which asset. That question has no stable answer at enterprise scale, which is why the spreadsheet always rots.
You answer
You are asked how you operate. One question per control domain: is this run once for the group, or separately, and if separately, split by what.
It derives
The engine does the rest. Which control instances exist, which systems each covers, at what cadence, and the reason it exists at all.
Why the old way cannot work

An asset-to-control matrix is a snapshot of a thing that will not hold still.

Take a mid-sized group: a few thousand systems, a few dozen legal entities, and a control framework of a few hundred controls. Mapped by hand, that is hundreds of thousands of decisions, made once, by people who then move on. The moment anything changes the matrix is wrong, and worse, it is wrong silently. Nothing errors. The report still renders. You simply cannot trust it any more, and there is no way to tell from the outside.

The problem is not that people are careless. It is that the question is the wrong shape. Nobody actually knows their control-to-asset map, because it is not a fact anybody holds. It is a consequence of how the organisation runs, and that is a much smaller thing to describe.

It starts wrong
The first version is built during implementation, under time pressure, by a consultant who learned your estate three weeks ago.
It drifts silently
No system announces that a mapping has gone stale. Reports keep rendering from data nobody has been able to trust for a year.
It loses its reasons
A row says a control covers a system. It never says why, so nobody can safely remove anything, and the matrix only ever grows.
It cannot be re-derived
Because it was typed rather than computed, there is nothing to run again after a reorganisation. You rebuild it by hand, or you live with it.
Nobody knows their control-to-asset map.
They know how they operate.
The Control Mapping wizard

Four steps, and the hardest artefact in governance derives itself.

The wizard opens on your real estate: the systems it can see, across the legal entities it can see, and the framework controls that apply to them. It then asks one question per control domain, not per control and never per asset.

The question is simply whether that domain is run once for the whole group, or separately, and if separately, split by what: by entity, by platform, by team, by system. Answer that, and the number of control instances is arithmetic. One answer can shape fifty controls at once, and coverage still stays resolved per system underneath.

Where a domain is obviously common to everyone, it is not asked at all. It is taken from the framework's own default and reported to you as taken, not hidden.

How one control serves many frameworks The graph underneath
The four steps
Entitiesthe systems and legal entities in scope
Operating modelone question per control domain
Roleswho operates, owns and attests
Reviewevery derived control, with its reason, before anything is written
Commonrun once for the group
System-specificsplit by entity, platform, team or system
Hybridshared with named exceptions
What comes out the other side

Every derived control arrives already knowing why it exists.

This is the part that survives the two-year test. A control is not just a row that covers some systems. It carries the walk that produced it, so the question a new risk officer asks on their first day has an answer that did not depend on anyone still being here.

Its reason

Walked live from the graph: the regulation, the clause, the framework control, the entity. Not a note somebody typed and never revisited.

Its coverage

Full or partial, resolved per system rather than asserted for the group. Partial is shown as partial instead of rounding up.

Its cadence

Where several obligations demand different frequencies for the same control, the strictest one wins. That is the answer an examiner expects.

Its evidence

What has to be produced to show the control ran, listed per system, so evidence collection is defined at derivation rather than discovered at audit.

Its operator

Who runs it, who owns it, who attests to it, drawn from real roles in your directory rather than a free-text name field.

Its exceptions

Where a system is deliberately outside a shared control, the exception is an edge on the graph, visible and reviewable, not an omission.

Its edges

Each control implements a framework control and covers named entities. Those are relationships in the graph, so they can be walked in either direction.

Its honesty

Review shows every control before a single row is written, and the count reported afterwards comes from what the engine actually wrote, never from what it intended to.

And when the AI is off

The wizard degrades. The derivation does not.

With AI available, the engine reads your asset and tool graph and suggests an operating model for each domain, with its reasoning attached, so most of the work is confirming rather than deciding. There is also a discovery view that shows who actually touches these systems, drawn from the relationships already in the graph, for the domains where you are not sure.

Switch the AI off and the wizard becomes manual: you answer each domain yourself. What does not change is the deterministic part underneath, the walk from regulation to clause to framework control to entity. AI sharpens the operating model. It never produces the base.

That distinction is the whole architecture in one place. With the model off, this platform still derives your controls and you fill in the operating model. A platform built model-first has nothing to fall back to.

Pull the kill-switch yourself
AI on, and AI off
Deterministicregulation to clause to control to entity
Runsin both modes, unchanged
AI addsa suggested operating model, with its rationale
AI addsdiscovery: who already touches these systems
AI offyou answer the domains yourself, nothing else changes
The chain this sits in

Mapping is one link. It only works because the links either side are real.

The clause-to-control library is being populated framework by framework, and on a call we will tell you exactly which are mapped today rather than implying all of them are. How the library works →

A mapping you typed goes stale.
A mapping you derive can be run again.
Design partner programme

Bring us the question your regulator is going to ask.

A small cohort of regulated banks, NBFCs and the firms that own them. Early access, real influence, pricing that holds.

We are pre-launch and we will not dress it up. There are no logos on this page because there are none to show. Come and try to break the chain.