Spain software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in Spain, the rule that reaches your code most directly today is the National Security Framework (Esquema Nacional de Seguridad, ENS), Royal Decree 311/2022. It applies to the whole public sector and to private companies that supply it, and its Annex II already defines a maintained list of the third-party software components in a system as a reinforcement that a risk analysis or a contract can switch on. Around it sit DORA for banks, insurers and investment firms, the EU Cyber Resilience Act for anyone selling products with digital elements, the GDPR as enforced by the Spanish Data Protection Agency (AEPD), and the EU AI Act, with the Spanish Agency for the Supervision of Artificial Intelligence (AESIA) set up to supervise it. Spain has not transposed NIS2: the European Commission referred it to the EU Court of Justice on 8 July 2026, and with the Cortes dissolved on 6 October 2026 for the 29 November election, no new law can pass before the next parliament sits. The 2018 NIS1 rules still apply.

This guide takes each regime from its primary source, names the supervisor, lists what it asks of software, and ends with a 30/60/90-day plan that works with any tooling. It is a practical reading of public texts, not legal advice.

Key takeaways

• ENS is the anchor. Royal Decree 311/2022 applies to the public sector and, under Article 2.3, to private suppliers whose systems deliver services or solutions to it. Public contract specifications must include what is needed to ensure ENS conformity, such as a Declaration or Certification, and this can extend down the contractor's supply chain.
• ENS already names a software component list. Annex II reinforcements op.exp.1 R4 and mp.sw.1 R5 describe a formal, updated list of third-party software components per version, with at least component, manufacturer and version. They are not defaults for any category, but contracts, profiles and risk analyses switch them on.
• NIS2 is late in Spain. The Commission referred Spain to the Court of Justice on 8 July 2026 and asked for financial sanctions. Royal Decree-law 12/2018 and Royal Decree 43/2021 still apply.
• DORA has applied since 17 January 2025 to Spanish financial entities, supervised by the Bank of Spain, the CNMV and the Directorate General of Insurance and Pension Funds within their own remits.
• The EU CRA reporting duty started on 11 September 2026. Manufacturers must give an early warning within 24 hours of becoming aware of an actively exploited vulnerability. The full product rules, including the SBOM, apply from 11 December 2027.
• AESIA exists, but its AI Act law lapsed. AESIA's statute dates from Royal Decree 729/2023. The organic bill designating it as an AI Act market surveillance authority lapsed when the Cortes were dissolved on 6 October 2026. The AI Act itself applies directly.
• Safeguard capabilities used in the plan, all GA: the Compliance and GRC suite with Spain ENS and NIS2 framework pages, SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, TPRM with SBOM requests, CSAF and VEX upload, autonomous remediation (ships switched off), the local runner, AI-BOM discovery, AI Gateway, MCP Guardrail, agent identity, Trust Center, and on-prem, air-gapped and Zero AI deployment options.

Who this applies to in Spain

Spain's rules fall on five groups, and many organisations sit in two or three.

The public sector and its suppliers. ENS applies to the whole public sector as defined by Article 2 of Law 40/2015: central government, the autonomous communities, local entities, public universities and the institutional public sector. It also applies to systems handling classified information. Under Article 2.3 it reaches private companies whose information systems support services or solutions they provide, by contract, to public sector bodies. The National Cryptologic Centre (Centro Criptológico Nacional, CCN) publishes the ENS guidance and runs CCN-CERT, the government CERT.

Operators of essential services and digital service providers. Royal Decree-law 12/2018 transposed the first NIS Directive and is still in force. It covers operators of essential services in critical sectors plus online marketplaces, search engines and cloud providers. The decree-law names sector competent authorities and three reference CSIRTs: CCN-CERT for the public sector, INCIBE-CERT for private entities, and ESPDEF-CERT, the defence CSIRT, in support. Check the decree-law for the authority that covers your sector.

