# CEDESA DIGITAL, S.L.

> Empresa de desarrollo de software a medida con sede en Badajoz (Extremadura, España). Especializada en proyectos complejos para Administración Pública, sector agroalimentario, ganadería, industria cárnica, transporte, defensa e Inteligencia Artificial. Más de 15 años y +200 proyectos en producción. Opera en toda España y tiene presencia internacional.

Este fichero (llms-full.txt) contiene el texto completo del contenido editorial de https://cedesa.es, generado automáticamente en cada build. Índice resumido en https://cedesa.es/llms.txt.

# Blog

## Software para asociaciones ganaderas: del libro de registro al sistema integrado

URL: https://cedesa.es/blog/software-gestion-asociacion-ganadera/
Publicado: 2026-04-16 · Actualizado: 2026-08-25
Resumen: Qué debe gestionar el software de una asociación ganadera de ovino, porcino o bovino: registro de socios, control de cabezas, trazabilidad REGA, libros genealógicos y reporting autonómico.

Las asociaciones ganaderas —de ovino, porcino, bovino, caprino o aves— tienen una problemática de gestión que no se parece a ningún otro sector. Gestionan censos de animales que cambian constantemente, mantienen libros genealógicos oficiales con validez para mejora genética, comunican con el REGA y con los organismos autonómicos de forma permanente, y tienen que demostrar ante los organismos de control que cada animal censado en sus registros existe realmente en una explotación concreta.

El resultado es que la mayoría de las asociaciones ganaderas trabajan con una combinación de hojas de Excel, aplicaciones autonómicas obsoletas y bases de datos de Access de hace 20 años. Cada cambio normativo —una nueva hoja de comunicación al REGA, un formato nuevo de libro de registro— implica semanas de trabajo manual para adaptar los sistemas.

Esta guía explica qué debe hacer realmente un software para asociaciones ganaderas y por qué la migración a un sistema integrado suele amortizarse en el primer año.

## Qué gestiona realmente una asociación ganadera

Una asociación ganadera es, en esencia, una organización que:

1. **Lleva el registro oficial de animales**: número de cabezas, identificación individual (crotal, chip), fechas de nacimiento, movimientos y bajas de cada animal en cada explotación de los socios.

2. **Gestiona el libro genealógico**: para razas con libro genealógico oficial (ovino manchego, ibérico, merino, vacuno pirenaico, entre muchas otras), la asociación es el organismo de llevanza del libro, lo que implica controles de paternidad, calificaciones morfológicas y registros de rendimientos productivos.

3. **Tramita comunicaciones oficiales**: altas y bajas en el REGA, movimientos entre explotaciones, resultados de saneamiento, declaraciones de existencias para PAC e INTECO.

4. **Presta servicios a socios**: certificados de origen, certificados de méritos para subastas, control lechero, pesajes de corderos, análisis genéticos.

5. **Gestiona las subvenciones**: muchas asociaciones son beneficiarias o gestoras de subvenciones de mejora genética (FEAGA, FEADER, autonómicas). La justificación de estas subvenciones exige reportes documentados del censo, los controles realizados y los animales tratados.

Cuando toda esta gestión se hace con sistemas distintos, no integrados, el trabajo administrativo puede llegar a representar el 40-60% del tiempo del equipo técnico de la asociación.

## Qué debe hacer un software para asociaciones ganaderas

### Gestión del censo con trazabilidad individual

El corazón de cualquier sistema para asociaciones ganaderas es el **registro individual de cada animal**: identificador oficial (crotal, microchip), explotación de origen, fecha de nacimiento, madre y padre (si se conocen), raza, sexo y todas las incidencias registradas (tratamientos, movimientos, bajas).

El sistema debe poder responder en segundos: ¿cuántas ovejas de raza X tiene el socio Y en la explotación Z a fecha de hoy? ¿Qué movimientos ha habido en las últimas 48 horas?

### Integración con REGA

El REGA es el Registro General de Explotaciones Ganaderas. Toda alta, baja o movimiento de animales debe comunicarse al REGA según los plazos establecidos por cada comunidad autónoma. En muchas regiones, esta comunicación es ya obligatoria por vía electrónica.

Un sistema sin integración con el REGA obliga a doble entrada de datos: primero en el sistema de la asociación, luego en la aplicación del REGA. Además de multiplicar el trabajo, aumenta el riesgo de errores y discrepancias entre los registros de la asociación y los oficiales.

### Libro genealógico oficial

Para las asociaciones con libro genealógico reconocido, el sistema debe gestionar:
- **Inscripción**: verificación de requisitos raciales, calificación morfológica, aceptación en libro
- **Genealogía**: árbol genealógico de cada animal, cálculo de coeficientes de consanguinidad
- **Controles de rendimiento**: producción lechera, índices de crecimiento, calificaciones de progenie
- **Certificados**: generación automática de certificados de origen y méritos con los datos del libro

Los libros genealógicos oficiales están regulados por el **Reglamento (UE) 2016/1012** y cada raza tiene su propio reglamento específico. El software debe ser flexible para adaptarse a los requisitos de cada raza.

### Control lechero y pesajes

Para las razas lecheras o de aptitud mixta, el control lechero oficial es uno de los servicios más valorados por los socios: permite calcular índices de selección, identificar los mejores reproductores y justificar el valor genético de los animales para subastas.

El sistema debe gestionar la recogida de datos en campo (con apps móviles para los técnicos de control), el procesado de las muestras y la comunicación de resultados al INTERBEV o al organismo autonómico correspondiente.

### Gestión de socios y cuotas

Más allá del censo animal, la asociación gestiona personas: socios, sus explotaciones asociadas, sus cuotas, sus comunicaciones. El software debe integrar el módulo de gestión de socios con el de gestión animal: un socio puede tener varias explotaciones, y una explotación puede tener varios socios.

### Reporting para organismos de control

Las asociaciones ganaderas presentan informes periódicos a:
- Organismos autonómicos de ganadería
- Ministerio de Agricultura (MAPA) para datos de census y libro genealógico
- Organismos pagadores para justificación de subvenciones
- Entidades de control de calidad (como el Consejo Regulador de la DOP correspondiente)

Cada destinatario tiene su propio formato. Un buen sistema genera los informes en el formato requerido automáticamente, sin procesado manual, reduciendo el riesgo de errores en la justificación de subvenciones.

## Por qué fallan los sistemas genéricos en asociaciones ganaderas

**El problema del modelo de datos**: La gestión ganadera tiene un modelo de datos muy específico. Un animal puede nacer en una explotación, transferirse a otra, registrarse en el libro genealógico, producir descendencia, y darse de baja por sacrificio, muerte o venta. Todo este ciclo de vida debe estar perfectamente documentado con fechas, responsables y comunicaciones oficiales. Un ERP genérico de facturación o gestión empresarial no tiene este modelo de datos y adaptarlo suele costar más que desarrollar un sistema propio.

**El problema de las normativas autonómicas**: La gestión ganadera en España está regulada a nivel autonómico, con variaciones significativas entre comunidades. Los plazos de comunicación al REGA, los formatos de los libros de registro, los requisitos de saneamiento y los formularios de subvenciones son diferentes en Extremadura, Castilla y León, Andalucía o Aragón. Un software "estándar" que funcione bien en una región puede requerir adaptaciones profundas en otra.

**El problema de la conectividad en campo**: Los técnicos de control lechero o de calificación morfológica trabajan en explotaciones con conectividad muy limitada. Las aplicaciones móviles deben funcionar en modo offline y sincronizarse cuando hay cobertura, sin pérdida de datos.

## Señales de que tu sistema actual ya no es suficiente

- Los técnicos duplican el trabajo introduciendo los mismos datos en el sistema de la asociación y en la aplicación del REGA
- Hay discrepancias frecuentes entre el censo oficial y el censo interno de la asociación
- La generación de informes para subvenciones requiere horas de trabajo manual en Excel
- Los socios piden información sobre sus animales y la respuesta tarda días
- Cada actualización normativa implica semanas de adaptación manual de plantillas y formatos
- Los datos de rendimientos productivos están en aplicaciones distintas que no se comunican entre sí

Si reconoces tres o más de estas situaciones, la inversión en un sistema integrado tiene ROI claro: menos horas de trabajo administrativo, menos riesgo de errores en comunicaciones oficiales y más capacidad técnica para dar valor a los socios.

## Qué preguntar antes de contratar un software para tu asociación

1. ¿El sistema tiene integración nativa con el REGA o solo exporta ficheros para importar manualmente?
2. ¿La aplicación móvil para técnicos funciona en modo offline con sincronización posterior?
3. ¿Puede gestionar libros genealógicos con las particularidades de nuestra raza?
4. ¿El proveedor tiene experiencia con otras asociaciones ganaderas en España? ¿Puedo hablar con alguna referencia?
5. ¿Qué ocurre con nuestros datos si decidimos cambiar de proveedor en el futuro? ¿Tenemos acceso a la exportación completa?
6. ¿Cómo se adapta el sistema a los cambios normativos autonómicos? ¿Está incluido en el mantenimiento?
7. ¿El sistema puede escalar si la asociación crece en número de socios o amplía su actividad?

