Annex II of Royal Decree 311/2022 is where the Esquema Nacional de Seguridad (ENS) turns its principles into controls. It lists every security measure a system can be required to implement, sets out how each measure grows stronger as the system's category rises, and is the text an ENS auditor works through, measure by measure.
For a supplier preparing for its first ENS audit, reading Annex II correctly decides the size of the project. It tells you which measures apply to your system, which reinforcements sit on top of them, which ones can be left out with a justification and what evidence each one has to leave behind. This article walks through the annex in that order.
How Annex II is organised: three frameworks, codes and reinforcements
Annex II groups its measures into three frameworks. The organisational framework (org) covers how security is organised across the whole organisation. The operational framework (op) covers how the system is run as a whole. Protection measures (mp) protect specific assets according to their nature and the security level each dimension requires.
Every measure has a code that tells you where it sits. In op.exp.6, "op" is the framework, "exp" is the family (operations) and "6" is the measure: protection against malicious code. Base requirements inside a measure carry their own subcodes, such as org.1.1 to org.1.5 for the contents of the security policy, and reinforcements are written as R1, R2 and so on. The codes are worth learning early, because the Statement of Applicability, the audit plan and the audit report all refer to measures by code rather than by name.
| Framework | Families | Measures |
|---|---|---|
| Organisational (org) | 1 | 4 |
| Operational (op) | 7 | 33 |
| Protection (mp) | 8 | 36 |
| Total | 16 | 73 |
Organisational framework (org)
The organisational framework has four measures: security policy (org.1), security regulations (org.2), security procedures (org.3) and the authorisation process (org.4). All four apply to every system, whatever its category, which makes them the common starting point of any ENS project.
Annex II is specific about what these documents contain. The security policy must state at least the organisation's objectives, the legal and regulatory framework it operates in, the security roles with their duties and how they are appointed and renewed, the structure of the security committee or committees, and the guidelines for structuring the security documentation (org.1.1 to org.1.5). The security regulations describe the correct use of equipment, services and facilities, what counts as misuse, and staff responsibilities including disciplinary measures (org.2). The procedures describe how routine tasks are carried out, who does each one, how anomalous behaviour is identified and reported, and how information is handled according to its security level (org.3).
The fourth measure, org.4, requires a formal authorisation process covering the use of facilities, putting equipment and applications into production, establishing communication links with other systems, using communication channels and information media, using mobile devices, and using services from third parties under contract. In practice this is the measure that connects the paperwork to daily operations: every new laptop, application or supplier should leave an authorisation behind.
Operational framework (op)
The operational framework has 33 measures in seven families: planning (op.pl), access control (op.acc), operations (op.exp), external resources (op.ext), cloud services (op.nub), service continuity (op.cont) and system monitoring (op.mon). It is the largest part of the annex in ongoing effort, because most of its measures describe activities that never stop.
The planning family sets the foundations. Besides the risk analysis (op.pl.1), it requires a documented security architecture (op.pl.2) covering facilities and access points, the system's equipment, internal networks and external connections, the scheme of lines of defence including firewalls and interconnection points, and the identification and authentication system. At MEDIUM category, op.pl.2 adds a management system for planning, organising and controlling security resources; at HIGH, it adds an information security management system with periodic update and approval, plus internal technical controls such as validation of input, output and intermediate data. Planning also covers the acquisition of new components (op.pl.3), capacity management (op.pl.4) and certified components (op.pl.5).
The remaining families cover how the system runs. Access control (op.acc) governs identification, access requirements, segregation of duties, access rights management and authentication. Operations (op.exp) is the largest family, with ten measures from asset inventory to the protection of cryptographic keys. External resources (op.ext) covers contracts and service levels, daily management of suppliers, supply chain protection and interconnection of systems. Cloud services (op.nub), service continuity (op.cont) and system monitoring (op.mon) complete the framework.
Protection measures (mp)
The protection framework has 36 measures in eight families: facilities and infrastructure (mp.if), personnel management (mp.per), equipment (mp.eq), communications (mp.com), information media (mp.si), software applications (mp.sw), information (mp.info) and services (mp.s). Where the operational framework protects the system as a whole, these measures protect specific kinds of asset.
Many protection measures apply at every category: separated areas with access control, identification of people and conditioning of premises (mp.if.1 to mp.if.3), awareness and training (mp.per.3 and mp.per.4), a secure perimeter (mp.com.1), custody and transport of media (mp.si.3 and mp.si.4), protection of personal data (mp.info.1) and email protection (mp.s.1). Others depend on a single dimension. Workstation locking (mp.eq.2) is driven by authenticity, protection of confidentiality in communications (mp.com.2) by confidentiality, and backups (mp.info.6) by availability.
Reinforcements
A reinforcement adds requirements on top of a measure's base requirements. Annex II states that reinforcements are added to the base but are not always incremental among themselves, so R2 is not necessarily "R1 plus more". Risk analysis (op.pl.1) shows how this works. A BASIC system needs an informal risk analysis written in natural language. A MEDIUM system adds R1, a semiformal analysis with a basic catalogue of threats, defined semantics and tables. A HIGH system adds R2, a formal analysis with an internationally recognised mathematical basis that formally accepts the residual risk.
Where two or more reinforcements appear in brackets, as in [R1 or R2], the organisation chooses one, and Annex II includes a flow diagram for those measures to guide the choice. Authentication of external users (op.acc.5) and separation of information flows in the network (mp.com.4) both work this way. Annex II also flags some reinforcements as optional: they are not required in every system and are applied as additional measures when the risk analysis recommends them.
Which measures apply: category, dimensions and the applicability table
Annex II sets out the selection in five steps: identify the types of asset present, determine the relevant security dimensions, set the security level of each dimension, determine the system's category, and then select the measures and reinforcements that correspond. The first four steps come from Annex I; the fifth is the applicability table at the start of Annex II. Our guide to whether ENS applies to your company and at which level covers the categorisation itself in more depth, so this section focuses on how it drives the selection.
Dimensions and security levels
Annex I defines five security dimensions: confidentiality [C], integrity [I], traceability [T], authenticity [A] and availability [D]. Each dimension affected by an incident is rated LOW, MEDIUM or HIGH according to the harm the incident would cause: limited harm for LOW, serious harm for MEDIUM and very serious harm for HIGH. Annex I gives examples for each level, from an appreciable reduction in the organisation's ability to perform its functions at LOW to the effective loss of that ability at HIGH.
When a system handles several kinds of information and provides several services, its level in each dimension is the highest level set for any of that information or those services. A system that holds mostly public content but also one dataset with MEDIUM confidentiality is MEDIUM in confidentiality.
Category and the applicability table
The system's category is the highest level reached by any dimension: HIGH if any dimension is HIGH, MEDIUM if any is MEDIUM and none is higher, BASIC otherwise. The applicability table then does the selection, and its key column says whether each measure is triggered by the category or by the level of specific dimensions.
- Measures driven by the category follow the overall category. Supply chain protection (op.ext.3) applies only to HIGH systems; change management (op.exp.5) and certified components (op.pl.5) do not apply to BASIC systems.
- Measures driven by dimensions follow one or more dimensions. The four continuity measures (op.cont) depend on availability: the impact analysis applies from MEDIUM, while the continuity plan, periodic tests and alternative means apply only at HIGH. Timestamps (mp.info.4) depend on traceability and apply only at HIGH.
This is why two systems in the same category can end up with different measure sets. A MEDIUM system whose availability is rated LOW does not need the impact analysis that a MEDIUM system with MEDIUM availability does. Rating each dimension carefully, rather than setting all five to the category level, can be the difference between a proportionate project and an oversized one.
Not applicable, segregation and the annual review
Where the table says "n.a.", the measure is not required for compliance at that level, although Annex II notes that implementing it may still be technically useful. Annex II also allows subsystems that need a different level of protection to be segregated from the main system, provided the information and services involved can be clearly delimited. A supplier whose public sector work runs on a delimited platform can use this to keep the higher measures where they are needed.
The categorisation is not permanent. Annex I requires it to be reassessed every year, or whenever the criteria behind it change significantly. Under article 41, the owners of the information and services value the dimensions, and the Security Officer determines the category. Both decisions should be recorded, because the auditor will check that the selection follows from them.
The Statement of Applicability: selection, exclusions and compensating measures
Article 28 of Royal Decree 311/2022 turns the selection into a formal document. It is where the reasoning from the previous steps becomes something an auditor can check line by line.
Minimum measures and the signed statement
Article 28.1 requires the Annex II measures and reinforcements to be adopted taking into account the assets that make up the system, its category and the decisions taken to manage its risks. Article 28.2 makes those measures minimum requirements: the Security Officer may add further measures in light of the state of technology, the nature of the information and services, and the risks the system faces.
The final list is recorded in a document called the Statement of Applicability (Declaración de Aplicabilidad), signed by the Security Officer. A statement that lists measures without connecting them to the categorisation and the risk analysis is hard to defend, because the auditor has no way to see why each measure is there.
Measures that do not apply
A measure leaves the selection for one of two reasons: the applicability table marks it "n.a." for the system's level, or the type of asset it protects is not present in the system. A supplier that develops no software internally, for example, has a different case for the software development measure (mp.sw.1) than one that builds the application it delivers to the public sector.
In both cases, recording the reason next to the measure makes the selection something an auditor can follow rather than take on trust. An exclusion without a recorded reason invites the question of whether the measure was assessed at all.
Compensating measures
Article 28.3 allows an Annex II measure to be replaced by a compensating measure, on three conditions. It must be documented that the alternative protects the assets against the risk as well as or better than the original. The basic principles and minimum requirements must still be met. And the Statement of Applicability must show, in detail, which Annex II measure each compensating measure replaces. The whole set requires formal approval by the Security Officer, and the decree provides for a CCN-STIC guide on selecting and recording compensating measures.
Compensating measures are a tool for genuine constraints, not a way around a measure. A compensating measure that is weaker than the original, or documented only in general terms, will not survive the audit.
Companies that already hold ISO 27001 will recognise the structure: it mirrors the ISO 27001 Statement of Applicability, which is one reason the two frameworks can be run as a single programme.
What evidence each framework produces
The three frameworks generate different kinds of evidence, and the difference matters when preparing for an audit. Documents can be written at any point; records of an activity only exist if the activity has actually been running.
Organisational measures: approved documents
The org measures produce documents: the security policy, the security regulations and the procedures, plus the record of authorisations. For a private company providing services to the public sector, article 2.3 states that the security policy is approved by the body holding the highest executive powers. A policy drafted but never formally approved does not meet the measure.
The evidence for these measures is the approved version, its distribution to staff and the trail of authorisations under org.4. Article 13.2 adds that the security policy must be known by everyone in the organisation, so the auditor may ask how staff were informed.
Operational measures: records built up over time
Many op measures describe an activity that has to keep running, so the evidence is what that activity produced over the audit period rather than a single document. These include the asset inventory (op.exp.1), maintenance and security updates (op.exp.4), protection against malicious code (op.exp.6), incident management and its register (op.exp.7 and op.exp.9), activity logging (op.exp.8, triggered by traceability) and the three system monitoring measures: intrusion detection, the metrics system and surveillance (op.mon.1 to op.mon.3).
These measures cannot be completed at the last minute, because records cannot be created retroactively. For how detection tools map onto op.exp.6 and op.mon, see our comparison of EDR, XDR and MDR.
Protection measures: the state of assets, plus records
The mp measures combine the physical and technical state of assets with records. Awareness (mp.per.3) and training (mp.per.4) apply to every category, so every system needs evidence that they actually took place. Backups (mp.info.6) are driven by availability: the higher the availability level, the more reinforcements apply.
All of this comes together at audit time. Article 31 requires a regular audit at least every two years, and the audit report must give an opinion on the degree of compliance, identifying findings of compliance and noncompliance. Article 38 requires MEDIUM and HIGH systems to obtain a certification audit, while BASIC systems only need an internal assessment to declare conformity. Our article on how the ENS audit works covers what the auditor reviews, and keeping operational records current between audits is covered in maintaining ENS certification. All our ENS articles are collected in the ENS hub.
Where Annex II meets the organisation chart
Annex II assumes roles that a growing company often does not have yet. Article 13.3 requires the Security Officer to be a different person from the System Officer, with no hierarchical dependency between them. Where a justified lack of resources makes that impossible, compensating measures are required to preserve the separation of responsibilities. For outsourced services, article 13.5 asks the provider to designate a security point of contact, unless there is a justified and documented reason not to.
For a supplier with a small IT team, this is the part of Annex II that documents alone cannot solve: operating the measures that produce records every week and keeping security responsibility separate from running the systems. For a company that already has a security team, the challenge is usually different: mapping Annex II onto controls it already runs for ISO 27001 without duplicating the work.
Qalea is a compliance platform that comes with guided support from our security team. The platform maps the Annex II measures to your controls and keeps the evidence for each one, reusing what already exists for frameworks such as ISO 27001. Our team works with your owners to categorise the system and build the Statement of Applicability, and the monitoring layer (EDR, SIEM and a SOC) produces the records that measures such as op.exp.6, op.exp.7 and op.mon need, so that the evidence exists when the auditor asks for it.
