ENS
ENS — Spanish Royal Decree 311/2022
What Spain's National Security Framework demands of a public body and of its suppliers: categorisation across five dimensions, a signed Statement of Applicability, and an audit at least every two years.
- Who it applies to
- The whole Spanish public sector as defined in Article 2 of Law 40/2015. In addition — and this is what catches companies out — it applies to the information systems of private-sector entities when, under a contractual relationship, they provide services or supply solutions to public bodies for the exercise of their administrative powers (Article 2(3)). The same caution extends to those contractors' own supply chain to the extent the risk assessment requires.
- Deadline
- In force since 5 May 2022. Pre-existing systems had twenty-four months to reach full compliance; new systems apply it from design. The ordinary audit recurs at least every two years, and must be brought forward as an extraordinary audit whenever the system undergoes substantial modification.
- Official reference
- Real Decreto 311/2022, de 3 de mayo, regulating the Esquema Nacional de Seguridad
Who is in scope without realising it
The ENS is a public sector regulation, but Article 2(3) pulls the private sector in: any company that, under a contract, provides services or supplies solutions to a public entity for the exercise of its administrative powers falls within scope, including the obligation to hold a security policy of its own. The provision extends to those contractors’ supply chain to the extent the risk assessment determines.
In practice it arrives through the tender document. Article 2(3) itself requires public sector administrative and technical specifications to include whatever is needed to ensure ENS conformity of the systems underpinning the contracted service, including the submission of declarations or certifications of conformity. Many companies discover the ENS not by reading the royal decree but by reading the clause that disqualifies them.
The sequence the regulation expects, in that order
The ENS has a logical order worth respecting, because doing it backwards doubles the work. First, assess the five security dimensions of the information and the services; the system’s category falls out of that assessment. With the category fixed, select the applicable Annex II measures, and formalise that selection in a signed Statement of Applicability. Only then does implementation make sense, and only after that, audit.
The usual error is to start implementing controls “because we always do” and build the categorisation afterwards so it fits. An auditor spots it in a minute: the date on the valuation record is later than the dates on the procedures that supposedly derive from it.
Three frameworks, seventy-three measures
Annex II groups measures into the organisational framework (org), the
operational framework (op) and protection measures (mp) — seventy-three in
total, each with reinforcements and with applicability varying by system
category. Not all of them always apply: the Statement of Applicability exists
precisely to put in writing which do, which do not, and why.
How it gets checked
Annex III sets out what the audit rules on: that the policy defines roles, that procedures exist to resolve conflicts between owners, that people have been appointed consistent with the separation-of-duties principle, that a risk assessment exists with annual review and approval, that the Annex II measures are met, and that a documented management system exists with regular management approval, built on the Statement of Applicability.
It also states what the audit rests on: documented procedures, the incident register, examination of affected staff — their actual knowledge and practice of the measures that apply to them — and certified products. That third item is the one that surprises people: the auditor may question an operator, and the answer is evidence.
Obligations
-
Hold a formally approved security policy with the prescribed minimum content
Article 12 requires a security policy approved by the competent body covering, at minimum, the organisation's objectives or mission, the applicable regulatory framework, the security roles with their duties and the procedure for appointing and renewing them, the structure of the security committees, the guidelines for structuring security documentation, and the risks arising from personal data processing. For the private entities covered by Article 2(3), it is approved by the body holding the highest executive authority.
Evidence required
The approved document, dated, with the approving body identified and an index that lets an auditor locate each of the six items in Article 12(1). A policy inherited from another organisation with no formal act of approval of your own is a guaranteed finding.
-
Keep the security officer separate from the system owner
Article 11 requires four distinct roles — information owner, service owner, security officer and system owner — and separation of responsibility for security from responsibility for operations. Article 13(3) goes further: the security officer must be a different person from the system owner, with no hierarchical dependency between them. Only in exceptional, justified cases of resource scarcity may the roles coincide, and compensating measures must then be applied. For outsourced services, the provider designates a security point of contact (Article 13(5)).
Evidence required
Signed, dated appointments for the four roles and an organisation chart demonstrating the absence of hierarchical dependency. Where they do coincide, the document justifying the exception and describing the compensating measures adopted.
-
Categorise the system by assessing all five dimensions
Annex I requires assessing the impact of an incident on availability, authenticity, integrity, confidentiality and traceability, assigning each affected dimension a LOW, MEDIUM or HIGH level. The system is HIGH category if any dimension reaches HIGH, MEDIUM if any reaches MEDIUM without exceeding it, and BASIC if any reaches LOW. The assessment falls to the information or service owner, and determination of the category to the security officer (Article 41).
Evidence required
A valuation record signed by the information and service owners, with the reasoning for each dimension, and the category decision signed by the security officer. These are two separate signatures from two separate roles: presenting them as a single unattributed document is a common mistake.
-
Sign the Statement of Applicability
Article 28(2) states that the set of selected security measures from Annex II is formalised in a document called the Declaración de Aplicabilidad, signed by the security officer. The seventy-three measures in Annex II are a mandatory floor and may be extended. Article 28(3) allows measures to be replaced by compensating ones provided it is documented that they protect equally or better, and requires the detailed mapping between each compensating measure and the measure it replaces to form an integral part of the Statement of Applicability itself.
Evidence required
The Statement of Applicability signed and dated by the security officer, recording the decision on every Annex II measure for the system's category, plus the compensating-measures mapping where any exist. Without a signature it is not a Statement of Applicability: it is a draft.
-
Review and approve the risk assessment every year
Point 1.1(d) of Annex III states that the audit will verify that a risk assessment has been carried out, with annual review and approval. It is a literal periodicity requirement that sits in the audit annex rather than in the articles, which is why it is so often missed. Article 7 sets the risk-based management principle and Article 27 the continuous improvement of the process.
Evidence required
The risk assessment report with a review date within the preceding twelve months and explicit evidence of its approval, with author and role. A methodologically flawless report from three years ago is a non-conformity.
-
Undergo an ordinary audit at least every two years
Article 31(1) requires a regular ordinary audit at least every two years, and an extraordinary one whenever substantial modifications occur that could affect the required security measures; the extraordinary audit resets the two-year count. The deadline may be extended by three months for force majeure not attributable to the entity. The report must rule on the degree of compliance, identifying both conformity and non-conformity findings, and set out the audit methodology, scope, objective and the data, facts and observations underpinning its conclusions (Article 31(4)).
Evidence required
The complete audit report containing those elements, plus the trail showing it was presented to the system owner and the security officer, that the latter analysed it, and that conclusions were escalated so corrective measures could be adopted (Article 31(5)).
-
Obtain and publish the appropriate conformity mark
Article 38(1) draws the line: MEDIUM and HIGH category systems require a certification audit, whereas BASIC category systems need only a self-assessment supporting a declaration of conformity — though they may be certified as well. Article 38(2) additionally requires the declarations and certifications to be published on the relevant websites or electronic offices.
Evidence required
The certificate or declaration of conformity in force, stating the exact scope of systems covered, and the public URL where the conformity mark is published. In a tender, the scope of the certificate is compared against the subject matter of the contract: if they do not match, it does not cover you.
-
Report incidents with significant impact to the CCN
Article 33(2) requires public sector entities to notify the CCN of incidents with a significant impact on the security of the systems concerned, in accordance with the relevant Technical Security Instruction. Article 33(7) routes private-sector organisations providing services to public bodies to INCIBE-CERT, which immediately informs CCN-CERT. After an incident, CCN-CERT determines the technical risk of reconnecting the affected system (Article 33(6)).
Evidence required
The notification record with time stamp and CERT reference number, the written impact-classification criterion applied in that case, and the reconnection authorisation or report where applicable.