1. INTRODUCCIÓN Y ENCUADRE

La transformación digital ha convertido los sistemas de información en una infraestructura esencial para el funcionamiento de cualquier organización. En una Administración sanitaria, esta dependencia es especialmente intensa: la identificación de pacientes, la historia clínica, la prescripción, la citación, el laboratorio, la imagen médica, la gestión de profesionales, la contratación, la contabilidad, la logística y la atención a la ciudadanía descansan sobre aplicaciones, redes, centros de proceso de datos, servicios en la nube, integraciones y bases de datos. Cuando estas piezas fallan, el impacto no se limita a una pérdida económica; puede afectar a la continuidad asistencial, a la confidencialidad de datos de salud, a la trazabilidad de decisiones clínicas y administrativas, a la legalidad de la actuación pública y, en situaciones críticas, a la seguridad del paciente.

La auditoría informática proporciona un mecanismo sistemático para obtener confianza sobre ese entorno tecnológico. Su cometido no es administrar los sistemas ni sustituir a quienes toman decisiones operativas, sino examinar de forma independiente si los riesgos relevantes han sido identificados, si los controles están adecuadamente diseñados, si funcionan de manera efectiva y si la organización puede demostrar el cumplimiento de sus obligaciones. La auditoría transforma una percepción subjetiva —«el sistema parece seguro» o «el proceso funciona habitualmente»— en una conclusión sustentada por criterios previamente definidos y por evidencia verificable.

Este carácter probatorio diferencia la auditoría de una mera revisión informal. Una revisión técnica puede localizar vulnerabilidades; una consultoría puede diseñar una arquitectura; una evaluación de riesgos puede estimar amenazas y consecuencias; una prueba de software puede comprobar requisitos funcionales. La auditoría puede utilizar los resultados de todas esas actividades, pero añade una metodología de aseguramiento: determina un alcance, fija criterios, preserva independencia y objetividad, selecciona muestras, documenta procedimientos, evalúa evidencia suficiente y apropiada, formula hallazgos y comunica una conclusión a destinatarios con responsabilidad para actuar.

En el ámbito público, la auditoría informática se integra además en un sistema más amplio de control, rendición de cuentas y fiscalización. Debe convivir con la intervención y el control financiero, la auditoría pública, la fiscalización externa, la protección de datos, el Esquema Nacional de Seguridad, la transparencia, la contratación pública, la continuidad de los servicios esenciales y las obligaciones de archivo y conservación. El auditor de sistemas necesita, por tanto, competencias técnicas y comprensión del marco jurídico-administrativo: un control puede ser técnicamente sólido y, sin embargo, resultar insuficiente para demostrar legalidad, trazabilidad o segregación de responsabilidades.

El temario exige estudiar el concepto y las funcionalidades básicas, las normas y estándares, la organización de la función, las clases de auditoría y las particularidades de la Administración pública. Estos bloques no son compartimentos aislados. La norma seleccionada influye en el criterio; el tipo de auditoría determina las técnicas; la organización de la función condiciona la independencia; y el carácter público del servicio amplía los destinatarios, las responsabilidades y las restricciones sobre la información obtenida. El enfoque correcto es sistémico: auditar no significa buscar errores puntuales, sino valorar si el conjunto de gobierno, procesos, personas y tecnología proporciona una seguridad razonable respecto de los objetivos.

2. CONCEPTO, NATURALEZA Y FINALIDADES DE LA AUDITORÍA INFORMÁTICA

2.1. Definición operativa

La auditoría informática puede definirse como un proceso sistemático, independiente y documentado dirigido a obtener y evaluar objetivamente evidencias sobre los sistemas de información, sus recursos, procesos y controles, con el propósito de determinar en qué medida satisfacen criterios establecidos y contribuyen a los objetivos de la organización. La definición reúne cinco notas esenciales. Es sistemática porque sigue un método reproducible; independiente porque el juicio no debe quedar sometido a quienes gestionan el objeto auditado; documentada porque el trabajo ha de poder revisarse; basada en evidencia porque las conclusiones no se apoyan en intuiciones; y orientada a criterios porque el auditor compara la realidad con requisitos normativos, contractuales, técnicos o internos.

El objeto auditado puede ser un sistema concreto, una aplicación, un proceso de TI, una plataforma tecnológica, un proveedor, un servicio externalizado, un centro de datos, una red, un proyecto de desarrollo, un sistema de gestión o el gobierno de TI de toda la entidad. El alcance debe describirse mediante límites organizativos, funcionales, físicos, tecnológicos y temporales. Una auditoría de una historia clínica electrónica, por ejemplo, puede incluir la aplicación, las bases de datos, los servicios de identidad, las interfaces con laboratorio y farmacia, la infraestructura de alojamiento, los operadores, el soporte y los proveedores; excluir alguno de estos componentes sin justificarlo podría dejar fuera riesgos decisivos.

2.2. Finalidades y atributos de calidad

Las finalidades habituales se relacionan con la confidencialidad, la integridad, la disponibilidad, la autenticidad, la trazabilidad y la conservación de la información y los servicios. A estas dimensiones de seguridad se añaden la eficacia, la eficiencia, la fiabilidad de la información, el cumplimiento, la calidad, la resiliencia y la alineación con los objetivos institucionales. Una auditoría de operación puede valorar si la gestión de incidencias restaura el servicio en los tiempos acordados; una auditoría de aplicación puede verificar que las reglas de validación evitan registros incoherentes; una auditoría de gobierno puede comprobar si el porfolio tecnológico responde a prioridades asistenciales y si los riesgos se elevan al nivel directivo adecuado.

El aseguramiento proporcionado es razonable, no absoluto. Ninguna auditoría puede garantizar que no exista fraude, error, vulnerabilidad o incumplimiento. El trabajo se realiza con limitaciones de tiempo y recursos, utiliza muestreo y depende de la calidad de la evidencia disponible. Además, los controles pueden ser eludidos por colusión, abuso de privilegios o cambios posteriores a la fecha examinada. La conclusión debe expresar adecuadamente estas limitaciones y evitar afirmaciones categóricas que excedan el trabajo efectuado.

2.3. Auditoría, evaluación, inspección, certificación y consultoría

Conviene distinguir conceptos próximos. Una evaluación es un término amplio que puede no exigir independencia formal ni conducir a una opinión de aseguramiento. Una inspección suele verificar aspectos concretos frente a requisitos y puede estar asociada a potestades de supervisión. Una certificación es una atestación de tercera parte mediante la cual un organismo competente declara que un sistema cumple un esquema o norma certificable. Una consultoría ofrece consejo, diseño o acompañamiento y su alcance se acuerda con el cliente; no debe confundirse con el aseguramiento independiente. La prueba de penetración es una actividad técnica que intenta explotar vulnerabilidades bajo autorización; su informe puede constituir evidencia para una auditoría, pero no equivale por sí mismo a una auditoría integral de seguridad.

2.4. Funcionalidades básicas

Las funcionalidades básicas de la auditoría informática son: identificar riesgos y áreas críticas; evaluar el diseño y la efectividad operativa de controles; comprobar cumplimiento normativo y contractual; validar la fiabilidad de datos e informes; detectar debilidades, redundancias y puntos únicos de fallo; revisar la economía y eficiencia de los recursos tecnológicos; apoyar la rendición de cuentas; y promover acciones correctivas verificables. A ello se añade una función preventiva: la mera existencia de controles de auditoría, segregación de funciones y trazabilidad reduce oportunidades de abuso y favorece una cultura de responsabilidad.

La auditoría también actúa como lenguaje común entre dirección, responsables de servicio, seguridad, áreas técnicas, asesoría jurídica, protección de datos y órganos de control. Un hallazgo bien construido traduce un problema técnico a consecuencias institucionales: no se limita a indicar que una cuenta tiene privilegios excesivos, sino que explica qué criterio se incumple, qué riesgo se genera, qué activos pueden verse afectados y qué prioridad requiere la corrección.

3. GOBIERNO, RIESGO, CONTROL Y ASEGURAMIENTO

3.1. Relación entre objetivos, riesgos y controles

La auditoría informática parte de los objetivos de la organización. Un control solo puede juzgarse adecuadamente si se entiende qué objetivo protege y frente a qué riesgo. El objetivo puede ser prestar un servicio clínico sin interrupciones, mantener la exactitud de una nómina, impedir accesos indebidos a datos personales, garantizar que un expediente electrónico conserva integridad o desplegar cambios sin introducir fallos. El riesgo es el efecto de la incertidumbre sobre ese objetivo. El control es la medida de gobierno, organización, proceso o tecnología que modifica la probabilidad o el impacto del riesgo.

