Data Breach Plan Ireland: 12 Steps, 72-Hour Deadline [2026]

Every Irish organisation that holds personal data is now sitting on a 72 hour clock it may never get to see start. Under the General Data Protection Regulation, that clock begins the moment staff become aware of a personal data breach, not the moment anyone finishes investigating it. Miss the deadline, or scramble through it without a plan, and the Data Protection Commission will ask exactly that question: why wasn’t this ready before the breach happened.

Ireland ranked 11th out of 25 EU member states for ransomware claims in 2025, and was one of only eight EU countries hit by all five of the major ransomware groups tracked across the bloc: Qilin, SafePay, Akira, INC Ransom and Hunters International, according to the Irish Examiner’s reporting on ENISA’s Threat Field 2026 findings. Ransomware alone accounted for roughly 40% of financially motivated cyber incidents recorded across the EU last year. This tutorial builds a complete, working data breach response plan for an Irish business: the detection pipeline, the severity scoring, the containment runbook, the GDPR 72 hour notification workflow, and the NIS2 early warning layer that now sits on top of it. By the end you will have a tested, version controlled incident response kit, not a PDF nobody reads until it is too late.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add TrendinTech Ireland once in the Google app and our stories appear in your news suggestions.

Add Now

Why Every Irish Business Needs a Documented Data Breach Response Plan

A data breach response plan is the difference between a controlled 72 hour process and a chaotic scramble that invites regulatory scrutiny on top of the original incident. The Data Protection Commission (DPC) has been explicit about what it expects to see: organisations must notify within 72 hours of becoming aware of the breach, and to hit that window reliably, you need detection, investigation and reporting processes built in advance, not improvised on the day.

The numbers explain why this has become urgent. Limerick Post reported that one in three Irish SMEs have experienced a cyberattack, with Irish SMEs losing an estimated 7.2 million working days annually to cyber incidents, citing research from Unitec IT Solutions. Separately, a William Fry technology report found that only 17% of Irish businesses feel very or extremely confident their cybersecurity posture is keeping pace with AI driven threats, and 20% reported no confidence at all. That confidence gap is exactly where a documented, tested data breach response plan closes the distance between “we think we’re covered” and “we know what happens in the first hour.”

There’s also a second regulator now watching. NIS2 (Directive (EU) 2022/2555) layered an early warning obligation on top of GDPR’s existing reporting duty for operators of essential and important services, including many mid-sized tech, energy, health and digital infrastructure firms in Ireland. As described on a Skadden podcast covering the directive, “so now a big change is that you have to file an early warning to the relevant regulator, and then followed by a full incident report within 72 hours.” If your organisation falls under NIS2 scope, your breach plan needs two parallel notification tracks running at once, and the sections below cover both.

Prerequisites: What You Need Before You Start

This is a process and tooling build, not a single software install, so the prerequisites cover both the technical environment and the organisational pieces you need lined up before Step 1.

• Python 3.11 or later, for the severity scoring script and log parsing examples
• Bash on Linux or macOS (or WSL2 on Windows) for the containment and backup verification scripts
• A centralised log source: application logs, firewall logs, identity provider sign in logs, and endpoint detection logs, ideally already flowing into one place
• Git, for version controlling your incident response runbook so changes are auditable
• OpenSSL 3.x, used here for hashing evidence files during forensic preservation
• A password manager with enforced multi factor authentication for every account with admin rights (the internal link below compares the two leading consumer grade options if you need to pick one for a small team)
• A named Data Protection Officer or equivalent contact, and a direct line to your legal counsel
• Knowledge of whether your organisation falls under NIS2 scope as an essential or important entity; if you are unsure, your sector regulator or the National Cyber Security Centre can confirm this
• An existing backup solution with at least one immutable or offline copy (see the backup section below for how to test this properly)

None of the code Requires paid tooling. Every script below runs on open source utilities already present on most Linux distributions, with Python and OpenSSL as the only two dependencies you may need to install.

Step 1: Define What Actually Counts as a Personal Data Breach