Financial entities. DORA, an EU regulation, applies directly. Under its Article 46 each entity is supervised by the authority that already supervises it under sector law: in Spain, broadly the Bank of Spain for credit, payment and e-money institutions, the National Securities Market Commission (Comisión Nacional del Mercado de Valores, CNMV) for investment firms and market infrastructures, and the Directorate General of Insurance and Pension Funds (Dirección General de Seguros y Fondos de Pensiones, DGSFP) for insurers. Spain has also extended DORA's ICT risk chapter to payment system and payment scheme operators, payment processors and other technical service providers, supervised by the Bank of Spain.

Manufacturers and software makers selling into the EU. The Cyber Resilience Act applies to products with digital elements placed on the EU market, regardless of where the maker is based.

Anyone processing personal data or deploying AI. The AEPD enforces the GDPR and the Organic Law 3/2018 on data protection and digital rights (Ley Orgánica de Protección de Datos Personales y garantía de los derechos digitales, LOPDGDD). The AI Act applies in stages across the EU, and AESIA is the Spanish agency created to supervise AI.

The rules, regulator by regulator

The National Security Framework (ENS) and the CCN

Royal Decree 311/2022 of 3 May 2022 replaced the 2010 ENS. It sets basic principles, minimum requirements and, in Annex II, the security measures a system must apply according to its category.

The structure matters for software teams:

• Categories. Article 40 sets three security categories, BASIC (BÁSICA), MEDIUM (MEDIA) and HIGH (ALTA), based on the impact of an incident on the information and services. Annex I explains how to rate each security dimension.
• Security policy and roles. Article 12 requires a security policy. For a private supplier in scope, Article 2.3 says it is approved by the company's own top executive body. Article 13 separates four roles, including the security officer (responsable de la seguridad) and the system owner (responsable del sistema), who must normally be different people with no reporting line between them.
• Security products and services. Article 19 says that ICT security products and services used in systems in scope must have certified security functionality, in proportion to the system's category, with the CCN's certification body setting the requirements. Annex II measure op.pl.5, which applies to MEDIUM and HIGH systems, then directs entities to the CCN's Catalogue of ICT Security Products and Services (Catálogo de Productos y Servicios de Seguridad de las Tecnologías de la Información y Comunicación, CPSTIC) for third-party products in the security architecture.
• Incidents. Article 25 requires incident management procedures, with detection mechanisms, classification criteria, analysis and resolution procedures and a record of actions. Article 33 sets CCN-CERT as the CCN's incident response structure and requires public sector entities to notify the CCN of incidents with a significant impact on their systems. Suppliers should expect their contract to set how they feed those notifications.
• Audit and conformity. Article 31 requires a regular ordinary audit of systems in scope at least every two years, according to the system's category and Annex III, and an extraordinary audit after substantial changes. Article 38 sets the conformity process: BASIC systems need only a self-assessment for a Declaration of Conformity, while MEDIUM and HIGH systems need an audit for a Certification of Conformity. Declarations and certifications must be published on the entity's website or electronic office.
• Profiles and transition. Article 30 allows specific compliance profiles, validated and published by the CCN. The single transitional provision gave systems that existed when the decree entered into force on 5 May 2022, including those of private contractors, 24 months to adapt, so that window closed in May 2024. New systems apply the decree from design.

Four Annex II reinforcements describe what is, in practice, an SBOM. Read the application lines carefully, because none of them is in the default set for any category. They become binding when your risk analysis, a CCN compliance profile or a contract calls for them, and auditors and contracting authorities increasingly ask about them.

• op.exp.1 R4, list of software components. The base measure, which applies at every category, is an updated inventory of all elements of the system, each with an identified owner. R4 adds a formal, updated list of the third-party software components used to deploy the system, including software libraries and the services they need (the platform or operating environment), with content equivalent to mp.sw.1 R5.
• mp.sw.1 R5, the developer's list. mp.sw.1 (application development) applies to MEDIUM and HIGH systems with reinforcements R1 to R4 (least privilege, a secure development methodology, security by design, and test data that avoids real data where possible). R5 asks the developer to keep a formal list of third-party components in the application, with a history across versions and at minimum the component, the manufacturer and the version, with the detail set in a CCN-STIC guide.
• op.ext.3 R3, supply chain register. op.ext.3 (supply chain protection) applies to HIGH systems. R3 asks for a register of the supply chain details of the components used to build software, provided by the supplier of the application, library or product.
• op.pl.5 R2, component list in the product description. Each product and service includes a list of software components in its description.

