Cross-mapping NIS2, AI Act, GDPR, ISO 27001 without duplicating compliance work

Reading time: about 13 minutes. Cluster: compliance. Author: Fryderyk.

The answer first

Four regimes, one set of evidence, and from autumn 2026 a fifth regime for anyone who manufactures products with software. NIS2 (in Poland transposed through the amended national cybersecurity act in force since 3 April 2026), the AI Act, GDPR and ISO 27001 impose requirements on a manufacturer deploying AI that, at the technical layer, largely overlap. One solid risk assessment answers NIS2 Art. 21, AI Act Art. 9, GDPR Art. 35 and ISO clause 6.1 at the same time. One supplier contract with the right clauses closes the NIS2 supply chain, the AI Act duties and the GDPR processor relationship.

The practical takeaway is the same as in the shorter note this material grew out of: do not run four separate compliance projects. Build one set of controls and evidence, assign each control a single artefact, then map each artefact onto the regimes in one compliance matrix. You work with controls, not statutes. This piece extends that principle to pillar depth: a fuller table with ISO Annex A controls, an evidence-per-control pattern, a layer of sectoral regimes (CRA and DORA), and the places where the regimes genuinely diverge, because those cannot be merged.

Table of contents

1. Why the regimes ask for the same thing
2. The principle: control, evidence, mapping
3. The cross-mapping table: nine areas and ISO controls
4. Evidence per control: one artefact, four regimes
5. Three overlaps with the highest return
6. Sectoral regimes: CRA and DORA as the fifth and sixth column
7. Where the regimes diverge: four clocks and exclusive domains
8. The compliance matrix: how to build and maintain it
9. Deadlines: what applies and what shifts in 2026 and 2027
10. FAQ
11. Disclosure and biases
12. What this piece does not cover
13. Related notes

Why the regimes ask for the same thing

A manufacturer deploying AI in Poland lands in at least four regimes at once. NIS2, transposed through the amended national cybersecurity act, covers it as an essential or important entity. The AI Act classifies some AI uses as high-risk. GDPR applies wherever personal data is involved. ISO 27001 is usually not required by law, but it is often expected contractually and it is the most convenient framework to hang everything else on.

The natural reaction is to treat each regime as a separate project with its own team, its own schedule and its own set of documents. That is the most expensive option possible, because at the technical layer the four regimes mostly ask the same thing: have you done a risk assessment, do you control your suppliers, do you detect and report incidents, do you control access, do you log, do you encrypt, do you have business continuity, and does someone at the right level own it.

They differ in vocabulary, article numbering and emphasis, but not in the fundamentals. A risk assessment done once, properly and documented, is the same evidence for a NIS2 auditor, for AI Act conformity and for ISO. That is why it pays to think in controls, not statutes: define a set of controls, implement them once, and map them onto whichever regimes happen to be looking at you.

The principle: control, evidence, mapping

Before the table, it is worth naming three concepts, because the whole piece rests on them and confusing them is the source of most duplicated work.

A control is an organisational or technical safeguard, for example risk management, access control, logging. A control is regime-independent, because good security hygiene looks the same regardless of which statute asks about it.

Evidence is the concrete artefact you show an auditor to prove the control works: a risk assessment document, a signed contract, a data flow map, an exported log, a completed register. An auditor is not interested in a declaration, only in an artefact.

Mapping is the assignment of evidence to articles in each regime. It is the only layer that is statute-specific, and the only one you rework when a statute changes. You implement a control once, produce evidence once, and update the mapping as needed. That separation is the difference between compliance that scales to a fifth and sixth regime and compliance you have to rebuild with every new act.

The cross-mapping table: nine areas and ISO controls

Below are nine control areas that recur across all four regimes, with references to specific articles and controls. The AI Act numbering refers to high-risk system obligations, and the ISO column points to Annex A controls in the 2022 edition.

