Every harmonization pitch ends at the same beautiful artifact: one deduplicated control library, mapped cleanly to SOX, ISO, NIST, and DORA, so you test once and satisfy many. The spreadsheet gets smaller. The mapping burden drops. And yet the thing the crosswalk describes — the control itself — is still being enforced, or quietly not enforced, in some entirely different system. You did not close the gap between the documented control and the executed reality. You documented it more efficiently.
Control harmonization has earned its concession
Start with the honest concession, because the control-harmonization vendors have earned it. Most enterprises carry a sprawl of near-duplicate controls — the same segregation-of-duties principle written four different ways for four different frameworks, each with its own owner, evidence request, and test cycle. Collapsing that sprawl into a single normalized library, then mapping one authoritative control to the many framework requirements it satisfies, is genuinely valuable work. The harmonization vendors reasonably point out that one well-mapped control can answer a large share of overlapping obligations at once, and that deduplicating the library cuts mapping and testing effort by a meaningful margin. That is real. Anyone who has staffed a controls team through three concurrent audits knows exactly how much manual reconciliation a good crosswalk removes.
So this is not an argument that harmonization is snake oil. It is an argument about what harmonization operates on — and about the one thing it structurally cannot touch.
Two objects wearing one label
Inside any control there are two distinct objects that a crosswalk quietly treats as one.
- The documented control — the description, the framework mappings, the test procedure, the evidence definition. This is what lives in the governance system of record, and this is what harmonization deduplicates and maps.
- The enforcing mechanism — the ERP approval configuration, the entitlement in the identity system, the threshold in the payment run, or the human step someone is supposed to perform. This is what actually decides whether a non-compliant action happens.
Harmonization is a discipline applied entirely to the first object. It normalizes and maps descriptions. The second object — the enforcement — lives somewhere else entirely, and the crosswalk asserts a relationship to it that it has no power to guarantee. The map says "this control is enforced." The map cannot make it so.
Why the drift is structural
Because the documented control and the enforcing mechanism are two separate objects, they are only ever reconciled at reconciliation time — through sampling, evidence collection, control testing, or monitoring. Everything that happens to the real system between those checkpoints is, by construction, invisible to the crosswalk. A config gets changed. An exception gets granted. An integration starts writing around the approval step. The documented control still reads as green; the executed reality has quietly moved.
Continuous monitoring narrows that window, and it deserves credit for it — pulling logs and config on a tight cadence genuinely shrinks the time drift can hide. But narrowing is not closing. Monitoring still detects after the action has already run; the transaction that breached policy already committed before the evidence arrived to flag it. And "test once, satisfy many" tests the accuracy of the mapping, not the behavior of the process. You are validating that the description is faithful, then attesting the description. The savings are scoped to the paperwork of proving. Enforcement, and therefore drift, are left exactly where they were.
This is the uncomfortable part for a controls architect: a better crosswalk makes the documentation more internally consistent while doing nothing about the gap between documentation and execution. It shrinks the spreadsheet. It cannot close the gap, because the control was never in the spreadsheet to begin with.
The control belongs in the process, not beside it
Entroid starts from a different premise: the control should not be a description that lives beside the process. The control should be the process. In the fabric, every enterprise process is modeled and executed as a composition of five primitives on a shared Semantic Ontology, and one of those primitives — the Deterministic Workflow — is where governance is enforced inline. Approval gates, segregation of duties, entitlement and authority limits, thresholds, human-in-the-loop checkpoints: these are not tests run against the process afterward. They are the routing rules the process is made of.
Consider a purchase order that would breach an approval threshold, or a change request that would put initiation and authorization in the same pair of hands. In a crosswalk world, a documented control describes what should happen and an auditor later samples to confirm it did. In the fabric, the workflow simply cannot route that action forward — the non-compliant path does not exist to be taken. Enforcement is a property of execution, not a verdict rendered after it. And because the fabric records each governed action immutably as it runs, the evidence becomes a byproduct of execution: continuous, population-complete, bound to the specific action rather than sampled or reconstructed later.
Be precise about the claim, because overclaiming here is how you lose an audit reader. ES is not the only architecture that can ever block anything before it happens — some tools bolt a narrow, discovery-dependent pre-execution check onto specific agent actions riding on a third-party runtime, and that is a legitimate capability. The distinction is structural: in ES, inline deterministic enforcement is a native property of the fabric across every process, expressed once against the ontology, with a provable per-action record — not an agent-specific sensor added at the edge of a system it does not run.
Right about the destination, wrong about the road
Here is where the harmonization instinct is right about the destination and wrong about the road. You do want one control that answers many frameworks. The question is what you are projecting from.
Framework mapping and reporting still exist in ES — regulators still want their SOX view, their ISO view, their DORA view, and the platform still produces them. That does not go away, and pretending it does would be dishonest. What changes is the source object. The Compliance module projects from a control that was enforced once inside the executing workflow, expressed against the ontology — not from a maintained crosswalk of documented controls that must be periodically reconciled back to a reality living in some other system. One enforcement; many framework projections. You are not testing a mapping for accuracy, because there is no separate mapped description whose fidelity could decay. The enforcement and the evidence are the same event.
So the two approaches remove different things. Harmonization removes the duplicate library — a real and worthwhile saving. The fabric removes the duplicate library and the drift, because it collapses the two objects — the documented control and the enforcing mechanism — into one. When there is only one object, there is nothing left to crosswalk and nothing left to reconcile.
A crosswalk documents the control you meant to have. Make the enforcement the map, and there is no mapping left to test — and no gap left to drift.
See what this looks like for your enterprise.
Not a demo. A strategic conversation about how your enterprise could operate
when every process runs on one governed fabric.
