Requisitos de seguridad para una plataforma de conteo de personas SOC2

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.

Por qué el conteo de personas merece escrutinio SOC2

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.

Type I frente a Type II: la distinción que ahorra disgustos

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 cinco criterios aplicados al conteo de personas

Los Trust Services Criteria de SOC2 se traducen en requisitos concretos cuando el sistema en cuestión cuenta visitantes:

• Seguridad: cifrado en tránsito desde el sensor hasta la plataforma, autenticación de dispositivos con certificados (no contraseñas compartidas entre tiendas), y segmentación de red documentada para los sensores.
• Disponibilidad: SLA con métricas medibles y almacenamiento local en el sensor cuando la conexión cae, para que un corte de red no signifique datos perdidos.
• Integridad del procesamiento: aquí conecta la seguridad con la precisión. Si el proveedor garantiza contractualmente un mínimo del 96% de precisión —con valores típicos del 98–99% cuando la iluminación, el diseño de la tienda y el comportamiento de los visitantes lo permiten—, el informe debe evidenciar cómo se valida y monitoriza ese dato, no solo cómo se protege.
• Confidencialidad: controles de acceso por rol y por tienda; el gerente regional no debe ver los datos de otra región, y el proveedor debe demostrar quién de su propio personal accede a sus cifras y por qué.
• Privacidad: el criterio más sencillo de cumplir si la tecnología está bien diseñada. Un sistema que trabaja con recuentos agregados, sin identificación personal y con exclusión de empleados, reduce drásticamente la superficie de riesgo frente a soluciones basadas en vídeo identificable.

Residencia de datos, retención y arquitectura

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.

Preguntas que debe incluir su RFP

• ¿Puede facilitar el informe SOC2 Type II completo bajo NDA, incluyendo excepciones señaladas por el auditor?
• ¿La gestión de sensores y su firmware están dentro del alcance del informe o excluidos como subservicio?
• ¿Soporta SSO/SAML con nuestro proveedor de identidad y aprovisionamiento automatizado de usuarios?
• ¿Dónde residen los datos, quién puede accederlos y con qué plazos de retención por tipo de dato?
• ¿Cuál es el plazo contractual de notificación de incidentes de seguridad?
• ¿Cómo se valida la precisión de conteo de forma continua y qué recurso tenemos si cae bajo el mínimo contractual?

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.