Before you can respond to a breach, your team needs a shared, written definition of what one is. Under GDPR Article 4(12), a personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That covers far more than a hacker stealing a database. A misdirected email with a customer list attached, a lost unencrypted laptop, a misconfigured cloud storage bucket left open to the public, and an employee accessing records outside their role are all personal data breaches under this definition. Our coverage of the Veradigm data breach is a useful real-world reminder that even a breach affecting a relatively small group of people still triggers the same notification duties described below.

Write this definition into a one page document and circulate it to every manager, not just the security team. The Department of Children, Disability and Equality’s own breach management policy makes the escalation point directly: a staff member who discovers that a suspected or actual breach has occurred should report this to their line manager and Head of Unit (or equivalent) immediately, given the strict reporting timelines involved. If your non-technical staff do not recognise a breach when they see one, your 72 hour clock starts running before anyone on the response team even knows about it.

Step 2: Build Your Breach Response Team and Assign Roles

A response plan without named owners is a document, not a plan. Set up a small core team with explicit backups for every role, because breaches do not wait for the right person to be back from leave.

Role	Primary Responsibility	Decision Authority	Response Window
Incident Commander	Owns the overall response, coordinates all workstreams	Can pause systems, approve containment actions	First point of contact within 1 hour
Data Protection Officer / Lead	Runs the GDPR risk assessment and DPC notification	Decides if notification threshold is met	Engaged within 4 hours of detection
Technical Lead (IT/Security)	Contains the incident, preserves evidence, restores from backup	Can isolate systems and revoke credentials	On call, immediate
Legal Counsel	Advises on regulatory exposure, contractual notification duties	Reviews all external communications	Within 4 hours
Communications Lead	Drafts customer and public statements	Approves all external messaging	Before any individual notification goes out
Executive Sponsor	Final sign off on notification decisions and resourcing	Can authorise emergency spend	Briefed within 4 to 8 hours

For smaller companies, one person may hold two or three of these roles, but write the roles down separately anyway. It forces you to notice gaps, such as nobody currently owning legal review, before a real incident does it for you. If you use dedicated identity and access tooling to enforce least privilege across this team, the CrowdStrike, SentinelOne and Microsoft Defender comparison we published covers how each platform handles the detection and alerting side that feeds this team its first signal.

Step 3: Set Up Centralised Breach Detection and Logging

You cannot notify the DPC about a breach you do not know happened. Centralise logs from identity providers, firewalls, endpoints and critical applications into one searchable location before you need it, not during an incident. At minimum, capture authentication events (successful and failed logins), file access on systems holding personal data, outbound data transfers, and administrative actions like permission changes or account creation.

A simple normalised log format makes the next steps, especially severity scoring, far easier to automate. Here is a minimal schema you can adapt into whatever log shipper you already run:

{
  "timestamp": "2026-10-16T09:14:32Z",
  "source": "idp-login",
  "event_type": "failed_login",
  "actor": "[email protected]",
  "ip_address": "203.0.113.45",
  "resource": "payroll-db",
  "data_classification": "personal_data",
  "record_count_estimate": 0,
  "country_of_origin": "unknown"
}

The two fields that matter most for breach response specifically are data_classification and record_count_estimate. If your logging pipeline cannot answer “which systems hold personal data and roughly how many records” within minutes of an alert, your 72 hour risk assessment in Step 7 will take far longer than it should.

Step 4: Automate Initial Severity Triage

Not every security alert is a notifiable data breach, and treating every alert as a five alarm fire burns out your response team fast. Build a simple, transparent severity scoring script that your Incident Commander can run the moment an alert fires, to decide whether this escalates to the full response team or gets handled as routine security hygiene.

#!/usr/bin/env python3
"""Breach severity triage script.
Scores an incident 0-10 based on data sensitivity, scope, and exposure.
"""

def score_incident(data_classification, record_count, external_exposure, special_category):
    score = 0

    classification_weights = {
        "public": 0,
        "internal": 1,
        "personal_data": 3,
        "sensitive_personal_data": 5,
    }
    score += classification_weights.get(data_classification, 1)

    if record_count > 10000:
        score += 4
    elif record_count > 1000:
        score += 3
    elif record_count > 100:
        score += 2
    elif record_count > 0:
        score += 1

    if external_exposure:
        score += 2

    if special_category:
        score += 2

    return min(score, 10)


