Technical controls: the ENS × ISO 42001 × EU AI Act cross-mapping over the on-premise LLM architecture

Third post in the blog’s AI governance trilogy. The first, ISO/IEC 42001, broke down the certifiable management system. The second, EU AI Act, broke down the directly applicable legal regulation. This one covers the third framework that appears when the client is a Spanish public administration or an essential-services entity: the ENS (Esquema Nacional de Seguridad, Spain’s national security framework, Royal Decree 311/2022). The editorial challenge: triple compliance is not the arithmetic sum of three jobs; it is one single set of technical evidence labelled for three lenses. This post takes apart how that evidence is built, measure by ENS measure.

TL;DR

Royal Decree 311/2022 updated the Spanish Esquema Nacional de Seguridad (ENS), aligning it with NIS2 and with the modern cyber-threat landscape. It applies mandatorily to the entire Spanish public sector (central, regional and local administration, universities, autonomous bodies) and to suppliers that provide IT services to them. The framework defines 74 security measures organised into three blocks (organisational framework org, operational framework op, protection measures mp), three application categories (Basic / Medium / High) according to the assessment of five dimensions (Confidentiality, Integrity, Traceability, Authenticity, Availability), and an Annex II with the measure × category matrix that dictates what is required at each level. This post maps the technical measures relevant to LLM systems (those of the op block: planning, access control, operation, external services, continuity, monitoring; and those of the mp block: communications, applications, information, services) against Annex A of ISO/IEC 42001 and the operational articles of the EU AI Act (Arts. 9 to 15, 17, 72 and 73), and shows that the overlap is massive: a single technical artefact from the blog’s OSS stack, the OTel spans of tracing, the datasets versioned with DVC, the LLM Guard scanners, the guardrail decisions, the incidents of the retrain loop, simultaneously satisfies ENS measures, 42001 controls and AI Act articles, provided it is labelled with the correct codes from the moment it is captured. The editorial thesis: the difference between a system that passes all three audits and one that suffers three separate certifications is not budget, it is disciplined labelling and a common vocabulary. The post builds the master table of triple compliance, walks through the case of the multi-tenant chatbot for a High-category public administration as a live checklist, and closes with the five traps of triple compliance.

The analogy: the triple inspection of a critical building

A critical building, say the control centre of a regional electricity grid, a reference hospital, or a 112 emergency response centre, goes through three different inspections of the same physical elements:

• The regional inspection reviews the planning permit, local fire regulations and accessibility under regional legislation.
• The European inspection reviews CE marking of equipment and conformity with EU directives on energy efficiency.
• The ISO quality inspection reviews processes and maintenance under a management standard.

All three inspectors look at the same fire detector hanging from the ceiling. The regional one wants to see the installation certificate with the installer company’s number; the European one wants to see the CE mark stamped on the casing; the ISO one wants to see the monthly maintenance record with signatures. There is only one detector. The evidence each inspector needs is different. If the building management team kept one folder per inspector, the installation certificate, the photo of the CE mark and the maintenance sheet would live in three places, and on audit day inconsistencies between the three folders would surface. The professional way to operate: one single file per asset, with tags pointing at the three sets of legislation.

The on-premise LLM system is that critical building. The OTel spans from tracing are the fire detector: a single technical piece that satisfies ENS measure op.exp.8 (activity logging), 42001 control A.8.2 (information to interested parties), and EU AI Act article 12 (record-keeping) provided the spans carry the correct metadata: traceparent propagated, gen_ai.* semantic conventions, WORM retention, PII redacted by LLM Guard Vault. Without consistent labelling from capture onwards, audit day produces three folders that do not add up.

The analogy matters because it bounds an architectural decision: labelling evidence is not a compliance topic, it is a technical design topic. It is decided when the OTel Collector is set up, when the Vault schema is designed, when the format of retrain incidents is agreed. Postpone it, and the debt compounds.

ENS in 15 seconds

