NIS2, AI Act, GDPR, ISO 27001: one control set, not four

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

Short answer first

Four regimes, one body of evidence. NIS2 (in Poland transposed by the amended National Cybersecurity System Act, in force since 3 April 2026), the AI Act, GDPR and ISO 27001 place requirements on a manufacturer deploying AI that overlap heavily. 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 vendor contract with the right clauses closes the NIS2 supply chain requirement, the AI Act obligations and the GDPR processor relationship. The practical takeaway: do not run four separate compliance projects. Build one set of controls and evidence, then map each control onto all four regimes. You work in controls, not statutes. Below is the cross-mapping table and, just as important, the places where the regimes genuinely diverge, because those cannot be merged away.

Table of contents

1. Why four regimes ask the same thing
2. The cross-mapping table: nine areas
3. Three overlaps that pay off most
4. Where the regimes diverge
5. How to structure this in practice
6. Deadlines that apply in 2026
7. FAQ
8. Disclosure and biases
9. What this does not cover
10. Related notes

Why four regimes ask the same thing

A manufacturer deploying AI in Poland lands inside at least four regimes at once. NIS2, transposed by the amended National Cybersecurity System 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 rarely a statutory requirement, but it is often expected contractually and is the most convenient skeleton on which to hang the rest.

The instinctive response is to treat each regime as a separate project with its own team, its own timeline and its own set of documents. That is the most expensive option available, because in the technical layer the four regimes mostly ask the same questions: did you run a risk assessment, do you control your suppliers, can you detect and report incidents, do you manage access, do you log, do you encrypt, do you have business continuity, and does someone at the right level own the decision.

They differ in vocabulary, article numbering and emphasis, not in substance. A risk assessment done once, properly, and documented, is the same piece of evidence for a NIS2 auditor, for AI Act conformity work and for ISO. That is why it pays to think in controls rather than statutes: define a control set, implement it once, and map it onto the four regimes.

The cross-mapping table: nine areas

Below are nine control areas that recur across all four regimes, with references to specific articles and controls. The AI Act references relate to obligations for high-risk systems.