def classify(score):
    if score >= 8:
        return "CRITICAL - notify DPO and Incident Commander immediately"
    if score >= 5:
        return "HIGH - escalate to full response team within 1 hour"
    if score >= 3:
        return "MEDIUM - DPO review within 4 hours"
    return "LOW - log and monitor, no immediate escalation"


if __name__ == "__main__":
    result = score_incident(
        data_classification="sensitive_personal_data",
        record_count=4500,
        external_exposure=True,
        special_category=True,
    )
    print(f"Severity score: {result}/10 -> {classify(result)}")

Running this against a sample incident involving 4,500 records of sensitive personal data with external exposure produces a score of 10, which classifies as CRITICAL and triggers immediate escalation. Keep this script in version control alongside your runbook, and review the weightings every quarter with your DPO, since what counts as “special category” data under GDPR Article 9 (health, biometric, political opinion, and similar data) should always score higher regardless of record count.

Step 5: Contain the Incident Before You Investigate Further

Once an incident crosses your escalation threshold, containment comes before deep investigation. The Department of Children, Disability and Equality’s breach management policy lays out a five step structure that matches what most Irish data controllers now follow: identification, classification and internal notification; containment and recovery; risk assessment; notification of breach (external); and evaluation and response. Containment is step two for a reason, it stops the bleeding before you spend hours working out exactly how bad it is.

Recommended containment actions, drawn from DPC guidance, include isolating affected systems, revoking compromised credentials, and preserving forensic evidence before anything is wiped or rebuilt. Here is a basic containment script that handles the two most common actions: network isolation of a host and immediate credential revocation for a compromised account, written generically so you can substitute your own firewall and identity provider commands.

#!/bin/bash
# containment.sh - isolate a host and revoke a compromised account
# Usage: ./containment.sh  

HOST_IP="$1"
COMPROMISED_USER="$2"
LOG_FILE="/var/log/incident-response/containment-$(date +%Y%m%d-%H%M%S).log"

mkdir -p /var/log/incident-response

echo "Containment started for host $HOST_IP and user $COMPROMISED_USER" | tee -a "$LOG_FILE"

# Isolate the host at the firewall (adapt to your firewall's CLI/API)
iptables -I INPUT -s "$HOST_IP" -j DROP
iptables -I OUTPUT -d "$HOST_IP" -j DROP
echo "Host $HOST_IP isolated via iptables" | tee -a "$LOG_FILE"

# Disable the compromised account (adapt to your identity provider's CLI)
# Example for a local Linux account:
usermod -L "$COMPROMISED_USER" 2>/dev/null
echo "Account $COMPROMISED_USER locked locally" | tee -a "$LOG_FILE"

# Flag for identity provider revocation (replace with your IdP's API call)
echo "ACTION REQUIRED: revoke SSO sessions and reset credentials for $COMPROMISED_USER in your identity provider" | tee -a "$LOG_FILE"

echo "Containment log written to $LOG_FILE"

Keep every containment action timestamped and logged. You will need this exact sequence of events later, both for the DPC notification and for any legal or insurance review that follows. Also take a snapshot of affected credentials for a password manager audit; if admin accounts were sharing passwords across services, that is exactly the kind of weak point tools like the ones compared in our Bitwarden versus 1Password breakdown for Irish teams are designed to close before the next incident.

Step 6: Preserve Forensic Evidence Correctly

Containment is not the same as cleanup, and a common mistake is wiping or rebuilding a compromised system before anyone has captured evidence of what happened. Preserve copies of relevant logs, memory dumps where feasible, and disk images, each hashed immediately so you can later prove the evidence was not altered.

# Capture a hash of each evidence file at the moment of collection
find /var/log/incident-response/evidence -type f -exec sha256sum {} \; > evidence-manifest.sha256

# Verify later that nothing in the evidence set has changed
sha256sum -c evidence-manifest.sha256

Store the evidence manifest somewhere separate from the evidence itself, ideally in a write once location or a version controlled repository with restricted access. If the incident ends up in front of the DPC, your legal counsel, or an insurer, a clean chain of custody for the evidence is often what separates a defensible response from a disputed one.

Step 7: Run the GDPR 72 Hour Risk Assessment

