DORA, NIS2 and EU AI Act compliance software

Build one evidence spine for entities, systems, services, vendors, controls, incidents and approvals—then keep each law's scope, thresholds, clocks, authorities and conclusions separate.

Compare the three tracks Design the evidence system

Start with applicability, not a merged control checklist

The three regimes regulate different subjects. The first useful software output is a reviewed scope record for every legal entity, service and AI system, including the facts used, the reviewer, unresolved questions and the law or national measure consulted.

Decision	DORA	NIS2	EU AI Act
Primary scope key	Type of financial entity, legal entity and applicable proportionality or simplified framework	Member State, Annex I or II sector, entity type, size rule and specific inclusions or exclusions	AI-system intended purpose, role in the value chain, risk category, territory and date placed on the market or put into service
Core accountable party	The in-scope financial entity; critical ICT third-party providers also face the EU oversight framework	The essential or important entity under the applicable national implementing law	Provider, deployer, importer, distributor or GPAI-model provider, depending on the actual role
Operational focus	ICT risk management, resilience testing, major incident reporting and ICT third-party risk	Management oversight, proportionate cybersecurity measures, supply-chain security and significant-incident reporting	Prohibited practices, transparency, AI literacy, GPAI duties and risk-based obligations for relevant systems
Authority route	Sectoral competent authority and prescribed DORA reporting route	National competent authority or CSIRT under Member State law	AI Office for its EU-level tasks and designated national competent authorities for other enforcement

DORA is already applicable

DORA has applied since 17 January 2025. Its Article 2 list—not a generic “fintech” label—drives financial-entity scope. Official regulation.

NIS2 is national in operation

Member States were required to transpose NIS2 by 17 October 2024. Scope, registration, supervision and procedures must be checked against current national law. Official directive.

AI Act dates are obligation-specific

The general application date was 2 August 2026, while the amended timetable delays core high-risk duties. Store dates per obligation instead of one global status. Consolidated text.

DORA can displace parts of NIS2—but not every group question

DORA identifies itself as the sector-specific Union legal act for the relevant NIS2 cybersecurity risk-management and incident- reporting provisions for covered financial entities. This prevents duplicated duties where the equivalence test is met; it does not turn a mixed corporate group into one undifferentiated scope.

Resolve at legal-entity level

Record the regulated entity, Member State, services, sector classification and why DORA, national NIS2 law or both remain relevant.

Keep the equivalence rationale

Link the sector-specific-law decision to DORA, NIS2 Article 4, Commission guidance and counsel review. Do not hide it in a project note.

Test adjacent operations

Shared-service companies, non-financial subsidiaries, managed services and activities outside the financial entity can follow a different route.

Reuse actual operations

Where one control genuinely covers several entities, preserve the common test but attach entity-specific scope, exceptions and approvals.

The Commission's Article 4 guidance explains the equivalence test for sector-specific Union acts. It is interpretive guidance; the underlying directive, DORA and applicable national measures remain the legal sources. Commission guidance.

Model evidence as a graph, not a folder tree

A document library cannot answer which current systems, services, vendors and obligations an artifact proves. The evidence layer needs typed relationships and version history so a reviewer can reconstruct the position at any reporting date.

Scope objects

Legal entity, establishment, business service, critical or important function, process, AI use case and accountable owner.

Technology objects

ICT asset, data flow, integration, software release, AI system, model, dataset, environment and dependency.

Third-party objects

Provider, subcontractor, contract, service, location, concentration indicator, exit plan and assessment.

Assurance objects

Obligation, control, procedure, test, source artifact, finding, exception, remediation, reviewer and approval.

Incident objects

Event, awareness time, classification time, impact, affected service, threshold result, decision and report revision.

Provenance objects

Source system, immutable identifier, query or method, collection time, covered period, checksum and access record.

One artifact, explicit mappings

A restore-test result may evidence DORA resilience testing, a NIS2 business-continuity measure and an AI service dependency. Store it once, then attach distinct requirement mappings and reviewer decisions. Never copy it into three untraceable folders.

Source fact: What happened, where it came from, when it was collected and which period it covers.
Mapping rationale: Why this source supports this particular requirement for this scope.
Review state: Who assessed sufficiency, when, with what exception or follow-up.
Change impact: Which mappings become stale when the service, system, contract or law changes.

One event record, independent reporting clocks

A production incident can trigger several assessments, but their definitions and time origins are not interchangeable. Capture raw facts once; run separate rule sets, approvals, recipients and report revisions. The system should never let one “reported” checkbox close every regulatory track.