The link that turns these lists into daily work is op.exp.4 (security maintenance and updates). It applies at every category: follow the manufacturer's defect notices and have a procedure to analyse, prioritise and decide when to apply security updates, weighing how the risk changes. MEDIUM adds testing in pre-production (R1), HIGH adds a rollback mechanism (R2), and reinforcement R4 asks for a continuous threat and vulnerability monitoring strategy whose patch policy covers the components on the op.exp.1 R4, op.ext.3 R3 and mp.sw.1 R5 lists.

Also read op.exp.2 (security configuration), op.exp.3 (configuration management), op.ext.1 and op.ext.2 (contracts, service levels and daily management) and mp.sw.2 (acceptance before production, at every category).

The CCN publishes the technical security instructions and CCN-STIC guides that explain how to apply ENS, and its ENS portal collects them with the compliance profiles. The decree itself refers to a CCN-STIC guide for the minimum content of the mp.sw.1 R5 component list.

NIS2 in Spain: still a bill, with the 2018 regime in force

NIS2 (Directive (EU) 2022/2555) had to be transposed by 17 October 2024. Spain missed that date. The European Commission sent a letter of formal notice on 28 November 2024 and a reasoned opinion on 7 May 2025, and on 8 July 2026 it referred Spain, together with Ireland, France and the Netherlands, to the Court of Justice of the European Union, asking for a lump sum and daily penalties until full transposition is notified. On 20 January 2026 the Commission also proposed targeted amendments to NIS2 as part of a cybersecurity package.

The government has prepared a draft Cybersecurity Coordination and Governance Law (Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad), but as of 26 October 2026 no transposing law has been published in the Official State Gazette (Boletín Oficial del Estado, BOE). Royal Decree 806/2026 dissolved the Congress and the Senate on 6 October 2026 and called a general election for 29 November, with the new chambers meeting on 23 December. Under Article 207 of the Congress standing orders, business pending when the Congress is dissolved lapses. A transposing law therefore has to start, or restart, in the new parliament.

Until then, two texts apply:

• Royal Decree-law 12/2018 on the security of networks and information systems, which transposed NIS1. It requires operators of essential services and digital service providers to take appropriate security measures and to notify significant incidents to their reference CSIRT. Article 11 names the three: CCN-CERT for entities within the public sector, INCIBE-CERT for the rest (operated jointly with the National Centre for the Protection of Critical Infrastructures for critical operators), and ESPDEF-CERT of the Ministry of Defence in support.
• Royal Decree 43/2021, which develops it, including the incident notification process and its annex. ENS Article 25 points operators of essential services and digital service providers to that annex for their incident procedures.

The directive's own text is settled, so most organisations prepare against NIS2 Article 21 (the ten risk management measures, including (d) supply chain security and (e) security in acquisition, development and maintenance, with vulnerability handling and disclosure) and Article 23 (early warning within 24 hours, incident notification within 72 hours and a final report within one month). When the Spanish law is published, map your evidence to its numbering.

DORA and the Bank of Spain, CNMV and DGSFP

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied since 17 January 2025. It is directly applicable, so there is no Spanish transposition to wait for. The parts that touch software most are Article 8 (identify ICT assets and their dependencies), Article 9 (protection and prevention, including patching), Articles 17 to 19 (incident management and major incident reporting), Article 28 (ICT third-party risk and the register of information under Article 28(3)) and Article 30 (key contractual provisions, including data location and security).

