Security incident management protocol for companies

A cyberattack, an email sent to the wrong recipient, a stolen laptop or a backup failure: any of these situations can turn into a personal data security breach with legal, reputational and operational consequences. The difference between managing the incident with minimal damage or suffering a serious impact usually comes down to one thing: having a security incident management protocol that is activated, documented and rehearsed before the problem occurs.

Regulation (EU) 2016/679 (GDPR) and Organic Law 3/2018 (LOPDGDD — the Spanish data protection act) do not require a specific protocol format, but they do oblige data controllers to adopt appropriate technical and organisational measures to respond to incidents, to notify breaches to the AEPD (Agencia Española de Protección de Datos — the Spanish Data Protection Authority) within 72 hours where required, and to document the entire process. This article describes the six phases of a security breach response plan that companies can adapt to their size and sector.

What is a security incident management protocol?

A security incident management protocol (also called an incident response plan) is the set of predefined procedures, roles and decisions that an organisation activates when an incident affecting the confidentiality, integrity or availability of its systems or data is detected or suspected. Under the GDPR, the focus is on personal data, but a good protocol also covers corporate assets, operating systems and business continuity.

Having this document is not just a cybersecurity best practice: art. 32 GDPR requires the controller to adopt appropriate technical and organisational measures, and art. 33.5 GDPR obliges it to document all security violations, whether notified or not. The absence of documented procedures worsens the AEPD's assessment in the event of an inspection or complaint.

Phase 1 — Detection and identification of the incident

The first phase of the security breach procedure consists of detecting that something has happened and classifying it correctly. Not all security events are incidents, and not all incidents are personal data breaches. The distinction matters because it triggers legal deadlines.

Common detection sources

• Alerts from SIEM (Security Information and Event Management) or EDR (Endpoint Detection and Response) systems.
• Internal notification from an employee (an email received by mistake, a lost device).
• Communication from a supplier or data processor handling data on behalf of the company.
• Notice from a customer or user about unauthorised access to their account.
• Detection of malware or ransomware by the technical team.
• Notification from INCIBE-CERT (National Cybersecurity Institute) in the event of sector-wide incidents.

Activating the response team

As soon as a possible incident is detected, the protocol must activate a response team with defined roles: a person responsible for coordinating the technical response, the Data Protection Officer (DPO) or compliance officer, company management and, where applicable, the legal and communications departments. The internal notification chain must be written into the protocol so there is no doubt about who to inform first.

The 72-hour deadline of art. 33 GDPR starts running from the moment the controller becomes aware of the breach. This is why it is critical to record the exact date and time the incident was detected. Every minute's delay in activating the protocol is a minute subtracted from that deadline.

Phase 2 — Containment of the incident

Once the incident has been identified, the priority is to stop the bleeding: preventing the damage from spreading to more systems or affecting more data. Containment is divided into two levels.

Immediate containment

Immediate containment measures aim to isolate the problem as quickly as possible, even if they are provisional:

• Disconnect compromised systems from the network without shutting them down (to preserve forensic evidence).
• Revoke compromised or suspected credentials.
• Block access to the affected resource (shared folder, database, mailbox).
• Temporarily suspend the processing activity that caused the incident.

Long-term containment

Once the environment is stabilised, more definitive measures are applied: patching the exploited vulnerability, reinforcing network segmentation, restoring systems from clean backups and verifying that no active backdoors remain. This phase can last days or weeks and must be carried out in parallel with the rest of the protocol.

Phase 3 — Risk assessment for the rights and freedoms of data subjects

The risk assessment is the phase that determines which legal obligations are triggered. Art. 33.1 GDPR requires notification to the supervisory authority unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Art. 34.1 GDPR requires communication to the data subjects themselves when that risk is high.

The following table summarises the three thresholds and the associated obligations:

The AEPD has published a indicative risk assessment tool that helps classify the incident at one of these levels. It is not legally binding, but it documents the organisation's reasoning and reduces exposure in the event of a subsequent inspection.

Phase 4 — Notification under arts. 33 and 34 GDPR

If the assessment determines that there is a significant risk, the notification obligations regulated under the GDPR are triggered. It is advisable to coordinate this phase with specialist advice: at Summum Consultoría we support organisations in managing and notifying security breaches, with protocols tailored to the sector and size of each company.

Notification to the AEPD (art. 33 GDPR)

The data controller must notify the breach to the AEPD without undue delay and, where feasible, no later than 72 hours after becoming aware of it. If that deadline cannot be met, the notification must be accompanied by a justification for the delay.

The minimum content of the notification, pursuant to art. 33.3 GDPR, includes:

• Nature of the breach: type (confidentiality, integrity, availability), categories of data affected and approximate number of records and data subjects.
• Contact details of the DPO or designated contact point.
• Likely consequences of the breach.
• Measures taken or proposed to address the breach and mitigate its effects.

Art. 33.4 GDPR allows information to be provided in phases when it is not all available at the time of notification. It is preferable to notify within the deadline with partial information and complete it later, rather than waiting until all data is available and missing the 72-hour window.

For further detail on the AEPD notification procedure, see our article How to notify a security breach to the AEPD within 72 hours.

Communication to data subjects (art. 34 GDPR)

When the assessment concludes that the breach involves a high risk to the rights and freedoms of individuals, the controller must also communicate it to the affected data subjects without undue delay. This communication must be written in clear and plain language and describe:

• The nature of the security breach.
• The likely effects on the data subjects.
• The measures taken or recommended to mitigate the harm (e.g., changing passwords, enabling two-factor authentication or blocking payment cards).
• The contact details of the DPO or the person responsible for handling data subject enquiries.

