> ## 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.
# Norwegian notices
> Assess GDPR and digitalsikkerhetsloven on an incident, follow each regime's own deadlines, and file with NSM and Datatilsynet from Norwegian paste packs.
**Plans:** Core and Plus, and the free trial. **Who:** any member assesses a regime, edits the packs and records filings.
An incident that the CRA makes reportable can also be a personal data breach under GDPR, or a serious incident under digitalsikkerhetsloven. Pharus triages every incident against these regimes next to the CRA, runs each regime's deadlines from its own awareness time, and prepares NSM's and Datatilsynet's forms as Norwegian paste packs on the incident's **Notices** tab. You decide whether a regime applies, and you file. Pharus prepares the text and keeps the record.
## What a new incident starts with
Every new incident gets one row per regime on its **Routing** tab, set by Pharus from where the company is established (**Settings → Company**). For a company established in Norway:
| Regime | Starts as | Recipient | Deadlines |
| - | - | - | - |
| Digitalsikkerhetsloven (forskrift § 17) | Under review | NSM | 24 h, 72 h, 1 month |
| GDPR (Art. 33) | Under review | Datatilsynet | 72 h |
| NIS2 (2022/2555) | Tracked | NSM | None |
Under review means still being assessed: nothing is due until someone sets the regime to **Triggered**. Each row shows what to confirm:
* **Digitalsikkerhetsloven:** "Confirm whether you provide an essential service (digitalsikkerhetsforskriften § 1), or a cloud service, online marketplace or search engine with 50 or more employees or over EUR 10 million a year."
* **GDPR:** "Confirm whether personal data is affected."
For a company established outside Norway, digitalsikkerhetsloven starts as **Not applicable** ("Applies only to undertakings established in Norway."), and GDPR's recipient is the data protection authority of the main establishment where Pharus knows it. For a financial entity, the incident also gets a DORA row: see [DORA triage](/incidents/dora).
Pharus gives no legal advice. Whether a regime applies is your assessment, and the reason you record is part of the incident's record.
## Assess a regime
Open the incident and go to **Routing**. The **Regimes** table lists every regime the incident may trigger, with its status, recipient, windows and the reason for the current status.
Select **Change status** on the regime's row and choose **Triggered**, **Under review**, **Not applicable** or **Tracked** ("Followed for reference. No obligation yet.").
When you choose **Triggered** for digitalsikkerhetsloven or GDPR, check **Aware for this regime (Oslo time)**. The regime's deadlines run from this time. Leave it as it is if that is when the incident became known; change it if you only learned later that, for example, personal data was affected. The time can't be in the future.
For digitalsikkerhetsloven, the recipient is your supervisory authority: "NSM is the authority where your sector has none, and gets a copy either way." For GDPR, it is the data protection authority where you have your main establishment.
Write why the status applies (at least 3 characters) and select **Record assessment**.
Each change adds a new assessment. Earlier ones stay in the **Assessment history** on the same tab, with the time, the person and the reason, and every assessment lands in the [audit trail](/reports/audit-trail). Rows Pharus set show "Pharus" as the author.
A regime can't be set to **Triggered** on a closed incident: reopen it first.
On Starter, the **Regimes** table shows the CRA row only, and the **Notices** tab offers the upgrade to Core. A regime that was already triggered, for example during the trial or before a downgrade, keeps working: you can still change its status, edit its pack and record its filings, and its deadline warnings still go out.
## Each regime's deadlines
Once a regime is **Triggered**, its clocks appear in the incident's header under the CRA clocks, and its packs appear on the **Notices** tab. The deadlines count from the regime's own awareness time, not from the CRA's.
| Regime | Report (as Pharus names it) | Due |
| - | - | - |
| Digitalsikkerhetsloven | First notice | 24 h after becoming aware for this regime |
| Digitalsikkerhetsloven | Update | 72 h after becoming aware for this regime |
| Digitalsikkerhetsloven | Incident report | 1 month after the first notice is submitted |
| GDPR | Breach notification | 72 h after becoming aware for this regime |
Until the first notice is marked as submitted, the incident report's clock reads "Starts when the first notice is submitted". These are the deadlines from digitalsikkerhetsforskriften § 17 and GDPR Art. 33(1). Pharus runs the same clocks for every incident where digitalsikkerhetsloven is triggered.
Pharus warns before a report is due: 4 hours before the first notice, the update and the breach notification, and 72 hours before the incident report, which is warned by email only. See [notifications](/notifications/overview) for who gets the warnings.
When GDPR's 72 hours have passed before you file, the pack says so: "The 72 hours have passed: the notification must give the reasons for the delay." The field for the reasons becomes required.
If you change a regime from **Triggered** to another status, its deadlines stop: "This regime is no longer triggered: its deadlines have stopped. What was filed stays here." A triggered notice also keeps the incident open: a CRA determination that finds the incident not reportable stops the CRA clocks, but doesn't close an incident while a notice still needs handling.
## File from the Notices tab
The **Notices** tab shows one pack per triggered regime and report. With more than one regime triggered, pick it in the **Regimes** switch at the top; pick the report under **Reports**. The tab opens on the first report that still needs filing.
Each pack follows the authority's own form. The labels are the authority's, in Norwegian, whatever language you use Pharus in, and Pharus fills in what it already knows. Fields marked **Missing** are required and still empty.
The pack follows NSM's form "Varsel om alvorlig hendelse etter digitalsikkerhetsloven", the same form for all three reports. The tab tells you where to send it: fill in NSM's form and send it to your supervisory authority. NSM takes it at [beredskap@nsm.no](mailto:beredskap@nsm.no), marked "varsel digitalsikkerhetsloven": send it there if NSM supervises you, or a copy if another authority does. The tab links to **NSM's form (PDF)** and NSM's **Guidance**.
| Field | Filled in from |
| - | - |
| Type | The report: "Varsel om ny hendelse", "Oppdatering" or "Endelig rapport" |
| Dato og tid | When you open the pack, Oslo time |
| Navn/Referanse | The incident's reference and title |
| NSM sin referanse | The reference you recorded for the first notice (update and incident report) |
| Virksomhetens navn, Organisasjonsnummer | **Settings → Company** |
| Kontaktperson, Epostadresse | The person who recorded the latest CRA determination, else you |
| Berørt tjeneste | The incident's product family |
| Når ble hendelsen oppdaget | The awareness time for digitalsikkerhetsloven |
| Hendelsen | The incident's summary, else its title |
| Andre berørte land | The incident's member states other than Norway, or "Tjenesten tilbys bare i Norge" |
| Avhjelpende tiltak som er iverksatt | What was released, from the incident's fix (incident report only) |
| Navn (Varslet av) | You |
You write the phone number, the possible causes, the consequences, the number of affected users and any impact in other countries. The form's tick boxes, the sender's phone and email and the signature are filled in on the form itself.
The incident report asks for the remedial measures (digitalsikkerhetsforskriften § 17), which NSM's form has no box for. Pharus checked the pack against NSM's form of 8 September 2025.
You report in Altinn, "Melding om brudd på personopplysningssikkerheten". Copy each field into the form, then record the reference Altinn gives you. The tab links to **Open the form in Altinn** and Datatilsynet's **Guidance**.
Pharus fills in when the breach was discovered (the awareness time for GDPR), what happened (the incident's summary), the measures to reduce the risk (what was released, from the incident's fix), the contact information (the security contact email from **Settings → Company**, else the contact person) and, for later information, the reference to the first notification. You write the rest: the main cause, how long the breach lasted, how many are affected, how it happened, the types of personal data, the relation to the people affected, where the data is now, the consequences, and what the people affected are told.
The labels follow Datatilsynet's guide to its Altinn form and are to be confirmed against the form itself.
Pharus has a paste pack for Datatilsynet only. With another data protection authority as GDPR's recipient, the tab shows the deadline and lets you record the filing: "File with their own form, then record it here."
Select **Edit pack** to write the fields Pharus can't fill in or to change an auto-filled one. Your text replaces the auto-filled value; clear a field, or select **Use auto-filled value**, to go back. Select **Save pack**. Edited fields show **Edited**.
Each field has a copy button. Paste the values into the authority's form and send it there. Pharus never files for you. **Print** prints the pack.
Back in Pharus, select **Mark as submitted**. See the next section.
When expert help is available for your workspace, owners and admins see an offer of a second opinion on the **Notices** tab before they file. See [expert help](/incidents/expert-review).
## Record that a notice was sent
Select **Mark as submitted** and set **Submitted at (Oslo time)**. The dialog shows the **Recipient** from the regime's assessment; to change it, change the regime's status on the **Routing** tab. Add a **Note** if you like. Pharus keeps a snapshot of the values in the pack.
When the authority answers, select **Record reference** and enter the **Reference** it gave you, with **Received at (Oslo time)**. The reference from the first notice fills NSM's "NSM sin referanse" in the update and the incident report; the reference from the breach notification fills the reference to the first notification for Datatilsynet.
Once submitted, the report's clock stops and the pack shows the values as submitted. A submitted pack can't be edited. To correct a filing, select **Void filing** and give a reason: it steps back the last action on the report, the reference first, then the submission. The voided action stays in the audit trail.
GDPR's breach notification takes more information later (GDPR Art. 33(4)). Its pack stays open after you submit it, and your edits go out with the next supplementary notification. When you send one, select **Record supplementary notification**, set **Sent at (Oslo time)** and, if you like, **What changed**. Pharus keeps a snapshot of the pack as it is then.
Every submission, reference, supplementary notification and void lands in the [audit trail](/reports/audit-trail).
## NIS2
For a company established in Norway, NIS2 is shown as **Tracked**, with the reason "Not yet Norwegian law." Pharus follows it for reference: it has no deadlines and no pack, and nothing about it appears on the **Notices** tab. You can still change its status and recipient on the **Routing** tab.
## In a drill
In a [drill](/incidents/drills), the recipients show as simulated, the tab links to no form or address, and the pack says: "Exercise: don't send this notice to the real authority. Mark it as submitted here and record a made-up reference."
## Related
The Art. 14(7) CSIRT route and the regimes table.
The CRA's 24 h, 72 h and final report clocks.
Classification and Finanstilsynet's reports for financial entities.
The CRA filing in ENISA's Single Reporting Platform.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.