It is Monday, 9:07 a.m. A message from your national cybersecurity authority reaches your CISO: please provide evidence of the cybersecurity risk-management measures you have implemented. Do you have an answer ready, or does a week of panic begin?

By mid-October 2026, 24 of the 27 EU Member States have transposed NIS2 into national law, according to the ECSO NIS2 tracker, so supervisors increasingly have the legal power to ask. This guide explains what a NIS2 evidence pack is, what belongs in it, and how to build one in 30 days.

Why 2026 Is the Year to Become Audit-Ready

Directive (EU) 2022/2555, known as NIS2, had to be transposed by 17 October 2024. Most Member States missed that date, but 2026 closed much of the gap. Germany's law has applied since December 2025, the Netherlands' Cyberbeveiligingswet took effect on 15 August 2026 (see our NIS2 compliance support in the Netherlands), and Austria's NISG 2026 followed on 1 October 2026. France, Ireland and Spain still lacked a national law in recent trackers, so check your own Member State's status. Even so, group-wide customers and supply-chain contracts rarely wait for local legislation. Operating there? Review our pages on NIS2 in France and NIS2 in Ireland.

Under Article 32, authorities can run on-site inspections, security audits and scans, and request evidence that your policies are genuinely implemented. Essential entities face proactive supervision; important entities face reactive supervision after an incident or complaint. The Article 21 duties are the same for both.

The stakes are real. Member States must set maximum fines of at least €10 million or 2% of worldwide annual turnover (whichever is higher) for essential entities, and at least €7 million or 1.4% for important entities. Article 20 also makes management bodies answerable for approving and overseeing the measures, and authorities can temporarily bar individuals from management roles in essential entities.

What Is a NIS2 Evidence Pack?

A NIS2 evidence pack is one indexed, version-controlled set of records that proves, control by control, that your obligations are met and working. It is the answer to every question a regulator might ask, stored so your team can produce it in hours, not weeks.

The NIS2 Compliance Checklist: 8 Things Your Evidence Pack Needs

Give every item an owner, date, version and review cycle. For evidence rows 7 and 8, independent penetration testing and a vulnerability assessment produce exactly the dated proof supervisors like to see.

Show That It Works, Not Just That It Exists

Policies earn half the marks. Supervisors want operating evidence: approvals, test results, tickets and logs showing controls ran during the period. Article 21 requires measures that are appropriate and proportionate, so record your reasoning (size, sector, exposure) beside each decision.

An ISO 27001 programme is a strong foundation, but certification alone does not prove NIS2 compliance, so map each control to the Article 21 measures. Financial entities should also align with DORA, the sector-specific regime for ICT risk and incident reporting, while one incident can also start the GDPR 72-hour clock. Cut duplicated effort with our guide to NIS2 and GDPR compliance, or run frameworks together through Audit Fusion 360. Board members who need a clear briefing can use CISO advisory services.

Three Evidence Mistakes That Slow Audits Down

First, stale documents: a policy last reviewed in 2023 signals that nobody owns it. Second, scattered proof: evidence spread across inboxes and personal drives cannot be produced quickly. Third, untested plans: an incident procedure nobody has rehearsed will not survive a 24-hour deadline. Fix these three and most supervisory requests become routine.

Watch the Horizon: NIS2 Is Being Amended

On 20 January 2026, the European Commission proposed targeted amendments to NIS2 alongside a revised Cybersecurity Act, building on the Digital Omnibus package of 19 November 2025, which aims to simplify incident reporting. These proposals are still moving through the legislative process, so today's obligations apply in full. Build your pack in modular form so it can adapt.

Build Your Pack in 30 Days

1. Week 1: confirm scope, entity type and national authority; run a gap analysis against Article 21.
2. Week 2: close governance and incident-response gaps; collect board approvals.
3. Week 3: test, running a tabletop exercise, a backup restore and a vulnerability scan.
4. Week 4: assemble the index, then run a mock regulator request and time your response.

NIS2 Evidence Pack FAQ

Who needs a NIS2 evidence pack? Every in-scope essential and important entity, because supervisors can request proof of Article 21 measures.

