NIS2 Spain 2026: complete compliance guide for businesses

The NIS2 Directive (EU Directive 2022/2555) is the European cybersecurity framework that replaces the former NIS1, with a significantly broader scope, stricter technical obligations and a sanctions regime that reaches up to 2% of global annual turnover. In Spain, it is transposed through the Cybersecurity Coordination and Governance Act, and it already affects thousands of organisations across sectors such as energy, healthcare, banking, transport, digital infrastructure, public administration and critical ICT providers. This pillar guide covers everything a board member, CISO or compliance officer needs to understand: real scope, Article 21 obligations, incident notification windows and a 12 month compliance roadmap.

Key takeaways

• NIS2 applies to thousands of entities in Spain, not only to classic operators of essential services.
• The general threshold is 50+ employees or turnover above 10 M€, with limited exceptions.
• Article 21 mandates 10 minimum risk management areas that must be documented and operational.
• Fines reach up to 10 M€ or 2% of global turnover for essential entities.
• Significant incident notification follows three windows: 24 hours, 72 hours and 1 month.

What NIS2 is and why it matters in Spain 2026

NIS2 replaces the 2016 NIS1 Directive to raise the common level of cybersecurity across the European Union. The rationale was clear: NIS1 left too many sectors out, obligations were generic and enforcement varied widely between Member States. NIS2 fixes these issues by extending sector coverage, introducing two categories (essential entities and important entities), reinforcing minimum technical and organisational measures and harmonising the sanctions regime.

In Spain, the directive is transposed through the Cybersecurity Coordination and Governance Act, which replaces Royal Decree-law 12/2018 that had transposed NIS1. The act designates competent CSIRTs (INCIBE-CERT for the non-financial private sector, CCN-CERT for the public sector, ESPDEF-CERT for defence) and assigns competent authority functions to sectoral bodies (Banco de España, CNMV, SEPBLAC for finance, sectoral ministries for the rest).

The real impact is twofold. On one hand, organisations that had never faced specific cybersecurity obligations (managed service providers, chemical manufacturers, mid-sized food companies, waste managers) now enter the regulatory perimeter. On the other, the sanctions regime stops being nominal: fines have high ceilings, board accountability is personal and the competent authority can disqualify directors for serious breaches.

Transposition and application timeline in Spain

The original deadline of the NIS2 Directive required transposition by Member States before 17 October 2024. Spain, along with most of the Union, missed that deadline: transposition was approved with delay into 2025, generating legal uncertainty for obligated entities. The European Commission opened infringement procedures against Member States that failed to transpose on time.

Once the Spanish transposition act enters into force, obligated entities must:

1. Identify themselves as obligated subjects by registering with the competent authority, within the deadlines set by national law (generally 5 months from entry into force).
2. Maintain updated contact information with the competent CSIRT and the appointed security officer.
3. Demonstrate implementation of Article 21 measures during any inspection or audit.
4. Notify significant incidents within the 24h, 72h and 1 month windows from detection.

INCIBE-CERT acts as the operational contact point for the non-financial private sector. For specific sectors, sectoral CSIRTs (CCN-CERT for public administrations, ESPDEF-CERT for defence, regional CSIRTs in some autonomous communities) coordinate incident response and authority communications. European coordination is channelled through ENISA and the CSIRTs Network.

Who is obligated: essential vs important entities

NIS2 introduces a binary classification that determines supervision intensity and sanction ceilings. Membership in either category depends on the sector (Annexes I and II of the directive) and the size of the entity.

Included sectors

Size thresholds

The directive refers to Commission Recommendation 2003/361/EC:

• Large enterprise: more than 250 employees, or turnover above 50 M€ and balance sheet above 43 M€. Automatically falls into essential entity if it belongs to an Annex I sector.
• Medium enterprise: 50 to 250 employees, or turnover between 10 M€ and 50 M€. Falls into important entity with exceptions (DNS, TLD, qualified trust services, central public administration, entities with functional monopoly, which are essential by nature).
• Small and micro enterprise: below those thresholds, not obligated unless a sectoral exception applies.

Differences between regimes

The 10 risk management measures of Article 21

