The ENS usually reaches a SaaS provider as a clause in a tender, with a deadline attached and no room left to renegotiate what it covers.
By then the hard questions have nothing to do with controls. They are about boundary and category, and getting either wrong will price you out of the contract or leave you unable to bid at all.
When does the ENS reach a SaaS platform?
The framework is not limited to public bodies. Under Article 2.3 of RD 311/2022 it also applies to information systems of private entities where three conditions hold together: there is a contractual relationship with a public sector entity, the company provides a service or supplies a solution, and that service is used by the entity in the exercise of its administrative powers.
For a SaaS platform, that usually looks like this: the platform forms part of a service delivered to a public administration, and it processes data relating to citizens, case files or administrative activity. The tender behind the contract then requires ENS conformity of the system supporting that service, which is how most providers find out where they stand.
One point deserves stressing: the whole company does not need to sit inside the boundary. The usual approach is to define a specific information system tied to the contracted service and apply the framework's measures to that.
Why do most SaaS systems land on the Medium category?
The ENS categorises systems as Basic, Medium or High, based on the impact an incident would have across the framework's security dimensions: confidentiality, integrity, availability, authenticity and traceability. A system is Medium when at least one dimension reaches that level and none reaches High.
For SaaS used by an administration, at least one usually does: the data would cause real harm if exposed, the integrity of administrative processes depends on the platform, or service availability has to be guaranteed. Hence the pattern of platforms landing on Medium even when the data itself is unremarkable, because more often than not it is availability or the integrity of the administrative process, not confidentiality, that sets the category.
The boundary decision sets the cost
A common and expensive error is trying to certify the entire organisation, or the whole platform, without separating out the part actually involved in the contracted service.
A disciplined approach identifies the specific service covered by the contract, determines which technical components deliver it, draws the boundary around those components, and explicitly excludes modules, environments and features that play no part. In cloud architectures this analysis has to account for how tenancy, shared services and platform components are separated, which is where cloud security design and certification scoping meet.
Categorising without inflating the category
Categorisation should rest on the real impact of an incident on that system, not on precautionary guesswork. The analysis looks at the nature of the information processed, the type of service delivered, and the consequences of a loss in each security dimension.
Where a system handles several types of information, each dimension takes the highest impact identified for it, and the system's category follows the most demanding of those dimensions. One sensitive dataset can therefore pull the whole platform up a category. Where the architecture allows, separating it into its own boundary keeps the wider system lower, which is why segmentation comes before categorisation.
| Area | Basic | Medium and above |
|---|---|---|
| Access control and identity | Baseline authentication and role separation | Stronger identity governance, privileged access control and review cycles |
| Logging and monitoring | Basic activity records | Systematic recording, retention and monitoring of activity |
| Incident management | A defined handling procedure | Formal process, classification, notification and lessons learned |
| Systems and communications | Standard protection | Reinforced segmentation, cryptographic protection and hardening |
| Continuity | Backups | Tested continuity planning proportionate to the service |
The step between categories is qualitative as well as quantitative: it changes what you must evidence, not only how much.
What an ENS project actually looks like
- Initial analysis: review the contractual requirements and confirm whether the obligation applies.
- Boundary definition: delimit the information system that will be certified.
- Categorisation: assess impact by dimension and determine the system's ENS category.
- Gap analysis: compare the measures required for that category against what the platform already does.
- Remediation: implement the technical and organisational measures still missing.
- Evidence: document and record the controls as they run.
- Audit: independent verification of conformity.
- Certification: obtain the corresponding report or certificate.
Where the platform sits alongside Microsoft 365 or similar collaborative environments, the remediation phase usually pulls in platform-specific controls as well, which our Microsoft 365 security audit checklist covers.
Four mistakes that cost SaaS teams the most
Assuming ISO 27001 is enough. The two overlap in governance and evidence, and an ISO 27001 implementation gives you a great deal of reusable structure, but the ENS has its own categorisation method and its own measures, assessed on their own terms.
Assuming the cloud provider covers it. Azure and AWS hold extensive certifications, but conformity is assessed on your specific system and the way you have configured, operated and evidenced it. Their attestations feed your evidence pack; they do not replace it.
Over-scoping. Including systems, environments or processes that play no part in the contracted service complicates the audit and inflates the cost, often for no commercial gain.
Leaving evidence until the end. Controls that work but produce no record are indistinguishable, at audit, from controls that do not work.
Getting the first decision right
If you are selling to Spanish public bodies, or intend to, the sequence matters: boundary and category first, controls second. Everything downstream inherits those two decisions, including the price of the audit.
Our own ENS High certificate, awarded under RD 311/2022, closed without a single non-conformity, for a broad and cross-functional boundary. It matters here for a narrow reason: advising on boundary and categorisation is easier when you have made those calls yourself, defended them at audit and lived with the result. That experience sits behind our ENS service and our ENS audit readiness work, and as a cybersecurity and compliance company we run security engineering and compliance out of the same team rather than two separate ones.
This article describes the framework established by Royal Decree 311/2022 and is provided for information only. Boundary, categorisation and certification requirements depend on each contract and system, and should be confirmed with qualified advice.
