La empresa cierra un contrato más grande —un cliente que factura más, atiende a más gente o trabaja en un sector más regulado— y junto con el contrato llega un formulario de ochenta preguntas sobre la TI de quien va a prestarle servicio: cómo funciona el backup, quién tiene acceso a qué, si existe registro de esos accesos, quién avisa a quién si ocurre un incidente. El plazo para responder suele ser de una semana.
Según el resumen ejecutivo del informe anual de violaciones de datos de Verizon, referido a 2026, las violaciones con participación de terceros crecieron un 60% en un año y ya representan el 48% de todo lo registrado: casi la mitad. Por eso cada vez más empresas grandes tratan a sus propios proveedores, incluido el proveedor de TI, como parte del riesgo de seguridad que necesitan controlar, y no como un ítem tercerizado que nadie sigue.
Para quien recibe el cuestionario, el problema casi nunca es la pregunta en sí. Es no tener la respuesta lista: nadie sabe cuánto tiempo tarda en restaurarse el backup, no existe una lista de quién accede a qué, y nadie sabe decir quién llama a quién si un sistema se cae. Quien no responde a tiempo no pierde solo un contrato: pierde la oportunidad de crecer con el cliente correcto.
El cuestionario que decide el contrato
El formulario suele cubrir siempre los mismos puntos: cómo y dónde se guardan los datos, quién tiene acceso a cada sistema, si ese acceso queda registrado, en cuánto tiempo la empresa vuelve a operar después de un problema serio, si las actualizaciones de seguridad están al día, y quién es avisado —y en qué orden— si algo falla. También es común preguntar si la empresa terceriza parte del trabajo, y a quién.
La distinción que explica esta exigencia está en la ley brasileña de protección de datos, la LGPD. La ley separa a quien decide qué hacer con los datos —el controlador, normalmente el propio cliente— de quien trata esos datos en nombre de otro —el operador, el papel que ocupan la empresa y su proveedor de TI. Según la autoridad brasileña de protección de datos, es el controlador quien tiene la obligación legal de comunicar un incidente de seguridad, pero el operador debe avisar sin demora y entregar toda la información necesaria. En la práctica: si el incidente ocurrió en el equipo, el servidor o la red de quien presta el servicio, quien responde ante la ley es el cliente que contrató —y por eso quiere saber, antes de firmar, si esa estructura está realmente cuidada.
Esto no ocurre solo con las empresas grandes. Una industria con dos turnos que abastece a una cadena minorista, un despacho contable que atiende a una financiera, una clínica que presta servicio a un seguro de salud: todos entran en la cadena de proveedores de alguien más grande, y ese alguien más grande vigila su propia cadena. Lo que cambia es el tamaño de quien pregunta; la pregunta es la misma.
Quien responde mal casi nunca se entera del motivo. Lo más común es el silencio: la propuesta se enfría, el contrato va para quien respondió con seguridad, y la empresa nunca llega a saber que fue un formulario de TI el que decidió la disputa.
Por qué la forma habitual no alcanza
La forma habitual de llevar la TI en una empresa pequeña o mediana es llamar a alguien cuando algo se rompe, confiar en un backup que nadie probó, y dejar que el acceso a los sistemas se acumule a medida que entra y sale personal, sin que nadie retire a quien ya no lo necesita.
Esa forma funciona hasta el día en que alguien pregunta. No existe una lista escrita de quién accede a qué porque nunca hizo falta tenerla. Nadie probó el backup porque "siempre funcionó". No existe un plan de qué hacer si un sistema es vulnerado porque eso nunca pasó, hasta que pasa.
El problema de esta forma habitual no es falta de cuidado. Es falta de registro. La empresa puede estar haciendo bien el backup, puede tener contraseñas fuertes, puede incluso tener un buen antivirus, pero si nada de eso está escrito en ningún lado, la respuesta al cuestionario se convierte en "creo que sí", y "creo que sí" no cierra un contrato.
Comprar otra herramienta de seguridad sin documentar qué hace es otra versión del mismo problema: el cliente que audita no pregunta qué producto usa la empresa, pregunta qué garantiza ese producto —y una herramienta sin un proceso alrededor no garantiza nada que se pueda poner por escrito. Es un patrón que Skills IT ve repetirse: herramienta comprada, proceso nunca escrito, cuestionario reprobado.
Lo que tiene que existir en la práctica
Responder el cuestionario con seguridad no depende de comprar algo nuevo. Depende de que la TI de la empresa tenga, documentados, mecanismos básicos.
Un inventario de sistemas y equipos. Saber qué computadoras, servidores y sistemas tiene la empresa —y quién responde por cada uno— es la base de cualquier respuesta. Sin eso, cada pregunta del formulario se vuelve una investigación de último momento.
Registro de quién accede a qué. Un directorio de usuarios y contraseñas que muestra quién tiene acceso a cada sistema, actualizado cuando alguien deja la empresa, responde de entrada buena parte de un cuestionario de seguridad.
Backup probado, con tiempo de recuperación conocido. No basta con tener una copia de seguridad: hay que saber, mediante una simulación real, en cuánto tiempo la empresa vuelve a operar tras perder un sistema.
Un plan escrito de respuesta a incidentes. Quién avisa a quién, en qué orden, y qué se hace primero si un equipo se infecta o una cuenta es comprometida —por escrito, no guardado en la memoria de una sola persona.
Actualizaciones de seguridad al día. Un sistema desactualizado es la puerta de entrada más común, y "cuando haya tiempo" no es una respuesta que convenza a quien audita.
Un único responsable de la TI. Cuando el cliente pregunta "quién se ocupa de esto en tu empresa", la respuesta correcta es un nombre o un equipo, no una lista de cuatro proveedores distintos, cada uno cubriendo una parte.
Así es como trabaja Skills IT: con inventario y registro de accesos documentados, backup probado mediante simulaciones y cada ticket de soporte registrado con su causa y su solución —la base que cualquier cuestionario de seguridad pide ver.
La ganancia para la empresa
El beneficio de tener esas respuestas listas no aparece solo el día del cuestionario. Aparece antes, en una propuesta que se cierra más rápido porque no necesita una segunda ronda de preguntas. Y aparece después, en un equipo que no abandona el trabajo del día para correr detrás de una auditoría de último momento.
Hay una ganancia financiera directa en esto. Cada semana que un contrato se demora por una pregunta sin respuesta es ingreso que no entra. Y cada vez que la empresa responde con seguridad, se califica para el próximo cliente del mismo tamaño —el tipo de cliente que, casi siempre, también audita.
También hay una ganancia que no aparece en ningún número: decidir con información. Cuando el dueño sabe, sin preguntarle a nadie, cuánto tiempo tarda en recuperarse un sistema o quién tiene acceso al área financiera, deja de depender de la memoria de una sola persona —y empieza a decidir con lo que está escrito.
Preguntas para llevar a la próxima reunión
Antes de que llegue el próximo cuestionario, vale la pena preguntar qué respondería la empresa hoy:
- ¿Alguien sabe, ahora mismo, cuánto tiempo tarda en restaurarse el backup después de un problema serio? Si la respuesta es "no sé" o "creo que rápido", esa ya es la primera pregunta del formulario que reprueba.
- ¿Existe una lista de quién tiene acceso a cada sistema de la empresa? Sin esa lista, toda pregunta sobre control de acceso se convierte en una suposición.
- Si un sistema se cae hoy, ¿está escrito quién avisa a quién, y en qué orden? Resolver eso en el momento cuesta un tiempo que el cliente que audita no perdona.
- ¿La empresa puede listar los equipos y sistemas que usa sin contar de memoria? Un inventario desactualizado vale casi lo mismo que no tener inventario.
- ¿Quien firma el cuestionario de seguridad sabe, de verdad, qué está prometiendo? Responder "sí" a una pregunta que nadie confirmó es el riesgo que aparece después, cuando el cliente lo descubre por su cuenta.