Article 21 sets the mandatory minimum content. Each entity must apply a risk-based approach, proportionate to its size and exposure, but cannot leave any of the 10 areas uncovered.

1. Risk analysis and information system security policies

The entity must have a documented risk analysis methodology over information assets, approved by management and reviewed at least annually. The policy must define risk appetite, acceptance criteria, owners for treatment of each identified risk and traceability between threats, vulnerabilities, controls and residual risks. In practice, the most used methodologies are ISO 27005, NIST SP 800-30 and MAGERIT, the latter especially common in organisations already complying with the National Security Framework (ENS).

A frequent mistake is presenting a static analysis carried out once by an external consultancy. The competent authority requires the analysis to be alive: each relevant change (new application, new supplier, organisational change) must trigger a review and high risks must have treatment plans with dates and assigned owners.

2. Incident management

A documented and operational procedure covering detection, classification, containment, eradication, recovery and lessons learned. It must define roles (incident manager, response team, management, communications), severity levels, escalation criteria and internal and external communication channels. Common tools are SIEM, SOAR, EDR and threat intelligence platforms, but NIS2 does not impose specific technologies, only capabilities.

The procedure must be integrated with regulatory notification to the CSIRT in the 24h, 72h and 1 month windows. This requires the technical team to know when an incident is significant (impact on availability, integrity or confidentiality above defined thresholds) and activate the notification chain without legal validation that delays the deadlines.

3. Business continuity and recovery

A business continuity plan (BCP) and disaster recovery plan (DRP) with recovery time objectives (RTO) and recovery point objectives (RPO) defined for each critical service. Backups must follow the 3-2-1 rule (three copies, two different media, one off-site), be encrypted, be immutable against ransomware and be tested periodically with real restorations, not documentary drills.

Crisis management includes activation of a committee, communications with customers and authorities, handling media pressure and continuity of essential operations while the incident lasts. Annual tabletop exercises are mandatory in practice to demonstrate maturity.

4. Supply chain security

This is one of the major novelties compared to NIS1. The entity must inventory its critical ICT suppliers, assess their security level, contractually require equivalent measures (model clauses, audit rights, cascading incident notification obligations) and reassess periodically. The directive places special focus on managed service providers, cloud, enterprise software and hardware.

Scope reaches second and third tier suppliers when risk justifies it. Real cases such as SolarWinds, Kaseya or MOVEit have shown that a compromise in the chain affects hundreds of customers simultaneously, which justifies the required rigour.

5. Security in system acquisition, development and maintenance

A secure development life cycle (SDLC) covering security requirements, secure design, secure coding, testing (SAST, DAST, SCA, pentesting), controlled deployment and maintenance. It includes a vulnerability management policy with SLAs by severity, coordinated vulnerability disclosure and specific management of security updates.

For entities that acquire third-party software, the obligation translates into requiring SBOM (Software Bill of Materials), pre-contract security reviews and timely update mechanisms. Vulnerability management must align with CVE, CVSS and, where appropriate, EPSS for prioritisation.

6. Policies and procedures to assess effectiveness

Having controls is not enough, you must show they work. This requires planned internal audits, technical testing (pentesting, red team, threat hunting), security metrics reported to management, documented management reviews and continuous improvement. The ISO 27001:2022 standard provides a proven framework: clauses 9 (performance evaluation) and 10 (improvement) apply directly.

Reasonable minimum metrics include mean time to detect (MTTD), mean time to respond (MTTR), percentage of critical vulnerabilities remediated within SLA, mandatory training coverage and results of simulated phishing campaigns.

7. Basic cyber hygiene and training

Mandatory training programme for all staff, with differentiated modules for system administrators, developers and management bodies. Board training is an important novelty: members of the management body must receive specific cybersecurity training and are personally responsible for compliance.

Hygiene practices cover password management, MFA, phishing identification, safe email use, secure browsing, handling of personal devices (BYOD) and secure communication. Simulated phishing campaigns and reinforced training for repeat offenders are common practices in mature organisations.

8. Cryptography and encryption policies and procedures

