ENS certification guide for the public sector and vendors

1. What the ENS is and what getting certified means
2. Basic, medium and high categories
3. Quick comparison table
4. ENS adaptation process
5. From policy to evidence: preparation
6. Realistic timeline to audit
7. Documentation auditors usually ask for
8. Audit and certification process
9. ENS compared with ISO 27001 and NIS2
10. Mistakes that stretch certification
11. How Privalex supports this journey
12. Frequently asked questions

ENS certification guide is what teams need when a tender or contract asks for the Spanish National Security Scheme (ENS). It is not a decorative badge: it is the usual way to show that an information system meets security, governance and evidence rules for the public administration.

Key takeaways:

• The ENS is a Spanish framework (law plus CCN guides); day-to-day reading is often Royal Decree 311/2022.
• Certificate (medium/high) and declaration (basic) are different paths: do not mix calendar or budget.
• Sensible sequence: scope and category → policy and operation with evidence → audit or declaration.
• Align with what you already run: NIS2 and ISO 27001, without parallel duplicate programmes.

What the ENS is and what “getting certified” means

Scope and governance

The ENS applies to information systems of Spanish public administrations and, frequently, to vendors that support them or process data. It blends principles, organisational and technical measures and expects real governance: roles, risk, change, incidents.

The CCN explains how to read measures, how to document evidence and how trust chains work between agency and supplier.

What “getting certified” usually means

In the strict sense it typically means:

1. A bounded information system.
2. Assessment by an accredited certification body (ENAC criteria plus the scheme).
3. A certificate of conformity with the ENS.

Accreditation separates a formal assessment from an informal internal note. Cross-check market and requirements with ENAC-accredited bodies and CCN documentation.

Instrument by category

• Basic: self-assessment and declaration; usually no certificate of that kind.
• Medium / high: audit and certificate as the reference; more policy, technical evidence and traceability.

Tenders and contracts: three useful reads

1. Does the buyer ask for explicit certification or only equivalent measures?
2. Are there GDPR clauses (processing agreements, transfers) to solve besides technical controls?
3. Is it mixed with international standards? Adjust scope; do not treat “ENS” as a synonym for ISO.

Basic, medium and high categories

How category is determined

It is not a voluntary “maturity level”. Dimensions include:

• Confidentiality
• Integrity
• Availability
• Authenticity
• Traceability

The highest level among them drives the system category.

What each level implies

Basic

• Smaller measure set in the profile.
• Still serious effort.
• Formal path: declaration after self-assessment; no mandatory external audit like medium/high.

Medium and high

• More depth: SoA, more demanding risk analysis, evidence testable in interview and sampling.
• High: higher time and skill cost; often tied to severe impact if the service fails or data is compromised.

Common classification mistakes

• Treating category as risk marketing instead of honest analysis.
• Playing down confidentiality because data “does not look sensitive” even though the system supports meaningful administrative decisions.
• Changing category mid-project (usually means redoing analysis and controls).

Internal scope plus vendor

For hybrid teams, category should reflect the end-to-end system as the administration uses it:

• Interfaces between applications
• Authentication flows
• Integrations and APIs

Scope drawn too narrow (vendor hosting only) is a typical source of audit gaps.

Express scope checklist

• Logical diagram with named boxes (not only “the platform”).
• List of URLs, APIs or integrations that consume administration data.
• Identification of privileged accounts and who custodies them.
• Written agreement on which environments (DEV / STG / PRD) are in scope during the audit.

Quick comparison table

Category	Instrument	External audit	Typical renewal
Basic	Self-assessment and declaration of conformity	Not mandatory	At least every 2 years
Medium	Certificate of conformity	Formal audit (accredited CB or OAT)	At least every 2 years
High	Certificate of conformity	More demanding formal audit	At least every 2 years

ENS adaptation process (CCN reference)

The CCN adaptation process requires an Adaptation Plan that integrates four prior phases:

1. Organisational security policy.
2. System categorisation (Annex I of RD 311/2022).
3. Risk analysis on the real system.
4. Statement of Applicability or compliance profile.

Conformity is demonstrated differently by category:

• Medium or high: formal audit, at least every two years (or extraordinary if significant changes occur).
• Basic: self-assessment on the same cycle; a basic system may still undergo formal audit if the tender requires it.

Typical operational sequence before opening the audit window:

1. Identify scope (services and systems included).
2. Categorise and obtain a provisional statement of applicability.
3. Complete risk analysis and validate the definitive statement.
4. Implement measures and mature evidence.
5. Select an accredited certification body and run audit or self-assessment.

From policy to evidence: preparation

Why programmes slip

Typical causes:

• Documentation that does not match production.
• Fuzzy ownership (no change approver, no risk owner).
• No recent evidence (logs, tickets, minutes).

Pre-audit checklist

Scope and design

• Delimit what is in and out, in writing.
• Up-to-date asset inventory and dependencies.

Risk and policy

• Risk analysis with assets, threats, vulnerabilities and treatments for the real system.
• Approved security policy; operational roles and approval flows.

Operations

• Access, backups, logging, patching and vulnerability management demonstrable with dates.
• Reasonable separation between development, staging and production.

Suppliers and continuity

• Processing agreements, SLAs and reviews aligned to risk.
• Continuity and recovery plans tested at least partially.

Physical and logical alignment

• Room access, media destruction and equipment disposal aligned with logical access narrative.

For parallels with other cyber audits, see how to prepare for a NIS2 audit (evidence and governance ideas that apply to the ENS with local nuances).

Minimum questions the file should answer

1. Which components are in perimeter and which are explicitly out?
2. Who owns the information system and who approves production changes?
3. What data does the system process and with what criticality for the administration?
4. How are identities, privileges and periodic access reviews managed?
5. Where are backups, how often are they tested and who signs the outcome?
6. How are security incidents detected, logged and escalated?
7. Which suppliers are critical and when was contractual compliance last reviewed?
8. What records prove controls run (not only that a PDF exists)?

Recommended project roles

• Sponsor who can decide scope and budget.
• Security lead for the system or operational equivalent.
• Information or business owner who validates criticality and scope.
• IT / platform with real access to logs, backups and changes.
• Legal / privacy if processing agreements and tender clauses overlap.

Realistic timeline to audit

Typical phases (in order)

1. Scope and category (often one to two months): business, IT and legal alignment; first category hypothesis.
2. Risk and control design (three to five months): SoA if needed, treatment plan, prioritise critical gaps.
3. Implementation and operation (several months, often parallel): rollout, monitoring, formal change management.
4. Evidence maturation before opening the audit window: records over a credible period; margin for nonconformities and corrective actions.

Many programmes land between nine and eighteen months, depending on size, technical debt and key people availability.

If you already have ISO 27001 or similar

• You can shorten policy and change-management work.
• It does not remove tuning to ENS wording and CCN guides.
• Keep one risk thread and one committee where possible.

Red flags on the calendar

• No closed asset inventory while an audit date is already discussed.
• Production changes still arrive by email with no ticket or traceability.
• Nobody can show logs for the last months for a control the policy calls mandatory.
• Scope is renegotiated every two weeks because a neighbouring system “was missing”.

Documentation auditors usually ask for

Organisation and governance

• Approved and communicated security policy.
• Roles and responsibilities for the information system.
• Risk analysis with a recognisable methodology and dated reviews.

Controls and operations

• Statement of Applicability where required, with well-argued exclusions.
• Change, vulnerability and backup procedures.
• Joiner, leaver and access-review records.
• Training or awareness evidence for critical roles.

Continuity, incidents and third parties

• Continuity and response plans with contacts and escalation.
• Minutes or reports from exercises, even initial ones.
• Contracts and reviews for critical suppliers and cloud subprocessors.

Practical rule

Quality beats volume: hundreds of pages without links to tickets and logs worsen auditor perception.

Versioning and dates they often check

• Version and date of the security policy and critical procedures.
• Date of the last risk analysis and review records after major changes.
• History of committee or security forum minutes (even quarterly).
• Ticket IDs linked to relevant changes in the certified perimeter.

Audit and certification process

CCN reference

The CCN publishes general audit and certification criteria; use official ENS documentation and check for later updates.

Examples of document-review evidence

Not exhaustive, but samples often requested include:

• Configuration exports or screenshots without secrets in clear text, scoped to the control under test.
• Log extracts with retention aligned to the declared policy.
• Dated access-review minutes with scope and owner.
• Backup restore or continuity exercise results.
• Change tickets linked to production deployment windows.

Typical sequence (simplified)

1. Planning: dates, scope, audit team and access rules.
2. Document review: filters obvious gaps (policy, stale risk).
3. On-site or remote audit: tests technical evidence and interviews against reality.
4. Nonconformities and action plan: owners, dates and closure proof.
5. Certification decision and issuance with limited validity.

Choosing a certification body

• Reference list: ENS certification portal (bodies).
• Ask for a proposal with phases, expected evidence samples and environment-access assumptions.
• Check accreditation, sector and references before signing.

During the audit

• Treat findings as business priorities.
• Tension rises when documentation was only “for the photo”.
• Name one lead contact who can commit correction dates and environment access.

After the certificate

• Keep the rhythm of reviews and evidence; surveillance is not theoretical.
• Log architecture changes and reassess category if the risk profile shifts.
• Plan renewal early (collecting period evidence often takes weeks).

The certificate assumes ongoing maintenance; major architecture or scope changes often trigger reassessment earlier than expected.

ENS compared with ISO 27001 and NIS2

What each framework adds

• ISO 27001: management system (Plan, Do, Check, Act); risk, SoA, management review.
• ENS: measures and category in the Spanish public sector context and CCN guides.
• NIS2: governance, risk and incidents at EU scale for essential and important entities.

How to integrate without duplicating

1. One control map where scope overlaps.
2. One finding feeds ISO, ENS and NIS2 reporting where it applies.
3. Tune SoA wording and exclusions to ENS language; the auditor does not assess the ISO logo alone.

Mixed customer portfolios

• One committee, one risk register and shared reviews.
• Distinct scopes per contract: the public segment may be only part of the platform.

International vendors and cloud

• Internal analysis may be in English, but evidence must still meet CCN and certification-body expectations.
• Document subprocessor chains, location, keys, backups and segregation.
• Decide early whether ENS covers a dedicated slice or a broad footprint (higher demonstration cost).

Quick glossary

• ENS: National Security Scheme, Spanish framework for public-sector information systems and relevant suppliers.
• CCN: Spanish national authority publishing guidance that shapes measures and audit expectations.
• SoA: Statement of Applicability; map of applicable controls and justified exclusions (medium/high).
• ENAC: accreditation body for certification entities under the ENS scheme, among others.

Before the first call to a certification body

Data usually requested in the initial briefing

1. One-page description of the system, main users and data processed.
2. Category hypothesis with short rationale (even if provisional).
3. Current logical diagram and list of critical integrations.
4. Status of security policy and risk analysis (draft, approved version, dates).
5. Target calendar and windows when environment access is possible.

What to prepare so scoping does not inflate cost

• List of proposed exclusions from scope and why.
• Inventory of critical suppliers with contracts available.
• Technical contact with rights to show logs and backups.

Mistakes that stretch ENS certification

• Generic templates without real system assets.
• Mixing consultant and auditor (breaks independence).
• Underestimating category and assuming basic for convenience.
• Scattered evidence (loose email instead of tickets and a repository).
• Blended environments (live credentials or data in non-production).
• Arriving with freshly dated policies and empty logs.

How Privalex supports this journey

Privalex is a consultancy focused on certifications, regulatory compliance and data protection, not a generic law firm or paperwork shop.

How we usually work

• Scope the system and expected category from the start.
• Risk analysis aligned with CCN guidance.
• Operable policies and procedures, not paper only.
• SoA preparation and evidence criteria an auditor can verify.
• Control cross-mapping if ISO 27001 or other certifications already exist.

Cross-team coordination

• Legal and procurement when ENS clauses sit next to processing agreements.
• Incident response so registers and plans exist in practice.
• Cloud migrations or redesigns: new surfaces, subprocessors and access paths enter the risk file before an auditor spots a screenshot inconsistent with the approved diagram.

Goal: sustainable certification, not a spike nobody maintains next year.

Frequently asked questions (FAQs)