What Spain's ENS Actually Requires From Cloud Platforms Selling to the Public Sector

Key points:

• Spain's ENS (Esquema Nacional de Seguridad) is mandatory. Real Decreto 311/2022 applies to the whole Spanish public sector and, under Article 2.3, to private companies that provide services or solutions to public bodies. Tender documents must require proof: a declaration or certification of conformity.
• Every system gets a category: BÁSICA, MEDIA or ALTA. The category comes from the impact rating across five dimensions (confidentiality, integrity, availability, authenticity, traceability), and the highest single rating wins. Under Article 38, MEDIA and ALTA systems need a certification audit; BÁSICA systems can self-assess.
• Annex II lists 73 security measures: 4 organisational (org), 33 operational (op) and 36 protection measures (mp). For a deployment platform, the ones that bite are access control and segregation of duties, activity logging, change management, external service management, backups, and the dedicated cloud measure op.nub.1.
• ENS has no blanket "data must stay in Spain" rule. It does make you control and assess where processing happens: op.nub.1 explicitly lists data jurisdiction, encryption and key management. Many tenders then add EU or Spanish residency clauses on top.
• The public body stays responsible for its own system's conformity, even on a third-party cloud. Running your platform inside your own AWS, GCP, Azure, Scaleway or existing Kubernetes cluster keeps the logs, keys and region choice in your name. That is the model Qovery uses.

Many SaaS vendors first meet ENS deep inside a Spanish tender's pliego de prescripciones técnicas (technical specifications), a few weeks before the bid deadline. The decree designs it that way. Article 2.3 of RD 311/2022 instructs public bodies to write ENS requirements into their contract documents, including "la presentación de las correspondientes Declaraciones o Certificaciones de Conformidad con el ENS", and to extend that to the contractor's supply chain where the risk analysis calls for it.

If you sell a cloud platform, or software running on one, to a Spanish ministry, regional government, city council or public hospital, ENS is your entry ticket. Below is what the decree actually says and what it changes in your architecture, with every legal claim linked to the BOE text or the CCN's ENS portal.

What is Spain's ENS (Esquema Nacional de Seguridad) and who does it legally bind?

The Esquema Nacional de Seguridad (National Security Framework) is Spain's mandatory security framework for public sector information systems. It is set out in Real Decreto 311/2022, de 3 de mayo (BOE núm. 106, 4 May 2022, in force since 5 May 2022, reference BOE-A-2022-7191), which replaced the original Real Decreto 3/2010. Its legal basis is Article 156.2 of Ley 40/2015.

Article 2 sets the scope:

• Article 2.1: the entire public sector as defined in Article 2 of Ley 40/2015. That covers central, regional and local administrations plus their public bodies.
• Article 2.3: the information systems of private sector entities that, under a contract, "presten servicios o provean soluciones a las entidades del sector público". These suppliers must also adopt a security policy (Article 12), approved by their top executive body.

The Centro Criptológico Nacional (CCN), part of Spain's CNI intelligence service, runs the scheme day to day. It publishes the CCN-STIC guides that turn the decree into implementation and audit practice. The 800 series is the one dedicated to ENS. Do not confuse ENS with its sibling, the ENI (Esquema Nacional de Interoperabilidad), which covers interoperability rather than security.

ENS overlaps with GDPR (personal data), ISO/IEC 27001 (a voluntary management-system standard) and NIS2 (the EU directive on essential and important entities), but replaces none of them. Many controls rhyme. The legal obligation and the evidence format belong to ENS alone.

How does ENS categorise a system as BASIC, MEDIUM or HIGH?

ENS starts with categorisation: before you pick a single control, you rate the impact a security incident would have on five dimensions. These are confidencialidad (confidentiality), integridad (integrity), disponibilidad (availability), autenticidad (authenticity) and trazabilidad (traceability). Each dimension gets a level of BAJO, MEDIO or ALTO (low, medium, high), following the procedure in Annex I.

The rule in Annex I is simple: a system is categoría ALTA if any dimension reaches ALTO, MEDIA if any reaches MEDIO and none is higher, and BÁSICA otherwise. A small informational portal with public content usually lands in BÁSICA. A system holding citizen identity, health or tax data can easily hit MEDIA or ALTA on confidentiality or integrity alone.

