> ## 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. # Fix deadlines > Give every open finding a fix-by date from your remediation policy, make someone owner of the fix, and see what is overdue. > [!NOTE] > > **Plans:** Every plan. On Free, deadlines and owners show but can't be changed. **Who:** any member sets owners and > deadlines; owners and admins change the remediation policy. Pharus gives each open finding on **Vulnerabilities** a deadline: the day it should be fixed by, worked out from how urgent the finding is. Your remediation policy says how many days each kind of finding gets. The CRA asks manufacturers to address and remediate vulnerabilities without delay (CRA Annex I Part II(2)). The policy records what that means for your company, and the deadlines show whether you keep to it. ## How a deadline is set Each finding goes in the most urgent tier that fits it. Its deadline is the tier's number of days, counted from when the finding came into that tier. | Tier | Which findings | Default | Counted from | | - | - | - | - | | **Exploited** | Known to be exploited: listed in CISA KEV or marked as exploited in EUVD | 7 days | When Pharus saw the exploitation | | **Exploitation likely** | An EPSS score at or above the policy's **EPSS threshold**, 10 % by default. See [EPSS](https://docs.pharussecurity.com/monitoring/vulnerabilities.md#use-epss-to-prioritise). | 14 days | When the score reached the threshold | | **Critical and high** | A CVSS score of 7.0 or more | 30 days | When Pharus first saw the finding | | **Everything else** | Medium, low and unscored findings | 90 days | When Pharus first saw the finding | * **Findings you already had** when your workspace got its first deadlines count from that day, so they don't start out overdue. * **A finding that becomes more urgent**, for example because it is added to CISA KEV, gets the new tier's deadline when that one is earlier. Pharus never moves a deadline later by itself, even when a finding becomes less urgent. * **Saving the policy** works out every deadline again from its tier's start, except the ones set by hand. * **Only open findings have a deadline that counts**: those whose VEX status is Affected or Investigating, in a component that is still in an active SBOM. A finding marked Not affected or Fixed, or whose component was removed, keeps its date, shown greyed out, and is never overdue. ## Change the remediation policy **1. Open the policy** Go to **Settings → Company**. The **Remediation policy** card shows the policy in force, with the defaults until someone changes them. **2. Set the days and the threshold** Enter the days for **Exploited**, **Exploitation likely**, **Critical and high** and **Everything else**, each between 1 and 365. Set the **EPSS threshold** in percent, between 0.1 and 100. 10 % is a common choice. **3. Save** Select **Save policy**. Pharus confirms "Policy saved, deadlines updated", and every deadline not set by hand gets its new date straight away. The [audit trail](https://docs.pharussecurity.com/reports/audit-trail.md) records "Updated the remediation policy", with the values that changed. ## Deadlines on the Vulnerabilities list The list has three columns for fixing: | Column | What it shows | | - | - | | **Fix available in** | The versions of the component that fix the vulnerability, from its OSV.dev record. A dash when no fixed version is known. | | **Deadline** | The date in Oslo time, marked **Overdue** once it has passed or **Due soon** within 7 days, and "Set by hand" when a person set it. Hover over it to see the tier it came from, for example "From your remediation policy: Critical or high." | | **Owner** | The member who owns the fix | **Order** is **Nearest deadline first** by default: open findings by deadline, then the rest, newest first. The other orders are **Exploited, then newest** and **Highest EPSS first**. Two filters narrow the list, each choice with its count: * **Owner**: **Any owner**, **Mine**, **No owner**, or one member. * **Deadline**: **Any deadline**, **Past the deadline**, **Due within 7 days** or **No deadline yet**. On a vulnerability's page, each row under **Affected in your products** shows the same facts: **Fix available in**, "Fix by" with the date, and the owner. ## Make someone owner of a fix, or set a deadline **1. Select findings** On **Vulnerabilities**, tick the findings, or tick the box in the header to **Select all on this page**. A bar shows how many are selected, with **Set VEX**, **Owner**, **Deadline** and **Clear selection**. **2. Choose an owner** Select **Owner**, pick a member under **Make owner of the fix**, or **Nobody** to remove the owner, and save. **3. Or set the deadline by hand** Select **Deadline** and pick a **Fix by** day: today or later, within two years. The fix is due by the end of that day, Oslo time. Select **Save**. A deadline set by hand stays until someone selects the findings again, opens **Deadline** and chooses **Back to the policy**. Changing the policy doesn't move it. **Set VEX** gives every selected finding the same VEX status, as if you had set each one: unchanged ones are skipped, and each change gets its own entry in the audit trail. On a vulnerability's page, **Set VEX for all** sets one VEX statement for the vulnerability in every product family listed there whose component is still present. See [Set a VEX status](https://docs.pharussecurity.com/monitoring/vulnerabilities.md#set-a-vex-status). > [!NOTE] > > The owner must be a member of the company. When someone leaves the company, the fixes they owned go back to no owner; > the audit trail keeps who it was. Owners stay in Pharus: they aren't sent to your > [issue tracker](https://docs.pharussecurity.com/incidents/remediation-tickets.md). ## Where overdue fixes show up * **Overview**: the number of fixes past their deadline, linked to the list filtered on **Past the deadline**. * **[Weekly digest](https://docs.pharussecurity.com/monitoring/weekly-digest.md)**: a **Fixes due** section with the open findings past their deadline and those due in the next 7 days, up to 10, with the owner. * **[Board report](https://docs.pharussecurity.com/reports/board-report.md)**: under **Open items and risks**, the fixes past their deadline, up to 10, with the date and the owner. * **[Audit trail](https://docs.pharussecurity.com/reports/audit-trail.md)**: "Made *name* owner of the fix", "Removed the owner of the fix", "Set a deadline for the fix" and "Put the fix deadline back to the policy", linked to the incident when there is one. ## Related > [card] [Vulnerabilities](https://docs.pharussecurity.com/monitoring/vulnerabilities.md) > [card] [Remediation tickets](https://docs.pharussecurity.com/incidents/remediation-tickets.md) > [card] [Weekly digest](https://docs.pharussecurity.com/monitoring/weekly-digest.md) > [card] [Board report](https://docs.pharussecurity.com/reports/board-report.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.