Preparing the technical specifications (pliego técnico) for a public software tender is one of the most error-prone tasks in public sector procurement departments. Poorly drafted specifications can force you to declare the tender unsuccessful, attract bids that cannot be delivered or, in the worst case, lead to the contract being awarded to a supplier that does not comply with security regulations. This guide will help you avoid that.
What software technical specifications must include under the LCSP
Spain’s public procurement law, Law 9/2017 on Public Sector Contracts (Ley 9/2017 de Contratos del Sector Público, LCSP), requires tender specifications to define precisely the subject matter of the contract and the minimum technical requirements. For software contracts, this must include:
- A detailed functional description: what the system must do, not how it must do it. Specify use cases, not architectures.
- Security requirements that cite the applicable regulations: the section most often left out and the one that causes the most problems in subsequent audits.
- Measurable acceptance criteria: how to verify that the system works correctly before payment is made.
- Maintenance and support terms: a documented SLA, response times and an escalation procedure.
- Intellectual property: who owns the code delivered and whether it can be audited.
Why the ENS is mandatory and how to include it in the specifications
The National Security Framework (Esquema Nacional de Seguridad, ENS), governed by Royal Decree 311/2022 (Real Decreto 311/2022), is mandatory for the information systems of Spain’s public authorities and for the suppliers that provide services to them. If your organisation handles citizens’ data, public documents or systems connected to the public sector’s corporate network, the software supplier must be ENS-certified.
The category of the system (basic, medium or high) determines the level of certification to require:
| System category | ENS level to require | When it applies |
|---|---|---|
| Basic | Declaration of conformity | Low-impact systems: informational websites, basic forms |
| Medium | Certification of conformity | Most municipal and provincial management systems |
| High | Enhanced certification of conformity | Systems holding sensitive data that are critical to operations |
How to word it in the specifications: it is not enough to write “the supplier must comply with the ENS”. You need to specify:
The successful bidder shall provide evidence of ENS certification
([basic/medium/high] level) issued by an ENAC-accredited certification
body or, failing that, an ENS declaration of conformity audited in
accordance with Royal Decree 311/2022. This certification or declaration
shall remain valid for the entire term of the contract.Also include a requirement for the supplier to report any security incident within a maximum of 24 hours.
For a sense of what a bidder should be able to show – certificate number, issuing body, scope and validity – you can use as a reference the way CEDESA publishes its own on its certifications page: ENS, ISO 27001, ISO 9001 and ISO 56001.
The 5 most common mistakes in public sector software specifications
1. Requiring specific technologies instead of outcomes
Writing “the system must be developed in Java 17 with Spring Boot” restricts competition without providing any guarantee of quality. The LCSP requires you to define performance requirements, not solutions. Write instead: “the system shall be interoperable with the Ministry’s services via a REST API in accordance with the AGE reference architecture” (the AGE, or Administración General del Estado, is Spain’s central government).
2. Leaving out data portability requirements
The specifications must state that, at the end of the contract, the contractor will hand over the data in an open, documented format (CSV, JSON or XML, depending on the type of data). Without this clause, changing supplier may be impossible in practice.
3. Requiring only ISO 9001 when the system processes personal data
ISO 9001 certifies quality processes, not information security. For systems that process citizens’ data or regulated data, ISO 9001 is not enough: you need ENS and/or ISO 27001 certification. Confusing them is the most common security mistake in public sector IT procurement.
4. A vague SLA, or one with no penalties
An SLA that says only “support during office hours” cannot be enforced. Define: response times by severity, financial penalties for non-compliance, the procedure for escalating to second-line support, and guaranteed system availability (e.g. 99.5% excluding scheduled maintenance).
5. Not requiring technical documentation as a deliverable
The software must be accompanied by: a technical manual describing the architecture, API documentation (if there is an API), a system administration manual, and a backup and recovery procedure. Without these, the public body is left hostage to the supplier for any future change.
Checklist: what your specifications must not leave out
Before publishing the tender, check that your specifications include:
- A functional description focused on outcomes, not technologies
- An ENS certification requirement specifying the category of the system
- A data portability clause for the end of the contract
- A documented SLA with financial penalties
- A requirement for technical documentation as a deliverable
- Acceptance criteria that can be verified before payment
- A requirement to report security incidents within 24 hours
- Intellectual property in the code assigned to the contracting authority
The thresholds for technical capacity and financial standing set in the specifications also determine what type of supplier can bid. In Large integrator or mid-sized company? How to choose a supplier we explain how to set them according to the size of the contract without unintentionally excluding certified mid-sized companies.
Frequently asked questions about software technical specifications
Can the supplier be required to be based in Spain or the EU?
Yes, it is possible to require that data be processed within the European Economic Area, especially where citizens’ personal data is involved. This requirement is compatible with the General Data Protection Regulation (GDPR) and can be included in the specifications as a security requirement.
What is the difference between ENS certification and an ENS declaration of conformity?
The ENS declaration of conformity is issued by the supplier itself after a self-assessment process. ENS certification is issued by a certification body (such as Bureau Veritas, AENOR or SGS) accredited by ENAC, Spain’s national accreditation body, and carries more legal and technical weight. For systems in the medium or high category, it is advisable to require certification, not the declaration.
Does the ENS also apply to cloud software (SaaS)?
Yes. If the supplier offers the service as SaaS (Software as a Service) and the data is held on its servers, the ENS applies to both the cloud infrastructure provider and the application supplier. Either both must demonstrate compliance, or the application supplier must demonstrate ENS compliance including the infrastructure on which the application is hosted.
How long does it take a supplier to obtain ENS certification?
The full ENS certification process for a mid-sized company can take between 6 and 18 months, depending on the initial maturity of its security controls. Requiring ENS certification in tender specifications without allowing bidders enough time to obtain it can restrict competition.
As regards technical capacity, the list of criteria and evidence worth requesting from each bidder is in what to require of a public sector software supplier.