Incident response under the ENS (Spanish National Security Framework) is a management cycle that requires detecting, containing, eradicating, recovering from and drawing lessons from every security incident. Measure op.exp.7 of Annex II of Royal Decree 311/2022 mandates this process, and significant-impact incidents in the public sector must be compulsorily reported to CCN-CERT, leaving documented evidence for audit.

Any organisation subject to the ENS (Spanish National Security Framework) will eventually face an incident: ransomware encrypting a server, a credential leak, a deliberate outage or unauthorised access to data. The difference between a mature organisation and one that improvises lies not in whether it suffers incidents, but in how it manages them. The ENS does not settle for antivirus and a firewall; it demands a documented response process with clear owners, mandatory notification when the impact justifies it, and evidence that an auditor can review.

This guide focuses on the incident management cycle and on the part most often neglected: notification to CCN-CERT and the documentation required for audit. If you are looking for the full framework of operational security obligations, I cover that on the cybersecurity incident management page for the ENS, which complements this article. And if you need to place the ENS in the broader landscape, the complete ENS guide provides the starting context.

What does the ENS require on incident response?

Infographic: ENS Incident Response — how to manage security incidents
Infographic: ENS Incident Response — how to manage security incidents. Own elaboration — Summum Marketing.

The ENS is governed by Royal Decree 311/2022, of 3 May, which replaced the former RD 3/2010. Within its Annex II, security measures are grouped into three frameworks: organisational, operational and protection. Incident management falls under the operational framework, specifically measure op.exp.7 ("Incident Management"). This measure requires a comprehensive process to handle incidents that could affect system security, including the communication of security events.

But op.exp.7 does not act alone. The ENS surrounds it with complementary measures that are worth knowing because auditors review them as a whole:

  • op.exp.8 (Activity logging): the logs that enable reconstruction of events. Without traces, forensic analysis is impossible.
  • op.exp.9 (Incident management log): the obligation to record the entire cycle, from initial reports to system changes resulting from the incident.
  • op.mon (System monitoring): the continuous surveillance that feeds the detection phase.

Above the technical measures, Articles 33 and 34 of Royal Decree 311/2022 articulate prevention, detection and incident response, and the provision of response services. These articles assign the National Cryptologic Centre, through CCN-CERT, the role of national public coordinator of the technical response to incidents affecting entities within the ENS scope.

The incident management cycle step by step

ENS Incident Response: How to Manage Security Incidents
Photo: NAVFAC (CC BY 2.0)

Incident response is not a single act but a chain of linked phases. Although each organisation adapts it to its own reality, the structure recommended by CCN-CERT's CCN-STIC-817 guide — and shared by international standards — always follows the same logic: prepare, detect, contain, eradicate, recover and learn. The key is that each phase has an assigned owner and leaves evidence, because that is exactly what auditors will ask for.

Preparation

Before anything happens, you need a plan. This includes defining what constitutes an incident for your organisation, who makes up the response team, what tools you will use, how a crisis escalates and what communication channels are activated. Preparation also covers staff training and running exercises. A team that rehearses responds better than one reading the procedure for the first time in the middle of a crisis. This phase links directly to your business continuity plan (BCP) under the ENS, because a serious incident can trigger activation of the contingency plan.

Detection and analysis

Detection means recognising that something is wrong: a SIEM alert, a user reporting a suspicious email, an anomalous traffic spike. Analysis means confirming whether it is a real incident, determining its scope and classifying it by severity and impact. This classification is decisive, because it determines whether you must notify CCN-CERT and within what timeframes. Here, continuous monitoring (op.mon) and activity logs (op.exp.8) are your raw material.

Containment

Once the incident is confirmed, you must prevent it from spreading. Containment can be immediate (isolating a device from the network, disabling a compromised account) or longer-term (segmenting, applying temporary firewall rules). The key here is not to destroy evidence in the rush: containment is not the same as erasure. Before powering down or reinstalling, preserve images and logs.

Eradication

Eradication means eliminating the root cause: the malware, the exploited vulnerability, the attacker's account. If you only contain but do not eradicate, the incident will recur. This phase requires understanding how the adversary got in, which is only possible if you preserved traces in the earlier phases.

