> ## 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. # Reporting clocks > How Pharus runs the CRA Art. 14 deadlines for the early warning, notification and final report, and warns you before each. **Plans:** Every plan. **Who:** any member records a fix and marks reports as submitted; owners and admins correct the awareness time. Every incident runs three CRA Art. 14 clocks: the early warning, the notification and the final report. Pharus starts each clock from the event the regulation names, shows the time left on every tab of the incident, and warns your team before a report is due. Filing is yours: a clock stops only when you mark the report as submitted. ## The three deadlines | Report | Actively exploited vulnerability | Severe incident | | - | - | - | | **Early warning** | 24 h after awareness. CRA Art. 14(2)(a) | 24 h after awareness. CRA Art. 14(4)(a) | | **Notification** | 72 h after awareness. CRA Art. 14(2)(b) | 72 h after awareness. CRA Art. 14(4)(b) | | **Final report** | 14 days after a corrective or mitigating measure is available. CRA Art. 14(2)(c) | One month after the notification was submitted. CRA Art. 14(4)(c) | ## What starts each clock * **Early warning and notification:** the incident's awareness time. For an incident Pharus opened from a match, that is when Pharus first saw the match as exploited; for one you declared, the time you entered. An owner or admin can correct it with **Correct awareness** on the Overview tab, and both clocks move with it. See [Incidents](/incidents/overview#the-awareness-time). * **Final report, actively exploited vulnerability:** the time you record with **Record fix available** on the Overview tab: when users could first get the security update or mitigation. Until then the clock shows "Starts when fix ships". * **Final report, severe incident:** the time you enter in **Submitted at** when you mark the notification as submitted. Until then the clock shows "Starts at notification". ## How Pharus counts * The 24 h, 72 h and 14-day windows are exact hours from the start. 14 days is 336 hours, so across a change to or from summer time the due time on the wall clock moves by an hour. * One month is the same Oslo wall-clock time one calendar month later, or the last day of the month when that month is shorter: a notification submitted on 31 January 2027 at 09:00 makes the final report due on 28 February 2027 at 09:00. * Times are entered and shown in Oslo time, with the zone (CET or CEST) on every due time. * Pharus doesn't move a CRA deadline for a weekend or a public holiday. Each due time is shown as it falls. ## How the app shows the clocks The three clocks sit at the top of every tab of an incident. Each shows its window (**24H**, **72H**, **14D**, or **1 MO** for a severe incident's final report), the report's name, a live countdown with a progress bar, the due time, and the CSIRT the report goes to, such as "→ NCSC-FI via SRP". | What you see | What it means | | - | - | | A countdown, such as `1d 04:12:09` | The clock is running | | A countdown below zero, in red, with an alarm icon | The deadline has passed and the report isn't marked as submitted | | **Submitted** and "Filed" with the time | The report is marked as submitted | | "Starts when fix ships" or "Starts at notification", and "Clock not running" | The final report clock hasn't started yet | | "Not required" | An approved determination found the incident not reportable | | "Incident closed" | The incident was closed before this report was filed | The **Incidents** list shows the next deadline of each open incident across every regime, for example "14 h 31 min left" with "CRA · Early warning" under it, or "3 h 12 min overdue". If your company is a micro or small enterprise (**Company size** under **Settings → Company**), the clocks carry this note from the app: "Micro and small enterprises are not fined for missing the 24-hour early-warning deadline (CRA Art. 64(10)). The early warning is still required, and the 72-hour notification and the final report are not covered." ## Warnings before a deadline Pharus sends a warning once for each report and deadline that is still running and not marked as submitted. | Report | Warning goes out | How | | - | - | - | | Early warning | 4 hours before it is due | Email, a page to on-call, and Slack, Teams or webhook alerts | | Notification | 4 hours before it is due | Email, a page to on-call, and Slack, Teams or webhook alerts | | Final report | 72 hours before it is due | Email, and Slack, Teams or webhook alerts. Never a page | * **Email** goes to the owners and admins who receive alert emails and, on a plan with on-call, to the person on call. If none of them receives alerts, the owners get it. * **The page** to on-call is by SMS, on a plan with on-call (Core and Plus, and the free trial), and only when no page for that incident is open already. A final report is days away, so its warning never wakes anyone. * **Slack, Teams and webhooks** get the warning on Core and Plus, and in the free trial, where you have set them up. See [Notifications](/notifications/overview). * A final report due within 72 hours, or overdue, is also listed under **Reports to file** in the **Notifications** bell until you file it or close the incident. * If a deadline moves (for example after a corrected awareness time or a changed fix date), Pharus warns again for the new deadline. * Drills, closed incidents and reports that are already submitted or not required get no warnings. * A read-only workspace (on Free, or closed) gets no warnings and no pages. If an owner subscribes or reopens it while a deadline is still ahead, the warning goes out then. Every warning is recorded in the audit trail as "Deadline warning sent". ## When you file a report Filing happens in ENISA's Single Reporting Platform. In Pharus you record it on the [SRP pack](/incidents/srp-pack) tab: 1. **Mark as submitted** with the time you filed. The clock shows **Submitted**, the incident's next deadline moves to the following report, and no more warnings go out for this one. For a severe incident, the notification's submission time starts the one-month final report clock. 2. **Record receipt** with the reference the SRP gave you. The report then shows as received. 3. **Void filing** steps back the last of those actions if it was recorded by mistake: the receipt first, then the submission. A voided submission puts the clock back to running (or overdue) against its original deadline. The voided action stays in the audit trail. You can file the reports in any order. Before you mark one as submitted, the SRP pack warns you if an earlier report isn't marked yet, or if you file an exploited vulnerability's final report before a fix is recorded. ## When the clocks stop without a filing * **An approved not-reportable determination** (Core and Plus): the unfiled clocks show "Not required". Reports already filed still show as filed. A determination waiting for approval doesn't stop anything: "The clocks keep running until every approver has approved." See [Decision record](/incidents/decision-record). * **Closing the incident:** the unfiled clocks stop and show "Incident closed". Reopening starts them again. * **On Starter**, without a decision record, the clocks keep running until the incident is closed. On Free, monitoring and the CRA clocks pause: no deadline warnings, no pages, and incidents are read-only, so you can't mark reports as submitted. A page that was already under way when the workspace became read-only still escalates. See [Billing](/workspace/billing). ## Other regimes have their own clocks The CRA clocks are only the CRA's. A Norwegian notice under digitalsikkerhetsloven or GDPR runs its own deadlines from that regime's awareness time, and a major incident under DORA runs Finanstilsynet's deadlines with DORA's own weekend rule. Their clocks appear under the CRA clocks once the regime is triggered. See [Norwegian notices](/incidents/norwegian-notices) and [DORA](/incidents/dora). ## Related Copy each report into the SRP and record the receipt. The determination that makes the clocks "Not required". How the on-call person is paged and how escalation works. NSM's and Datatilsynet's deadlines, run apart from the CRA's. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.