Documented standards on accepted algorithms (AES-256, RSA-3072 or higher, ECC P-256 or higher), key management (rotation, custody, separation of duties), encryption of data at rest (databases, backups, mobile devices, cloud storage) and in transit (TLS 1.2+, IPsec, SSH). The policy must also address the transition to post-quantum cryptography as a planning horizon.

Digital certificate management (internal or external PKI, ACME, expiry monitoring) and code signing for critical artefacts are part of this area. Cryptographic keys must have their own inventory and management procedure.

9. Human resources security, access control and asset management

Background checks proportionate to position sensitivity, confidentiality clauses, onboarding and offboarding procedures, separation of duties and periodic access reviews. Identity and access management (IAM) must support least privilege, strong authentication, life cycle management of privileged accounts (PAM) and periodic permission reviews.

The asset inventory covers hardware, software, data, cloud services and, increasingly relevant, non-human identities (service accounts, API tokens, machine credentials). Each asset must have an owner, criticality classification and associated controls.

10. MFA use, secure communications and emergency communication systems

Mandatory multi-factor authentication on privileged access, remote access, email and critical applications. The directive does not impose a specific factor, but SMS codes are considered weak. Recommended options include TOTP apps, FIDO2 hardware keys and biometrics with local storage.

Secure communication solutions cover encrypted email (S/MIME, PGP), end-to-end encrypted messaging for sensitive communications and videoconferencing with verified encryption. Emergency communication systems (out-of-band) must work when usual systems are compromised, an essential condition during a major incident.

Incident notification obligations

Regulatory notification is one of the areas where NIS2 substantially hardens requirements compared to NIS1. Every obligated entity must notify significant incidents (those that cause, or may cause, severe operational disruption or significant financial losses) to the competent CSIRT in three mandatory windows:

The difference from the GDPR notification (72 hours from awareness, to the AEPD, only if personal data is affected) is important: the same incident may trigger both obligations in parallel, with different authorities and different deadlines. Internal coordination between the DPO and the security officer must be defined in the procedure.

Regarding DORA (EU Regulation 2022/2554, applicable to financial entities since January 2025), the deadlines are even more demanding: 4 hours to classify a major incident, 24 hours for initial notification. A financial entity obligated by both regimes (bank, insurer, fund manager) follows DORA first, as it prevails as lex specialis for its ICT incidents.

Sanctions regime in Spain

NIS2 harmonises the sanctions regime upward across the Union. Fines have high ceilings, director accountability is personal and the competent authority has accessory sanctions with significant reputational and operational impact.

The accessory sanctions provided for include:

• Publication of the breach in official media, identifying the sanctioned entity.
• Temporary ban on holding management positions for board members or senior management personally responsible.
• Appointment of an intervenor to supervise the implementation of corrective measures.
• Order to cease or suspend activity of the affected service in serious cases.

The personal accountability of directors is one of the most relevant cultural shifts. The directive requires the management body to approve risk management measures, supervise their application and receive specific training. Failure to comply with these obligations is directly attributable and may lead to temporary disqualification.

INCIBE-CERT, CCN-CERT and competent authorities

Spain has an ecosystem of CSIRTs and sectoral authorities that share prevention, response and supervision functions.

At European level, ENISA (European Union Agency for Cybersecurity) coordinates cooperation between Member States, maintains the CSIRTs Network, manages the European vulnerability registry and publishes methodological guides. Cross-border operational cooperation is channelled through CyCLONe (European cyber crisis liaison organisation network at executive level).

NIS2 compliance roadmap in 12 months

A realistic roadmap for a medium organisation (between 100 and 1,000 employees) with no prior cybersecurity maturity typically takes between 9 and 14 months. Phased planning avoids rushed investments and allows prioritising what most reduces risk and regulatory exposure.

Phase 0: Identification and registration (month 1)

Determine whether NIS2 applies, in which category (essential or important) and to which group entities. Appoint the security officer to the competent authority and register the entity within the legal deadline. Map critical services whose interruption would trigger a significant incident.

Phase 1: Gap analysis against Article 21 (months 2 to 3)

Documentary and field audit of the 10 mandatory areas. Inventory of existing controls, maturity assessment per area (scale 0 to 5), prioritisation of gaps by risk and regulatory impact. The deliverable is a report with a prioritised remediation plan and effort estimation.

