Article 14(8) requires the manufacturer to tell users about the relevant actively exploited vulnerability or severe incident. Where necessary, the notice must also explain risk-mitigation and corrective measures that users can deploy. A structured, easily automatically processable machine-readable format is called for where appropriate.
The useful drafting question is not “How much can we say?” It is “What does this audience need to identify exposure and act safely?”
Lead with the product decision
Name the affected product, versions, configurations, and deployment conditions as precisely as the evidence permits. Give users a practical way to determine whether the notice applies to them. If scope remains under investigation, state the boundary and the next update point.
Do not use a severity label as a substitute for impact. Describe the user-relevant consequence in controlled language, separating confirmed effects from credible possibilities and unknowns.
Make every action executable
For each mitigation or corrective measure, state who should act, the prerequisite, the exact action, the expected outcome, and any material limitation. Distinguish a temporary mitigation from a security update or permanent correction. Include a safe rollback or support route when one is needed.
Avoid vague instructions such as “apply best practices” or “monitor closely.” If no user action is currently available, say that directly and provide the time or condition for the next update.
Separate fact, risk, and instruction
Structure the notice so a reader can distinguish what the manufacturer observed, what the current assessment means for the affected product, and what action the user should take. Give every technical instruction an owner, tested version range, prerequisite, and rollback or support condition where applicable.
Do not ask users to make an irreversible change based on a tentative product match. If an urgent temporary mitigation has costs or limitations, state them in the approved instruction rather than leaving support staff to explain them differently.
Plan the update path
Name the event that will produce the next notice: a confirmed scope change, available correction, changed mitigation, or closed investigation. Assign its owner and expected communication route. “More information later” is not an operational update plan.
When a correction is issued, link it to the earlier notice, state what changed, and repeat any action the user still needs to take. Preserve both versions and their audience records.
Design for people and systems
Use a human-readable notice as the primary communication and assess whether the affected audience also needs structured machine-readable information. Keep identifiers, versions, dates, and actions consistent across both forms.
Give the notice a stable identifier, publication time, version, and owner. When facts change, publish a clearly marked update and retain the earlier version. Record the audience and channels used so the response team can distinguish drafting from delivery.
Before release, have a technically qualified reviewer execute the instructions against an affected test environment. The best notice is concise because its scope and actions are precise, not because important uncertainty was removed.
Have a second reviewer read the notice as the intended user. They should be able to determine whether the product is affected, identify the immediate action, understand any limitation, and find the next update or support route. Record the approved human-readable and structured versions together so their identifiers, versions, dates, and actions remain aligned.
Continue this workflow with the impacted-audience decision and the delivery-evidence packet.