La gestión ganadera es demasiado específica para confiarla a un ERP genérico. Un sistema a medida, desarrollado por un proveedor que entiende el sector, puede transformar la operativa de una asociación: de la burocracia reactiva a la gestión proactiva que añade valor real a los ganaderos.

---

## Software ERP para industria cárnica y mataderos: trazabilidad, IFS y normativa

URL: https://cedesa.es/blog/software-erp-industria-carnica-mataderos/
Publicado: 2026-04-20 · Actualizado: 2026-08-25
Resumen: Guía práctica sobre qué debe incluir un ERP para mataderos y procesado cárnico: trazabilidad lote a lote, auditorías IFS/BRC, integración REGA y gestión de producción en tiempo real.

La industria cárnica española es una de las más auditadas del mundo. IFS Food, BRC, AECOC, TRACES, REGA, etiquetado obligatorio según el Reglamento (UE) 1169/2011… Si llevas una planta de sacrificio, un obrador o una industria de procesado cárnico, sabes que la documentación de trazabilidad no es burocracia: es la diferencia entre pasar la auditoría del cliente de retail y perder el contrato.

El problema es que la mayoría de los ERPs generalistas —SAP, Sage, Odoo— no están diseñados para la casuística real de la industria cárnica. Generan documentos parecidos a los que piden las normas, pero no capturan los datos en el punto y momento en que ocurren, no integran directamente con REGA ni con TRACES, y no permiten el rastreo lote a lote que exige una auditoría IFS de nivel B o A.

Esta guía explica qué debe hacer realmente un ERP para industria cárnica y mataderos, y qué errores evitar en el proceso de selección.

## Por qué los ERPs genéricos fallan en industria cárnica

Un ERP genérico está pensado para gestionar pedidos, facturas, almacén y RRHH. Eso es suficiente para un comercio, una empresa de servicios o incluso una industria manufacturera estándar. Pero la industria cárnica tiene particularidades que lo rompen todo:

**1. Doble flujo de materiales: entrada de canal, salida de producto transformado**

Un matadero no recibe cajas de componentes y ensambla un producto final. Recibe animales vivos con un número de lote vinculado a su origen geográfico (REGA), los sacrifica y transforma en canales que se despiezan en múltiples productos finales. Un ERP que no entienda esta lógica de "un input → muchos outputs con trazabilidad cruzada" no puede generar el árbol de trazabilidad que pide IFS en su cláusula 4.18.

**2. Tiempo real en línea de producción**

La IFS exige que la trazabilidad sea trazable "en toda la cadena de producción". En la práctica, eso significa registrar datos en cada punto de la línea: recepción de animales, clasificación, sacrificio, despiece, envasado, etiquetado y expedición. Si los operarios tienen que ir a un ordenador de oficina a introducir datos, los datos llegan tarde, incompletos o incorrectos.

**3. Gestión de subproductos y materiales no aptos**

Decomiso sanitario, subproductos SANDACH, recortes para industria de transformación… Cada material no apto para consumo humano tiene un tratamiento legal específico y debe documentarse de forma separada. Los ERPs genéricos suelen tratar esto como devoluciones o mermas, lo que contamina los informes de trazabilidad.

**4. Integración con REGA y TRACES**

El Registro General de Explotaciones Ganaderas (REGA) es la fuente de origen de todos los animales que entran en un matadero. La comunicación con REGA y con TRACES (para movimientos intracomunitarios) no es una opción: es un requisito legal. Un ERP sin integración nativa con estos sistemas obliga a doble entrada de datos, aumenta el riesgo de errores y no puede validar los números de explotación en tiempo real.

## Qué debe incluir un ERP para mataderos y procesado cárnico

### Trazabilidad lote a lote completa

El ERP debe poder responder, en menos de 4 horas, a estas preguntas:
- ¿Qué animales dieron origen al lote X de producto Y?
- ¿En qué explotaciones de origen estaban esos animales?
- ¿Qué otros lotes de producto salieron de esos mismos animales?
- ¿A qué clientes se distribuyeron todos esos lotes?

Esto es el "árbol de trazabilidad" que exige IFS. Sin él, la auditoría IFS no puede superarse.

### Etiquetado automático conforme al Reglamento 1169/2011

El etiquetado de carne debe incluir origen del animal (según el Reglamento UE 1337/2013 para bovino, porcino, ovino y aves), fecha de sacrificio, número de lote, categoría y peso. Un ERP bien integrado genera la etiqueta automáticamente en el momento del despiece o envasado, con los datos capturados en producción, sin intervención manual.

### Gestión de APPCC y no conformidades

El plan APPCC (Análisis de Peligros y Puntos Críticos de Control) exige registros de temperatura, pH, tiempos de procesado y no conformidades en cada punto crítico. Un ERP para industria cárnica debe tener un módulo de APPCC con alertas automáticas, registro de acciones correctoras y trazabilidad de los lotes afectados por cada no conformidad.

### Integración con básculas y lectores de código

Los datos de peso no pueden introducirse manualmente sin riesgo de error. La integración directa con básculas industriales, lectores de código de barras o RFID permite capturar datos en el punto de producción, reducir errores de transcripción y generar informes de mermas automáticamente.

### Módulo de ventas con trazabilidad de expedición

Cada albarán de salida debe llevar vinculados los lotes de producto expedido. Si un cliente pide un recall parcial, el sistema debe poder generar en segundos la lista de todos los pedidos que contienen producto del lote afectado, con datos de contacto del cliente.

## Normas que debe soportar el ERP

### IFS Food (versión 8)

La cláusula 4.18 de IFS Food exige un sistema de trazabilidad capaz de identificar lotes de productos desde las materias primas hasta el producto final y la distribución. En auditoría, el evaluador puede solicitar un ejercicio de trazabilidad en tiempo real: hay que trazar un lote en ambas direcciones (upstream y downstream) en menos de 4 horas.

Un ERP que no esté diseñado para esto no pasará el ejercicio de trazabilidad, lo que en IFS Food puede implicar un mayor (incumplimiento grave) o un knockout.

### BRC Global Standard for Food Safety (Issue 9)

La cláusula 3 de BRC regula la gestión de la inocuidad alimentaria, que incluye la trazabilidad. BRC es especialmente estricta en la documentación de proveedores de materias primas y en la gestión de incidentes de seguridad alimentaria.

### Reglamento (CE) 178/2002 — Ley General de Alimentación

Es el marco legal europeo de base para la trazabilidad alimentaria. Obliga a todos los operadores de la cadena a mantener registros de quién les proveyó un alimento y a quién se lo suministraron. En caso de incidente de seguridad alimentaria, estos registros deben estar disponibles para las autoridades competentes de forma inmediata.

## Errores frecuentes al elegir ERP para industria cárnica

**Error 1: Elegir un ERP por precio, no por ajuste sectorial**

Un ERP más barato que no integra REGA o no genera el árbol de trazabilidad IFS saldrá más caro a largo plazo: parametrizaciones costosas, horas de consultoría para adaptar informes que el ERP no puede generar de base, y el riesgo real de suspender una auditoría.

**Error 2: Creer que una hoja de cálculo complementa el ERP**

Si el equipo de producción usa el ERP para facturación pero lleva la trazabilidad en Excel, la trazabilidad no es real ni auditable. Las hojas de cálculo no tienen control de versiones, no registran quién modificó qué dato ni cuándo, y no pueden integrarse con básculas o lectores.

**Error 3: No incluir la integración con básculas en el pliego**

La integración con básculas industriales es técnicamente compleja (protocolos propietarios de cada fabricante, comunicación en tiempo real, tolerancias de error) y muchos ERPs la cobran como proyecto adicional o directamente no la soportan. Es un requisito que debe estar en el pliego de condiciones desde el principio.

**Error 4: No probar el ejercicio de trazabilidad antes de la auditoría**

La auditoría IFS puede solicitar el ejercicio de trazabilidad sin previo aviso. Muchas empresas que tienen ERP descubren en el momento de la auditoría que el sistema tarda horas en generar el árbol, o que hay datos faltantes porque los operarios no los registraron en el momento. El ERP debe testarse con ejercicios de trazabilidad reales antes de la auditoría.

## Checklist: preguntas para evaluar un ERP de industria cárnica

Antes de tomar una decisión, formula estas preguntas al proveedor:

- [ ] ¿El ERP puede generar el árbol de trazabilidad upstream/downstream en menos de 4 horas con datos reales?
- [ ] ¿Integra directamente con REGA para validación de número de explotación en recepción?
- [ ] ¿Genera etiquetas de producto con los datos del Reglamento 1337/2013 de forma automática?
- [ ] ¿Captura datos de básculas industriales en tiempo real? ¿Qué marcas son compatibles?
- [ ] ¿Tiene módulo de APPCC con registro de no conformidades y alertas automáticas?
- [ ] ¿Puede gestionar los subproductos SANDACH con documentación separada?
- [ ] ¿Qué sucede con los datos si el proveedor deja de operar? ¿El cliente tiene acceso al código fuente o a la exportación de datos?

Si el proveedor no puede responder afirmativamente a las primeras cuatro preguntas con una demo real —no con capturas de pantalla—, el ERP no está preparado para una auditoría IFS de nivel B.

---

## Software a medida vs ERP genérico para administración pública: cuál elegir

URL: https://cedesa.es/blog/software-a-medida-vs-erp-administracion-publica/
Publicado: 2026-04-10 · Actualizado: 2026-08-25
Resumen: Análisis honesto de las diferencias entre desarrollar software a medida y contratar un ERP estándar para organismos públicos. Costes reales, riesgos, ENS y cuándo usar cada opción.

Cuando un organismo público necesita un nuevo sistema de gestión, se enfrenta invariablemente a la misma disyuntiva: ¿contratamos un ERP estándar del mercado y lo configuramos para nuestras necesidades, o encargamos desarrollo a medida? Ambas opciones tienen defensores convencidos y casos de éxito. También tienen casos de fracaso costoso. La clave está en saber cuál es la adecuada para cada situación.

## Qué es un ERP genérico y qué es software a medida

**ERP genérico** (Enterprise Resource Planning): sistema estándar de gestión diseñado para funcionar en múltiples sectores y organismos con configuración y parametrización. Ejemplos: SAP, Oracle, Microsoft Dynamics, Odoo. En el sector público español, también soluciones específicas pero estándar como SIGEP, PLYCA para contratación, o las plataformas de la Junta de Castilla y León o de la AGE.

**Software a medida**: sistema diseñado y desarrollado específicamente para los procesos de un organismo o sector concreto. No existe antes del proyecto: se construye según los requisitos del cliente.

Entre ambos extremos hay una zona gris importante: los **ERPs configurables** o los **productos sectoriales**, que son estándar en su base pero con capacidad de personalización profunda. Muchas soluciones para sector público entran en esta categoría.

## Cuándo tiene sentido un ERP estándar

Un ERP estándar es la opción adecuada cuando:

**Los procesos son estándar y no requieren diferenciación.** Contabilidad pública, nóminas de funcionarios, gestión de expedientes administrativos básicos —estos procesos están normalizados por ley y son iguales en todos los organismos del mismo nivel. No hay ventaja en desarrollarlos a medida.

**El organismo no tiene capacidad técnica para mantener software propio.** Un pequeño ayuntamiento de 20 empleados no tiene personal técnico para gestionar actualizaciones, parches de seguridad y adaptaciones legales de un sistema a medida. Un ERP con soporte del fabricante externaliza ese coste de mantenimiento.

**El presupuesto es limitado y el tiempo de implantación corto.** Un ERP existente puede estar en producción en semanas. Un desarrollo a medida de la misma funcionalidad puede tomar entre 3 y 12 meses.

**La funcionalidad cubierta por el ERP es suficiente en un 80-90%.** Si el sistema estándar cubre la mayor parte de las necesidades y solo requiere pequeñas adaptaciones, la eficiencia del ERP supera al desarrollo desde cero.

## Cuándo tiene sentido el software a medida

El desarrollo a medida es la opción adecuada cuando:

**Los procesos son únicos y no están contemplados en ningún ERP del mercado.** El sistema de control de trazabilidad de una cadena de distribución de agua provincial, el módulo de gestión de licitaciones de una diputación con flujos de aprobación específicos por su organigrama, o la plataforma de gestión de mediaciones laborales de SIMA —ninguno de estos sistemas existe como ERP estándar porque no hay mercado suficiente para que ningún fabricante lo desarrolle.

**La integración con sistemas existentes es crítica y compleja.** Cuando el nuevo sistema debe integrarse con varios sistemas heredados (legacy) de diferentes tecnologías, y esa integración define el valor del proyecto, un ERP estándar obliga a adaptaciones costosas que frecuentemente superan el coste del desarrollo a medida.

**El organismo necesita controlar completamente la propiedad intelectual del código.** En proyectos críticos financiados con fondos públicos, tener el código fuente bajo control del organismo permite auditarlo, modificarlo con otros proveedores en el futuro y garantizar la continuidad del servicio independientemente del proveedor original.

**Los requisitos de seguridad son elevados y el ERP estándar no los cubre por defecto.** Para sistemas de categoría media o alta en el ENS, la seguridad debe estar diseñada desde el inicio (security by design). Adaptar un ERP genérico para cumplir los requisitos ENS de alta categoría suele ser más costoso y menos robusto que diseñar la seguridad desde cero.

## La trampa del ERP "casi perfecto": el coste real de la parametrización

El argumento más frecuente a favor del ERP estándar es el económico: "ya está hecho, solo hay que configurarlo". Este argumento falla sistemáticamente cuando la parametrización es extensa.

Un estudio de Gartner sobre implantaciones de ERP en sector público en Europa mostró que **el coste total de propiedad de un ERP con parametrización extensa a lo largo de 5 años es entre 1,8 y 2,4 veces mayor que el coste del contrato inicial**. Los costes ocultos incluyen:

- Licencias anuales que se incrementan con el número de módulos y usuarios
- Consultoría especializada del fabricante para cada parametrización (a tarifas premium)
- Actualizaciones de versión que deshacen las parametrizaciones previas
- Dependencia técnica del fabricante que dificulta el cambio de proveedor

El software a medida tiene sus propios costes de mantenimiento, pero son más predecibles y no incluyen licencias incrementales.

## ENS: cómo afecta a la decisión ERP vs medida

La certificación ENS añade una dimensión importante a esta decisión que frecuentemente se ignora.

**ERPs estándar y ENS**: Los grandes fabricantes (SAP, Microsoft) tienen certificaciones ENS para sus plataformas cloud. Sin embargo, la certificación cubre la plataforma base, no las personalizaciones. Cuando un organismo añade módulos custom o integraciones, esas piezas adicionales quedan fuera del alcance de la certificación y deben certificarse por separado. Esto puede convertir la certificación ENS de un ERP parametrizado en un proceso largo y costoso.

**Software a medida y ENS**: Un proveedor de software a medida certificado en ENS diseña el sistema desde el inicio con los controles de seguridad requeridos. La certificación ENS cubre el producto completo porque no hay una base estándar sobre la que se han añadido capas de personalización. El alcance de la certificación es más claro y el mantenimiento de la certificación más sencillo.

Para organismos con sistemas de categoría media o alta que necesitan una certificación ENS limpia y mantenible, el software a medida con un proveedor certificado suele ser la opción más segura a largo plazo.

## Checklist para decidir: 8 preguntas clave

Antes de decidir entre ERP y software a medida, responde honestamente:

1. ¿Más del 80% de los procesos que necesitas están cubiertos por el ERP estándar sin adaptaciones?
2. ¿Tu organismo tiene capacidad técnica para gestionar un sistema a medida (actualizaciones, incidencias)?
3. ¿El plazo de implantación es un factor crítico (menos de 6 meses)?
4. ¿Los procesos que necesitas son estándar del sector o únicos de tu organismo?
5. ¿Necesitas integración con muchos sistemas externos existentes?
6. ¿Quieres ser propietario del código fuente del sistema?
7. ¿La categoría ENS del sistema es media o alta?
8. ¿Prevés cambios normativos frecuentes que afectarán al sistema?

Si las respuestas 4, 5, 6, 7 u 8 son mayoritariamente "sí", el software a medida es probablemente la opción más eficiente a largo plazo.

## Preguntas frecuentes sobre software a medida vs ERP en sector público

**¿El software a medida puede licitarse como tal o requiere una figura contractual específica?**

Puede licitarse como contrato de servicios (desarrollo) o como contrato mixto (desarrollo + mantenimiento). La LCSP permite contratos a medida sin restricciones; lo importante es que el pliego defina correctamente el objeto del contrato y los criterios de aceptación. Para proyectos complejos, es habitual usar el procedimiento negociado con publicidad o el diálogo competitivo.

**¿Qué garantías tiene el organismo si el proveedor de software a medida desaparece?**

El pliego debe incluir la entrega del código fuente, la documentación técnica completa y el depósito del código en un servicio de custodia de terceros (como AENOR o un notario). Con estas garantías, el organismo puede contratar a otro proveedor para mantener el sistema. Esta cláusula es especialmente importante para software crítico.

