Preparar un mapa de riesgos de datos industriales

Un mapa de riesgos de datos industriales debe explicar qué decisión puede fallar, por qué dato y bajo qué condición. Una lista de sistemas con colores no basta. Dirección necesita ver la relación entre una señal, su transformación, el uso operativo y el control que permite aceptar, reducir o investigar la exposición.

No empiece por la tecnología. Empiece por la pregunta que alguien intenta responder: comprometer capacidad, mover una orden, comparar plantas, aprobar una intervención o explicar una desviación. Después reconstruya qué datos sostienen esa decisión y dónde pueden perder significado.

Preparar el mapa exige relacionar cada decisión con la fuente, el objeto, la ventana, la transformación, el fallo observable, el control y el propietario; una valoración sin evidencia queda como hipótesis. NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. El programa de NIST no valida el mapa de una planta ni fija su prioridad.

El resultado es un instrumento de gobierno para dirección. No sustituye una evaluación de ciberseguridad, una auditoría técnica ni una investigación causal.

1. Definir la decisión expuesta

Escriba la decisión en términos observables. “Mejorar los datos” es demasiado amplio. “Liberar el plan de mañana con la capacidad disponible registrada a las 14:00” permite identificar objeto, corte, población y autoridad.

Anote quién decide, quién prepara la evidencia y quién puede corregir el origen. Una sola persona puede ocupar más de un rol, pero las responsabilidades deben quedar separadas.

Defina el horizonte. Un dato con una hora de retraso puede ser útil para una revisión mensual y peligroso para una reasignación durante el turno.

Conecte el mapa con el linaje de fuentes para el informe de producción. El mapa no debe volver a inventar la procedencia.

2. Separar objeto, atributo y registro

No trate “el dato de producción” como una unidad. Separe orden, operación, activo, producto, lote, turno, cantidad, duración, estado y marca temporal.

Un mismo riesgo puede afectar solo a un atributo. Una orden bien identificada puede tener una fecha obsoleta o una cantidad expresada en otra unidad.

Registre el identificador utilizado en cada capa. Si ERP, MES y OT usan claves distintas, documente la correspondencia y su propietario.

Evite agregar antes de revisar. Un total diario puede ocultar registros duplicados, poblaciones incompletas o asignaciones a la entidad equivocada.

3. Dibujar la ruta del dato

Para cada objeto, muestre origen, transporte, almacenamiento, transformación, consulta y salida. Incluya sistemas intermedios aunque no aparezcan en el informe.

Anote qué ocurre en cada tramo: conversión de unidad, unión de tablas, redondeo, filtrado, clasificación, imputación o cambio de zona horaria.

Registre versión y fecha de la regla. Una transformación sin versión impide explicar por qué dos informes históricos difieren.

La ruta debe poder comprobarse con una muestra. Si solo existe como diagrama ideal, márquela como arquitectura prevista, no como evidencia operativa.

4. Describir el fallo observable

Formule el riesgo como una condición comprobable. “Mala calidad” no indica qué buscar. “El MES omite órdenes sin confirmación final y el informe las trata como cero” sí permite probar población y efecto.

Distinga ausencia, duplicación, retraso, definición incompatible, estado incorrecto, pérdida de precisión y transformación no trazada.

No asigne causa todavía. El mismo hueco puede proceder del sensor, del transporte, de un filtro o de la consulta.

Registre también cómo se detectó: conciliación, revisión manual, alerta, discrepancia entre informes o pregunta de un responsable.

5. Delimitar población y ventana

Un riesgo necesita frontera. Indique activos, familias, centros, versiones, estados y periodos incluidos.

No extienda un hallazgo de una línea a toda la planta. Tampoco mezcle ventanas antes y después de un cambio de integración.

Conserve los casos no observados. Una muestra pequeña puede revelar un problema, pero no cuantificar su frecuencia para toda la población.

Si la cobertura es desconocida, registre ese desconocimiento como parte de la exposición. No lo sustituya por un porcentaje estimado sin base.

6. Relacionar el riesgo con la decisión

Explique qué parte de la decisión puede cambiar: prioridad, cantidad, fecha, orden, condición de parada, comparación o aprobación.

