Cómo se gestiona un incidente en ISO 27001

Un empleado reporta que recibió un correo raro y que hizo clic antes de darse cuenta. Alguien de sistemas revisa, no ve nada extraño, y el asunto se cierra en una conversación de chat. Seis semanas después aparece actividad anómala en una cuenta y nadie puede reconstruir qué pasó aquel día, quién revisó qué ni con qué criterio se concluyó que no había nada. El problema no fue la respuesta técnica: fue que no existía un proceso.

Evento no es lo mismo que incidente

La distinción es la que sostiene todo el proceso. Un evento de seguridad de la información es cualquier ocurrencia que indica una posible falla de un control o una situación previamente desconocida que puede ser relevante: un intento de acceso fallido repetido, una alerta del antivirus, un reporte de un usuario. Un incidente es el evento —o la serie de eventos— que tiene probabilidad significativa de comprometer las operaciones o amenazar la seguridad de la información. Sin ese criterio escrito, cada persona decide por su cuenta qué escala y qué no, y la organización se entera tarde.

Las etapas del proceso

• —Reporte: canales conocidos por todo el personal, con la obligación explícita de reportar y sin castigo por reportar de más.
• —Evaluación y clasificación: aplicar el criterio definido para decidir si el evento es incidente y qué categoría y severidad le corresponde.
• —Respuesta: contener, erradicar y recuperar según procedimientos por tipo de incidente, con roles asignados de antemano.
• —Registro de evidencia: preservar la información de forma que sirva después, tanto para el análisis como para un eventual proceso legal o disciplinario.
• —Aprendizaje: analizar la causa, ajustar los controles que fallaron y alimentar con eso la evaluación de riesgos.

El requisito que convierte el proceso en sistema

Responder bien a un incidente aislado es gestión de crisis; el sistema de gestión aparece cuando el conocimiento obtenido se usa. La norma pide explícitamente que el aprendizaje de los incidentes sirva para reducir la probabilidad o el impacto de incidentes futuros, lo que en la práctica significa revisar si el control que falló estaba mal diseñado, mal implementado o simplemente ausente, y llevar esa conclusión a la declaración de aplicabilidad y al plan de tratamiento de riesgos. Un registro de incidentes que no modifica nunca ningún control es una bitácora, no un proceso de mejora.

La obligación de notificar hacia afuera

Además del manejo interno, hay incidentes que disparan obligaciones externas: notificar al cliente cuyo dato se vio afectado, al titular de los datos personales, a la autoridad competente o al socio contractual dentro del plazo que fija el contrato. Esos plazos suelen medirse en horas, no en días, y por eso la decisión de a quién avisar y en cuánto tiempo tiene que estar resuelta antes del incidente, con los contactos identificados y el criterio documentado. Improvisarlo en el momento es la forma más rápida de incumplir un contrato mientras se atiende la contingencia.

Por dónde empezar

El camino práctico es escribir la clasificación —qué es evento, qué es incidente, qué severidades hay y quién decide—, definir el canal de reporte y probarlo con un caso simulado para ver si el proceso realmente corre. En Yucatán, donde el polo de servicios y tecnología de Mérida trabaja para clientes que auditan a sus proveedores antes de compartirles información, tener este proceso documentado suele ser la diferencia entre pasar el cuestionario del cliente o quedarse fuera del contrato. En la Consultoría ISO 27001 en Mérida se empieza por el criterio de clasificación, porque sin él el registro de incidentes queda vacío no porque no ocurran, sino porque nadie sabe cuáles anotar.