CIS NIS2 mapping answers a very concrete problem. A mid-sized European company running Microsoft 365 or Google Workspace now faces four texts stacked on top of each other. NIS2 if it falls in a covered sector, DORA if it touches financial services, ISO 27001 because a client demands it, and GDPR in all circumstances. On top of that sits the technical baseline everybody leans on without naming it, the benchmarks published by the Center for Internet Security.
The instinct is to treat each text separately. A NIS2 project, an ISO project, a GDPR review. Three providers, three timelines, and three rounds of interviews asking the same questions of the same people. In the end, you therefore hold three documents describing the same environment in three different vocabularies.
What these texts actually ask for
None of these texts describes a configuration. That is indeed what makes them hard to apply, and it is also what makes mapping possible.
NIS2 lists, in Article 21, risk management measures. They apply to essential and important entities, and they read as objectives: risk analysis policy, incident handling, business continuity, supply chain security, access control, cyber hygiene.
DORA then reasons in terms of digital operational resilience. The regulation insists notably on third-party control and on the ability to demonstrate that arrangements actually work.
ISO 27001, meanwhile, reasons in terms of a management system, with an annex of controls and a standing requirement to evidence effectiveness.
GDPR, finally, reasons in terms of data protection. It mandates appropriate technical measures without ever saying which ones.
Consequently, not one of the four will tell you which setting to enable in your tenant. CIS does nothing else.
Where the texts converge
One exception lights up the whole mechanism. NIS2 explicitly names, in Article 21(2)(j), the use of multi-factor authentication or continuous authentication solutions. It is indeed one of the very few technical measures the directive calls out by name.
Multi-factor authentication also appears in the ISO 27001 annex controls, in DORA’s expectations around access control, in supervisory guidance on appropriate technical measures under GDPR, and in several recommendations of the CIS benchmark that applies to your platform.
So a single observed setting, the real state of strong authentication on privileged accounts, simultaneously feeds four requirements from four texts. This is not a presentation trick. In reality, it is the structure of these frameworks: they describe the same risks in distinct professional vocabularies.
The same reasoning then repeats on logging, on privileged account management, on external document sharing, on encryption and on email protection. Every time, one technical finding answers several obligations.
What CIS NIS2 mapping does not do
It exempts you from no text, and that needs saying plainly.
Governance does not map. NIS2 thus requires management bodies to approve the measures and to be trained. ISO 27001 requires a living management system, with management review and continual improvement. DORA moreover requires contractual management of critical providers. GDPR finally requires a record of processing and a lawful basis. No technical configuration answers any of these.
Nor does mapping replace a risk assessment. Indeed, two organisations sharing an identical configuration do not carry identical risk, since they do not hold the same assets or face the same exposure.
What it does, and it is already considerable, is handle in one pass the technical layer common to all four texts. It therefore removes redundant work, eliminates repeated interviews, and produces a single evidence base that each framework reads through its own grid.
The condition that makes a mapping admissible
A mapping is worth exactly as much as the findings feeding it. A table linking requirements to declared measures stays a documentary exercise. By contrast, a table linking requirements to settings actually measured, on a given date, counts as a probative item.
Three properties then make the difference in front of an auditor.
The date. A finding with no timestamp proves nothing over time, and time is precisely what the regulator cares about.
Repeatability. If the same measurement run six months later does not return a comparable result, the observed gap consequently means nothing.
Provenance. A finding produced by reading the configuration directly can be verified. Conversely, a finding produced by declaration is believed or it is not.
That is where a mapping stops being a table and becomes an evidence file.
What this changes in how you run a programme
The usual order starts from the text, breaks it into requirements, then goes looking in the environment for whatever answers them. It is slow, and it generates a great deal of discussion for very few findings.
The reverse order moves faster. You measure the real configuration state against a complete technical baseline first, then redistribute each finding to the requirements it feeds. Thus one survey serves four texts, discussion focuses on actual gaps, and the remediation plan gets prioritised on facts.
Tenovia produces that survey for Microsoft 365 and Google Workspace, read-only, with the regulatory mapping carried on every finding.