"Why now" is not a sales slogan here — it is a calendar observation. In the 2025-2027 window, four regulatory regimes with hard incident-reporting deadlines converge: DORA, the AI Act, NIS2 and GDPR. Each of them creates an obligation for evidence of an event and a timely report to an authority or to the board. This page organizes the facts and shows precisely where ipIII addresses that gap — as decision-support, not as legal advice.
DORA has applied since 17.01.2025. AI Act art.50 (transparency) — since 2.08.2026. NIS2 imposes a 72-hour notification obligation for essential and important entities. GDPR art.33/34 — 72 hours on a personal data breach. Four different regimes, the same logic: when an incident occurs, you need evidence of what happened and the ability to report it within a deadline measured in hours, not weeks.
The table below organizes the dates and scopes. All of them are publicly available regulatory facts — interpreting a specific case always requires a review by a lawyer or DPO.
| Regime | Key date | Who it covers | Reporting obligation |
|---|---|---|---|
| DORA (Digital Operational Resilience Act) | In force since 17.01.2025 | EU financial entities (banks, insurers, investment firms, critical ICT providers) | ICT operational resilience + reporting major incidents to the supervisory authority within defined time windows. |
| AI Act — art.50 | In force since 2.08.2026, unchanged after the Digital Omnibus | Providers/deployers of AI systems that interact with humans (transparency, labelling of content/deepfakes) | Information obligation — the user must know they are interacting with AI or viewing synthetic content. |
| AI Act — art.73 / Annex III | Annex III (high-risk) deferred 2.08.2026 → 2.12.2027 (Digital Omnibus) | High-risk systems (including scoring, HR, recruitment) — scope deferred, not abolished | Reporting serious incidents (art.73) of high-risk AI systems. indicative date — to verify against the EU Official Journal |
| NIS2 | Notification obligation within 72h of detection (early warning typically within 24h) | Essential and important entities (energy, health, finance, digital infrastructure, public administration and other sectors in scope) | Multi-stage incident notification to the competent CSIRT/authority, with status updates and a final report. |
| GDPR — art.33/34 | Notification obligation within 72h of becoming aware of a breach | Controllers and processors of personal data (practically every organization) | Notification of a personal data breach to the supervisory authority (the national DPA) and — if high risk — notification of the data subjects. |
Four different legal regimes, one shared structure of the problem. When an incident happens — a cyberattack, a data breach, a serious AI failure — an organization must answer three questions in a short amount of time: what exactly happened (evidence), by when it must be reported (deadline), and in what form the report should take shape (report). In practice, these three elements today most often drift apart between the security team's spreadsheet, an email to compliance, and a separate draft for the lawyer — without a single source of truth linking the technical finding to the regulatory clock.
This is exactly the layer where ipIII operates: finding import → evidence with hash and chain-of-custody → Legal Trigger Engine suggesting a possible obligation and an indicative deadline → Board Pack for the board → Regulatory Pack as a starting point for the lawyer. We do not replace the lawyer, the auditor or the DPO — we organize the facts before they reach their desk, so the decision is made on the basis of evidence, not the team's memory.
| Regime | Estimated scale (model) | Source (to verify) |
|---|---|---|
| DORA | on the order of ~22,000 EU financial entities in scope | published estimate from the DORA regulatory impact assessment (European Commission); to confirm against the current ESAs register |
| NIS2 | on the order of tens of thousands to ~160,000 essential/important entities across the EU (a significant expansion of scope versus NIS1) | European Commission / ENISA communications on the expanded NIS2 scope; to confirm against the national CSIRT/competent-authority register |
These two figures illustrate the scale of the regulatory problem, not a revenue forecast for K0NSULT or the size of the market addressable by ipIII — we do not derive any financial figure from them on this page.
Unlike the market estimates above, the figures below describe the current state of the ipIII codebase and are directly verifiable, without model assumptions.
Every one of these figures is checkable without taking our word for it — just open the referenced endpoint. That is the distinction we care about: product figures we show as fact from the code; market figures as an explicitly labeled model assumption.
ipIII is not a competitor to a vulnerability scanner, a pentesting tool, a SIEM or a GRC platform — it consumes their output. The category we occupy is an evidence-and-regulatory layer between pentest/AppSec/SOC/GRC and the board, audit and the regulator: the place where a technical finding turns into evidence with a hash, an assigned owner, an SLA deadline and — where applicable — an indicative notification obligation. We treat this as complementary positioning to the existing security-tool stack, not as a claim that we are the only or the best solution on the market. A broader comparison with specific tool categories is covered on /porownanie-vs-scanners, /porownanie-vs-siem and /porownanie-vs-grc.
| Deployment mode | Description | Status |
|---|---|---|
| SaaS, EU region | Shared hosted instance, access via API/JWT, customer data logically separated in the current model. | MVP |
| Private tenant (dedicated instance) | Separate instance per customer, full Row-Level Security isolation in PostgreSQL. | ROADMAP |
| Customer VPC / on-prem | Deployment within the customer's network environment or locally, outside K0NSULT infrastructure. | ROADMAP |
A full description of maturity boundaries (auth, transport, tenancy, evidence signatures) is centralized on the page /known-limitations.
Related: AI Act pack (decision-support) → /ai-act-pack · legal rules engine → /legal-engine · known limitations and deployment modes → /known-limitations · engagement models → /pricing · trust center → /trust-center.