NIS-2 + AI Act — Shared Compliance Stack. Risk Register, DPIA, FRIA
NIS-2 and the AI Act share fundamentals — risk management, monitoring, documentation. One risk register, two frameworks. How to build a shared compliance stack for a Polish SME in 2026–2027.
Two Frameworks, One Stack — Because the Foundations Overlap
NIS-2 and the AI Act arrived on the Polish SME scene two years apart — the first with a transposition deadline of 17 October 2024, the second with its main deadline in August 2026. The natural temptation is to treat them as two separate projects, two teams, two sets of documentation. The natural mistake.
Both regulations rest on the same foundations — risk management, monitoring, documentation, incident response, governance. These foundations are also required by GDPR (Art. 35 DPIA), by DORA for the financial sector, and by ISO 27001 as an industry standard. Building five separate stacks instead of one with multiple views multiplies costs without adding compliance value.
This article shows where NIS-2 and the AI Act actually overlap, where they require separate artefacts (DPIA, FRIA), and how to build a shared compliance stack that serves both frameworks simultaneously. The goal — one risk register, one monitoring process, one audit cycle.
Four Common Points
Risk Management — NIS-2 Art. 21 vs AI Act Art. 9
Art. 21 NIS-2 requires essential and important entities to implement “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems.” The minimum list in paragraph 2 covers risk analysis policy, incident handling, business continuity, supply chain security, security in acquiring and maintaining systems, evaluating the effectiveness of measures, basic cyber hygiene practices and training, cryptography, access control, and asset management.
Art. 9 AI Act for high-risk systems requires a “risk management system” — a documented, continuous, iterative process covering the identification, estimation, evaluation, and mitigation of known and foreseeable risks throughout the system’s entire lifecycle.
Common points: continuous nature of the process (not a one-off document), iterativeness, documentation requirement, linkage to operational monitoring, integration with suppliers (supply chain in NIS-2, training data and third-party components in the AI Act).
Differences: NIS-2 focuses on risk to networks and systems; the AI Act — on risk to fundamental rights, health, and safety arising from a specific AI system. In practice the risk register needs two views on the same assets — a cyber perspective and an AI impact perspective.
Monitoring — NIS-2 Art. 21(2) vs AI Act Art. 72
NIS-2 requires monitoring of the effectiveness of risk management measures (Art. 21(2)(f)). AI Act Art. 72 imposes on high-risk providers an obligation of post-market monitoring — a documented system that actively collects, documents, and analyses data on the AI system’s performance throughout its entire lifecycle.
Common points: active, continuous monitoring; documentation obligation; obligation to update measures based on observations.
Stack practice: one observability toolset (logs, metrics, traces, alerts) with two separate dashboards — security operations for NIS-2 and AI performance/drift for the AI Act. The same SIEM, the same data lake, two views.
Documentation — NIS-2 vs AI Act Art. 11 + Annex IV
NIS-2 requires documentation of risk management measures (indirectly from Art. 21 in conjunction with Art. 32 enforcement). AI Act Art. 11 requires preparation of detailed technical documentation for the high-risk system before market placement, with a minimum scope defined in Annex IV.
Annex IV covers a general system description, a detailed description of components, a monitoring description, a risk management description, and a copy of the EU declaration of conformity — totalling over fifty information fields.
In practice, AI Act documentation is significantly more technically detailed. But the common shell — a documentation management system with versioning, access control, audit trail, and retention — is the same.
Incident Response — NIS-2 Art. 23 vs AI Act Art. 73
NIS-2 Art. 23 defines the obligation to report significant cybersecurity incidents — covered in detail in the article NIS-2 — incident reporting in practice.
AI Act Art. 73 defines the obligation to report serious incidents related to high-risk systems — including death or serious injury, serious disruption to the management of critical infrastructure, violation of fundamental rights, and serious property or environmental damage.
The recipient differs — in NIS-2 it is the CSIRT, in the AI Act it is the AI supervisory authority. But the internal process of detection, escalation, documentation, and root cause analysis is the same process. The difference lies in incident classification (is it a cyber incident, an AI safety incident, or both?) and in the report recipient.
One incident response team, one playbook with two classification branches — this is the operational minimum.
Risk Register as a Shared Artefact
A risk register is the central risk database of the organisation. For a shared NIS-2 + AI Act stack, each entry should ideally contain:
| Field | Description | Regulatory mapping |
|---|---|---|
| ID | Entry identifier | — |
| Asset | What it concerns — system, data, process | NIS-2 Art. 21(2)(i); AI Act Art. 9 |
| Threat | The threat | NIS-2 Art. 21; AI Act Art. 9 |
| Likelihood | Probability | NIS-2; AI Act |
| Impact (cyber) | Impact on availability, integrity, confidentiality | NIS-2 |
| Impact (AI/rights) | Impact on fundamental rights, health, safety | AI Act Art. 9, 27 |
| Mitigation | Measures | NIS-2 Art. 21(2); AI Act Art. 9 |
| Owner | Person responsible | NIS-2 Art. 20 (board); AI Act Art. 14 (human oversight) |
| Review date | Date of last review | Both |
| Residual risk | Risk after mitigation | Both |
| Status | Open / mitigated / accepted | Both |
Review frequency — minimum quarterly for active entries, monthly for entries with high residual risk. Full register audit — once a year with board involvement (NIS-2 Art. 20 requires approval of measures by management bodies and holds them accountable).
DPIA — Where It Meets the AI Act
GDPR Art. 35 requires a data protection impact assessment (DPIA) before processing “likely to result in a high risk to the rights and freedoms of natural persons” — particularly in systematic and comprehensive profiling, large-scale processing of special category data, and monitoring of publicly accessible areas.
Many high-risk AI systems require a DPIA regardless of the AI Act. It makes sense to build a single process that delivers:
- DPIA as an artefact compliant with GDPR;
- input for FRIA for required deployers (AI Act Art. 27);
- input for the risk register (cyber and AI views).
In practice — a DPIA template extended with the sections required by AI Act Art. 27 (categories of affected persons, frequency of use, AI-specific risks, human oversight measures) becomes a single document serving both regimes. Where a separate FRIA analysis is required, sections are indicated as part of the broader DPIA.
FRIA — When Is It Required and How to Organise It
AI Act Art. 27 imposes a FRIA obligation on:
- deployers that are public authorities and bodies providing public services;
- deployers of systems in Annex III point 5(b) (credit scoring) and point 5(c) (life and health insurance pricing).
Scope of FRIA from Art. 27(1):
- a description of the deployer’s processes in which the system will be used;
- the period and frequency of use;
- the categories of natural persons affected by the system;
- the specific risks of harm to those categories;
- a description of human oversight measures;
- measures taken in the event of risk materialisation, including internal governance and complaint mechanisms.
FRIA must be updated if any of these elements changes. The outcome goes to the supervisory authority — in Poland the authority designated by the AI Act implementation legislation (legislative process ongoing at publication date).
Operationally — FRIA is often completed as an extended DPIA. If the organisation already has a DPIA process under GDPR, adding FRIA sections per high-risk system is cheaper than building a separate process from scratch.
When DPIA + FRIA + Risk Register Become a Single Process
The three artefacts can become a single workflow if the organisation adopts the approach of:
- a shared asset catalogue: systems, data, and processes entered once, used by all three processes;
- shared risk taxonomies: a list of risk categories (cyber, fundamental rights, privacy, operational, financial) used everywhere;
- a shared review cycle: quarterly for the risk register, annually for DPIA/FRIA — in one compliance calendar;
- a shared documentation system: from a single GRC platform to disciplined use of Confluence + Excel + Git for technical artefacts.
The boundary that should not be blurred — competencies. DPIA requires a DPO or a person with equivalent legal-privacy competencies. FRIA requires competencies in fundamental rights and the specific intended purpose of the AI system. Cyber risk register requires a security engineer. These roles can use a shared stack but should not be merged in a single person below a certain organisational scale.
Tooling — GRC vs Excel + Confluence
In 2026, for a Polish SME below 250 employees, the rational choice for the first twelve to eighteen months is the following stack:
- risk register in Excel or in a versioned database (e.g. Notion, Airtable);
- documentation in Confluence or in a Git repository (Markdown + PR review);
- incident tickets in Jira or an equivalent ticket management tool;
- audit log in write-once storage (S3 Object Lock or equivalent).
Migration to a dedicated GRC platform (e.g. OneTrust, Drata, Vanta, ServiceNow GRC) makes sense only when: the number of high-risk systems exceeds approximately fifteen, the number of monitored requirements (NIS-2 + AI Act + GDPR + DORA + ISO) exceeds two hundred, or when a corporate client requires a specific report from a specific tool.
Earlier adoption of a GRC platform costs money that SMEs do not have — and creates the appearance of compliance without its operational substance. It is better to build process discipline on cheaper tooling and migrate with discipline than to buy a platform and treat it as a substitute for process.
6-Month Plan for SMEs in 2026
Month 1: audit of current state. What already exists? A list of all documents, policies, processes, and tools related to security, compliance, and AI. AS-IS state without polishing.
Month 2: gap analysis. Mapping existing artefacts against NIS-2 requirements (Art. 20, 21, 23) and AI Act requirements (Art. 9–22, 26–27, 72–73). Each gap categorised: blocking, major, minor.
Month 3: roadmap. Action plan for the next twelve months with prioritisation: blocking items first, then major. With responsibilities, deadlines, budget.
Months 4–5: core stack implementation. Operational risk register. DPIA-FRIA template. Incident playbooks. CSIRT contact list. Minimum policies: risk management, incident response, supply chain security, AI usage.
Month 6: external audit. Independent verification by a third party — not to receive a certificate, but to get a frank list of things that were overlooked internally. The audit result becomes an input for the second iteration of the roadmap.
QA10 — Where We Apply This
Within the AiP Audit we conduct a NIS-2 + AI Act + GDPR gap analysis in a single pass and deliver a map of shared vs framework-specific gaps. The Engineering Lab builds a shared risk register and the first iteration of a DPIA-FRIA template with the client.