The CRA asks the manufacturer to indicate, where applicable, how sensitive it considers information in the 72-hour notification. That is a field-level assessment, not permission to omit the substance needed for the report and not a guarantee that onward dissemination will be delayed.
A practical process classifies the information before the assigned representative reaches the submission screen and keeps any delay request specific, evidence-based, and separately approved.
Classify the content, not the case name
Review each material element: product identity, affected versions, exploit path, indicators, architecture, source code or configuration excerpts, user locations, malicious-actor information, mitigations, and planned release timing. A case may contain both ordinary and highly sensitive fields.
For each field, record the harm that premature or unnecessarily broad disclosure could cause. Distinguish exploitation enablement, exposure of defensive gaps, trade-secret harm, personal data, contractual confidentiality, and national-security concerns. Avoid a single “confidential” label with no rationale.
Use the minimum detail that remains accurate and useful for the notification. Redact unrelated secrets from attachments, but preserve the evidence internally and explain any necessary abstraction. The reporting team should be able to show that minimisation did not become concealment.
Separate handling controls from a delay request
Ordinary controls still apply: restricted case access, approved transfer channels, recipient checks, retention rules, and protected evidence storage. These controls do not depend on an authority decision.
A dissemination-delay request is different. State the specific cybersecurity risk created by immediate onward circulation, which information creates it, the affected period, and the condition that would reduce the risk. Route the request through legal and product-security approval.
Do not write the runbook as though selecting sensitivity automatically withholds the report. The coordinating CSIRT decides whether the statutory and delegated conditions justify delay. Prepare the response team for either outcome.
Keep the classification current
Sensitivity can change as a patch ships, indicators become public, an investigation closes, or affected scope changes. Reassess it at each reporting stage. Preserve the earlier classification and the reason for any increase or decrease.
Link public advisories and user notices to the same case without assuming they contain the same details as the authority report. Their audiences and purposes differ.
Test with a difficult example
Run a tabletop using an exploited vulnerability for which the 72-hour report needs technical detail but a public exploit is not yet available. Ask the team to classify each field, prepare a narrowly reasoned delay request, and produce a version suitable for the normal dissemination path if the request is not accepted.
The output should be a reviewable matrix: content, sensitivity reason, internal handling, report wording, delay-request rationale where applicable, approver, and reassessment trigger.
Continue this workflow with the delayed-dissemination analysis and the user-notice delivery record.