In Spain, the Bank of Spain, the CNMV and the DGSFP supervise DORA for the entities each already supervises. Royal Decree-law 8/2023 of 27 December 2023 went further than the regulation: it applies DORA's Chapter II on ICT risk management to payment system operators, payment scheme operators, electronic payment arrangement operators, payment processors and other technological or technical service providers, and makes the Bank of Spain the competent authority to supervise and sanction those duties. A software or processing firm that would not be a DORA financial entity elsewhere can be inside Chapter II in Spain.

The AEPD, the GDPR and the LOPDGDD

The GDPR applies as in every member state. For software teams, Article 25 (data protection by design and by default), Article 28 (processor contracts), Article 32 (security of processing) and Articles 33 and 34 (notifying a personal data breach to the authority within 72 hours where feasible, and to individuals where the risk is high) are the working parts. The LOPDGDD adds Spanish detail, including the regime for the data protection officer (delegado de protección de datos) in Articles 34 to 37. The AEPD is the national supervisor.

AESIA and the EU AI Act

The AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024. According to the European Commission, prohibited practices and the AI literacy duty have applied since 2 February 2025, governance rules and the obligations for general purpose AI models since 2 August 2025, and the Act became generally applicable on 2 August 2026, with exceptions. After the political agreement on the AI Omnibus, the rules for high-risk use cases in the sensitive areas of Annex III apply from 2 December 2027 and those for AI embedded in regulated products under Annex I from 2 August 2028.

Spain created its supervisor early. The Spanish Agency for the Supervision of Artificial Intelligence (Agencia Española de Supervisión de Inteligencia Artificial, AESIA) has a statute approved by Royal Decree 729/2023 of 22 August 2023, and its seat is in A Coruña.

The law meant to give AESIA its AI Act powers did not make it. The government's Organic Bill for the good use and governance of artificial intelligence (Proyecto de Ley Orgánica para el buen uso y la gobernanza de la inteligencia artificial, file 121/000096) was published in the Congress gazette on 12 June 2026, with amendments due by 30 June. It designated AESIA as market surveillance authority for a list of high-risk AI systems and gave other bodies, including the data protection authorities and the General Council of the Judiciary, specific areas. It lapsed with the dissolution of 6 October 2026. Until a new law passes, the AI Act's directly applicable articles apply, AESIA works under its statute, and deployers should still prepare the inventories, risk classifications and documentation the Act requires.

The EU Cyber Resilience Act

The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its reporting obligations under Article 14 have applied since 11 September 2026: a manufacturer that becomes aware of an actively exploited vulnerability in its product must send an early warning within 24 hours, a notification within 72 hours and a final report, through the single reporting platform run by ENISA, addressed to the CSIRT designated as coordinator in the member state of its main establishment. Severe incidents follow the same clock. The full requirements, including Annex I Part II(1), which asks manufacturers to identify and document components and vulnerabilities, including by drawing up an SBOM covering at least the top-level dependencies, apply from 11 December 2027.

What the rules ask of software and open source

Read across the regimes and the same handful of duties appear. The table maps each to the evidence a Spanish auditor, supervisor or contracting authority is likely to ask for.

Two points are easy to miss.

First, the ENS component list is not only about the code you write. op.exp.1 R4 explicitly includes the platform or operating environment the libraries need. A container base image, a runtime and a managed database version belong on the list.

Second, the ENS conformity duty flows down. Article 2.3 lets contracting authorities require the contractor's supply chain to show conformity in proportion to risk. A subcontractor that writes a module for a ministry's system can be asked for evidence even though it never signs with the ministry.

Real public incidents in or affecting Spain

Primary and official reporting only, with dates. These are not offered as lessons about what any victim should have done.

