The ENS sets out two obligations regarding your technology providers that are not the same: Article 2.3 of Royal Decree 311/2022 extends security precautions to the supply chain “to the extent necessary” based on risk analysis, from any category; and measure op.ext.3 of Annex II, literally called “Protection of the supply chain”, is only mandatory at HIGH category. Confusing the two leads to requiring too much or too little.
The ENS requires two different things regarding your technology providers, and confusing them leads to false conclusions in both directions. On one hand, Article 2.3 of Royal Decree 311/2022 requires extending security precautions to the supply chain "to the extent necessary and in accordance with the results of the corresponding risk analysis", from any category. On the other, the Annex II measure literally called "Protection of the supply chain" (op.ext.3) is only mandatory at HIGH category. Translating these legal obligations into contract clauses is part of our ENS technical implementation service.
What the ENS says about the supply chain of your contractors (Art. 2.3)
Article 2.3 of Royal Decree 311/2022 requires that the specifications of contracts entered into by entities subject to the ENS include the requirements necessary to ensure the conformity of the systems underpinning the contracted services, and adds:
"This precaution shall also extend to the supply chain of those contractors, to the extent necessary and in accordance with the results of the corresponding risk analysis."
— Royal Decree 311/2022, Art. 2.3 (BOE-A-2022-7191)
The key is "to the extent necessary": the obligation is proportional to risk, not automatic by category. The risk analysis that determines this starts by correctly calculating your system's category (available in Spanish), although, as the next section shows, Article 2.3 can require contractual precautions regarding providers even before the formal Annex II measure is active.
The specific Annex II measure, op.ext.3: why it is only mandatory at HIGH category
op.ext.3 is part of the same Annex II we broke down here. Verified directly against the official table: op.ext.3 is "not applicable" at both basic and medium, and only becomes a formal requirement at high category; the rest of the op.ext family (contracting, day-to-day management and interconnection) already gets activated at medium, as we detail in what medium category adds over basic. This does not mean the supply chain "does not matter" until high: Article 2.3 can require contractual precautions earlier if the risk analysis justifies it, with no need for op.ext.3 to be active as a formal measure.
When op.ext.3 is active (high category), it includes three reinforcements with very specific clauses: R1, a contingency plan covering dependence on critical providers; R2, protection of B2B data flows; and R3, a register of software components, very similar to what is known internationally today as an SBOM (software bill of materials):
"[...] an up-to-date formal register shall be maintained containing the details and relationships of the supply chain of the various components used in building computer programs [...]. This list shall be provided by the supplier of the application, library or product supplied."
— Royal Decree 311/2022, Annex II, reinforcement op.ext.3.R3 (BOE-A-2022-7191)
Why this is not a single box to tick: four obligations with four different legal bases
It is common to treat "provider security" as if it were a single requirement met with a generic confidentiality clause. Royal Decree 311/2022 actually distinguishes four separate obligations, each with its own legal basis: the risk-proportional extension under Article 2.3, product certification under Article 19, staff qualification under Article 16, and the formal Annex II continuity measure for critical-provider failure (op.ext.3). Meeting one does not mean meeting the rest: a provider can have perfectly qualified staff (Art. 16) and still not offer any product with security certification proportional to your category (Art. 19), or vice versa.
Before the supply chain: what to require from any provider from MEDIUM onwards (op.ext.1 and op.ext.2)
Before reaching op.ext.3, two measures from the same family already apply from medium category to any external provider, not only critical ones: op.ext.1 requires a formal Service Level Agreement (SLA) before using the resource, and op.ext.2 requires a routine system for measuring that SLA and maintenance-coordination procedures. op.ext.3 only applies at high; for the rest of the measures by category, check the full basic-category breakdown and its continuation at medium.
If your provider is a cloud infrastructure provider, these general clauses come on top of what the specific op.nub.1 measure requires: we cover it in this guide on the ENS in the cloud. We already explained your provider's service model (SaaS, PaaS or IaaS) here, and it determines exactly which clause applies.
Certified security products and services: what Article 19 of Royal Decree 311/2022 requires
Article 19 requires that the security products and services acquired hold certified security functionality, proportional to the system's category, and it refers to the CCN the determination of functional requirements and additional certifications. This is the legal basis for why not just any "security" product is equally valid for any category: the higher the category, the more demanding the certification level that can be required.
Qualified provider staff: what Article 16 (professionalism) requires
Article 16 requires qualified, dedicated staff trained throughout the system's lifecycle, and expressly requires organisations to demand, in an objective and non-discriminatory way, that organisations providing security services have qualified professionals. This is a different obligation from the product certification in Article 19: here, what gets certified is the competence of the people providing the service, not the product.
The mandatory security point of contact in outsourced services (Art. 13.5) and why it does not release you from responsibility
Article 13.5 requires the provider of an outsourced service to appoint a security point of contact, but it is explicit that this does not transfer responsibility: "without prejudice to the fact that ultimate responsibility lies with the public-sector entity receiving those services." Requiring evidence of security testing from the provider connects with pentesting and red teaming, covered in detail in that guide: a point of contact with no technical evidence behind it is a ticked box, not a real guarantee.
A common case: the provider that resists signing these clauses
In practice, not every technology provider — especially smaller ones, or those not used to working with the public sector — is familiar with these requirements, and some resist signing a formal SLA or committing to maintaining a register of software components. Two situations are worth distinguishing here: if the provider cannot offer the evidence because their service does not allow it (for example, a closed component with no visibility into its internal dependencies), that is a genuine risk signal that should weigh on the contracting decision. If the provider simply has never done it because nobody had asked before, the negotiation is usually resolved by explaining exactly what the regulation requires and why the requirement is not arbitrary on your organisation's part, but an obligation you yourself have to pass down the chain.
The three specific op.ext.3 clauses that can go into a contract
For high-category systems, or for any organisation that wants to get ahead based on its own risk analysis, the three op.ext.3 clauses translate into a contract as follows: (1) a documented contingency plan in case a critical provider fails, with identified alternatives; (2) specific protection of B2B information-exchange flows with that provider, not just general access; and (3) the contractual obligation for the provider to deliver and keep up to date a register of the software components (libraries, dependencies) that are part of what they supply. These clauses coexist with what GDPR compliance requires when the provider processes personal data: they are parallel obligations, not substitutes for one another.
Checklist: what to require from a technology provider depending on your category
- Any category (Art. 2.3): risk-proportional precautions if the analysis justifies it, even if the formal measure is not yet active.
- From medium (op.ext.1, op.ext.2): a formal written SLA and a measurement and maintenance-coordination procedure.
- From medium (Art. 19, Art. 16): products with security certification proportional to the category and qualified, accredited provider staff.
- Only at high (op.ext.3): a contingency plan for critical-provider failure, B2B flow protection and a software components register.
If the cost of auditing your providers is a barrier, there are cybersecurity grants for SMEs that may cover part of that work; it is worth checking the current call for applications before assuming it in a proposal to a client.
Frequently asked questions
Do I have to require supply-chain clauses if my system is basic category?
The formal op.ext.3 measure does not require it at basic: it is only mandatory at high. But Article 2.3 of the Royal Decree can require risk-proportional contractual precautions from any category, if your own risk analysis justifies it. These are two separate layers, not a single box.
What is the "software components list" the ENS asks for, and what is it similar to?
It is reinforcement R3 of op.ext.3: an up-to-date register of the components (libraries, dependencies) used in building a piece of software, which the provider itself must supply. It is functionally equivalent to what is known internationally today as an SBOM (software bill of materials), although Annex II does not use that term.
Does Article 2.3 also apply to providers of private entities, or only public-sector ones?
Article 2.3 is drafted within the framework of public-sector contract specifications. Private companies acting as providers to those entities are reached through the contractual relationship, not as a direct subject of the article, but in practice this is the mechanism through which the requirement gets passed down the chain.
This content is for general information purposes only. It does not constitute legal advice and does not replace the analysis of a qualified professional for your specific case.