Esta relación evita una auditoría mecánica basada en listas de comprobación. Una lista puede confirmar que existe una política, pero no demuestra que sea conocida, aplicada y eficaz. Un control formalmente implantado puede ser irrelevante para el riesgo real; a la inversa, una organización puede utilizar un control alternativo que satisfaga el objetivo aunque no coincida literalmente con una configuración de referencia. El auditor debe comprender el contexto, el diseño, la operación y la evidencia de resultados.

3.2. Riesgo inherente, riesgo de control y riesgo residual

El riesgo inherente es el nivel de exposición antes de considerar controles. El riesgo de control expresa la posibilidad de que los controles no prevengan, detecten o corrijan oportunamente una desviación. El riesgo residual permanece después de aplicar los controles. En la planificación de auditoría también se utiliza el riesgo de auditoría: la posibilidad de emitir una conclusión inadecuada debido a que las pruebas no detecten una desviación relevante. Para reducirlo, se combinan conocimiento del entorno, pruebas de diseño, pruebas de funcionamiento, procedimientos sustantivos, muestreo y revisión de calidad.

La aceptación del riesgo residual corresponde a la dirección o al responsable con autoridad definida, no al auditor. El auditor evalúa si la aceptación está informada, documentada y dentro del apetito y tolerancia aprobados. Si una deficiencia expone datos de salud o compromete un servicio esencial, no basta con que un administrador afirme que «se asume el riesgo»; debe existir una decisión formal del nivel competente, con tratamiento, plazo, responsables y posibles medidas compensatorias.

3.3. Gobierno de TI y COBIT

El gobierno de TI establece cómo se evalúan las necesidades de las partes interesadas, cómo se orienta la toma de decisiones y cómo se supervisan resultados, riesgos y recursos. La gestión, por su parte, planifica, construye, ejecuta y controla actividades para alcanzar la dirección marcada. COBIT 2019, de ISACA, diferencia gobierno y gestión y proporciona objetivos, componentes y factores de diseño para adaptar el sistema a las necesidades de la organización. No es una certificación técnica de producto ni una metodología de pentesting; es un marco de gobierno y gestión que puede emplearse como fuente de criterios de auditoría.

3.4. Modelo de las tres líneas

El modelo de las tres líneas ayuda a distribuir responsabilidades. La primera línea está formada por la dirección y los equipos que poseen y gestionan los riesgos: responsables de aplicaciones, operaciones, infraestructura, procesos asistenciales o administrativos. La segunda línea aporta especialización, supervisión y apoyo en materias como seguridad, cumplimiento, privacidad, calidad, riesgos o continuidad. La tercera línea es la auditoría interna, que proporciona aseguramiento independiente sobre gobierno, gestión de riesgos y control. Los órganos de gobierno reciben información de las tres líneas y deben preservar la independencia de la tercera.

El modelo no significa aislamiento. La coordinación reduce duplicidades y mejora la cobertura, pero la auditoría no debe asumir funciones de primera o segunda línea que comprometan su juicio. Puede utilizar trabajos de seguridad o cumplimiento siempre que evalúe su competencia, objetividad, alcance, metodología y evidencia. La confianza depositada en otros proveedores de aseguramiento debe quedar documentada.

3.5. Control preventivo, detectivo y correctivo

Los controles preventivos tratan de impedir el evento, como la autenticación multifactor o la segregación entre desarrollo y producción. Los detectivos identifican que el evento ha ocurrido, como alertas de un SIEM, conciliaciones o revisiones de accesos. Los correctivos restauran la situación o reducen consecuencias, como la recuperación desde copia, la revocación de credenciales o un procedimiento de respuesta a incidentes. Un diseño equilibrado combina los tres tipos; confiar únicamente en prevención es insuficiente, porque ningún control evita todos los fallos.

También se distinguen controles manuales, automatizados y dependientes de TI. Un control manual puede ser la revisión mensual de usuarios privilegiados; uno automatizado, el bloqueo de una transacción con dato inválido; y uno dependiente de TI, la revisión humana de un informe generado por una aplicación. En este último caso, el auditor debe comprobar no solo que alguien revisa el informe, sino que el informe es completo y exacto.

4. NORMAS TÉCNICAS, ESTÁNDARES Y MARCOS PROFESIONALES

No existe una única norma que cubra toda la auditoría informática. El auditor selecciona un conjunto coherente de normas profesionales, criterios técnicos, requisitos legales y marcos de control. Debe diferenciar entre normas de requisitos certificables, guías metodológicas, catálogos de controles, marcos de gobierno y regulación obligatoria. Confundir su naturaleza conduce a errores frecuentes: ISO 19011 orienta la realización de auditorías, pero no es por sí misma una norma certificable; ISO/IEC 27002 contiene orientación sobre controles, mientras que ISO/IEC 27001 establece requisitos de un sistema de gestión; COBIT estructura gobierno y gestión, pero no sustituye al ENS ni al RGPD.

4.1. ISO 19011:2026

ISO 19011:2026, cuarta edición publicada en mayo de 2026, proporciona directrices para auditar sistemas de gestión. Sustituye a ISO 19011:2018 y aborda los principios de auditoría, la gestión de programas, la realización de auditorías y la competencia de quienes participan. Es aplicable a auditorías de primera, segunda y tercera parte sobre distintos sistemas de gestión y favorece una metodología común. No concede una certificación propia: ayuda a planificar y ejecutar auditorías de normas que sí pueden ser objeto de certificación.

Entre los principios consolidados se encuentran integridad, presentación imparcial, debido cuidado profesional, confidencialidad, independencia, enfoque basado en evidencia y enfoque basado en riesgos. La independencia se interpreta de manera proporcional al tipo de auditoría; en una auditoría interna, la persona auditora puede pertenecer a la organización, pero debe estar libre de responsabilidad directa sobre la actividad examinada y proteger su objetividad.

4.2. Familia ISO/IEC 27000

ISO/IEC 27001:2022 contiene los requisitos de un sistema de gestión de seguridad de la información. La auditoría interna del SGSI, la revisión por la dirección, la evaluación de riesgos, el tratamiento, los objetivos y la mejora continua forman parte del sistema. ISO/IEC 27002:2022 aporta orientación para los controles de seguridad de la información; no todos los controles se aplican automáticamente, pues la selección debe justificarse a partir del riesgo, las obligaciones y el alcance. ISO/IEC 27005:2022 orienta la gestión de riesgos de seguridad y ayuda a conectar el análisis con el tratamiento y la evaluación de controles.

ISO/IEC 27007:2020 desarrolla la gestión de programas y la ejecución de auditorías de SGSI, complementando ISO 19011. En 2026 existe una revisión en tramitación como proyecto de norma, pero mientras no se publique la nueva edición, la referencia vigente sigue siendo la de 2020. ISO/IEC 27008 ofrece orientación para evaluar controles de seguridad. Para privacidad pueden resultar relevantes ISO/IEC 27701 y otras normas de la familia, siempre recordando que una certificación voluntaria no elimina obligaciones del RGPD ni sustituye el juicio jurídico.

4.3. ITAF, COBIT y estándares de auditoría interna

ITAF, en su quinta edición, es el marco de ISACA específicamente orientado a auditoría y aseguramiento de tecnologías de la información. Establece estándares sobre funciones, responsabilidades, ética, comportamiento profesional, conocimientos y competencias, y ofrece guía para planificar, ejecutar y comunicar trabajos. COBIT 2019 puede utilizarse para establecer criterios sobre gobierno y gestión de la información y la tecnología. Ambos marcos son complementarios: COBIT ayuda a definir qué objetivos y prácticas deberían existir; ITAF orienta cómo debe actuar el profesional de auditoría y aseguramiento.

Los Global Internal Audit Standards del Institute of Internal Auditors, edición 2024 y efectivos desde enero de 2025, organizan la práctica en cinco dominios: propósito, ética y profesionalidad, gobierno de la función, gestión de la función y prestación de servicios. Refuerzan la autorización por el órgano de gobierno, la posición independiente, la supervisión, la planificación estratégica, la gestión de recursos, la calidad, la comunicación y el seguimiento de acciones. Son especialmente útiles para diseñar una unidad de auditoría interna que incluya competencias tecnológicas.

