Preparar un prego técnico de software para unha licitación pública é unha das tarefas que máis erros xera nos departamentos de contratación da Administración. Un prego mal redactado pode obrigar a declarar deserto o proceso, atraer ofertas que non se poden executar ou, no peor dos casos, adxudicarlle un contrato a un provedor que incumpre a normativa de seguridade. Esta guía axúdache a evitalo.
Que debe incluír un prego técnico de software segundo a LCSP
A Lei 9/2017 de contratos do sector público (LCSP) establece que os pregos deben definir con precisión o obxecto do contrato e os requisitos técnicos mínimos. Para contratos de software, isto inclúe obrigatoriamente:
- Descrición funcional detallada: que debe facer o sistema, non como debe facelo. Especifica casos de uso, non arquitecturas.
- Requisitos de seguridade con referencia normativa: o apartado que máis a miúdo se omite e o que máis problemas xera en auditorías posteriores.
- Criterios de aceptación medibles: como se verifica que o sistema funciona correctamente antes do pagamento.
- Condicións de mantemento e soporte: SLA documentado, tempos de resposta, procedemento de escalado.
- Propiedade intelectual: quen é o titular do código entregado e se pode ser auditado.
Por que o ENS é obrigatorio e como incluílo no prego
O Esquema Nacional de Seguridade (ENS), regulado polo Real decreto 311/2022, é de aplicación obrigatoria para os sistemas de información das administracións públicas e para os provedores que lles prestan servizos. Se o teu organismo manexa datos de cidadáns, documentos públicos ou sistemas conectados á rede corporativa da Administración, o provedor de software debe estar certificado en ENS.
A categoría do sistema (básica, media ou alta) determina o nivel de certificación esixible:
| Categoría do sistema | Nivel ENS esixible | Cando se aplica |
|---|---|---|
| Básica | Declaración de conformidade | Sistemas de baixo impacto: webs informativas, formularios básicos |
| Media | Certificación de conformidade | A maioría dos sistemas de xestión municipal e provincial |
| Alta | Certificación de conformidade reforzada | Sistemas con datos sensibles, críticos para o funcionamento |
Como redactalo no prego: non abonda con escribir «o provedor debe cumprir co ENS». Debes especificar:
O provedor adxudicatario deberá acreditar a certificación ENS
(nivel [básico/medio/alto]) emitida por un organismo de certificación
acreditado por ENAC ou, na súa falta, a declaración de conformidade ENS
auditada conforme ao Real decreto 311/2022. Esta acreditación deberá
manterse vixente durante toda a duración do contrato.
Inclúe tamén a esixencia de que o provedor notifique calquera incidente de seguridade nun prazo máximo de 24 horas.
Para saber que debe poder amosar un licitador —número de certificado, organismo emisor, alcance e vixencia— podes tomar como referencia como o publica CEDESA na súa páxina de certificacións: ENS, ISO 27001, ISO 9001 e ISO 56001.
Os 5 erros máis comúns nos pregos de software público
1. Esixir tecnoloxías específicas no canto de resultados
Escribir «o sistema debe estar desenvolvido en Java 17 con Spring Boot» limita a competencia sen achegar garantías de calidade. A LCSP obriga a definir prestacións, non solucións. Escribe no seu lugar: «o sistema deberá ser interoperable cos servizos do Ministerio mediante API REST conforme á arquitectura de referencia da AXE».
2. Non incluír requisitos de portabilidade de datos
O prego debe especificar que, ao remate do contrato, o adxudicatario entregará os datos en formato aberto e documentado (CSV, JSON, XML segundo o tipo de dato). Sen esta cláusula, cambiar de provedor pode ser imposible na práctica.
3. Pregos que só esixen ISO 9001 cando o sistema procesa datos persoais
A ISO 9001 certifica procesos de calidade, non seguridade da información. Para sistemas que procesan datos de cidadáns ou datos regulados, a ISO 9001 non abonda: necesitas ENS e/ou ISO 27001. Confundilos é o erro de seguridade máis frecuente na contratación pública de TI.
4. SLA ambiguo ou sen penalizacións
Un SLA que só di «soporte en horario de oficina» non é executable. Define: tempo de resposta segundo a gravidade, penalización económica por incumprimento, procedemento de escalado ao segundo nivel e dispoñibilidade garantida do sistema (p. ex.: 99,5% excluíndo o mantemento programado).
5. Non esixir documentación técnica entregable
O software debe ir acompañado de: manual técnico da arquitectura, documentación da API (se a hai), manual de administración do sistema e procedemento de backup e recuperación. Sen isto, o organismo queda refén do provedor para calquera modificación futura.
Checklist: o que non pode faltar no teu prego
Antes de publicar a licitación, verifica que o teu prego inclúe:
- Descrición funcional orientada a resultados, non a tecnoloxías
- Requisito de certificación ENS coa categoría do sistema especificada
- Cláusula de portabilidade de datos ao rematar o contrato
- SLA documentado con penalizacións económicas
- Esixencia de documentación técnica entregable
- Criterios de aceptación verificables antes do pagamento
- Requisito de notificación de incidentes de seguridade en 24h
- Propiedade intelectual do código a favor do organismo contratante
Os limiares de solvencia técnica e económica do prego determinan ademais que tipo de provedor pode concorrer. En Gran integradora ou empresa mediana? Como elixir provedor explicamos como fixalos segundo o tamaño do contrato sen excluír, sen querer, as empresas medianas certificadas.
Preguntas frecuentes sobre pregos técnicos de software
Pode esixirse que o provedor teña sede en España ou na UE?
Si, é posible esixir que o tratamento dos datos se realice dentro do Espazo Económico Europeo, especialmente cando se manexan datos persoais de cidadáns. Esta esixencia é compatible co Regulamento xeral de protección de datos (RXPD) e pode incluírse no prego como requisito de seguridade.
Que diferenza hai entre a certificación ENS e a declaración de conformidade ENS?
A declaración de conformidade ENS emítea o propio provedor tras un proceso de autoavaliación. A certificación ENS emítea un organismo de certificación acreditado por ENAC (como Bureau Veritas, AENOR ou SGS) e ten máis peso legal e técnico. Para sistemas de categoría media ou alta, é recomendable esixir a certificación, non a declaración.
Aplícase o ENS tamén ao software na nube (SaaS)?
Si. Se o provedor ofrece o servizo como SaaS (Software as a Service) e os datos residen nos seus servidores, o ENS aplícase ao provedor da infraestrutura cloud e ao provedor da aplicación. Deben acreditarse os dous, ou o provedor da aplicación debe acreditar o cumprimento do ENS incluíndo a infraestrutura onde se aloxa.
Canto tempo tarda un provedor en obter a certificación ENS?
O proceso completo de certificación ENS para unha empresa mediana pode levar entre 6 e 18 meses, dependendo da madurez inicial dos seus controis de seguridade. Esixir o ENS nun prego sen dar tempo abondo para que os licitadores a obteñan pode limitar a concorrencia.
Para a parte de solvencia técnica, a lista de criterios e de evidencias que convén pedirlle a cada licitador está en que lle esixir a un provedor de software do sector público.