A draft notice does not meet the CRA duty to tell users. The maker must decide which users are at risk. It must give them useful steps to fix or reduce the risk. It also needs proof that its chosen routes reached the right users.
EU guidance sets a limit. Telling users does not mean that every detail must be made public or shared with all people.
Define the reachable audience
Start with the product and version map. List each type of user. These may include account owners, device owners, licence admins, and company security teams. They may also include sellers, service firms, package users, and people who did not sign in to get a file.
For each group, state why it is at risk and what it can do. Record the contact data or other route you have. Name the party that controls that route. Keep “contact not known” apart from “not at risk.”
Use the facts to decide whether to tell only users at risk or all users. Save the risk logic. The size of a mail list must not drive the choice.
Match channel to user action
Use routes that users trust for security news. These can include a signed-in alert, admin email, support site, public notice, or update screen. A seller can also pass on the note. A data feed may suit some users. Use more than one route if one cannot reach all users in time.
Give each middle party a fixed notice pack. Set the due time and define the users to reach. Give it a way to report results. A contract term is not proof that later users got the note.
Limit public detail if it would aid an attack or expose other secret facts. Still give users the product name, risk, and steps they can take.
Capture delivery evidence
Keep proof for each route. Save the approved note, target list, send time, and result. Keep the list of failed sends, any reply from a middle party, and the owner of the next try. Record what a signed-in user saw. A log that says a mail job ran is not enough.
For a public route, save proof that the page or feed went live. Keep the copy seen in a web cache and its change log. A view count does not prove that each user at risk was told.
Manage inaccessible users
Keep a queue for bad addresses, old admins, seller gaps, unused accounts, and old versions. Choose a fair next route and due time. Raise large gaps with security and legal teams. Do not close them without a record.
Send a new or revised note if the scope or fix changes. Link each copy to the new technical proof. State whether the user group also changed.
The final record should answer five points. Who needed the facts? Why were they chosen? What did the note say? How did the maker try to reach them? What did it do after a failed send?
Continue this workflow with the impacted-audience decision and the user-notice drafting workflow.