Does NIS2 apply outside the EU? It can, when you provide in-scope services within the EU. Check Member State rules and your regulatory exposure. German-speaking teams can also download the NIS2 Readiness Guide für deutsche Unternehmen.

Sources: Directive (EU) 2022/2555, EUR-Lex; ECSO NIS2 Transposition Tracker; Covington, Commission NIS2 amendment proposal. Informational only, not legal advice; national laws vary.

Scroll through any European feed today and a quiet question hangs over every image, voice and chat bubble: was a human behind this? Since 2 August 2026, EU law expects an honest answer. EU AI Act Article 50, the rule behind AI labelling and AI transparency obligations, is now live, and developers shipping chatbots, image generators or synthetic media to EU users sit on the front line. Here is what it demands, what changed this year, and a practical checklist you can run against your product this week.

What Is EU AI Act Article 50?

Article 50 of Regulation (EU) 2024/1689 sets transparency duties for AI systems that talk to people or create content. It applies whether or not a system is classed as high-risk, so even a simple marketing chatbot is in scope. It contains four core duties, plus a rule on how disclosures must look and when they must appear:

• Article 50(1): providers must design AI systems that interact with people so users are told they are dealing with AI, unless that is obvious from context.
• Article 50(2): providers of systems generating synthetic audio, images, video or text must mark outputs in a machine-readable format so they are detectable as AI-generated or manipulated.
• Article 50(3): deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them.
• Article 50(4): deployers must disclose deepfakes, and AI-generated text published to inform the public on matters of public interest.
• Article 50(5): disclosures must be clear, distinguishable, accessible, and given at the latest at first interaction or exposure.

Was Article 50 Delayed by the Digital Omnibus? Mostly No

This is the question developers keep asking, and the answer matters. The Digital Omnibus on AI, in force since 27 July 2026, postponed high-risk obligations: Annex III systems now follow on 2 December 2027, and AI embedded in regulated products (Annex I) on 2 August 2028. Article 50 was not postponed and has applied since 2 August 2026.

There is one narrow exception. For generative systems already on the EU market before 2 August 2026, the Article 50(2) machine-readable marking duty applies from 2 December 2026. Anything placed on the market from 2 August 2026 must comply from day one. With that date less than two months away, treat the grace period as a countdown, not a reprieve.

Provider or Deployer? Know Your Role

Providers build AI systems or place them on the market; deployers use them under their own authority. Many teams are both. A SaaS company that fine-tunes a model and embeds it in its product is a provider for Articles 50(1) and 50(2), and a deployer for 50(4) when it publishes outputs itself. Map your role per feature, not per company.

The AI Labelling Checklist for Developers

1. Inventory every AI touchpoint. List chatbots, voice agents, image, video, audio and text generators, and any emotion or biometric features. You cannot label what you have not found.
2. Disclose AI interaction by design (50(1)). Show a clear "you are talking to an AI" notice at or before the first message. Skip it only where context makes AI use genuinely obvious, and document why.
3. Apply machine-readable marking (50(2)). Embed watermarks, metadata or equivalent signals into generated audio, image, video and text. Aim for solutions that are effective, interoperable, robust and reliable as far as technically feasible. Assistive editing that does not substantially alter the input is carved out.
4. Make marks detectable. A mark nobody can read is a failed control. Test that your signals survive compression, cropping and format conversion, and that detection works for third parties.
5. Label deepfakes visibly (50(4)). Where your product publishes realistic synthetic media, add a clear visible or audible disclosure. For evidently artistic, creative, satirical or fictional works, disclosure can be lighter so it does not spoil the experience.
6. Flag AI text on public-interest topics. Published AI-generated text that informs the public needs a label, unless a human has reviewed it and a person holds editorial responsibility. Record that review.
7. Notify people exposed to emotion recognition or biometric categorisation (50(3)). Pair the notice with GDPR-compliant processing.
8. Make disclosures timely and accessible (50(5)). Show them at first exposure, in plain language, and in formats everyone can use. Audio-only content needs an audio disclaimer.
9. Log, test and document. Keep evidence of design decisions, marking tests and review workflows. Include your marking and disclosure flows in security testing so they cannot be stripped or spoofed easily.

Your Shortcut: The Code of Practice and Commission Guidelines

