ENS certification for a cloud supplier selling to Spanish public administration

If you sell software or services to Spanish public administration, the Esquema Nacional de Seguridad is a condition of the contract rather than a differentiator. Royal Decree 311/2022 replaced the earlier 2010 framework, and it applies to the public entity and — through the supply chain provisions — to you.

Unlike ISO 27001, which you choose to pursue, ENS arrives as a procurement requirement with a deadline attached.

The three categories, and why the choice matters most

ENS classifies systems as BÁSICA, MEDIA or ALTA. The category is determined by assessing impact across five dimensions — confidentiality, integrity, availability, authenticity and traceability — and the system takes the highest resulting level.

This is the decision that determines the size of the project, and it is made early, often carelessly. A system that handles no personal data and supports an internal administrative process may legitimately be BÁSICA, with a much shorter measure set. The same system classified as MEDIA because nobody wanted to argue carries substantially more requirements, including formal segregation of duties and stricter monitoring.

Do the impact analysis properly, document the reasoning per dimension, and get the client entity to agree the category in writing before you scope the work. The CCN-STIC 803 guide sets out the valuation method; following it gives you a defensible answer rather than an assumed one.

Note that for BÁSICA a self-assessment (autoevaluación) is permitted, while MEDIA and ALTA require certification by an accredited entity. That alone can be the difference between a two-month and a six-month project.

What the 2022 revision changed

Three changes matter operationally:

Cloud services are addressed directly. Annex II now speaks to cloud deployments in a way the 2010 version did not, and the shared responsibility split has to be documented per service. The major hyperscalers hold ENS certification for their regions, so you inherit infrastructure measures — but you must state which measures you inherit, from which certificate, and confirm the certificate covers the specific services and regions you use. An ENS certificate for a provider's Spanish region does not cover the service you run in Ireland.

Profiles of compliance. Simplified profiles exist for certain entity types, reducing the measure set where the risk profile is well understood. Check whether one applies before working through the full annex.

Continuous improvement and periodic review are more explicit, which in practice means the certificate is not a one-off exercise: there are surveillance requirements and a renewal cycle.

Where cloud-native companies actually fail

The measures in Annex II are organised into organisational framework (org), operational framework (op) and protection measures (mp). The technical protection measures are usually the easy part. The recurring failures are elsewhere:

op.pl — planning. A formal risk analysis, a security architecture document and a documented acquisition process. Engineering organisations have the architecture in people's heads and in Terraform; ENS wants it written and approved.

op.acc — access control. The requirement for MEDIA and above around segregation of duties is stricter than most startups operate. "Everyone in the engineering team has production access because we are small" does not survive the audit, and the remediation — break-glass access with approval and logging — takes real work.

op.exp.8 — activity logging, and op.exp.10 — cryptographic key protection. Log retention periods and key management with documented custody. The logging requirement is specific about what must be recorded and for how long.

mp.info.6 — backups, with restoration testing evidenced. Again: the test, not the policy.

op.mon — monitoring, including intrusion detection and a metrics system. A cloud-native company usually has observability for reliability and nothing that would qualify as security monitoring. Something that collects and alerts has to exist.

The Security Policy and the named roles. ENS requires distinct roles — responsible for information, for the service, for security and for the system — and they must be different people where the category demands separation. Assigning all four to the CTO is a finding.

Sequence and timing

Category determination, then a gap analysis against the applicable measures, then remediation, then the Declaración de Aplicabilidad (the ENS equivalent of the SoA), then evidence of operation, then the audit by an accredited certification entity.

For a small cloud-native company at MEDIA with a clean starting point, six months is realistic. The compression comes from inherited infrastructure measures; the time goes into documentation, role separation and building monitoring.

If you have ISO 27001 already

The overlap is substantial and the Spanish certification bodies are used to handling both. Your risk analysis, policies, access control and continuity work transfer with rework rather than restart.

What does not transfer: the category-based measure selection, the specific Spanish documentation expectations, the role structure, and the Declaración de Aplicabilidad in ENS format. Budget a few months on top of an existing ISO certificate, not a fresh project — and get the category agreed before anything else, because it determines everything that follows.