Mapping is already built into eramba, because eramba uses problem and solution approach. Your requirements are the problems. Your controls, policies, exceptions and projects are the solutions. Mapping (in eramba context) just means reusing a solution wherever it fits. Something like endpoint encryption can cover a requirement in ISO, another in NIS2, a risk and a data flow all at once.
In practice, one solution usually ends up linked to somewhere between 5 and 15 problems.
The feature you mentioned mapped requirements one-to-one (exact same solutions), and we don’t think that’s realistic. No two requirements ask for exactly the same thing, and that one-to-one mapping can leaves gaps.