Two official resources make life easier. The European Commission published the final Code of Practice on marking and labelling AI-generated content on 10 June 2026. It is voluntary, and the Commission and the AI Board have assessed it as adequate, so signatories can rely on it to demonstrate compliance. On 20 July 2026, the Commission added non-binding guidelines that explain scope, with practical examples for each Article 50 duty. Read both before you finalise your design.

What Happens If You Ignore It?

Breaches of Article 50 can draw administrative fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher; for SMEs and start-ups the lower amount applies. National authorities enforce the rules, and unlabelled synthetic content also puts customer trust at risk in a market that already expects strong data protection.

Turn the Checklist Into Compliance Evidence

A checklist is a start; evidence is what regulators and enterprise buyers ask for. VISTA InfoSec's EU AI Act compliance services can help you scope your obligations and close gaps, and the EU AI Act compliance checklist offers a wider walkthrough. Because AI systems process personal data, align your labelling work with GDPR compliance consulting and the AI and GDPR preparation expert roundup.

Finally, prove your controls hold up. Penetration testing can show whether your marking and disclosure flows can be bypassed, while ISO 27001 consulting gives you a management system to keep them governed. Ready to move? Book a free compliance consultation and turn Article 50 from a risk into a trust signal.

Since 11 September 2026, a new regulatory clock has been running for every manufacturer selling connected products in the EU. The Cyber Resilience Act (CRA) reporting duties are now live, and they sit on top of NIS2, DORA and GDPR obligations your security team already juggles. One incident can now trigger four different deadlines, four recipients and four sets of wording. If your incident response runbook still treats them as one generic "notify the regulator" step, this guide is for you.

Why CRA incident reporting changes your runbook now

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its main requirements apply from 11 December 2027, but the reporting obligations for manufacturers arrived much earlier: 11 September 2026. That includes products already on the EU market, not just new launches.

Manufacturers of products with digital elements, such as connected devices, software and components, must report two things: actively exploited vulnerabilities and severe incidents that affect the security of their product. Reports go through the ENISA single reporting platform, which routes them to the CSIRT designated as coordinator and to ENISA.

CRA, NIS2, DORA and GDPR deadlines at a glance

The pattern is clear: 24 hours is the new baseline, and DORA is the strictest of all. A fintech that ships its own connected app could face every one of these at once.

What counts as reportable under the CRA?

Two triggers matter. The first is a vulnerability in your product that is being actively exploited, meaning there is reliable evidence that a malicious actor used it without the system owner's permission. The second is a severe incident with an impact on the security of your product. A theoretical flaw found in testing is not reportable on its own; one seen in the wild is.

The CRA reporting clock also starts at awareness, not at confirmation of full root cause. Your team needs authority to file an early warning before the investigation is finished.

6 steps to update your incident response runbook

1. Build one triage decision tree. Ask the same questions once: Is a product vulnerability exploited? Is personal data affected? Is a financial ICT service disrupted? Is an essential or important service impacted? Each "yes" activates a regulation-specific track.
2. Start separate clocks. Log the "awareness" timestamp and run parallel timers for 4 hours (DORA), 24 hours (CRA, NIS2) and 72 hours (CRA, NIS2, GDPR). Document who decides that an incident is "major" or "significant" and how quickly.
3. Assign named roles with deputies. Incident commander, legal and DPO, product security lead and regulatory submitter, each with a backup for weekends and holidays.
4. Pre-write report templates. Keep early-warning, notification and final-report drafts ready for each regime so analysts fill in facts instead of drafting prose under pressure.
5. Prepare platform access. Make sure the right people can use the ENISA single reporting platform and national authority portals before you need them.
6. Test it. Run a tabletop exercise that mixes a CRA vulnerability with a GDPR breach. Measure how long it takes to produce a defensible first report.

Common mistakes to avoid

• Waiting for certainty. Early warnings exist precisely because facts are incomplete.
• Ignoring suppliers. Your open-source components and third-party code can be the source of an exploited vulnerability. Keep an up-to-date software bill of materials (SBOM) and clear vendor notification clauses.
• Inconsistent messaging. Regulators compare notes. Use a single fact sheet as the source for every submission.
• Forgetting users. The CRA expects manufacturers to inform affected users about incidents and the corrective measures available.

