DORA audit requirements and what you report each year

A running DORA programme sends three things to Finanstilsynet on a deadline and keeps a fourth on the shelf for whoever asks. Here is what each one is, when it goes, and who has to have signed it first.

This is the steady-state guide. If you are still standing the programme up, start with our DORA checklist for Norwegian financial firms and come back here. DORA has applied in Norway since 1 July 2025, the day the Norwegian DORA act and the DORA regulation entered into force.

1. Submit the register of information once a year

The register of information lists every ICT service contract you hold, and Norwegian firms send it to Finanstilsynet once a year.

You maintain and update the register at entity level, and at sub-consolidated and consolidated level if you sit in a group (DORA article 28(3)). The same paragraph makes you report at least yearly on new arrangements, the categories of ICT provider, the contract types, and the services being delivered.

In Norway the file goes through the e-Reg portal in XBRL-CSV, on the templates in Commission Implementing Regulation (EU) 2024/2956. The first round closed 13 March 2026 and covered calendar year 2025. Finanstilsynet passes the files to the European supervisory authorities by 31 March each year.

Two things decide whether your file is accepted. Every provider needs an LEI or EUID code, and so does every subcontractor supporting a critical or important function. And every contract needs a critical-or-important marking you can defend, which means the business impact analysis behind the marking has to exist on paper.

Set aside time after the deadline, not only before it. In the first Norwegian round, submissions came back rejected on EBA validation rules, and Finanstilsynet held a correction window open to 30 April 2026.

2. Notify planned ICT contracts 30 days before they take effect

You notify Finanstilsynet before an ICT contract supporting a critical or important function takes effect, and Norway reads that as 30 days ahead.

The regulation words the deadline as “in good time” (article 28(3)). Finanstilsynet has put a number on that phrase: at least 30 days before the agreement or the change takes effect, on Altinn form KRT-1121, per its circular on notifying ICT service agreements.

That distinction matters. The 30 days is Norwegian supervisory practice, not a figure in the regulation, and it is still the number your supervisor counts against. Put it in the procurement calendar so legal does not discover it in week one of a renegotiation.

3. Run the incident clock in three stages

A major ICT incident produces three reports: initial within 4 hours, intermediate within 72 hours, final within a month.

Classification comes first. An incident counts as major when it hits critical services and either gives an attacker successful, malicious and unauthorised access that risks data loss, or trips two or more of the other materiality criteria: clients and transactions affected, reputation, duration and downtime, geographical spread, data losses, and economic impact (Commission Delegated Regulation (EU) 2024/1772).

Then the clock runs. The initial notification goes within 4 hours of the moment you classify the incident as major, and no later than 24 hours after you became aware of it. The intermediate report follows within 72 hours of the initial notification. The final report lands within one month of the last intermediate report (Commission Delegated Regulation (EU) 2025/301, article 5).

There is a weekend and holiday extension to noon on the next working day. It does not reach credit institutions, central counterparties, operators of trading venues, or firms designated essential or important under NIS2. Check which list you are on before you plan a Saturday.

In Norway the reports go through Finanstilsynet’s reporting solution, with the mechanics set out in the circular on incident reporting under DORA. Finanstilsynet confirmed in 2026 that fields 4.7 and 4.8 accept future dates, so you can report a planned completion instead of holding the report back.

The four-hour clock starts at classification, not at detection. So rehearse the classification decision, not the form. Name the person who makes it, name a deputy, and log the time they were reached.

4. Put the ICT audit plan in front of the board

DORA sends the ICT internal audit plan to the management body for approval (article 5(2)(f)).

The board approves and periodically reviews the ICT internal audit plans, the ICT audits themselves, and any material change to them. That is a standing agenda item with minutes, not a one-time sign-off in year one.

The audit carries two conditions (article 6(6)). Your auditors need sufficient knowledge, skills and expertise in ICT risk. They also need appropriate independence. Frequency and focus scale with the firm’s ICT risk, so a payment institution running one core platform and a bank with forty integrations do not get the same plan. Microenterprises sit outside the internal audit requirement.

