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

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.

​

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.

• 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.

​

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. 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.

​

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:

​

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. The Overview tab also holds the cards for reporting upstream to a component’s maintainers and expert help.

​

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.

​

Close an incident

Owners and admins close and reopen incidents. Members see “Only owners and admins can close or reopen incidents.”

• 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.

​

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.

​

Related