• Regulatory framework: Royal Decree 311/2022, of 3 May, in force since 5 May 2022. It replaces RD 3/2010. It implements the update of the Esquema with NIS2, the NCS (Estrategia Nacional de Ciberseguridad, Spain’s national cybersecurity strategy) and the post-2020 reality.
• Mandatory scope: the Spanish public sector (central, regional and local administration, universities, autonomous bodies), public-sector entities with their own legal personality, and private suppliers that provide IT services to them (a very important clause in consultancy: if your client is the Junta de Andalucía, the Comunidad de Madrid or Bilbao City Council, you fall under ENS by contractual extension).
• Operational applicability in 2026: any AI project financed with NextGenerationEU European funds, plus any project with public data, plus any integration with electronic administrative systems.
• Categorisation: three categories, Basic / Medium / High, according to the assessment of the five dimensions (C, I, T, A, D). The category dictates which measures are required and at what depth.
• Certification: for Medium and High categories, a formal audit by an accredited body. For Basic category, self-assessment. Certification cycle is biennial.
• Authority: the Centro Criptológico Nacional (CCN-CERT, Spain’s national cryptologic centre), part of the CNI intelligence agency. It maintains the ens.ccn.cni.es portal with the STIC guides (800 series).
• Total number of measures: 74, organised into three blocks, plus Annex II with the measure × category matrix that defines what applies at each level.

The five security dimensions and their AI mapping

To classify the system as Basic / Medium / High, the ENS requires each dimension to be rated on a scale (not applicable / low / medium / high). The final category is the highest of the five. For LLM systems, the typical rating:

Typical result: Medium category for internal LLM systems with no sensitive data, High if they handle PII or regulated sectoral data (health, tax, judicial). The category triggers different controls.

The three blocks of measures

Organisational framework (org), 4 measures that always apply, transversal:

• org.1 Security policy
• org.2 Security regulations
• org.3 Security procedures
• org.4 Authorisation process

Operational framework (op), 31 measures in 6 subgroups, these are how it is operated:

• op.pl Planning (5)
• op.acc Access control (6)
• op.exp Operation (10)
• op.ext External services (4)
• op.cont Service continuity (4)
• op.mon System monitoring (2)

Protection measures (mp), 39 measures in 7 subgroups, these are what is protected:

• mp.if Facility protection (7)
• mp.per Personnel management (4)
• mp.eq Equipment protection (4)
• mp.com Communications protection (4)
• mp.si Information media protection (5)
• mp.sw Application protection (2)
• mp.info Information protection (6)
• mp.s Service protection (4)

Of those 74, roughly 25 matter operationally for LLM systems. The rest are either transversal (policies, personnel management, physical facilities) or specific to other layers (telephony, physical media in the literal sense). The rest of this post drops down to the 25 relevant ones.

Technical mapping: key ENS measures × 42001 controls × EU AI Act articles

What follows, by ENS subgroup, are the measures relevant to LLM with their cross-mapping. The Technical evidence from the blog column points to the operational artefact that materialises the measure.

Operational framework — planning (op.pl)

Operational framework — access control (op.acc)

Operational framework — operation (op.exp)

This is the densest subgroup and the one that overlaps most with the LLM architecture.

Operational framework — external services (op.ext)

Critical when the system integrates GPAI (Llama, Mistral) hosted elsewhere, or when the deployer is a third party.

Operational framework — continuity (op.cont)

Operational framework — monitoring (op.mon)

Protection measures — communications (mp.com)

Protection measures — applications (mp.sw)

Protection measures — information (mp.info)

Protection measures — services (mp.s)

Master table of triple compliance — the 25 relevant controls consolidated

The key reading of the table: one row per technical capability. The organisation does not build three solutions for “activity log” (ENS) + “information to interested parties” (42001) + “record-keeping” (AI Act). It builds one single piece of OTel tracing with the correct metadata and presents it labelled for whichever inspector is asking.

The labelling typically materialises in three mechanisms:

1. Tags in the CI/CD pipelines: every artefact produced carries tags ens:op.exp.8, iso42001:A.8.2, aia:art.12 in its Helm / Argo CD metadata.
2. Semantic OTel attributes: gen_ai.compliance.ens = "op.exp.8", gen_ai.compliance.iso42001 = "A.8.2" as custom attributes on the relevant spans (not standard yet, but useful internally).
3. A mapping table in the wiki: a living document of ENS measure → 42001 control → AI Act article → technical runbook + owner + last verification. This is the artefact the auditor consults.

