Yes, you can comply with the ENS (Spanish National Security Framework) in the cloud, but hiring a "secure" provider isn't enough. The reference is the CCN-STIC 823 guide (use of cloud services); measure op.nub.1 in Annex II requires you to demand conformity from the provider according to the service model (SaaS, PaaS, IaaS), and the public body remains responsible for its share under the shared-responsibility model.
In brief: ENS can be complied with in the cloud, and an increasing number of public tenders require it. The backbone is the CCN-STIC 823 guide and measure op.nub.1, "Protection of cloud services," in Annex II of Royal Decree 311/2022, which points to the relevant CCN-STIC guides depending on the service model. The rule that never changes: the public body that owns the information remains responsible, even when it delegates operation to a third party. Here I cover both sides of the table — the public administration consuming cloud services and the SaaS provider that wants to sell to it — the shared-responsibility model seen through an ENS lens, the CCN-STIC 884-887 profiles for hyperscalers, the role of the CPSTIC catalogue, and the steps for a provider starting from zero.
This article covers one specific thing: how ENS compliance works in the cloud. That's not the same as cloud security in general. If you're looking for how to protect your company's data in the cloud — encryption, backups, access control, GDPR — I cover that in my guide to cloud security for businesses. What follows here is more specific and more demanding: compliance with the Spanish National Security Framework when the service runs in the cloud, with the CCN-STIC 823 guide as the reference and the public sector in the mix. I look at it both from the side of the public body that wants to migrate and from the side of the SaaS provider that wants to get into a tender.
Can you comply with ENS in the cloud? (Quick answer)
Yes, and this isn't an interpretation: ENS itself provides for it. Here are the five points that sum up everything else:
- There's a dedicated guide. CCN-STIC 823 provides guidance on using cloud services within the scope of ENS: service models, deployment models, and the conditions for consuming cloud services with guarantees.
- There's a dedicated measure. The op.nub family in Annex II — specifically op.nub.1, "Protection of cloud services" — applies from the BASIC category upward and requires the cloud service to comply with ENS or with the measures in the corresponding CCN-STIC guide.
- Responsibility isn't outsourced. The public body that owns the information remains accountable for compliance even when it contracts a third party.
- The major providers have already done groundwork. Azure, Microsoft 365, and AWS have CCN-STIC compliance profiles (884, 885, 887), but those cover their share, not yours.
- Conformity is accredited. Through a declaration of conformity at the BASIC category, or through certification at MEDIUM and HIGH, with a scope that must genuinely cover the service provided.
The rest of the article develops each point and turns it into concrete decisions, depending on whether you're on the public buyer's side or the provider's side.
What the CCN-STIC 823 guide is and what it solves
CCN-STIC 823, "Use of Cloud Services," is the guide in the 800 series from the National Cryptologic Centre (CCN) dedicated to bringing ENS into cloud environments. It responds to a real problem: Annex II was designed for systems where the organisation controls the infrastructure, and in the cloud that control is shared with the provider. The guide translates that split into operational criteria.
What guide 823 sets out, in practice:
- Service models. It distinguishes IaaS (the customer controls the operating systems, storage, and applications), PaaS (controls the applications, not the infrastructure), and SaaS (consumes the software without managing the platform). The higher up the stack the service sits, the more responsibility the provider takes on.
- Deployment models. Public, private, community, and hybrid cloud, each with different implications for isolation and control.
- Security levels and dimensions. The service is assessed across the five ENS security dimensions — availability, integrity, confidentiality, authenticity, and traceability — and assigned a level that determines which measures apply.
- What to require from the provider by contract. Service description, security levels, data location, backup and deletion procedures, and conformity with Annex II measures according to the system's category.
A useful nuance in the guide: if you encrypt the information before transferring it to the cloud and manage the keys yourself, most of the requirements on the provider concentrate on the availability dimension, because the provider can't access the content. It doesn't remove obligations, but it does shift the focus.
The op.nub measure in Annex II: what it requires in the cloud
The Royal Decree 311/2022 reform added a new family of measures to Annex II within the operational framework: op.nub, cloud services. This is the point where ENS stops treating the cloud as a special case of "external services" and gives it its own standing.
Measure op.nub.1, "Protection of cloud services," applies from the BASIC category upward — that is, in all of them — and it comes down to this: systems that supply cloud services to the public sector must meet the set of security measures according to the service model (SaaS, PaaS, IaaS), in line with the applicable CCN-STIC guides. And when third-party cloud services are used, the systems that support them must either conform to ENS or meet the measures in a CCN-STIC guide that includes, among other things, audit-testing requirements.
The practical consequence is twofold. For the public body, op.nub.1 turns "procuring cloud" into "procuring conformant cloud": the requirement stops being optional. For the provider, it sets the standard they'll have to demonstrate. And because the measure itself points to the CCN-STIC guides, guide 823 and the platform-specific profiles stop being recommendations and become the expected path.
Shared responsibility: what you can delegate and what you can't
The shared-responsibility model is where most projects go wrong. The point CCN-STIC 823 keeps making is blunt: responsibility for ENS compliance always rests with the public body that owns the information. You can delegate the operation; you cannot delegate the responsibility.
Where the line falls between what the provider takes on and what stays yours depends on the service model:
- In IaaS, the provider is responsible for the data centre, virtualisation, and physical availability; you're responsible for the operating system upward: patching, configuration, identities, data.
- In PaaS, the provider takes on one more layer and manages the platform; you remain responsible for the application, its access, and the information.
- In SaaS, the provider takes on almost the entire technical stack, but you never stop being responsible for identity management, service configuration, and the classification and lifecycle of the information.
There's a constant across all three models: identity, configuration, and data almost always stay on your side. The classic mistake is assuming that "since the provider has ENS, I'm already compliant." Not so: their conformity covers their share of the split. You still have to implement and demonstrate yours.
If you're a public administration: how to procure ENS-compliant cloud
When a public body wants to consume cloud services without stepping outside ENS, the work starts before choosing a provider. The sequence I recommend:
- Categorise the system first. Assess the information and services across the five dimensions and determine the category (BASIC, MEDIUM, or HIGH). That category fixes what you can require from the cloud.
- Carry the category into the tender. Don't ask for "a provider with ENS": ask for conformity at the category that applies, with a scope that covers the specific service you're going to use, not some other unit of the provider.
- Fix the data location. Depending on the category and the type of information, require processing within the EU and, where applicable, within national territory, with jurisdiction clarified by contract.
- Reserve your own responsibilities. Put in writing which measures you implement (identity, encryption with keys under your control, activity logging, continuity) and which ones the provider does.
- Ask for auditable evidence. Conformity reports, accessible logs, and the results of the audit tests that op.nub.1 itself mentions.
If you're going to require ENS from your providers in a tender, it helps to be clear beforehand on who is required to comply with ENS and under what conditions, so you don't ask for too much or too little.
If you're a SaaS or cloud provider: how to sell to the public sector with ENS
From the other side of the table, the question changes: what do I need so that a public body can hire me without falling out of compliance? The short answer is to accredit your service's ENS conformity at the category the tenders require, with a well-defined scope.
What I usually see making the difference:
- Scope of the declaration or certification. The certificate has to cover the service you sell and the platform you deliver it from. A genuine certificate whose scope doesn't include your product won't help you bid.
- The right category. BASIC can be accredited through a declaration of conformity; MEDIUM and HIGH require certification by an accredited body. Aim for the one your public-sector clients will actually ask for.
- Inherited controls. If you build on a hyperscaler with a CCN-STIC profile, you can inherit part of its controls, but you have to document what you add on top.
- A prepared audit. The process includes audit tests; arriving with documentation and evidence in order shortens both timelines and cost. I walk through the process in the ENS certification process and costs.
If you regularly work in public tenders, in ENS for public administration providers I go into how this requirement shows up in tender documents and how it cascades down to subcontractors.
Cloud services in the CPSTIC catalogue and the CCN-STIC 884-887 profiles
This is where many providers get lost, because two different mechanisms coexist.
On one hand, the CCN's CPSTIC catalogue includes a taxonomy of cloud services: it lists products and services qualified for systems affected by ENS at the MEDIUM and HIGH categories. A service's presence in the CPSTIC gives the public buyer a baseline of confidence verified by the CCN itself. Access to the full catalogue requires registering as a CCN user.
On the other hand, there are specific compliance profiles: CCN-STIC guides that detail how to deploy a particular hyperscaler in an ENS-conformant way. The ones worth knowing:
- CCN-STIC 884 — specific compliance profile for Azure (corporate cloud service).
- CCN-STIC 885 — profile for Microsoft 365, with its associated secure configuration guides.
- CCN-STIC 886 — profile for private and community clouds.
- CCN-STIC 887 — specific compliance profile for AWS (corporate cloud service), with its configuration guide.
The point of these profiles is that you don't start from zero: if you deploy on Azure or AWS following its guide, you inherit a baseline of controls that's already been worked out, and you can focus on your own part. That said, a platform profile isn't a certificate for your service: it accredits how to use the cloud in a conformant way, not that your SaaS is conformant. That distinction avoids a lot of misunderstandings in negotiations.
Annex II measures read through a cloud lens: encryption, data, and location
The Annex II security measures don't change in the cloud, but how they're applied — and who's responsible for each one — does. This table summarises the cloud reading of the ones that carry the most weight in a real project.
| Security aspect | Cloud reading | What to require or verify |
|---|---|---|
| Encryption of information | Data encrypted in transit and at rest; encrypting it before uploading concentrates the provider's risk in the availability dimension | Key management under your control whenever possible |
| Data location | Where data is processed and stored, and under what jurisdiction | EU or national region according to category and tender, clarified by contract |
| Segregation and multi-tenancy | Isolation between customers sharing infrastructure | Evidence of separation; at higher levels, don't share resources with lower-level communities |
| Identity and access control | Federation, strong authentication, and identity management | Configuring and governing it remains your responsibility |
| Traceability and logging | Activity logs are generated on the provider's platform | Access to the logs, their retention, and their exportability |
| Continuity and exit | Availability, reversible backups, and service reversibility | Measurable recovery objectives, data return, and certified deletion |
The cross-cutting reading is the usual one in the cloud: the provider supplies the technical capacity; you supply the governance. Encryption, identity, and data rarely stop being your responsibility, even when the provider's platform executes them.
Steps for a SaaS provider starting from scratch
If you have a product and want to sell it to the public sector but have never touched ENS, here's the order that works:
- 1. Define the scope. Exactly which service you're going to accredit and what infrastructure it runs on. Everything else depends on this.
- 2. Categorise. Assess your service across the five dimensions and set the target category based on what your prospective clients require.
- 3. Choose your cloud base. If you're going to build on a hyperscaler, adopt its CCN-STIC profile (884, 885, 887) and inherit whatever you can.
- 4. Risk analysis and statement of applicability. Document which Annex II measures apply and how you cover them, distinguishing what's inherited from what's your own.
- 5. Implement what's missing. Identity, encryption, logging, continuity, and incident management at your service layer.
- 6. Audit and accredit. A declaration of conformity at BASIC, or certification by an accredited body at MEDIUM and HIGH, after passing the conformity audit.
There are no shortcuts, but there is an order that avoids redoing the work: scope, category, inheritance, documentation, implementation, and audit. Skipping the scope at the start is the mistake that costs the most.
Conclusion: the cloud doesn't exempt you from ENS, it redistributes responsibility
Migrating to the cloud doesn't dilute the Spanish National Security Framework; it redistributes who does what. The CCN-STIC 823 guide and measure op.nub.1 set the rules, the CCN-STIC profiles and the CPSTIC catalogue save you some of the road, but responsibility for the information never gets uploaded to someone else's server: it stays with you. A public body that understands this procures better; a provider that understands it sells sooner.
If you're weighing up moving a public-sector system to the cloud, or you have a SaaS and have just been asked for ENS to get into a tender, tell me about your case and we'll look at it together, no strings attached.
Need to accredit your cloud service's conformity to sell to the public sector? Learn about my ENS consultancy service for companies that want to bid for or become suppliers to the public sector.
Frequently asked questions about ENS in the cloud
Does a SaaS need to be ENS-certified to sell to the public sector?
If the service processes information or performs functions for a public entity, an increasing number of tenders require it. The route is to accredit the service's ENS conformity at the category the public client asks for: through a declaration of conformity at the BASIC category, or through certification by an accredited body at MEDIUM and HIGH. The certificate's scope must genuinely cover the service and the platform it's delivered from.
What is the CCN-STIC 823 guide?
It's the guide from the National Cryptologic Centre (CCN) that provides guidance on using cloud services within the scope of ENS. It distinguishes service models (IaaS, PaaS, SaaS) and deployment models (public, private, community, and hybrid), assesses the service across the five ENS security dimensions, and details what the public body consuming cloud services must require by contract, from data location to secure deletion.
What does the ENS op.nub measure require?
Measure op.nub.1, "Protection of cloud services," in Annex II of Royal Decree 311/2022, applies from the BASIC category upward and requires the cloud service to comply with ENS or with the measures in the applicable CCN-STIC guide according to its service model (SaaS, PaaS, IaaS), including audit-testing requirements.
Can I use AWS, Azure, or Google Cloud and still comply with ENS?
Yes, with some caveats. Azure, Microsoft 365, and AWS have specific CCN-STIC compliance profiles (884, 885, and 887) that explain how to deploy them in an ENS-conformant way. That profile covers the provider's part: always check the exact scope and region, and remember that identity, configuration, and data remain your responsibility.
Does my cloud provider's ENS certificate exempt me from certifying myself?
No. It covers the provider's share under the shared-responsibility model. The public body or the SaaS building on top remains responsible for its own measures — identity, encryption, configuration, logging, and operation — and must accredit its own conformity when the tender requires it.
Where must data be located under ENS in the cloud?
It depends on the system's category and the type of information. The trend in tenders is to require processing within the European Union and, in certain cases, within national territory, with jurisdiction clarified by contract. It's worth stating this explicitly rather than assuming it just because you've contracted a European region.