Control area	NIS2 / national law (Art. 21)	AI Act (high-risk system)	GDPR	ISO 27001:2022
Risk management	Art. 21(2)(a)	Art. 9 (risk management system)	Art. 35 (DPIA)	Clause 6.1, A.5.1
Supply chain and supplier security	Art. 21(2)(d)	Art. 25, 26 (provider and deployer)	Art. 28 (processor agreement)	A.5.19 to A.5.23
Incident handling and reporting	Art. 21(2)(b), Art. 23	Art. 73 (serious incidents)	Art. 33, 34 (breaches)	A.5.24 to A.5.28
Access control and authentication	Art. 21(2)(i),(j) (MFA)	Art. 15 (cybersecurity)	Art. 32	A.5.15 to A.5.18, A.8.5
Logging and monitoring	Art. 21 (event detection)	Art. 12 (record-keeping)	Art. 32	A.8.15, A.8.16
Cryptography and data protection	Art. 21(2)(h)	Art. 15	Art. 32(1)(a)	A.8.24
Business continuity and backups	Art. 21(2)(c)	Art. 15 (robustness)	Art. 32(1)(b),(c)	A.5.29, A.5.30, A.8.13
Documentation and records	ISMS documentation	Art. 11, Annex IV	Art. 30 (records of processing)	Clause 7.5
Human oversight and accountability	Art. 20 (management accountability)	Art. 14 (human oversight)	Art. 22 (automated decisions)	A.5.2 to A.5.4

Column by column, the same pattern shows up: different statutes, one control question. That is the whole idea of cross-mapping. Instead of nine times four, that is thirty-six tasks, you have nine controls, each documented once and shown from four sides. The ISO Annex A controls work here as the common denominator, because they are the most granular and it is easier to hang the other regimes' requirements onto them than the other way around.

Evidence per control: one artefact, four regimes

The table shows where the regimes meet. The pillar has to go one step further and say what exactly you put on the auditor's desk for each control. Below is the pattern: one control, one primary artefact that satisfies all four regimes at once.

For risk management, the evidence is a single AI deployment risk assessment covering threats to system security, to individuals' rights and to process continuity. If it genuinely covers those three layers, it is at once the NIS2 measure, the AI Act risk management system, the GDPR impact assessment and the entry point to the ISO risk treatment plan.

For the supply chain, the evidence is a contract set with the supplier, that is an MSA plus a DPA, with clauses on scope of processing, subprocessors, safeguards, the right to audit and exit terms. That one set closes the NIS2 supply chain assessment, the AI Act split of roles, the GDPR processor relationship and the ISO supplier controls.

For incidents, the evidence is a response procedure plus a logging configuration that gives you the ability to detect and describe an event. One procedure serves the NIS2 report to the CSIRT, the AI Act serious incident notification, the GDPR breach notification and the ISO incident controls, although, as shown below, the deadlines inside it have to be separated.

For access control the evidence is an access policy plus proof of MFA and access reviews. For logging it is a logging policy plus a sample export with retention. For cryptography it is an encryption policy plus a register of what is encrypted where. For continuity it is a continuity plan plus recovery test evidence. For documentation it is a set of registers, including the record of processing activities and the AI system technical documentation. For human oversight it is a description of the decision review mechanism plus an accountability assignment at management level.

Nine controls, nine primary artefacts. That is a real list of things to produce, not four parallel binders. More about the set of documents you produce before an auditor is in the note on audit readiness for NIS2 plus AI.

Three overlaps with the highest return

Not all rows of the table weigh the same. Three areas give the highest return on a single effort, because they are both the most frequently audited and the most labour-intensive when done separately.

Risk management. The cleanest example of one effort across four regimes. NIS2 requires risk management measures, the AI Act requires a risk management system across the entire lifecycle of a high-risk system, GDPR requires an impact assessment for operations that are high-risk to individuals, and ISO puts risk assessment at the centre of the information security management system. The one condition: the assessment must genuinely cover the three layers, not be a copy of a template from one regime.

Supply chain and the supplier contract. The second high-return area. NIS2 explicitly covers supply chain security, the AI Act splits duties between the system provider and the deployer, GDPR requires a processor agreement with every processor, and ISO has a separate block of supplier controls. One well-built contract closes all four. I wrote about the clauses themselves in the note on the DPA for an AI vendor.

Logging and incidents. The third area. The ability to detect, describe and report an incident comes from logs. The same logging mechanism and the same response procedure serve the NIS2 reporting duty to the CSIRT, the AI Act serious incident notification, the GDPR breach notification and the ISO incident controls. Thresholds and deadlines differ, but the infrastructure is one. More on what exactly to log in an AI system running locally is in the note on observability for on-prem LLMs.

Sectoral regimes: CRA and DORA as the fifth and sixth column

The four regimes in the table are the common denominator for most manufacturers. Some of them additionally fall into sectoral regimes that impose their own controls and, more importantly, their own reporting clocks. Two are worth knowing, because they touch manufacturers directly.

CRA, the Cyber Resilience Act. This is the fifth regime for anyone who manufactures products with digital elements themselves, not only deploys someone else's AI. A maker of a machine with a controller, a device with software or a component with a connectivity module becomes, in CRA terms, a manufacturer of a product with digital elements. The key difference from NIS2: NIS2 looks at you as an entity that uses systems, while CRA looks at you as a manufacturer that places a product on the market. Those are two different roles and two different sets of duties that can fall on the same company.