Applied case: multi-tenant chatbot for public administration

A variant of the multi-tenant chatbot from the forensic post, where the client is now a Spanish regional government offering citizen assistance on administrative procedures. The three lenses:

• ENS: applies mandatorily, being public sector plus a service to citizens. Category High (citizens’ PII plus a critical service).
• ISO 42001: the regional government requires certification from the supplier as a contractual condition.
• EU AI Act: if the chatbot informs about procedures but decides nothing on the citizen’s behalf, it is limited risk (Art. 50 transparency). If it automates decisions (admission to a programme, refusal of a benefit), it is high risk.

We assume high risk for the most demanding walkthrough.

The chatbot’s 25 key technical capabilities consolidated

Result: the 25 technical capabilities are common to all three frameworks. Only two require evidence for a single framework in isolation: mp.info.4-5 (qualified signature and timestamp, ENS-specific, not required so literally by 42001 or the AI Act) and Art. 50 (transparency banner, AI Act-specific). The rest are the same technical piece with three labels. A well-organised team certifies all three in series with only marginal extra work between the second and the third.

The five traps of triple compliance

Trap 1 — Measuring the same thing three times. Inexperienced teams create three separate dashboards (one for ENS, another for 42001, another for the AI Act) with the same metrics duplicated. The result: three sources of truth that diverge, three audit teams with different figures, three corrections to resolve one and the same deviation. The rule: one metric, three labels.

Trap 2 — Losing the control that covers only one framework. mp.info.4 (electronic signature) is ENS-specific and gets forgotten while the team is focused on 42001 + AI Act. On ENS audit day, the gap surfaces. Solution: the master table keeps every control visible, orphans included.

Trap 3 — Bias towards the most recent framework. The team spends 80% of the effort on the AI Act because it is the newest, and forgets the rigour of the ENS, which has been in force for 14 years. The ENS measures are technically more prescriptive than the AI Act (which is legally stricter but leaves implementation freedom). Moving up a level to ENS High category introduces specific requirements (HSM, qualified timestamps, 24×7 surveillance) that the AI Act does not spell out. The ENS deserves respect for its technical detail, not for its legal stature.

Trap 4 — Mixing ENS Medium and High categories. The Annex II matrix of RD 311/2022 dictates which measures are required and at what depth per category. Moving from Medium to High changes 15-20 controls, which is not marginal. The category is decided at the start of the project and documented; changing it halfway forces a complete re-audit.

Trap 5 — Audit fatigue inside the technical team. Three audits a year (biennial ENS + annual 42001 surveillance + ad-hoc AI Act by the authority) exhausts the team if they are not planned and if evidence is not reused. The professional approach: one single quarterly internal audit cycle with rotating scope, producing evidence consumable by all three external auditors. The difference between 30 days a year and 90 days a year lost to audits is the discipline of single evidence plus disciplined labelling.

What we have not covered (upcoming posts)

• The CCN-CERT STIC series applicable to AI systems: STIC 800-159 (web service operation), STIC 800-105 (cryptography), STIC 800-150 (cloud environments). Each adds technical detail on how to materialise the ENS measures.
• The GDPR as a fourth lens: privacy and personal data protection. It overlaps with mp.info.1 and with A.7.6 of 42001 plus Art. 10 of the AI Act. Material for an analogous pass over LOPDGDD + GDPR + AEPD against the three frameworks seen here.
• Concrete templates of technical evidence with minimum fields: a log entry with every attribute required by the three lenses, an incident report with every field demanded by the three frameworks, a unified ENS / AI Act / 42001 declaration of conformity.
• The NextGenerationEU funds case: specific compliance requirements for AI projects financed with European funds, where the AI Act + ENS are contractually mandatory.
• 42001 + ENS High category combined with DORA (Digital Operational Resilience Act, Reg. 2022/2554) for Spanish financial entities deploying AI.

References

