Getting to ENS Alto

What It Actually Took to Certify a Digital Health Platform at Spain’s Highest Security Category

ENS isn’t one certificate with one bar to clear. It’s a categorisation system with three levels, and the level you land in decides almost everything about the effort involved. Here’s how we got a digital health platform certified at Alto, the highest category, and what CCN-CERT reporting actually requires once you’re there.

Spain’s ENS framework isn’t a single certificate; it’s three categories, and which one you land in decides almost everything about the work ahead. Here’s what it actually took to certify a digital health platform at Alto, the highest tier, and the CCN-CERT reporting obligation that comes with it.

ENS, the Esquema Nacional de Seguridad, gets talked about like it’s a single certification with a single set of requirements. It isn’t. The first and most consequential decision in any ENS engagement isn’t a control, it’s a category. Get the category wrong, or underestimate what the highest one actually demands, and the rest of the project is built on the wrong foundation.

Three levels, and they’re not optional to pick

ENS classifies every system into one of three categories, Básico, Medio or Alto, based on the impact a security failure would have across five dimensions: availability, integrity, confidentiality, authenticity and traceability. The category isn’t a choice you make for convenience. It’s determined by the highest impact rating across those five dimensions, and for a platform processing special category health data, that tends to push the answer toward the top of the scale rather than the bottom.

The category isn’t picked, it’s calculated. Whichever of the five dimensions has the highest impact rating decides the category for the whole system.

Básico: the lowest category, appropriate where a security failure would have limited impact. Lighter control set, less audit rigour.

Medio: a meaningful step up, with a broader control baseline and more formal evidence expectations.

Alto: the highest category, reserved for systems where a failure could cause serious or very serious harm. This is where the client landed, given the nature of the health data involved, and it comes with the strictest control set in the framework and a mandatory, more rigorous external audit rather than a lighter-touch review.

Landing at Alto wasn’t a surprise, and it wasn’t the easy option either. It meant every control had to be evidenced to the highest bar the framework sets, not the one that would have been more comfortable to reach.

Why Alto was genuinely hard

The gap between having good general security practice and having Alto-grade, evidenced ENS controls is bigger than it looks from the outside. Several of the underlying gaps that made this work hard were the same ones that had already surfaced in the client’s broader technical security assessments, which meant we weren’t guessing at where the weak points were, but it also meant we knew exactly how much genuine work each one represented.

Cryptography standards: Alto expects state-of-the-art cryptographic controls. Some environments were still running on cryptographic configurations that had previously been flagged as insufficient against equivalent NIS2 expectations, which meant a real uplift rather than a documentation exercise.

Asset inventory: a complete, current inventory of workloads, databases, cryptographic keys and service accounts is a precondition for evidencing Alto-level controls properly. This had previously been flagged as incomplete, and closing it out properly, not just on paper, took real time.

Risk assessment and threat modelling: Alto requires a risk assessment and threat model that actually holds up, not a general-purpose one reused from elsewhere. Earlier assessments had flagged existing risk documentation as insufficient for this level of scrutiny, which meant building a threat model specific to the health data actually in scope.

Data retention alignment: retention and deletion processes that exist but only run manually, or aren’t aligned between cloud and product infrastructure, don’t hold up under Alto-level evidence requirements. This had to be tightened and aligned before it could be presented to the auditor with confidence.

The CCN and INES reporting obligation

Alto-category ENS certification doesn’t end at the audit. Organisations certified at this level have an ongoing obligation to report their security status to CCN-CERT, Spain’s national CERT under the Centro Criptológico Nacional, using INES, the national reporting platform built for exactly this purpose. This isn’t a one-off submission, it’s a standing reporting relationship with a national authority, and it has no real equivalent in the other frameworks the client holds.

Setting this up meant establishing the reporting process itself, not just understanding the requirement: who owns the submission, what triggers an incident report to CCN-CERT versus routine status reporting, and how that sits alongside the client’s existing incident response process so nothing falls through the gap between an internal security event and a formal report to a Spanish national authority.

Where it landed

The client is certified against ENS at the Alto category, the highest level the framework sets, evidenced against the full control baseline that category requires rather than a lighter version of it. The technical gaps that made this hard, cryptography, asset inventory, threat modelling and retention alignment, were closed properly rather than papered over, which means the certification reflects a genuinely stronger security position, not just a passed audit. And the CCN-CERT reporting relationship via INES is now a running process, not a one-time scramble to satisfy an auditor.

If a Spanish public sector deal or a supplier chain into one is on your horizon, the first question worth asking isn’t “can we get ENS,” it’s “which category are we actually going to land in,” because that single answer decides almost everything else about the effort ahead.