Communication to data subjects is not required if the data were encrypted with a key inaccessible to the attacker, if the measures applied eliminate the high risk, or if individual communication would require disproportionate effort — in which case it may be replaced by a public communication (art. 34.3 GDPR).

Phase 5 — Internal breach register

Regardless of whether the breach is notified to the AEPD, art. 33.5 GDPR obliges the controller to document all security violations in an internal register. This register is the primary piece of evidence that the organisation acted with due diligence and must be retained long enough for the AEPD to verify it in a possible inspection.

The internal breach register must include, at a minimum:

• Date and time of detection and start of containment.
• Description of the facts: what happened, which systems were involved and how it was detected.
• Type of breach (confidentiality, integrity, availability) and data affected.
• Approximate number of data subjects affected and categories of data compromised.
• Risk level assessment, including the reasoning behind it.
• Decision on notification to the AEPD (with date of submission or justification for not notifying).
• Decision on communication to data subjects (with date or justification for the exception applied).
• Containment, recovery and improvement measures taken.
• Person responsible for managing the incident.

There is no official format for the register, but the AEPD recommends keeping it up to date and well-structured. Many organisations integrate it into their Information Security Management System (ISMS), especially if they have implemented the ISO/IEC 27001 standard.

Phase 6 — Lessons learned and continuous improvement

Once the incident has been resolved, the final phase of the security incident management protocol involves analysing what happened, why, and how to prevent it from recurring. This review should be conducted with all parties involved: the technical team, the DPO, management and, where applicable, the supplier or data processor that participated in the incident.

The key questions in the post-mortem analysis are:

• What was the attack vector or root cause of the incident?
• Did the protocol work as designed, or were there bottlenecks?
• Were the detection and notification timelines adequate, or were there avoidable delays?
• Were the existing technical measures (encryption, access controls, backups) sufficient?
• What improvements should be made to the protocol, staff training or technical infrastructure?

The conclusions of the analysis should be translated into an action plan with owners and deadlines, and the most significant improvements should be incorporated into the next protocol review. This continuous improvement cycle is precisely the spirit of art. 32 GDPR: technical and organisational measures are not static — they must be reviewed periodically.

The link between cybersecurity and data protection

An effective incident management protocol cannot live solely in the legal or compliance department: it needs to be integrated with the organisation's cybersecurity measures. Most security breaches affecting personal data have a technical origin (unpatched vulnerabilities, weak passwords, phishing, ransomware) that the IT team must address.

On the regulatory front, the National Security Framework (ENS — Esquema Nacional de Seguridad) — mandatory for public-sector entities and their suppliers — includes in its Annex II a catalogue of security measures that covers incident management as a standalone category. For private companies, ISO/IEC 27001 establishes equivalent controls in its Annex A. Both frameworks are compatible with the GDPR requirements and allow for the building of an information security management system that simultaneously meets legal data protection requirements and cybersecurity best practices.

The Kit Digital grants (Spain's SME digitalisation programme) include a Cybersecurity solution that can fund the implementation of incident detection and response tools. Organisations accessing these grants must demonstrate that the installed tools comply with the GDPR as regards the personal data they generate (activity logs, alerts, user access records).

Summum Consultoría's Systems team works in close coordination with the legal consultancy team to provide an integrated view: not just the technical tool, but also the response protocol and the documentation required by the GDPR. If you want to review your breach response plan or need support in managing an active incident, the specialist team at Summum Consultoría is available to organisations in Castilla y León (Valladolid, Burgos, Palencia, Aranda de Duero) and the Canary Islands (Las Palmas). You can learn more about our security breach management and notification service or read what the GDPR says exactly about the definition of a breach in our article on what a security breach is under the GDPR.

Frequently asked questions

What is the difference between a security incident and a security breach?

A security incident is any event that compromises the confidentiality, integrity or availability of a system or asset. A security breach, within the meaning of art. 4.12 GDPR, is an incident that specifically affects personal data: their destruction, loss, alteration, unauthorised disclosure or access. Any incident affecting personal data may be a breach, but not every IT incident qualifies if no personal data is involved.

Does the incident management protocol need to follow an official format?

There is no standardised mandatory template imposed by the GDPR or the LOPDGDD for the incident management protocol. The regulation requires appropriate technical and organisational measures (art. 32 GDPR) and documentation of all security violations (art. 33.5 GDPR), but leaves the format open. What matters is that the protocol is written down, is known to the people involved, has been tested at least once and is updated periodically. The complete absence of documentation is the scenario that weighs most heavily in a sanctioning decision.

How long must the internal breach register be retained?

The GDPR sets no fixed retention period for the breach register; the controller must define it under the accountability principle (art. 5.2 GDPR). As a practical orientation, the register should be kept for as long as the AEPD may request it in an investigation. Actual limitation periods for infringements are governed by art. 78 LOPDGDD: 3 years for very serious infringements, 2 years for serious infringements and 1 year for minor infringements.

What happens if the data controller has no DPO and suffers a breach?

The obligation to notify the AEPD and communicate to data subjects falls on the data controller regardless of whether it has a Data Protection Officer. If the organisation is not required to appoint a DPO under art. 37 GDPR, it must still manage the breach and, where applicable, notify it. In that case, the contact point with the AEPD may be the management team or the compliance officer. What does not change is the deadline (72 hours) or the minimum content of the notification. Having a documented protocol and a designated internal responsible person — even if not a formal DPO — significantly reduces the risk of non-compliance.