• RD 311/2022 — por el que se regula el Esquema Nacional de Seguridad. https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191.
• CCN-CERT — Portal ENS: https://ens.ccn.cni.es/. Guías STIC Series 800.
• CCN-STIC 803 — Valoración de los sistemas y de la información. Metodología para asignar categoría ENS.
• CCN-STIC 804 — Esquema Nacional de Seguridad. Guía de implantación.
• CCN-STIC 824 — Informe del estado de seguridad. Plantilla para auditoría ENS.
• MAGERIT v3 — Metodología de Análisis y Gestión de Riesgos del Ministerio de Asuntos Económicos. Insumo de op.pl.1.
• ISO/IEC 42001:2023 — Sistema de gestión IA. Norma certificable que solapa con ENS.
• Regulation (EU) 2024/1689 (EU AI Act) — texto consolidado.
• NIS2 (Dir. 2022/2555) — directiva de ciberseguridad que el ENS implementa parcialmente en su versión 2022.

See also

• Hardening and secrets in the sovereign LLM stack: defence in depth — the technical implementation of many of these controls: network, secrets, supply chain.

• ISO/IEC 42001: the operations manual for the AI system — the first post of the governance trilogy, the certifiable management system.

• EU AI Act: the technical dossier, article by article — the second post, the directly applicable EU legal regulation.

• The six-stage LLMOps pipeline — the reference operational architecture that supports all three frameworks.

• LLM tracing with OpenTelemetry GenAI — the canonical piece that materialises op.exp.8 + .10 ENS + A.8.2 ISO 42001 + Arts. 12 + 19 AI Act simultaneously.

• Guardrails and safety in LLMs — the piece that materialises op.mon.1 + mp.s.4 ENS + A.9.2 ISO 42001 + Art. 15 AI Act.

• LLM Guard: the sworn translator with a book of equivalences — the piece that materialises mp.info.1 + .6 ENS + A.7.6 ISO 42001 + Art. 10 AI Act.

• Data versioning with DVC and lakeFS and RAG corpus curation — the pieces that materialise mp.info.1-2 ENS + A.7 ISO 42001 + Art. 10 AI Act.

• Retrain: closing the feedback → dataset → adapter loop — the piece that materialises op.exp.7 + .9 ENS + clause 10 ISO 42001 + Art. 73 AI Act.

• Evals: the layer after tracing — the piece that materialises mp.sw.2 ENS + A.6.2.5 ISO 42001 + Art. 15 AI Act.

• Seven layers of the stack and seven deployment phases — the direct material for op.pl.2 architecture.

• The parallel catalogue: OSS vs hyperscalers — input for op.ext.1 + .3 supplier analysis + Art. 53 GPAI.

• The OSS catalogue for LLMOps — inventory of components with licences for op.exp.1.

• Anatomy of an LLM request in production — the forensic case walked through with the triple lens in this post.

• Incident response runbooks for LLMs with Keep + Kafka — the concrete piece that materialises op.exp.7-10 ENS + A.8.2 ISO 42001 + Art. 73 EU AI Act simultaneously: declarative Keep workflows + WORM Kafka audit.actions + NIS2 deadlines of 24h/72h/1 month.

• Isolating AI agents: from the workstation to the cluster and its operational runbook — runtime isolation (bubblewrap on the client, Tetragon in the cluster) as a materialisation of op.mon (monitoring) and op.exp (activity logging): Tetragon’s eBPF events are technical evidence of what each agent executed and of every blocked access attempt.

• Model chain of trust (3/4): signing, provenance and AIBOM — the technical evidence of model provenance (signature, attestations and AIBOM) that feeds the technical documentation of Art. 11 + Annex IV of the AI Act and the traceability controls of ISO 42001.

• Model chain of trust (4/4): workload identity and isolation — SPIFFE/SPIRE and confidential computing as a materialisation of op.acc and mp.com in the ENS and of Art. 15 on robustness and cybersecurity.

• Virtual keys, budgets and limits in LiteLLM — the concrete implementation of access control and administrative traceability at the gateway, with what it demonstrates to an auditor and what it does not.