28/09 edition: a security advisory must let its recipient act

Write for the recipient, not the publisher

This edition addresses product security, documentation and manufacturer support. It asks whether a recipient can act correctly from an advisory. This is a retrospective editorial proposal, not a communication about a product affected on 28 September. It contains no invented releases, victims or events.

Article 14(8) concerns informing affected users and, where appropriate, all users about an actively exploited vulnerability or severe product-security incident. It includes relevant corrective or mitigation measures and, where appropriate, a structured machine-readable format. Scope and qualifications matter: do not describe every advisory as a mandatory, identical message to everyone.

Authority notification is not the customer advisory

ENISA describes SRP as a tool for notifications from manufacturers and, when applicable, stewards. Submission through that channel must not be presented as evidence that a user received actionable instructions. This article verifies neither message delivery nor operation of an SRP account.

Velqory proposal: retain linked identifiers but separate reporting and advisory records. The first tracks the authority relationship; the second retains intended recipients, approved content, channel and changes. Avoid publishing abuse-enabling detail merely to show that the technical team investigated the problem.

The proposed operational minimum

Our proposed advisory answers four questions: how to recognise an affected release, what measure is available, what prerequisites or operational effects exist and how to confirm completion. Also state what remains unresolved. For a temporary measure, explain how the user will receive replacement or review, without promising an unapproved deadline.

Do not confuse instructions with assurance: 'apply this update' does not prove the recipient applied it. For each step, the team should validate compatibility and provide a known support route. Plain language does not justify hiding limits or adding precision that the investigation does not yet support.

Review by a test recipient

This original matrix is an untested proposal. Use a reader who understands operations but did not write the advisory, and an authorised scenario without customer data. Ask them to explain what they would do; do not verbally supply instructions missing from the document.

The advisory only says to update

Hypothetical scenario: a team receives 'update to the fixed release' but cannot identify its running version and does not know whether the measure interrupts a service. The advisory fails our proposed acceptance even if it contains an accurate technical vulnerability description.

Editorial review must return specific questions to engineering, not fill gaps imaginatively. If no fix is available yet, distinguish that state from a mitigation validated for the relevant scope. If no instruction is confirmed, declare the limit and follow-up channel; do not invent a supposedly secure configuration.

The recipient needs evidence too

The UK's NCSC recommends verifying reconfiguration or mitigation measures and continuing to monitor temporary workarounds. This is technical guidance, not a Portuguese format requirement. Velqory's adaptation gives the recipient an observation criterion consistent with product documentation, without turning it into an offensive test.

Retain advisory versions and reasons for changes. If affected scope or measures change, review the earlier message and its routing. Value does not lie in the declared recipient count: it lies in allowing the right person to recognise the problem, decide on action and understand what conclusion they can, or cannot, draw.