Penalties: why this is a board-level issue

The stakes are real. GDPR fines reach up to €20 million or 4% of global annual turnover. NIS2 allows up to €10 million or 2% for essential entities and €7 million or 1.4% for important ones. Breaching CRA essential requirements can cost up to €15 million or 2.5% of worldwide turnover, and failing other CRA obligations, including reporting, up to €10 million or 2%. Supplying incorrect information to authorities carries its own penalty.

Frequently asked questions

Does CRA incident reporting replace NIS2 or GDPR reporting?
No. The CRA covers product security, while NIS2 covers entity-level incidents and GDPR covers personal data breaches. One event can trigger all of them, so your incident response plan must run them in parallel.

Is a single EU reporting channel coming?
The European Commission has proposed simplifying incident reporting through a single entry point as part of its digital simplification agenda, but proposals can change. Until a final law applies, keep separate obligations in your runbook and monitor official EU sources.

Final thoughts

CRA incident reporting is not a future problem. It is live, overlaps with NIS2, DORA and GDPR, and rewards organisations that decide fast and document well. Update your triage logic, pre-build your templates and rehearse. Then talk to VISTA InfoSec about turning your runbook into an audit-ready compliance asset.

This article is for general information, not legal advice. Deadlines and national rules can change; confirm current requirements with your legal counsel and official EU and national authority guidance.

Two standards. One regulation. And a certificate that may not mean what your board thinks it means.

If you build, sell or deploy AI in Europe, 2026 has handed compliance teams a new dilemma: certify to ISO 42001 now, or organise everything around EN 18286, the first standard written specifically for the EU AI Act? The honest answer is that they do different jobs, and only one of them is aimed squarely at the law. Here is what is confirmed, what is still pending, and how to plan around both.

What Is EN 18286?

EN 18286:2026, titled Artificial intelligence – Quality management system for EU AI Act regulatory purposes, was prepared by CEN/CLC/JTC 21 under the European Commission's standardisation request M/613 and approved by CEN-CENELEC on 12 July 2026. CEN-CENELEC describes it as the first harmonised European standard supporting the AI Act, and it is not tied to any single sector.

Its job is narrow and important: it turns Article 17, the quality management system (QMS) duty for providers of high-risk AI systems, into auditable requirements. Its Annex ZA, the section that links a standard to the law, covers Article 17(1) and the first sentence of Article 11(1).

What Is ISO 42001?

ISO/IEC 42001:2023, published in December 2023, is the world's first certifiable AI management system (AIMS) standard. It follows the same harmonised structure as ISO 27001, so it slots neatly beside an existing security programme, and any organisation that develops, provides or uses AI can adopt it. Certification is voluntary and third-party audited. However, it is not a harmonised standard under the AI Act, so a certificate alone gives no legal presumption of conformity.

EN 18286 vs ISO 42001: Key Differences

The Catch: No Presumption of Conformity Yet

Under Article 40 of the AI Act, a provider that follows a harmonised standard gets a presumption of conformity with the requirements it covers, but only once the Commission cites that standard in the Official Journal of the European Union. In the latest public checks we found (August 2026), EN 18286 was published but not yet cited, and CEN-CENELEC has said the reference is expected later in 2026. Verify the current status before briefing your board.

Two practical consequences follow. Until citation, EN 18286 is not a legal safe harbour, yet it is the clearest preview of what regulators and notified bodies will expect. And even after citation it covers only part of the Act, so other obligations still need their own evidence.

Digital Omnibus: More Time, Not Less Work

The Digital Omnibus on AI has been in force since 27 July 2026. It moved the stand-alone high-risk (Annex III) deadline from 2 August 2026 to 2 December 2027, and high-risk AI embedded in regulated products (Annex I) to 2 August 2028. The telling reason: harmonised standards and national authorities were not ready.

Do not mistake this for a pause. Prohibited practices and AI literacy duties already apply, general-purpose AI obligations are unchanged, and Article 50 transparency rules have applied since 2 August 2026, with a grace period to 2 December 2026 for machine-readable marking on generative systems already on the market. Fines for prohibited practices can reach €35 million or 7% of global turnover. For European buyers and regulators, documented readiness now is fast becoming a trust signal, not just a legal checkbox.

