DORA ICT-Risk Reporting: Reading KNF’s 2026 Cyber-Threat Report

ByOfficer

On 9 July 2026, CSIRT KNF, the cyber-incident response team inside Poland’s Financial Supervision Authority, refreshed its report on the cyber threats facing the Polish financial sector for 2026. The document reads like a briefing pack rather than a rulebook: the priority attack scenarios, the techniques criminals are stacking into single campaigns, and the risks the supervisor wants firms watching. It carries no filing deadline and adds nothing to any regulatory return. For teams that own DORA ICT-risk reporting in Poland, that is precisely why it earns an afternoon of attention.

The reason sits with the author. CSIRT KNF is the sectoral computer security incident response team for the Polish financial market, and it also runs the channel through which financial entities file their major ICT-related incident reports under the Digital Operational Resilience Act. When the same body that receives your incident notifications publishes its own view of the attacks it expects to see, that view is a useful proxy for what a supervisor will later ask about when a report lands on its desk.

This article works through what the CSIRT KNF report is, where it touches the binding DORA incident-reporting regime under Regulation (EU) 2022/2554, how Polish entities actually file, and how a reporting team can use the report to pressure-test its own detection, classification, and third-party controls without confusing an awareness document for a new obligation.

Related reading: the ECB’s supervisory letter to bank CEOs on AI-enabled cyber threats and what it means for DORA.

What the CSIRT KNF report is, and what it does not change

The publication is titled “Krajobraz cyberzagrozen w polskim sektorze finansowym 2026” (Cyber Threat Landscape in the Polish Financial Sector 2026). CSIRT KNF describes it as supporting material for risk analysis, protective planning, detection capability, response scenarios, and staff awareness. It is a diagnostic, distributed to help firms prepare. Nothing in it amends a template, moves a deadline, or creates a data point you must submit.

That distinction is the first thing to get right, because threat reports from a national authority are easy to over-read. A common assumption is that a supervisor’s threat publication tightens a reporting requirement. Here it does not. The obligations that matter for filing already exist in DORA and its technical standards, and they applied from 17 January 2025 with no transitional period. The report tells you what the supervisor is thinking. DORA tells you what you must record and report.

The report’s own framing of 2026 is worth carrying into your risk register. CSIRT KNF’s headline point is about convergence: the defining shift for the year is the increasingly routine stacking of several techniques inside one campaign, a cyberattack element, financial fraud, social engineering, identity theft, extortion, and reputational pressure, braided together. That matters for a reporting team, because a blended campaign rarely maps to one tidy incident category, and DORA grades an incident on its impact whatever the attacker’s playbook.

The threats CSIRT KNF put at the top for 2026

The report sets out a priority list. Read as a reporting officer, each item works as a question: would your detection and classification catch it, and grade it correctly?

CSIRT KNF flags cyber-enabled fraud amplified by artificial intelligence; the theft of identities, sessions, and credentials; the growth of access markets and the activity of Initial Access Brokers; attacks on the software supply chain; ransomware and data extortion; distributed denial-of-service attacks; hacktivism and reputational operations; and the risks that flow from the financial sector’s dependence on ICT providers and from technological concentration. The report gives particular weight to digital identity risk, to infostealers, and to hijacked cookies, tokens, and login data, noting that credentials harvested this way can be used for account takeover, for monetising access, for staging ransomware or fraud, for data exfiltration, or for compromising cloud and SaaS environments.

Artificial intelligence runs through the whole document. CSIRT KNF’s assessment is that generative AI raises the success rate of phishing, smishing, vishing, deepfake impersonation, and investment scams, making the approach more credible, more personalised, and harder to tell apart from legitimate communication. Looking further out, the report expects AI to help automate reconnaissance, surface vulnerabilities, speed up their exploitation, and plan more complex attack paths. None of that changes how an incident is reported. It changes how likely you are to have one, and how convincingly a fraudulent instruction or a spoofed executive can slip past a control you were relying on.

The supply-chain and concentration warnings deserve a separate note, because they land on DORA’s third-party regime as much as on incident reporting. If a shared provider is the single point of failure for several firms, an incident there is both an ICT-related incident to classify and a third-party dependency to have already documented in your DORA register of information.

How the report maps onto DORA ICT-risk reporting