From 11 September 2026, the CRA reporting obligation begins. A manufacturer reports an actively exploited vulnerability and a severe incident to ENISA and the relevant CSIRT through a single reporting platform, in a multi-stage mode: an early warning within 24 hours, a fuller notification within 72 hours, and a final report for vulnerabilities within 14 days of a fix becoming available. Full CRA product obligations start on 11 December 2027. The CRA control areas, vulnerability management, security across the lifecycle, technical documentation, largely overlap with what you already have in the table, so CRA mostly adds a new clock and a new recipient, not a new foundation.

DORA, the regime for the financial sector. In force since 17 January 2025, it covers financial entities and the ICT providers that serve them. For a typical manufacturer DORA is not a regime of its own, but it can become one indirectly when you sell a component or service to a bank or insurer and your contract has to meet DORA requirements for critical providers. Do not force DORA into the main matrix if you are not in the financial supply chain, because you will only add a column nobody audits.

The conclusion is that sectoral regimes do not break the control, evidence, mapping principle. You add a column to the matrix, check which existing evidence covers it, and close what is specific, for example product vulnerability management under CRA. On the fact that the product layer and the operator layer are two different roles under the same law, I also write in the context of Article 50 of the AI Act and your own LLM.

Where the regimes diverge: four clocks and exclusive domains

Cross-mapping is powerful, but it has a limit. A few requirements do not map to anything in the other regimes, and trying to merge them only creates risk. These have to be handled separately.

Reporting deadlines are different and cannot be averaged. A single event can start several independent clocks to different institutions. NIS2 introduces a multi-stage mode, with an early warning within 24 hours and a fuller notification within 72 hours to the relevant CSIRT. GDPR has its own 72 hours to notify a breach to the supervisory authority, counted from a different moment and to a different recipient. The AI Act has its own serious incident reporting regime. CRA, if it covers you as a product manufacturer, adds a fourth mode: 24 hours, 72 hours, 14 days, to ENISA and the CSIRT. The same leak can therefore mean four notifications to four recipients on different deadlines. The incident procedure has to recognise and branch this, not assume one deadline.

AI-specific requirements have no equivalent in NIS2, GDPR, ISO or CRA. Human oversight in the AI Act sense, the quality and representativeness of training data, model accuracy and robustness, and information duties toward the user are requirements you cannot take off the cybersecurity shelf. Cross-mapping does not help here, because there is nothing to map. These areas require separate work for systems classified as high-risk. On the classification itself there is a separate note: the AI Act in manufacturing and high-risk classification.

Legal basis and data subject rights are the exclusive domain of GDPR. Compliance with NIS2, ISO or CRA says nothing about whether you have a basis to process personal data or how you fulfil individuals' rights. That is a layer with a life of its own and it cannot be derived from security controls.

The compliance matrix: how to build and maintain it

The order that works is the opposite of the intuitive one. You do not start by reading four legal acts in parallel, but by defining a set of controls and building one matrix.

The matrix is a sheet where rows are controls and columns are, in order: evidence name, owner, status, review date, then one column per regime with an article reference. First set the list of controls, roughly the nine from the table plus the AI-specific requirements if the system is high-risk, plus CRA rows if you manufacture products with software. For each control enter one piece of evidence and its owner. Only then fill the regime columns. This matrix is at once your map and your proof of audit readiness, because to an auditor of any regime you show their column and the artefacts behind it.

The advantage of this approach is resilience to change. When a new regime appears or the numbering in some act changes, you do not rework the whole of compliance. You add a column and check which existing evidence covers it and which gaps need closing. That is far cheaper than maintaining parallel document flows nobody synchronises. I develop this way of thinking in the NIS2 plus AI mapping cheat sheet.

ISO 27001 is worth treating here as the organising framework. Its information security management system is general enough that the other regimes hang onto it as detailed requirements. If you already have or are building an ISMS, bolting NIS2, the AI layer and CRA onto it is cheaper than starting from scratch. Which three ISO controls to map first is described in the note on ISO 27001 and an AI vendor.

The ready matrix to download

Instead of building the sheet from scratch, you can start from a ready template. The compliance matrix in spreadsheet form contains 14 controls mapped onto NIS2, AI Act, GDPR, ISO 27001 and CRA, a separate tab with the four reporting clocks, and a calendar of key deadlines for 2026 to 2028. You fill in the owner, status and review date columns, and the progress counter computes automatically. It is the same skeleton described above, ready to use. Download the compliance matrix in XLSX.