**¿Es más difícil justificar un proyecto de software a medida ante la Intervención?**

No necesariamente. La Intervención valora que el objeto del contrato sea claro, que el precio sea justificado por el mercado y que los entregables sean verificables. Un software a medida bien documentado y con criterios de aceptación objetivos es perfectamente justificable. La dificultad aparece cuando el pliego es ambiguo o los entregables no están definidos.

---

## Qué es el ENS y por qué tu proveedor de software debe tenerlo

URL: https://cedesa.es/blog/que-es-el-ens-software-administracion-publica/
Publicado: 2026-04-01 · Actualizado: 2026-08-25
Resumen: Guía completa sobre el Esquema Nacional de Seguridad: qué es, a quién aplica, cómo verificar si tu proveedor está certificado y qué riesgos implica contratar sin ENS.

Si trabajas en una Administración Pública o en una empresa que presta servicios a organismos públicos, es probable que hayas oído hablar del ENS. Pero muchos responsables de contratación no tienen claro qué implica exactamente, cuándo es obligatorio exigirlo a un proveedor de software y, sobre todo, cómo verificar que la certificación es real y está vigente. Esta guía lo explica de forma práctica.

## Qué es el ENS (Esquema Nacional de Seguridad)

El **Esquema Nacional de Seguridad (ENS)** es el marco de referencia de ciberseguridad para los sistemas de información de las Administraciones Públicas españolas. Está regulado por el **Real Decreto 311/2022**, que derogó y actualizó el anterior ENS de 2010.

En términos simples: el ENS define qué controles de seguridad técnicos, organizativos y de gestión debe tener un sistema de información —y su proveedor— para que la Administración pueda confiarle el tratamiento de sus datos y procesos.

No es una certificación voluntaria. Es un **requisito legal** para:
- Los sistemas de información de todas las Administraciones Públicas españolas
- Los proveedores privados que prestan servicios a la Administración cuando esos servicios implican tratamiento de datos públicos o acceso a sistemas de la Administración

El ENS es administrado y supervisado por el **Centro Criptológico Nacional (CCN)**, organismo dependiente del Centro Nacional de Inteligencia (CNI).

## Tres niveles ENS: básico, medio y alto

El ENS categoriza los sistemas según el impacto que tendría un incidente de seguridad:

| Categoría | Descripción | Ejemplos |
|-----------|-------------|----------|
| **Básica** | Incidente con impacto limitado | Webs informativas, formularios de contacto, boletines |
| **Media** | Incidente con impacto significativo | La mayoría de sistemas de gestión municipal, RRHH, contabilidad |
| **Alta** | Incidente con impacto grave o muy grave | Sistemas de seguridad pública, infraestructuras críticas, datos de salud |

Para cada categoría, el ENS define un conjunto de medidas de seguridad que deben implementarse. La categoría la determina el organismo público propietario del sistema, no el proveedor.

## A quién aplica el ENS

### Organismos obligados

Todos los organismos del sector público español están obligados a cumplir el ENS:
- Administración General del Estado (AGE)
- Comunidades Autónomas
- Entidades Locales (ayuntamientos, diputaciones, cabildos)
- Universidades públicas
- Empresas públicas y entidades de derecho público
- Fundaciones del sector público

### Proveedores privados

Un proveedor privado está **obligado a cumplir el ENS** cuando:
1. Presta servicios de administración de sistemas a un organismo público
2. Desarrolla o mantiene software que procesa datos de la Administración
3. Ofrece servicios cloud o SaaS donde residen datos públicos
4. Presta servicios de soporte con acceso a sistemas de producción de la Administración

Si tu empresa provee cualquiera de estos servicios sin certificación ENS, estás incumpliendo el contrato y, en función del pliego, puedes estar expuesto a penalizaciones económicas o resolución del contrato.

## Cómo funciona la certificación ENS

Existen dos formas de acreditar el cumplimiento del ENS:

### Declaración de conformidad ENS

La emite el propio proveedor tras un proceso de autoevaluación documentada. Es suficiente para sistemas de categoría **básica**. Tiene menor peso legal que la certificación porque no está auditada por un tercero independiente.

### Certificación ENS

La emite un **organismo de certificación acreditado por ENAC** (como AENOR, Bureau Veritas, BSI Group, SGS, o Dekra). Incluye una auditoría técnica del sistema y los procesos del proveedor. Es obligatoria para sistemas de categoría **media y alta**, y cada vez más exigida en los pliegos aunque no sea obligatoria por ley.

