Incidente en una API de multas: qué se comunica y cuándo

Detectar un incidente y contenerlo es una parte del trabajo. La otra empieza cuando hay que contarlo: a las flotas que integran la API, a las personas cuyos datos pudieron quedar involucrados y, según el caso, a la autoridad. Esa parte se improvisa seguido, y se nota.

El error habitual no es el silencio deliberado: es esperar a tener la historia completa antes de escribir la primera línea, y mandar un texto prolijo y tardío que ya no le sirve a nadie. El incidente se comunicó; la ventana en la que servía, no.

No existe un mensaje único. Existen tres, con destinatarios, contenidos y relojes distintos.

Tres audiencias que necesitan cosas distintas

El aviso operativo va a quien tiene que hacer algo ahora: el contacto técnico de cada flota alcanzada. Su medida de éxito es que el receptor pueda actuar, no que el texto esté terminado.

La notificación a las personas alcanzadas y, cuando corresponde, la comunicación a la autoridad de aplicación son otra cosa. La ley argentina de datos personales —y una infracción asociada a un titular es dato personal— exige medidas técnicas y organizativas para garantizar su seguridad y confidencialidad, y obliga al secreto a quien los trata incluso después de terminada la relación; la Agencia de Acceso a la Información Pública publica esas obligaciones para los responsables de bases de datos.

Lo que esas fuentes no traen es un procedimiento de aviso: no fijan a quién notificar un incidente, con qué forma ni en qué plazo. Conviene saberlo antes: quien busque esa respuesta con el incidente en curso no la va a encontrar ahí. Si el deber existe en un caso concreto, sale de otra norma o del contrato con la flota, y se define con asesoramiento legal al escribir el procedimiento, no durante la guardia.

Confundirlas falla en las dos direcciones: un aviso técnico redactado como comunicado, ilegible para quien tiene que rotar la clave con la que su flota consulta multas, o una notificación formal armada sobre el borrador operativo, llena de hipótesis que hay que desmentir.

El primer aviso sale antes que el informe

El umbral no es “ya sabemos qué pasó”, sino “hay algo accionable del otro lado”. Alcanza para un mensaje de cuatro campos:

• qué superficie o sistema está involucrado;
• desde cuándo y hasta cuándo, hasta donde se sabe hoy;
• qué tiene que hacer el receptor y con qué urgencia;
• cuándo llega la próxima actualización, con hora concreta.

El último es el que más se omite y el que más trabajo ahorra: sin próxima fecha, cada flota abre su canal para preguntar lo mismo y el equipo termina respondiendo mensajes en vez de investigar.

Lo que un aviso temprano todavía no puede afirmar

Tres frases suelen aparecer en borradores y no deberían salir mientras la investigación sigue abierta: que nadie accedió a las patentes ni a los titulares de un cliente, que el incidente está cerrado y quién estuvo detrás. Las tres son conclusiones, y una conclusión retirada después cuesta más que un dato faltante al principio. Tampoco se adjunta el material expuesto: reproducirlo lo difunde otra vez, por un canal más amplio.

Un buen aviso es explícito sobre su incertidumbre: qué se revisó, con qué registros y qué queda por confirmar. Esa honestidad depende de tener trazas que cubran la ventana, un problema de diseño previo más que de redacción, como en auditoría verificable sin payloads completos.

Relojes, versiones y cierre

Un incidente tiene al menos tres momentos y conviene nombrarlos por separado: cuándo empieza la ventana de exposición, cuándo se detecta y cuándo se contiene. Mezclarlos distorsiona en los dos sentidos: parece que se tardó semanas, o que todo duró minutos. Cada hora va con zona horaria y con la marca de si es exacta o estimada: una ventana estimada que se amplía es normal, pero una hora presentada como precisa que luego cambia erosiona el comunicado entero.

Las actualizaciones se numeran, llevan hora y dicen qué cambió respecto de la anterior; editar en silencio un documento vivo es la forma más rápida de que nadie sepa qué versión leyó. Si el alcance crece, se anuncia como novedad.

El informe final se escribe con causa establecida, alcance cerrado y correcciones implementadas: qué pasó, qué se cambió y cómo se detectará antes la próxima vez. La contención técnica —revocar, invalidar derivados, reemitir— tiene su propio procedimiento en credenciales comprometidas: plan de rotación.

Qué tener listo antes

Los catálogos de controles de referencia ubican la respuesta a incidentes como una familia propia: algo que se diseña y se mantiene. Del lado de la comunicación, son cuatro cosas que podés revisar hoy:

• una lista de contactos técnicos por integración, con dueño y fecha de última revisión;
• plantillas del aviso y de la actualización, con los campos mínimos ya definidos;
• un canal alternativo, por si el habitual es justamente el comprometido;
• una persona con autoridad para decidir que se avisa, y su reemplazo.

Probalo: tomá un incidente ficticio —la credencial con la que una flota consulta multas quedó expuesta—, redactá el primer aviso y cronometrá cuánto tarda en estar listo. Si nunca lo hiciste, la primera vez que escribas ese mensaje va a ser con el incidente real encima.

Preguntas frecuentes

¿Conviene esperar a tener el informe completo antes de avisar?

No. El aviso operativo tiene un umbral propio: existe algo que el receptor puede hacer. Si hay que rotar una credencial, revisar accesos o frenar una exportación, ese mensaje sale aunque el alcance todavía se esté calculando. El informe completo es otro documento, con otro destinatario y otro momento.

¿Se puede decir que no se accedió a datos personales?

Sólo si la evidencia lo sostiene para toda la ventana involucrada. No encontrar rastros de acceso y probar que no lo hubo son cosas distintas, sobre todo cuando la trazabilidad no cubre ese período completo. Mientras esa diferencia exista, corresponde describir qué se revisó y qué no, en lugar de afirmar una conclusión que después haya que retirar.

¿A quién hay que notificar un incidente en Argentina?

Las fuentes oficiales citadas —la ley de protección de datos personales y las obligaciones que publica la autoridad de aplicación— exigen garantizar la seguridad y la confidencialidad de los datos, pero no establecen a quién avisar un incidente, con qué forma ni en qué plazo. Eso no equivale a que no haya nada que comunicar: puede haber reglas sectoriales, cláusulas de contrato o compromisos propios que sí lo exijan. Cuál aplica a tu caso se determina antes, con asesoramiento profesional; esto es orientación general y no lo reemplaza.

¿El aviso puede incluir el dato o la credencial expuesta?

No. Reproducir el secreto, el token o el registro comprometido lo vuelve a difundir, ahora por un canal más amplio y con copia en casillas ajenas. Para identificar de qué se habla alcanzan referencias no sensibles: un identificador interno, los últimos caracteres de una clave o el nombre del recurso afectado.

Notas relacionadas