Under Article 41, the people responsible for the information and the service rate each dimension, and the security officer sets the category. If you are the vendor, that means you inherit the buyer's category. Ask for it before you scope anything, because it decides which measures apply and what paperwork you will need.

Under Article 38.2, entities must also publish their declarations and certifications on their websites or sedes electrónicas. The CCN issues the matching conformity seals (distintivos) and keeps a public register of certificates.

Which ENS security measures does a cloud platform actually have to implement?

The concrete obligations sit in Annex II of RD 311/2022, which lists 73 measures. I counted them in the BOE text: 4 in the organisational framework (org), 33 in the operational framework (op) and 36 in protection measures (mp). Each measure states which dimension or category triggers it, and whether it simply applies ("aplica") or comes with numbered reinforcements (R1, R2, ...) at higher levels.

• Organisational framework (org.1 to org.4): security policy, security regulations, security procedures, authorisation process.
• Operational framework (op): planning (op.pl), access control (op.acc), operations (op.exp), external resources (op.ext), cloud services (op.nub.1), service continuity (op.cont) and system monitoring (op.mon).
• Protection measures (mp): facilities (mp.if), personnel (mp.per), equipment (mp.eq), communications (mp.com), information media (mp.si), applications (mp.sw), information (mp.info) and services (mp.s).

Article 28 adds two rules auditors care about. Your chosen measures go into a signed Declaración de Aplicabilidad (statement of applicability). And you may replace an Annex II measure with a compensating measure if you document that it protects at least as well.

Here is what the families mean when the system in question is the platform that builds, deploys and runs your applications:

One numbering detail trips people up: guides written for RD 3/2010 refer to backups as mp.info.9. In RD 311/2022 the measure is mp.info.6, and op.nub.1 is new. If a consultant's spreadsheet still uses the old codes, ask for an update before your audit.

How do you prove ENS conformity - certification, declaration, or an auditor?

You prove ENS conformity with a formal document. For BÁSICA systems that is a declaración de conformidad (declaration of conformity) backed by a self-assessment. For MEDIA and ALTA systems it is a certificación de conformidad (certification of conformity), issued after an audit by an accredited certification body. That rule is in Article 38.1, nearly word for word.

Article 31 sets the clock: an ordinary audit at least every two years, and an extraordinary audit whenever substantial modifications could affect the required measures. The extraordinary audit restarts the two-year count, and force majeure can extend the deadline by three months. Annex III specifies what the auditor checks: roles and responsibilities, an annually reviewed risk analysis, the Annex II measures, and a documented security management system built on the Declaración de Aplicabilidad.