4.4. ISO/IEC 20000, ISO 9001 e ISO/IEC 29119

ISO/IEC 20000-1:2018 especifica requisitos para un sistema de gestión de servicios. Una auditoría puede evaluar planificación del servicio, relaciones, resolución, aseguramiento, diseño, transición, entrega y mejora. ISO 9001:2015 proporciona requisitos de gestión de la calidad y puede aportar criterios sobre enfoque a procesos, evaluación del desempeño y mejora. La serie ISO/IEC/IEEE 29119 estructura procesos, documentación y técnicas de pruebas de software; resulta útil para auditar la trazabilidad entre requisitos, casos de prueba, resultados, defectos y criterios de aceptación.

4.5. Marco jurídico y técnico español

En el sector público español, el Real Decreto 311/2022 regula el Esquema Nacional de Seguridad y convierte la auditoría de seguridad en una obligación jurídica según la categoría y el mecanismo de conformidad. La serie CCN-STIC 800 desarrolla criterios de implantación y verificación. La guía CCN-STIC 802 de abril de 2026 describe auditorías de cumplimiento, equipos, alcance, fases, evidencia, informes, planes de acciones correctivas y clasificación de hallazgos. La CCN-STIC 808 sirve de itinerario para verificar medidas; la CCN-STIC 809 aborda declaración, certificación y distintivos de conformidad.

El RGPD incorpora el principio de responsabilidad proactiva y exige medidas apropiadas al riesgo. El delegado de protección de datos supervisa el cumplimiento, incluidas las auditorías correspondientes, pero no monopoliza todas las auditorías de privacidad. El Real Decreto 1112/2018 establece seguimiento y revisión de accesibilidad para sitios web y aplicaciones móviles del sector público. La normativa presupuestaria y de control público, las reglas de contratación, transparencia, archivo e interoperabilidad pueden aportar criterios adicionales según el objeto auditado.

5. ORGANIZACIÓN DE LA FUNCIÓN AUDITORA

5.1. Mandato, estatuto y dependencia

Una función de auditoría eficaz necesita un mandato formal que defina propósito, autoridad, responsabilidad, acceso a información y líneas de reporte. Este mandato suele materializarse en un estatuto o carta de auditoría aprobado por el órgano de gobierno o por el nivel directivo con competencia suficiente. Debe reconocer el derecho de acceso oportuno a registros, aplicaciones, instalaciones, personal, proveedores y documentación dentro del alcance, sujeto a deberes de confidencialidad, protección de datos y secreto profesional.

La posición organizativa es decisiva. La persona responsable de auditoría interna debe tener acceso directo al órgano de gobierno, comité de auditoría o alta dirección y poder comunicar asuntos críticos sin interferencias. La dependencia administrativa puede situarse en una dirección general para cuestiones de presupuesto y personal, pero la dependencia funcional —aprobación del plan, nombramiento, evaluación, alcance y comunicación de resultados— debe proteger la independencia. Una unidad subordinada a la misma dirección que explota los sistemas podría sufrir presiones para reducir alcance, retrasar informes o suavizar hallazgos.

La independencia pertenece a la función; la objetividad, a cada profesional. Puede existir independencia organizativa y, sin embargo, un auditor concreto tener un conflicto por relaciones previas, intereses, participación en el diseño del sistema o responsabilidad reciente sobre el área. Los conflictos reales, potenciales o aparentes deben declararse y gestionarse. Las salvaguardas incluyen reasignación, supervisión adicional, revisión por un tercero o exclusión del aspecto afectado.

5.2. Estructura y perfiles

La estructura depende del tamaño, complejidad y riesgo. Puede existir una unidad centralizada con especialistas, un modelo federado con equipos por ámbitos, un servicio compartido, un órgano de auditoría técnica del sector público o una combinación de recursos internos y proveedores externos. En entornos sanitarios amplios conviene integrar perfiles de gobierno, ciberseguridad, infraestructura, aplicaciones, datos, continuidad, contratación, privacidad, interoperabilidad y auditoría financiera asistida por TI.

El jefe de auditoría o responsable equivalente gestiona estrategia, plan, presupuesto, calidad, relación con el órgano de gobierno y coordinación con otros proveedores de aseguramiento. El jefe de trabajo dirige la misión concreta, valida alcance y pruebas, supervisa papeles de trabajo y revisa hallazgos. Los especialistas ejecutan procedimientos técnicos. Cuando se requieren conocimientos singulares —por ejemplo, dispositivos médicos, criptografía, sistemas industriales, inteligencia artificial o análisis forense— puede incorporarse un experto, pero el auditor conserva la responsabilidad sobre el uso de su trabajo.

Las competencias combinan conocimiento de auditoría, sistemas y sector. Se requiere comprender arquitecturas, redes, bases de datos, desarrollo, gestión de servicios, seguridad, cloud, identidad, logs y continuidad; dominar evaluación de riesgos, control interno, muestreo, documentación y comunicación; y conocer normativa pública y sanitaria. Certificaciones como CISA, CIA, CISSP u otras pueden acreditar parte de la competencia, pero no sustituyen experiencia, actualización y conocimiento del contexto.

5.3. Comité de auditoría y relaciones institucionales

Un comité de auditoría fortalece la supervisión al revisar el plan basado en riesgos, los recursos, la independencia, los resultados críticos, los retrasos en acciones correctivas y la calidad de la función. En el sector público, su configuración depende de la normativa y estructura aplicables; no debe importarse automáticamente el modelo societario privado. Lo esencial es que exista un nivel capaz de exigir respuesta a riesgos transversales y resolver discrepancias entre auditoría y responsables operativos.

La función debe coordinarse con seguridad, protección de datos, calidad, continuidad, control financiero, asesoría jurídica, inspección, contratación y órganos externos. La coordinación no implica intercambiar indiscriminadamente información sensible. Antes de compartir papeles de trabajo se debe comprobar competencia, finalidad, base jurídica, necesidad, clasificación de la información y condiciones de uso. En determinadas investigaciones, una divulgación prematura puede comprometer evidencias o procedimientos disciplinarios, judiciales o de respuesta a incidentes.

5.4. Aseguramiento de calidad

La propia función auditora necesita controles. El programa de aseguramiento y mejora de calidad incluye supervisión continua, revisiones internas periódicas, indicadores, formación, evaluación de competencias, revisión de informes y evaluaciones externas cuando proceda. Debe comprobar conformidad con las normas adoptadas, eficiencia de los trabajos, satisfacción de partes interesadas y valor aportado. La calidad no se mide por el número de hallazgos: una auditoría sin desviaciones puede ser excelente si su alcance y evidencia son sólidos; una auditoría con decenas de observaciones triviales puede ocultar riesgos relevantes.

Entre los indicadores útiles figuran cobertura de riesgos altos, cumplimiento del plan, tiempo desde cierre de campo hasta informe, porcentaje de recomendaciones aceptadas, acciones vencidas, reincidencia, utilización de analítica, revisiones superadas y formación del equipo. Deben evitarse incentivos que premien únicamente cantidad o severidad, porque pueden deteriorar el juicio profesional.

6. PROGRAMA DE AUDITORÍA Y PLANIFICACIÓN BASADA EN RIESGOS

6.1. Universo auditable

La planificación comienza con el universo auditable: conjunto estructurado de entidades, procesos, sistemas, servicios, proyectos, proveedores y riesgos susceptibles de examen. No debe limitarse a un inventario de aplicaciones. Un mismo servicio puede depender de identidades, red, base de datos, interfaces, cloud, soporte y contratos; auditar cada pieza sin visión de servicio puede dejar sin evaluar responsabilidades, dependencias y puntos de fallo.

El universo se mantiene actualizado con el porfolio, inventarios de activos, catálogo de servicios, mapa de procesos, registro de tratamientos, contratos, proyectos, análisis de riesgos, incidentes, cambios regulatorios y resultados anteriores. La aparición de un nuevo servicio, una migración a nube, una fusión organizativa, un ciberincidente o una externalización relevante puede alterar prioridades antes del ciclo anual.

6.2. Evaluación de riesgos y priorización

La planificación basada en riesgos asigna recursos a los asuntos con mayor posibilidad de afectar objetivos. Los factores pueden incluir criticidad asistencial, sensibilidad y volumen de datos, exposición a Internet, dependencia de terceros, complejidad, obsolescencia, cambios, incidentes, debilidades previas, impacto económico, presión regulatoria, fraude, concentración de conocimiento y tiempo desde la última revisión. La puntuación ayuda a ordenar, pero no sustituye el juicio. Un algoritmo puede infravalorar un riesgo emergente porque no existe histórico.

