Measure op.nub.1 of the ENS Annex II requires third-party cloud services to be conformant with the ENS or to comply with an equivalent CCN-STIC guide on pentesting, transparency, encryption/key management, and data jurisdiction. It already applies from basic category, with no reinforcement. And a certified provider does not exempt you from responsibility: Article 13.5 of Royal Decree 311/2022 leaves it with the entity providing the final service.
Spain's National Security Framework (ENS) sets out a specific measure for when a system uses cloud services: op.nub.1, protection of cloud services. And no, contracting a cloud provider that is "certified" or "ENS-compatible" does not release you from responsibility: Royal Decree 311/2022 itself literally states that ultimate responsibility stays with your organisation.
The specific measure: op.nub.1, "Protection of cloud services"
If you are considering migrating, or already work with cloud infrastructure, this is what the ENS requires from that provider. Measure op.nub.1 in Annex II of Royal Decree 311/2022 is the only one in its family (op.nub) and it already applies from basic category, with no reinforcement. Requirement [op.nub.1.1] refers compliance to whichever CCN-STIC guides apply depending on the service model contracted, and requirement [op.nub.1.2] adds, for services provided by third parties, the following literal requirement:
"When cloud services provided by third parties are used, the information systems that support them must be conformant with the ENS or comply with the measures set out in a CCN-STIC guide that will include, among others, requirements relating to: a) Penetration testing audits (pentesting). b) Transparency. c) Encryption and key management. d) Jurisdiction of the data."
— Royal Decree 311/2022, Annex II, requirement [op.nub.1.2] (BOE-A-2022-7191)
This measure is part of the same Annex II we broke down here, and it already applies at basic: to see the rest of your category's measures, check the full basic-category list.
What it requires depending on the service model: SaaS, PaaS and IaaS
Requirement [op.nub.1.1] does not treat a SaaS the same way as an IaaS: the more management responsibility the provider takes on (SaaS), the more the application of the relevant CCN-STIC guides falls on them; the more responsibility falls on the client (IaaS), the more direct technical control you have and the more evidence you will have to provide yourself. We already explained the difference between these three models here: the ENS requires different things depending on which one you contract, not because the regulation discriminates between models, but because the actual split of technical responsibility changes.
In a SaaS, the provider manages the entire technical stack: operating system, network, application. There, the evidence you can demand is mostly documentary — certifications, audit reports, contractual clauses — because you have no direct access to the underlying infrastructure. In an IaaS, the provider only manages the physical and virtualisation infrastructure layer; the operating system, applications and much of the security configuration remain on your side, so the evidence op.nub.1 requires about the "cloud service" is split between what the provider contributes and what you have to document yourself. A PaaS sits in between: the provider manages the runtime environment, but the code and much of the application's configuration remain your responsibility. Confusing these three splits is the most common reason a Statement of Applicability for op.nub.1 ends up incomplete: what the provider contributes gets documented, and what remains on the client's side gets forgotten.
What to require from a third-party cloud provider: ENS conformity or an equivalent CCN-STIC guide
Annex II itself gives two valid routes for a third-party provider: either the service is conformant with the ENS, or it complies with an equivalent CCN-STIC guide covering the four points quoted above. It is not enough to ask for "a security certification" in generic terms: you have to ask for specific evidence of those four points, or of the ENS conformity of the contracted service. It is also not enough to assume that a well-known international provider automatically meets this just because of its size or reputation: the requirement is documentary and specific, not a presumption of trust.
In practice, this means asking the provider, before signing, for the specific documentation proving each of the four points — not a generic statement that "we comply with industry standards" — and recording in writing which CCN-STIC guide or which ENS conformity scheme covers the contracted service. If the provider cannot precisely identify which of the two routes covers their service, that is a sign the analysis has not been done yet, on their side or on yours.
The four points the guide requires reviewing: pentesting, transparency, encryption and key management, jurisdiction of the data
- Penetration testing audits (pentesting): demand evidence that the service undergoes periodic intrusion tests. Requiring pentesting from the cloud provider connects directly with pentesting and red teaming, covered in detail in that guide.
- Transparency: real visibility over where and how data is processed, not a generic statement of trust.
- Encryption and key management: the in-transit encryption this guide requires rests on the same TLS fundamentals we already covered here, plus management of the keys' lifecycle.
- Jurisdiction of the data: which law the provider is subject to, not just which physical country the data centre is in. This nuance — a provider can be subject to foreign legislation even if it hosts data in a European data centre — is worth verifying case by case in the contract, not assuming as a given.
The reinforcements: recognised certification (R1) and specific configuration guides (R2)
On top of the base measure, Annex II adds two reinforcements: R1 requires the service to be certified under a methodology recognised by the CCN's Certification Body, and R2 requires the service's configuration to follow a specific CCN-STIC Security Configuration guide.
What each category requires: basic, medium and high for op.nub.1
- Basic category: op.nub.1 with no reinforcement.
- Medium category: op.nub.1 + R1 (recognised certification).
- High category: op.nub.1 + R1 + R2 (recognised certification and specific configuration guide).
Responsibility is NOT transferred to the provider (even if certified)
Article 13.5 of Royal Decree 311/2022 is explicit on this point. In outsourced services, the provider appoints a security point of contact, but:
"[...] without prejudice to the fact that ultimate responsibility lies with the public-sector entity receiving those services."
— Royal Decree 311/2022, Art. 13.5 (BOE-A-2022-7191)
A cloud provider certified under the ENS reduces risk and makes evidence easier to gather, but it does not shift legal responsibility. If your cloud provider fails, service continuity still depends on a real backup and recovery plan, not just the provider's promise; and on those backups actually restoring, not just existing.
This distribution of responsibility has a practical consequence that often gets overlooked: if a security incident originates in the cloud provider's infrastructure, the entity providing the final service is still the one that answers to the ENS conformity auditor, still the one that has to report the incident under its own procedures, and still the one that bears the consequences of any eventual sanction or non-compliance. The contract with the provider can later split that financial responsibility between the parties, but that happens on a different plane — civil or commercial — from the one Article 13.5 sets out: as far as the ENS is concerned, responsibility cannot be subcontracted.
How this translates in practice: contractual clauses and evidence to request
In a contract or tender with a cloud provider subject to op.nub.1, it is worth demanding in writing: evidence of ENS conformity or of compliance with the equivalent CCN-STIC guide; periodic pentesting reports; documentation of encryption in transit and at rest with clearly defined key management, whether the provider's own or shared; and an explicit data-jurisdiction clause. You can also estimate the real cost of a cloud backup that meets these requirements with this calculator (available in Spanish).
A common mistake when preparing the Statement of Applicability is documenting op.nub.1 with a single generic line such as "we use a trusted cloud provider" and considering it closed. The conformity auditor — or the security officer themselves in a basic-category self-assessment — needs specific, dated evidence: the contract or technical annex stating the conformity route chosen, the latest pentesting report received from the provider (or commissioned from a third party on the contracted service), and the encryption and key management policy applied, stating who holds the keys and under what conditions they can be accessed. Without those three dated documents, the measure is declared but not demonstrated, which is exactly the distinction between a solid self-assessment and a box-ticking one.
Auditing whether your current cloud provider meets what op.nub.1 requires is part of our ENS technical implementation service.
Frequently asked questions
Does an ENS-certified cloud provider exempt me from responsibility?
No. Article 13.5 of Royal Decree 311/2022 establishes that ultimate responsibility lies with the entity providing the final service, even if the subcontracted cloud provider is certified and appoints its own security point of contact.
Do I need a provider with an ENS Conformity Statement, or is an international certification (ISO 27001, SOC 2) enough?
Requirement [op.nub.1.2] requires either ENS conformity or compliance with an equivalent CCN-STIC guide covering pentesting, transparency, encryption/key management and data jurisdiction. A generic international certification does not automatically substitute for that requirement: you need to ask for specific evidence of those four points.
From which category does this measure apply?
From basic category, with no reinforcement. Reinforcement R1 (recognised certification) is added at medium, and R1 and R2 (plus the specific configuration guide) are added at high.
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.