For a supplier to the Spanish public sector, the ENS audit is where its security stops being a claim and becomes something an independent auditor has checked. The Esquema Nacional de Seguridad, governed by Royal Decree 311/2022, is audited against a fixed catalogue of measures and a published methodology, so the process is predictable once you know how it is built. This guide to the ENS audit follows it in the auditor's order: scope, route to conformity, the audit itself, what is reviewed and how findings are resolved. If you are here because a public tender requires ENS, this is the step that comes after the first decisions.
What an ENS audit is under RD 311/2022, and the rules that govern it
Article 31 of Royal Decree 311/2022 requires every information system within the scheme to undergo a regular ordinary audit at least every two years, verifying that it meets the ENS requirements. An extraordinary audit is also required whenever the system undergoes substantial changes that could affect the security measures. Annex III of the decree sets out what that audit covers.
The detail of how an audit is carried out sits in three layers below the decree. The Technical Security Instruction on security audits, published in the BOE in April 2018, fixes the procedure, the scope definition and the content of the audit report. The CCN-STIC guides published by Spain's National Cryptologic Centre supply the criteria: CCN-STIC 802 is the audit guide, CCN-STIC 808 sets out how compliance with each measure is verified, and CCN-STIC 809 covers declarations and certifications of conformity. Certification bodies, in turn, are accredited by ENAC under UNE-EN ISO/IEC 17065 and apply the CCN's general audit and certification criteria.
An ENS auditor is not improvising: the questions, the sampling and the grading of findings are written down, and preparing against those documents is preparing against the actual test.
Scope and category decide what gets audited
Before any measure is reviewed, two things are fixed: the scope and the category. The scope is the specific information system, and the services it supports, that the audit covers. It is rarely the whole company: a supplier running a citizen-request platform for a city council audits that platform and the people and providers who operate it, not its unrelated internal systems.
The category comes from Annex I. Each system is assessed for the impact an incident would have across five security dimensions: confidentiality, integrity, availability, authenticity and traceability. Each dimension is rated, and the highest rating across the five sets the category of the whole system: Basic, Medium or High.
The category then decides which of the 73 measures in Annex II apply and at what depth. Those measures are grouped into three frameworks: organisational (4 measures), operational (32) and protection (37). A higher category does not so much add new measures as add reinforcements to existing ones: stronger authentication, more frequent reviews, more demanding monitoring.
Two scoping errors cause trouble later. The first is a scope drawn so wide that the organisation commits to evidencing measures across systems nobody intended to audit. The second is a scope drawn so narrow that it excludes something the contracted service depends on, most often a cloud platform or an outsourced operator, leaving a gap the auditor will ask about. The categorisation itself also needs to be documented and justified, dimension by dimension, because the auditor will review the reasoning, not only the result.
Declaration or certification: which route applies
ENS offers two ways to demonstrate conformity, and the category determines which one is available.
- Basic category: a self-assessment is enough. It can be carried out by the staff who run the system or by someone they delegate, and it results in a declaration of conformity, renewed at least every two years.
- Medium and High categories: a formal certification audit by an ENAC-accredited certification body is mandatory, and its outcome is a certification of conformity.
A Basic system may also opt for certification, which the audit instruction describes as the desirable option. Our guide to declaration versus certification covers the choice in depth. Most services provided to public bodies fall into Medium or High, so the rest of this guide describes the certification audit.
How the certification audit runs, stage by stage
Planning and documentation review
The certification body confirms the scope, category and applicable measures, agrees an audit plan covering environments and interviewees, and reviews the documents that define the system. The auditor reads the security policy and checks that top management approved it; the categorisation document; the risk analysis, commonly built with the CCN's Magerit methodology and PILAR tool, although the scheme does not mandate a specific tool; the statement of applicability, which lists each Annex II measure, whether it applies and how it is implemented; the security regulations and operating procedures; the formal appointment of the ENS roles; and the contracts with providers who operate part of the system. These documents describe what should happen; everything that follows checks whether it does.
Audit of the system in operation
The second stage, on site, remote or both, examines the measures while they run: interviews, observation of procedures, and technical checks such as configuration reviews, an inspection of access rights or a walk through an incident ticket.
Evidence sampling
The auditor samples evidence that each measure works over time: backup reports from different months, a restore test, access reviews across two cycles, training records for people who joined during the period. A single artefact shows a measure existed on one day; a series shows it operates.
Report and verdict
The audit closes with a report that records the findings and a verdict. Under CCN-STIC 802 and the CCN's general criteria, the verdict can be favourable, when no non-conformities are found; favourable with non-conformities, when major or minor findings exist that can be closed through a corrective action plan; or unfavourable, when the number or weight of findings is such that an extraordinary audit is needed to verify the fixes in person.
What the auditor reviews in each framework
Organisational framework. The auditor checks that the security policy exists, is approved at the right level and has been communicated; that security regulations and procedures cover how the system is actually used; and that there is a working authorisation process for new equipment, software and connections. A typical test: ask for the approval record, then ask a member of staff where the policy lives.
Operational framework. This is the largest block and the one most dependent on evidence. It covers planning (risk analysis, security architecture, acquisition of components), access control (identification, access rights, authentication mechanisms, with stronger requirements at higher categories), operation (inventory, secure configuration, change management, protection against malicious code, incident management and activity logging), external services and cloud services, service continuity, and system monitoring. The auditor wants logs that are reviewed, changes that followed the documented process, incidents with a complete trail and monitoring someone actually watches.
Protection framework. This covers facilities, personnel, equipment, communications, media, applications, information and services. For personnel, the auditor looks at job characterisation, duties and obligations, and the awareness and training measures (mp.per.3 and mp.per.4). For information, they check classification, the handling of personal data and backups, including whether restores have been tested. For communications, perimeter protection and network segregation.
The roles the auditor will interview
Article 11 of RD 311/2022 requires differentiated responsibilities: the information owner, the service owner, the security officer and the system officer. It also requires the responsibility for security to be separated from the responsibility for operating the system. The auditor will check the formal appointments, and then interview the people who hold them.
The interviews test whether the roles are real. A security officer who cannot explain the risk analysis, or a system officer who is also approving their own security measures, produces a finding however complete the paperwork is. Where an organisation relies on an exception to the separation of roles, the auditor will expect the justification and the compensating measures to be documented.
Evidence that passes and evidence that fails
The ENS audit is passed on operation, not on documents, and the difference shows in the evidence. Evidence that holds up is dated, generated by the systems or processes themselves, covers a period rather than a moment, and can be traced to the measure it supports. Evidence that fails usually looks like this:
- Policies written or signed the week before the audit, with no history behind them.
- Undated screenshots of a configuration that nobody can show is still in place.
- Backup reports with no record that a restore has ever been tested.
- Activity logs that exist but that nobody reviews or acts on.
- Access reviews planned in the procedure but never carried out.
- Training sessions with no attendance records and no link to roles.
- An incident procedure with no incidents, near misses or exercises recorded against it.
Findings, corrective actions and the certificate
Findings are graded. A major non-conformity is a breach that compromises the security of the system or the absence of a mandatory measure. A minor non-conformity is an isolated deviation that does not compromise the whole. The auditor may also record observations and improvement opportunities that do not count against the verdict.
Non-conformities are closed through a corrective action plan that sets out the root cause, the action, the owner and the date. The certification body reviews the plan and, depending on the weight of the findings, the evidence that the actions have been completed. Once the verdict allows it, the certificate of conformity is issued. It is valid for two years, and any substantial change to the system can trigger an extraordinary audit before then. In between, the measures have to keep running: reviews carried out, logs monitored, incidents handled and, where they affect covered systems, notified to the CCN-CERT. For companies that also hold ISO 27001, running both frameworks as one programme keeps that evidence in one place.
Seven reasons ENS audits go wrong
- The categorisation is asserted rather than reasoned, dimension by dimension.
- The security officer and the system officer are the same person, with no documented exception.
- The statement of applicability lists measures that are not implemented, or omits required ones.
- A cloud provider or outsourced operator sits outside the scope, but the service depends on it.
- Evidence covers weeks rather than months.
- Incident management exists on paper, with no trail and no process for notifying the CCN-CERT.
- No internal verification was done, so the auditor's review is the first one.
How to prepare: a readiness plan for the months before the audit
Work backwards from the audit date.
- Six months out: confirm the scope and the category in writing, appoint the Article 11 roles with the separation between security and operation, and run a gap analysis against the verification criteria in CCN-STIC 808. Start generating evidence for every measure that applies, because the audit will look for a history.
- Three months out: carry out an internal verification of the measures, as close as possible to how the external auditor will do it. Close the gaps it finds, run a restore test, complete an access review cycle and check that training records exist for everyone in scope.
- One month out: build an evidence index that maps each applicable measure to its supporting records, brief the people who will be interviewed, and name a single contact who coordinates with the certification body during the audit.
Where Qalea fits
The reliable way to pass an ENS audit is to arrive with measures that have been operating, and producing evidence, for months. Qalea runs that work for its clients: it implements the ENS measures in day-to-day operations, provides a security officer function separated from system operation, and operates the monitoring layer (EDR, SIEM and SOC) that produces the logs, alerts and incident trails an auditor samples. Qalea does not issue certificates and is not a certification body. It gets the organisation audit-ready and runs the security function that keeps the certificate valid between audits. More on the scheme itself is on our ENS page, and every related guide is collected on our ENS hub.