No confunda cambio posible con impacto demostrado. Primero describa el mecanismo: un estado tardío puede mantener una orden en el plan; una unidad equivocada puede distorsionar una comparación.

Registre qué decisiones ya utilizaron el dato. El historial permite localizar informes y reuniones que quizá necesiten una nota, sin reescribir el pasado.

Si la decisión tiene otras fuentes independientes, indíquelas. Un riesgo puede degradar una señal sin invalidar todo el expediente.

7. Conservar la evidencia mínima

La evidencia del riesgo incluye decisión, entidad, fuente, consulta, ventana, regla, muestra, resultado, excepciones y responsable. NIST caracteriza sistemas y analiza datos operativos para estudiar métricas y mejoras. La fuente de NIST es investigación metodológica y no demuestra el riesgo local.

Adjunte ejemplos originales y transformados. No conserve solo una captura del gráfico final.

Registre cómo se seleccionó la muestra y qué casos quedaron fuera. Otra persona debe poder repetir la consulta.

Evite duplicar datos sensibles en el mapa. Enlace el expediente controlado y muestre únicamente lo necesario para decidir.

8. Valorar severidad sin falsa precisión

Una escala puede ayudar si sus categorías tienen significado común. Defina qué distingue una exposición baja, media o alta para esa decisión.

No multiplique probabilidad e impacto cuando ambos son opiniones sin evidencia. El decimal resultante parece exacto, pero no mejora la decisión.

Puede separar impacto potencial, evidencia observada y confianza. Un riesgo de gran alcance con evidencia débil puede priorizar una comprobación, no una corrección masiva.

Documente quién aprobó el criterio. Cambiar la escala requiere una nueva versión para mantener comparabilidad.

9. Evitar un ranking engañoso

No ordene riesgos de decisiones distintas con una puntuación única si usan escalas o horizontes incompatibles.

Agrupe por decisión, ventana o tipo de control. Compare después solo elementos con criterios equivalentes.

Use empates cuando la evidencia no distingue. El mapa puede presentar dos comprobaciones urgentes sin inventar una prioridad absoluta.

Mantenga visibles los riesgos sin valoración. Ocultarlos porque no caben en el ranking premia la falta de información.

10. Definir el control

El control debe producir evidencia. “Revisar datos” no basta. Especifique conciliación, regla, tolerancia, frecuencia, población, salida y responsable.

Distinga prevención, detección y corrección. Una alerta detecta; no repara el origen ni valida los registros afectados.

Incluya qué ocurre cuando el control falla: retener el KPI, marcarlo condicionado, abrir una revisión o usar una fuente alternativa aprobada.

No asuma que automatizar elimina el riesgo. La lógica, la cobertura y las excepciones también necesitan prueba.

11. Asignar propietario y autoridad

El propietario del dato mantiene definición y calidad. El propietario del control demuestra que se ejecutó. La autoridad de la decisión acepta o rechaza el riesgo residual.

Evite asignar todo a “IT”. Producción, mantenimiento, planificación y dirección pueden tener responsabilidades diferentes sobre el mismo flujo.

Registre sustitutos y escalado. Un control sin responsable disponible puede convertirse en un punto único de fallo.

Enlace, cuando proceda, la guía de acceso a datos IT/OT, pero mantenga permisos y seguridad fuera de este mapa de decisión.

12. Tratar dependencias comunes

Una fuente, reloj, catálogo o transformación puede afectar varias decisiones. Registre la dependencia una vez y enlace sus usos.

No sume impactos automáticamente. Dos decisiones afectadas pueden referirse a la misma población o al mismo expediente.

Identifique controles compartidos. Una conciliación común puede reducir varias exposiciones, pero cada decisión conserva su condición de uso.

Si cambia la dependencia, abra revisión para todos sus consumidores. El mapa ayuda a localizar el alcance sin afirmar que todos los resultados son incorrectos.

13. Revisar frescura y cortes

Defina la frescura necesaria para cada decisión. “Actualizado” no significa lo mismo en un turno y en un comité mensual.

