NIS2 Incident Report Checklist & Template

Template Overview

An effective NIS2 incident report has six sections. Print this list and keep it in your incident response folder — when something happens, you fill in each section in sequence.

1. Incident Summary (1 paragraph)

What happened, when, what systems were affected, and the current status. Written for a non-technical audience — your client's CEO will read this first.

2. Timeline of Events (bullet list)

When the incident was detected, when it started (estimated), each action taken, and when each action was completed. Precision matters here — regulators will compare your timeline against log data.

3. Impact Assessment

What data was affected (categories, volume, sensitivity), what systems were compromised, what services were disrupted, and what the business impact is. Be honest — underestimating impact damages credibility more than overestimating it.

4. Containment and Remediation

What you did to stop the incident (containment), what you did to remove the cause (eradication), and what you did to restore normal operations (recovery). Include timestamps for each action.

5. Root Cause Analysis

How the incident happened. Not just the technical trigger (a vulnerable plugin, a weak password) but the systemic cause (no update policy, no password rotation). This section answers the question: will it happen again?

6. Preventive Measures

What you are changing to prevent recurrence. Specific actions with deadlines: "MFA enabled for all admin accounts by 1 September" is better than "improving access controls." Include who is responsible and the review date.

Notification Process

When you discover a security incident, follow this process. Time is the critical factor — the 24-hour NIS2 clock starts ticking from the moment you become aware, not from the moment you confirm the details.

Step 1: Initial Notification (Within 1 Hour)

Notify your internal security contact and the affected client's designated contact. By email AND phone. Include: what happened (brief), what systems are affected, and when you will provide the next update.

Step 2: Investigation (24 Hours)

Determine the scope: what data, what systems, what users. Collect logs, take system snapshots, preserve evidence. Prepare the initial NIS2 early-warning notification with whatever information you have.

Step 3: Submit Early Warning (Within 24 Hours)

Submit the NIS2 early-warning report. It does not need to be complete — NIS2 allows incomplete information at the initial stage. The key is demonstrating that you have a process and you are following it.

Step 4: Contain (Within 48 Hours)

Contain the incident. Disconnect affected systems, revoke compromised credentials, block malicious IPs. Document every action with timestamps.

Step 5: Final Report (Within 30 Days)

Complete the full incident report with root cause analysis, impact assessment, and preventive measures. Submit to the client and, if required, to the relevant NIS2 regulator. Keep a copy for your own records.

Step 6: Post-Incident Review (30 Days After Closure)

Review the incident response process itself. What worked? What didn't? Update your incident response plan based on lessons learned. This step is often skipped but it is the most valuable one for improving over time.

Common Mistakes

Five mistakes that turn a manageable incident into a regulatory problem:

1. Waiting to have complete information before notifying. NIS2's 24-hour clock starts at awareness, not at full understanding. Submit an early warning with whatever you know — you can always update it. The fine for late notification is far worse than the fine for incomplete notification.

2. Not documenting everything as it happens. Every phone call, every decision, every command executed. If you do not write it down in real time, you will not remember it accurately 30 days later when the final report is due.

3. Downplaying the impact. The temptation is to minimise the incident to avoid alarm. Regulators and clients have seen this before. An impact assessment that turns out to be too optimistic destroys your credibility. State the worst reasonable case.

4. Forgetting the post-incident review. The incident itself is a learning opportunity. Agencies that skip the post-incident review repeat the same mistakes. Those that conduct it systematically improve their security posture over time.

5. Not having a template ready before an incident. Writing an incident report from scratch under time pressure produces poor reports. A pre-written template with placeholders turns a panic into a process.

Sample Template

Below is a fill-in template you can adapt for your agency. Keep it in your incident response folder and update it annually.

INCIDENT REPORT — [Agency Name]

Report Number: IR-[YEAR]-[001]

Classification: [Critical / High / Medium / Low]

Status: [Open / Contained / Resolved]

1. Incident Summary

On [DATE] at [TIME], [describe what happened briefly — e.g. "unauthorised access detected on client hosting panel"]. Affected systems: [list]. Current status: [open/contained/resolved].

2. Timeline

[TIME] — Incident detected by [source]

[TIME] — Investigation started

[TIME] — Containment initiated: [action]

[TIME] — Client notified

[TIME] — Early warning submitted

3. Impact Assessment

Affected data categories: [e.g. names, emails, financial data]

Number of records: [estimate]

Sensitivity level: [low / medium / high]

Services disrupted: [list]

Business impact: [description]

4. Containment and Remediation

[Describe actions taken to contain, eradicate, and recover. Include timestamps.]

5. Root Cause Analysis

Technical cause: [e.g. outdated plugin with known CVE]

Systemic cause: [e.g. no automated update policy]

6. Preventive Measures

[Action] — Owner: [name] — Deadline: [date]

Prepared by: [Name] Date: [Date]

Reviewed by: [Name] Date: [Date]

Going Deeper

Our NIS2 Compliance for Small Web Agencies e-book includes a complete incident response plan template, 5 contract clauses, and a 30-day compliance checklist — everything your agency needs.

Get the Complete NIS2 E-Book → NIS2 Readiness Guide →

Frequently Asked Questions

Does my 3-person agency really need an incident reporting process?

If you serve clients who are in NIS2 scope (50+ employees in critical sectors), yes. They will require it in their vendor agreements. And if a serious incident happens on a client site you manage, having a documented process is the difference between a professional response and a relationship-ending scramble.

What counts as an "incident" under NIS2?

NIS2 defines incident broadly: any event that compromises the availability, authenticity, integrity, or confidentiality of stored or transmitted data. A hacked admin account, a ransomware attack, a data leak, a DDoS that takes a client site down — all of these are incidents that trigger the reporting obligation.

Can I submit an incomplete initial report?

Yes — NIS2 explicitly allows it. The early warning (24 hours) is a notification, not a full report. You provide whatever information you have and update it as you learn more. The critical requirement is to NOTIFY within 24 hours, not to have all the answers within 24 hours.

What happens if I miss the 24-hour deadline?

Late notification is a violation of NIS2 Article 21(2)(c) and could result in enforcement action. For small agencies acting as subcontractors, the penalty is typically contractual (loss of contract, professional indemnity issues) rather than direct NIS2 fines — but the reputational damage is significant.

Where do I keep incident reports?

Store completed reports in an encrypted, access-controlled location separate from the systems that were affected. Keep them for at least 2 years (the NIS2 review period for enforcement). Use a naming convention that makes them easy to retrieve: IR-2026-001, IR-2026-002, etc.

Get the Complete NIS2 E-Book → NIS2 Readiness Guide →

Related Guides

UPTIME

NIS2 Incident Report
Checklist & Template

Why Incident Reporting

24-Hour Timeline

Final Report Within 1 Month

Template Is Required