DORA’s incident rules sit in Chapter III of Regulation (EU) 2022/2554, Articles 17 to 23. Three of them carry the weight for a reporting team.

Article 17 requires every financial entity to run an ICT-related incident management process that detects, manages, and notifies incidents, and to record all ICT-related incidents and all significant cyber threats. That recording duty is broader than the reporting duty, and it is easy to under-build. You log everything relevant; you report only what crosses the threshold.

Article 18 sets the classification test. A financial entity determines an incident’s impact against a defined set of criteria: the number and relevance of clients or financial counterparts affected and the transactions involved, together with any reputational impact; the duration of the incident and the service downtime; the geographical spread, with particular attention where more than two Member States are affected; data losses touching the availability, authenticity, integrity, or confidentiality of data; the criticality of the services hit; and the economic impact in both absolute and relative terms. Article 18 also defines when a cyber threat is significant, judged on the criticality of the services at risk, the number and relevance of the clients or counterparts targeted, and the geographical spread of the areas at risk. The materiality thresholds that turn these criteria into a yes-or-no answer are set in the DORA classification standard, Commission Delegated Regulation (EU) 2024/1772.

Article 19 is the filing duty. Financial entities must report major ICT-related incidents to the relevant competent authority. The same article provides for the voluntary notification of significant cyber threats: where an entity judges a threat relevant, it may notify, but it is not obliged to. That voluntary status is the second easy thing to get wrong, and it matters when you read a threat report like this one. A scenario that CSIRT KNF flags as a priority becomes a notification only if your own assessment classifies a live threat as significant and you choose to share it, not simply because the supervisor is worried about it.

The reporting clock, once an incident is major

The cadence for a major incident is fixed by Commission Delegated Regulation (EU) 2025/301, which specifies the content and time limits, with the standard forms and procedures set out in Commission Implementing Regulation (EU) 2025/302. The dates worth pinning to the wall:

  • DORA applies from 17 January 2025, with no transitional period for the incident-reporting obligations.
  • Initial notification: within 4 hours of classifying the incident as major, and no later than 24 hours from the moment the entity became aware of it.
  • Intermediate report: within 72 hours of the initial notification.
  • Final report: no later than one month after the intermediate report, or after the latest updated intermediate report, once the root-cause analysis is complete.

The four-hour figure is measured from classification, not from the first alert, which is why the classification step is where teams lose time. If the process to grade an incident against Article 18 takes half a day, the clock that follows is already under pressure. The CSIRT KNF report is a rehearsal aid for exactly that moment: run its scenarios through your classification logic before a real one forces the question.

Reporting in Poland: the SOID channel and CSIRT KNF’s dual role

In Poland, the Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) is the DORA competent authority, and CSIRT KNF operates the incident-reporting channel. Financial entities file through SOID, the System do Obslugi Incydentow DORA (DORA Incident Handling System), reached at csirt.knf.gov.pl. Where the system is unavailable, the submission goes by email to incydenty.dora@knf.gov.pl using KNF’s downloadable forms, and the entity then registers that email submission in the system once access is restored. KNF provides two spreadsheet templates, one for major ICT-related incidents and one for significant cyber threats.

The dual role is the operational detail to hold onto. CSIRT KNF is both the recipient of your reports and the author of the threat report. The two feed each other: the incidents that firms file shape what the supervisor understands about the market, and the market picture shapes the threats it chooses to highlight. A reporting team that treats the annual threat report as background reading is missing that the same team on the other side of the SOID portal wrote it.

One practical trap here is scope. The threat report speaks to the whole Polish financial ecosystem, its institutions, their clients, and their ICT providers. DORA’s reporting obligations apply to the financial entities within its own perimeter under Article 2 of Regulation (EU) 2022/2554. A vendor named in a supply-chain warning is not thereby a DORA reporting entity; your obligation as the financial entity is to classify and, where relevant, report the incident that reaches you, and to have the provider relationship captured in your register.

Using the threat report to pressure-test your framework

The most useful way to read the document is as a set of test cases. Take each priority scenario and walk it through your own controls, in the order DORA would.

Start with detection and the incident-management process under Article 17. An AI-assisted phishing campaign that harvests a treasury operator’s session token is only an incident you can report if you notice it. Ask whether your early-warning indicators would fire on the specific techniques CSIRT KNF names, or whether they are tuned to yesterday’s threats.

