> ## 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.
# Decision record
> Record whether an incident is reportable under the CRA, with your rationale, evidence and four-eyes approvals that can't be changed afterwards.
**Plans:** Core and Plus, and the free trial. **Who:** any member records a determination and names its approvers; only the members named as approvers approve or decline.
The decision record answers the question an incident turns on: is it reportable under CRA Art. 14? Each answer is an entry with your rationale, your evidence and the people who approved it. Entries are append-only, so the record shows what you knew, when you decided, and who agreed. It lives on the incident's **Determination** tab.
## The question you answer
The question follows the kind of incident.
| Kind | Question | Determinations |
| - | - | - |
| Actively exploited vulnerability | "Is the vulnerability actively exploited in our product?" | **Yes — actively exploited**, **No — not exploited**, **No — product not affected** |
| Severe incident | "Is this a severe incident affecting the security of our product?" | **Yes — severe incident**, **No — not severe** |
The form explains each one:
* **Yes — actively exploited:** there is reliable evidence that a malicious actor has exploited the vulnerability. Reportable under CRA Art. 14(1).
* **No — not exploited:** the product contains the vulnerability, but there is no evidence of exploitation. Not reportable; keep handling it as a vulnerability.
* **No — product not affected:** the vulnerable code isn't present or can't be reached in the product. Not reportable. Sets VEX to not affected on the linked vulnerability.
* **Yes — severe incident:** the incident affects, or could affect, the security of the product or led to malicious code being run. Reportable under CRA Art. 14(3).
* **No — not severe:** the incident doesn't meet the Art. 14(5) threshold. Not reportable.
Pharus records your answer. It doesn't decide for you, and it gives no legal advice.
## What an entry records
| Part | What it holds |
| - | - |
| **Determination** | Your answer to the question |
| **Rationale** | What you know and why you conclude this. At least 10 characters |
| **Evidence** | Items of type CISA KEV entry, EUVD entry, Disclosure report, Test, Link or Note, each with a description and an optional URL |
| **Required approvers** | The colleagues who must approve before the entry takes effect |
| **Decided by** | Your name, your job title (or role) and the time, in Oslo time |
The awareness time isn't part of the entry: it is on the incident's Overview tab, and only owners and admins can correct it, with a rationale that stays in the audit trail. See [Incidents](/incidents/overview#the-awareness-time).
## Record a determination
On the incident, select the **Determination** tab. The form is titled **Record determination**, or **Record a new determination** when there is one already.
Pick the answer that fits the incident.
Say what you know and why you conclude this.
Pharus suggests evidence from the matched data: the CISA KEV entry, the EUVD ID and any disclosure report linked to the incident. Select a chip to include it or leave it out, and use **Add evidence** for your own, such as a reachability test or a link to a vendor advisory.
Under **Required approvers**, pick the colleagues who must approve. Leave it empty and the determination takes effect immediately.
Tick **I understand this entry can't be changed afterwards** and select **Record determination**.
An entry can't be edited or deleted once recorded. To change your answer, record a new determination; both stay in the record.
## Approvals and the four-eyes rule
* **Who can approve:** the members you name under **Required approvers**, up to 10. Any member of the company can be named, whatever their role. You can't name yourself: "Four-eyes rule: you can't approve your own determination."
* **How approvers hear about it:** each one gets an email, whatever they have chosen for alert emails, and sees it in the **Notifications** bell under **Awaiting your approval**. If you have set up Slack, Teams or webhook alerts, the request goes there too.
* **Approve:** the approver selects **Approve determination**, with an optional comment. "Your approval is recorded with your name and the time, and can't be changed."
* **Decline:** the approver selects **Decline** and must say why. "The determination won't take effect. Someone has to record a new one."
* **One response each:** an approver responds once. Only the latest entry can be approved; once a newer one is recorded, the older one is superseded.
* **In force:** the entry takes effect when every required approver has approved. The card's badge says **In force**, "Waiting for 2 approvals" or **Determination declined**. The person who recorded it is emailed when an approver responds.
While approvals are pending, nothing changes: "The clocks keep running until every approver has approved."
## What happens when a determination is in force
**Reportable** (**Yes — actively exploited** or **Yes — severe incident**):
* The record says "CRA is triggered. File the reports before the clocks run out."
* The CRA status on the [Routing](/incidents/routing) tab becomes **Triggered**.
* The linked vulnerability's VEX status becomes affected.
* On Plus, a partner review opens by itself. See [Expert help](/incidents/expert-review).
**Not reportable** (any "No" answer):
* The CRA clocks that weren't filed show "Not required". Reports already filed still show as filed.
* The CRA status on the Routing tab becomes **Not applicable**.
* **No — product not affected** sets the linked vulnerability's VEX status to not affected, with your rationale.
* Pharus closes the incident with the reason **Not reportable**, unless a Norwegian notice or the DORA classification still needs handling. Then the incident stays open and the record says why.
## Revise a determination
Select **Record a new determination** and go through the form again. The new entry gets the next revision number and supersedes the current one. Earlier entries stay listed under **Earlier determinations**, each marked **Superseded**, with who decided, when, and who approved or declined.
On a closed incident you can't record or approve anything: "The incident is closed. Reopen it first."
## On Starter
Starter has no decision record. The Determination tab says: "Nothing is recorded here on Starter. The clocks keep running until the incident is closed." Instead:
* Any member can set the CRA status on the [Routing](/incidents/routing) tab with **Change status** and a reason.
* An owner or admin closes an incident that isn't reportable from its Overview tab, with the reason **Not reportable** and a note.
Both are recorded in the [audit trail](/reports/audit-trail). Determinations recorded during the free trial stay visible after it, and approvals already requested can still be given, so a record can be finished.
For a financial entity on Plus, the DORA classification uses the same kind of record, with its own question and its own four-eyes approval, kept apart from the CRA determination. See [DORA](/incidents/dora).
## In the audit trail
Every entry and response is logged: "Recorded determination", "Approved determination" and "Declined determination", with the determination, the revision and the comment. The effects that follow (the CRA status, the VEX status and closing the incident) are logged as Pharus's own events. See [Audit trail](/reports/audit-trail).
## Related
What runs while a determination waits, and what stops when it is in force.
Invite the colleagues you want as approvers.
Where the CRA status shows, and where the reports go.
The append-only log of every determination and approval.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.