Do You Need Both? Usually, Yes

Think of it this way: ISO 42001 is your organisation-wide AI governance engine; EN 18286 is the regulator-facing QMS blueprint. EN 18286 even includes annexes relating it to ISO 9001 and ISO/IEC 42001, a sign that Europe expects the standards to coexist rather than compete. Building once and mapping twice saves both budget and audit fatigue.

For most providers, the smartest sequence is to build an AIMS on ISO 42001 now, since enterprise buyers recognise it and it reuses your ISO 27001 scaffolding, then gap-assess it against EN 18286. VISTA InfoSec's guide to EU AI Act vs ISO 42001 explains why a certificate never replaces conformity assessment, CE marking or registration duties.

Your 5-Step Plan for 2026

1. Inventory every AI system, including AI hidden inside SaaS tools. This EU AI Act compliance checklist shows how.
2. Confirm your role and risk class: provider, deployer, importer or distributor, and whether anything is high-risk.
3. Stand up an AIMS with expert ISO 42001 certification support.
4. Gap-assess against EN 18286 (clauses 4–10) and document evidence for Articles 11 and 17.
5. Track the Official Journal and re-baseline your roadmap to December 2027, using these 10 EU AI Act readiness controls as a working list.

FAQs

Final Thoughts

EN 18286 is the standard built for the EU AI Act; ISO 42001 is the governance foundation that gets you there faster. Start with ISO 42001, map to EN 18286, keep evidence audit-ready, and treat the Omnibus extension as runway, not relief. Ready to turn standards into evidence? Talk to the team at VISTA InfoSec, whose European engagements run through Zulon Audits OÜ, and request an EU AI Act readiness review.

If your organisation has rolled out an AI chatbot, an automated underwriting tool, or an AI-assisted hiring workflow in the last two years, your insurer has almost certainly started asking harder questions about it. Across Europe, cyber insurance renewals in 2026 look nothing like they did even eighteen months ago. Insurers have stopped treating “AI risk” as a footnote buried inside a general cyber policy and started treating it as its own underwriting category with its own exclusions, its own evidence requirements, and its own pricing logic.

At the centre of that shift sits ISO/IEC 42001, the world’s first certifiable standard for an Artificial Intelligence Management System (AIMS). What started as a governance framework for responsible AI development is quickly becoming the reference point underwriters use to decide who gets favourable AI liability insurance terms and who gets an exclusion clause instead.

Why cyber insurers are rewriting the rules for AI

For years, AI exposure quietly rode along inside standard cyber and general liability policies. That’s changing fast. Several major carriers have introduced dedicated AI exclusion language across general liability, errors and omissions, and directors and officers lines, while cyber remains the more stable line for AI risk though even there, coverage is fragmenting through narrower definitions rather than blanket exclusions.

What underwriters are really asking for isn’t proof that your AI is perfect. It’s a paper trail: evidence that testing happened, that someone reviewed the results, and that someone with the authority to do so signed off. Organisations that scramble at renewal time usually have done the testing they just never documented who looked at it or when. That documentation gap is now the single biggest driver of AI-related coverage disputes and premium increases.

Underwriting has also moved from a one-off application form to something closer to continuous assessment. Insurers increasingly score an applicant’s AI governance maturity documentation, red-team testing, model lifecycle management, access controls, and auditability against frameworks like the NIST AI Risk Management Framework and ISO/IEC 42001, and that score can move between renewals. A “yes” that your own telemetry contradicts is now considered worse than an honest “no.”

What ISO 42001 actually proves to an underwriter

ISO 42001 doesn’t promise your AI systems are flawless. What it does provide is exactly the paper trail insurers are asking for: a structured AI Management System covering AI policy and objectives, internal roles and accountability, AI impact assessments, lifecycle management from design through decommissioning, data governance, and oversight of third-party AI tools and vendors.

