You filed all three reports. You still have to tell your users.

Article 14 is usually described as three deadlines: twenty-four hours, seventy-two hours, and a final report. That framing is right about the filings and wrong about the obligation, because sitting underneath the three clocks is a fourth duty with no hour count attached to it, no field on the platform you file through, and nothing in the reporting workflow that will ever mention it to you.

The short answer

You must inform the users affected by the actively exploited vulnerability or the severe incident, without undue delay, and where necessary tell them what they can do about it.Art. 14⁠(8)⁠ This is not the same duty as reporting to your CSIRT and ENISA, it is not discharged by reporting to them, and it runs on its own schedule.

The platform has no field for it

This is the part that catches people, and it catches them in a specific way. The ENISA Single Reporting Platform is a form, and a form asks for what its operator needs to receive. The users you have to notify are not the platform's business, so the platform does not ask about them — and a filer who treats the form as the checklist has just finished a submission believing the obligation is closed.

We keep a field for it anyway, on our own side of the form, marked plainly as not being a platform field. It exists because the filing is not the only thing anyone will eventually want to see, and a record that says "notified customers on the 12th, by email, to the three affected release channels" is worth more in a later conversation than a submission reference is.

"Without undue delay" is not a number, and not an excuse

The Regulation gives the three filings hour counts. It gives this duty a standard.Art. 14⁠(8)⁠ The absence of a number is not the absence of urgency — it means the question asked afterwards will be whether the delay was justified by something, and "we were busy with the notification" is a poor answer given that the notification was about the same event.

The practical reading is that the user notice is a parallel track, not a fourth stage. The moment you have decided an event is reportable, two things start: the clock to the CSIRT, and the work of telling the people running your software. They are done by different people, usually, and they fail independently.

What a notice actually has to contain

Less than people fear, and it is a shape rather than a template: what the issue is, which versions it affects, what you have done about it, and what the reader should do. Four blocks. The middle two are the ones that are genuinely hard, because writing them honestly at hour six means admitting how much you do not yet know.

Our draft leaves those two as visible placeholders rather than filling them with plausible sentences, for the same reason the generated policy documents leave theirs visible: a notice that quietly invents a mitigation is worse than one that obviously still needs a human. The count of what is still missing is shown next to it.

Why we made it an artefact rather than a checkbox

A tick-box saying "users informed" proves nothing to anybody. The notice is stored as what it was — the body that went out, the channel it went out on, when, and who marked it sent — and it lands in the evidence pack beside the filings.

That is the whole argument for treating this duty as a first-class thing rather than a step in a runbook. The three filings have an external record: they exist on a platform, with a reference. The user notice has no external record at all. Whatever you keep is the only evidence that it happened, which makes it the one part of Article 14 where your own process is not merely helpful but is the entire proof.

The readiness questionnaire asks who owns this, among the twenty-eight questions — and it is one of the ones most often answered with a name nobody has told.