Cross-mapping NIS2, AI Act, GDPR and ISO 27001 without duplication

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

Answer first

Four regimes, one set of evidence, and from autumn 2026 a fifth regime for those who make products with software themselves. NIS2 (in Poland the amendment to the National Cybersecurity System Act, in force since 3 April 2026), the AI Act, the GDPR and ISO 27001 impose on a manufacturer deploying AI a set of requirements that, at the technical layer, largely overlap. One solid risk assessment answers NIS2 Article 21, AI Act Article 9, GDPR Article 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 obligations, and the GDPR processing arrangement.

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 one artefact to each control, then map each artefact onto the regimes in a single compliance matrix. You work in controls, not statutes. This text extends that principle into a guide: a fuller table with ISO Annex A controls, an evidence-per-control pattern, a sectoral layer (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 overlays with the highest return
6. Sectoral regimes: CRA and DORA as the fifth and sixth columns
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 note 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 by the amendment to the National Cybersecurity System Act, covers it as an essential or important entity. The AI Act classifies some AI uses as high-risk. The GDPR applies wherever personal data is involved. ISO 27001 is usually not a legal requirement, but is often expected contractually and is the most convenient skeleton on which to arrange the rest.

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 possible variant, because at the technical layer the four regimes ask, for the most part, about the same things: did you carry out 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 foundation. 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 material 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 independent of the regime, because good security hygiene looks the same regardless of which legal act 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. The auditor is not interested in a declaration, only in the artefact.

Mapping is the assignment of evidence to articles in each regime. It is the only layer that is regime-specific, and the only one you rework when a rule 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 from scratch 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 of the 2022 edition.

Control area	NIS2 / NCSA (Art. 21)	AI Act (high-risk system)	GDPR	ISO 27001:2022
Risk analysis and management	Art. 21(2)(a)	Art. 9 (risk management system)	Art. 35 (DPIA)	Clause 6.1, A.5.1
Supply chain security and suppliers	Art. 21(2)(d)	Art. 25, 26 (provider and deployer)	Art. 28 (processing 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 (resilience)	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 (record of processing)	Clause 7.5
Human oversight and accountability	Art. 20 (management responsibility)	Art. 14 (human oversight)	Art. 22 (automated decisions)	A.5.2 to A.5.4

Column by column the same pattern shows: different rules, 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 act as a common denominator here, because they are the most granular and it is easier to attach the requirements of the other regimes to them than the other way round.

Evidence per control: one artefact, four regimes

The table shows where the regimes meet. You have to go a step further and say what exactly you put on the auditor's table for each control. Below is the pattern: one control, one primary piece of evidence that satisfies all four regimes at once.

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

For the supply chain the evidence is the contractual set with the supplier, that is an MSA plus a DPA, with clauses on the scope of processing, sub-processors, safeguards, the right to audit and exit terms. That one set closes the NIS2 supply chain assessment, the AI Act allocation of roles, the GDPR processing arrangement, and the ISO supplier controls block.

For incidents the evidence is a response procedure plus a logging configuration from which the ability to detect and describe an event follows. One procedure serves the NIS2 report to the CSIRT, the AI Act serious incident report, the GDPR breach notification and the ISO incident controls, although, as I show below, the deadlines within it must be separated.

For access control the evidence is an access policy plus proof of MFA rollout 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 and where. For continuity it is a continuity plan plus proof of a recovery test. For documentation it is a set of registers, including the record of processing activities and the technical documentation of the AI system. For human oversight it is a description of the decision review mechanism plus an assignment of responsibility at management level.

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

Three overlays 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 at once the most frequently audited and the most labour-intensive if done separately.

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

Supply chain and the supplier contract. The second high-return area. NIS2 expressly covers supply chain security, the AI Act splits obligations between the system provider and the deployer, the GDPR requires a processing agreement with every processor, and ISO has a separate supplier controls block. One well-constructed 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 follows from logs. The same logging mechanism and the same response procedure serve the NIS2 reporting obligation to the CSIRT, the AI Act serious incident report, the GDPR breach notification and the ISO incident controls. The thresholds and deadlines differ, but the infrastructure is one. More on what exactly to log in an AI system run locally is in the note on observability for on-prem LLMs.

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

The four regimes from 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.

The CRA, the Cyber Resilience Act. This is the fifth regime for anyone who makes products with digital elements themselves, rather than only deploying 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 the meaning of the CRA, a manufacturer of a product with digital elements. The key difference from NIS2: NIS2 looks at you as an entity that uses systems, while the CRA looks at you as a manufacturer placing a product on the market. Those are two different roles and two different sets of obligations that can fall on the same company.

From 11 September 2026 the CRA reporting obligation starts. The 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 flow: an early warning within 24 hours, a fuller notification within 72 hours, and a final report for a vulnerability within 14 days of a corrective measure becoming available. The full product obligations of the CRA start to apply from 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 the CRA mainly adds a new clock and a new addressee, not a new foundation. We break the reporting clock down on its own in the note on CRA vulnerability reporting from 11 September.

DORA, the regime for the financial sector. In force since 17 January 2025, it applies to financial entities and the ICT providers that serve them. For a typical manufacturer DORA is not a regime of its own, but it becomes one indirectly when you sell a component or service to a bank or insurer and your contract has to meet DORA's requirements for critical providers. Do not force DORA into the main matrix if you are not in the financial chain, because you will only add a column no one 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 the CRA. I also touch on the fact that the product layer and the operator layer are two different roles towards the same law when discussing 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 onto anything in the other regimes, and trying to merge them only generates risk. These have to be handled separately.

Reporting deadlines differ and cannot be averaged. A single event can start several independent clocks to different institutions. NIS2 introduces a multi-stage flow, with an early warning within 24 hours and a fuller notification within 72 hours to the relevant CSIRT. The GDPR has its own 72 hours to notify a breach to the supervisory authority, counted from a different moment and towards a different addressee. The AI Act has its own regime for reporting serious incidents. The 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 reports to four addressees on different deadlines. The incident procedure must recognise this and branch, not assume a single deadline.

AI-specific requirements have no counterpart in NIS2, GDPR, ISO or the CRA. Human oversight in the meaning of the AI Act, the quality and representativeness of training data, model accuracy and robustness, and information obligations towards 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. There is a separate note on the classification itself: the AI Act in manufacturing and high-risk classification.

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

The compliance matrix: how to build and maintain it

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

The matrix is a spreadsheet where rows are controls and columns are, in order: the evidence name, the owner, the status, the review date, and then one column per regime with a reference to the article. First set the list of controls, roughly the nine from the table plus AI-specific requirements if the system is high-risk, plus CRA rows if you make products with software. For each control enter one piece of evidence and its owner. Only then fill in 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 one 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 that no one synchronises. I develop this way of thinking in the cheat sheet mapping NIS2 plus AI to concrete controls.

ISO 27001 is worth treating here as the organising skeleton. Its information security management system is general enough that the other regimes can be hung on it as detailed requirements. If you already have or are building an ISMS, attaching NIS2, the AI layer and the CRA to it is cheaper than starting from zero. Which three ISO controls to map first I describe in the note on ISO 27001 and an AI vendor.

A ready-made matrix to download

Instead of building the spreadsheet from scratch, you can start from a ready template. The compliance matrix in spreadsheet form contains 14 controls mapped onto NIS2, the AI Act, the GDPR, ISO 27001 and the 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 a progress counter is computed automatically. It is the same skeleton I describe above, ready to use. Download the compliance matrix in XLSX format.

Deadlines: what applies and what shifts in 2026 and 2027

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

NIS2 came into force in Poland through the amendment to the National Cybersecurity System Act, which took effect on 3 April 2026. Entities meeting the criteria have until 3 October 2026 to apply 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 something like tens of thousands of Polish companies, not a few hundred as before the amendment.

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

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

The GDPR is stable and applies unchanged. DORA has applied since 17 January 2025 for the financial sector and its ICT providers. ISO 27001 in its current 2022 edition has a new Annex A structure with four control areas, 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, before decisions it is worth verifying the current state of publication of the amending act in the Official Journal of the EU.

FAQ

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

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

Where do I start if I already have ISO 27001?

By treating the ISMS as the skeleton. You attach the other regimes as detailed requirements to existing controls. That is cheaper than building parallel structures.

How does the CRA differ from NIS2, given both concern cybersecurity?

By the role they see you in. NIS2 looks at you as an entity that uses systems and provides services. The CRA looks at you as a manufacturer placing on the market a product with digital elements. The same company can fall under both, in two different roles, with two sets of obligations.

How many reporting clocks can one incident start?

Up to four: NIS2 (24 h and 72 h to the CSIRT), the GDPR (72 h to the supervisory authority), the AI Act (serious incidents) and the CRA (24 h, 72 h, 14 days to ENISA and the CSIRT). Deadlines and addressees 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 Article 50 transparency obligations 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 rights of individuals, which are the exclusive domain of the GDPR.

// disclosure & biasesDisclosure and biases

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

What this note does not cover

I do not give a full mapping of all ISO Annex A controls or all paragraphs 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 the CRA and DORA, because each deserves its own material. I leave aside the national implementing acts to the National Cybersecurity System Act, which will refine the details. Nor do I discuss the operational side of reporting an incident to the CSIRT or the technical layer of model protection, which I cover 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 NIS2 plus AI: 7 documents you produce before the auditor
• NIS2 plus AI: mapping Article 21 to concrete controls, one cheat sheet
• The DPA for an AI vendor: 8 clauses whose absence will topple an audit