How to write a breach message people can act on

A person reading a breach message wants to answer three questions quickly: what happened to my information, what could happen next and what should I do? A message that begins with several paragraphs about the organisation’s commitment to privacy delays those answers.

The message must also reflect what the team actually knows. Neither an alarming list of every imaginable consequence nor a blanket statement that everything is safe helps someone make a sensible decision. Good incident communication is factual, specific and easy to update.

As of 22 October 2026, the main DPDP breach duties are scheduled for 13 May 2027 under the commencement notification. This article prepares for the content requirements in Rule 7; existing sector, contractual and other applicable obligations need separate assessment.

Build the message around the affected person

Rule 7 requires information to each affected Data Principal without delay, in concise, clear and plain language through the person’s user account or a registered mode of communication. The required content includes the nature, extent and timing of the breach, likely consequences, mitigation, protective measures the person may take and relevant business contact information.

Use those categories as an editing checklist, not as headings that must be copied mechanically. A short incident may need a compact message. A complex incident may need an accessible initial notice with linked detail and a clear update route.

Do not substitute a general website announcement for a reasoned assessment of the prescribed individual communication. The audience, channel and content all matter.

Describe the information precisely

Compare “some information may have been involved” with “the exposed file contained your name, delivery address and order reference”. The second version is useful when supported by evidence. If the affected fields remain uncertain, say what is confirmed and what is still being examined.

A hypothetical homeware retailer discovers an improperly shared order file. Its investigation confirms names and delivery addresses but has not yet established the full access history. A message can state those facts without claiming that the file was definitely downloaded or definitely untouched.

Only exclude categories, such as payment information, when the investigation supports that statement. A reassurance copied from an old template can become inaccurate when a different system is involved.

Connect consequences to actions

If the exposed information could support convincing delivery scams, explain the relevant warning signs and the safe contact route. If an account credential is affected, coordinate the message with the actual reset or protection process. Avoid giving generic advice that does not address the incident.

Recommendations should be feasible. Telling a customer to change every password after exposure of a postal address creates work without explaining the connection. Telling them how to verify a suspicious delivery request provides a concrete action tied to the known information.

Describe mitigation in ordinary terms: the sharing link was restricted, the affected account was disabled or a configuration was corrected. Do not reveal unnecessary technical details that create additional security problems. State whether further investigation or action remains underway.

Give uncertainty a place in the draft

Use a fact table internally before writing. Include confirmed facts, reasonable assessments, open questions and the owner investigating each question. The external message should not silently convert an internal possibility into a confirmed event.

The future Rule 7 process distinguishes initial information from the detailed Board update. It does not make a finished investigation a prerequisite for all communication. Coordinate drafting with the incident chronology so the team can communicate without delay while identifying what may change.

Choose a contact route that will be staffed. A mailbox nobody monitors is not a meaningful support mechanism. Prepare the support team with the same verified facts and a process for escalating information that changes the incident assessment.

Review the draft from the recipient’s position

Read the message on a small screen. Is the affected information visible near the beginning? Can a person find the recommended action without opening several attachments? Is the contact information recognisable and consistent with the organisation’s normal channels?

Check that the notification itself does not disclose other affected people’s details. Avoid attaching the underlying customer list as evidence or exposing recipients through an inappropriate group message.

Keep the approved wording, audience selection, delivery record and subsequent updates. If new facts materially change the explanation, determine the appropriate correction and communicate it clearly. A breach notice is part of an ongoing response, not a final declaration designed to end questions before the facts are settled.