A supplier must comply with the ENS whenever its systems form part of the delivery of public services within the scope of Royal Decree 311/2022 (Spain's National Security Framework regulation) and as agreed in the contract. Compliance is not about buying tools: it requires defining the system's scope, categorising it, analysing risks, approving a statement of applicability, implementing controls, gathering evidence, and undergoing the corresponding conformity assessment.
Confirming the scope
The following must be identified:
- The client public entity.
- The service and contract.
- Systems and sites.
- Data and communications.
- Staff with access.
- Cloud services and subcontractors.
- Integrations.
- Shared responsibilities.
Not the entire company needs to fall within scope if the service can be clearly delimited, but critical dependencies cannot be excluded.
Roles
| Role | Responsibility |
|---|---|
| Information Owner | Information requirements and classification |
| Service Owner | Service requirements |
| Security Officer | Security decisions and oversight |
| System Owner | Operation and controls |
| Management | Policy, resources and risk |
These roles must be formally assigned and must avoid conflicting responsibilities.
Categorising the system
The security dimensions set out in the ENS are assessed: availability, authenticity, integrity, confidentiality, and traceability. The resulting impact determines the basic, medium, or high category.
The category must be agreed with the client whenever interdependencies exist. A lower category should never be chosen purely to cut costs.
Policy and internal rules
The security policy sets out principles, organisation, obligations, risk management, incident handling, continuity, personnel, and continual improvement. It is complemented by internal rules and operating procedures.
It must reflect the actual system in place; a generic template does not demonstrate implementation.
Risk analysis
The analysis identifies assets, threats, vulnerabilities, impact, likelihood, and controls. It is updated after changes and incidents, and on a periodic basis.
It must cover the supply chain, cloud services, remote access, ransomware, loss of credentials, and service continuity.
Statement of applicability
The Statement of Applicability (SoA) sets out the applicable controls, their status, the evidence, and the justification. Where compensating controls are used, equal or greater protection must be demonstrated in line with the framework and applicable guides.
| Control | Status | Evidence | Owner | Gap |
|---|---|---|---|---|
| Access control | Implemented | Access matrix and logs | IT | Quarterly review |
| Backups | Partial | Configuration | Operations | Restore test pending |
The SoA is a living document and must match what is verified during the audit.
Technical and organisational controls
The key areas are:
- Policy and organisation.
- Assets.
- Access.
- Operations.
- Protection of communications.
- Protection of information.
- External services.
- Continuity.
- Monitoring.
- Incidents.
Priority is given to the highest-impact baseline controls: asset inventory, MFA, patch management, backups, logging, segregation of duties, and response capability.
Privileged access
Administrative access relies on named accounts, MFA, least privilege, a bastion host where appropriate, logging, and periodic review. Support access is granted on a temporary basis.
Shared accounts without traceability must not exist.
Cloud services and suppliers
The following are reviewed:
- Scope of the provider's certification.
- Shared responsibility.
- Regions.
- Subcontractors.
- Encryption and key management.
- Logs.
- Continuity.
- Notification.
- Exit (reversibility).
The cloud provider's certification does not automatically certify the client's own configuration.
Development and change management
Where software is developed, the following must be covered:
- Security requirements.
- Repositories and branches.
- Code review.
- Dependency management.
- Secrets management.
- Testing.
- Separate environments.
- Approval and rollback capability.
Every significant change must update the risk analysis and the corresponding evidence.
Incidents
The procedure defines detection, classification, containment, communication, recovery, and lessons learned. Contractual deadlines must allow the public body to meet its own obligations.
Ransomware, data leak, service outage, and supplier compromise scenarios are rehearsed.
Continuity
RTOs/RPOs, backups, redundancy, staffing, and communication are all defined. Restoration must be tested in practice: a backup that cannot actually be recovered does not demonstrate continuity.
Conformity assessment
The applicable mechanism depends on the category and the relevant requirements. Some systems require certification by an accredited body, while others may rely on a declaration of conformity under the corresponding rules.
The CCN's ENS portal and the relevant certification body should be consulted. The term "certified" must never be used before certification is obtained or outside its actual scope.
CCN tools
The CCN (Spain's National Cryptologic Centre) provides CCN-STIC guides and governance tools such as INES, AMPARO, and MARGA. These should be used according to the system's scope and never as a substitute for professional judgement.
120-day plan
Days 1-30
Scope, roles, category, and gap analysis.
Days 31-60
Risks, SoA, policies, and priority controls.
Days 61-90
Implementation, testing, incidents, and continuity.
Days 91-120
Internal audit, corrective actions, and conformity assessment.
Evidence
- Scope and architecture.
- Categorisation.
- Risks.
- Policy and SoA.
- Inventory.
- Access.
- Patches.
- Backups and restoration.
- Logs.
- Incidents.
- Suppliers.
- Training.
- Audits.
Common mistakes
- Starting by buying technology.
- Failing to delimit the system.
- Choosing the category based on budget.
- Copying someone else's statement of applicability.
- Relying solely on the cloud provider's certificate.
- Sharing access accounts.
- Not testing backup restoration.
- Overlooking subcontractors.
- Auditing before implementing.
- Communicating certification outside its scope.
Checklist
- Contractual scope defined.
- Roles formally assigned.
- Category approved.
- Risks up to date.
- Policy and SoA approved.
- Controls and evidence gathered.
- Cloud and supply chain reviewed.
- Incident response and continuity tested.
- Internal audit performed.
- Applicable conformity obtained.
Frequently asked questions
Does every public-sector supplier need the ENS?
It depends on the service and the systems used to deliver public services, as well as the contract and the scope of Royal Decree 311/2022.
Does ISO 27001 replace the ENS?
No. It can provide useful controls, but they must be mapped and the ENS's own requirements must still be met. If your company already has an ISMS in place, our ISO 27001 certification service helps you build on that existing work.
Is a certified cloud provider enough?
No. The configuration, operation, and scope of the provider's service must also comply with the ENS.
At Summum Calidad, we support the entire process: from scoping and risk analysis to the statement of applicability, control implementation, and the internal audit that precedes certification. Discover our ENS compliance service.