Track	Trigger and first stage	Follow-up stages	Workflow requirement
DORA major ICT-related incident	Initial notification as early as possible, within four hours of classification as major and no later than 24 hours after awareness.	Intermediate report within 72 hours after the initial notification; final report within one month after the intermediate or latest update.	Preserve awareness and classification times, threshold evidence, competent authority, submitted payload and every update.
NIS2 significant incident	Early warning without undue delay and within 24 hours after awareness.	Incident notification within 72 hours after awareness; final report within one month after the incident notification, subject to Article 23.	Apply the Member State's threshold, CSIRT or authority route, language, portal and any sector-specific instructions.
AI Act serious incident	Provider reporting depends on the system, role, serious-incident definition and applicable provisions rather than a DORA or NIS2 label.	Route post-market information, corrective action and notifications through the applicable AI Act workflow and current authority guidance.	Link system version, intended purpose, logs, affected persons, role allocation, investigation and notification decision.

DORA clock logic

Delegated Regulation 2025/301 makes classification time and awareness time separately material. If classification occurs later than 24 hours after awareness, the initial notification is still due within four hours of classification. Binding time limits.

NIS2 local implementation

Article 23 supplies the EU reporting sequence, but the operational submission follows national transposition. Keep the authority, threshold version and local form configuration effective-dated. NIS2 Article 23.

Give each regulation its own operating lane

Shared data reduces duplicated work. Regulation-specific workflows preserve meaning. Each lane should expose missing owners, stale evidence, open exceptions and report readiness without presenting an unsupported “compliant” percentage.

DORA operations

ICT risk framework, policies, roles, critical functions and annual review evidence
Incident capture, major-incident classification, approvals and regulatory report versions
Resilience testing program, findings, remediation and risk-based test coverage
ICT third-party register in the prescribed templates, with referential integrity checks
Contract clauses, subcontracting chains, concentration analysis, continuity and exit planning
Threat-led penetration testing workflow only where the entity is identified as subject to it

NIS2 operations

National scope assessment, registrations, competent authority and material changes
Management-body approval, oversight evidence and relevant cybersecurity training
Risk analysis, incident handling, business continuity, crisis management and security testing
Supply-chain risk, supplier practices and security in acquisition, development and maintenance
Vulnerability handling, disclosure, cryptography, access control and multi-factor authentication
Significant-incident triage, CSIRT or authority reports and post-incident improvement

AI Act operations

AI-system and GPAI-model inventory with intended purpose, role, provider and release lineage
Prohibited-practice screening, AI literacy records and applicable transparency controls
Risk classification with facts, exclusions, reviewer, decision version and change triggers
High-risk readiness for quality, risk, data, technical documentation, logs and human oversight
Deployer duties, instructions, monitoring, worker information and impact assessment where applicable
Post-market monitoring, serious-incident handling, corrective action and authority cooperation

DORA register quality gates

Regulation 2024/2956 defines linked templates, keys and controlled values. A spreadsheet export is not enough if entity, branch, contract, provider, service and function references disagree. Official templates.

Validate unique identifiers and foreign-key relationships before export.
Version contracts, services, locations and critical-function mappings over time.
Separate direct provider facts from subcontractor-chain facts and known gaps.
Retain the submitted package, validation result, reviewer and reporting date.

Treat the AI Act as a live timetable

As of this review, the Act generally applies, but the consolidated law retains phased and transitional dates. A roadmap must be tied to each obligation, role and system release—not a dated slide saying the whole Act starts at once.

Already applicable

Prohibited-practice and AI-literacy provisions have applied since February 2025; governance and GPAI provisions have applied since August 2025; the general application date was August 2026.

High-risk Annex III

Core Chapter III high-risk requirements for systems classified through Article 6(2) and Annex III apply from 2 December 2027 under the amended Article 113.

High-risk Annex I products

The corresponding core requirements for AI safety components or products classified through Article 6(1) and Annex I apply from 2 August 2028.

Transition-sensitive records

Market-placement date, model release, substantial modification, system role and the particular provision determine which transition or grandfathering rule applies.

These dates follow the consolidated AI Act amended on 27 July 2026 and the Commission's current enforcement overview. They describe the EU framework; a system-specific legal assessment must also test exclusions, special provisions and later official measures. Enforcement framework.

Architecture for defensible automation

The compliance layer should reference operational systems, not become a second uncontrolled copy of them. Prefer read-only, least-privilege integrations and retain enough provenance for a reviewer to reproduce the evidence.

Authoritative sources

Identity, cloud, ticketing, code, asset, vendor, contract, incident and AI lifecycle systems remain sources of truth.

Normalization layer

Stable identifiers, schema validation, effective dates and entity resolution connect facts across tools.

Evidence and decisions

Versioned artifacts, mappings, tests, approvals, exceptions, clocks and immutable activity history preserve reasoning.

Controlled outputs

Authority reports, DORA register files, management packs and reviewer access are generated from approved versions.

Automate these safely

Inventory synchronization, schema validation and stale-owner detection
Evidence collection with source ID, timestamp, query and covered period
Recurring tests, review assignments, reminders and escalation paths
Deadline calculations from approved event timestamps and classifications
Crosswalk suggestions, report assembly and pre-submission validation