• Hospital Clínic de Barcelona, March 2023. INCIBE-CERT's security log records that the hospital notified a ransomware attack on 5 March 2023. Emergency, laboratory and pharmacy services were disrupted and staff worked by hand while systems were restored. The attackers demanded a ransom of 4.5 million dollars, and the regional government said it would not pay. The hospital notified the Catalan Cybersecurity Agency.
• Banco Santander, May 2024. On 14 May 2024 the bank stated that it had become aware of unauthorised access to a Santander database hosted by a third-party provider, affecting some customers in Chile, Spain and Uruguay and current and some former employees. It said no transactional data or credentials were in the database, its operations and systems were not affected, and it had notified regulators and law enforcement. The incident sat with a third-party provider, the relationship DORA Article 28 governs.

The personas who own the problem

The CISO or Responsable de Seguridad. The CISO needs to know which systems are in scope and at what category, what the audit will find, and how fast the organisation can say whether a published vulnerability affects it. The trigger is usually the two-yearly ENS audit, a contracting authority's tender clause, or a supervisor letter from the Bank of Spain or the CNMV under DORA.

The head of AppSec or VP of Engineering. They need the component list and the patch evidence to come out of the build, not out of a spreadsheet someone fills before the audit. Their trigger is the audit request for op.exp.1 and op.exp.4 evidence, a CRA early warning, or a customer asking for an SBOM in a tender.

The GRC or compliance lead. They own the mapping from measures to evidence, the Declaration or Certification of Conformity, the DORA register of information and the readiness for the NIS2 law. They need evidence by clause, with dates, and a list of gaps they can schedule.

Procurement and vendor risk. In public bodies they write the contract specifications that ask for ENS conformity. In banks they keep the DORA register and the Article 30 clauses. In suppliers they answer both. They need to know what to ask each supplier for and when.

The data protection officer (DPO). The DPO needs a data flow map that is accurate to the component and the hosting location, a breach process that meets the 72-hour clock, and an inventory of AI systems processing personal data.

A practical 30/60/90-day plan

This plan works with spreadsheets and open source tools as well as with a platform. Adjust the order to your trigger: an audit date, a tender deadline or a supervisor letter.

Days 1 to 30: scope, inventory and ownership

1. Decide which regimes apply. List every legal entity, its sector and its customers. Mark ENS (public sector or a supplier to it), RDL 12/2018 and the coming NIS2 law (essential or important entity), DORA (financial entity or ICT supplier to one), CRA (products with digital elements sold in the EU), GDPR and the AI Act.
2. Categorise ENS systems. For each system that supports a public sector service, rate it BASIC, MEDIUM or HIGH using Annex I. That decides whether you need a Declaration or a Certification of Conformity.
3. Name owners. Assign the ENS roles your policy defines, a DORA ICT risk owner if you are a financial entity, a CRA product security contact if you are a manufacturer, and the DPO.
4. Build the component inventory. Generate an SPDX or CycloneDX SBOM for every application and container image, on every build. Include the base image and runtime so the list matches op.exp.1 R4, and keep each version's list so you have the history mp.sw.1 R5 describes. Store each SBOM with the release it describes.
5. Start a supplier register. List every ICT supplier, the service, the data it touches and the systems it supports. For banks this is the start of the DORA register of information.

A one-page scope template you can use today:

Days 31 to 60: vulnerability handling and suppliers

6. Set patch targets and write them down. ENS op.exp.4 and DORA Article 9 ask for a maintenance process. Pick target times by severity and exploitation status, and decide who can grant an exception and for how long.
7. Prioritise by exploitation and reachability. Use EPSS and the CISA Known Exploited Vulnerabilities catalogue to rank findings, and check whether the vulnerable function is actually called.
8. Gate releases. Fail or flag builds that introduce components with known exploited vulnerabilities, unpinned versions or licences you have not approved. Record each exception with a reason and an expiry.
9. Practise the clocks. Run a table-top for a library being actively exploited. Time how long it takes to answer: which products and versions contain it, which customers run them, and who must be told. Map the result to the CRA 24-hour early warning, the NIS2 24-hour and 72-hour steps, DORA's major incident reports and the GDPR's 72 hours.
10. Ask suppliers for evidence. Send a standard request for an SBOM in SPDX or CycloneDX, a vulnerability disclosure contact, patch commitments and ENS conformity where the contract requires it. Track responses and validate them before accepting.