Phase 2: Implementation of priority controls (months 3 to 8)

Execution of the remediation plan focused on critical gaps: 24h/72h notification procedure, MFA on privileged access, backup encryption, critical ICT supplier management, board training. Planning by biweekly sprints with KPIs per sprint maintains momentum.

Phase 3: Documentation and procedures (months 6 to 9, in parallel)

Master security policy, specific policies per domain (incident management, cryptography, supply chain, access control, continuity), operational procedures and records. Documentation must be usable, not decorative: the inspecting authority asks for application evidence, not documents stored in a folder.

Phase 4: Testing and tabletop (months 9 to 10)

Technical testing (internal and external pentesting, cloud configuration audit, identity management review) and simulation exercises (tabletop with management, CSIRT notification drill, ransomware recovery exercise). Results feed back into continuous improvement.

Phase 5: External audit and certification (months 10 to 12)

Independent NIS2 compliance audit producing a defensible report before the authority. For entities also seeking voluntary certification, ISO 27001:2022 certification can be obtained in parallel, since it covers approximately 65 to 75% of Article 21 requirements.

Continuous maintenance

Annual review of risk analysis, supplier inventory update, recurring training, periodic drills, continuous vulnerability monitoring and metrics reported quarterly to management. NIS2 is not a project with an end, it is a permanent capability.

NIS2 vs ISO 27001 vs ENS vs DORA

Organisations already complying with other frameworks often ask to what extent what they have done serves them. A practical comparison helps prioritise investments.

A large financial organisation may simultaneously have NIS2, DORA and, if it is a public administration supplier, ENS obligations. The efficient strategy is to build a single management system based on ISO 27001:2022 with specific extensions covering each regulatory framework.

Common NIS2 compliance mistakes

Experience on real projects shows recurring patterns that end in avoidable findings or sanctions.

1. Assuming ISO 27001 already covers everything

ISO 27001:2022 is an excellent starting point and covers much of Article 21, but NIS2 introduces specific obligations that do not map automatically: 24h notification to the CSIRT, deepened supply chain management, mandatory board training, registration as an obligated entity. A gap analysis is essential.

2. Not notifying within 24 hours out of reputational fear

The calculation of "let us wait until we have everything clear" to avoid communicating an incident that is later denied goes against the spirit and the letter of the rule. The 24h early warning is not a public statement, it is a communication to the competent authority with preliminary information. Missing the deadline is a standalone infringement, regardless of how the incident evolves.

3. Incomplete scope on supply chain

Inventorying only direct ICT suppliers and forgetting critical dependencies (datacenter, ISP, cloud providers, enterprise software, monitoring tools, MSSP) is a frequent mistake. The chain must be mapped end-to-end and critical suppliers identified with objective impact criteria.

4. Lack of TLPT or red team testing

Declarative testing (questionnaires to the IT team) does not demonstrate effectiveness. The inspecting authority values real testing: pentesting with results, documented tabletop drills, red team exercises or threat-led penetration testing (TLPT) when size and maturity justify it.

5. Training only for management

Although board training is a novelty and mandatory, limiting effort to it leaves the operational frontline unprotected. The strategy must combine board training (governance, accountability, reading risk reports), general staff training (phishing, passwords, devices), differentiated technical training (developers, systems, operations) and reinforced training for users repeatedly failing simulations.

Relevant public cases

The status of NIS2 transposition across the European Union is heterogeneous. At the start of 2025, several Member States (including Spain, France, Netherlands, Belgium) remained in the process of parliamentary approval of their national laws, which led the European Commission to open infringement procedures against delayed States.

The first publicly documented sanction cases come from States that transposed on time. In Poland, the sectoral authority published early enforcement actions against digital infrastructure entities for breaches of registration obligations. In Lithuania, public communications from the national CSIRT confirmed sanction procedures against operators of essential services for late incident notification.

INCIBE-CERT and CCN-CERT publish periodic communications (security advisories, alerts, sectoral guides) throughout 2025 and 2026 that serve as operational reference for obligated entities. Regular consultation of these official sources is part of the due diligence required.

