In this article
- 1. Why ENS and GDPR are inseparable in public sector software
- 2. ENS and RD 311/2022: Low, Medium and High levels
- 3. GDPR applied to public procurement
- 4. The data processor: article 28 GDPR agreement
- 5. International transfers
- 6. Drafting ENS/GDPR requirements in the Technical Specification
- 7. Documentation the provider must supply
- 8. Generative AI and GDPR: what changes with LLM and RAG
- 9. Audit and maintenance: biennial ENS review
- 10. Practical checklist for a contracting body
- 11. Frequently asked questions
1. Why ENS and GDPR are inseparable in public sector software
ENS and GDPR are two regimes with complementary logic. ENS sets the security controls that a public sector information system must apply: authentication, encryption, traceability, continuity, audit. GDPR regulates the processing of personal data from the data subject's rights perspective: lawfulness, minimisation, purpose limitation, accountability.
In a software contract for a public administration, both regimes apply simultaneously: ENS because the system is part of the digital ecosystem of the administration; GDPR because, in practice, almost any administrative software ends up processing personal data (tenderer data, officer data, citizen data). Treating them separately is one of the most common errors when drafting the Technical Specification.
Key fact: Royal Decree 311/2022, of 3 May, replaced RD 3/2010 and updated the ENS to align it with the NIS2 Directive, the GDPR and the eIDAS Regulation. Adaptation to the new ENS was mandatory within 24 months of its entry into force.
2. ENS under RD 311/2022: Low, Medium, High levels and when each applies
ENS classifies systems into three security levels (Low, Medium, High) across each of five dimensions: confidentiality, integrity, traceability, authenticity and availability. The resulting level determines the applicable controls, listed in Annex II of RD 311/2022.
Low level: an incident would cause limited harm to the organisation or data subjects. Typical example: an informational portal without significant personal data. Medium level: harm would be relevant but not serious. Example: administrative processing tools with citizen data. High level: harm would be serious or very serious. Example: systems with special categories of data (health, criminal records), critical infrastructure or essential public services.
Categorisation is carried out by the system owner through a formalised impact analysis. For public procurement tools, the most common outcome is a Medium categorisation in most dimensions, with a High dimension when the system handles data allowing tenderer profiling or when the system is critical to the service.
3. GDPR applied to public procurement
A procurement procedure involves processing several categories of personal data: identification data of tenderers and representatives, professional data of signing officers, solvency data, sometimes data of workers assigned to the service. Each requires its legal basis under article 6 GDPR and a retention period proportionate to LCSP compliance and file documentation.
The Spanish LOPDGDD (Organic Law 3/2018) supplements the GDPR and adds specific obligations for public administrations: mandatory data protection officer (article 34 LOPDGDD), register of processing activities (article 31 LOPDGDD) and coordination with the Spanish Data Protection Agency (AEPD) in case of breaches. Any procured software must fit into this framework.
4. The data processor: article 28 GDPR agreement
When an administration procures software as a service, the provider becomes a data processor with respect to the personal data it processes on behalf of the organisation. Article 28 GDPR requires a specific agreement that must include: object, duration, nature and purpose of processing, type of data, categories of data subjects, obligations of the processor and rights of the controller.
In public procurement, this agreement is usually articulated as a specific clause or annex to the PCAP or the post-award formalised contract. Mandatory minimum elements are: documented instructions from the controller, confidentiality obligations of the provider's staff, technical and organisational measures aligned with ENS, sub-processing regime with prior authorisation, cooperation on data subject rights, breach notification within 72 hours, and return or deletion of data at the end of the contract.
Common error: signing a generic data processor agreement that does not specify the type of data processed or the organisation's specific instructions. The Spanish AEPD has sanctioned such agreements for formal insufficiency in several published rulings.
5. International transfers: when a SaaS provider triggers them
A SaaS provider may involve international data transfers if it: hosts data outside the European Economic Area, uses subcontractors (hosting, support, backups) located outside the EEA, or deploys AI models that process data on non-EU infrastructure. Any of these scenarios triggers the Chapter V GDPR regime.
Legal routes to enable these transfers are three: adequacy decision by the European Commission, appropriate safeguards (2021 Standard Contractual Clauses, Binding Corporate Rules) or specified derogations under article 49 GDPR. After the Schrems II judgment (C-311/18), the controller must additionally perform a Transfer Impact Assessment (TIA) to verify that the recipient country's legislation does not neutralise the contractual safeguards.
For a Spanish public administration, the lower-risk option is to require that all data and the complete processing remain on infrastructure located within the EEA, ideally with encryption at rest where keys are managed by the organisation itself or by a European third party.
6. Drafting ENS/GDPR requirements in the Technical Specification
ENS/GDPR requirements in the Technical Specification must be concrete, verifiable and proportionate to the contract object. A generic clause such as "the provider shall comply with ENS and GDPR" adds nothing and is appealable for indeterminacy. It must translate into operational demands.
Drafting best practice: (1) set the minimum ENS categorisation required of the offered system; (2) require certification or statement of applicability with reference to CCN-STIC-809; (3) specify geographical location of processing and backups; (4) require the article 28 processor agreement as a signed annex at award; (5) establish breach notification SLA; (6) reserve the right to audit the provider.
These requirements, when properly weighted in the award criteria, allow differentiating providers who comply formally from those who comply operationally. This is a key lever in software contracts with an AI component.
7. Documentation the provider must supply (CCN-CERT, statement of applicability)
The provider must prove ENS compliance with formal documentation. The most solid route is an ENS certification issued by an ENAC-accredited body under the CCN-STIC-809 scheme, covering the declared level (Low, Medium or High). As an alternative, a self-declaration based on CCN-STIC-809 with documented internal audit is acceptable.
From the GDPR perspective, the provider must supply: register of processing activities showing the offered service, Data Protection Impact Assessment (DPIA) where high-risk processing is involved, service-applicable privacy policy, identification of the data protection officer and evidence of technical and organisational measures (encryption, pseudonymisation, access control, traceability).
8. Generative AI and GDPR: what changes with LLM and RAG
Large language models (LLMs) and retrieval augmented generation (RAG) architectures raise new questions. First: if the provider uses an LLM trained on the organisation's data, the contract must make clear that such data are not reused to train third-party models. Second: the right not to be subject to a decision based solely on automated processing (article 22 GDPR) limits the use of AI in decisions with legal effects on individuals; an officer must retain final responsibility.
Third: the EU AI Act (Regulation 2024/1689) introduces additional obligations for high-risk systems, including many public sector AI uses. Although its application schedule is phased, AI software contracts signed in 2026 should anticipate it by including adaptation clauses to applicable regulation.
In the specific domain of specification drafting, the practical recommendation is to work with providers offering RAG architecture over the organisation's own documentation, deployment on European infrastructure and contractual guarantees of no data reuse. You can read more about this approach on our how it works page.
9. Audit and maintenance: biennial ENS review
ENS is not a one-off formality. Article 31 of RD 311/2022 establishes that Medium and High category systems must undergo a formal audit every two years, or whenever substantial changes occur. Low category systems require self-assessment on the same cycle.
In long-term SaaS contracts, the PCAP must provide for periodic audits, updates of the statement of applicability when applicable controls change, and the provider's obligation to communicate incidents and infrastructure changes that may affect compliance.
10. Practical checklist for a contracting body
A summary of actions we recommend incorporating in any software file for public administrations that processes personal data:
ENS/GDPR checklist for the file
1 — ENS system categorisation before tendering
Formalised impact analysis determining the level in each dimension and setting the minimum ENS level required of the provider.
2 — Specific clauses in Technical Specification and PCAP
Concrete ENS requirements (level, certification, location), GDPR clauses (legal basis, retention, rights) and award criteria weighting compliance.
3 — Data processor agreement
Specific article 28 GDPR annex signed at award, with detailed instructions, controlled sub-processing and breach notification.
4 — Documentation required from the awardee
ENS certification or statement, DPIA where appropriate, identification of the DPO and evidence of technical and organisational measures.
5 — Monitoring during execution
Annual compliance reports, biennial audits, clause updates if applicable regulation changes (AI Act, adequacy decisions).
For the specific case of AI tools for specification drafting, LicitadIA has been designed from day one with this framework in mind: European deployment, ready-to-sign data processor agreement, no data reuse for training and compatibility with Medium-level ENS controls.
If you want to review the ENS and GDPR documentation before considering a pilot, the most direct route is to contact us indicating your organisation and the type of contracts you handle.
Frequently asked questions
What ENS level does a specification drafting tool need?
It depends on the categorisation of the system under Annex I of RD 311/2022. A tool handling non-personal data or only basic tenderer data typically falls within Low or Medium level. If the system processes citizen data in significant quantities, or if a failure directly affects an essential public service, High level may be required. The final decision belongs to the data controller through an impact analysis and must be formalised before the tender starts.
Can I procure a SaaS hosted outside the European Union?
Yes, but with caveats. International transfers of personal data to countries outside the EEA are regulated by Chapter V of the GDPR. You must check whether an adequacy decision exists (e.g. UK, Canada partially) or apply adequate safeguards: 2021 Standard Contractual Clauses, a transfer impact assessment following the Schrems II ruling and, where appropriate, supplementary technical measures such as encryption at rest with keys managed by the organisation. For Spanish administrations, the general recommendation is to keep processing within the EEA.
Does ENS apply to SaaS tools or only to installed software?
It applies to both. Article 2 of RD 311/2022 defines scope by the use of electronic means in administrative activity, not by deployment model. What varies are the applicable controls: in a SaaS arrangement, the organisation must require the provider to supply documentation proving ENS compliance (certification or statement of applicability), verify its management procedures and retain responsibility over service configuration. Ultimate accountability is not delegated to the provider.
Looking for a provider with ENS and GDPR already solved?
LicitadIA is designed for Spanish public administrations: European deployment, ready-to-sign data processor agreement and ENS compatibility. We send you the documentation before talking about a demo.
Request documentation