Es una escena hipotética, pero estructuralmente plausible en cualquier empresa argentina de tecnología, servicios financieros o infraestructura: un área de Seguridad de la Información detecta, durante una revisión de rutina, que un administrador de sistemas —empleado directo de la compañía o, cada vez con más frecuencia, personal de un proveedor externo de servicios gestionados de TI— accedió reiteradamente a una base de datos de clientes fuera del horario y del alcance de sus tareas habituales. No hubo un ataque externo, no hubo una vulnerabilidad técnica explotada desde afuera: hubo una persona que ya tenía la llave, y que la usó para abrir una puerta que no le correspondía. Es exactamente el tipo de escenario que separa dos preguntas distintas, y que las organizaciones argentinas suelen resolver bien la primera y mal la segunda: qué hacemos ahora mismo, y por qué esta persona llegó a tener ese nivel de acceso sin que nadie lo hubiera cuestionado antes.


La respuesta inmediata: contener antes de entender del todo

Frente a un incidente de este tipo, la primera etapa es de naturaleza esencialmente técnica y legal, y su prioridad es contener el daño antes de que se agrave. Esto implica, en términos generales, revocar o limitar de inmediato los accesos de la persona involucrada —sea empleado, contratista o proveedor— a los sistemas y datos comprometidos, preservar la evidencia digital disponible de manera forense, de forma que pueda sostenerse en una eventual instancia judicial o administrativa, y activar la participación coordinada de las áreas de Legal, Compliance y Seguridad de la Información, que en este tipo de situaciones necesitan trabajar en simultáneo y no de manera secuencial. Una investigación interna mal preservada, o una decisión apresurada de desvincular a la persona antes de resguardar la evidencia, puede debilitar seriamente la posición de la empresa si el caso deriva en una denuncia penal o en un reclamo laboral posterior.


En paralelo, la organización necesita evaluar qué obligaciones de comunicación podrían corresponderle según el tipo de dato comprometido y el sector en el que opera. La Ley N° 25.326 de Protección de Datos Personales impone, en su artículo 9°, el deber de adoptar medidas de seguridad para evitar el tratamiento no autorizado de datos personales, y el Código Penal, en su artículo 157 bis —incorporado precisamente por la Ley 25.326—, tipifica como delito el acceso ilegítimo a un banco de datos personales por parte de quien, a sabiendas, viola los sistemas de confidencialidad establecidos para protegerlos. Sin embargo, es importante ser preciso en un punto que suele generar confusión: a diferencia de otros marcos internacionales, actualmente no existe en Argentina una obligación legal general de notificar todo incidente de seguridad de datos personales a la Agencia de Acceso a la Información Pública (AAIP) o a los titulares de los datos afectados. La AAIP ha promovido la notificación de incidentes como una buena práctica recomendable, pero elevarla al rango de obligación legal generalizada sería inexacto. Distinto es el caso de las entidades financieras alcanzadas por el Banco Central de la República Argentina (BCRA), cuyo marco de gestión de riesgos de tecnología y ciberseguridad —contenido en la Comunicación "A" 7724— sí prevé exigencias específicas de reporte de incidentes significativos hacia el propio regulador, en función del sector y la magnitud del evento.


Por qué la etapa técnica no cierra el problema

Una vez contenido el incidente, resuelta la investigación forense y tomadas las decisiones legales correspondientes, queda pendiente la pregunta que rara vez recibe la misma atención: ¿qué llevó a que esta persona específica tuviera ese nivel de acceso, y qué mecanismo debería haber revisado esa situación antes de que se convirtiera en un problema? Es en esta segunda dimensión donde el análisis deja de ser un problema exclusivamente de ciberseguridad y pasa a ser un problema de gestión del riesgo humano: de decisiones de contratación, de asignación de privilegios, de evaluación de terceros y de revisión periódica de funciones sensibles.


La fotografía inicial y lo que cambia después

Una verificación de antecedentes realizada al momento de la contratación —sea de un empleado, un contratista o un proveedor tecnológico— describe una situación válida en ese momento puntual, pero no anticipa lo que puede ocurrir después: un cambio de rol que amplía el acceso de una persona sin que se repita ningún tipo de evaluación asociada a ese nuevo nivel de responsabilidad, un ascenso a una función con autoridad sobre sistemas críticos, o la incorporación de un proveedor externo cuyo personal técnico termina teniendo credenciales privilegiadas equivalentes a las de un empleado directo, sin haber pasado por ningún proceso de verificación comparable. Esta última situación es particularmente relevante en el ecosistema argentino de tecnología y servicios financieros, donde es habitual que empresas de fintech, software o telecomunicaciones deleguen en proveedores externos de servicios gestionados —los llamados MSP— funciones de administración de infraestructura que implican acceso directo a sistemas de producción y bases de datos de clientes, sin que ese vínculo contractual sea jurídicamente equivalente a una relación de empleo, pero sí comparable en términos de exposición y riesgo.