Recovery

Recovery means restoring systems to normal operation safely: restoring from clean backups, rebuilding servers, validating that the threat has gone before reconnecting. Recovery must be gradual and monitored, because a persistent attacker may have left backdoors. Hasty restoration is one of the most costly mistakes.

Lessons learned

The cycle closes with a post-incident analysis: what failed, what worked, what measures need reinforcing. This phase is not bureaucracy — it is the mechanism by which your organisation improves. Conclusions must translate into concrete actions: patching, adjusting configurations, training staff or updating the response procedure itself. The ENS values this feedback loop particularly highly, because it demonstrates that the management system is alive.

Incident management cycle under the ENS: owner, evidence and associated Annex II measure (own elaboration, Summum Marketing)
Phase Objective Typical owner Audit evidence Associated ENS measure
Preparation Have a plan, team and training ready Security Officer Documented procedure, exercise minutes op.exp.7
Detection & analysis Confirm and classify the incident SOC team / operator Alerts, logs, classification sheet op.mon, op.exp.8
Containment Stop the spread Response team Action log, forensic images op.exp.7, op.exp.9
Eradication Eliminate the root cause Systems technical team Root cause report, applied patches op.exp.7
Recovery Return to normal operation safely Systems administration Restoration and validation log op.exp.7
Lessons learned Improve and prevent recurrence Security Officer Final report, corrective action plan op.exp.7, op.exp.9

Who must be notified of an ENS incident?

This is one of the obligations that generates the most confusion. Within the public sector subject to the ENS, incidents of significant impact or high level must be compulsorily reported to the CCN, through CCN-CERT. This obligation is developed in the Security Technical Instruction on Notification of Security Incidents, approved by the Resolution of 13 April 2018.

Notification is channelled through the CCN-CERT platform. The reference tool for ticket and incident management is LUCIA, which allows you to log the incident, exchange information with the CCN-CERT team and track its handling until closure. Not all incidents require notification: it depends on the level of severity and impact assigned during the classification phase.

It is important to be clear that CCN-CERT is not the only possible recipient. A single incident can trigger several parallel notifications if different regulatory frameworks apply simultaneously — something I explain further below and detail in the guide on cybersecurity regulations in Spain (GDPR, ENS, NIS2 and DORA).

How are incidents classified according to CCN-CERT?

The CCN-STIC-817 guide on Cyber Incident Management establishes a taxonomy that classifies incidents by severity into five levels: Critical, Very High, High, Medium and Low. Alongside severity, impact is assessed (low, medium or high, based on the damage caused to the organisation). The obligation to notify and the closure timeframes depend on the combination of both.

The general rule, according to the guide, is that High, Very High and Critical incidents carry a mandatory obligation to notify CCN-CERT, while Medium and Low do not. Closure timeframes increase with severity. I have summarised the logic in the table below, which will help you decide quickly when facing a real incident.

Incident severity levels according to CCN-STIC-817 guide (Summum Marketing summary for guidance; always consult the current version)
Severity level CCN-CERT notification required? Severity guidance
Critical Yes, mandatory Extreme damage, longest closure timeframe
Very High Yes, mandatory Very serious damage
High Yes, mandatory Serious damage
Medium Not mandatory Moderate damage
Low Not mandatory Limited damage

One nuance worth stressing: the specific timeframes and thresholds may be updated in successive versions of CCN-STIC-817, so the table above is for guidance only. When facing a real incident, the binding source is always the current version of the guide and the Security Technical Instruction itself.

What documentation and evidence does the audit require?

This is the part that separates an improvised response from one that passes the ENS audit. Measure op.exp.9 requires recording all incident management activity: initial, interim and final reports, emergency actions and system changes resulting from the incident. And it goes further: when the incident could lead to disciplinary proceedings against internal staff, external suppliers or criminal action, the ENS requires recording evidence admissible before a court, with the detail of its composition and specification determined with specialist legal advice.