This is the step most teams get wrong under pressure, because the 72 hour clock is not 72 hours to investigate, it is 72 hours to notify, and the clock started when you became aware, not when you finished investigating. The DPC’s own guidance states the deadline plainly: organisations must notify within 72 hours of becoming aware of the breach. If you cannot complete a full assessment in that window, GDPR allows a phased notification, where you notify what you know now and follow up with details as the investigation continues, rather than missing the deadline entirely.

The DPC also frames the preparation work clearly: to facilitate decision-making and determine whether or not your organisation needs to notify the relevant supervisory authority and affected individuals, you should have a high quality risk management process and solid breach detection, investigation and reporting processes in place beforehand. In practice, your risk assessment needs to answer four questions: what data was involved, how many individuals are affected, what harm could result (financial loss, identity theft, discrimination, reputational damage), and whether the breach is likely to result in a risk to the rights and freedoms of those individuals.

When You Must Notify the DPC

Notification to the DPC is required unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. In practice, that threshold is low: most breaches involving personal data beyond a trivial internal mix up should be notified. Document the reasoning either way, because “we decided not to notify” without a written rationale is itself a compliance gap if the DPC later asks.

Step 8: Submit the DPC Breach Notification

Once the risk assessment confirms notification is required, submit through the DPC’s breach notification channel with a structured record of what you know. Build the notification payload as a template in advance so nobody is drafting prose under deadline pressure. A structured internal record, even before you transcribe it into the DPC’s own form, should look something like this:

{
  "notification_type": "GDPR_Article_33",
  "breach_detected_at": "2026-10-16T09:14:32Z",
  "breach_discovered_at": "2026-10-16T10:02:11Z",
  "nature_of_breach": "unauthorised_access",
  "categories_of_data": ["contact_details", "payroll_data"],
  "approximate_record_count": 4500,
  "special_category_data": true,
  "likely_consequences": "risk of identity theft and financial fraud for affected employees",
  "containment_measures_taken": [
    "isolated affected host",
    "revoked compromised credentials",
    "restored from immutable backup dated 2026-10-15"
  ],
  "dpo_contact": "[email protected]",
  "individuals_notified": false,
  "phased_notification": true
}

Having this structure ready before an incident means your DPO is filling in values, not designing a form, while the clock runs. Keep a copy of every submitted notification and the DPC’s acknowledgement, since both become part of the evaluation and response phase later.

Step 9: Notify Affected Individuals Without Undue Delay

Separate from the DPC notification, a higher bar applies before you must tell the affected individuals directly: this is required only where the breach is likely to result in a high risk to their rights and freedoms, but once that bar is met, the DPC’s guidance requires informing them without undue delay, which is a stricter standard than the 72 hour window since there is no fixed grace period at all.

Your communications lead should have a notification template ready that covers, in plain language: what happened, what data was involved, what you have done to contain it, and what the individual should do themselves (reset passwords, watch for phishing attempts referencing the breach, monitor financial statements). Avoid legal hedging in this communication. Individuals who receive a vague, lawyer-written notice are more likely to escalate to the DPC themselves out of frustration, which adds a second front to your response.

Step 10: Layer NIS2 Early Warning Reporting On Top

If your organisation is in scope for NIS2 as an essential or important entity, you have a second, faster obligation running in parallel to GDPR. As explained on a Skadden podcast covering the directive’s rollout, the new structure requires filing an early warning to the relevant regulator, followed by a full incident report within 72 hours. That early warning window is typically far shorter than 72 hours, often within 24 hours of becoming aware, so your triage script from Step 4 needs to flag NIS2 applicability as a field, not an afterthought you remember halfway through the GDPR process.

Obligation	Regulation	Who It Applies To	Reporting Deadline
Supervisory authority notification	GDPR Article 33	Any data controller processing personal data	72 hours from becoming aware
Individual notification	GDPR Article 34	Controllers where breach poses high risk to individuals	Without undue delay (no fixed deadline, but as soon as possible)
Early warning	NIS2 (EU 2022/2555)	Essential and important entities in scope	Typically within 24 hours of becoming aware
Full incident report	NIS2 (EU 2022/2555)	Essential and important entities in scope	Within 72 hours of becoming aware
Final report	NIS2 (EU 2022/2555)	Essential and important entities in scope	Within one month of the incident report