That structure maps closely onto what a cyber insurance AI rider now typically expects: a written AI acceptable-use policy, a live inventory of every AI tool in use (including “shadow AI” employees adopt without IT’s knowledge), monitoring of AI use, controls that stop confidential data leaking into AI tools, human oversight for anything agentic or autonomous, and a documented AI risk assessment. You don’t strictly need certification to answer these questions but being able to hand an underwriter a certified AIMS, rather than a folder of ad hoc policies, changes the conversation considerably. Certified organisations have reportedly been able to negotiate premium discounts in the region of 15–25% on AI liability cover compared with uncertified peers, precisely because the certification removes so much of the underwriter’s guesswork.

The European angle: ISO 42001, the EU AI Act, and the compliance stack

For organisations operating in or selling into Europe, ISO 42001 doesn’t sit in isolation it slots directly into an already crowded regulatory stack. The EU AI Act’s high-risk obligations, originally due from 2 August 2026, have since been formally deferred: the Digital Omnibus on AI (Regulation (EU) 2026/1744) entered into force on 27 July 2026, days ahead of that original deadline, pushing standalone high-risk systems under Annex III to 2 December 2027, and AI embedded in already-regulated products under Annex I to 2 August 2028. That’s a genuine breathing space, but not a pause button prohibited practices, GPAI model obligations, and the AI literacy requirement remain on their original timelines, and insurers are not waiting for enforcement to start pricing risk.

That’s exactly where ISO 42001 earns its keep for European organisations: it’s built to complement, not compete with, ISO 27001, GDPR, NIS2, and DORA. Financial institutions already managing DORA’s ICT risk requirements, or critical-sector businesses working through NIS2, will find ISO 42001’s governance, risk, and lifecycle structure familiar it follows the same Annex SL backbone as ISO 27001, which makes integration into an existing management system considerably less painful than building an AI governance programme from a blank page.

What this means for your 2026 renewal

Whether or not you pursue full certification this year, a few moves will materially change how your next cyber insurance conversation goes:

• Build the AI inventory first. One spreadsheet listing every AI tool in use, what data it touches, and who owns it answers more underwriting questions than almost anything else.
• Write down the human oversight. For any agentic or autonomous AI process, document who can intervene, and under what authority.
• Pull your current policy and read the definitions. Look specifically for “AI,” “condition precedent,” and any control you’re contractually required to maintain — that’s your real to-do list before renewal.
• Map your AI risk assessment to a recognised framework. Whether that’s the NIST AI RMF or ISO 42001 itself, alignment gives your broker something concrete to present to underwriters.
• Treat ISO 42001 as an extension of your existing ISMS, not a parallel project — especially if you’re already ISO 27001 certified or working through NIS2 and DORA obligations.

Where Vista Infosec fits in

As a CREST-accredited cybersecurity and compliance consultancy working across Europe, the UK, the US, and Asia, Vista Infosec helps organisations build AI governance programmes that stand up to both regulatory scrutiny and insurer due diligence. Whether you’re starting an ISO 42001 certification journey, aligning AI governance with an existing ISO 27001 information security management system, or working through overlapping EU AI Act, NIS2, and DORA obligations, the right documentation trail does double duty — it satisfies your regulator and it gives your insurance broker something real to negotiate with.

17 January 2028 sounds a long way off. For any EU financial entity designated for DORA TLPT (Threat-Led Penetration Testing), it isn't. Once you account for provider scarcity, regulatory scoping, and a testing cycle that runs 9 to 14 months on its own, the real deadline that matters is 2026 — because that is when procurement has to begin.

If your bank, insurer, investment firm, or payment institution has received a designation notice from your National Competent Authority (NCA), this article breaks down exactly what Threat-Led Penetration Testing under DORA Article 26 requires, why the timeline is tighter than it looks, and what to do about it right now.

What Is DORA TLPT, Exactly?

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has been in force across the EU since 17 January 2025. Among its five pillars — ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing — Article 26 and Article 27 introduce the most demanding obligation of all: Threat-Led Penetration Testing, modelled directly on the European Central Bank's TIBER-EU framework.

Unlike a standard vulnerability scan or annual penetration test, TLPT is an intelligence-led, covert red team exercise run against your live production environment. Your own security operations team is not told it is happening. A licensed threat intelligence provider first builds a Targeted Threat Intelligence (TTI) report profiling the real adversaries most likely to target your institution — nation-state actors, organised financial cybercrime groups, or insider-threat scenarios. An accredited red team then executes those exact attack scenarios against your critical or important functions, including outsourced and cloud infrastructure, for a minimum of 12 weeks.