Frequently asked questions

Is my company required to comply with NIS2?

It is if it belongs to a sector in Annexes I or II of the directive (energy, transport, banking, healthcare, water, digital infrastructure, public administration, postal, waste, chemical, food, critical manufacturing, digital providers, research) and exceeds the general threshold (more than 50 employees or turnover above 10 M€). There are limited exceptions for entities classified as essential by nature (DNS, TLD, qualified trust services, central public administration) that apply regardless of size.

What is the real compliance deadline in Spain?

The European transposition deadline expired on 17 October 2024. Spain transposed with delay in 2025 through the Cybersecurity Coordination and Governance Act. From the entry into force of the national law, obligated entities have the deadlines it sets (generally 5 months for registration and a reasonable period to demonstrate implementation of measures). In practice, the recommendation is not to wait and to advance compliance now, given that the material obligation exists from the directive.

Does NIS2 replace ENS if I am a public administration supplier?

No, they are complementary frameworks. ENS regulates the information systems of the public sector and its suppliers when they handle public sector information or services. NIS2 regulates cybersecurity of entities in designated sectors. An ICT supplier to the administration may simultaneously have ENS obligations (due to its contractual relationship with public administration) and NIS2 (if it belongs to an obligated sector and exceeds thresholds). Efficient integration is built on a common management system.

What happens if I fail to notify an incident within 24 hours?

Failure to meet the early warning deadline is a standalone infringement. The competent authority may sanction the delay or non-notification independently of any sanction for the underlying incident. The amount depends on the entity category (essential or important), on the degree of subsequent cooperation and on the severity of the incident. Accessory sanctions (publication of breach, intervention, director disqualification) may be added to the fine.

How do I demonstrate compliance to an auditor?

Through documentary and operational evidence: signed and current policies, updated risk analysis, incident log with detection and response times, CSIRT notification records, training records, results of technical testing, management review minutes, security metrics, updated inventories, supplier contracts with security clauses. The principle is traceability: any compliance claim must be backed by evidence.

Do I need ISO 27001 before NIS2?

It is not mandatory, but it shortens the path significantly. An organisation with ISO 27001:2022 implemented covers approximately 65 to 75% of Article 21, and typical gaps (24h notification to CSIRT, specific board training, deepened supply chain management) are manageable. If you do not have ISO 27001 and are going to implement NIS2 from scratch, consider building the management system with ISO 27001 structure from the start, opening the door to certification later without rewriting.

Who supervises my sector?

It depends on the sector. Banking, financial market infrastructure, insurance: Banco de España, CNMV, DGSFP, coordinated with DORA. Healthcare: Ministry of Health and competent regional authorities. Energy, transport, water: sectoral ministries. Digital infrastructure, MSSP, digital providers: authority designated by the transposition act, with INCIBE-CERT as operational CSIRT. Public administration: CCN-CERT and authorities at each administrative level. Defence: ESPDEF-CERT. If in doubt, check the specific designation in the Cybersecurity Coordination and Governance Act.

Related resources

• NIS2 audit step by step
• NIS2 directive enforcement and fines
• NIS2 vs NIS1: key differences
• DORA vs NIS2: differences and overlaps
• ISO 27001 and NIS2 complementarity
• DORA compliance guide for financial entities 2026
• ENS certification: complete guide
• What is ISO 27001 certification

NIS2 diagnostic with Secra

At Secra we support essential and important entities on NIS2 compliance with a pragmatic and defensible approach before the competent authority. Our service covers:

• Gap analysis in 4 weeks against the 10 areas of Article 21, with maturity scoring and prioritised remediation plan.
• Compliance roadmap of 9 to 12 months with biweekly sprints, KPIs per sprint and executive reporting.
• Auditable evidence generated during implementation: policies, procedures, records, metrics, technical testing results.
• Specific training for the management body on responsibilities, cybersecurity governance and risk report reading.
• Continuous support during the first year after implementation, with notification drills, quarterly reviews and updates against regulatory changes.

If your organisation falls within the NIS2 perimeter and you need clarity on where to start, contact us and we will arrange a first conversation with no commitment to assess your situation.