Para funciones de esta naturaleza —administración de sistemas críticos, gestión de pagos, acceso a bases de datos sensibles, roles de decisión sobre proveedores o contratos—, puede resultar razonable implementar revisiones posteriores a la contratación inicial, basadas en el riesgo específico de la función, particularmente cuando cambian las responsabilidades, el nivel de acceso o la exposición de la persona. Esto no equivale a instalar un régimen de monitoreo permanente sobre toda la dotación de una empresa, ni a sugerir que la mayoría de los empleados representan algún tipo de amenaza: la proporcionalidad sigue siendo el criterio central, y debería aplicarse exactamente al mismo estándar tanto a empleados directos como a terceros con privilegios equivalentes, sin que la forma jurídica del vínculo —relación de dependencia o contrato de servicios— determine automáticamente un nivel de control menor.


El eslabón que casi nunca se revisa: los terceros con acceso privilegiado

El riesgo proveniente de contratistas de tecnología, proveedores de servicios gestionados y consultores externos suele quedar fuera del radar de los procesos de gestión de riesgo humano, precisamente porque no forman parte de la nómina de la empresa y su vínculo se gestiona, casi siempre, exclusivamente desde el área de Compras o de Tecnología, sin intervención de Recursos Humanos ni de Compliance. Sin embargo, un consultor externo con credenciales de administrador sobre un sistema de pagos o una base de datos de clientes tiene, en términos de exposición real, un perfil de riesgo comparable —y en algunos casos superior— al de un empleado directo en una posición equivalente. Tratar a estos terceros bajo un estándar de verificación y revisión distinto, más laxo, únicamente porque su vínculo contractual es diferente, es una de las brechas más comunes y menos discutidas en la gestión de riesgo humano de empresas argentinas con estructuras de tecnología tercerizadas.


Dónde entra Human Risk Management en esta conversación

Como plantea Guido Schenone, Comercial & Growth Manager de Validato, "la respuesta técnica a un incidente interno resuelve el problema inmediato, pero la pregunta que realmente previene que se repita es otra: quién tiene acceso hoy a qué, qué se evaluó antes de otorgarle ese acceso, y qué cambió desde entonces sin que nadie lo haya vuelto a mirar". Esa mirada integral —que conecta la evaluación previa a la incorporación de una persona (Background Screening), la revisión basada en riesgo durante la relación laboral o contractual (In-Employment Screening), y la debida diligencia sobre terceros con privilegios equivalentes (Third-Party Screening y, cuando corresponde por la actividad de la empresa, procesos de KYC vinculados a la normativa de prevención de lavado de activos de la UIF)— es lo que distingue una gestión de riesgo humano estructurada de una que solo reacciona después de cada incidente.


Una reflexión final: lo que un incidente realmente demuestra

Un incidente de amenaza interna no demuestra que todas las personas dentro de una organización sean un riesgo, ni justifica instalar una cultura de sospecha generalizada sobre empleados, contratistas o proveedores. Demuestra, en cambio, que la organización necesita saber con precisión qué funciones concentran el mayor nivel de exposición —por el acceso que otorgan, por la responsabilidad que implican, por la capacidad de decisión que conllevan— y diseñar, alrededor de esas funciones específicas, controles proporcionales que se revisen con la misma seriedad con la que se otorgaron en un primer momento. Ningún proceso de verificación, por más riguroso que sea, puede garantizar que un incidente de este tipo no vuelva a ocurrir. Lo que sí puede lograr una gestión de riesgo humano bien diseñada es reducir la probabilidad de que la próxima vez que ocurra, la pregunta "¿por qué esta persona tenía este acceso?" no vuelva a encontrar, como única respuesta, que nadie se lo había preguntado antes.


Fuentes y marco normativo consultado:

  1. Ley N° 25.326 de Protección de Datos Personales, artículo 9°, B.O. 2/11/2000.
  2. Código Penal de la Nación Argentina, artículo 157 bis, incorporado por la Ley N° 25.326.
  3. Banco Central de la República Argentina (BCRA), Comunicación "A" 7724, gestión de riesgos de tecnología y ciberseguridad para entidades financieras.
  4. Ley N° 25.246, régimen de prevención del lavado de activos y financiamiento del terrorismo, y normativa de la Unidad de Información Financiera (UIF) aplicable a sujetos obligados.
  5. Ley N° 20.744, Ley de Contrato de Trabajo, artículo 85 (deber de fidelidad).
  6. Agencia de Acceso a la Información Pública (AAIP), recomendaciones sobre notificación de incidentes de seguridad como buena práctica (sin carácter de obligación legal general vigente).