TLPT is not optional and it is not self-selected. Your NCA designates you based on systemic importance, asset size, and criticality to the financial system. Once designated, the obligation repeats at least every three years, and no generic penetration test can substitute for it.

The 2028 Deadline — And Why It's Already Close

The first mandatory TLPT cycle under DORA must be completed by 17 January 2028. On paper, that is more than a year away from today. In practice, a full engagement — provider procurement, scope agreement with your competent authority, the threat intelligence phase, the red team campaign, purple teaming, remediation, and final attestation — typically takes between 9 and 14 months once everything is running smoothly.

Typical DORA TLPT Timeline

Work backwards from January 2028 and the math is unforgiving: procurement should realistically start in 2026, not 2027. Entities that wait until designation pressure builds risk being left with whatever accredited provider capacity remains — often at a premium, and often without the specialist industry experience their scope actually needs.

What Happens If You Miss the Deadline?

Missing the 2028 deadline, running a poorly scoped test, or failing to remediate critical findings on the agreed timeline all expose an institution to enforcement action under DORA Article 50, including financial penalties tied to global annual turnover and operational restrictions imposed by supervisors. For designated entities, TLPT sits alongside the broader resilience testing programme required under Article 25 — but it carries a legal weight and reputational visibility that an annual vulnerability scan does not.

How to Prepare Now

• Confirm designation status with your NCA and don't assume you're out of scope simply because you haven't been formally notified yet.
• Start provider procurement in 2026 — evaluate TIBER-EU accredited threat intelligence and red team providers before capacity dries up.
• Map critical and important functions, including third-party and cloud dependencies, ahead of scoping discussions.
• Run standing red team and continuous penetration testing programmes so TLPT becomes a checkpoint rather than a scramble.
• Align TLPT with your wider DORA programme — ICT risk management, incident reporting, and third-party risk registers all feed into a credible scope document.

This is exactly where experienced penetration testing services earn their keep well before the formal TLPT clock starts. A mature, continuous testing programme built on CREST-approved methodology gives your institution a defensible baseline while you queue for accredited TLPT capacity. VistaInfoSec's broader guidance on common DORA compliance challenges is a useful starting point if you're still building out your resilience testing roadmap.

It's also worth understanding how TLPT fits alongside your other frameworks. If your institution already holds ISO 27001 or SOC 2, this DORA, ISO 27001 and SOC 2 mapping guide shows exactly where DORA's testing requirements go beyond what those certifications already cover. And if NIS2 obligations apply to any part of your group alongside DORA, this NIS2 vs DORA compliance guide untangles where the two regulations overlap and where they diverge.

The Bottom Line

DORA TLPT isn't a 2028 problem — it's a 2026 decision. The financial entities that treat threat-led penetration testing as a checkpoint within an already-mature security testing programme will move through designation, scoping, and attestation calmly. Those that wait will be negotiating with whatever accredited provider has a slot left, on someone else's timeline. For EU financial institutions serious about operational resilience, the smartest move this year is simple: start the conversation with accredited providers now, not in Q4 2027.

Three months of "not yet live" updates end this week. ENISA has scheduled the Single Reporting Platform (SRP) — the mandatory channel for Cyber Resilience Act incident and vulnerability notifications — to go operational on 11 September 2026, the exact date Article 14 reporting duties enter into application. For European developers, product security teams, and manufacturers placing connected products on the EU market, this is no longer a compliance deadline on a roadmap slide. It is a live, 24-hour regulatory clock.

If your team builds IoT devices, embedded firmware, industrial controllers, or software with a network connection sold anywhere in the EU, this article breaks down exactly what the Cyber Resilience Act (Regulation (EU) 2024/2847) requires you to report, when, and through which channel — without the guesswork.

What Is the ENISA Single Reporting Platform?

The Single Reporting Platform is the electronic entry point established under Article 16 of the CRA. Instead of notifying multiple national authorities separately, a manufacturer files one report through the SRP, which then routes it simultaneously to the national CSIRT designated as coordinator for the manufacturer's main EU establishment, and to ENISA itself.