PwC Ireland’s Annual Threat Dynamics 2026 report frames this shift bluntly: DORA and NIS2 are raising resilience, governance and accountability expectations across Irish organisations, moving the conversation away from a tick box compliance exercise. Build your plan on the assumption that both regulators may be reading your incident timeline, not just one.

Step 11: Build and Test Immutable Backups

A data breach response plan that assumes you can always restore clean data is only as good as your last successful, verified backup restore. Ransomware specifically targets backups first in many modern attacks, so an immutable or offline copy that an attacker with domain admin cannot touch is non-negotiable. Run a restore test on a schedule, not just when you remember to.

#!/bin/bash
# backup-verify.sh - confirm the latest backup is restorable and unmodified
# Adapt the restore command to whatever backup tool you run

BACKUP_DATE=$(date +%Y-%m-%d)
RESTORE_TEST_DIR="/tmp/backup-verify-$BACKUP_DATE"
mkdir -p "$RESTORE_TEST_DIR"

echo "Starting backup verification for $BACKUP_DATE"

# Example restore command, replace with your backup tool's restore syntax
# e.g. restic restore latest --target "$RESTORE_TEST_DIR"
echo "Restoring latest snapshot to $RESTORE_TEST_DIR..."

if [ -d "$RESTORE_TEST_DIR" ] && [ "$(ls -A "$RESTORE_TEST_DIR")" ]; then
    echo "PASS: backup restored and contains data"
else
    echo "FAIL: backup restore produced no data, escalate immediately"
    exit 1
fi

# Clean up the test restore
rm -rf "$RESTORE_TEST_DIR"
echo "Verification complete for $BACKUP_DATE"

If you are choosing or re-evaluating backup tooling for this purpose, our comparison of Veeam, Rubrik and Cohesity covers how their ransomware warranty terms and immutability guarantees differ, which matters directly for this step. Whatever platform you run, the test above should be scheduled weekly at minimum, and the result logged alongside your incident response records, since “we have backups” and “we have tested, restorable backups” are very different claims to make to a regulator or an insurer after an incident.

Step 12: Run a Tabletop Exercise and Post Incident Review

The final step of the Department of Children, Disability and Equality’s five step structure is evaluation and response, and this is the step most plans skip entirely because the pressure is off once the immediate incident is resolved. Schedule a tabletop exercise at least twice a year, walking the full response team through a realistic scenario: a phishing email leading to compromised credentials, a ransomware encryption event, or a misconfigured cloud bucket exposing customer records. Include suppliers and third parties in at least one exercise a year, since PwC Ireland’s resilience framing specifically calls out third party risk as a growing attack vector.

After every real incident, run a structured post-incident review within two weeks while details are fresh: what worked, what took too long, which step in this plan needs updating, and whether the severity scoring from Step 4 would classify the same incident correctly if it happened again. Feed every lesson back into the runbook in the project section below, and commit the change to version control with a clear message explaining why it changed.

Common Pitfalls When Building a Data Breach Response Plan

• Starting the clock from the wrong moment. The 72 hours begins when any staff member becomes aware of a potential breach, not when the investigation confirms it. Teams that wait for certainty before starting the clock routinely blow the deadline.
• No backup owner for key roles. If your Incident Commander or DPO is on leave with no named deputy, the plan stalls at the worst possible moment.
• Treating every alert as equally urgent. Without severity triage like the script in Step 4, response teams either burn out from false alarms or miss the genuinely critical incident buried among routine noise.
• Wiping systems before preserving evidence. Rebuilding a compromised server immediately feels productive but destroys the forensic trail you need for the DPC notification and any insurance claim.
• Assuming backups work without testing them. Many organisations discover their backups are corrupted, incomplete, or themselves encrypted by ransomware only during an actual restore attempt.
• Writing legally dense individual notifications. Over-lawyered breach notices increase the chance that recipients panic or escalate directly to the DPC rather than following your guidance.
• Never running a tabletop exercise. A plan that has never been rehearsed tends to fall apart on contact with a real incident, usually at exactly the step nobody practiced.

Troubleshooting Your Data Breach Response Plan