Control area	NIS2 / national act (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, domain A.5
Supply chain and vendor 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
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 backup	Art. 21(2)(c)	Art. 15 (robustness)	Art. 32(1)(b), (c)	A.5.29, A.5.30
Documentation and records	ISMS documentation	Art. 11, Annex IV	Art. 30 (records 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 up: different provisions, one control question. That is the whole idea of cross-mapping. Instead of nine times four, thirty six tasks, you have nine controls, each documented once and presented from four angles.

Three overlaps that pay off most

Not every row carries the same weight. Three areas give the largest return on a single piece of work, because they are both the most frequently audited and the most labour intensive if done separately.

Risk assessment. This is the cleanest example of one job serving four regimes. NIS2 requires risk management measures, the AI Act mandates a risk management system across the lifecycle of a high-risk system, GDPR requires a data protection impact assessment for high-risk processing, and ISO puts risk assessment at the centre of the information security management system. If you build one risk assessment for the AI deployment that covers threats to system security, to the rights of individuals and to process continuity, a single document answers four requirements. The condition: the assessment has to genuinely span those three layers, not be a copy of a template from one regime.

Supply chain and vendor contract. The second high-return area. NIS2 explicitly covers supply chain security, the AI Act splits obligations between the system provider and the deployer, GDPR requires a processor agreement with every processor, and ISO has a dedicated block of supplier controls. One well constructed contract, an MSA plus a data processing agreement, with clauses on processing scope, sub-processors, safeguards, right to audit and exit terms, closes all four. I covered the clauses themselves in the note on a 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 report, the GDPR breach notification and the ISO incident controls. Thresholds and deadlines differ, but the infrastructure is one. More on what specifically to log in a locally hosted AI system is in the note on observability for on-prem LLMs.

Where the regimes diverge

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

Reporting deadlines differ and cannot be averaged. NIS2 introduces a multi-stage flow, with an early warning within 24 hours and a fuller notification within 72 hours to the relevant CSIRT. GDPR has its own 72 hours for reporting a breach to the supervisory authority, but counted from a different moment and directed at a different addressee. The AI Act has its own regime for serious incidents. A single event can start three different clocks toward three different institutions. The incident procedure has to recognise this rather than assume one deadline.

AI-specific requirements have no counterpart in NIS2, GDPR or ISO. 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 lift off a cybersecurity shelf. Cross-mapping does not help here, because there is nothing to map onto. These areas require dedicated work for systems classified as high risk. Classification itself is a separate note: the AI Act in manufacturing and high-risk classification.

Legal basis and data subject rights are GDPR only. Conformity with NIS2 or ISO says nothing about whether you have a basis to process personal data or how you fulfil data subject rights. That layer lives its own life and cannot be derived from security controls.

How to structure this in practice

The sequence that works is the opposite of the intuitive one. You do not start by reading four legal acts in parallel, you start by defining a control set.

First set the list of controls, roughly the nine from the table plus the AI-specific requirements if the system is high risk. For each control define one piece of evidence, a concrete artefact: the risk assessment, the contract, the data flow map, the logging policy, the incident procedure. Only then map each artefact onto the relevant articles of the four regimes, building a simple compliance matrix. That matrix is at once your map and your audit readiness evidence.

The advantage of this approach is resilience to change. When a fifth regime appears or the numbering in one act shifts, you do not rebuild your entire compliance programme. You add a column to the matrix and check which existing artefacts cover it and which gaps remain. That is far cheaper than maintaining four parallel document sets that nobody keeps in sync. I develop this way of thinking in the NIS2 plus AI mapping cheat sheet.

ISO 27001 is worth treating here as the organising skeleton. Its information security management system is general enough that the other regimes hang off it as detailed requirements. If you already have or are building an ISMS, attaching NIS2 and the AI layer to it is cheaper than starting from scratch.

Deadlines that apply in 2026

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

NIS2 entered 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 tens of thousands of Polish companies rather than the few hundred covered before the amendment.

The AI Act was significantly pushed back this year. The simplification package known as the Digital Omnibus moved the start of obligations for high-risk systems under Annex III from August 2026 to 2 December 2027, and for AI embedded in regulated products under Annex I to 2 August 2028. Note a common error: this does not mean everything is deferred. The transparency obligations under Article 50, for example labelling AI-generated content, arrive on the original schedule from 2 August 2026. The deferral concerns the high-risk layer, not the whole act.

GDPR is stable and applies unchanged. ISO 27001 in its current 2022 edition has a restructured Annex A with four control themes, and the transition period from the 2013 version has already ended, so certificates and mappings should reference the 2022 edition.

Because the AI Act dates shifted several times this year, before making decisions it is worth verifying the current publication status of the amending act in the Official Journal of the EU.

FAQ

Do I have to run four separate compliance projects?

No. In the technical layer, NIS2, the AI Act, GDPR and ISO 27001 mostly ask for the same controls. It is more efficient to build one control set and body of evidence, then map it onto the four regimes in a single compliance matrix.

Where do I start if I already have ISO 27001?

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

What will cross-mapping not solve?

Incident reporting deadlines, because they differ across NIS2, GDPR and the AI Act. AI-specific requirements such as human oversight, data quality and model accuracy. And the legal basis and data subject rights, which are GDPR only.

Does the AI Act deferral mean I have until 2027?

Only for high-risk system obligations. The Article 50 transparency obligations apply from 2 August 2026 regardless of the deferral.

// 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 flow and on-prem architecture. I have tried to separate the content of the rules from architectural preference. This text is not legal advice. Mapping between regimes is an editorial simplification: a single article is often realised through several controls and vice versa, and interpretation depends on the sector and the facts. Audit practice for NIS2 and the AI Act is still forming. Before making compliance decisions, consult a lawyer specialising in cybersecurity and data protection.

What this does not cover

I do not give a full mapping of every ISO Annex A control or every paragraph of the four acts, because that belongs in a working document, not a note. I do not go into sector-specific regimes, for example DORA for finance or product requirements, which may add obligations. I skip the national implementing acts to the Cybersecurity System Act, 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 securing the model itself, which deserve 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
• NIS2 audit readiness plus AI: 7 documents you produce for the auditor
• NIS2 plus AI: mapping Article 21 onto concrete controls, one cheat sheet
• A DPA for an AI vendor: 8 clauses whose absence will sink an audit