Crucially, ENISA has confirmed that no reporting API will be offered at this stage. Submissions go through a browser-based interface, authenticated via EU Login, the European Commission's shared sign-in credential. Internal detection and triage workflows can be automated, but the final act of filing is manual. Teams that assumed system-to-system integration would carry them through launch week need to rebuild that assumption immediately.

What Developers Must Actually Report Under Article 14

Article 14 does not ask you to report every bug ticket. It creates two distinct reporting tracks, and understanding the difference is the single most important thing a developer or product security lead can do before touching the platform.

1. Actively exploited vulnerabilities. If a vulnerability in your product with digital elements is being exploited in the wild — not theoretical, not internally discovered during a code review, but actually under active exploitation — you are obligated to notify ENISA and your coordinating CSIRT.

2. Severe incidents having an impact on the security of the product. This covers incidents that materially affect the product's ability to protect the confidentiality, integrity, or availability of data or functions.

For both tracks, the CRA imposes a rigid three-stage timeline:

• 24 hours — an early warning, submitted as soon as the manufacturer becomes aware.
• 72 hours — a more detailed notification confirming severity, indicators of compromise, and corrective measures underway.
• 14 days — a final report once the vulnerability or incident is resolved, including a root-cause assessment.

This is precisely why compliance specialists have been urging manufacturers to treat the reporting obligation as a distinct, earlier milestone from the CRA's broader December 2027 conformity deadline. VISTA InfoSec's detailed Cyber Resilience Act compliance checklist walks through exactly how to sequence this preparation across scoping, documentation, and reporting readiness.

Who Is on the Hook — and Who Isn't

Manufacturers carry almost the entire reporting burden. Importers and distributors have separate, narrower duties around conformity verification and CE marking, but the 24/72-hour reporting clock sits squarely with the manufacturer of the product with digital elements. Open-source software stewards also fall within ENISA's guidance and should register and validate on the SRP only when they have an actual notification to file, to avoid overloading national CSIRT teams during the launch window.

For manufacturers not established in the EU, the coordinating CSIRT is determined by the country of the manufacturer's authorised representative — not by where the company is headquartered. This detail catches non-EU vendors off guard more often than any other part of Article 14.

What Developers Should Prepare Before Filing a First Report

Even with the platform now operational, several practical gaps remain open. The official reporting data format is set by a separate European Commission implementing act, and full registration handbooks, dry-run environments, and the finalised list of national CSIRT coordinators have been rolling out only in the weeks immediately before launch.

What development and product security teams can control right now:

• Create EU Login accounts in advance for a primary and secondary organisational representative, using durable work email addresses.
• Maintain a live product inventory mapping every shipped SKU to a manufacturer identity, an SBOM, and a named PSIRT contact.
• Build (and rehearse) the internal detection-to-decision workflow that determines, within hours, whether an event meets the "actively exploited" or "severe incident" threshold.
• Name a reporting owner and a documented backup, since the 24-hour clock does not pause for someone being on leave.
• Run a full dry-run submission the moment ENISA's test environment is accessible, rather than waiting for a real incident to be your team's first encounter with the interface.

Because classification (Default, Important I, Important II, or Critical under Annex III/IV) determines both your conformity route and how deep your documentation needs to go, organisations still mapping their product portfolio against these categories should not wait. VISTA InfoSec's Cyber Resilience Act gap assessment guide is a useful reference for structuring that inventory and documentation work alongside reporting readiness, rather than treating them as separate projects.

Penalties Make This Non-Negotiable

Non-compliance with the CRA carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher — figures that place it firmly alongside GDPR and NIS2 in terms of enforcement weight. For a regulation whose full conformity requirements do not bite until December 2027, it is notable that the reporting obligation — arguably the operationally hardest part to get right under time pressure — is the piece that started first.

The Bottom Line for European Developers

The SRP going live does not mean your compliance work is finished; it means the clock that actually matters has started. Article 14 rewards organisations that have already separated "actively exploited vulnerability" from routine bug triage, pre-built their EU Login access, and rehearsed their escalation path. Teams still treating CRA reporting as a 2027 problem are now operating under a live regulatory deadline with real financial exposure.