La cobertura debe equilibrar riesgos altos, obligaciones cíclicas y áreas nunca auditadas. Repetir cada año los mismos sistemas porque son conocidos puede dejar zonas ciegas. También debe reservarse capacidad para trabajos no planificados: investigaciones, cambios sustanciales, requerimientos regulatorios, incidentes o solicitudes urgentes del órgano de gobierno.

Ejemplo simplificado de factores de priorización:

Riesgo de auditoría =
  criticidad del servicio
+ impacto sobre datos y legalidad
+ exposición y amenazas
+ magnitud del cambio
+ dependencia de terceros
+ debilidades e incidentes previos
- madurez y cobertura reciente de aseguramiento

La fórmula es conceptual; las ponderaciones deben adaptarse y documentarse. Es importante evitar falsa precisión: una diferencia mínima de puntuación no significa que un objeto sea materialmente más arriesgado. La planificación debe explicar por qué se incluyen y excluyen trabajos, qué riesgos quedan sin cobertura y qué recursos serían necesarios para ampliar el alcance.

6.3. Plan estratégico y plan anual

El plan estratégico de auditoría alinea la función con la estrategia institucional durante varios años, define competencias, tecnología, cobertura, modelo de provisión y evolución hacia auditoría continua. El plan anual concreta trabajos, objetivos preliminares, calendario, responsables, horas, dependencias y reservas. Debe ser aprobado por el nivel de gobierno previsto en el mandato y revisado cuando cambien los riesgos.

Un buen plan no es una lista rígida. Si durante el año aparece una amenaza grave, la función debe poder repriorizar y comunicar el efecto: qué trabajo se incorpora, cuál se aplaza y qué riesgo implica. La transparencia sobre limitaciones de recursos es una obligación profesional. Aceptar un plan imposible puede conducir a alcances superficiales y a una apariencia de cobertura engañosa.

6.4. Coordinación y mapa de aseguramiento

El mapa de aseguramiento relaciona riesgos con quienes los supervisan: operación, seguridad, privacidad, calidad, control financiero, auditoría externa, certificadores y auditoría interna. Permite identificar solapamientos y vacíos. La auditoría puede apoyarse en trabajos ajenos, pero antes debe evaluar competencia, objetividad, alcance, fecha, metodología y calidad de evidencia. Un escaneo automático sin validación no sustituye una auditoría; una certificación limitada a un alcance tampoco cubre sistemas excluidos.

6.5. Objetivos y alcance preliminar

Cada trabajo parte de una hipótesis de riesgo y objetivos concretos. «Auditar la aplicación» es demasiado amplio. Es preferible formular objetivos como: determinar si el acceso se concede según funciones y se revoca oportunamente; comprobar si los cambios en producción están autorizados, probados y trazados; evaluar si las copias soportan los objetivos de recuperación; o verificar si las interfaces procesan mensajes de forma completa y exacta.

El alcance define unidades, ubicaciones, periodos, componentes, procesos y exclusiones. Las exclusiones deben justificarse. Si una base de datos es administrada por un proveedor, no queda fuera por ese motivo; la responsabilidad de la entidad pública exige obtener aseguramiento contractual y técnico. Un límite de acceso puede constituir una limitación de alcance y afectar la conclusión.

7. FASES DE UN TRABAJO DE AUDITORÍA INFORMÁTICA

7.1. Inicio y conocimiento del objeto

El trabajo comienza con la autorización, la identificación de partes interesadas y la recopilación de información. Se revisan organigramas, arquitectura, inventarios, políticas, procedimientos, análisis de riesgos, contratos, diagramas de flujo, incidencias, cambios, informes anteriores y métricas. Las entrevistas iniciales permiten comprender objetivos, responsabilidades y preocupaciones, pero las manifestaciones verbales deben corroborarse.

El auditor construye una visión extremo a extremo. En un proceso de alta de usuarios, por ejemplo, identifica quién solicita, quién aprueba, qué sistema crea la cuenta, cómo se asignan roles, qué controles evitan incompatibilidades, cómo se revisan privilegios y cómo se produce la baja. La comprensión puede documentarse con narrativas, diagramas, matrices de riesgos y controles y pruebas de recorrido.

7.2. Evaluación preliminar de riesgos y diseño del programa

Con el conocimiento obtenido se identifican riesgos y controles clave. El programa de trabajo transforma objetivos en procedimientos: documentos a inspeccionar, poblaciones, muestras, entrevistas, consultas, configuraciones y criterios de evaluación. Debe indicar quién ejecuta, qué evidencia espera y cómo se documenta. Los procedimientos se adaptan si aparecen riesgos nuevos; no son una lista inmutable.

La materialidad en TI no es solo monetaria. Una desviación que afecta a pocos registros puede ser crítica si compromete confidencialidad, derechos, continuidad o seguridad clínica. La importancia se valora por magnitud, naturaleza, alcance, duración, detectabilidad, repetición y obligaciones legales.

7.3. Reunión de apertura

La reunión de apertura comunica objetivo, alcance, criterios, calendario, interlocutores, canales de evidencia, confidencialidad y reglas para pruebas técnicas. Se aclaran necesidades de acceso y se evita interferir con la operación. No es un trámite ceremonial: reduce malentendidos y permite que el auditado prepare evidencia. Cuando existe riesgo de destrucción o manipulación, determinadas actuaciones pueden requerir protocolos especiales y comunicación restringida.

7.4. Trabajo de campo

Durante el trabajo de campo se aplican pruebas de diseño y de efectividad operativa. La prueba de diseño pregunta si el control, tal como está concebido, podría prevenir o detectar el riesgo. La prueba de operación pregunta si funcionó de forma consistente durante el periodo. Una política que exige revisión trimestral de privilegios puede estar bien diseñada; si no hay revisiones o se firman sin comprobar población, falla la operación.

Las pruebas combinan inspección, observación, entrevista, recalculo, repetición, confirmación y análisis. El auditor documenta población, muestra, procedimiento, resultado y excepciones. Las excepciones se investigan para determinar si son casos aislados, errores de datos o fallos sistémicos. Antes de formular un hallazgo se confirma el hecho con el responsable y se solicita evidencia adicional.

7.5. Pruebas técnicas y seguridad

Las pruebas técnicas deben estar expresamente autorizadas, acotadas y coordinadas. Un escaneo, una consulta masiva o una prueba de carga puede afectar producción. Se definen ventanas, rangos, credenciales, límites, reglas de parada, tratamiento de datos y notificación de hallazgos críticos. Las evidencias se protegen y se evita copiar datos personales reales salvo necesidad justificada.

Regla operativa para pruebas técnicas autorizadas:

1. Objetivo y alcance aprobados.
2. Sistemas, direcciones y periodos identificados.
3. Técnicas permitidas y prohibidas documentadas.
4. Contactos y procedimiento de emergencia disponibles.
5. Evidencia protegida, minimizada y trazable.
6. Restauración y cierre verificados.

7.6. Evaluación, contradicción y cierre

Los resultados se comparan con criterios. Una observación se convierte en hallazgo cuando existe evidencia suficiente, efecto o riesgo relevante y necesidad de acción o comunicación. El auditor analiza causa raíz para evitar recomendaciones superficiales. Si las cuentas no se revocan, la causa puede estar en una interfaz inexistente entre recursos humanos e identidad, en responsabilidades ambiguas o en controles manuales sin seguimiento; «recordar al administrador que dé de baja» no resolvería el problema estructural.

La reunión de cierre presenta resultados, escucha evidencia contradictoria, acuerda hechos y discute acciones. No es obligatorio acordar la valoración, pero sí asegurar que la conclusión considera información relevante. Los hallazgos críticos pueden comunicarse inmediatamente sin esperar al informe final.

7.7. Informe y seguimiento

El informe comunica objetivos, alcance, criterios, metodología, limitaciones, conclusión y hallazgos. La dirección formula respuestas y planes con responsable y fecha. El seguimiento verifica implantación y efectividad; no basta con recibir un correo que afirme «corregido». Cuando la dirección acepta un riesgo superior a la tolerancia, la función lo eleva al nivel competente.

8. EVIDENCIA, MUESTREO Y TÉCNICAS ASISTIDAS POR ORDENADOR

8.1. Suficiencia y adecuación

