Article 14(8) says the maker must tell users about the CRA trigger. It may be a flaw under active attack or a severe event. When needed, the note must give steps users can take to reduce or fix the risk. Use a data form that a machine can read when apt.
Do not ask, “How much can we say?” Ask, “What does this user need to find the risk and act in a safe way?”
Lead with the product decision
Name the product, versions, setups, and use at risk as well as the proof allows. Give users a clear way to see if the note applies to them. If scope is still under review, state its current edge and the next update.
A risk label does not explain harm. State the result for the user in clear words. Keep proven harm apart from possible harm and facts not yet known.
Make every action executable
For each risk step or fix, state who should act and what they need first. Give the exact act, likely result, and key limit. Keep a short-term risk step apart from an update or lasting fix. Add a safe way back or a help route when needed.
Do not say “use best practice” or “watch closely.” If users cannot act yet, say so. Give the time or event for the next update.
Separate fact, risk, and instruction
Split the note into three parts. What did the maker see? What does the current check mean for the product? What should the user do?
Give each technical step an owner, tested versions, and needs. Add a way back or help rule when apt.
Do not ask users to make a one-way change from a weak product match. A fast short-term step may have costs or limits. Put them in the approved words. Do not leave support staff to explain them in new ways.
Plan the update path
Name the event that will cause the next note. It may be new scope, a ready fix, a changed risk step, or the end of the review. Name its owner and send route. “More news later” is not a plan.
When a fix is issued, link it to the old note and state what changed. Repeat any step users still need to take. Keep both copies and their user records.
Design for people and systems
Use a note that people can read as the main form. Check if the users also need fixed data that a machine can read. Keep IDs, versions, dates, and steps the same in both forms.
Give the note a stable ID, post time, version, and owner. When facts change, mark the new copy as an update. Keep the old copy. Record the users and send routes so the team can tell a draft from a sent note.
Before release, have a skilled reviewer run the steps in a test setup at risk. A good note is short because its scope and steps are exact. It does not hide key doubt.
Have a second reviewer read it as a user. Can they tell if their product is at risk? Can they find the first step, its limits, and the next update or help route? Keep the approved human and data forms together. Their IDs, versions, dates, and steps must match.
Continue this workflow with the impacted-audience decision and the delivery-evidence packet.