Independence has a defined shape. ICT risk management, the control function and internal audit stay segregated, on a three lines of defence model or an equivalent internal risk management and control model (article 6(4)). Write down who audits and why they are both competent and independent. Competence is a documented judgment, the same way a Lead Implementer and a Lead Auditor are separate roles on an ISO 27001 project.

5. Close critical audit findings on a written deadline

A formal follow-up process for critical ICT audit findings is a DORA obligation, not good practice (article 6(7)).

The regulation asks for rules on timely verification and remediation. It does not define timely. Defining it is your job, and your definition is what an auditor tests. Give each severity a deadline in days, name the owner, and log the evidence that closed it.

The framework itself gets reviewed at least once a year (article 6(5)). It also gets reviewed after a major incident, after supervisory instructions, and after conclusions from testing or audit. Those triggers sit alongside the annual cycle, and they are the ones firms forget. The same paragraph lets the supervisor ask for the review report, so write the review as a document, not as a meeting.

After a major incident that disrupted core activities, run a post-incident review (article 13(2)). Firms other than microenterprises tell the authority what they changed, on request. Keep the review and the change record in the same folder.

6. Keep the ordinary-day evidence pack current

On an ordinary day with no incident running, an auditor asks for six things.

• The current register of information, plus the e-Reg receipt from the last submission.
• Board minutes approving the ICT internal audit plan, and the written annual framework review.
• The incident log, including the incidents you classified as not major and the reason why.
• The follow-up register for critical ICT audit findings, with dates opened and dates closed.
• The KRT-1121 notifications, dated so they can be compared against signature dates.
• The results of the digital operational resilience testing programme.

That sixth item is its own subject. DORA runs a separate testing regime, including yearly tests of the systems supporting critical or important functions (article 24(6)), and our guide to recurring penetration testing under DORA covers what that means in delivery. FM CyberSecurity handles the scanning and testing side through our vulnerability management practice.

The other five are record keeping. They fail the same way every year, because nobody owns the files between reporting rounds.

Next action

Take the six items above and check whether you could produce each one today without asking anyone. Two or more misses, and that is the gap to close before the next reporting round.

Johan Vorgaard leads DORA work in our compliance practice and will go through your register, your audit plan and your incident classification rules with you in 30 minutes. If the gap turns out to be capacity rather than paperwork, our consultants can hold the files between rounds. Bring the last board minutes that mention ICT.

FAQ

How often do we report the register of information under DORA?

At least yearly (article 28(3)). In Norway the first submission closed 13 March 2026 and covered calendar year 2025, through the e-Reg portal, and Finanstilsynet forwards the files to the European supervisory authorities by 31 March.

When does the four-hour reporting clock start?

At classification, not at detection. You have 4 hours from the moment you classify the incident as major, capped at 24 hours from when you became aware of it (Regulation (EU) 2025/301, article 5). That is why the classification decision is the part worth rehearsing.

Can the person who owns ICT risk also sign off the internal audit?

No. Auditors of the ICT risk management framework need appropriate independence (article 6(6)), and DORA asks for segregation between ICT risk management, control functions and internal audit under a three lines of defence model or an equivalent (article 6(4)). Small firms usually solve this with an external auditor on a named mandate.

Does DORA apply to us in Norway, and since when?

The Norwegian DORA act (lov 2025-05-27-18) and the DORA regulation (forskrift 2025-06-24-1296) both entered into force 1 July 2025. If Finanstilsynet supervises you, DORA almost certainly applies to you.

Where does DORA stop and Finanstilsynet’s own expectations start?

DORA sets the obligation, Finanstilsynet sets the Norwegian mechanics. The 30-day notice on ICT contracts is the clearest case: the regulation says “in good time”, the Norwegian circular reads that as at least 30 days. Note both in your framework, and note which one is which, because an auditor will ask where the number came from.

Drafted with AI assistance, reviewed and edited by Johan Vorgaard and the FM CyberSecurity editorial team.