> ## 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.
# Incidents
> What an incident is in Pharus, the ways one opens, and how to work it from the awareness time to closing it.
**Plans:** Every plan. On Free, incidents are read-only. **Who:** any member declares an incident and edits its details; owners and admins correct the awareness time and close or reopen incidents.
An incident is Pharus's record of one event you may have to report under CRA Art. 14: an actively exploited vulnerability in your product, or a severe incident that affects its security. Each incident has its own reporting clocks, determination, CSIRT route, SRP paste pack and audit trail. Pharus prepares the reports; your company files them.
## Two kinds of incident
| Kind | What it covers | Final report due |
| - | - | - |
| **Actively exploited vulnerability** | A vulnerability in your product that a malicious actor is exploiting. CRA Art. 14(1). | 14 days after a fix or mitigation is available |
| **Severe incident** | An incident that affects the security of your product, such as a compromised build or update server. CRA Art. 14(3). | One month after the notification |
The kind is set when the incident opens and stays with it. It decides which question the determination answers, which fields the SRP pack asks for, and when the final report is due. Incidents that Pharus opens by itself are always actively exploited vulnerabilities.
## How an incident opens
The **Source** line on the Overview tab says how each incident started.
| Source | How it opens | Awareness time |
| - | - | - |
| Matched CISA KEV entry | Automatically, from an exact match | When Pharus first saw the match as exploited |
| Matched exploited EUVD entry | Automatically, from an exact match | When Pharus first saw the match as exploited |
| From the disclosure inbox | A member declares it from a report | The time you enter |
| Declared manually | A member selects **Declare incident** | The time you enter |
### Automatically, from an exact match
When a component in one of your SBOMs matches, by exact version, a vulnerability that CISA KEV lists or that ENISA EUVD marks as exploited, Pharus opens an incident for that product family and starts the clocks. The awareness time is the moment Pharus first saw the match as exploited: when it matched, or later, when CISA KEV or EUVD listed it. Owners and admins who receive alert emails are told, and on a plan with on-call the person on call is paged. See [Paging](/on-call/paging).
* Pharus opens one incident per vulnerability and product family. A second match for the same pair doesn't open another.
* No incident opens when the match's VEX status says the product is not affected or the vulnerability is fixed.
* A match on the component's name only ("Version not verified") doesn't open an incident by itself. A member checks the version and selects **Confirm match**, then **Confirm and open incident** on the vulnerability's page. The awareness time is then the moment you confirm. See [Vulnerabilities](/monitoring/vulnerabilities).
### From a disclosure report
Open the report in the **Disclosure inbox** and select **Declare incident from report**. You choose the kind, title, product family and, for a vulnerability, its ID. The incident and the report are linked, and the report can be added as evidence on the Determination tab. See [Disclosure inbox](/disclosure/inbox).
The awareness time is when you became aware that the vulnerability is actively exploited, or that the incident is severe. The app's own guidance: "Not when the report arrived, unless that is when you knew."
### Declare one by hand
Use this for anything Pharus didn't open itself, for example a phone call from a customer or a compromised update server.
Select **Declare incident** in the top bar, or on the **Incidents** page.
Under **What happened**, pick **Actively exploited vulnerability** or **Severe incident**.
Fill in **Title**, **Product family** and **Product versions** (leave the versions empty to use the family's current version). For a vulnerability, add the **CVE or vulnerability ID** if you have one, for example `CVE-2026-41120`. For a severe incident, tick **Suspected unlawful or malicious act** if that applies: the early warning asks for it.
**Aware since** is in Oslo time and can't be in the future. The 24h and 72h clocks run from here.
**Member states where the product is made available** defaults to the product family's list when you leave it empty. **Summary** is what you know so far; you can edit it later.
Select **Declare incident**. Pharus opens the incident page with the clocks running.
## References
Every incident gets a reference such as `INC-0042`, numbered in order within your company. Drills have their own series, such as `DRILL-0003`. The incident page lives at `/incidents/INC-0042` in the app, and the audit trail, emails and pages use the same reference.
## The awareness time
The CRA's early warning and notification deadlines run from when you become aware (CRA Art. 14(2)(a) and (b), and Art. 14(4)(a) and (b) for a severe incident). The awareness time is therefore the most important timestamp on an incident. The **Awareness** card on the Overview tab shows it, in Oslo time, with its basis: for example "Matched CISA KEV entry", the disclosure report it came from, or "Declared manually".
If the recorded time is wrong, an owner or admin corrects it:
On the Overview tab, select **Correct awareness** on the Awareness card.
Enter **Aware since (Oslo time)** and a **Rationale** of at least 10 characters: why the recorded time was wrong.
The 24h and 72h clocks move to the new time. The old and new times and your rationale stay in the audit trail, and the rationale becomes the new basis.
Moving the awareness time moves the early warning and notification deadlines with it. The correction can't be removed: it stays in the audit trail, with your reason, for anyone who reviews the incident later.
## The incident page
Every tab shows the same header: the reference, status badges (such as **Actively exploited**, **Severe incident**, **Awaiting approval**, **Determination declined** and **Closed**), the title, the product family and versions, the vulnerability ID, the awareness time and the kind. Under it are the three CRA clocks, and the clocks of any Norwegian notice or DORA report the incident has triggered.
| Tab | What it holds | Shown |
| - | - | - |
| **Overview** | Summary and details, the affected component, the exploitation signal from CISA KEV and ENISA EUVD, awareness, fix available, advisories, informing users, expert help and the status | Always |
| **Determination** | The [decision record](/incidents/decision-record): is it reportable, why, and who approved | Always |
| **DORA** | The [DORA classification](/incidents/dora) | For a financial entity on a plan with DORA, or once the incident has a DORA record |
| **Routing** | The [CSIRT route](/incidents/routing) and the triage of every regime | Always |
| **SRP pack** | The [paste pack](/incidents/srp-pack) for ENISA's Single Reporting Platform | Always |
| **Notices** | The [Norwegian notices](/incidents/norwegian-notices) and the DORA reporting template | Always |
| **Users** | [Informing users](/incidents/inform-users) under CRA Art. 14(8) | Once that duty applies, or something has been recorded |
| **Audit** | Every event on this incident, oldest first. See [Audit trail](/reports/audit-trail) | Always |
The Overview tab also holds the cards for [reporting upstream](/incidents/report-upstream) to a component's maintainers and [expert help](/incidents/expert-review).
### Edit the details
Any member selects **Edit details** on the Summary card to change the **Title**, **Summary**, **Product versions**, member states and, for a severe incident, **Suspected unlawful or malicious act**. The change is logged in the audit trail. The SRP pack fills its fields from these details.
### Record that a fix is available
When users can first get a security update or mitigation, select **Record fix available** on the Fix available card. Enter **Available since (Oslo time)** and, optionally, **What was released**, for example "Firmware 4.3 with OpenSSL 3.0.15". For an actively exploited vulnerability this starts the 14-day final report clock. Use **Change fix details** to correct it. See [Reporting clocks](/incidents/clocks).
## Close an incident
Owners and admins close and reopen incidents. Members see "Only owners and admins can close or reopen incidents."
On the Overview tab, select **Close incident** on the Status card.
Choose **Reported**, **Duplicate** or **Not reportable**, and add a **Note** if you want.
The incident leaves the open list. Filed reports, the decision record and the audit trail stay as they are. Clocks that weren't filed stop and show "Incident closed".
* If the duty to inform users under CRA Art. 14(8) applies and nobody has recorded that users were informed, the dialog says so. You can still close the incident.
* Closing stops a partner's review link for the incident.
* **Reopen incident** on the same card brings a closed incident back to the open list.
* On Core and Plus, a fully approved determination that the incident is not reportable closes it automatically, unless a Norwegian notice or the DORA classification still needs handling.
* On Starter there is no decision record: an admin closes an incident that isn't reportable from its Overview tab.
* A drill ends with **Complete drill** instead. See [Drills](/incidents/drills).
## The Incidents page
**Incidents** in the sidebar has three tabs: **Open**, **Closed** and **Drills**. The open list is sorted by the nearest deadline and shows, for each incident, the reference, product, CVE, awareness time, the next deadline across every regime, the status badges and the CRA status. When there are many, the list shows the most urgent and you search by reference or title to find the rest.
On Free, incidents are read-only and Pharus doesn't run the CRA clocks or prepare SRP packs. If something needs reporting, file it in ENISA's Single Reporting Platform yourselves, or start a plan. See [Plans](/plans).
## Related
The 24 h, 72 h and final report deadlines, and the warnings before them.
Record whether the incident is reportable, with evidence and approvals.
Copy each report into ENISA's Single Reporting Platform.
Every action on the incident, append-only.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.