Move to classification under Article 18. A credential-theft event that enables a fraudulent payment run touches several of the criteria at once: clients and transactions affected, potential data loss, the criticality of the payment service, and direct economic impact. Rehearse whether your team would reach a “major” determination quickly enough to start the four-hour clock on solid footing, and whether they would document the reasoning a supervisor could later test.

Then look outward to third-party and concentration risk, which the ESAs’ own data underlines. In its 2025 report on major ICT-related incidents, published on 3 June 2026 under Article 22 of DORA, the Joint Committee of the European Supervisory Authorities recorded 3,383 major incidents across all EU financial sectors, an average of 0.18 per entity in DORA’s scope, concentrated in the credit and payments sectors. Almost a third of those incidents traced back to failures attributable to third parties, and around a third had a cross-border impact. Two thirds caused no or only minor disruption to clients and transactions, which the ESAs read as evidence that timely detection and containment were generally working. The third-party share is the number to sit with: the supply-chain and concentration warnings in the KNF report are the national echo of an EU-wide pattern, and both point at the quality of your ICT third-party risk management and register of information.

Finally, connect the report to your testing programme. DORA’s digital operational resilience testing, and threat-led penetration testing for the entities in scope, is where a threat report earns its keep by feeding the scenario design. If CSIRT KNF is telling you that Initial Access Brokers and infostealers are the routes it expects, a threat-led test that ignores credential theft is testing the wrong thing. The mechanics of the exercise are covered in our note on DORA threat-led penetration testing for European financial entities.

How the AI emphasis affects detection and reporting

The report’s emphasis on artificial intelligence invites a specific misreading: that an AI-enabled attack needs a special report or a new category. It does not. DORA classifies incidents by their impact on your operations and data under Article 18, whatever tool the attacker used. A deepfake voice that authorises a fraudulent transfer and a plain email that does the same thing are graded on the same criteria. There is no AI incident template and no separate AI notification track.

What the AI angle changes is the plausibility of the attack and the pace at which it can scale, and that is a detection and control problem before it is a reporting problem. The ESAs made a complementary point in their 2025 report: relatively few of the year’s major incidents were categorised as cyber-related, while they cautioned that firms must keep pace with the potential use of highly capable AI-driven tools. Read together, the two messages are consistent. The volume of reported cyber incidents has been contained so far; the supervisors, national and European, are signalling that the attacker’s toolkit is improving faster than the incident numbers suggest, and that complacency at the detection layer is the risk. The classification and reporting machinery is ready. The question the KNF report presses is whether your front line still sees the attack coming.

For firms weighing how much of this applies to them, proportionality is real but narrow. DORA scales some requirements by size and risk profile, and lighter routes exist for microenterprises and for entities on the simplified ICT risk management framework, a point covered in our piece on DORA resilience testing for smaller firms. Proportionality changes the depth of the framework you must build. It does not switch off the duty to classify and report a major ICT-related incident.

Frequently Asked Questions

Does the CSIRT KNF cyber-threat report create a new reporting obligation for Polish financial entities?

No. CSIRT KNF presents it as supporting material for risk analysis, detection, and awareness. It amends no template and sets no deadline. The binding reporting duties live in DORA, Regulation (EU) 2022/2554, and its technical standards, which have applied since 17 January 2025.

Who is the DORA competent authority in Poland, and who receives the reports?

The Polish Financial Supervision Authority (KNF) is the DORA competent authority for financial entities in Poland. CSIRT KNF operates the incident-reporting channel through which major ICT-related incidents and voluntary significant-cyber-threat notifications are submitted.

How do Polish financial entities file a major ICT-related incident?

Through SOID, the DORA Incident Handling System, at csirt.knf.gov.pl. If the system is unavailable, the entity submits by email to incydenty.dora@knf.gov.pl using KNF’s forms, then registers that submission in the system once access is restored. Separate templates cover major incidents and significant cyber threats.

What are the DORA deadlines once an incident is classified as major?

Under Commission Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours from becoming aware of it; the intermediate report within 72 hours of the initial notification; and the final report no later than one month after the intermediate report.

Are we required to notify significant cyber threats?

No. Article 19 of DORA makes the notification of significant cyber threats voluntary. An entity may notify where it judges the threat relevant, but the obligation to report applies to major ICT-related incidents, not to threats. Recording significant cyber threats internally is required under Article 17.