• The severity script flags every incident as critical. Review your classification_weights in Step 4; teams new to the script often set every category too high out of caution, which defeats the purpose of triage.
• We missed the 72 hour deadline because the investigation wasn’t finished. Submit a phased notification with what you currently know rather than waiting for completeness; the DPC accepts partial initial notifications followed by updates.
• We can’t tell how many records were affected. This points to a logging gap from Step 3. Add record count estimation to your application logging now, even a rough order of magnitude is better than “unknown” in a DPC filing.
• Legal and technical teams disagree on notification thresholds. Put the four risk assessment questions from Step 7 in writing and require both teams to answer them independently before a joint decision, rather than debating from differing assumptions.
• The backup restore test keeps failing. Check whether your backup software’s retention policy is pruning snapshots before the verification job runs, this is one of the most common causes of silent backup failure.
• Staff aren’t reporting suspected breaches. This usually means Step 1’s definition was never actually circulated beyond the security team. Re-run a short awareness session with real examples, not just the legal definition.
• The containment script locked out a legitimate admin account by mistake. Build a documented emergency unlock procedure as part of the same script, with a required sign off from the Incident Commander so false positives don’t become their own incident.
• We don’t know if NIS2 applies to us. Check your sector classification against the NIS2 scope list for essential and important entities; many mid-sized technology, health, energy and digital infrastructure providers in Ireland are in scope even if they assumed otherwise.
• The evidence manifest hash check fails after collection. This typically means a file was touched (even by an antivirus scan or backup job) after collection but before hashing; isolate the evidence drive from any automated processes first.

Advanced Tips for a Mature Breach Response Programme

Once the core plan is running, a few refinements separate a baseline programme from a genuinely mature one. First, automate the severity triage script in Step 4 to run directly against your SIEM or log aggregator’s alert stream, rather than requiring a human to copy data in manually, so the first severity score exists within seconds of detection rather than minutes.

Second, extend your joiner-mover-leaver process so that account deprovisioning is itself logged and auditable. PwC Ireland’s 2026 threat reporting places privileged access reviews and joiner-mover-leaver controls at the centre of resilience planning for exactly this reason: a huge share of breaches trace back to access that should have been revoked months earlier. Third, build supplier and third party breach notification clauses directly into contracts, specifying a notification deadline to you that is shorter than your own regulatory deadline, so you are never waiting on a vendor’s internal process before your own clock has even started properly.

Finally, track your own notification history over time. The DPC’s enforcement patterns respond to repeated or poorly handled notifications more than isolated ones, and Lunyb’s analysis of Irish data breach trends noted DPC notifications rose from roughly 6,000 in 2023 to more than 8,500 in 2025, a volume that means regulators are increasingly comparing your organisation’s response quality against a much larger pool of filings than in previous years.

Complete Working Project: The Incident Response Runbook

Bring every step above together into a single version controlled runbook file. This YAML structure is deliberately simple so any team member can read and update it without specialist tooling, while still being machine readable enough to drive automation later.

incident_response_runbook:
  version: "1.0"
  last_reviewed: "2026-10-16"
  team:
    incident_commander: { name: "TBD", backup: "TBD" }
    dpo_lead: { name: "TBD", backup: "TBD" }
    technical_lead: { name: "TBD", backup: "TBD" }
    legal_counsel: { name: "TBD", backup: "TBD" }
    comms_lead: { name: "TBD", backup: "TBD" }

  steps:
    - id: 1
      name: "Detect and classify"
      script: "severity_triage.py"
      owner: "technical_lead"
    - id: 2
      name: "Contain"
      script: "containment.sh"
      owner: "technical_lead"
    - id: 3
      name: "Preserve evidence"
      script: "evidence-hash.sh"
      owner: "technical_lead"
    - id: 4
      name: "GDPR risk assessment"
      owner: "dpo_lead"
      deadline_hours: 72
    - id: 5
      name: "NIS2 early warning (if in scope)"
      owner: "dpo_lead"
      deadline_hours: 24
    - id: 6
      name: "DPC notification"
      owner: "dpo_lead"
      deadline_hours: 72
    - id: 7
      name: "Individual notification (if high risk)"
      owner: "comms_lead"
      deadline: "without undue delay"
    - id: 8
      name: "Restore from verified backup"
      script: "backup-verify.sh"
      owner: "technical_lead"
    - id: 9
      name: "Post-incident review"
      owner: "incident_commander"
      deadline_days: 14

  nis2_in_scope: false
  backup_test_schedule: "weekly"
  tabletop_exercise_schedule: "twice yearly"

