Qué es el alcance de SOC 2 y dónde se recoge
Un informe SOC 2 tiene cuatro partes. La sección I es la opinión del auditor independiente. La sección II es la aserción de la dirección. La sección III es la descripción del sistema, que redacta la propia empresa. La sección IV recoge los controles, los criterios a los que responden y, en un informe Tipo II, las pruebas que hizo el auditor y sus resultados. El cliente suele empezar por la sección III, porque es la que le dice si el informe habla de lo que está contratando.
El alcance de SOC 2 tiene tres dimensiones que se fijan a la vez. La primera es el sistema: el servicio y todo lo que lo presta. La segunda son los criterios de servicios de confianza que cubre el informe, con Seguridad siempre incluida. La tercera es el tiempo: una fecha concreta en un Tipo I, un periodo de observación en un Tipo II. Este artículo trata la primera dimensión, porque es la que determina cuánto trabajo exige el examen y si el informe responde a la pregunta del cliente.
La descripción no es libre. Se prepara conforme a los Description Criteria de 2018 del AICPA para la descripción del sistema en un informe SOC 2, conocidos como DC section 200, con una guía de aplicación revisada en 2022. La opinión del auditor cubre si la descripción se presenta de forma fiel conforme a esos criterios. Una descripción que omite una parte relevante del sistema, o que describe controles que no funcionan como dice, es un problema para la opinión y no solo para quien la lee.
Cómo trazar los límites del sistema
Los límites separan lo que cubre el informe de lo que queda fuera. Trazarlos bien significa empezar por el cliente, no por el organigrama.
Empezar por lo que compra el cliente
El primer punto de partida son los compromisos que la empresa ya ha asumido. Los contratos, los acuerdos de encargo de tratamiento, los acuerdos de nivel de servicio, la página de seguridad de la web y las respuestas dadas en cuestionarios de seguridad anteriores describen lo que la empresa promete. DC section 200 los llama compromisos principales de servicio, y el sistema dentro del alcance es el que los cumple.
En la práctica, se trata de enumerar los productos y servicios por los que pagan los clientes y preguntarse cuáles usa el cliente que pide el informe. Una empresa con un único producto SaaS lo tiene sencillo. Una empresa que vende una plataforma más un servicio gestionado, o varios productos sobre infraestructuras distintas, tiene que decidir si un solo informe los cubre todos o si el primer informe se centra en el producto que está frenando la venta.
Productos y entornos
Una vez elegidos los servicios, hay que decidir qué entornos les pertenecen. El entorno de producción que atiende a los clientes siempre está dentro. Los entornos de preproducción y desarrollo suelen quedar fuera, pero solo si los datos de clientes nunca llegan a ellos y los controles que los separan de producción están dentro del alcance. Si el equipo copia datos de producción a preproducción para hacer pruebas, preproducción forma parte del sistema lo diga o no la descripción.
Con las regiones y las cuentas del proveedor cloud ocurre lo mismo. Si el producto se ejecuta en dos regiones, o en varias cuentas del mismo proveedor, la descripción debe nombrarlas. Un auditor que encuentra una carga de producción en una cuenta que la descripción no menciona preguntará por qué no está cubierta.
Personas y equipos
El componente de personas abarca a todos los que influyen en el sistema: ingeniería, operaciones, soporte con acceso a datos de clientes y la función de seguridad. También incluye procesos que no son de ingeniería pero controlan el acceso al sistema, como las altas y bajas de RR. HH., la verificación de antecedentes y la formación de concienciación.
Los colaboradores externos y los equipos subcontratados necesitan un tratamiento explícito. Una agencia de desarrollo con permisos para subir código, o un equipo de soporte externo que puede ver registros de clientes, forma parte del componente de personas. La descripción debe indicar quiénes son, qué acceso tienen y qué controles se les aplican.
Datos
El componente de datos describe qué tipos de información trata el sistema y por dónde circula. El contenido de los clientes, los datos personales, las credenciales, los registros y las copias de seguridad necesitan un lugar en la descripción. Un ejercicio útil es seguir un registro de cliente desde que entra en el sistema hasta que se borra, anotando cada componente por el que pasa.
Aquí es donde los límites se mueven con más frecuencia. Un flujo de datos hacia una herramienta de analítica, una plataforma de soporte o un almacén de datos puede meter otro sistema en el alcance, o convertir a un proveedor en una organización subcontratada que la descripción tiene que tratar.
Qué tiene que recoger la descripción del sistema
DC section 200 contiene nueve criterios, de DC1 a DC9. Cada uno es una información que la descripción debe dar. No hay un formato obligatorio, de modo que la sección III puede organizarse por componentes del sistema, por áreas de control o con otra estructura lógica, siempre que responda a todos los criterios.
Servicios, compromisos y requisitos del sistema
DC1 pide los tipos de servicio que se prestan. DC2 pide los compromisos principales de servicio y los requisitos del sistema. Los compromisos son lo que la empresa promete al cliente, como objetivos de disponibilidad, cifrado de sus datos o borrado al terminar el contrato. Los requisitos del sistema son las especificaciones internas que permiten cumplir esas promesas, como la frecuencia de las copias de seguridad, la periodicidad de las revisiones de acceso o los plazos de parcheo.
Esta pareja importa porque los controles de la sección IV se evalúan frente a ella. Si la descripción promete un 99,9 % de disponibilidad y ningún control trata la capacidad o la recuperación, el hueco queda a la vista del auditor y del lector.
Los cinco componentes del sistema
DC3 pide los componentes con los que se presta el servicio: infraestructura, software, personas, procedimientos y datos. La descripción debe explicar cómo funciona cada componente en la práctica, no cómo dice la política que debería funcionar. La infraestructura son el alojamiento, las redes y los equipos. El software son las aplicaciones, bases de datos y herramientas de apoyo. Los procedimientos son los procesos automáticos y manuales que hacen funcionar el servicio.
El punto débil más habitual es el lenguaje genérico. Una descripción que dice "la empresa utiliza cifrado estándar del sector" no le da al lector nada en lo que apoyarse. Una descripción que nombra el servicio de base de datos, indica que los datos se cifran en reposo con claves gestionadas en el servicio de gestión de claves del proveedor cloud y explica quién puede acceder a ellas le da algo que comprobar.
Incidentes y cambios significativos
DC4 exige informar de los incidentes del sistema causados por controles mal diseñados o que no funcionaron, o que provocaron un incumplimiento significativo de los compromisos de servicio. La descripción indica la naturaleza, el momento, el alcance y la resolución de cada uno. Muchas empresas esperan dejar este apartado vacío. Es mejor informar de un incidente con una explicación clara de lo que se corrigió que dejar que el auditor lo descubra durante las pruebas.
DC9 se aplica a los informes Tipo II y pide los cambios significativos del sistema durante el periodo. Una migración a otro proveedor de alojamiento, una nueva línea de producto dentro de los límites, un cambio en la dirección de seguridad o un cambio de entidad jurídica tienen su sitio aquí, con la fecha y cómo era el sistema antes y después.
Criterios, controles complementarios y exclusiones
DC5 trata los criterios de servicios de confianza aplicables y los controles relacionados. DC6 enumera los controles complementarios de la entidad usuaria: los que tiene que aplicar el cliente para que funcionen los controles de la empresa, como gestionar el acceso de sus propios usuarios o proteger sus claves de API. DC7 trata las organizaciones subcontratadas y cómo se tratan. DC8 pide indicar cualquier criterio concreto que no sea pertinente para el sistema, y el motivo.
DC8 es donde las decisiones de alcance se hacen explícitas. Si la empresa no tiene oficinas que alberguen componentes del sistema, los criterios de acceso físico pueden quedar cubiertos por el proveedor cloud. El motivo tiene que ser un hecho sobre el sistema, redactado de forma que el lector pueda comprobarlo.
Proveedores cloud y otros proveedores en la descripción
La mayoría de las empresas que afrontan su primer SOC 2 funcionan sobre un gran proveedor cloud. Ese proveedor es una organización subcontratada: un proveedor de cuyos controles depende la empresa para cumplir sus compromisos. La descripción tiene que indicar cómo se trata. Con el método de exclusión (carve out), los controles del proveedor quedan fuera del informe y se remite al cliente al SOC 2 del propio proveedor. Con el método inclusivo, el examen cubre también esos controles. Las diferencias se explican en nuestra comparativa de SOC 2 Tipo I y Tipo II; casi todas las empresas que trabajan sobre AWS, Azure o Google Cloud usan el método de exclusión.
Excluir al proveedor no significa dejarlo fuera de la descripción. La descripción lo sigue nombrando, explica qué servicios presta y enumera los controles complementarios de la organización subcontratada: los que la empresa da por hecho que aplica el proveedor, como la seguridad física de los centros de datos o la resiliencia de la infraestructura. La empresa necesita además su propio control de seguimiento del proveedor, normalmente una revisión anual de su informe SOC 2 y un registro de cómo se valoraron las excepciones.
No todos los proveedores son organizaciones subcontratadas. Una herramienta para redactar documentos, o una aplicación de diseño sin acceso a datos de clientes, no necesita aparecer en DC7. La prueba es si los controles del proveedor son necesarios para cumplir los compromisos de DC2. Un procesador de pagos, un proveedor de identidad o una plataforma de soporte que guarda registros de clientes suelen pasarla. Cómo evaluar a estos proveedores se trata en nuestro artículo sobre gestión del riesgo de terceros.
Errores de alcance que cuestan ventas
Tres errores explican la mayoría de los problemas de alcance que aparecen cuando el informe ya está emitido, que es cuando más cuesta corregirlos.
Demasiado estrecho: el informe no cubre lo que compra el cliente
El error más caro es un informe que no cubre lo que el cliente está comprando. Ocurre cuando el primer informe se limita a la plataforma principal y el cliente usa un módulo más reciente que funciona sobre otra infraestructura, o cuando se dejó fuera un servicio gestionado prestado por otro equipo para reducir el tamaño del examen.
El equipo de seguridad del cliente leerá la sección III, verá que su producto no aparece y considerará que el informe no le sirve. La empresa tendrá que responder igualmente al cuestionario completo, o esperar al siguiente periodo. Contrastar el alcance con el caso de uso del cliente concreto antes de que empiece el examen lo evita.
Demasiado amplio: controles que nadie ha pedido
El error contrario es meterlo todo. Las herramientas internas, los productos antiguos con pocos clientes, las sociedades adicionales y todas las oficinas suman controles, evidencias y posibles excepciones. Cada excepción aparece en la sección IV y hay que explicársela a todos los lectores del informe, incluidos los que nunca usaron el sistema donde se produjo.
Un alcance amplio también alarga el trabajo previo al periodo de observación, porque cada componente incluido necesita sus controles diseñados y en funcionamiento. Para un primer informe, el alcance que cubre los compromisos que mueven las ventas actuales suele ser el adecuado. Otros productos pueden añadirse en periodos posteriores, a medida que el marco de controles se consolida.
Una descripción que no coincide con el sistema
Todo lo que dice la descripción se puede auditar. Si dice que las revisiones de acceso son trimestrales, el auditor pedirá las revisiones trimestrales. Si describe un proceso de despliegue con revisión obligatoria por pares y el equipo a veces sube cambios directamente, el auditor encontrará esos cambios en el historial.
El problema contrario es igual de real. Si el auditor encuentra un sistema de producción, un equipo con acceso o un flujo de datos que la descripción no menciona, la descripción no está presentada de forma fiel. Eso puede llevar a una opinión con salvedades sobre la propia descripción, que es la parte del informe en la que más confía el cliente. La descripción más segura es la que se redacta a partir del sistema tal como funciona y luego se contrasta con él.
Cuándo hay que cambiar el alcance entre informes
El alcance no es fijo durante toda la vida del programa. Un producto nuevo, una nueva región cloud, una adquisición o un cambio de proveedor de alojamiento cambian el sistema. Los cambios dentro de un periodo Tipo II se informan en DC9. Los cambios entre periodos se incorporan a la siguiente descripción, con los nuevos controles diseñados y en funcionamiento antes de que empiece el siguiente periodo de observación.
Los clientes que tienen el informe anterior necesitan saber cuándo cambia el alcance en el que confían. Una carta puente (bridge letter) de la dirección cubre el tiempo entre el final del último periodo y hoy, pero no puede extender el informe a sistemas que nunca cubrió. Si el producto de un cliente importante entra en el alcance, decirle cuándo lo incluirá el siguiente informe forma parte de gestionar la relación.
La disciplina práctica es mantener un inventario actualizado de los límites del sistema: productos, entornos, cuentas, equipos, proveedores y flujos de datos. Cuando ese inventario cambia, la pregunta sobre el alcance se plantea en ese momento, no el mes antes de que llegue el auditor.
Dónde encaja Qalea
La plataforma de Qalea vincula cada control del marco SOC 2 con los sistemas, las personas y los proveedores que están dentro de los límites, y recoge las evidencias de cada control a medida que se genera el trabajo. Cuando aparece una cuenta, un equipo o un proveedor nuevo, se contrasta con el alcance en lugar de esperar a que lo encuentre el auditor.
El área de Infraestructura añade lo que un ejercicio documental no puede dar: visibilidad de la superficie de ataque externa, la configuración cloud y el código. Eso muestra qué está realmente expuesto y en funcionamiento, de modo que los límites escritos en la sección III coinciden con el sistema que va a examinar el auditor. Más sobre el marco en nuestro espacio dedicado a SOC 2.