Days 61 to 90: evidence, AI controls and residency

11. Assemble the audit pack. For each ENS measure that touches software, file the evidence: SBOMs, scan results, patch records, exceptions, supplier answers and acceptance records.
12. Inventory AI. List every AI model, API, agent and MCP server in use, who owns it, what data it sees and what it can do. Classify each against the AI Act's risk categories and note any that could be high risk under Annex III.
13. Control agent access. Give each AI agent its own identity and the least access it needs, and log what it does.
14. Decide residency. Document where code, SBOMs, findings and personal data are processed, and check each against your contracts and the GDPR transfer rules.
15. Rehearse the conformity outcome. For BASIC systems, complete the self-assessment and Declaration of Conformity. For MEDIUM and HIGH, book the certification audit with an accredited body and run an internal pre-audit.
16. Report up. Give management a one-page view: systems by category, audit dates, overdue critical findings and supplier gaps.

Common mistakes

• Treating ENS as a public sector only rule. Article 2.3 brings private suppliers into scope, and contract specifications make it a bid condition.
• Building the component list once, before the audit. op.exp.1 asks for an updated inventory, and R4 an updated component list. A list from last year's release is not evidence for this year's system.
• Ignoring the component list reinforcements because they are not defaults. A contract, a compliance profile or your own risk analysis can make op.exp.1 R4 and mp.sw.1 R5 binding, and R4's list covers the platform the libraries need, not only the package manifest.
• Waiting for the Spanish NIS2 law. With the Cortes dissolved, it cannot pass until the new parliament sits. The directive's Article 21 and 23 duties are settled, and building the evidence now costs the same as building it later.
• Assuming DORA is the bank's problem only. Software vendors to Spanish banks will be asked for Article 30 clauses and register data.
• Mixing clocks. The CRA, NIS2, DORA, the GDPR and ENS each have their own trigger and recipient. One incident can start several.
• Forgetting the payment rules. Royal Decree-law 8/2023 puts some payment processors and technical providers under DORA's ICT risk chapter in Spain.

How Safeguard does this

Everything in the plan above works without Safeguard. This section shows how the same steps run in Safeguard, using only what Safeguard's documentation describes. Every capability named here is generally available (GA).

1. Turn on the Spain ENS and NIS2 framework pages. In the Compliance and GRC suite (GA), the Spain ENS (RD 311/2022) and EU NIS2 frameworks are on in a workspace unless you switch them off under Compliance › Manage. Each page lists requirements that a scan decides, plus controls from Safeguard's own control catalogue that you evidence with automated tests, uploaded evidence, policies or an attestation. On the ENS page, the scan requirements point at Annex II measures such as op.exp.1 for the asset inventory and op.ext for external services. The identifiers on those pages are Safeguard's own, not the CCN's.
2. Generate SBOMs on every scan. SBOM generation and analysis (GA) produces SPDX and CycloneDX, and SCA with deep transitive dependency scanning (GA) builds the full component inventory. Each scan of a product is checked against the framework's requirements, including whether components carry versions and hashes and whether suppliers are known.
3. Scan without sending source code. For teams that will not grant repository access, the local runner (GA) is part of the Safeguard CLI. As the docs show, you install the CLI, run safeguard, type /login, and the machine starts polling for work. It runs each scan locally and uploads only the SBOM and findings, never the source code. All traffic is outbound HTTPS that the runner opens. For headless use the docs show:

# Start without the terminal UI and serve assistant turns for this workspace
safeguard runner start --workspace ./path/to/repo
# Is it running, and what is it doing
safeguard runner status
# Drain in-flight work and stop
safeguard runner stop