La evidencia es la información utilizada para sustentar hallazgos y conclusiones. La suficiencia se refiere a cantidad; la adecuación, a calidad, relevancia y fiabilidad. Más documentos no compensan evidencia irrelevante. La fiabilidad suele aumentar cuando la fuente es independiente, el auditor obtiene directamente la información, existe control sobre su generación y la evidencia es documental o reproducible. Sin embargo, ninguna regla es absoluta: un registro del sistema puede ser poco fiable si administradores pueden modificarlo sin trazabilidad.

La evidencia puede ser física, documental, testimonial, analítica o técnica. Debe permitir a otro profesional competente comprender qué se hizo, qué se obtuvo y cómo se llegó a la conclusión. Los papeles de trabajo registran objetivo, población, muestra, procedimiento, resultado, excepciones, referencias y revisión. Deben protegerse frente a acceso, alteración y pérdida.

8.2. Técnicas de obtención

La indagación obtiene explicaciones mediante entrevistas; es útil para comprender, pero rara vez suficiente sola. La observación presencia un procedimiento, aunque el comportamiento puede cambiar al saberse observado. La inspección examina documentos, configuraciones, registros o activos. La repetición ejecuta de nuevo un control. El recalculo verifica operaciones. La confirmación obtiene respuesta de un tercero. Los procedimientos analíticos buscan relaciones, tendencias y anomalías.

Una prueba de recorrido sigue una transacción completa desde origen hasta salida. Es especialmente útil en integraciones: se selecciona una petición, se verifica el mensaje enviado, su recepción, validación, transformación, almacenamiento, respuesta y conciliación. Permite detectar puntos donde se pierde trazabilidad o se depende de controles manuales.

8.3. Muestreo

El muestreo estadístico permite inferencias cuantificadas sobre una población mediante selección probabilística. El no estadístico utiliza juicio profesional y puede ser apropiado para riesgos dirigidos, casos críticos o poblaciones pequeñas. En ambos se define población completa, unidad de muestreo, periodo, criterio de desviación, tamaño, método y tratamiento de excepciones. Elegir únicamente casos fáciles o disponibles genera sesgo.

El tamaño depende de riesgo, frecuencia del control, desviación esperada y tolerable, confianza y naturaleza de la prueba. Para un control automatizado estable puede bastar comprobar configuración y cambios; para un control manual recurrente se requieren muestras del periodo. Si una excepción revela un fallo sistémico, ampliar muestra puede ser menos útil que investigar causa y alcance completo.

8.4. CAATs y analítica de datos

Las técnicas de auditoría asistidas por ordenador permiten analizar grandes poblaciones. Incluyen consultas SQL de solo lectura, scripts, herramientas de análisis, exportaciones de SIEM, revisiones de configuración, comparación de archivos, análisis de privilegios, detección de duplicados y secuencias, reconciliaciones y pruebas de integridad. La analítica puede cubrir el cien por cien de transacciones, pero no elimina la necesidad de validar calidad de datos y lógica.

Ejemplos de pruebas analíticas:

- Usuarios activos sin relación laboral vigente.
- Cuentas privilegiadas sin propietario identificado.
- Cambios en producción sin solicitud o aprobación asociada.
- Accesos a historias clínicas fuera de unidad o relación asistencial.
- Transacciones duplicadas o secuencias interrumpidas.
- Copias declaradas como correctas sin prueba de restauración.
- Incidentes cerrados sin evidencia de recuperación del servicio.

Antes de ejecutar una consulta, el auditor valida que la extracción sea completa y exacta: origen, filtros, periodo, zona horaria, campos, transformaciones y recuentos. Si el auditado genera el fichero, se conserva la consulta o se observa su ejecución. Las hojas de cálculo requieren controles de versiones, fórmulas, rangos y modificaciones; una tabla visualmente correcta puede contener filas ocultas o fórmulas sobrescritas.

8.5. Evidencia digital y cadena de custodia

Cuando la evidencia puede utilizarse en investigación o procedimiento, se documenta adquisición, persona, fecha, fuente, método, hash, transferencias, almacenamiento y acceso. Se trabaja sobre copias cuando sea posible y se preserva el original. La sincronización horaria es esencial para correlacionar eventos. Un hash demuestra que un archivo no cambió desde su obtención, pero no prueba que su contenido fuera verdadero en origen.

8.6. Protección de la información de auditoría

Los papeles de trabajo pueden contener vulnerabilidades, datos personales, secretos comerciales, configuraciones y evidencias de incidentes. Se aplican minimización, clasificación, cifrado, control de acceso, registro, conservación y destrucción segura. La retención se determina por normas profesionales, obligaciones legales, política y necesidades de seguimiento; no debe inventarse un plazo universal para todos los logs o papeles.

El auditor necesita acceso, pero no acceso ilimitado e indiscriminado. La solicitud debe ser proporcional al objetivo. Para probar controles sobre datos de salud puede bastar información seudonimizada o atributos de acceso sin contenido clínico. Cuando se requieren datos reales, se documentan finalidad, base, medidas y personas autorizadas.

9. CONTROLES GENERALES DE TI Y CONTROLES DE APLICACIÓN

9.1. Controles generales de tecnologías de la información

Los controles generales de TI, conocidos como ITGC, crean el entorno de confianza sobre el que funcionan aplicaciones y datos. Si son débiles, los controles automatizados de negocio pueden dejar de ser fiables. Se agrupan habitualmente en gobierno y organización, gestión de identidades y accesos, desarrollo y cambios, operaciones, continuidad, seguridad física y lógica, gestión de activos, proveedores y configuración. La clasificación concreta depende del marco utilizado, pero la lógica es estable.

En identidad y acceso se auditan altas, modificaciones, bajas, privilegios, cuentas técnicas, autenticación, revisiones periódicas, segregación y trazabilidad. La pregunta no es solo si existe una contraseña: debe comprobarse que la identidad se vincula a una persona o proceso, que el rol responde a necesidad, que las incompatibilidades se gestionan y que las cuentas dejan de ser utilizables cuando desaparece la causa. Las cuentas compartidas reducen atribución; si son inevitables por limitaciones técnicas, requieren controles compensatorios.

En gestión de cambios se evalúan solicitud, impacto, autorización, desarrollo, pruebas, segregación, aprobación, despliegue, reversión y documentación. Los cambios de emergencia no quedan exentos; siguen un procedimiento abreviado y una revisión posterior. El acceso directo de desarrolladores a producción incrementa riesgo de alteración no autorizada y debe restringirse, monitorizarse y justificarse.

En operaciones se revisan monitorización, planificación de trabajos, gestión de incidencias y problemas, capacidad, copias, restauraciones, parches, vulnerabilidades, antivirus o EDR, registros y respuesta. Una copia exitosa según la consola no demuestra recuperabilidad; se necesitan pruebas de restauración alineadas con objetivos de recuperación. Un SLA de disponibilidad tampoco garantiza continuidad si no contempla dependencias y escenarios de desastre.

9.2. Controles de aplicación

Los controles de aplicación aseguran autorización, integridad, exactitud y completitud de transacciones dentro de un sistema. Se dividen en entrada, procesamiento, salida, interfaces y datos maestros. Los de entrada validan formato, rango, obligatoriedad, unicidad y autorización. Los de procesamiento comprueban cálculos, secuencias, totales y tratamiento de errores. Los de salida protegen informes y distribuciones. Los de interfaz concilian mensajes enviados, recibidos, rechazados y reprocesados. Los de datos maestros controlan creación y modificación de tablas que condicionan reglas de negocio.

En un sistema de citación, por ejemplo, los controles pueden impedir citas duplicadas, validar la unidad, registrar quién modifica la agenda y conciliar mensajes con otros sistemas. En nómina, pueden limitar cambios de cuenta bancaria, verificar conceptos, detectar duplicidades y separar alta, aprobación y pago. En farmacia o laboratorio, la integridad de códigos, unidades y correspondencias puede tener impacto asistencial.

9.3. Diseño y efectividad operativa

La evaluación de diseño determina si el control, individualmente o combinado, aborda el riesgo. La efectividad operativa comprueba que se ejecutó por personas competentes, con frecuencia y evidencia adecuadas. Un control puede operar exactamente como se diseñó y seguir siendo insuficiente. También puede ser adecuado sobre el papel y no ejecutarse. El informe debe separar ambos problemas porque requieren acciones distintas.

9.4. Controles automatizados y dependencia de la configuración

