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 sistemaNivel ENS esixibleCando se aplica
BásicaDeclaración de conformidadeSistemas de baixo impacto: webs informativas, formularios básicos
MediaCertificación de conformidadeA maioría dos sistemas de xestión municipal e provincial
AltaCertificación de conformidade reforzadaSistemas 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.