Preparar un pliego técnico de software para una licitación pública es una de las tareas que más errores genera en los departamentos de contratación de la Administración. Un pliego mal redactado puede obligar a declarar desierto el proceso, atraer ofertas que no se pueden ejecutar o, en el peor caso, adjudicar un contrato a un proveedor que incumple la normativa de seguridad. Esta guía te ayuda a evitarlo. ## Qué debe incluir un pliego técnico de software según la LCSP La Ley 9/2017 de Contratos del Sector Público (LCSP) establece que los pliegos deben definir con precisión el objeto del contrato y los requisitos técnicos mínimos. Para contratos de software, esto incluye obligatoriamente: - **Descripción funcional detallada**: qué debe hacer el sistema, no cómo debe hacerlo. Especifica casos de uso, no arquitecturas. - **Requisitos de seguridad con referencia normativa**: el apartado más frecuentemente omitido y el que más problemas genera en auditorías posteriores. - **Criterios de aceptación medibles**: cómo se verifica que el sistema funciona correctamente antes del pago. - **Condiciones de mantenimiento y soporte**: SLA documentado, tiempos de respuesta, procedimiento de escalado. - **Propiedad intelectual**: quién es titular del código entregado y si puede ser auditado. ## Por qué el ENS es obligatorio y cómo incluirlo en el pliego El **Esquema Nacional de Seguridad (ENS)**, regulado por el Real Decreto 311/2022, es de aplicación obligatoria para los sistemas de información de las Administraciones Públicas y para los proveedores que les prestan servicios. Si tu organismo maneja datos de ciudadanos, documentos públicos o sistemas conectados a la red corporativa de la Administración, el proveedor de software debe estar certificado en ENS. La categoría del sistema (básica, media o alta) determina el nivel de certificación exigible: | Categoría del sistema | Nivel ENS exigible | Cuándo aplica | |-----------------------|-------------------|---------------| | Básica | Declaración de conformidad | Sistemas de bajo impacto: webs informativas, formularios básicos | | Media | Certificación de conformidad | La mayoría de sistemas de gestión municipal y provincial | | Alta | Certificación de conformidad reforzada | Sistemas con datos sensibles, críticos para la operativa | **Cómo redactarlo en el pliego**: no basta con escribir "el proveedor debe cumplir con el ENS". Debes especificar: ``` El proveedor adjudicatario deberá acreditar la certificación ENS (nivel [básico/medio/alto]) emitida por un organismo de certificación acreditado por ENAC, o en su defecto la declaración de conformidad ENS auditada conforme al Real Decreto 311/2022. Esta acreditación deberá mantenerse vigente durante toda la duración del contrato. ``` Incluye también la exigencia de que el proveedor notifique cualquier incidente de seguridad en un plazo máximo de 24 horas. ## Los 5 errores más comunes en pliegos de software público ### 1. Exigir tecnologías específicas en lugar de resultados Escribir "el sistema debe estar desarrollado en Java 17 con Spring Boot" limita la competencia sin aportar garantías de calidad. La LCSP obliga a definir prestaciones, no soluciones. Escribe en su lugar: "el sistema deberá ser interoperable con los servicios del Ministerio mediante API REST conforme a la arquitectura de referencia de la AGE". ### 2. No incluir requisitos de portabilidad de datos El pliego debe especificar que, a la finalización del contrato, el adjudicatario entregará los datos en formato abierto y documentado (CSV, JSON, XML según el tipo de dato). Sin esta cláusula, cambiar de proveedor puede ser imposible en la práctica. ### 3. Pliegos que solo exigen ISO 9001 cuando el sistema procesa datos personales ISO 9001 certifica procesos de calidad, no seguridad de la información. Para sistemas que procesan datos de ciudadanos o datos regulados, ISO 9001 no es suficiente: necesitas ENS y/o ISO 27001. Confundirlos es el error de seguridad más frecuente en contratación pública de TI. ### 4. SLA ambiguo o sin penalizaciones Un SLA que solo dice "soporte en horario de oficina" no es ejecutable. Define: tiempo de respuesta por severidad, penalización económica por incumplimiento, procedimiento de escalado al segundo nivel, y disponibilidad garantizada del sistema (ej: 99,5% excluyendo mantenimiento programado). ### 5. No exigir documentación técnica entregable El software debe ir acompañado de: manual técnico de la arquitectura, documentación de la API (si la hay), manual de administración del sistema, y procedimiento de backup y recuperación. Sin esto, el organismo queda rehén del proveedor para cualquier modificación futura. ## Checklist: lo que no puede faltar en tu pliego Antes de publicar la licitación, verifica que tu pliego incluye: - [ ] Descripción funcional orientada a resultados, no a tecnologías - [ ] Requisito de certificación ENS con la categoría del sistema especificada - [ ] Cláusula de portabilidad de datos al finalizar el contrato - [ ] SLA documentado con penalizaciones económicas - [ ] Exigencia de documentación técnica entregable - [ ] Criterios de aceptación verificables antes del pago - [ ] Requisito de notificación de incidentes de seguridad en 24h - [ ] Propiedad intelectual del código a favor del organismo contratante ## Preguntas frecuentes sobre pliegos técnicos de software **¿Puede exigirse que el proveedor tenga sede en España o en la UE?** Sí, es posible exigir que el tratamiento de los datos se realice dentro del Espacio Económico Europeo, especialmente cuando se manejan datos personales de ciudadanos. Esta exigencia es compatible con el Reglamento General de Protección de Datos (RGPD) y puede incluirse en el pliego como requisito de seguridad. **¿Qué diferencia hay entre certificación ENS y declaración de conformidad ENS?** La declaración de conformidad ENS la emite el propio proveedor tras un proceso de autoevaluación. La certificación ENS la emite un organismo de certificación acreditado por ENAC (como Bureau Veritas, AENOR o SGS) y tiene más peso legal y técnico. Para sistemas de categoría media o alta, es recomendable exigir la certificación, no la declaración. **¿El ENS aplica también a software en la nube (SaaS)?** Sí. Si el proveedor ofrece el servicio como SaaS (Software as a Service) y los datos residen en sus servidores, el ENS aplica al proveedor de la infraestructura cloud y al proveedor de la aplicación. Deben acreditarse ambos o el proveedor de la aplicación debe acreditar el cumplimiento del ENS incluyendo la infraestructura donde se aloja. **¿Cuánto tiempo tarda un proveedor en obtener la certificación ENS?** El proceso completo de certificación ENS para una empresa mediana puede tomar entre 6 y 18 meses, dependiendo de la madurez inicial de sus controles de seguridad. Exigir ENS en un pliego sin dar tiempo suficiente para que los licitadores la obtengan puede limitar la concurrencia.