Un control automatizado puede ser consistente, pero depende de código, parámetros, datos maestros, interfaces y accesos. Para confiar en él, el auditor evalúa ITGC relevantes y comprueba lógica y configuración. Si una validación se desactiva mediante parámetro accesible a numerosos administradores, su fiabilidad disminuye. En controles complejos puede ser necesario revisar especificaciones, pruebas, cambios y resultados con datos controlados.

10. CLASES DE AUDITORÍA INFORMÁTICA

10.1. Según la relación con la organización

La auditoría de primera parte es realizada por o para la propia organización y suele corresponder a auditoría interna. La de segunda parte la efectúa una organización sobre un proveedor, socio o parte interesada, normalmente para evaluar obligaciones contractuales. La de tercera parte la realiza una entidad independiente con finalidad de certificación, acreditación o confianza externa. Esta clasificación no coincide exactamente con interno y externo: una auditoría interna puede contratarse externamente, pero conservar finalidad de primera parte.

Las auditorías externas aportan independencia y especialización, aunque necesitan conocimiento del contexto y supervisión contractual. Externalizar no transfiere la responsabilidad de la dirección ni del órgano de gobierno. Deben definirse acceso, confidencialidad, propiedad de papeles, incidentes, subcontratación, conflicto de interés y requisitos de cualificación.

10.2. Según finalidad

La auditoría de cumplimiento verifica requisitos legales, regulatorios, contractuales o internos. La auditoría operativa evalúa eficacia, eficiencia y economía. La auditoría de seguridad examina riesgos y controles de protección. La auditoría financiera asistida por TI valora sistemas que soportan información económico-financiera. La auditoría de gobierno analiza dirección, decisiones, responsabilidades, valor, recursos y supervisión. Una misión puede combinar finalidades, pero debe explicitar criterios y conclusión para cada una.

10.3. Según el objeto tecnológico

La auditoría de infraestructura revisa centros de datos, servidores, almacenamiento, virtualización, redes, cloud y puestos. La auditoría de aplicaciones analiza controles funcionales, interfaces, datos, accesos y operación. La auditoría de bases de datos aborda privilegios, configuración, cifrado, copias, integridad, rendimiento y actividad. La auditoría de desarrollo examina requisitos, arquitectura, código, pruebas, configuración, DevSecOps, despliegue y mantenimiento. La auditoría de servicios valora catálogo, niveles, incidencias, problemas, cambios, capacidad y continuidad.

La auditoría de datos evalúa gobierno, calidad, linaje, metadatos, acceso, conservación y usos. La de proveedores y nube revisa diligencia previa, contratos, responsabilidades compartidas, certificaciones, ubicación, portabilidad, incidentes y salida. La de continuidad examina análisis de impacto, estrategias, planes, pruebas, crisis y recuperación. La de accesibilidad comprueba requisitos técnicos y procesos de seguimiento. La de privacidad evalúa responsabilidad proactiva, legitimación, derechos, minimización, encargos, seguridad y evaluaciones de impacto.

10.4. Según momento y frecuencia

Puede ser previa, concurrente o posterior. La previa actúa antes de una decisión o puesta en producción; debe evitar convertirse en aprobación operativa que comprometa independencia futura. La concurrente observa controles durante la ejecución. La posterior examina periodos ya transcurridos. Por frecuencia se distinguen periódicas, continuas, extraordinarias y de seguimiento.

La auditoría continua utiliza pruebas automatizadas o frecuentes sobre indicadores y transacciones. No significa vigilancia total ni sustituye el juicio. Una auditoría extraordinaria responde a cambios, incidentes o riesgos. El seguimiento verifica acciones de auditorías previas y puede limitarse al estado del hallazgo, salvo que aparezcan riesgos adicionales.

10.5. Según profundidad

Una revisión de diseño se centra en políticas, arquitectura y configuración prevista. Una auditoría de implementación confirma que los controles existen. Una auditoría de efectividad examina funcionamiento durante un periodo. Una evaluación de madurez analiza capacidad, institucionalización y mejora. Una prueba técnica profundiza en vulnerabilidades o configuraciones. Los términos deben definirse en el encargo para evitar que una «auditoría» de alcance documental se interprete como garantía técnica completa.

11. AUDITORÍA DE SEGURIDAD Y CONFORMIDAD CON EL ENS

11.1. Régimen de auditoría

El artículo 31 del Real Decreto 311/2022 establece una auditoría regular ordinaria, al menos cada dos años, para verificar el cumplimiento del ENS, y una auditoría extraordinaria cuando se produzcan modificaciones sustanciales que puedan repercutir en las medidas. La extraordinaria reinicia el cómputo para la siguiente auditoría ordinaria. El plazo puede extenderse tres meses por fuerza mayor no imputable a la entidad en las condiciones previstas por la norma.

La auditoría se realiza según categoría y, en su caso, perfil de cumplimiento específico. El artículo 38 y el anexo III precisan el mecanismo: los sistemas de categoría MEDIA o ALTA requieren auditoría para certificar conformidad, mientras que en categoría BÁSICA basta una autoevaluación para declarar conformidad, sin perjuicio de certificación voluntaria. La guía CCN-STIC 802 de 2026 confirma el ciclo bienal y diferencia auditoría externa de certificación e interna de verificación.

11.2. Auditoría de cumplimiento y auditoría técnica

La CCN-STIC 802 distingue auditoría de cumplimiento y técnica. La primera verifica disposiciones de una norma jurídica, estándar o política y obtiene evidencia mediante documentación, entrevistas y demostraciones realizadas por el auditado. La técnica evalúa eficacia de medidas interactuando directamente con el sistema, como un análisis de vulnerabilidades o un pentest. La auditoría de cumplimiento puede solicitar informes técnicos previos; no debe confundirse con ejecutarlos necesariamente.

Esta separación protege operación y responsabilidades. El auditor de cumplimiento no debe realizar pruebas intrusivas improvisadas. Si necesita evidencia técnica, se planifica una prueba autorizada o se utiliza trabajo de especialistas. El informe debe declarar qué se hizo y qué no, para no transmitir una seguridad superior a la obtenida.

11.3. Equipo auditor y organismos de certificación

La certificación puede ser realizada por una entidad privada acreditada por ENAC, por un Órgano de Auditoría Técnica del sector público reconocido por el CCN o, excepcionalmente, por el propio CCN. El organismo debe gestionar riesgos de imparcialidad y demostrar competencia técnica. El equipo necesita conocimiento del ENS, auditoría, categoría, arquitectura, tecnologías y sector.

La organización auditada aporta responsables, interlocutores, documentación y evidencias. La diferenciación de responsabilidades del ENS exige separar responsable de seguridad y responsable del sistema, con las condiciones y excepciones previstas. El auditor comprueba que la estructura sea real, no meramente nominal, y que las decisiones estén documentadas.

11.4. Alcance, evidencia e informe

El alcance identifica sistemas, servicios, información, ubicaciones, infraestructuras, dependencias y proveedores. La documentación suele incluir política, categorización, declaración de aplicabilidad, análisis de riesgos, arquitectura, procedimientos, inventario, contratos, incidentes y auditorías técnicas. La auditoría material verifica la implantación mediante muestras y demostraciones.

El informe debe dictaminar el grado de cumplimiento, identificar hallazgos, describir criterios metodológicos, alcance, objetivo, datos, hechos y observaciones. Se presenta al responsable del sistema y al responsable de seguridad; este analiza y eleva conclusiones para la adopción de medidas correctoras. En sistemas de categoría ALTA, la gravedad puede justificar suspensión temporal del tratamiento, servicio u operación hasta subsanación o mitigación.

11.5. Hallazgos y plan de acciones correctivas

La guía CCN-STIC 802 estructura hallazgos en desviaciones, recomendaciones y puntos fuertes, con reglas específicas para certificación. El plan de acciones correctivas debe abordar desviaciones con causa, medida, responsable, plazo y evidencia. No basta con prometer una futura política; debe demostrarse que la acción elimina o reduce el riesgo y que se integra en operación.

La declaración o certificación de conformidad se publica en los portales o sedes según la instrucción técnica. La publicidad del distintivo no implica publicar el informe técnico completo, que puede contener información sensible. Transparencia y seguridad se concilian mediante versiones, disociación, límites legales y análisis de daño.

12. PARTICULARIDADES DE LA AUDITORÍA INFORMÁTICA EN LA ADMINISTRACIÓN PÚBLICA