Conserve hora de evento, recepción, proceso y consulta cuando afecten al significado. No compare marcas sin aclarar zona y precisión.

Pruebe los bordes del corte. Un evento exactamente a las 06:00 puede entrar en poblaciones distintas según la regla.

Registre eventos tardíos y reaperturas. El informe revisado debe conservar vínculo con la versión que vio la decisión original.

14. Revisar transformaciones críticas

Liste reglas que cambian entidad, unidad, estado, población o tiempo. Esas transformaciones merecen prueba específica.

Compruebe con ejemplos positivos, negativos y ambiguos. Una regla que funciona en el caso normal puede fallar con devoluciones, retrabajos o estados corregidos.

Conserve código, consulta o configuración cuando sea posible. Si no está disponible, documente la limitación y aumente la revisión manual.

Use la página sobre calidad antes de una capa de lectura para separar problemas del origen y problemas de presentación.

15. Gestionar riesgos abiertos

Un riesgo abierto necesita siguiente comprobación, responsable y fecha. “Pendiente” sin acción no es un estado gestionable.

Registre qué decisión puede continuar y bajo qué límite. No todos los riesgos obligan a detener todo el proceso.

Si se usa una alternativa temporal, indique población, periodo y autoridad. No permita que se convierta en fuente permanente por inercia.

Revise si aparecen nuevos consumidores. Una exposición aceptable para un informe descriptivo puede no serlo para una secuencia operativa.

16. Cerrar y reabrir

Defina evidencia de cierre antes de ejecutar el control. Puede ser una conciliación repetida, cobertura demostrada o versión desplegada y probada.

Conserve el riesgo residual y quién lo aceptó. Cerrar no significa que el dato sea perfecto.

Establezca condiciones de reapertura: cambio de versión, fuente, población, ventana, unidad o propietario.

No borre la entrada cerrada. El historial permite entender decisiones posteriores y evitar repetir la misma investigación.

17. Mantener la frontera de ciberseguridad

Este mapa puede registrar que una decisión depende de un acceso o servicio, pero no evalúa amenaza, vulnerabilidad o conformidad.

Remita esos asuntos al proceso de seguridad competente. No convierta disponibilidad de datos en recomendación sobre arquitectura defensiva.

Evite publicar detalles que aumenten exposición. Use referencias controladas para configuraciones, credenciales o topología sensible.

La fuente autoritativa de cada KPI tampoco sustituye autorización, segregación de funciones o pruebas de seguridad.

18. Presentar el mapa a dirección

Abra con las decisiones expuestas y los riesgos que requieren acción o comprobación. No empiece por un inventario de aplicaciones.

Muestre para cada entrada fuente, fallo, población, decisión, evidencia, control, propietario y estado. Use notas breves para incertidumbre.

Separe hechos, hipótesis y propuestas. Dirección debe distinguir qué se observó de lo que aún necesita prueba.

Termine con decisiones solicitadas: aceptar temporalmente, financiar una comprobación, asignar autoridad, corregir o retener un uso.

19. Probar el control antes de declararlo eficaz

Prepare un caso que deba pasar y otro que deba activar el control. Incluya al menos una excepción conocida. Si el control solo se prueba con datos limpios, su cobertura real sigue abierta.

Ejecute la prueba con la misma consulta, ventana y permisos del proceso habitual. Una demostración manual con otra extracción no acredita el comportamiento operativo.

Registre entrada, resultado, tiempo de detección y acción posterior. El control puede detectar bien y fallar al escalar o conservar evidencia.

Repita después de cambios de versión, reglas o fuentes. Una validación antigua no cubre automáticamente una transformación nueva.

20. Controlar excepciones y anulaciones

Documente quién puede omitir el control y bajo qué condición. Una anulación verbal convierte una salvaguarda visible en una práctica difícil de auditar.

Conserve motivo, población, periodo y autoridad. La excepción debe caducar o volver a revisión; no puede quedar como estado indefinido.

Mida cuántas decisiones usan la excepción. Una frecuencia creciente puede indicar que el control no encaja con el proceso o que la fuente necesita corrección.