La certificación tiene una **validez de dos años**, tras los cuales debe renovarse mediante una auditoría de seguimiento. El CCN publica un [registro público de entidades certificadas](https://ens.ccn-cert.cni.es) donde puedes verificar cualquier certificación.

## Cómo verificar si tu proveedor tiene ENS válido

Este es el punto que más se omite en los procesos de contratación. Pedir una certificación ENS no es suficiente: hay que verificar que es auténtica y está vigente.

**Paso 1**: Accede al [portal del CCN sobre el ENS](https://ens.ccn-cert.cni.es) o pide al proveedor el número de certificado y el organismo emisor.

**Paso 2**: Verifica en la web de ENAC que el organismo emisor está acreditado para la certificación del ENS.

**Paso 3**: Comprueba la fecha de emisión y de caducidad. Una certificación ENS vencida no es válida.

**Paso 4**: Verifica que el alcance de la certificación incluye el servicio que vas a contratar. Una empresa puede tener ENS para un producto específico y no para otro.

## Los riesgos de contratar software sin ENS

Muchos organismos siguen contratando software sin exigir ENS, bien por desconocimiento, bien porque el proveedor habitual "siempre ha funcionado bien". Los riesgos son concretos:

**Riesgo legal**: Incumplimiento del Real Decreto 311/2022, con posibilidad de sanciones y responsabilidad personal del responsable de seguridad del organismo.

**Riesgo de auditoría**: Los proyectos financiados con fondos Next Generation EU son auditados por el Tribunal de Cuentas y la Intervención General. Si el proveedor no tiene ENS cuando los fondos exigen cumplimiento, el organismo puede tener que devolver la financiación.

**Riesgo de incidente**: Un proveedor sin ENS no tiene los controles de seguridad auditados que reducen la probabilidad y el impacto de un ciberataque. En caso de brecha de seguridad, la Agencia Española de Protección de Datos (AEPD) puede imponer sanciones RGPD sobre el organismo, no solo sobre el proveedor.

**Riesgo de continuidad**: Si durante la vida del contrato el organismo recibe una auditoría del CCN y el sistema no cumple el ENS, puede verse obligado a suspender el servicio o cambiar de proveedor en plazos muy cortos.

## ENS vs ISO 27001: ¿son lo mismo?

Una confusión frecuente. No son lo mismo, pero son complementarios:

| | ENS | ISO 27001 |
|-|-----|-----------|
| Ámbito | España (obligatorio para sector público español) | Internacional (voluntario) |
| Regulación | Real Decreto 311/2022 (CCN) | Norma ISO/IEC 27001 (ISO) |
| Obligatoriedad | Legal para sector público español | Voluntario |
| Enfoque | Medidas técnicas y organizativas específicas para la AGE | Sistema de gestión de seguridad de la información |
| Reconocimiento | Imprescindible para contratos públicos en España | Reconocido internacionalmente |

Tener ISO 27001 no exime del ENS. Tener ENS sin ISO 27001 es suficiente para contratos públicos españoles, pero menos competitivo en el mercado internacional. Lo óptimo es tener ambos.

## Preguntas frecuentes sobre el ENS

**¿El ENS aplica a sistemas en la nube (cloud)?**

Sí. Cuando un organismo público usa un servicio cloud (SaaS, IaaS, PaaS), el proveedor cloud debe cumplir el ENS para la infraestructura, y el proveedor de la aplicación también para el software. La guía CCN-STIC-823 regula específicamente la utilización de servicios en la nube en la Administración.

**¿Puede exigirse el ENS en contratos con empresas privadas que no son del sector público?**

Legalmente no es obligatorio para empresas privadas que no contratan con la Administración. Pero muchas empresas privadas de sectores regulados (utilities, infraestructuras críticas, banca) lo exigen voluntariamente a sus proveedores como señal de madurez en ciberseguridad.

**¿Cuánto cuesta obtener la certificación ENS para un proveedor de software?**

El coste varía según el tamaño de la empresa y la madurez inicial de sus controles de seguridad. Orientativamente: entre 15.000€ y 50.000€ en consultoría e implantación, más los honorarios del organismo de certificación (entre 5.000€ y 15.000€). El proceso completo suele tomar entre 6 y 18 meses.

**¿Qué pasa si el proveedor pierde la certificación ENS durante el contrato?**

El proveedor está obligado a notificarlo al organismo público contratante. En función del pliego, puede implicar la suspensión del servicio o la resolución del contrato. Esta es una razón más para incluir en el pliego una cláusula de mantenimiento de la certificación durante toda la vida del contrato.

---

## Cómo preparar un pliego técnico de software para una licitación pública con ENS

URL: https://cedesa.es/blog/pliego-tecnico-licitacion-ens/
Publicado: 2026-03-15 · Actualizado: 2026-08-25
Resumen: Guía práctica para responsables de contratación y directores de sistemas que necesitan incluir requisitos ENS en sus licitaciones de software. Evita los errores más costosos.

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.

---

## Next Generation EU para proyectos de digitalización: guía para administraciones públicas

URL: https://cedesa.es/blog/next-generation-eu-digitalizacion-administracion/
Publicado: 2026-01-10 · Actualizado: 2026-08-25
Resumen: Qué fondos Next Gen EU están disponibles para digitalización pública en España, cómo solicitarlos, qué requisitos técnicos exigen y por qué el ENS es imprescindible para ejecutarlos.

Los fondos Next Generation EU han puesto sobre la mesa más de 69.000 millones de euros para España hasta 2026, con el objetivo de transformar la economía y la administración pública española. Buena parte de esos fondos están específicamente orientados a digitalización. Sin embargo, muchos organismos públicos que podrían beneficiarse de ellos no lo hacen por desconocimiento de los requisitos técnicos y procedimentales. Esta guía resume lo esencial.

## Qué es Next Generation EU y por qué importa para la digitalización pública

Next Generation EU (NGEU) es el mayor paquete de estímulo económico de la historia de la Unión Europea, creado para responder a las consecuencias económicas de la pandemia y acelerar la transición verde y digital. En España se canaliza principalmente a través del **Plan de Recuperación, Transformación y Resiliencia (PRTR)**, que estructura las inversiones en diez componentes.

Para la digitalización pública, los componentes más relevantes son:

- **Componente 11 — Modernización de las Administraciones Públicas**: incluye proyectos de digitalización de trámites, implementación de identidad digital, interoperabilidad de sistemas y mejora de la ciberseguridad (ENS).
- **Componente 12 — Política Industrial España 2030**: incluye los PERTE (Proyectos Estratégicos para la Recuperación y Transformación Económica), entre ellos el PERTE Digitalización del Sector Agroalimentario y el PERTE Agua.
- **Componente 15 — Conectividad digital, impulso de la ciberseguridad y despliegue del 5G**: especialmente relevante para municipios rurales y digitalización de servicios en zonas con brecha digital.

## Líneas de financiación disponibles en 2025-2026

### Kit Digital para Ayuntamientos (ampliación)

El programa Kit Digital, inicialmente orientado a pymes, ha sido ampliado para incluir a pequeños municipios y entidades locales menores. Permite financiar:
- Presencia web avanzada y gestión de contenidos
- Comercio electrónico para servicios municipales
- Gestión de redes sociales y comunicación ciudadana
- Soluciones de digitalización de procesos administrativos básicos

Los importes oscilan entre 2.000€ y 12.000€ según el tamaño del municipio, y el proceso de solicitud es gestionado directamente por el organismo.

### Convocatorias PERTE sectoriales

Los PERTE financian proyectos de mayor envergadura (habitualmente desde 500.000€) en sectores estratégicos. Los más activos para tecnología pública son:

- **PERTE Agua**: proyectos de gestión inteligente del agua, sensórica, modelos predictivos de consumo y detección de fugas.
- **PERTE Agroalimentario**: digitalización de la cadena de valor, trazabilidad, inteligencia artificial aplicada a la producción y distribución.
- **PERTE Chip**: microelectrónica y semiconductores, con componente de digitalización industrial.

### Fondos FEDER para digitalización regional

Las Comunidades Autónomas gestionan fondos FEDER con líneas específicas para digitalización de administraciones locales. Las condiciones varían por comunidad, pero en general financian entre el 50% y el 80% del coste del proyecto. Los plazos de tramitación son más cortos que en las convocatorias nacionales.

## Requisitos técnicos imprescindibles para ejecutar estos proyectos

Este es el punto donde muchas administraciones se atascan. Los fondos Next Gen EU tienen condiciones de elegibilidad técnica que van más allá de "el proyecto debe ser digital".

### Principio DNSH (Do No Significant Harm)

Todos los proyectos financiados con NGEU deben cumplir el principio de "No causar perjuicio significativo" a los objetivos medioambientales europeos. Para proyectos TI, esto implica declarar y justificar el consumo energético de la infraestructura, usar proveedores cloud con certificaciones de eficiencia energética y documentar las medidas de reducción de la huella de carbono.

### Cumplimiento del ENS (obligatorio para datos públicos)

Cualquier sistema que procese datos de ciudadanos o esté conectado a la red de la Administración debe cumplir el Esquema Nacional de Seguridad. Esto no es opcional ni interpretable: el CCN (Centro Criptológico Nacional) audita los proyectos NGEU y puede exigir la devolución de fondos si se detecta incumplimiento ENS en la justificación.

El proveedor de software debe acreditar la certificación ENS antes de la firma del contrato. Pedir la certificación ENS después de contratar genera retrasos que pueden hacer perder la ventana de justificación de los fondos.

### Interoperabilidad con los estándares de la AGE

Los sistemas implantados con fondos NGEU en el ámbito de la Administración General del Estado (AGE) deben ser interoperables con el marco de referencia de interoperabilidad (NTI) y, cuando aplique, con el Sistema de Interconexión de Registros (SIR) y Cl@ve para autenticación.

Para administraciones locales, el requisito de interoperabilidad con la AGE no es siempre obligatorio, pero sí es criterio de valoración positivo en muchas convocatorias.

### Documentación técnica exigida en la justificación

La justificación de los fondos ante los organismos europeos exige una documentación técnica precisa:
- Memoria técnica del proyecto con indicadores de impacto verificables
- Contrato con el proveedor que incluya los requisitos técnicos auditables
- Acreditaciones del proveedor (ENS, ISO 27001, etc.)
- Evidencias de cumplimiento de hitos y resultados

Un proyecto bien ejecutado pero mal documentado puede no ser elegible para la justificación.

## Errores frecuentes que hacen perder los fondos

### No vincular el proyecto a los indicadores del PRTR

Cada convocatoria NGEU tiene indicadores de impacto específicos (número de empleados públicos formados, número de trámites digitalizados, porcentaje de reducción de consumo energético). El proyecto debe diseñarse para alcanzar esos indicadores, no al revés. Muchos organismos formulan el proyecto técnico y luego intentan encajarlo en los indicadores, lo que genera inconsistencias en la justificación.

### Subestimar los plazos de contratación pública

Un proyecto Next Gen EU tiene fechas de inicio y finalización improrrogables. Si el proceso de licitación del contrato de software se alarga más de lo previsto —algo habitual cuando el pliego es incorrecto o se presentan recursos—, la ventana de ejecución se reduce drásticamente. La planificación debe incluir un buffer del 30-40% sobre el plazo de licitación estimado.

### No exigir ENS al proveedor desde el inicio

Contratar con un proveedor no certificado en ENS pensando en obtener la certificación durante el proyecto es un riesgo elevado. Los procesos de certificación ENS son auditados por terceros y tienen sus propios plazos. Si el proveedor no tiene ENS cuando el sistema entra en producción, el proyecto puede no ser justificable.

## Preguntas frecuentes sobre Next Generation EU para digitalización

**¿Un ayuntamiento pequeño (menos de 5.000 habitantes) puede acceder a fondos Next Gen?**

Sí. De hecho, muchas convocatorias priorizan a municipios rurales y pequeños. El Kit Digital ampliado es la vía más accesible. Para proyectos más grandes, los fondos suelen llegar a través de convocatorias autonómicas (FEDER) o de diputaciones provinciales que actúan como organismos intermedios.

**¿Cuánto tarda en resolverse una solicitud de fondos Next Gen para digitalización?**

Depende del tipo de convocatoria. Las convocatorias de Kit Digital resuelven en 2-4 meses. Las convocatorias PERTE pueden tomar de 6 a 12 meses desde la solicitud hasta la aprobación. En todos los casos, el plazo de ejecución y justificación corre desde la resolución favorable, no desde la solicitud.

**¿Los fondos NGEU cubren el coste del mantenimiento posterior del sistema?**

Generalmente no. Los fondos NGEU financian el desarrollo e implantación, no el mantenimiento recurrente. El organismo debe presupuestar el coste de mantenimiento (SLA, actualizaciones, soporte) con fondos propios o con otros instrumentos de financiación.

**¿Qué pasa si el proyecto no alcanza los indicadores comprometidos?**

La Intervención General puede exigir la devolución total o parcial de los fondos. En proyectos TI, los indicadores suelen ser objetivos y medibles (número de trámites digitalizados, disponibilidad del sistema, reducción del tiempo de proceso), por lo que es fundamental diseñar el proyecto con indicadores alcanzables, no optimistas.

---

## ISO 27001 en proveedores de software: qué certifica y por qué importa a tu empresa

URL: https://cedesa.es/blog/iso-27001-proveedores-software/
Publicado: 2026-04-18 · Actualizado: 2026-08-25
Resumen: Qué garantiza realmente la certificación ISO 27001 en un proveedor de software, cómo verificarla y qué riesgos asumes si tu proveedor no la tiene. Guía para responsables de IT y contratación.

Cuando una empresa o un organismo público contrata software externo, está poniendo sus datos —y los de sus clientes o ciudadanos— en manos de un tercero. La pregunta que muy pocas organizaciones hacen antes de firmar el contrato es: ¿qué controles de seguridad tiene ese proveedor sobre mis datos?

La certificación ISO 27001 es la respuesta más objetiva a esa pregunta. No porque sea perfecta ni porque garantice que nunca ocurrirá un incidente, sino porque certifica que el proveedor tiene un sistema de gestión de seguridad de la información auditado, con controles documentados y mejorados de forma continua.

Esta guía explica qué certifica realmente la ISO 27001, cómo leer un certificado de forma crítica y qué riesgos concretos asumes si tu proveedor de software no la tiene.

## Qué es la ISO 27001

La **ISO/IEC 27001** es la norma internacional que especifica los requisitos para establecer, implementar, mantener y mejorar continuamente un **Sistema de Gestión de Seguridad de la Información (SGSI)**. La versión vigente es la de 2022.

No es una certificación de producto (no certifica que el software en sí sea seguro). Es una certificación de proceso: certifica que la organización que desarrolla o gestiona software tiene un sistema de gestión con controles para proteger la confidencialidad, integridad y disponibilidad de la información.

Los controles del Anexo A de la ISO 27001:2022 cubren 93 áreas, organizadas en 4 temas:
- **Controles organizativos**: políticas de seguridad, gestión de incidentes, continuidad de negocio
- **Controles de personas**: formación, acuerdos de confidencialidad, teletrabajo
- **Controles físicos**: protección de centros de datos, acceso a instalaciones
- **Controles tecnológicos**: gestión de accesos, cifrado, copias de seguridad, seguridad en desarrollo de software

## Qué certifica y qué NO certifica la ISO 27001

### Sí certifica

- Que el proveedor tiene una política de seguridad documentada y aprobada por dirección
- Que existe un proceso formal de evaluación y tratamiento de riesgos de seguridad
- Que los accesos a sistemas están controlados y auditados
- Que hay un proceso de gestión de incidentes de seguridad
- Que el desarrollo de software sigue prácticas de seguridad documentadas (controles A.8.25 a A.8.31 de la norma)
- Que se realizan auditorías internas y externas del SGSI
- Que la dirección revisa periódicamente el sistema y aprueba mejoras

### No certifica

- Que el software está libre de vulnerabilidades
- Que el proveedor nunca sufrirá un incidente de seguridad
- Que todos los empleados siguen siempre los procedimientos
- Que la infraestructura técnica es segura per se (eso lo evalúan otros controles, como las pruebas de penetración)

La ISO 27001 es un sistema de gestión, no una garantía técnica absoluta. Pero un proveedor certificado tiene probabilidades estadísticamente menores de sufrir un incidente grave, y si lo sufre, tiene procesos definidos para gestionarlo y notificarlo.

## Cómo leer un certificado ISO 27001

No todos los certificados ISO 27001 son iguales. Antes de aceptar uno como válido, verifica estos elementos:

### 1. Organismo certificador

La certificación debe haberla emitido un organismo acreditado por **ENAC** (Entidad Nacional de Acreditación, en España) o por un organismo equivalente en el IAF (International Accreditation Forum). Los más habituales en España: AENOR, Bureau Veritas, SGS, BSI Group, Applus, TÜV Rheinland.

Un certificado emitido por un organismo no acreditado por ENAC o IAF no tiene validez reconocida. Esto ocurre más de lo que se cree: hay empresas que muestran certificados de entidades de dudosa acreditación.

**Cómo verificar**: Accede a la web de ENAC (enac.es) → Entidades acreditadas → busca el organismo emisor del certificado. Si no aparece, el certificado no es válido.

### 2. Alcance del certificado

El certificado ISO 27001 tiene un **alcance** definido: qué actividades, procesos, sistemas o sedes están incluidos. Un proveedor puede estar certificado para "desarrollo de software para clientes del sector financiero" y no para "soporte técnico" o "infraestructura cloud".

Verifica que el alcance del certificado incluye el servicio que vas a contratar. Si el proveedor va a mantener tu sistema en producción pero el certificado solo cubre el desarrollo, el mantenimiento no está auditado.

### 3. Fecha de vigencia

Los certificados ISO 27001 tienen una validez de tres años, con auditorías de seguimiento anuales. Verifica que el certificado está en vigor y que la última auditoría de seguimiento se realizó hace menos de 12 meses.

### 4. Versión de la norma

La versión vigente es ISO/IEC 27001:2022. Si el certificado hace referencia a la versión 2013, el proveedor puede estar en proceso de transición, pero debería haberla completado antes del 31 de octubre de 2025 (fecha límite del período de transición marcado por IAF).

## Riesgos de contratar software sin ISO 27001

### Riesgo RGPD

Cuando contratas un proveedor de software que trata datos personales de tu empresa o tus clientes, ese proveedor es un **encargado del tratamiento** según el RGPD. Estás obligado a firmarlo y a verificar que tiene garantías suficientes de cumplimiento. Si el proveedor sufre una brecha de datos y no tiene ISO 27001, tú como responsable del tratamiento puedes ser sancionado por la AEPD por no haber aplicado la diligencia debida en la selección del encargado.

Las sanciones del RGPD pueden llegar al 4% de la facturación anual global o 20 millones de euros, lo que sea mayor.

### Riesgo de continuidad de negocio

Un proveedor sin gestión formal de continuidad de negocio (que es uno de los controles de ISO 27001) puede verse incapacitado para dar servicio después de un incidente. Sin copias de seguridad testadas, sin plan de recuperación documentado y sin redundancia de sistemas, un ransomware o un fallo de hardware puede dejar tus sistemas inoperativos días o semanas.

### Riesgo en licitaciones y contratos

En sectores regulados (sector público, servicios financieros, utilities, salud), la ISO 27001 está empezando a aparecer como requisito mínimo en pliegos de contratación. Trabajar con un proveedor no certificado puede invalidar tu cumplimiento de los requisitos de seguridad del pliego y, en el sector público, puede implicar la resolución del contrato.

### Riesgo reputacional

Si un proveedor tuyo sufre una brecha de datos que afecta a tus clientes, la percepción pública es que tu empresa no tomó las precauciones necesarias, independientemente de la responsabilidad legal. La selección de proveedores con certificaciones de seguridad reconocidas es parte de la debida diligencia que se espera de cualquier organización.

## ISO 27001 vs otras certificaciones de seguridad

| Certificación | Ámbito | A quién interesa |
|---|---|---|
| ISO 27001 | Sistema de gestión de seguridad de la información | Cualquier empresa que gestione información sensible |
| ENS (Esquema Nacional de Seguridad) | Seguridad para sistemas de la Administración Pública española | Proveedores del sector público español |
| SOC 2 | Seguridad de servicios en la nube (Estados Unidos) | Proveedores SaaS con clientes norteamericanos |
| PCI DSS | Seguridad en pagos con tarjeta | Empresas que procesan pagos con tarjeta |
| TISAX | Seguridad en la industria del automóvil | Proveedores del sector automotriz |

Para la mayoría de las empresas españolas, la combinación **ISO 27001 + ENS** cubre todos los escenarios de contratación: sector privado (ISO 27001) y sector público (ENS). Un proveedor que tenga ambas certificaciones puede trabajar con cualquier tipo de cliente sin restricciones de seguridad.

## Preguntas que debes hacer a tu proveedor de software

Antes de firmar el contrato, pide estas respuestas por escrito:

1. ¿Tienen certificación ISO 27001 vigente? ¿Puedo ver el certificado y verificar el organismo emisor?
2. ¿El alcance del certificado incluye el servicio que voy a contratar?
3. ¿Cuándo fue la última auditoría de seguimiento y cuáles fueron los hallazgos?
4. ¿Tienen plan de continuidad de negocio testado? ¿Con qué frecuencia lo prueban?
5. ¿Cómo gestionan los incidentes de seguridad? ¿En qué plazo me notificarían una brecha que afecte a mis datos?
6. ¿Qué controles aplican al desarrollo seguro de software? ¿Realizan análisis de vulnerabilidades antes de poner en producción?
7. ¿Cómo controlan el acceso de sus empleados y subcontratistas a mis datos?

Un proveedor con ISO 27001 real debe poder responder a todas estas preguntas con documentación concreta, no con generalidades. Si las respuestas son vagas o hay resistencia a compartir información sobre el SGSI, es una señal de alerta.

---

## Inteligencia Artificial aplicada al sector público: tres proyectos reales en España

URL: https://cedesa.es/blog/inteligencia-artificial-sector-publico/
Publicado: 2026-02-20 · Actualizado: 2026-08-25
Resumen: Cómo la IA está transformando la Administración Pública española: asistentes conversacionales para municipios rurales, modelos predictivos y etiquetado NFC inteligente financiados con Next Gen EU.

La inteligencia artificial en el sector público ha dejado de ser una promesa para convertirse en proyectos concretos, contratados, ejecutados y auditados. En España, los fondos Next Generation EU y los PERTE han financiado desde 2022 cientos de proyectos de digitalización con componente de IA en administraciones de todos los tamaños. Estos son tres casos reales —que hemos implantado— para entender qué funciona y qué no.

## Por qué la IA llega ahora a la Administración Pública española

Durante años, la IA era terreno de grandes corporaciones con presupuestos millonarios. Dos factores han cambiado el escenario en la Administración:

**Los modelos de lenguaje (LLMs) se han abaratado radicalmente.** En 2023, desplegar un asistente conversacional de calidad requería un equipo de data scientists y una infraestructura propia. En 2025, los mismos resultados se consiguen mediante APIs de modelos fundacionales (GPT-4, Claude, Gemini) con infraestructura cloud estándar, a una fracción del coste.

**Los fondos europeos exigen innovación medible.** Next Generation EU y los PERTE priorizan proyectos con componente tecnológica y con indicadores de impacto verificables. Esto ha empujado a muchas administraciones que nunca habrían aprobado un presupuesto propio de IA a incluirla en sus solicitudes de fondos.

El resultado es un mercado activo pero exigente: las administraciones quieren IA que funcione, que sea auditable, que cumpla el RGPD y que pueda implantarse con proveedores certificados ENS. No quieren pilotos que no escalen.

## Proyecto 1: Asistente de IA conversacional para 33 municipios rurales de Extremadura

**Contexto**: La Consejería de Digitalización de Extremadura financió con fondos Next Generation EU (425.283€) un proyecto para proporcionar atención ciudadana automatizada a municipios rurales con menos de 500 habitantes, muchos de ellos sin personal técnico de administración a tiempo completo.

**El problema que resolvía**: Los ciudadanos de pequeños municipios tienen las mismas obligaciones administrativas que los de las ciudades —empadronamiento, solicitud de subvenciones, trámites urbanísticos— pero con acceso mucho más limitado a asesoramiento presencial. Un vecino de una pedanía de 80 habitantes puede tardar semanas en resolver una duda que en una capital se resuelve en el mostrador en diez minutos.

**La solución implantada**: Un asistente conversacional disponible 24/7 a través de la web municipal y por WhatsApp, entrenado con la normativa local y autonómica de cada municipio. El sistema escala automáticamente las consultas complejas al técnico municipal, con toda la conversación transcrita y categorizada para facilitar la respuesta humana.

**Resultados a 6 meses**:
- 78% de las consultas resueltas sin intervención humana
- Reducción del 60% en llamadas de consulta al ayuntamiento
- Disponibilidad 24/7 para ciudadanos con horarios no laborales
- Ahorro estimado de 3,2 horas semanales de trabajo administrativo por municipio

**Clave técnica**: el sistema usa RAG (Retrieval-Augmented Generation) sobre la base documental de cada municipio, lo que garantiza que las respuestas están fundamentadas en documentos verificables y no en conocimiento genérico del modelo. Esto es fundamental para la responsabilidad administrativa.

## Proyecto 2: Modelos predictivos para gestión de redes de abastecimiento hídrico (PERTE Agua)

**Contexto**: El Consorcio de Medio Ambiente de la provincia de Badajoz recibió financiación Next Generation EU (70.900€) para un proyecto de vigilancia ambiental con componente predictiva.

**El problema**: Las redes de distribución de agua en zonas rurales tienen un índice elevado de fugas no detectadas que no se descubren hasta que provocan un fallo visible. Reparar una fuga avanzada es entre 5 y 10 veces más caro que detectarla en fase temprana. El mantenimiento reactivo —arreglar cuando se rompe— tiene un coste total muy superior al mantenimiento predictivo.

**La solución**: Un sistema de sensores IoT en los puntos críticos de la red, conectados a un modelo de machine learning que analiza patrones de presión, caudal y consumo para detectar anomalías con hasta 72 horas de antelación. El modelo aprende del historial de incidencias de cada tramo de red.

**Por qué esto es diferente a "instalar sensores"**: Los datos de los sensores solos no sirven sin el modelo que los interpreta. El valor está en la capacidad del sistema de distinguir entre una anomalía que requiere intervención inmediata, una variación estacional normal y un falso positivo. Un modelo mal calibrado genera más trabajo del que ahorra.

**Resultado principal**: reducción del 35% en el tiempo de detección de fugas y disminución del 28% en el coste de reparaciones urgentes en el primer año de operación.

## Proyecto 3: Etiquetado NFC inteligente para trazabilidad en cadena agroalimentaria

**Contexto**: Proyecto implantado para un cliente del sector agroalimentario con exigencias de trazabilidad IFS y necesidad de digitalizar el control de lotes en producción y distribución.

**El problema**: Los sistemas de trazabilidad tradicionales dependen de la introducción manual de datos en distintos puntos de la cadena, lo que genera errores, retrasos y documentación inconsistente que no supera las auditorías IFS/BRC sin correcciones manuales.

**La solución**: Etiquetas NFC embebidas en el envase que registran automáticamente cada movimiento del producto —entrada a producción, controles de temperatura, salida de almacén, recepción en destino— sin intervención humana. El lector NFC se integra con el ERP de trazabilidad y genera automáticamente el informe de auditoría IFS.

La componente de IA entra en la detección de anomalías: el sistema aprende los patrones normales de temperatura, tiempo de tránsito y manipulación para cada tipo de producto, y alerta en tiempo real cuando un lote está fuera de rango antes de que llegue al destino.

**Resultado**: cero no conformidades en la última auditoría IFS del cliente. El informe de trazabilidad completo, que antes tomaba 4 horas de trabajo manual, se genera en menos de 3 minutos.

## Qué necesita una Administración antes de implantar IA

Estos tres proyectos comparten un patrón de éxito que es útil conocer antes de lanzar cualquier iniciativa de IA pública:

**1. Un problema real y medible, no "queremos hacer IA"**
Los proyectos que fracasan suelen empezar con la tecnología y buscar un problema que resolver. Los que funcionan empezar con un proceso concreto, un coste real o un tiempo de respuesta inaceptable, y evalúan si la IA es la mejor herramienta para mejorarlos.

**2. Datos existentes y accesibles**
La IA no crea datos de la nada. Si los procesos actuales no generan datos digitalizados, el primer paso es digitalizarlos —y eso requiere tiempo y recursos antes de poder entrenar cualquier modelo.

**3. Un proveedor que conoce el contexto normativo público**
Implantar IA en la Administración implica cumplir con el ENS, el RGPD, la Ley de Transparencia y, en muchos casos, las Guías de Uso Ético de la IA de la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA). Trabajar con un proveedor sin experiencia en este contexto es garantía de problemas en la auditoría.

## Preguntas frecuentes sobre IA en el sector público

**¿Qué fondos europeos pueden financiar proyectos de IA en una Administración Local?**

Los principales son el Componente 11 del PRTR (Plan de Recuperación, Transformación y Resiliencia) y los PERTE. Para ayuntamientos y diputaciones, los fondos suelen llegar a través de programas autonómicos o del FEDER. El proceso de solicitud requiere un proyecto técnico detallado y un plan de indicadores de impacto verificables.

**¿La IA en la Administración debe cumplir el Reglamento de IA europeo?**

Sí. El AI Act de la UE (en vigor desde agosto de 2024) clasifica muchos sistemas de IA en administración pública como de "alto riesgo", lo que implica obligaciones adicionales de transparencia, supervisión humana y documentación técnica. Los proveedores de estos sistemas deben estar preparados para cumplir estos requisitos.

**¿Puede una Administración pequeña permitirse IA?**

Sí, si el proyecto está bien dimensionado y financiado con fondos europeos. El coste de los proyectos descritos está entre 70.000€ y 425.000€, rangos accesibles para diputaciones y comunidades autónomas mediante PERTE o PRTR. El ROI, cuando el problema es real, suele recuperarse en 12-24 meses.

---

## Canal de denuncias obligatorio en la empresa: cómo cumplir la Ley 2/2023

URL: https://cedesa.es/blog/canal-denuncias-ley-2-2023-software/
Publicado: 2026-04-15 · Actualizado: 2026-08-25
Resumen: Todo lo que necesitas saber sobre el canal de denuncias obligatorio según la Ley 2/2023: a quién aplica, qué debe incluir, plazos, sanciones y cómo implantarlo con software certificado.

La **Ley 2/2023, de 20 de febrero**, reguladora de la protección de las personas que informen sobre infracciones normativas y de lucha contra la corrupción, transpone la Directiva Whistleblowing de la UE al ordenamiento jurídico español. Desde su entrada en vigor, empresas y administraciones públicas están obligadas a implantar un canal de denuncias interno que cumpla con los requisitos técnicos y organizativos de la ley. El incumplimiento tiene consecuencias económicas significativas.

## A quién aplica la Ley 2/2023

La obligación de implantar un canal de denuncias interno aplica a:

**Sector privado**:
- Empresas con 50 o más empleados (cualquier sector)
- Partidos políticos, sindicatos, organizaciones empresariales y fundaciones con financiación pública (independientemente del número de empleados)
- Empresas en sectores financieros (independientemente del tamaño): banca, seguros, servicios de inversión, mercados de valores, entidades de pago

**Sector público**:
- Todas las Administraciones Públicas (AGE, CCAA, entidades locales)
- Organismos públicos y entidades de derecho público
- Empresas con participación mayoritariamente pública

**Importante**: las empresas con entre 50 y 249 empleados pudieron implantar el canal de forma compartida entre varias empresas hasta el 1 de diciembre de 2023. A partir de esa fecha, la obligación es individual.

## Qué debe incluir el canal de denuncias según la ley

La Ley 2/2023 establece requisitos específicos que el canal de denuncias debe cumplir. No basta con un formulario de email o un buzón físico.

### Requisitos técnicos obligatorios

**Confidencialidad garantizada**: el sistema debe garantizar que la identidad del informante solo sea conocida por el responsable del sistema de información interno, sin que sea accesible a ningún otro empleado o directivo de la organización. Esto implica que el canal no puede ser gestionado por RRHH, por el departamento legal interno o por cualquier persona subordinada a quien pueda ser denunciado.

**Opción de denuncia anónima**: el canal debe permitir presentar comunicaciones de forma anónima. Esta es una novedad respecto a legislaciones anteriores: la empresa no puede rechazar denuncias anónimas.

**Acuse de recibo en 7 días**: el sistema debe enviar al informante una confirmación de recepción en un plazo máximo de 7 días naturales desde la comunicación.

**Respuesta en 3 meses**: la empresa o administración debe comunicar al informante las medidas adoptadas o previstas en un plazo máximo de 3 meses desde la recepción (ampliable a 6 meses en casos complejos).

**Independencia del responsable**: la persona responsable del sistema debe tener independencia para llevar a cabo las investigaciones, con acceso directo al órgano de gobierno. En muchos casos, se externaliza este rol a un abogado externo o a un compliance officer independiente.

**Registro**: todas las comunicaciones deben quedar registradas con la fecha, el contenido y las medidas adoptadas. Los registros deben conservarse al menos durante 3 años.

### Qué infracciones debe permitir denunciar

El canal debe cubrir, como mínimo:
- Infracciones del Derecho de la Unión Europea
- Infracciones del ordenamiento jurídico español (penal, administrativo, laboral)
- Vulneraciones de normas internas de la organización
- Acciones u omisiones que puedan constituir corrupción

La ley es amplia intencionalmente: la empresa no puede limitar el alcance del canal solo a algunas categorías de infracciones.

## Las sanciones por incumplir la Ley 2/2023

El régimen sancionador es uno de los más estrictos en materia de compliance en España:

| Infracción | Calificación | Sanción máxima |
|------------|-------------|----------------|
| No disponer de canal de denuncias cuando es obligatorio | Muy grave | 1.000.000€ (empresas) / 500.000€ (persona física) |
| Canal que no cumple los requisitos técnicos | Grave | 300.000€ (empresas) / 100.000€ (persona física) |
| Represalias contra el informante | Muy grave | 1.000.000€ + indemnización al informante |
| No guardar confidencialidad | Muy grave | 1.000.000€ |
| No resolver en plazo | Grave | 300.000€ |

La potestad sancionadora corresponde a la **Autoridad Independiente de Protección del Informante (A.A.I.)**, organismo creado por la propia ley.

## Requisitos técnicos de seguridad: por qué el ENS importa aquí

El canal de denuncias maneja información especialmente sensible: identidades de informantes, detalles de supuestas infracciones, datos sobre personas investigadas. La Ley 2/2023 no menciona explícitamente el ENS, pero sí exige que el sistema garantice la confidencialidad y la integridad de la información.

Para las **Administraciones Públicas**, el ENS es obligatorio también para el canal de denuncias, dado que es un sistema de información que maneja datos personales de ciudadanos o empleados públicos. La categoría del sistema suele ser **media**, lo que requiere certificación por tercero.

Para las **empresas privadas**, el ENS no es obligatorio por ley, pero el uso de un proveedor certificado en ENS y/o ISO 27001 es la forma más robusta de demostrar que se han adoptado medidas técnicas apropiadas para garantizar la confidencialidad exigida por la ley. En caso de litigio o investigación de la A.A.I., esta acreditación es un argumento defensivo importante.

## Cómo implantar el canal de denuncias: pasos prácticos

### Paso 1: Determinar si la obligación aplica

Verifica: número de empleados, sector de actividad, participación pública. Si tienes dudas, consulta con un abogado especializado en compliance o con el proveedor de software antes de iniciar el proyecto.

### Paso 2: Decidir entre gestión interna o externalizada

**Gestión interna**: el responsable del canal es un empleado o directivo de la empresa, generalmente el Compliance Officer o el Director Legal. Válido si la persona designada tiene independencia real y acceso al consejo de administración. Riesgo: conflicto de interés si hay que investigar a la propia dirección.

**Gestión externalizada**: el responsable del canal es un despacho de abogados externo u otra empresa especializada. Elimina el conflicto de interés y aporta credibilidad ante los informantes. Recomendado para empresas sin compliance officer propio.

### Paso 3: Seleccionar e implantar la plataforma tecnológica

La plataforma debe cubrir:
- Formulario de denuncia anónima accesible 24/7
- Cifrado de las comunicaciones en tránsito y en reposo
- Canal de comunicación bidireccional anonimizado (para preguntar al informante sin revelar su identidad)
- Workflow de gestión: registro, asignación, seguimiento de plazos, resolución
- Registro inmutable de todas las acciones (para auditoría)
- Control de acceso por roles con segregación de funciones

### Paso 4: Comunicar la existencia del canal

La ley obliga a informar a todos los empleados de la existencia del canal, su alcance y las protecciones que ofrece al informante. Esta comunicación debe quedar documentada.

### Paso 5: Formar al responsable del canal

El responsable del canal debe recibir formación específica sobre el procedimiento de investigación, los plazos legales, el tratamiento de los datos personales y las garantías del informante.

## Preguntas frecuentes sobre el canal de denuncias

**¿Una empresa con 30 empleados tiene que implantar el canal de denuncias?**

No, si no está en un sector financiero regulado ni tiene participación pública. La obligación para el sector privado general empieza en 50 empleados. Por debajo de ese umbral, tener un canal es una buena práctica de compliance pero no una obligación legal.

**¿Puede usarse el canal de RRHH o el email del director como canal de denuncias?**

No cumple con los requisitos de la ley. El canal debe garantizar la independencia del responsable y la confidencialidad de la identidad del informante. Un email corporativo gestionado por RRHH no cumple ninguno de los dos requisitos.

**¿El RGPD afecta al canal de denuncias?**

Sí. El canal procesa datos personales (del informante, de la persona investigada, de testigos) y debe cumplir con el RGPD. Esto implica: base jurídica para el tratamiento, información al afectado (en la medida en que no comprometa la investigación), plazos de conservación y medidas de seguridad apropiadas. El Responsable del Tratamiento es la empresa, no el proveedor del software.

**¿Puede exigirse que el informante se identifique para procesar su denuncia?**

No. La ley prohíbe rechazar denuncias anónimas. La empresa puede asignar menos recursos a la investigación de denuncias anónimas que a las identificadas, pero no puede ignorarlas ni archivarlas sin investigación previa.

**¿Qué plazo tiene la empresa para implantar el canal si aún no lo tiene?**

La obligación ya está en vigor. Si tu empresa supera los 50 empleados y no tiene canal de denuncias, está en incumplimiento desde el 1 de junio de 2023 (empresas de más de 249 empleados) o desde el 1 de diciembre de 2023 (empresas de 50 a 249 empleados). La implantación urgente es posible: con un proveedor especializado, el canal puede estar operativo en 2-4 semanas.

---