12.1. Legalidad, servicio público y rendición de cuentas

En la Administración, el éxito no se mide únicamente por rentabilidad. Los sistemas deben servir al interés general, respetar competencia y procedimiento, garantizar derechos, continuidad, igualdad, accesibilidad y uso eficiente de fondos. La auditoría incorpora criterios de legalidad y buena administración. Una solución puede ser técnicamente rápida, pero inaceptable si impide trazabilidad del expediente, discrimina usuarios, vulnera conservación o elude contratación.

La rendición de cuentas amplía destinatarios: órganos de gobierno, intervención, fiscalización externa, autoridades de control, parlamentos, ciudadanía y órganos judiciales. No todos reciben el mismo detalle. La auditoría debe preservar información clasificada o sensible y, al mismo tiempo, permitir control democrático y transparencia mediante informes adecuados.

12.2. Control interno y externo

La Ley General Presupuestaria regula el control interno estatal y la auditoría pública ejercida por la IGAE. En Andalucía, la Intervención General ejerce control financiero conforme al texto refundido de la Ley General de la Hacienda Pública y su reglamento. La Cámara de Cuentas fiscaliza el sector público andaluz, y el Tribunal de Cuentas es el supremo órgano fiscalizador de cuentas y gestión económica del sector público. Estos controles pueden requerir auditoría de sistemas para confiar en datos, aplicaciones y controles que sustentan información financiera y de gestión.

La auditoría informática no sustituye la fiscalización económico-financiera. Puede apoyarla verificando controles de acceso, cambios, interfaces, integridad, trazabilidad y generación de informes. Una deficiencia tecnológica puede afectar estados contables, contratación, subvenciones o nóminas y adquirir relevancia más allá de TI.

12.3. Contratación y terceros

La Administración depende de contratistas, servicios cloud, mantenimiento y licencias. El artículo 2.3 del ENS extiende obligaciones a entidades privadas que prestan servicios o proveen soluciones al sector público en virtud de una relación contractual. La auditoría debe comprobar que los pliegos y contratos trasladan seguridad, continuidad, privacidad, niveles de servicio, auditoría, subcontratación, devolución, destrucción y salida.

El derecho de auditoría contractual debe ser practicable. Una cláusula genérica puede resultar inútil si no define acceso a evidencias, plazos, costes, terceros subcontratados y tratamiento de vulnerabilidades. Los informes de certificación del proveedor ayudan, pero se revisan alcance, periodo, excepciones y complementariedad con controles de la entidad. El modelo de responsabilidad compartida exige identificar qué controla cada parte.

12.4. Protección de datos, transparencia y archivo

El RGPD exige responsabilidad proactiva. La auditoría puede comprobar registro de tratamientos, legitimación, información, derechos, encargos, seguridad, brechas, evaluaciones de impacto y privacidad desde el diseño. El delegado de protección de datos supervisa cumplimiento y auditorías correspondientes. Las pruebas deben minimizar datos y evitar que el propio trabajo cree un repositorio innecesario de información personal.

La transparencia reconoce acceso a información pública, pero existen límites relativos a seguridad, datos, investigación, secreto y otros intereses protegidos. El informe debe prepararse pensando en posibles solicitudes: separar anexos técnicos, datos personales y vulnerabilidades facilita versiones publicables. El archivo y la gestión documental garantizan autenticidad, integridad, disponibilidad y conservación; también los papeles de auditoría tienen ciclo de vida y reglas de acceso.

12.5. Accesibilidad e interoperabilidad

El Real Decreto 1112/2018 establece revisión, seguimiento y presentación de informes sobre accesibilidad de sitios y aplicaciones móviles del sector público. La auditoría no se limita a ejecutar una herramienta automática, porque muchos criterios requieren revisión manual, pruebas con tecnologías de apoyo y análisis de procesos de publicación. Se comprueban declaración de accesibilidad, canal de comunicación, revisiones y corrección.

El Esquema Nacional de Interoperabilidad y sus normas técnicas aportan criterios sobre documento y expediente electrónico, firma, copiado, digitalización, política de gestión documental y estándares. La auditoría debe evaluar interoperabilidad organizativa, semántica y técnica, así como conservación en el tiempo. Un intercambio que funciona técnicamente puede ser insuficiente si pierde significado o evidencia.

12.6. Restricciones y potestades

El acceso del auditor se ejerce dentro de competencias y con garantías. Pueden existir secreto profesional, información clínica, datos tributarios, investigaciones, seguridad nacional o contratación confidencial. La negativa injustificada es una limitación; la restricción legal legítima exige procedimientos seguros, equipos habilitados o evidencia alternativa. La documentación debe registrar limitaciones y efecto sobre la conclusión.

13. APLICACIÓN AL SECTOR SANITARIO PÚBLICO Y AL SAS

13.1. Riesgo clínico y datos de salud

En el SAS, la auditoría informática debe comprender que la tecnología forma parte del proceso asistencial. La indisponibilidad de una historia clínica, una cola de laboratorio bloqueada, una identidad duplicada o una configuración errónea puede alterar decisiones. El impacto se valora en confidencialidad, integridad y disponibilidad, pero también en seguridad del paciente, continuidad de cuidados, tiempos y capacidad de trazabilidad.

Los datos de salud son categoría especial. Deben revisarse perfiles por función, necesidad de conocer, altas y bajas, cuentas privilegiadas, accesos de emergencia, consultas masivas, exportaciones, sesiones, dispositivos y trazabilidad. Un acceso técnicamente autenticado puede ser ilegítimo si no existe relación asistencial o función. La auditoría combina controles preventivos con análisis retrospectivo.

13.2. Auditoría de accesos y trazabilidad

Los logs deben permitir atribución suficiente: identidad, fecha y hora, sistema, operación, recurso y resultado, según diseño y obligaciones. No existe un plazo universal del ENS expresado en años para todos los registros; la conservación se establece según riesgo, finalidad, normativa y política, evitando tanto destrucción prematura como retención indiscriminada. La integridad, sincronización y control de acceso a logs son esenciales.

Los accesos de emergencia o break glass pueden ser necesarios cuando el rol ordinario impediría atender una situación urgente. Deben quedar justificados, registrados, alertados y revisados. Si se convierten en vía habitual para evitar la gestión de permisos, el control pierde su carácter excepcional. La auditoría analiza frecuencia, usuarios, motivos, pacientes, horarios y revisión.

13.3. Interoperabilidad clínica

Sistemas como Diraya se relacionan con laboratorio, radiología, farmacia, citación, identificación y otros servicios. La auditoría de interfaces revisa estándares y perfiles aplicables, colas, confirmaciones, reintentos, duplicados, transformación, códigos, unidades y conciliación. HL7, FHIR, CDA, DICOM o terminologías aportan criterios, pero la conformidad nominal no garantiza una integración correcta.

Debe probarse el ciclo completo: origen, mensaje, transporte, validación, destino, respuesta y manejo de error. Los mensajes rechazados necesitan responsables y alertas; los reenvíos deben evitar duplicados; las transformaciones deben preservar significado. El linaje del dato permite conocer de dónde procede y qué cambios sufrió.

13.4. Continuidad y ciberresiliencia

La continuidad se diseña alrededor de servicios asistenciales y administrativos, no solo servidores. El análisis de impacto identifica procesos, dependencias, tiempos máximos y procedimientos degradados. Se auditan redundancia, copias, restauración, recuperación, comunicaciones, energía, personal, proveedores y ejercicios. Un plan no probado ofrece poca confianza.

Los ejercicios deben generar evidencia y acciones. Puede realizarse una prueba técnica, de mesa o integral según riesgo. Se comprueba si los profesionales conocen alternativas, cómo se registran actuaciones durante caída y cómo se reconcilian al restaurar. La ciberresiliencia añade detección, contención y recuperación ante ataques, incluyendo copias protegidas y credenciales de emergencia.

13.5. Proveedores, cloud y dispositivos

Las soluciones sanitarias pueden incluir cloud, soporte remoto, equipamiento conectado y software de fabricante. La auditoría revisa inventario, versiones, parches, accesos del proveedor, segmentación, certificados, mantenimiento, fin de soporte y responsabilidades. En dispositivos médicos conectados, los cambios deben coordinar seguridad y validación clínica; una actualización técnicamente recomendable puede requerir pruebas y autorización.