Keep these accountable

Legal-entity scope and the effect of national implementing law
Criticality, materiality, significance and serious-incident judgments
AI role, prohibited-practice and risk-classification decisions
Residual-risk acceptance, exceptions and management-body approvals
Final content, recipients and authorization of regulatory submissions

Deliver vertical slices that reviewers can test

Do not spend a quarter building a universal control catalog before proving one workflow. Each release should connect source facts to a scoped obligation, human decision, evidence result and usable output.

Establish scope and source ownership
Resolve legal entities, national regimes, services, critical functions, vendors, AI systems and responsible reviewers. Document unknowns instead of defaulting them to not applicable.
Build the shared evidence spine
Create identifiers, effective dates, obligation mappings, source provenance, tests, exceptions, approvals and role-based access. Migrate only evidence with an owner and interpretable lineage.
Ship one high-risk workflow
Choose a real bottleneck such as DORA incident reporting, the ICT third-party register, NIS2 supply-chain review or AI-system classification. Exercise it with representative data and exceptions.
Add regulatory output adapters
Generate prescribed templates and authority-ready packs from approved records. Keep local forms, schemas, languages and rule versions outside the shared domain model.
Operate and improve
Track stale scope, overdue reviews, failing controls, unresolved exceptions, incident drill results and evidence gaps. Reassess mappings when law, guidance, systems or vendors change.

Acceptance criteria worth buying

Traceability

A reviewer can travel from entity and obligation to current control, source artifact, test, exception and approval—and back again.

Temporal accuracy

The platform can reconstruct scope, evidence, contracts, system versions, decisions and report payloads at a chosen date.

Rule isolation

A change to one Member State form or AI Act date does not rewrite DORA history or silently close another framework's work.

Incident readiness

A tabletop proves timestamp capture, separate classifications, deadline calculation, approver availability and report versioning.

Data minimization

Connectors collect only evidence needed for the declared purpose; secrets, message content and customer records are excluded by default.

Honest status

Dashboards show coverage, freshness, test results, exceptions and overdue decisions rather than a legally meaningless global score.

DORA, NIS2 and AI Act software FAQ

Can one platform make an organization compliant with DORA, NIS2 and the AI Act?

No. Software can maintain scope decisions, inventories, controls, evidence, incidents, approvals and reporting packs. It cannot determine legal scope without accountable review, approve residual risk, replace management responsibilities, or guarantee a regulator's conclusion. The useful goal is demonstrable operation with traceable human decisions—not a universal compliance score.

Does a financial entity subject to DORA also have to run a separate NIS2 program?

Not automatically. DORA states that, for financial entities covered by it, DORA is a sector-specific Union legal act for the relevant NIS2 cybersecurity risk-management and incident-reporting requirements. The boundary still needs legal review: group entities, services or obligations outside DORA can remain subject to national NIS2 law, and NIS2 is implemented and supervised through Member States.

What are the DORA incident reporting deadlines?

For an incident classified as major, the initial notification is due as early as possible and within four hours of classification, with an outside limit of 24 hours from awareness. The intermediate report is due within 72 hours after the initial notification. The final report is due no later than one month after the intermediate report or latest updated intermediate report. The platform must preserve both awareness and classification timestamps.

What are the NIS2 significant-incident reporting stages?

Article 23 sets an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month after the incident notification. Intermediate progress reports may also be requested. Apply the relevant Member State's implementing law, authority instructions, thresholds and portal rather than treating the directive as the only operational source.

Which AI Act dates apply in September 2026?

The AI Act's general application date was 2 August 2026; prohibitions and AI literacy have applied since 2 February 2025, and governance and general-purpose AI obligations since 2 August 2025. Under the consolidated text amended in July 2026, the core high-risk duties for Annex III systems apply from 2 December 2027 and for Annex I product systems from 2 August 2028. Other transitional provisions and system-specific dates can differ, so the inventory needs a per-obligation timeline.

What evidence can the three programs safely share?

Common source evidence can include entity and service inventories, identity reviews, vulnerability records, change approvals, backup and restore tests, incident exercises, vendor due diligence, contract state, training and risk decisions. Each mapping still needs its own legal entity, scope, requirement, rationale, review date and accountable owner.

What should the first implementation release contain?

Start with legal-entity and service scope, authoritative inventories, an obligation register, evidence lineage, owner and reviewer workflows, exception handling, and a dual-clock incident record. Add DORA register templates, national NIS2 reports and AI-system classification as separate output modules. Integrate only the few source systems that close the largest evidence gaps.

Primary sources and legal status

Reviewed 2 September 2026. DORA and the AI Act are directly applicable EU regulations; NIS2 is a directive implemented through Member State law. Delegated and implementing regulations listed here are binding within their scope. Commission guidance is authoritative but non-binding. Yarify's data models, workflow patterns and delivery recommendations are engineering guidance, not legal advice.