DORA and NIS2 on Windows Servers: logging and incidents

DORA and NIS2 are EU rules on cyber security and operational resilience. Both expect you to detect incidents, record them, judge how serious they are and, for the serious ones, report to the authorities on short deadlines. Much of that is organisation and governance. Part of it happens on your Windows Servers.

This page is a general overview, not legal advice. Which rules apply to you, and what exactly they require, depends on your organisation and, for NIS2, on your country's law. Check with your legal or compliance team.

1. DORA in a few sentences

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) applies from 17 January 2025. It covers a wide range of financial entities, for example banks, investment firms, payment institutions, insurers and crypto-asset service providers, and it also brings critical ICT third-party providers under oversight.

For incidents, DORA asks financial entities to:

• have mechanisms to detect anomalous activities and ICT-related incidents promptly;
• run an ICT-related incident management process to detect, manage and notify incidents, and record ICT-related incidents and significant cyber threats;
• classify incidents by criteria such as the clients affected, the duration, the geographical spread, data losses, how critical the affected services are and the economic impact;
• report major ICT-related incidents to the competent authority: an initial notification, an intermediate report and a final report. The deadlines are set in technical standards, and the first one is counted in hours, not days.

For financial entities that fall under DORA, DORA's rules on ICT risk and incident reporting generally take the place of the corresponding NIS2 rules.

2. NIS2 in a few sentences

The NIS2 Directive (Directive (EU) 2022/2555) had to be turned into national law by October 2024. It applies to essential and important entities in the sectors it lists, such as energy, transport, health, digital infrastructure, public administration and many manufacturing and service sectors, generally medium-sized and larger organisations, and some others regardless of size. The details and the dates depend on your country's law.

NIS2 asks for:

• cyber security risk-management measures, including incident handling, business continuity and supply-chain security;
• management bodies that approve and oversee these measures;
• for a significant incident: an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours and a final report within one month of the notification, to the national CSIRT or competent authority.

3. What this means on a Windows Server

Neither law prescribes a Windows setting. But you can only report on time what you noticed, and only prove what you recorded. On each Server that means:

• Security logging that stays on. Failed logons, firewall decisions and policy changes must be audited. If a policy or an attacker switches auditing off, you need to know.
• A log large enough. The Windows Security log is small by default and overwrites itself. On a busy Server, hours of history can be gone.
• Exact times. Deadlines run from detection. Record times in UTC and keep the Server's clock synchronised.
• A record of each incident: what happened, when it was detected, how it was classified, what was done, and when each report was sent.
• Evidence that can't quietly change: an auditor will want to see that entries were not edited afterwards.
• Changes to the firewall made outside your change process: a switched-off firewall or a new "allow from anywhere" rule is often the first sign of trouble.

4. Doing it with Windows' own tools

• Audit policy: check with auditpol /get /category:* as administrator. Set it centrally with Group Policy (Advanced Audit Policy Configuration).
• Log size: Event Viewer › Windows Logs › Security › Properties, or wevtutil sl Security /ms:<bytes>.
• Central collection: Windows Event Forwarding or a SIEM keeps logs off the Server, where an attacker can't delete them.
• Incident record: a ticket system or a register maintained by hand. It works, but someone has to notice the incident first and write down the times.

The gap is usually in between: the logs exist, but nobody connects a switched-off firewall or a password attack at 3 a.m. to an incident record with a deadline.

5. How Coinetic helps on the Server

Doing this by hand means...

• checking audit settings and log sizes on every Server, again after every Group Policy change;
• someone reading the logs often enough to notice an incident in time, because the deadlines run from detection;
• writing down times, steps and decisions by hand, and proving later that nobody changed them;
• putting together the information for the authority from several logs while the clock is running;
• and still the gaps: a firewall switched off at night, or auditing quietly disabled by a policy, is easy to miss.

With Coinetic: installed in minutes, then it runs by itself

Coinetic works on each Windows Server and PC through the Windows Firewall. Setup installs a protection service that works in the background, also when nobody is logged on. Coinetic does not make you DORA or NIS2 compliant. It helps with specific technical parts: detecting, recording and documenting security incidents on the Server.

• Incidents recorded for you (Pro): a password attack from many addresses, the firewall changed or switched off outside Coinetic, the protection service stopped unexpectedly, or security logging switched off goes into the Server's Incidents (DORA) register by itself. Anything else you add with New incident.
• Classification and deadlines in one place: Coinetic suggests major or not major by DORA's criteria, and you decide. For a major incident it tracks the initial notification, the intermediate report and the final report, warns when one is due and turns the incident red when it is overdue.
• Evidence that holds up: every timeline entry is part of a hash chain, so a later change is shown. Report (DORA) puts together the information for the notification, ready to print or save as PDF; you submit it through your authority's own channel.
• One central register: every new or changed incident can be forwarded to a REST API (for example a SIEM or ticket system), a database (SQL Server or ODBC) or by e-mail to your compliance officer. If the target is unreachable, it waits in a queue.
• History and reports for auditors (Pro): bans, failed logins, port scans, firewall changes made outside Coinetic, incidents and service starts and stops are kept on the Server in UTC, for 13 months by default and up to 10 years. A security report for any period shows the incidents of that period and whether each report was on time; the monthly report can be saved automatically to a folder your auditors can read.
• Logging and firewall that stay on: every 15 seconds Coinetic checks the firewall for changes made outside it and switches a firewall that was switched off back on. It keeps the audit settings and Security log size it needs, and switches auditing back on if a policy switches it off.
• Your AI security analyst (Pro + AI): right-click any line, ban, port or connection and choose Ask AI, e.g. “What happened in this incident, and what goes into the report?”. It looks up this computer's Coinetic data itself and answers in plain words, with what to do on this machine.

What stays with you: the decision whether an incident is major or significant, the notification itself, your policies, your other systems and your legal assessment. Coinetic runs on Windows Server 2008 R2 to 2025 and on Windows 7 to 11, in any Windows language.

More guides: all Coinetic guides.

Frequently asked

Does Coinetic make us DORA or NIS2 compliant?

No. Compliance needs organisational measures: governance, policies, responsibilities, risk management, testing, third-party management and legal advice. Coinetic covers specific technical parts on each Windows Server and PC: detecting incidents, recording them, tracking report deadlines and keeping evidence.

We fall under NIS2, not DORA. Is the incident register still useful?

The register, its timeline, the reports and the forwarding are the same for any incident. Its classification and deadlines follow DORA, so check NIS2's 24-hour, 72-hour and one-month steps, and your national law, yourself.

Does the security history leave the Server?

No. It is kept on the computer. Only what you choose to forward (incidents to your central register) or e-mail (reports) leaves it.

Are Windows' own logs not enough?

They are the raw material. What they don't give you is a record of each incident with its classification, its deadlines and proof that nothing was changed afterwards, and they can be switched off or overwritten without anyone noticing.