Who can certify? The CCN publishes the list of certification bodies: firms accredited by ENAC (Spain's national accreditation body) under ISO/IEC 17065, firms still going through accreditation, and some public audit bodies. The auditors work from the CCN-STIC 800 series and the CCN's published certification criteria.

What about ISO 27001 and SOC 2? They help, because a lot of controls overlap, and Microsoft's own ENS page notes that many ENS controls "align directly with ISO/IEC 27001". But an ISO 27001 certificate or a SOC 2 report is not an ENS certificate, and a Spanish buyer cannot hand either one to their ENS auditor as a substitute.

In practice, a public buyer asks a cloud vendor for one of two things:

1. The vendor's own ENS certificate, at a category equal to or higher than the buyer's system.
2. Evidence the buyer can use to certify its own system running on the vendor's platform: logs, configurations, access records, backup reports.

The second point matters more than most vendors realise. The public body categorises and gets audited on its own system, so whatever runs underneath has to produce evidence the body can actually get its hands on.

Does ENS require Spanish or EU data residency - and what about EU sovereignty rules?

No. ENS contains no blanket legal requirement to keep data physically in Spain. It requires you to know and control where processing happens. The cloud measure op.nub.1.2 says that when you use third-party cloud services, they must be ENS-conformant or meet a CCN-STIC guide covering, among other things, penetration testing, transparency, "cifrado y gestión de claves" and "jurisdicción de los datos". From MEDIA upwards, R1 requires those cloud services to be certified under a methodology recognised by the CCN's certification body.

Residency usually comes from somewhere else. Individual tenders often specify EU or Spanish hosting, and GDPR Chapter V already restricts personal data transfers outside the EU. The EU Data Act has applied since September 2025 and adds switching and international access safeguards for cloud services. The EU cloud certification scheme (EUCS) is still a proposal, so do not cite its "sovereignty" levels as law.

Region choice therefore becomes an architecture decision. Here is what the main providers publish:

Certified infrastructure only gets you part of the way. The questions that decide an audit are practical ones: who holds the cloud account, who holds the encryption keys, and who can produce the logs on audit day.

Where do most cloud platforms fail an ENS review?

In my experience, cloud platforms rarely fail an ENS review on cryptography. They fail on evidence. The usual gaps:

• Logs locked in a shared tenant. The buyer cannot export activity records for their own system, so op.exp.8 evidence does not exist on their side.
• One deploy credential shared by the whole team. For systems where op.acc.3 applies, nobody can show that critical tasks need more than one person.
• Deployments that leave no trail. A push goes live, but nothing links the change request, the commit, the approver and the running version (op.exp.5).
• Backups that are claimed, not shown. The vendor says "we back up everything" but cannot produce per-environment retention or a restore test (mp.info.6, op.cont.*).
• Opaque sub-processors. Nobody knows which clouds and services sit under the vendor, so op.ext.* and op.nub.1 cannot be assessed.
• A vendor-owned cloud account. The public body cannot pull evidence for its own audit without going through the vendor.

How does running on your own cloud account change the ENS conversation?

When the public body or its supplier owns the cloud account, conformity gets much easier to prove. The region, the keys, the audit logs and the infrastructure configuration all sit under the entity's control. This is the "bring your own cloud" (BYOC) model: the platform orchestrates deployments inside your AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, and the account and the cloud bill stay in your name.

Mapped to ENS, that looks like this:

• Location and jurisdiction (op.nub.1): you pick eu-south-2, europe-southwest1 or spaincentral, on a provider whose ENS certificate you can link.
• Traceability (op.exp.8): AWS CloudTrail, Google Cloud Audit Logs or Azure Monitor record activity in your own account, under your retention policy.
• Keys (op.exp.10): encryption keys live in your KMS or Key Vault.
• Backups (mp.info.6): snapshots land in your storage, and you can show them to your auditor.

This is where we built Qovery. It runs in your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster and gives developers self-service deployments without anyone managing Kubernetes by hand. The pieces that matter for ENS: per-environment RBAC, git-driven deployments with a deployment history and audit logs, preview environments isolated from production, managed cluster upgrades for patch hygiene, and databases backed by your cloud's managed services.

To be clear about the limits: Qovery is not an ENS certification, and installing Qovery does not make your system ENS-conformant. You still need the policy, the risk analysis, the Declaración de Aplicabilidad and the audit. What changes is who holds the evidence, and how many operational controls your team has to build and run itself.

Heroku, Vercel and Render are excellent products for a lot of teams, and I would happily recommend them for a startup MVP. The friction with ENS has nothing to do with quality. In a vendor-held multi-tenant account, the public body can only show what the vendor chooses to show.

There is also a staffing reality. ENS operational measures assume someone handles patching, log review, change records and restore tests. Plenty of public-sector IT teams and small govtech vendors do not have a dedicated DevOps engineer for that. A platform layer on your own cloud account is how a small team meets those measures without hiring one.

How do I set this up with Qovery from Claude Code or Cursor?

You can set this up from your coding agent: install the Qovery Agent Skills once and ask in plain language. The Skills handle onboarding, deployment and troubleshooting. The MCP Server operates what already exists.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scope them to the current project only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Add the Qovery MCP Server to Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Enable write access only when you explicitly want it
# (write access must also be enabled in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills include qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. Then ask something like: "Deploy this app into my Azure Spain Central subscription with Qovery."

The read-only default matters in an ENS setting. Your agent cannot change production unless someone deliberately enables write access on both the MCP client and the Qovery Console, which is precisely the kind of control an auditor asks you to explain. Full setup is in the AI agent quickstart and the Claude Code integration page.