Deadlines: what applies and what shifts in 2026 and 2027

Cross-mapping only works if you operate on current dates, and in 2026 they are moving.

NIS2 in Poland came into force through the amendment of the national cybersecurity act, which started applying on 3 April 2026. Entities meeting the criteria have until 3 October 2026 to submit an application for entry in the relevant register, and until 3 April 2027 to fully implement the information security management obligations. The scale is different from before: the regime will cover the order of tens of thousands of Polish companies, not a few hundred as before the amendment.

The AI Act was significantly delayed this year. The simplification package known as the Digital Omnibus moved the start of obligations for high-risk systems in Annex III from August 2026 to 2 December 2027, and for AI embedded in regulated products in Annex I to 2 August 2028. Watch out for a common error: this does not mean everything was postponed. The transparency obligations under Art. 50, for example labelling AI-generated content, apply on the original calendar from 2 August 2026, with a shorter transition for watermarking alone for systems already on the market. The postponement concerns the high-risk layer, not the whole act.

CRA adds a new deadline that was not in this puzzle before. From 11 September 2026 the reporting of actively exploited vulnerabilities and severe incidents to ENISA and the CSIRT applies, and full product obligations start on 11 December 2027. If you manufacture products with software, that clock applies to you regardless of NIS2.

GDPR is stable and applies unchanged. DORA has applied since 17 January 2025 for the financial sector and its ICT providers. ISO 27001 in the current 2022 edition has a new Annex A structure with four control themes, and the transition period from the 2013 version has already ended, so certificates and mappings should refer to the 2022 edition.

Because the AI Act dates changed several times this year, verify the current state of publication of the amending act in the EU Official Journal before making decisions.

FAQ

Do I have to run separate compliance projects for each regime?

No. At the technical layer NIS2, the AI Act, GDPR, ISO 27001 and often CRA ask for mostly the same controls. It is more efficient to build one set of controls and evidence and then map it onto all regimes in one compliance matrix.

Where do I start if I already have ISO 27001?

By treating the ISMS as the framework. You bolt the other regimes onto existing controls as detailed requirements. That is cheaper than building parallel structures.

How does CRA differ from NIS2 if both concern cybersecurity?

In the role they see you in. NIS2 looks at you as an entity that uses systems and provides services. CRA looks at you as a manufacturer that places a product with digital elements on the market. The same company can be subject to both, in two different roles, with two sets of duties.

How many reporting clocks can one incident start?

Up to four: NIS2 (24 h and 72 h to the CSIRT), GDPR (72 h to the supervisory authority), the AI Act (serious incidents) and CRA (24 h, 72 h, 14 days to ENISA and the CSIRT). Deadlines and recipients differ, so the incident procedure has to branch them.

Does the AI Act postponement mean I have time until 2027?

Only for high-risk system obligations. The transparency obligations under Art. 50 apply from 2 August 2026 regardless of the postponement.

What will cross-mapping not solve?

Incident reporting deadlines, because they differ. AI-specific requirements such as human oversight, data quality or model accuracy. And the legal basis and data subject rights, which are the exclusive domain of GDPR.

// disclosure & biasesDisclosure and biases

I write from the perspective of someone working on AI deployments running outside the public cloud, so I naturally emphasise control over data flow and the ability to audit dependencies. I have tried to separate the content of the statutes from the architectural preference. This text is not a legal opinion. The mapping between regimes is an editorial simplification: a single article is often implemented by many controls and vice versa, and interpretation depends on the sector and the facts. Audit practice for NIS2, the AI Act and CRA is only taking shape. Before compliance decisions, consult a lawyer specialising in cybersecurity and data protection.

What this piece does not cover

I do not give a full mapping of every ISO Annex A control or every paragraph of the acts, because that is material for a working matrix, not a single text. I do not go deeper into sectoral regimes beyond flagging CRA and DORA, because each deserves its own material. I skip the national implementing acts to the cybersecurity law, which will refine the details. I also do not cover the operational side of reporting an incident to the CSIRT or the technical layer of model security, which I run in separate notes.

Related notes

• The AI Act in manufacturing: high-risk classification and what it means for deployment
• ISO 27001 and an AI vendor: three controls worth mapping today
• Audit readiness for NIS2 plus AI: 7 documents you produce before an auditor
• NIS2 plus AI: mapping Art. 21 onto concrete controls, one cheat sheet
• The DPA for an AI vendor: 8 clauses whose absence sinks an audit