4. Prioritise what is exploited and reachable. Vulnerability management (GA) matches components against advisories and adds EPSS and CISA KEV context. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls, which is how you meet a 24-hour clock without drowning in findings.
5. Gate releases and record exceptions. Policies and gates (GA) are set under Settings › Policies with a visual builder or YAML. Each policy's action is Block, Warn or Notify. When a legitimate exception is needed, a developer requests one with a business justification and expiry date, approvers decide, and the audit trail is recorded. In CI, with policy outcomes on, the docs show a job failing when a gate fails:

safeguard ci scan --wait --fail-on-gate <gate>

6. Collect evidence from suppliers. TPRM (GA) keeps the vendor directory. Its SBOM requests let you send single or bulk requests from a template that sets SPDX or CycloneDX format and a deadline, track status from Sent to Validated, send automatic reminders, and validate each submission for format and completeness before it is scanned. That is the evidence behind ENS op.ext, a DORA register entry or a NIS2 Article 21(2)(d) control.
7. State what is and is not affected. CSAF and VEX upload (GA) lets you hold and share exploitability statements, which helps when a contracting authority, a bank customer or CCN-CERT asks whether a published vulnerability affects your product.
8. Fix, with a human in charge. Autonomous remediation (GA) can open tested, policy gated fix pull requests, singly or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own.
9. Inventory and govern AI. AI-BOM discovery (GA) inventories AI assets. AI Gateway (GA) evaluates prompts, responses and tool calls against guardrails such as prompt injection, jailbreak and PII egress; in monitor mode, the default, it records a guardrail event for each and lets traffic pass unchanged, so you can baseline what your AI features do. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access, at what level. These map to the AI inventory and agent access steps in the plan.
10. Share posture with buyers. Trust Center (GA) publishes posture and documents such as SBOMs and VEX to customers, and helps answer security questionnaires in a tender.
11. Choose where it runs. Safeguard's SaaS is multi-region across US, EU and Gov regions; no Spain-specific region is offered or implied. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU. For residency, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped with the AI models running inside your environment and signed offline snapshot delivery. Zero AI mode (GA) runs the whole platform deterministically with no LLM in the loop, and bring your own model (GA) is available for teams with an approved model list.

Safeguard's posture wording is limited to what its Trust Center says: SOC 2 Type II audit in progress, and designed for FedRAMP High. Safeguard is not ENS certified, does not hold a Declaration or Certification of Conformity with the ENS, and is not listed in the CPSTIC.

What Safeguard does not do

• It does not make you ENS conformant. Safeguard helps you produce and keep the evidence the ENS measures ask for. The Declaration of Conformity, or the Certification after an audit by an accredited body, stays with your organisation and your auditor.
• It is not a CPSTIC product, and it does not replace one. Where op.pl.5 or Article 19 requires a CPSTIC listed or certified product in your security architecture, choose that product on its own merits. Safeguard can run inside an environment you have already approved through the on-prem, air-gapped and local runner options.
• It does not report to CCN-CERT, INCIBE-CERT, the Bank of Spain, the AEPD or ENISA for you. It helps you answer "which products and versions are affected" quickly. Filing the notification is your team's job, in the channel the authority sets.
• It does not decide your category or your scope. Rating a system BASIC, MEDIUM or HIGH, and deciding whether the NIS2 law, DORA or the AI Act's high-risk rules apply, needs your own analysis and legal advice.
• It does not write your contracts. DORA Article 30 clauses, GDPR Article 28 processor terms and ENS contract specifications need your legal and procurement teams.
• It does not fix vendor appliances or hosted services. When a vulnerability sits in a product you buy rather than build, the fix comes from that vendor. Safeguard helps you track the request and the evidence.

FAQ

Does the ENS apply to private companies?

Yes, when their information systems support services or solutions they provide by contract to public sector bodies. Article 2.3 of Royal Decree 311/2022 says so, and requires those companies to have a security policy approved by their top executive body.

Does the ENS require an SBOM?

It does not use the word. Annex II reinforcements op.exp.1 R4, mp.sw.1 R5, op.ext.3 R3 and op.pl.5 R2 describe a formal, updated list of third-party software components, with at least the component, manufacturer and version. They are reinforcements that a risk analysis, compliance profile or contract makes binding, not defaults. An SPDX or CycloneDX SBOM per release is the practical way to meet them.