Los contratos deben contemplar incidentes, disponibilidad, recuperación, portabilidad, subencargados, ubicación, auditorías y salida. La dependencia de conocimiento del proveedor es un riesgo. Se evalúan documentación, código o mecanismos de continuidad, exportación de datos, formación y capacidad de transición.

13.6. Casos prácticos de auditoría en el SAS

Estos ejemplos deben adaptarse al alcance real. No procede afirmar categorías ENS concretas de sistemas sin la categorización aprobada. El auditor utiliza documentación oficial del sistema y evita inferir que todo sistema sanitario es automáticamente de categoría ALTA; la categoría se determina conforme al impacto en las dimensiones del ENS.

14. INFORME, HALLAZGOS, ACCIONES CORRECTIVAS Y SEGUIMIENTO

14.1. Estructura del hallazgo

Un hallazgo útil describe criterio, condición, causa, consecuencia o riesgo y acción. El criterio identifica la norma, política, contrato o control esperado. La condición explica la realidad con alcance y evidencia. La causa evita tratar síntomas. La consecuencia traduce el efecto sobre objetivos. La recomendación o acción propuesta debe ser proporcional y dejar margen a la dirección para elegir el tratamiento, salvo requisito prescriptivo.

La redacción debe ser precisa, neutral y comprensible. «La seguridad es deficiente» no es verificable. Es mejor indicar que determinadas cuentas conservaban privilegios tras el cese, especificar población, periodo, criterio y riesgo. Los nombres personales se limitan a anexos restringidos cuando sean necesarios.

14.2. Clasificación y prioridad

Las escalas pueden usar crítico, alto, medio y bajo; no conformidad mayor o menor; desviación y recomendación. No existe una equivalencia universal. La metodología define criterios de impacto, probabilidad, extensión, urgencia y obligación. La prioridad no debe negociarse por conveniencia. La respuesta de la dirección puede aceptar, mitigar, evitar o transferir riesgo, pero la valoración del auditor conserva independencia.

Un hallazgo crítico requiere comunicación inmediata y puede justificar medidas temporales. Muchos hallazgos menores con causa común pueden constituir un problema sistémico. La reincidencia aumenta severidad porque demuestra ineficacia del seguimiento o tolerancia no autorizada.

14.3. Contenido del informe

El informe incluye destinatarios, objetivo, alcance, periodo, criterios, metodología, limitaciones, conclusión, resumen ejecutivo, hallazgos, respuestas y anexos. Debe diferenciar hechos, juicio y manifestaciones de la dirección. La conclusión responde a los objetivos; no es un resumen de observaciones. Si el alcance fue limitado, se explica cómo afecta.

14.4. Plan de acción

La respuesta de gestión identifica acción, responsable, fecha y recursos. Las fechas deben considerar riesgo, dependencias y contratación. Las medidas provisionales reducen exposición mientras llega la solución definitiva. El auditor evalúa si el plan aborda causa y riesgo; no asume su ejecución.

Un plan puede cerrarse por implantación, aceptación formal del riesgo, sustitución del sistema o desaparición del objeto. «En progreso» no es evidencia. El seguimiento solicita pruebas y, para hallazgos relevantes, repite controles. Si una política fue aprobada pero no aplicada, el hallazgo no se cierra.

14.5. Seguimiento y escalado

La frecuencia de seguimiento depende de severidad. Las acciones vencidas se comunican a responsables y órgano de gobierno. Cuando la dirección acepta un riesgo que el responsable de auditoría considera fuera de tolerancia, se discute y eleva. El auditor no obliga operativamente, pero garantiza que la decisión sea tomada por quien tiene autoridad y visibilidad.

El sistema de seguimiento debe conservar historial, cambios de fecha, evidencia, validación y cierre. Los indicadores de mora y reincidencia permiten detectar áreas donde las recomendaciones no se traducen en mejora. La transparencia interna sobre retrasos es parte del valor de auditoría.

15. AUDITORÍA CONTINUA, ANALÍTICA DE DATOS Y RETOS EMERGENTES

15.1. Auditoría continua y monitorización continua

La monitorización continua pertenece principalmente a gestión y segunda línea: observa controles y riesgos de forma recurrente. La auditoría continua es el uso frecuente o automatizado de procedimientos de aseguramiento por la tercera línea. Pueden compartir datos, pero conservan responsabilidades. Si auditoría configura y opera alertas que luego audita, compromete independencia.

Los casos adecuados incluyen usuarios incompatibles, cambios sin autorización, cuentas huérfanas, accesos anómalos, transacciones duplicadas, SLA incumplidos o copias fallidas. Las reglas deben validarse, mantener versiones y controlar falsos positivos. Un cuadro de mando sin procesos de respuesta no constituye control efectivo.

15.2. Analítica avanzada

La analítica permite pasar de muestras a poblaciones completas, identificar patrones y priorizar investigación. Se pueden aplicar estadística, minería de procesos, análisis de grafos y modelos de detección. Sin embargo, la calidad, el sesgo y el linaje condicionan resultados. El auditor debe documentar fuentes, transformaciones, parámetros, umbrales y validación.

La minería de procesos reconstruye secuencias a partir de logs y las compara con el proceso esperado. Puede descubrir saltos de aprobación, reprocesos o variantes. Los grafos ayudan a detectar relaciones entre usuarios, proveedores y transacciones. Estas técnicas generan indicios, no culpabilidad; requieren corroboración y respeto a derechos.

15.3. Inteligencia artificial

La IA puede asistir en clasificación, análisis de documentos y anomalías, pero introduce riesgos de opacidad, error, confidencialidad y automatización del sesgo. Si se utiliza en auditoría, se protege la información, se valida el modelo, se mantiene supervisión humana y se documentan limitaciones. No debe enviarse evidencia sensible a servicios no autorizados.

Al auditar sistemas de IA se examinan propósito, gobierno, datos, calidad, sesgo, seguridad, explicabilidad, supervisión, monitorización y cambios. La conclusión debe distinguir rendimiento técnico de legalidad y utilidad. Un modelo preciso en promedio puede fallar en subgrupos o degradarse con el tiempo.

15.4. Cloud, DevSecOps y cadenas de suministro

En cloud, el auditor revisa responsabilidad compartida, configuración, identidades, registros, cifrado, resiliencia, ubicación, subcontratación y salida. Las certificaciones del proveedor son evidencia, no garantía total. En DevSecOps se evalúan repositorios, ramas, revisiones, dependencias, secretos, integración continua, artefactos, despliegues e infraestructura como código. La velocidad exige controles automatizados y trazables.

La cadena de suministro de software incluye bibliotecas, imágenes, repositorios y servicios. Se auditan inventario de componentes, origen, vulnerabilidades, firmas, actualizaciones y respuesta. Un proveedor pequeño puede tener acceso privilegiado a sistemas críticos; el riesgo no depende solo del valor del contrato.

15.5. Competencia y actualización

La rápida evolución exige aprendizaje. ISO 19011 cambió en 2026; ITAF ya dispone de quinta edición; las guías CCN-STIC se actualizan; tecnologías y amenazas evolucionan. El programa de competencias identifica brechas, formación y especialistas. La actualización no consiste en memorizar productos, sino en comprender principios y verificar versiones.

16. MAPA CONCEPTUAL E IDEAS CLAVE

16.1. Distinciones esenciales

• Auditoría frente a consultoría: la primera asegura y concluye; la segunda aconseja o diseña.
• Diseño frente a operación: un control puede ser adecuado y no ejecutarse, o ejecutarse y no cubrir el riesgo.
• Cumplimiento frente a técnica: una verifica requisitos; la otra prueba eficacia técnica directa.
• Independencia frente a objetividad: posición de la función frente a actitud y conflicto individual.
• Suficiencia frente a adecuación: cantidad de evidencia frente a relevancia y fiabilidad.
• Auditoría ordinaria ENS frente a extraordinaria: bienal frente a cambios sustanciales.
• Categoría BÁSICA frente a MEDIA/ALTA: autoevaluación para declaración frente a auditoría para certificación.

16.2. Errores típicos

• Creer que la auditoría garantiza ausencia de errores o ataques.
• Considerar que una certificación cubre cualquier sistema o periodo sin revisar alcance.
• Confundir un pentest con una auditoría completa.
• Afirmar plazos de conservación de logs no establecidos por norma aplicable.
• Asignar categoría ENS a un sistema solo por contener datos sensibles.
• Cerrar hallazgos con documentación sin probar funcionamiento.
• Permitir que auditoría diseñe y opere controles que luego asegura.