El Shadow IT rara vez comienza con una intención de saltarse las reglas. Aparece cuando un área necesita compartir archivos, automatizar una tarea o atender clientes y encuentra una aplicación SaaS antes de que exista una respuesta corporativa. El problema no es solo que la herramienta haya sido contratada sin pasar por TI. El riesgo crece cuando nadie puede explicar qué datos contiene, quién administra sus accesos, con qué sistemas se integra o cómo se abandonará el servicio.
Bloquear todas las iniciativas puede empujar el uso fuera de la vista. Aprobarlas sin condiciones traslada decisiones críticas a una tarjeta de crédito. Una gestión útil del Shadow IT busca descubrir, asignar responsables y decidir qué aplicaciones regularizar, reemplazar o retirar según su valor y su exposición.
Shadow IT: descubrir sin convertirlo en una cacería
La primera conversación debería explicar para qué se usa cada servicio y qué necesidad resuelve. Si el levantamiento se presenta como una búsqueda de culpables, las áreas ocultarán las herramientas que más necesitan. En cambio, una revisión breve con negocio, TI, seguridad y compras permite identificar plataformas contratadas directamente, versiones gratuitas, extensiones de navegador e integraciones creadas por usuarios.
El Control 2 de CIS recomienda administrar activamente el software para que solo las soluciones autorizadas sean instaladas y ejecutadas. En servicios SaaS, “inventario” no puede limitarse a una lista de nombres: debe mostrar suficiente contexto para tomar una decisión.
Un inventario que permita tomar decisiones
Por cada aplicación conviene registrar propósito, área usuaria, responsable de negocio, administrador, modalidad de autenticación, datos tratados, integraciones, criticidad, costo y fecha de renovación. También importa saber si existe un método de exportación y quién ejecutaría el cierre. Una herramienta barata puede resultar costosa si concentra información sensible o si retirar su integración detiene un proceso comercial.
La guía del NCSC para utilizar SaaS de forma segura propone comprender la finalidad del servicio, sus opciones de autenticación y administración, el manejo de permisos, los datos involucrados y la forma de compartirlos. Estas preguntas convierten un inventario estático en una vista operativa.
Regularizar, reemplazar o retirar
No toda aplicación descubierta merece el mismo tratamiento. Una herramienta sin datos sensibles ni integraciones críticas puede regularizarse con un dueño y una configuración básica. Otra que duplica una capacidad corporativa podría migrarse. Un servicio sin soporte, sin exportación o con controles insuficientes puede requerir retiro, pero solo después de identificar dependencias y conservar la información necesaria.
La decisión debería combinar valor de negocio, sensibilidad de los datos, privilegios concedidos, alcance de las integraciones, continuidad y capacidad del proveedor. El NIST Cybersecurity Framework 2.0 ayuda a ubicar estas decisiones dentro del gobierno del riesgo, en vez de tratarlas como excepciones técnicas aisladas.
La identidad y los datos muestran el costo real
Dos aplicaciones aparentemente similares pueden tener riesgos distintos. Una usa inicio de sesión corporativo, permite revocar usuarios y almacena información pública; la otra conserva contraseñas propias, tiene administradores compartidos y recibe bases de clientes. El mapa de datos personales permite saber qué información entra y sale, mientras la gestión de accesos privilegiados aclara quién puede cambiar configuraciones o extraer contenido.
Integrar el servicio con el proveedor de identidad reduce cuentas olvidadas y facilita el retiro cuando una persona cambia de cargo. Sin embargo, el inicio de sesión único no corrige permisos excesivos dentro de la aplicación. El dueño del servicio debe revisar roles, invitados, enlaces públicos y aplicaciones conectadas con una periodicidad acorde con su criticidad.
El contrato no reemplaza la operación
El Control 15 de CIS plantea inventariar, clasificar, evaluar y supervisar proveedores. Para un SaaS, eso incluye acordar notificación de incidentes, ubicación y devolución de datos, subcontratación, continuidad, niveles de servicio y término de la relación. La cláusula sirve solo si la empresa sabe quién la activará y conserva evidencia de que los controles operan.
También debe definirse una salida antes de depender del servicio. ¿Los datos pueden exportarse en un formato utilizable? ¿Quién revoca integraciones y claves? ¿Cómo se comprueba la eliminación? ¿Cuánto tiempo necesita el proceso? Estas respuestas evitan que la renovación automática sea la única estrategia de continuidad.
Cómo recuperar control sin centralizar cada decisión
Una ruta rápida y conocida reduce el incentivo a contratar por fuera. Las aplicaciones de bajo riesgo pueden seguir un conjunto simple de requisitos; las que procesan datos sensibles, conceden acceso amplio o sostienen procesos críticos necesitan revisión adicional. Los umbrales deben ser comprensibles para negocio y no depender de interpretar una política extensa.
Los logs de seguridad aportan trazabilidad cuando responden preguntas concretas sobre accesos, cambios e integraciones. No todos los servicios ofrecerán el mismo nivel de registro, por lo que esa limitación debe influir en la clasificación y en los controles compensatorios.
El resultado esperado no es una lista perfecta, sino un proceso que detecta nuevas aplicaciones, decide con criterios consistentes y revisa lo que cambia. Una auditoría de seguridad puede tomar una muestra de servicios, reconstruir su alta y salida, y convertir las brechas encontradas en una hoja de ruta. Así, la empresa conserva la velocidad que dio origen al SaaS sin renunciar a la responsabilidad sobre sus datos y operaciones.