Commit this file, the three scripts referenced inside it, and your notification templates into a private Git repository with access limited to the response team. Review and update it after every tabletop exercise and every real incident, and change last_reviewed every time so nobody is ever working from a runbook that is quietly a year out of date.

Keeping the Plan Current as Regulations Evolve

GDPR and NIS2 obligations are not static, and the cyber vendor tooling field underneath them is moving quickly too. Cyber Vendor Guide’s own tracking recorded 45 new cybersecurity tools added to its directory in September 2026 alone, taking the running total to 262 across 11 categories, up from 27 additions the previous month. That pace of change means the detection and response tooling your plan assumes today may have better, cheaper or faster alternatives within a year, so build a quarterly review into the runbook specifically to re-check your tooling choices, not just your process steps.

Set a calendar reminder tied to major regulatory milestones too. NIS2 transposition is still settling into Irish law at sector level, and DORA enforcement for financial entities is maturing in parallel, so a plan written in early 2026 should not be treated as finished. Assign the quarterly review itself as a runbook step with a named owner, exactly like every other item in the YAML file above, so the review happens on schedule rather than only after the next incident forces it. For more coverage of the threats driving this shift, see our cybersecurity section.

Frequently Asked Questions

How many hours do I have to report a data breach in Ireland?

Under GDPR, you have 72 hours from the moment you become aware of a notifiable personal data breach to notify the Data Protection Commission. If your organisation is also in scope for NIS2, an earlier warning is typically required within around 24 hours, with a full incident report due within the same 72 hour window.

Do I have to notify every person affected by a data breach?

No. Individual notification under GDPR Article 34 is only required where the breach is likely to result in a high risk to the affected individuals’ rights and freedoms. Notification to the DPC has a lower threshold and applies more broadly, unless the breach is unlikely to pose any risk at all.

What happens if I miss the 72 hour deadline?

A late notification does not automatically trigger enforcement, but you will typically need to explain the delay. GDPR allows phased notification, where you report what you know within the window and supply further detail as the investigation continues, which is almost always a better outcome than waiting for a complete picture before notifying at all.

Is a lost laptop a reportable data breach?

It can be, depending on whether the device held personal data and whether it was encrypted. An unencrypted laptop containing personal data that goes missing is generally treated as a confidentiality and availability breach and should go through your full risk assessment process in Step 7.

How is NIS2 different from GDPR for breach reporting?

GDPR governs breaches of personal data specifically and applies to any data controller. NIS2 governs cybersecurity incidents more broadly for essential and important entities in designated sectors, and adds an early warning obligation that generally arrives faster than GDPR’s 72 hour notification, with its own follow up incident report and final report requirements.

Do small businesses in Ireland need a formal breach response plan?

Yes. GDPR applies regardless of company size wherever personal data is processed, and Limerick Post reported that one in three Irish SMEs have already experienced a cyberattack. A small business with no dedicated security team benefits even more from a written plan, since there is less institutional knowledge to fall back on during a real incident.

Who in Ireland do I actually notify first, the DPC or the NCSC?

For a personal data breach under GDPR, notify the Data Protection Commission. If the incident also qualifies as a cybersecurity incident under NIS2 because your organisation is an in-scope essential or important entity, you will separately notify your sector’s designated competent authority or the National Cyber Security Centre according to the NIS2 timelines. The two notifications are not mutually exclusive and often both apply to the same incident.

How often should we test this plan?

Run a tabletop exercise at least twice a year and a backup restore test weekly at minimum. Update the runbook after every exercise and every real incident, and review the full plan on a quarterly cycle to account for regulatory and tooling changes, as outlined in the keeping the plan current section above.

Related Coverage

• How to Set Up Xbox Cloud Gaming in Ireland: 14 Steps [2026]
• Nvidia RTX Spark N1X Setup: 12 Steps for Mini PCs [2026]
• Run Local LLMs 2026: Ollama vs LM Studio, 12 Steps
• MARINEX's 4-Year Mission to Inspect Irish Wind Farms [2026]
• KONKR Pocket BLOCK Setup: 12 Steps, $89 Handheld [2026]