What is the difference between an ENS Declaration and Certification of Conformity?

Under Article 38, systems in the BASIC category may self-assess and issue a Declaration of Conformity. MEDIUM and HIGH systems need a Certification of Conformity after a formal audit by an accredited certification body.

How often is an ENS audit needed?

Article 31 requires a regular ordinary audit at least every two years, carried out according to the system's category under Annex III, and an extraordinary audit after substantial changes. For BASIC systems, the conformity route is a self-assessment.

Is NIS2 in force in Spain?

Not as Spanish law on 26 October 2026. The Commission referred Spain to the EU Court of Justice on 8 July 2026 for not transposing it, and the Cortes were dissolved on 6 October 2026 ahead of the 29 November election. Royal Decree-law 12/2018 and Royal Decree 43/2021 still apply.

Who supervises DORA in Spain?

The Bank of Spain, the CNMV and the DGSFP, each for the entities it already supervises. DORA has applied since 17 January 2025, and Royal Decree-law 8/2023 extends its ICT risk chapter to some payment operators and technical providers under Bank of Spain supervision.

What is AESIA?

The Spanish Agency for the Supervision of Artificial Intelligence, with a statute approved by Royal Decree 729/2023 and its seat in A Coruña. The organic bill that would have designated it as a market surveillance authority under the AI Act lapsed when the Cortes were dissolved on 6 October 2026, so its AI Act powers await a new law.

When do Spanish manufacturers have to report under the EU CRA?

Since 11 September 2026, for actively exploited vulnerabilities and severe incidents, under Article 14, starting with an early warning within 24 hours through ENISA's single reporting platform. The full product requirements, including the SBOM, apply from 11 December 2027.

Every Spanish regime above comes back to the same question: when a vulnerable component is named, how fast can you find it and fix it. The block below sets out the ways Safeguard closes the gap between a disclosure and a fixed build, including when upstream has not shipped a fix yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow is how an ENS supplier closes a vulnerability and keeps the op.exp.4 record, with a human approving each change.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. This is the option for public bodies and banks that will not let source code leave their network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For teams preparing their AI inventory for the AI Act and AESIA, it shows what scoped agent access looks like in practice.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• BOE: Royal Decree 311/2022, Esquema Nacional de Seguridad (consolidated text)
• BOE: Royal Decree-law 12/2018 on the security of networks and information systems
• BOE: Royal Decree 43/2021 developing Royal Decree-law 12/2018
• BOE: Royal Decree 729/2023 approving the AESIA statute
• BOE: Organic Law 3/2018 (LOPDGDD)
• BOE: Royal Decree-law 8/2023 (DORA Chapter II for payment operators)
• BOE: Royal Decree 806/2026 dissolving the Cortes and calling elections
• BOE: Standing Orders of the Congress of Deputies, Article 207
• Congress gazette: Organic Bill 121/000096 on the good use and governance of AI (PDF)
• European Commission: referral of Ireland, Spain, France and the Netherlands over NIS2 (IP/26/1499)
• CCN: ENS portal
• AESIA
• AEPD
• INCIBE-CERT: ransomware attack paralyses activity at Hospital Clínic in Barcelona
• Santander: statement of 14 May 2024
• European Commission: NIS2 Directive
• European Commission: Cyber Resilience Act
• European Commission: AI Act regulatory framework and timeline
• Safeguard docs: Spain ENS (RD 311/2022) framework
• Safeguard docs: EU NIS2 framework
• Safeguard docs: Local Runner
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: Deployment options
• Safeguard docs: AI Gateway

Related reading: Spain's NIS2 transposition delay and the reasoned opinion, the France country guide in this series, SBOM requirements for financial services under DORA, lessons from the April 2025 DORA register of information and CRA Article 14 vulnerability reporting.

To try the flows above, download Safeguard and read the Safeguard documentation.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.