2. Cumplir no es tener papeles¶
2.1. ¿De qué va este tema?¶
Tener una política, un contrato y una carpeta de procedimientos no demuestra que cumplamos. ¿Se aplican? ¿Funcionan? ¿Cómo lo sabemos? Vamos a conectar obligaciones, riesgos, controles y evidencias para que los documentos reflejen una forma real de trabajar.
Vamos a seleccionar obligaciones, pensar qué puede fallar, decidir cómo evitarlo y comprobar el resultado. El recorrido será siempre parecido: organización → obligaciones → riesgos → controles → evidencias → revisión.
Este tema tiene una duración estimada de 12 horas.
2.2. Clases¶
2.2.1. Perímetro regulatorio y aplicabilidad¶
¿Qué reglas nos afectan de verdad?
Antes de buscar leyes, describe la organización. «Es una empresa informática» dice muy poco sobre sus obligaciones.
Actividad y servicios: ¿vende equipos, administra sistemas, aloja datos?
Clientes y destinatarios: ¿particulares, otras empresas, sector público?
Información y tecnología: ¿qué datos trata y qué sistemas usa para prestar cada servicio?
Sector, tamaño y contratos: pueden cambiar qué requisitos resultan aplicables.
Límites: distingue hechos confirmados de información que falta. Un servicio a un ayuntamiento no convierte automáticamente toda la empresa en un sistema del mismo alcance.
No todas las fuentes cumplen la misma función.
Norma jurídica: establece reglas dentro de su ámbito. Buscamos el texto y sus modificaciones en fuentes oficiales como el BOE o EUR-Lex.
Jurisprudencia y resoluciones judiciales: permiten conocer cómo interpretan los tribunales el Derecho. Hay que leer qué cuestión resuelven y con qué hechos; no convertir cualquier frase de una sentencia en una regla universal.
Guía: ayuda a interpretar o aplicar. Su utilidad técnica no la convierte automáticamente en una obligación del mismo rango que la norma.
Comentario o noticia: puede orientarnos hacia una fuente, pero conviene comprobar en ella la afirmación que nos interesa.
Leer una norma sin perderse.
Objeto y ámbito: qué regula, a quién y a qué sistemas o actividades afecta.
Vigencia y aplicación: cuándo entra en vigor, desde cuándo se exige una obligación y si existen plazos transitorios. Publicación y exigibilidad no siempre coinciden.
Versión: comprobar modificaciones y la fecha de actualización. El texto consolidado del BOE facilita la lectura, pero es informativo; para fundamentar una conclusión jurídica se contrasta la publicación oficial.
Rango y competencia: una regla interna no puede contradecir una ley. Entre normas estatales y autonómicas también importa quién tiene competencia; no todo se resuelve diciendo que una «está por encima» de otra.
Derecho de la UE: su primacía opera en su ámbito de aplicación. Un reglamento y una directiva tienen mecanismos diferentes: para aplicar NIS2 a una entidad en España hay que revisar también el marco nacional vigente.
Del texto a un inventario pequeño. Una fila útil contiene:
Hecho de la organización que activa la consulta.
Fuente, disposición concreta y versión consultada.
Obligación o cuestión por verificar, expresada con tus palabras.
Servicio o sistema afectado y función responsable.
Estado: confirmado o pendiente, con el dato que falta.
Ejemplo: «El sistema municipal gestiona expedientes electrónicos» → ENS, artículos 2 y 12 → política de seguridad para su ámbito → sistema de expedientes → aprobación por el órgano competente. El enlace general a una ley, sin explicar qué tiene que hacer la organización, deja el trabajo a medias.
Para hacer
Considera estas tres organizaciones ficticias:
Una pyme de reparación de ordenadores que presta servicios solo a particulares.
Un ayuntamiento con un sistema de expedientes electrónicos.
Una empresa que declara prestar servicios de distribución de electricidad; todavía no conocemos su tamaño ni su estructura societaria.
Consulta solo los apartados 1 y 3 del ámbito del ENS. ¿Qué puedes afirmar sobre las dos primeras organizaciones con los datos disponibles?
En NIS2, localiza el sector de energía del anexo I. Para la tercera, ¿basta con encontrar ese sector para cerrar la aplicabilidad?
Escribe una fila del inventario para el ayuntamiento y otra, marcada como pendiente, para la empresa eléctrica. Incluye el dato que falta y quién debería ayudar a comprobarlo.
La actividad digital abre otras preguntas. Para acotar la búsqueda:
Si la empresa vende servicios por una web, revisaremos la LSSI-CE y qué obligaciones de información o contratación corresponden a esa actividad.
Si distribuye software, imágenes o documentación, revisaremos propiedad intelectual y licencias. Poder descargar un archivo no demuestra permiso para incorporarlo a un producto.
Si usa firmas electrónicas o servicios de confianza, revisaremos eIDAS y el tipo de servicio o firma, sin suponer que todas las firmas son equivalentes.
Aquí basta con saber qué hecho lleva a qué consulta. El inventario debe crecer por necesidades justificadas, no por acumular nombres de leyes.
Una sentencia también puede orientar una decisión técnica.
En la sentencia C-340/21 del TJUE, de 14 de diciembre de 2023, se estudia un ciberataque a la administración tributaria búlgara que expuso datos personales. Entre otras cuestiones, el tribunal interpreta los artículos 24 y 32 del RGPD.
En los apartados 29 a 32 explica que el incidente no demuestra por sí solo que las medidas fueran inapropiadas: hay que examinarlas en su contexto.
Los apartados 45 a 47 conectan esa valoración con la naturaleza de las medidas, su aplicación y su efecto práctico frente a los riesgos.
Es una interpretación sobre seguridad del tratamiento de datos personales. No equivale a certificar cumplimiento del ENS ni a exonerar automáticamente de responsabilidad a cualquier organización atacada.
Para hacer
Lee únicamente los apartados indicados de la sentencia.
Corrige estas conclusiones: «Si hubo ataque, las medidas eran necesariamente inadecuadas» y «Si atacó un tercero, no tenemos que justificar nuestras medidas».
Propón dos evidencias técnicas que ayudarían a examinar cómo se aplicaron los controles antes del incidente. Explica qué demostraría cada una.
Ya tenemos fuentes y obligaciones seleccionadas. Ahora necesitamos una forma de gestionarlas que no dependa de recordar cada una de memoria.
2.2.2. Modelo de gestión actualizado¶
¿Cómo hacemos que cumplir no dependa de acordarnos?
Un sistema de gestión conecta decisiones, trabajo y revisión. No es una aplicación informática ni una carpeta de plantillas.
Contexto: qué hace la organización y qué condiciona su trabajo.
Partes interesadas: personas y entidades cuyas necesidades debemos considerar, como usuarios, clientes, personal, proveedores o autoridades. Una expectativa no es automáticamente una obligación legal.
Alcance: servicios, procesos y sistemas que incluimos. Debe ser explícito y no servir para ocultar dependencias o eludir obligaciones aplicables.
Liderazgo y recursos: quién decide, quién ejecuta y con qué medios.
Objetivos y operación: resultados buscados y actuaciones para lograrlos.
Evaluación y mejora: comprobar resultados y cambiar lo que no funciona.
Ejemplo: las bajas de proveedores.
Contexto: varias empresas realizan mantenimiento remoto.
Alcance: cuentas y permisos de esos proveedores en los sistemas administrados.
Objetivo interno: retirar todos sus accesos cuando termine la autorización.
Operación: comunicar la fecha, ejecutar la baja y comprobar el resultado.
Evaluación: comparar las bajas debidas con las realizadas a tiempo.
Mejora: si los avisos llegan tarde, corregir la comunicación y volver a comprobar.
El objetivo necesita responsable, criterio de cumplimiento y momento de revisión. «Mejorar la seguridad» no permite saber si hemos terminado.
Para hacer
Una empresa propone «cumplir toda la normativa» como único objetivo. Concreta uno sobre las bajas de proveedores, indicando responsable y comprobación.
Hay un procedimiento, pero nadie tiene tiempo asignado para revisar sus resultados. ¿Qué elemento del sistema falta?
Un cliente pide un informe diario. ¿Es necesariamente una obligación legal? ¿Dónde comprobarías si hay un compromiso que debamos atender?
Referencias que ayudan a organizar el sistema.
ISO 19600:2014 es un antecedente de directrices de gestión del cumplimiento, retirado. La referencia que lo sustituye es ISO 37301:2021, de requisitos con orientación para su uso; su ficha oficial recoge también la enmienda de 2024 sobre cambio climático.
Utilizaremos la información pública del catálogo para conocer su finalidad. El esquema de esta clase es una explicación didáctica, no una reproducción de cláusulas ni una lista suficiente para certificar un sistema.
ENS y NIS2 aportan requisitos en su ámbito. Un modelo de gestión ayuda a organizarlos, pero no sustituye su análisis ni garantiza cumplirlos.
Conviene distinguir:
Obligación legal: exigencia aplicable a la entidad o actividad.
Adopción voluntaria: decisión de utilizar una referencia de gestión.
Certificación: evaluación de conformidad respecto de requisitos y dentro de un alcance; no es una garantía de ausencia de incumplimientos.
Proporcionado no significa improvisado.
Una pyme puede usar un registro sencillo, responsables identificados y revisiones breves integradas en su trabajo habitual.
Una entidad pública con varios servicios puede necesitar coordinación entre unidades y un circuito formal de aprobación y seguimiento.
En ambos casos deben poder responder a las mismas preguntas: qué se exige, quién actúa, cómo se comprueba y qué ocurre cuando se detecta un fallo.
El tamaño no es el único factor: un equipo pequeño puede prestar un servicio de gran impacto y necesitar controles exigentes.
Para hacer
Propón dos recomendaciones para una pyme de soporte con seis personas y para un ayuntamiento con varias unidades. Una debe servir a ambos; la otra debe adaptarse a su organización. Explica el motivo.
«Tenemos un certificado, por tanto no necesitamos revisar las obligaciones nuevas». ¿Qué falla en el razonamiento?
Organizar el trabajo no basta para priorizarlo. Necesitamos entender qué puede fallar y con qué consecuencias.
2.2.3. Riesgos de cumplimiento¶
¿Qué puede salir mal y qué atendemos primero?
Formula el escenario antes de ponerle un número. El riesgo expresa el efecto de la incertidumbre sobre objetivos. Aquí nos centramos en escenarios que pueden impedir cumplir obligaciones y compromisos.
Causa: las bajas de personal externo no llegan al equipo técnico.
Evento: alguien cuyo servicio terminó utiliza una cuenta que sigue activa.
Consecuencia: acceso no autorizado, exposición de información e incumplimiento del compromiso de limitar el acceso al personal autorizado.
Propietario del riesgo: función con responsabilidad y capacidad para coordinar su tratamiento; en este ejemplo, el responsable del servicio con apoyo de sistemas y seguridad.
Controles existentes: qué se hace realmente para prevenir, detectar o responder. Una propuesta de control no cuenta todavía como protección implantada.
«Hackeo», «multa» o «falta de seguridad» no describen por sí solos un escenario que permita decidir una actuación.
Identificar, analizar y evaluar son pasos distintos.
Identificar: describir el escenario y la obligación afectada.
Analizar: valorar probabilidad, consecuencias y controles.
Evaluar: comparar el resultado con criterios para decidir prioridades.
ISO 31000:2018 ofrece directrices de gestión del riesgo; no es una norma certificable. El análisis y gestión de riesgos del ENS exige justificar las medidas y su proporcionalidad. Ninguna de esas referencias nos obliga a usar la pequeña escala del ejercicio que sigue.
Para hacer
Reformula «riesgo de multa» como causa, evento y consecuencia para un contrato que exige retirar accesos de proveedores al finalizar el servicio.
Distingue control existente y propuesta: «revisamos cada viernes las cuentas activas» y «el próximo mes queremos automatizar las bajas». ¿Qué evidencia pedirías para confirmar la primera afirmación?
Una escala sencilla para practicar. Valoraremos la posibilidad de que el evento ocurra durante los próximos doce meses. Los niveles son orientativos del ejercicio, no probabilidades estadísticas ni categorías del ENS.
Criterios de valoración del ejercicio¶ Nivel
Probabilidad
Impacto: considerar servicio, personas y obligaciones
1
Exposición poco frecuente y condiciones difíciles de reunir, justificadas con los datos del escenario.
Efecto limitado, recuperable y sin perjuicio relevante para personas ni compromisos esenciales del servicio.
2
Exposición periódica y un evento plausible, aunque no habitual.
Interrupción o perjuicio apreciable que requiere intervención y afecta a compromisos del servicio.
3
Exposición frecuente y condiciones facilitadoras o fallos repetidos.
Afección grave a personas, información sensible o continuidad de un servicio crítico.
Como ayuda para ordenar, calculamos P × I: 1–2, prioridad ordinaria; 3–4, atención preferente; 6–9, atención urgente. Son umbrales didácticos.
Si varias consecuencias tienen niveles distintos, usamos la más grave razonablemente sustentada y anotamos el motivo.
El resultado orienta una decisión, no la sustituye. Un 3 por impacto grave merece estudiar esa gravedad, aunque otro escenario también puntúe 3.
Faltar datos no significa probabilidad baja. Registra la incertidumbre y qué necesitas averiguar. Una obligación exigible no desaparece por puntuar poco.
Inherente, residual y previsto. Para este ejercicio:
Inherente: valoración sin considerar los controles específicos del escenario.
Residual actual: lo que permanece considerando controles implantados cuya eficacia podemos justificar.
Residual previsto: estimación tras una mejora aún pendiente. Debe comprobarse cuando se implante; no se presenta como resultado conseguido.
Ejemplo resuelto: hay rotación frecuente de técnicos externos y antecedentes de cuentas olvidadas. Sin controles específicos, estimamos P=3 e I=2: resultado 6. Un circuito de avisos y verificación, probado y revisado, permite justificar P=1. Si un acceso indebido aún puede causar el mismo daño, I sigue en 2: residual 2. No hemos «restado puntos por tener una herramienta»: hemos explicado qué cambia.
Para hacer
Dos organizaciones tienen la misma exposición frecuente a cuentas de terceros no retiradas y antecedentes de fallos. Usa P=3 para ambas, sin controles específicos.
En una pyme, esas cuentas permiten cambiar configuraciones de soporte y provocar interrupciones apreciables a clientes, recuperables con intervención.
En una entidad sanitaria, permiten acceder a historias clínicas y afectar a información sensible y a la atención a pacientes.
Asigna impacto y calcula la prioridad en ambas. Justifica la diferencia.
Se propone una baja automática todavía no instalada. ¿Puedes reducir ya el residual actual? ¿Qué tendrías que comprobar tras implantarla?
Un compañero cambia simultáneamente P e I a 1 «porque hay doble factor». ¿Por qué no basta esa explicación para una cuenta que conserva permisos indebidos?
Tratar y seguir el riesgo.
Reducir: mejorar avisos, bajas y comprobaciones.
Evitar: dejar de realizar una actividad o eliminar un acceso innecesario.
Compartir: distribuir determinadas consecuencias mediante contratos o seguros; no desaparecen todas las obligaciones ni responsabilidades propias.
Aceptar: decisión justificada por quien tiene autoridad, dentro de los límites aplicables. Aceptar un riesgo no autoriza a incumplir la ley.
Registrar actuación, responsable, fecha objetivo, recursos y revisión. Si cambian el servicio, los proveedores o las obligaciones, hay que reevaluar.
Un mapa de riesgos sirve para decidir y actuar. En la siguiente clase veremos cómo dejar constancia de ese recorrido sin generar papeles que nadie utiliza.
2.2.4. Documentación, evidencias y trazabilidad¶
¿Cómo demostramos que el control funciona?
Documenta para poder trabajar y comprobar. Recupera la diferencia entre política, procedimiento, instrucción y registro del tema anterior.
Un índice inicial puede reunir: alcance y responsables; inventario de obligaciones; registro de riesgos; políticas y procedimientos; evidencias; revisiones y acciones correctoras.
No exige un archivo para cada elemento. Una herramienta de incidencias puede contener solicitudes, autorizaciones y comprobaciones, si permite recuperarlas y protegerlas adecuadamente.
Cada documento necesita propietario, aprobación cuando corresponda, versión y fecha. Debe poder distinguirse la versión aplicable de una obsoleta.
Define acceso y conservación según finalidad y obligaciones. Guardarlo todo para siempre o permitir que cualquiera lo modifique no mejora la evidencia.
Un mapa documental explica dónde encontrar cada cosa.
Ejemplo reducido¶ Elemento
Gestión
Acceso y conservación
Procedimiento de bajas, versión 2
Propietario: servicio; aprobación: función competente; fecha de vigencia.
Consulta por personal implicado; versiones anteriores identificadas.
Registros de bajas
Sistemas registra ejecución; supervisión documenta la comprobación.
Acceso limitado por función; plazo justificado según finalidad y obligaciones.
Registro de revisión
Responsable del servicio documenta resultados, decisiones y seguimiento.
Disponible a quienes deciden o ejecutan acciones; integridad protegida.
Un plazo de conservación es un dato que hay que justificar, no un número universal que podamos copiar para todos los registros.
Para hacer
Hay dos archivos llamados «procedimiento definitivo», sin fecha, y se usan instrucciones diferentes. Define los campos mínimos para corregir el problema.
El registro de bajas es editable por cualquier usuario y contiene contraseñas. Propón dos cambios y explica qué mejoran.
Para practicar, escribe un índice de cinco elementos que permita encontrar la obligación, el riesgo, el procedimiento, la evidencia y la revisión.
Trazabilidad: una obligación debe llegar hasta una comprobación.
Recorrido resuelto de una obligación contractual ficticia¶ Pieza
Contenido
Obligación
El contrato de soporte exige retirar accesos al terminar la autorización.
Riesgo
Un aviso tardío deja una cuenta disponible para un uso no autorizado.
Control
Aviso con fecha efectiva, ejecución de baja y comprobación de cuentas afectadas.
Responsables
Servicio comunica y coordina; sistemas ejecuta; supervisión comprueba.
Evidencia
Aviso, autorización, fecha efectiva, registro de ejecución y resultado de revisión.
Seguimiento
Revisar las bajas previstas frente a las ejecutadas y corregir diferencias.
El contrato ficticio es la fuente concreta de este ejemplo. El enfoque de control y revisión se relaciona con ENS y NIS2, sin atribuirles un plazo universal de bajas ni la periodicidad interna elegida.
Un registro de inicio de sesión muestra una actividad, pero no demuestra por sí solo que estuviera autorizada. Necesitamos poder relacionar ambas cosas.
La existencia de una copia tampoco demuestra que podamos restaurarla. Una prueba registrada debe indicar qué se recuperó, cómo y con qué resultado.
Para hacer
Un contrato ficticio exige poder recuperar la configuración de los equipos administrados. Hay copias, pero nunca se ha probado una restauración.
Completa un recorrido como el anterior: obligación, riesgo, control, responsables, evidencia y seguimiento. Basta una frase por elemento.
La pantalla de la herramienta dice «copia correcta». ¿Qué demuestra y qué falta comprobar para responder al compromiso contractual?
Un indicador permite comparar un resultado con un objetivo.
Para las bajas, un indicador posible es:
Bajas realizadas a tiempo / bajas que debían realizarse en el periodo × 100.
Define periodo, fuente de datos, responsable de cálculo y tratamiento de excepciones. Si no hubo bajas debidas, registra «no aplicable», no un 100 % ficticio. Si faltan datos, indica «no verificable» y completa la comprobación.
Ejemplo: debían ejecutarse 10 bajas; 8 fueron puntuales, una tardía y otra sigue pendiente. El resultado es 80 %, no 8/9: la pendiente también cuenta.
Contar cuántas revisiones hicimos mide actividad. Saber cuántos accesos indebidos detectamos y corregimos ayuda a valorar resultados. Un único porcentaje puede ocultar un caso especialmente grave.
Revisión y acción correctora.
Corrección: resolver el fallo encontrado; retirar la cuenta pendiente.
Análisis de causa: averiguar por qué el aviso o la ejecución fallaron.
Acción correctora: cambiar el proceso para reducir la repetición.
Comprobación de eficacia: observar si la mejora funciona, no solo si se instaló.
La dirección o la función competente revisa resultados y decide recursos y prioridades. Un registro breve debe conservar dato, decisión, responsable, fecha objetivo y comprobación posterior.
Para hacer
Este mes vencieron 12 autorizaciones de acceso: 9 bajas se ejecutaron a tiempo, 2 tarde y 1 sigue pendiente. Los tres fallos se relacionan con avisos que llegaron después de la fecha efectiva. El objetivo interno era que todas fueran puntuales.
Calcula el indicador y explica la desviación. ¿Por qué no debes excluir la pendiente?
Distingue una corrección inmediata y una acción correctora sobre el proceso.
Redacta un registro de revisión de cinco líneas: resultado, decisión, responsable, plazo propuesto y cómo comprobar la eficacia el mes siguiente.
El mes siguiente se hacen todas las bajas puntualmente, pero no se incluyen las cuentas de una subcontrata en el inventario. ¿Puedes afirmar que el sistema funciona?
El sistema debe permitir reconstruir decisiones y detectar fallos. La siguiente clase reúne las piezas para comprobar que no estamos diseñando documentos aislados.
2.2.5. Diseño del sistema de cumplimiento¶
¿Encaja todo o solo tenemos documentos sueltos?
Sigue un recorrido completo. Para el servicio de soporte del ejemplo:
Describimos alcance, clientes, sistemas y terceros.
Identificamos la exigencia contractual de retirar accesos.
Valoramos un uso indebido de cuentas no retiradas y justificamos la prioridad.
Asignamos avisos, ejecución, comprobación y recursos.
Conservamos evidencias y calculamos el indicador con todas las bajas debidas.
Revisamos desviaciones, corregimos causas y verificamos las mejoras.
Comprueba que cada pieza sostiene la siguiente.
Un enlace a una ley no sustituye explicar su relación con el caso.
Un número de riesgo no sustituye describir el escenario y justificarlo.
Un control comprado no equivale a un control implantado y eficaz.
Un documento sin responsable ni uso no mantiene el sistema.
Un porcentaje sin alcance o fuente fiable no demuestra cumplimiento.
Para hacer
Una pyme presenta este diseño: «NIS2 se aplica porque tenemos web; el riesgo de acceso indebido es bajo porque hemos comprado una herramienta; sistemas revisará cuando pueda; guardaremos una captura de pantalla y dirección verá si todo va bien a final de año».
Señala cuatro debilidades y propone una corrección breve para cada una.
Si el mismo servicio administra información clínica, ¿qué tendrías que reconsiderar? No necesitas elaborar otro sistema completo.
Un sistema pequeño puede ser riguroso. Lo importante es poder explicar por qué elegimos cada medida, quién la aplica y cómo sabemos que funciona.
Test de autoevaluación
Test disponible el 31 de Octubre (o antes).
Actividad final integradora
Disponible el 31 de Octubre (o antes)