In practice, an auditor will want to see at least:

  1. The incident management procedure, documented, approved and known to staff.
  2. An incident log with detection date, classification, actions taken and closure date.
  3. Notification evidence to CCN-CERT where required, with the corresponding ticket or reference.
  4. Final reports with root cause and lessons learned.
  5. Traceability of the corrective actions arising from the post-incident analysis.

The chain of custody of evidence deserves special mention. If an incident ends up in court, poorly collected evidence loses its value. This is why it is important to define from the preparation phase how evidence is preserved, who holds it and how its integrity is documented. This documentary rigour is also what is evaluated in any ENS implementation consultancy process.

How does ENS notification relate to the GDPR and NIS2?

A common mistake is assuming that notifying CCN-CERT exempts you from any other obligation. It does not. The ENS, the GDPR and the NIS2 Directive are separate frameworks that can apply simultaneously to the same incident, each with its own recipient and its own timeframe.

The clearest case is a personal data breach. If the incident affects personal data, Article 33 of the GDPR requires the breach to be notified to the competent supervisory authority (in Spain, AEPD) without undue delay and, where feasible, within 72 hours of becoming aware of it. That 72-hour deadline is from the GDPR and must not be confused with ENS timeframes, which are governed by the Security Technical Notification Instruction and the CCN-STIC-817 guide. You can read more about the breach regime in my GDPR compliance guide for businesses and its penalties.

NIS2 adds its own notification obligations for essential and important entities within its scope. The result: a single ransomware attack encrypting systems and exposing personal data at a public sector entity can simultaneously generate a notification to CCN-CERT (ENS), a notification to AEPD (GDPR) and, if applicable, a notification under NIS2. Coordinating these obligations without overlap or gaps is one of the reasons it pays to have the response procedure well defined in advance.

Common mistakes when managing ENS incidents

In my work as a compliance consultant, based in Valladolid (Castilla y León) and in Las Palmas, I see the same failures recurring in organisations that, on paper, comply with the ENS:

  • Not classifying the incident. If you do not assign a severity and impact level, you do not know whether you must notify or within what timeframe. Classification is not optional.
  • Destroying evidence in the rush. Reinstalling the affected server before preserving images and logs leaves the organisation without forensic analysis capability or legal defence.
  • Confusing containment with resolution. Isolating a device does not eliminate the vulnerability. Without eradication, the incident returns.
  • Failing to document. A technically flawless response that leaves no written record will not pass the audit, because op.exp.9 requires the log.
  • Forgetting the GDPR. Notifying CCN-CERT but not AEPD when personal data is involved is an independent breach that can result in a separate penalty.
  • Not closing the cycle. Without lessons learned and corrective actions, the same incident recurs and the management system fails to mature.

If you want to prepare your organisation to respond competently and leave the documentary trail that audit requires, I can help from Castilla y León and across the rest of Spain, combining on-site and remote work.

Frequently asked questions

How are incidents managed under the ENS?

Through a management cycle covering six phases: preparation, detection and analysis, containment, eradication, recovery and lessons learned. Measure op.exp.7 of Annex II of Royal Decree 311/2022 requires this documented process, with assigned owners, classification of each incident and a record of all actions so they can be reviewed in audit.

Who must be notified of a security incident?

In the public sector subject to the ENS, incidents of significant impact or high level must be compulsorily reported to the CCN via CCN-CERT, through its management platform (LUCIA). If the incident affects personal data, the breach must additionally be notified to AEPD within 72 hours under the GDPR, as these are separate and concurrent obligations.

What is CCN-CERT?

CCN-CERT is the security incident response team of the National Cryptologic Centre. Under Articles 33 and 34 of Royal Decree 311/2022, it acts as the national public coordinator of the technical response to cyberincidents affecting entities within the ENS scope, and publishes the CCN-STIC-817 guide with the incident classification taxonomy.

What documentation does the ENS require after an incident?

Measure op.exp.9 requires recording all incident management activity: initial, interim and final reports, emergency actions and system changes. When the incident may lead to disciplinary or criminal proceedings, evidence admissible before a court must be preserved. The audit reviews the procedure, the incident log, the notifications made and the corrective actions taken.

Sources