The CRA may ask the maker to mark facts in the 72-hour notice as sensitive. Review each field on its own. The mark is not leave to omit facts the report needs. It also does not ensure that later sharing will wait.

Classify the facts before the filing person opens the form. Base any request for delay on clear proof. Give that request its own approval.

Classify the content, not the case name

Review each key fact. Cover the product, versions, attack path, signs, design, and code or setup samples. Also check user places, facts about the attacker, fixes, and release plans. One case can have both plain and very secret fields.

For each field, state the harm from sharing it too soon or too far. Ask if it could aid an attack or expose a weak guard. Check for trade secrets, personal data, contract limits, or a risk to State security. Do not use one “secret” label with no reason.

Give the least detail that is still true and useful. Remove unrelated secrets from files sent with the report. Keep the full proof inside the firm and explain any broad wording. The team should show that it cut excess detail without hiding the case.

Separate handling controls from a delay request

Normal safety steps still apply. Limit case access. Use approved ways to send files, check each reader, and protect saved proof. Apply the rules for how long to keep it. These steps do not need an authority’s choice.

A request to delay later sharing is different. Name the security risk from sharing at once. State which facts create it and how long it may last. Name the event that would cut the risk. Get approval from legal and product security teams.

A sensitive mark does not hold back the report by itself. The main CSIRT decides if the legal rules allow a delay. Plan for both answers.

Keep the classification current

The level can change when a patch ships or attack signs become public. It can also change when the review ends or scope shifts. Check it again at each report stage. Keep each old result and the reason for a change.

Link public and user notes to the case. Do not assume they need the same facts as the report to an authority. They serve different people and goals.

Test with a difficult example

Run a drill with a flaw that is under attack. The 72-hour notice needs technical facts, but no public attack tool exists yet. Ask the team to mark each field and draft a narrow delay request. It must also make a copy fit for normal sharing if the request fails.

The result should be a table that can be checked. For each field, show the secret-data reason, in-house guard, and report words. Add any delay reason, approver, and event for a new check.

Continue this workflow with the delayed-dissemination analysis and the user-notice delivery record.