After awareness of a CRA trigger, a maker must tell users at risk. The trigger may be a flaw under active attack or a severe event that harms product security. When apt, the maker must tell all users. The note should include risk steps and fixes users can apply when needed.
This user duty is apart from reports to an authority. A filed report does not close it.
Define the audience from product evidence
Start with the products, versions, setups, and use at issue. Map them to users or groups with the proof on hand. Record the rule used to include a user, each data source, gaps, and the approver.
If exact user names are not known, decide if a broad note is apt. Do not shrink the group because contact data is hard to get. Do not call users at risk when proof rules them out.
Use three states for users. Mark them at risk, possibly at risk after a named check, or out of scope with proof. Save the product or version rule for each group. A large user list is just a way to send. It is not the risk check.
If scope changes, keep the first user choice. Name the users who need a new note. Do not edit a list after a note was sent.
Coordinate the notice with response work
The note owner needs current scope, seen risk, user steps, and a help route. Security and message teams should use the same approved facts. Legal staff should check the time and secret facts. Save each version so later fixes stay clear.
Keep the send route, user rule, words, send time, proof of delivery, and follow-up. If you use several routes, record what each user group got.
Treat timing as its own decision
Open the user-note task when the Article 14 trigger is met. Do not wait for the authority filing to close. Name owners for the user group, words, secret-data check, send, and support reply. Show note status next to report clocks. Keep its approval path apart.
If facts have gaps, decide what checked facts users need now. State which point will need an update. Do not hold back a useful step while you polish the story. Do not send a step the code team has not checked for the versions at risk.
Keep the authority fallback visible
Article 14(8) gives main CSIRTs a backup power. They may tell users if the maker fails to do so in time. Their act must be fair and needed to prevent or cut harm. This is not the maker’s message plan.
Assign the user-note task when the report case opens. Track it to a result backed by proof. Its owner should differ from the person who closes the site filing.
The final pack should show the approved user rule, note copy, route, send time, and delivery proof. Add failed sends and the follow-up owner. Text alone does not show who was told.
Continue this workflow with the user-notice drafting workflow and the delivery-evidence packet.