How to prepare for your first ENS conformity audit

A first ENS audit is rarely failed on technical deficiencies. It is failed on documents that do not exist, signatures nobody applied, and dates that fall in the wrong order. That is good news: almost everything that goes wrong can be fixed beforehand, and none of it needs an infrastructure budget.

This guide assumes you already know you are in scope, either as a public sector body or as a supplier caught by Article 2(3) of Royal Decree 311/2022. If that is still unclear, start there, because scope conditions everything else.

First: fix the scope, and fix it in writing

Scope is not “the company”. It is a set of information systems supporting specific services. The operational question is: which services do you provide to the public entity, and which systems underpin them?

Draw the boundary with proper nouns: which applications, which infrastructure, which processing centres, which staff, which suppliers are inside. And draw the boundary around what is outside too, with the justification for why the exclusion does not compromise the service.

A small, well-defined scope beats a large, fuzzy one. A certificate with broad but imprecise scope collapses at the first tender that compares it against the subject matter of the contract. Scope can also be widened later; what cannot be explained later is why a system that was inside was never audited.

Second: assess the five dimensions before touching any control

This is the step most people skip and the one that costs most. Annex I requires assessing, for each piece of information and each service in scope, the impact of an incident on availability, authenticity, integrity, confidentiality and traceability, assigning a LOW, MEDIUM or HIGH level.

The system’s category falls out of that assessment: HIGH if any dimension reaches high, MEDIUM if any reaches medium, BASIC if none exceeds low. And the category determines which Annex II measures apply to you and at what intensity.

Doing it backwards — implementing controls and then categorising so it fits — leaves a trail an auditor spots immediately: the valuation record is dated later than the procedures supposedly derived from it.

Two details that always go wrong: the valuation falls to the information or service owner, and determination of the category to the security officer. These are two separate acts by two separate roles, and both must be signed.

Third: appoint the four roles, and check it against the org chart

Article 11 requires distinguishing the information owner, the service owner, the security officer and the system owner. Article 13(3) adds the requirement that causes most trouble in small organisations: the security officer must be a different person from the system owner, with no hierarchical dependency between them.

In practice this rules out the usual shortcut of making the head of IT operations the security officer. If a justified lack of resources means both functions have to sit with the same person, or with people in a reporting line, the regulation allows it as an exception — but it requires compensating measures, and it requires them in writing.

Prepare: signed and dated appointments for the four roles, an org chart demonstrating independence, and, where applicable, the exception document with its compensating measures.

Fourth: the Statement of Applicability, signed

Article 28(2) is explicit: the set of selected measures is formalised in a document called the Declaración de Aplicabilidad, signed by the security officer. The seventy-three Annex II measures are a floor, not a ceiling.

The Statement must record, measure by measure, whether it applies and how, with justification where it does not. If you have replaced any with a compensating measure — Article 28(3) allows this — the detailed mapping between the compensating measure and the one it replaces forms an integral part of the document itself, and the justification that it protects equally or better has to be written down.

Without a signature it is not a Statement of Applicability. It is a spreadsheet.

Fifth: the risk assessment, reviewed and approved this year

Point 1.1(d) of Annex III says the audit will verify that a risk assessment has been carried out “with annual review and approval”. It is a literal periodicity requirement, and it sits in the audit annex rather than in the articles, which explains how often it is missed.

Check two things: that the review date falls within the twelve months before the audit, and that there is explicit evidence of approval, with author and role. An excellent assessment from two years ago is a non-conformity; a mediocre one reviewed three months ago is not.

Sixth: assemble the file for the way it will be walked

Annex III states what the audit rests on: documented procedures, the incident register, examination of affected staff, and certified products. That third item deserves attention because it surprises people: the auditor may question an administrator or an operator directly about the measures that apply to them, and the answer is evidence.

It is worth spending a short session with the operational teams before the audit. Not to rehearse answers, but to make sure they know the procedures that have been written about their work. The gap between the documented procedure and actual practice is the most common finding, and it is found by talking, not by reading.

The order of the dates is the silent criterion

If I had to reduce the preparation to one sentence: check that the dates on your documents tell a coherent story. Dimension valuation → category determination → Statement of Applicability → implementation → operating evidence → audit. Each link dated later than the one before.

When that order holds, the audit proceeds on solid ground even when there are findings. When it does not, even a technically sound environment invites the suspicion that the file was assembled the week before.

After the first time

The regular ordinary audit recurs at least every two years, and must be brought forward as an extraordinary audit if the system undergoes substantial modifications that could affect the required measures. MEDIUM and HIGH category systems need a certification audit; BASIC category systems, a self-assessment. In both cases Article 38(2) requires publishing the conformity mark on the website or electronic office.

What changes from the second time onwards is not the effort of the audit but the effort of keeping the file alive between audits: the Statement of Applicability updated after each change, the risk assessment reviewed each year, the evidence retained with its dates. That is where a tool like Violet Security saves more than it does during the audit itself.