No interprete toda excepción como incumplimiento. Puede ser una respuesta legítima a cobertura incompleta, siempre que el límite permanezca visible.

21. Tratar cambios de definición

Cuando cambia una definición, identifique consumidores, periodos y comparaciones afectados. No actualice solo la etiqueta del informe.

Conserve la versión anterior y la fecha de entrada en vigor. Los históricos pueden necesitar una nota o una serie separada, no una reconstrucción silenciosa.

Revise controles y umbrales. Una regla diseñada para otra población puede producir falsas alertas o dejar huecos.

Abra riesgos específicos si dos áreas siguen usando definiciones distintas. El mapa debe mostrar la incompatibilidad hasta que exista una decisión de gobierno.

22. Revisar el mapa con una cadencia útil

No programe una revisión anual idéntica para todos los riesgos. Vincule la cadencia a la decisión, el cambio técnico y la velocidad con la que puede crecer la exposición.

Revise antes cuando cambien fuente, propietario, población, firmware, integración o regla. Esos eventos invalidan supuestos aunque no haya llegado la fecha ordinaria.

En cada revisión, compruebe evidencia de control, excepciones, decisiones afectadas y riesgos nuevos. Evite limitarse a cambiar el color o la fecha.

Archive versiones cerradas y explique los movimientos de prioridad. El historial debe permitir reconstruir por qué dirección actuó o esperó.

Proceso resumido

El proceso local identifica decisiones, descompone objetos y rutas, formula fallos observables, delimita población, conserva muestras y asigna controles antes de priorizar. NIST desarrolla métodos para caracterizar sistemas y analizar datos operativos. El programa oficial no prescribe este mapa ni garantiza resultados.

Primero catalogue decisiones y consumidores. Después trace fuentes y transformaciones, formule riesgos comprobables y documente evidencia.

Valore solo con criterios defendibles. Asigne control, responsable, autoridad y condición de revisión.

Revise dependencias, riesgos abiertos y cambios de versión. Conserve el historial de cierres y reaperturas.

Límites de la referencia externa

NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y trade-offs. La investigación no es una estadística española, una norma obligatoria ni una certificación del mapa local.

La aplicabilidad depende de cómo se caracterice la población y de la evidencia disponible. No use la fuente para asignar probabilidades, ahorros o causas.

El método local debe documentarse como síntesis editorial y aprobarse por la autoridad competente.

Decisión final

La salida relaciona fuente, riesgo, decisión afectada, evidencia, control, propietario y siguiente revisión; si falta cobertura o un criterio comparable, mantiene la hipótesis abierta. NIST aporta métodos para analizar datos operativos y métricas. La fuente no aprueba la prioridad ni el control de una planta.

El mapa queda listo cuando cada exposición tiene población, evidencia, estado y autoridad identificables. Los elementos sin base suficiente se convierten en comprobaciones, no en puntuaciones inventadas.

Preguntas frecuentes

¿Qué diferencia hay entre riesgo de datos y riesgo de ciberseguridad?

El riesgo de datos describe cómo cobertura, definición, estado, transformación o frescura pueden degradar una decisión. La ciberseguridad trata amenazas, vulnerabilidades, acceso y protección; puede relacionarse, pero requiere controles y responsables propios.

¿Debo asignar una puntuación a todos los riesgos?

No. Use categorías o rangos solo cuando exista un criterio común y evidencia suficiente. Si probabilidad o impacto no pueden defenderse, registre incertidumbre y priorice la comprobación necesaria.

¿Un dato incorrecto siempre es el riesgo principal?

No. También importan ausencia, retraso, población incompleta, definición distinta, versión obsoleta, transformación opaca o falta de propietario. El riesgo depende de la decisión que consume el dato.

¿Cuándo puede cerrarse un riesgo?

Cuando el control se ha probado sobre la población definida, existe evidencia reproducible, la decisión afectada acepta el riesgo residual y quedan registradas autoridad, fecha y condición de reapertura.

¿NIST valida el mapa de riesgos de una planta?

No. NIST aporta investigación sobre caracterización, métricas y análisis de datos operativos. El mapa, sus prioridades y sus controles necesitan evidencia y revisión local.