> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pharussecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Inform users

> Draft the CRA Art. 14(8) notice to your users, send it through your own channels, and record when and how they were told.

<Info>
  **Plans:** Every plan. **Who:** any member drafts the notice and records that users were informed.
</Info>

After an actively exploited vulnerability or a severe incident, the CRA asks you to inform the impacted users, and where appropriate all users, and to tell them what they can do to limit the impact (CRA Art. 14(8)). If you don't do it in time, the CSIRT may tell them itself. Pharus drafts the notice from the incident and keeps the record. You send it through your own channels.

## When the Users tab appears

The incident gets a **Users** tab, and its **Overview** tab an **Inform users** card, once the duty applies:

* the latest determination, unless it was declined, says the vulnerability is actively exploited or the incident is severe;
* a CRA early warning or notification is marked as submitted; or
* the incident is an exploited vulnerability that nobody has ruled out yet: no determination says it isn't exploited or doesn't affect you, and it wasn't closed as not reportable.

The tab also stays once something has been recorded. Drills never get it.

The **Inform users** card shows **Not recorded yet** or **Users informed** with the date. Once the CRA notification is submitted and users still aren't recorded as informed, the card turns into a warning: "The notification is submitted, but users haven't been recorded as informed yet."

## Draft the notice

<Steps>
  <Step title="Open the Users tab">
    On the incident, select **Write the notice** on the **Inform users** card, or open the **Users** tab. **The notice** is prefilled from the incident, the SRP pack and its advisories.
  </Step>

  <Step title="Choose the language and the audience">
    Pick the **Language**, **Norwegian** or **English**; it starts in the company's default language. Under **Who to tell**, choose **The impacted users** or **All users**. A draft you haven't edited follows the language you pick.
  </Step>

  <Step title="Edit the text">
    Check the **Subject**, **What happened** and **What users can do**: updates to install, settings to change, workarounds. Pharus fills **What users can do** from the SRP pack's field 3.2 or the remediations in the incident's advisories; the SRP pack's field 3.2 in turn uses this text when it has none of its own.
  </Step>

  <Step title="Save the draft">
    Select **Save draft**. **Start over from the template** replaces your text with Pharus's first draft again.
  </Step>
</Steps>

**The whole message** shows the notice as it will read. Pharus adds at the end the links to the incident's public advisories and their CSAF documents, your security contact and the company name. The security contact is the contact address in your disclosure settings (**Settings → Disclosure**), else the security contact email under **Settings → Company**.

## Send it through your own channels

Pharus sends nothing. Copy **The whole message** with its copy button, or select **Open in email**: your email program opens with the subject and the text and no recipients. Add your customers there, as Bcc. Pharus sends no bulk email and keeps no list of your customers or their addresses.

Pharus doesn't publish the notice either. What it links to is public: the incident's advisories, once you publish them on your disclosure page at `/disclose/<your-slug>/advisories` and in your CSAF feed. See [advisories](/disclosure/advisories). Publish the advisory first if you want the notice to link to it.

## Record that users were informed

<Steps>
  <Step title="Record users informed">
    When you have told users, select **Record users informed**.
  </Step>

  <Step title="Say when and how">
    Set **Users informed at** and tick under **How** every channel you used: **Email**, **Security advisory**, **Website**, **In the product** or **Other**. The time can't be in the future.
  </Step>

  <Step title="Save the record">
    Select **Record**. Pharus keeps the message as it reads now, with when and how users were told.
  </Step>
</Steps>

<Warning>
  The record can't be changed afterwards. Check the message and the time before you select **Record**.
</Warning>

Each record is listed under **Recorded** on the **Users** tab, with "Recorded by" the person and the time, and **Show the message** shows what users were told. You can record more than once, for example a first notice to the impacted users and a later one to all users. Each record lands in the [audit trail](/reports/audit-trail).

## Closing the incident

An owner or admin can close an incident before users are recorded as informed. The close dialog warns: "Users haven't been recorded as informed (CRA Art. 14(8)). You can still close the incident."

## End-of-support notices

Users should also know when their product stops getting security updates. That notice is drafted and recorded from a product family's support periods, with **Tell users**, not from an incident. See [support periods](/monitoring/support-periods).

## Related

<CardGroup cols={2}>
  <Card title="Advisories" icon="file-text" href="/disclosure/advisories">
    Publish the CSAF/VEX advisory your notice links to.
  </Card>

  <Card title="SRP paste pack" icon="clipboard-check" href="/incidents/srp-pack">
    Field 3.2 and the CRA notification.
  </Card>

  <Card title="Support periods" icon="calendar-clock" href="/monitoring/support-periods">
    End dates per release line, and telling users.
  </Card>

  <Card title="Incidents" icon="siren" href="/incidents/overview">
    How an incident runs from match to closing.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.