El cuestionario de seguridad llega a la semana seis del proceso de compra. El proveedor de conteo de personas ha superado la prueba piloto, el equipo de operaciones está convencido, y entonces el equipo de seguridad pregunta por el informe SOC2. La respuesta —un PDF de dos páginas titulado "Resumen de seguridad"— detiene el proyecto en seco. Esta escena se repite en casi todas las adquisiciones empresariales de analítica retail, y suele ocurrir porque nadie definió los requisitos de seguridad antes de evaluar la precisión de los sensores.
Una plataforma de conteo de personas SOC2 no es simplemente "un proveedor con un certificado". Es un proveedor cuyos controles operativos —gestión de accesos, cifrado, respuesta a incidentes, gestión de cambios— han sido verificados por un auditor independiente durante un periodo de observación. Para un director de TI que va a conectar sensores en 200 tiendas a su red corporativa, la diferencia entre una afirmación de marketing y un informe auditado es la diferencia entre asumir riesgo y transferirlo.
El argumento habitual de los proveedores es que los datos de conteo son "solo números agregados" y, por tanto, de bajo riesgo. Es un argumento incompleto. Los datos de tráfico revelan el rendimiento comercial por tienda, por hora y por campaña: información que un competidor pagaría por obtener y que un consejo de administración considera confidencial. Además, los sensores son dispositivos físicos dentro de su red. Un sensor mal gestionado, con firmware sin parchear o credenciales por defecto, es un punto de entrada, independientemente de lo inocuos que sean los datos que transmite.
Por eso los equipos de seguridad tratan estas plataformas como cualquier otro SaaS con presencia en la infraestructura: exigen evidencia auditada, no promesas. SOC2 es el marco que la mayoría de compradores norteamericanos y multinacionales reconocen; en Europa suele evaluarse junto a ISO 27001 y, siempre, junto al RGPD.
Un informe SOC2 Type I confirma que los controles existían en una fecha concreta. Un Type II confirma que funcionaron durante un periodo, normalmente de seis a doce meses. La diferencia práctica es enorme: un proveedor puede preparar un Type I en semanas; un Type II exige disciplina operativa sostenida. Si su organización va a depender de la plataforma para decisiones de personal, alquileres o aforos, exija Type II o, como mínimo, un Type I con fecha comprometida para el Type II en el contrato.
Lea también el alcance del informe. Un detalle que los implementadores veteranos conocen bien: muchos informes SOC2 de proveedores de analítica cubren la plataforma cloud pero excluyen —mediante el llamado "carve-out"— el pipeline de actualización de firmware de los sensores y a los subencargados de infraestructura. Es decir, precisamente los componentes que viven dentro de su red pueden quedar fuera de la auditoría. Pida la lista de organizaciones de subservicio y pregunte explícitamente si la gestión de dispositivos está dentro del alcance.
Los Trust Services Criteria de SOC2 se traducen en requisitos concretos cuando el sistema en cuestión cuenta visitantes:
Para los equipos de compliance europeos, SOC2 nunca es suficiente por sí solo. Necesitan saber dónde residen los datos físicamente, cuánto tiempo se retienen y bajo qué base jurídica del RGPD se procesan. Aquí la arquitectura importa: un proveedor que ofrece tanto despliegue hosted como en nube privada le permite adaptar la solución a su política de residencia de datos en lugar de negociar excepciones. Vemco, por ejemplo, diseñó su plataforma sobre el principio de conteo agregado sin identificación personal y con opciones de nube privada, precisamente porque sus clientes empresariales operan en jurisdicciones con requisitos de residencia divergentes.
Sobre la retención: exija un calendario explícito en el contrato. Los datos de tráfico agregado pueden conservarse legítimamente durante años para análisis interanual, pero los registros técnicos de los sensores (logs, diagnósticos, imágenes de calibración si existen) deben tener plazos de borrado cortos y verificables.
Un consejo práctico: haga estas preguntas antes del piloto, no después. Los pilotos generan inercia interna, y esa inercia es exactamente lo que aprovechan los proveedores con carencias de cumplimiento para que su equipo de seguridad acabe cediendo. Verifique cada certificación específica con el documento en mano; ningún proveedor serio se ofende cuando le piden evidencia.
Si está preparando una RFP de conteo de personas y necesita respuestas concretas sobre arquitectura de despliegue, opciones de nube privada, exclusión de empleados y documentación de cumplimiento, hable con el equipo de Vemco Group: solicite una sesión técnica con su equipo de seguridad presente en vemcogroup.com/contact-us y obtenga la documentación que su departamento de compliance va a pedir de todos modos.