La parte más difícil de un incidente de seguridad suele llegar después de que el incidente haya terminado: cuando la empresa tiene que explicar qué ha ocurrido, cuándo se descubrió, qué datos se vieron afectados, a quién afectó y por qué se tomaron ciertas decisiones.
Para muchas pymes, estos registros no existen de forma completa. Los detalles pueden estar dispersos entre mensajes de chat, bandejas de entrada, tickets de soporte, capturas de pantalla y la memoria de los miembros del equipo. Las empresas se mantienen a flote durante un incidente con estos registros fragmentados, pero se convierten en un problema cuando una autoridad de control, una aseguradora, un cliente o un miembro del consejo pide una cronología clara.
Las empresas de todos los tamaños necesitan un registro de incidentes de seguridad exhaustivo. Debe ser una única fuente de verdad para registrar qué ocurrió, cómo se gestionó el incidente y qué pruebas respaldan las decisiones que se tomaron en el camino.
El registro es valioso incluso cuando no necesitas notificar un incidente. Explicamos por qué los registros de incidentes de seguridad son útiles para tu empresa y cómo crear el tuyo propio.
Por qué importan los registros de incidentes de seguridad
Registros de incidentes frente a planes de respuesta ante incidentes
Qué debe incluir un registro de incidentes de seguridad
Una plantilla sencilla de registro de incidentes para pymes
Cómo registrar las decisiones de notificación
Qué esperan las autoridades de control de los registros de incidentes de seguridad
El registro de acceso a credenciales
Por qué importan los registros de incidentes de seguridad
Los registros de incidentes de seguridad fomentan la rendición de cuentas en el momento en que es más probable que una empresa pierda de vista los detalles. Durante un incidente, las acciones ocurren con rapidez: se restablecen contraseñas, se desactivan cuentas, se contacta con proveedores de TI, se revisan los datos de clientes y se informa a la dirección. Es posible que estos pasos sean exactamente lo que la empresa necesita en ese momento, pero resultan mucho más difíciles de explicar después si nadie registra cuándo ocurrió cada acción, quién la aprobó y qué pruebas respaldaron la decisión.
Para las empresas con sede en Europa, esto no es solo una buena práctica. En virtud del Reglamento General de Protección de Datos (GDPR), tanto en el Reino Unido como en la UE, las vulneraciones de datos personales deben evaluarse y algunas deben notificarse a la autoridad de control correspondiente.
En el Reino Unido, la guía para denunciar una vulneración(ventana nueva) de la ICO (Oficina del Comisionado de Información) explica que las organizaciones deben evaluar el riesgo probable para los derechos y libertades de las personas y notificar a la ICO cuando ese riesgo sea probable. El artículo 33 también exige que los responsables documenten las vulneraciones de datos personales, incluidos los hechos de la vulneración, sus efectos y las medidas correctivas adoptadas. Los mismos requisitos se aplican en virtud del GDPR de la UE.
Por ejemplo, la ICO no espera que todas las pymes tengan sistemas de nivel empresarial, pero sí espera registros adecuados. Su marco de respuesta y monitorización de vulneraciones indica que las organizaciones deben disponer de procedimientos para asegurarse de que los incidentes y las vulneraciones de datos personales se detecten, se gestionen y se registren de forma adecuada. Esto significa que un registro de incidentes no debe crearse solo cuando ya se ha producido una vulneración grave. Debe formar parte del proceso de respuesta habitual.
Unos buenos registros también respaldan las reclamaciones a seguros. Las aseguradoras de ciberseguridad pueden solicitar pruebas de cuándo se descubrió el incidente, qué medidas de contención se tomaron, qué cuentas se vieron afectadas y si la empresa siguió su proceso de respuesta ante incidentes. Un registro bien llevado puede demostrar que la empresa actuó con prontitud y coherencia.
También ayuda a la empresa a aprender. Los recuerdos y los registros orales no son fiables, pero un registro que muestra que el incidente comenzó con una contraseña reutilizada, la falta de autenticación multifactor (MFA), acceso de proveedores o una baja tardía de empleados da a la empresa algo concreto que corregir y una dirección más clara para reforzar la seguridad con el tiempo.
Registros de incidentes frente a planes de respuesta ante incidentes
Un registro de incidentes de seguridad y un plan de respuesta ante incidentes están relacionados, pero no son el mismo documento.
Un plan de respuesta ante incidentes explica qué debe hacer la empresa cuando algo sale mal. Asigna roles, rutas de escalado, pasos de contención, responsabilidades de comunicación y procedimientos de recuperación. El registro de incidentes recoge lo que realmente ocurrió. Es la cronología, el rastro de pruebas, el registro de decisiones y el archivo de seguimiento de un evento concreto.
Esa distinción importa porque incluso un buen plan puede fallar sin documentación. Una empresa puede seguir los pasos correctos y, aun así, tener dificultades para demostrarlo después. El registro debe permitir responder a preguntas prácticas: ¿cuándo nos enteramos?, ¿quién actuó?, ¿qué contuvimos?, ¿qué datos estaban en riesgo?, ¿qué decidimos? y ¿qué cambió después?
| Plan de respuesta ante incidentes: qué debe hacer tu empresa | Registro de incidentes de seguridad: qué ocurrió realmente |
| Quién lidera la respuesta Quién contacta con TI, los servicios jurídicos, la aseguradora o los reguladores Cómo contener, recuperar y comunicar | Cuándo se descubrió el incidente Qué sistemas y datos se vieron afectados Qué acciones se tomaron, quién las llevó a cabo y cuándo |
Qué debe incluir un registro de incidentes de seguridad
Un registro de incidentes útil debe ser lo bastante coherente para que una empresa pueda reconstruir el evento más tarde y explicar las decisiones tomadas durante la respuesta.
Fecha y hora del descubrimiento
Registra cuándo se enteró la empresa del incidente por primera vez, quién lo detectó y cómo se descubrió. Si la hora es aproximada, márcala como aproximada. La hora del descubrimiento importa porque los plazos de notificación del GDPR y los requisitos de los seguros a menudo dependen de cuándo se enteró la empresa del problema.
Naturaleza del incidente
Describe qué ocurrió en un lenguaje sencillo. Evita etiquetas vagas como «problema de seguridad» o «posible vulneración» sin contexto. El registro debe explicar qué sistemas se vieron afectados y si el incidente implicó credenciales, correo electrónico, archivos, datos de clientes, sistemas de pago, puntos de conexión o acceso de terceras partes.
Datos implicados
Si es posible que se hayan visto afectados datos personales, registra qué tipo de datos estaban implicados: nombres, direcciones de correo electrónico, números de teléfono, direcciones, datos de cuentas, información financiera, expedientes de empleados, comunicaciones con clientes, credenciales de inicio de sesión o cualquier otra categoría relevante. Calcula cuántas personas pueden verse afectadas y deja claro si la cifra está confirmada o sigue bajo investigación.
Causa probable
Registra la causa conocida o sospechada, aunque la investigación siga en curso. A medida que surjan nuevos detalles, el registro puede actualizarse de «causa desconocida» a «un correo electrónico de suplantación de identidad (phishing) provocó el compromiso de credenciales» o «la cuenta de un antiguo contratista seguía activa». El registro debe mostrar cómo cambió la comprensión de la empresa con el tiempo.
Acciones inmediatas de contención
Documenta qué se hizo para limitar los daños. Esto puede incluir restablecimientos de contraseñas, revocación de sesiones, aplicación de la MFA, suspensión de cuentas, eliminación de reglas del buzón, aislamiento de dispositivos, eliminación del acceso de proveedores, cambios en el cortafuegos o interrupciones temporales del servicio. Cuando sea posible, incluye el responsable y la marca de tiempo de cada acción.
Decisiones de notificación
Registra si la empresa notificó a la autoridad de control correspondiente (la ICO en el Reino Unido o la autoridad nacional de protección de datos en el resto de la UE), a las personas afectadas, a los clientes, a los proveedores, a las aseguradoras, a los asesores jurídicos o a las fuerzas del orden. Si la decisión fue no notificar, documenta el razonamiento. Esa explicación suele ser tan importante como la notificación en sí.
Medidas correctivas y cronología
La contención aborda el incidente inmediato. Las medidas correctivas reducen la probabilidad de que el mismo problema vuelva a ocurrir. Registra las acciones de seguimiento, como aplicar la MFA, eliminar credenciales compartidas, actualizar las políticas de acceso, mejorar el proceso de baja de empleados, corregir una configuración incorrecta o cambiar la forma en que se protegen las copias de seguridad.
Lecciones aprendidas
Termina con lo que la empresa ha aprendido y lo que va a cambiar. No debe escribirse como una acusación. Debe identificar la debilidad, la mejora necesaria y quién se encarga del seguimiento.
Una plantilla sencilla de registro de incidentes para pymes
No se necesita software especializado para documentar incidentes. Una hoja de cálculo, un formulario interno seguro, un sistema de tickets o un registro compartido pueden servir si el acceso está controlado y las entradas se mantienen coherentes.
Un registro de incidentes eficaz debe incluir estos campos:
- ID de incidente: un número de referencia único.
- Fecha y hora del descubrimiento: cuándo se enteró la empresa del incidente.
- Notificado por: empleado, proveedor, cliente, vendedor, alerta de monitorización o parte externa.
- Tipo de incidente: suplantación, malware, compromiso de credenciales, pérdida de datos, acceso no autorizado, ransomware, incidente de proveedor, pérdida de dispositivo, correo electrónico mal dirigido u otro.
- Resumen: qué ocurrió, escrito en lenguaje sencillo.
- Sistemas afectados: aplicaciones, cuentas, dispositivos, bases de datos, bandejas de entrada o servicios de terceras partes implicados.
- Datos implicados: si se vieron afectados datos personales, de qué tipo y cuántas personas pueden verse afectadas.
- Causa probable: conocida, sospechada o en investigación.
- Acciones de contención: qué se hizo de inmediato.
- Decisión de notificación: autoridad de control, personas, clientes, aseguradora o no notificar con la justificación.
- Enlaces a pruebas: capturas de pantalla, tickets, registros, correos electrónicos, registros de acceso, archivos exportados o informes de proveedores.
- Acciones de remediación: pasos realizados después de la contención.
- Responsable: persona encargada del seguimiento.
- Estado: abierto, en monitorización, contenido, resuelto, cerrado.
- Lecciones aprendidas: qué debería cambiar.
Cómo registrar las decisiones de notificación
Las decisiones de notificación merecen un espacio propio en un registro de incidentes de seguridad porque a menudo se revisan después del incidente.
Tanto en el GDPR (Reglamento General de Protección de Datos) del Reino Unido como en el de la UE, las organizaciones deben evaluar el riesgo probable para los derechos y libertades de las personas cuando se produce una vulneración de datos personales. Si es probable que exista riesgo, debe notificarse a la autoridad de control lo antes posible y, cuando sea factible, en un plazo de 72 horas: la ICO(ventana nueva) (Oficina del Comisionado de Información) en el Reino Unido y la autoridad nacional de protección de datos de cada Estado miembro de la UE. Si el riesgo es alto, también debe notificarse a las personas afectadas sin dilación indebida. Los umbrales y el plazo son los mismos en ambos casos; solo cambia la autoridad.
Un buen registro de incidentes debe mostrar que la empresa realizó esta evaluación. Debe registrar si se vieron implicados datos personales, qué tipo de daño podría derivarse, qué protecciones había en vigor y por qué la empresa decidió notificar o no hacerlo.
Por ejemplo, un incidente con una contraseña de administrador expuesta puede no revelar de inmediato si se accedió a datos personales. El registro debe reflejar esa incertidumbre. Puede registrar la preocupación inicial, los pasos de la investigación, la revisión de la actividad de la cuenta y la conclusión final una vez que se disponga de pruebas.
En este punto del proceso, muchas empresas se centran en organizar la solución técnica y olvidan registrar la justificación de cumplimiento. Se restablecen las contraseñas, se protegen las cuentas y las operaciones continúan. Semanas después, la empresa no puede explicar por qué decidió que el incidente no era notificable.
Qué esperan las autoridades de control de los registros
Las autoridades de control no solo se fijan en si se notificó una vulneración. También pueden preguntar cómo la empresa:
- Identificó el incidente
- evaluó el riesgo
- decidió si era necesaria la notificación
- documentó las acciones tomadas
Un buen registro debe dejar clara la historia del incidente de principio a fin. Debe mostrar qué ocurrió, qué datos personales se vieron implicados, qué daño podría derivarse, qué hizo la empresa para contener el problema y por qué notificó o no notificó la vulneración.
El nivel de detalle debe corresponder a la gravedad del incidente. Un correo electrónico mal dirigido no necesita el mismo registro que un ataque de ransomware, pero aun así debe documentarse para mostrar que la empresa lo evaluó adecuadamente.
Estos registros también deben almacenarse de forma segura. Los registros de incidentes pueden incluir detalles sensibles sobre las personas afectadas, los sistemas expuestos, las acciones de los empleados, capturas de pantalla, registros de acceso o pasos de remediación. El acceso debe limitarse a las personas que lo necesiten y la conservación debe ajustarse a la política de conservación de datos más amplia de la empresa.
El registro de acceso a credenciales
Muchos incidentes implican credenciales: pueden desencadenarse por una contraseña reutilizada, una cuenta compartida, una bandeja de entrada comprometida, un inicio de sesión de administrador expuesto, una solicitud de MFA (autenticación multifactor) sospechosa o un empleado que no fue dado de baja correctamente.
Por ese motivo, los registros de acceso a credenciales pueden convertirse en una entrada directa para la documentación de incidentes de ciberseguridad. Cuando un incidente implica un inicio de sesión compartido o una cuenta sensible, la empresa necesita saber quién tenía acceso, cómo se compartió el acceso, si cambiaron los permisos y si la credencial se rotó después del incidente.
Un gestor de contraseñas para empresas como Proton Pass for Business ayuda a los equipos a administrar credenciales en cajas fuertes cifradas, generar contraseñas únicas, usar el relleno automático, compartir credenciales de forma segura, administrar llaves de acceso y usar la autenticación de dos factores integrada. Para la documentación de incidentes, el valor más importante es el rastro de acceso en torno a las credenciales: quién tenía acceso a cajas fuertes o cuentas compartidas, cómo se administraba el acceso y quién lo usaba, y qué cambió después del incidente.
Un gestor de contraseñas para equipos de TI añade funciones de administrador como políticas, informes, registros, control de acceso basado en roles, aprovisionamiento SCIM (Sistema para la Gestión de Identidades entre Dominios) e integración con SSO (inicio de sesión único). Estas funciones pueden ayudar a las empresas a mostrar cómo se controla el acceso a las credenciales y aportar pruebas cuando se investiga un incidente relacionado con credenciales.
Un gestor de contraseñas no puede sustituir a un registro de incidentes, una evaluación jurídica, un proceso de notificación regulatoria o un plan de respuesta ante incidentes. Pero proporciona pruebas sobre credenciales que pueden alimentar esos procesos.
Mantén un registro de auditoría completo del acceso a las credenciales con un gestor de contraseñas para empresas.
