A 24-hour reporting deadline is not met by reading the regulation when something happens. It is met by having a short list of things already in place, most of which take an afternoon each.
Start with a monitored intake path for security reports, published where a researcher will actually look: a security.txt file, an address on the product page, and a mailbox that more than one person reads. Then name the person who owns the clock, and a deputy, because the first notification is due in a day and that day may be a Saturday. Register on the reporting platform before you need it rather than during an incident.
Next, make your own product searchable. If you cannot answer “which shipped firmware versions contain this library” in an hour, you cannot write an accurate notification in a day. A software bill of materials per release, stored somewhere queryable, is what turns that question into a lookup. Keep a build archive that lets you reproduce any version still in the field.
Finally, write the decision rule and the template now. The rule says who decides that a vulnerability is being actively exploited and on what evidence; getting that wrong in either direction is costly. The template holds the fields an early warning needs, so the first filing is an exercise in filling gaps rather than in composition. Rehearse it once against a vulnerability you have already fixed, and you will find out which of these eight things you do not really have.