Does an AI-enabled attack get reported through a different route?

No. DORA classifies incidents by their impact under Article 18, regardless of the method used. A deepfake-driven fraud and a conventional intrusion are graded on the same criteria and reported on the same forms. There is no separate AI incident category.

What if the incident originates at an ICT third-party provider?

The financial entity remains responsible for classifying and, where the threshold is met, reporting the incident. The provider relationship should already be captured in the DORA register of information, and third-party origin is a recurring theme: almost a third of the EU’s 2025 major incidents traced back to third parties.

Does the report change what goes into our register of information?

No. The register’s content is fixed by the DORA implementing standard, and a threat publication does not touch it. The report is a prompt to check that the concentration and supply-chain dependencies you already record are complete and current.

Related Articles

Key Takeaways

  • The CSIRT KNF report “Cyber Threat Landscape in the Polish Financial Sector 2026”, updated 9 July 2026, is supporting material. It creates no reporting obligation and changes no DORA template or deadline.
  • The value is that its author, CSIRT KNF, also runs Poland’s DORA incident-reporting channel, so the report is a proxy for what the supervisor expects firms to detect and classify.
  • DORA’s binding duties sit in Chapter III of Regulation (EU) 2022/2554: incident management under Article 17, classification under Article 18, and reporting under Article 19.
  • Major ICT-related incidents must be reported; significant cyber threats may be notified voluntarily under Article 19. Both must be recorded internally under Article 17.
  • The reporting clock under Commission Delegated Regulation (EU) 2025/301 runs 4 hours from classification (and no later than 24 hours from awareness), then 72 hours, then one month, so the classification step is where time is won or lost.
  • In Poland, entities file through SOID at csirt.knf.gov.pl, with an email fallback to incydenty.dora@knf.gov.pl that must be registered in the system once restored.
  • An AI-enabled attack is classified and reported like any other incident, on Article 18 impact criteria; the AI shift lands on detection and controls, and opens no new reporting track.
  • Third-party and concentration risk is the through-line: almost a third of the EU’s 3,383 major incidents in 2025 traced back to third parties, matching the KNF report’s supply-chain warnings.

Sources and References

  • CSIRT KNF, “Krajobraz cyberzagrozen w polskim sektorze finansowym 2026” (Cyber Threat Landscape in the Polish Financial Sector 2026), updated 9 July 2026: knf.gov.pl
  • CSIRT KNF, “Incydenty DORA” (DORA incident reporting via SOID): knf.gov.pl and csirt.knf.gov.pl
  • Regulation (EU) 2022/2554 (DORA), OJ L 333, 27.12.2022: eur-lex.europa.eu
  • Commission Delegated Regulation (EU) 2024/1772 of 13 March 2024 (RTS on classification of ICT-related incidents and cyber threats and materiality thresholds), OJ L, 2024/1772, 25.6.2024: eur-lex.europa.eu
  • Commission Delegated Regulation (EU) 2025/301 of 23 October 2024 (RTS on content and time limits for incident reports and voluntary threat notifications), OJ L, 2025/301, 20.2.2025: eur-lex.europa.eu
  • Commission Implementing Regulation (EU) 2025/302 of 23 October 2024 (ITS on forms, templates, and procedures to report major incidents and notify significant cyber threats), OJ L, 2025/302, 20.2.2025: eur-lex.europa.eu
  • Joint Committee of the ESAs, “2025 Report on major ICT-related incidents” (JC 2026 16), 3 June 2026, under Article 22 of DORA: eba.europa.eu
  • ESAs Statement on DORA application (JC 2024 99), 4 December 2024 (application from 17 January 2025; register of information timing): esma.europa.eu

Turning a supervisor’s threat map into filing discipline

A national threat report is only as useful as the questions it makes you ask before an incident forces them. CSIRT KNF has told the Polish market which attacks it expects to see in 2026 and which techniques it thinks are converging. The report changes none of your obligations, and reading it as a rule would be a mistake. Reading it as a rehearsal is the point. Run its scenarios through your Article 18 classification, time the walk to the four-hour clock, check that your register captures the concentration risks it warns about, and feed its named techniques into your next test. The filing machinery under DORA is already built and already running across the EU. What the report probes is whether your side of the SOID portal would recognise the attack in time to use it.

Last updated: July 2026

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts