Una empresa de logística contrató a un proveedor de plataformas en la nube para alojar sus datos de clientes y su sistema de gestión de pedidos. El proveedor tenía una certificación ISO 27001, y el equipo de TPRM de la empresa de logística la aceptó como confirmación de que los controles de seguridad del proveedor cumplían la norma internacional. Durante una auditoría de seguimiento, el auditor revisó el certificado ISO 27001 del proveedor y su declaración de aplicabilidad. La declaración de alcance de la certificación decía: "El sistema de gestión de la seguridad de la información de la infraestructura de TI corporativa interna que respalda las operaciones de negocio de la organización". La plataforma de alojamiento en la nube orientada al cliente, el entorno donde residían realmente los datos de la empresa de logística, la había creado y la gestionaba una división independiente que no estaba dentro del alcance de la certificación. Las pruebas de penetración, las revisiones del control de acceso, la gestión del cifrado y las prácticas de respuesta a incidentes que acreditaba la certificación ISO 27001 se aplicaban a la infraestructura de TI corporativa. No se aplicaban a la división de alojamiento en la nube. La empresa de logística había heredado la confianza de una certificación que certificaba un ámbito organizativo distinto del servicio que estaba contratando.
¿Qué es realmente el problema de los malentendidos sobre la herencia de controles?
La herencia de controles es la práctica de confiar en una certificación, auditoría o evaluación de un tercero como evidencia de que determinados controles están implantados, en lugar de evaluar directamente esos controles. Cuando un proveedor tiene un informe SOC 2 Tipo II, un certificado ISO 27001 o una atestación de cumplimiento de PCI-DSS, los clientes pueden heredar la garantía de esas certificaciones para los controles y el alcance que cubren, lo que reduce la necesidad de evaluar directamente controles que un tercero de prestigio ya ha evaluado. Es un enfoque legítimo y eficiente para recopilar evidencias que reduce la carga de evaluación tanto para los proveedores como para los clientes.
El malentendido surge cuando los clientes heredan la garantía de las certificaciones sin verificar que su alcance cubre los activos, servicios y controles relevantes para su relación concreta. Toda certificación importante tiene un alcance definido: los límites de lo que se evaluó y de aquello a lo que se aplica la certificación. Los certificados ISO 27001 especifican el alcance del sistema de gestión y los activos que comprende. Los informes SOC 2 definen la descripción del sistema que abarca los servicios evaluados y la infraestructura que los respalda. Las atestaciones de cumplimiento de PCI-DSS cubren el entorno de datos de titulares de tarjetas. Cada certificación está delimitada por su alcance, y los controles que quedan fuera de ese límite no están cubiertos por la garantía de la certificación.
El problema del estrechamiento del alcance es donde el malentendido genera riesgo con más frecuencia. Los alcances de las certificaciones de los proveedores suelen ser más limitados de lo que parecen. Una certificación ISO 27001 de una empresa con varios productos puede cubrir solo la línea de productos que solicitó la certificación. Un informe SOC 2 de un proveedor SaaS puede excluir expresamente la infraestructura de desarrollo, los subencargados y los controles físicos del centro de datos. Una atestación de PCI-DSS de un procesador de pagos puede cubrir el entorno de procesamiento de pagos y excluir la plataforma de análisis de fraude que también trata datos de titulares de tarjetas. Cada limitación es legítima: las certificaciones cubren aquello para lo que se diseñaron. El problema son los clientes que suponen que la certificación cubre toda la relación con el proveedor sin leer la declaración de alcance.
- Alcance de la certificación no revisado: certificado aceptado como garantía sin leer la declaración de alcance
- Alcance más limitado de lo supuesto: un alcance de TI corporativa aplicado a la suposición de un servicio orientado al cliente
- Sistemas excluidos no evaluados: los controles de los sistemas fuera del alcance de la certificación no se evalúan directamente
- Suposición sobre la cobertura de los subencargados: suponer que la certificación cubre subencargados que están expresamente excluidos
- Antigüedad de la certificación no considerada: certificaciones antiguas que cubren el entorno tal como existía en el momento de la evaluación, no su estado actual
Por qué es importante
Los malentendidos sobre la herencia de controles son importantes para TPRM porque crean un tipo concreto de falsa garantía: la confianza que proviene de una certificación genuina y bien considerada que en realidad no cubre los activos relevantes para el riesgo del cliente. La certificación es real. La garantía que ofrece es real para su alcance definido. El error es la suposición del cliente de que el alcance incluye su servicio relevante. Este tipo de falsa garantía es especialmente insidioso porque se basa en evidencia genuina que tiene verdadera autoridad en lo que cubre; el error está por completo en la suposición sobre el alcance, no en la certificación en sí.
El problema de las exclusiones del alcance de SOC 2 es su manifestación práctica más frecuente. Los informes SOC 2 definen expresamente en la descripción del sistema el sistema dentro del alcance: los servicios, la infraestructura y los controles evaluados. Muchos informes SOC 2 incluyen exclusiones expresas: "los subencargados no están dentro del alcance de este examen", "la seguridad física de la infraestructura del centro de datos la proporciona [proveedor de nube] y no se evalúa en este informe", "el entorno de desarrollo no está dentro del alcance del sistema". Los clientes que aceptan un informe SOC 2 como evidencia de una garantía de seguridad integral sin leer la descripción del sistema ni las exclusiones han aceptado una garantía para un subconjunto de los controles relevantes.
Dónde se equivocan la mayoría de los equipos
El fallo más constante es aceptar las certificaciones como evidencia sin leer las declaraciones de alcance ni las exclusiones. Las declaraciones de alcance no son letra pequeña: son la definición de lo que cubre la certificación y de lo que no cubre. Un evaluador que confirma "certificado ISO 27001" sin leer la declaración de alcance ha confirmado la existencia de la certificación sin confirmar su pertinencia.
- Aceptar una certificación como garantía sin leer las declaraciones de alcance
- Exclusiones del SOC 2 no revisadas: no se examinan la descripción del sistema ni los sistemas excluidos
- Ninguna comprobación de la pertinencia del alcance: si el alcance de la certificación cubre los activos relevantes para la relación
- Antigüedad de la certificación no evaluada: cuándo se evaluó el entorno por última vez
- Requisitos de controles complementarios no evaluados: controles cuya responsabilidad la certificación del proveedor atribuye al cliente
Cómo se ve una buena práctica
Los programas maduros de herencia de controles leen las declaraciones de alcance y las exclusiones antes de confiar en las certificaciones como garantía, confirman que el alcance de la certificación cubre los servicios y activos concretos relevantes para la relación con el cliente, e identifican y evalúan directamente los controles que quedan fuera del alcance de la certificación.
- Lea las declaraciones de alcance: para cada certificación en la que se confía, se revisa la declaración de alcance y se confirman los activos cubiertos
- Identifique las exclusiones del alcance: los sistemas y controles expresamente excluidos del alcance de la certificación se identifican y se evalúan directamente
- Confirme la pertinencia del servicio: el servicio y la infraestructura concretos relevantes para la relación con el cliente están dentro del alcance de la certificación
- Revise la sección de controles complementarios: se revisan los controles complementarios del SOC 2 que debe implementar el cliente
- Compruebe la vigencia de la certificación: cuándo se realizó la evaluación más reciente y si el alcance refleja el entorno actual
Herramientas
Revisión del informe SOC 2: directrices de AICPA, revisión de la descripción del sistema de SOC 2
Los informes SOC 2 siguen una estructura definida: descripción de la organización de servicios, criterios de servicios de confianza aplicables, descripción de los controles y resultados de las pruebas de los controles. La sección de descripción del sistema especifica lo que está dentro del alcance. La sección de controles complementarios de la entidad usuaria especifica lo que debe implementar el cliente. Para los profesionales de TPRM, leer ambas secciones antes de confiar en un informe SOC 2 aporta la información sobre la pertinencia del alcance y los controles complementarios que no ofrece la aceptación de la certificación sin leerla.
Revisión del certificado ISO 27001: declaraciones de alcance del certificado, Declaración de Aplicabilidad
Los certificados ISO 27001 especifican el alcance en el propio certificado. La Declaración de Aplicabilidad documenta qué controles se incluyen, cuáles se excluyen y con qué fundamento. Para los profesionales de TPRM, solicitar la Declaración de Aplicabilidad junto con el certificado ISO 27001 aporta la información detallada del alcance que resume la breve declaración de alcance del certificado.
Desafíos de gobernanza
El desafío de gobernanza de la herencia de controles es el esfuerzo de lectura. Los informes SOC 2 pueden ser documentos extensos. Las declaraciones de aplicabilidad de ISO 27001 pueden ser hojas de cálculo exhaustivas. La ventaja de eficiencia de la herencia de controles se reduce si cada evaluador debe leer cada documento completo. La solución de gobernanza es una lectura centrada en el alcance: evaluadores formados para localizar y evaluar de inmediato las declaraciones de alcance, las descripciones del sistema, las exclusiones y los requisitos de controles complementarios sin leer todas las páginas.
- Forme a los evaluadores para que lean las declaraciones de alcance y las exclusiones: no todas las páginas, sino las secciones que definen el alcance
- Exija la confirmación del alcance antes de confiar en las certificaciones: confirmación documentada de que el alcance cubre los activos relevantes
- Identifique y evalúe directamente los controles excluidos: los controles que quedan fuera del alcance de la certificación se evalúan directamente
- Haga un seguimiento de la vigencia de la certificación: cuándo se realizó la evaluación más reciente
- Revise los controles complementarios: se identifican e implementan las obligaciones de control del cliente derivadas de las certificaciones del proveedor
Si usted forma parte de un equipo pequeño
Para las tres certificaciones en las que más se apoya su programa de TPRM, busque la declaración de alcance o la descripción del sistema y léala específicamente para responder a esta pregunta: ¿cubre el alcance el servicio o la infraestructura concretos a través de los cuales este proveedor accede a nuestros datos o los trata? En el caso de los informes SOC 2, lea también la sección de controles complementarios de la entidad usuaria para identificar qué debe implementar su organización. Esas dos lecturas, el alcance y los controles complementarios, revelarán si sus suposiciones sobre la herencia de controles son correctas.
- Lea las declaraciones de alcance de todas las certificaciones en las que se apoya TPRM
- Confirme que el alcance cubre el servicio y la infraestructura concretos relevantes para la relación con el cliente
- Revise las secciones de controles complementarios de la entidad usuaria del SOC 2
- Identifique y evalúe directamente los controles que quedan fuera del alcance de la certificación
Qué exigir
Pregunte directamente:
"Respecto de su certificación ISO 27001, ¿puede confirmar que el alcance cubre [nombre del servicio concreto e infraestructura], en concreto, que el sistema que trata nuestros datos está dentro de la declaración de alcance de la certificación?"
"Respecto de su informe SOC 2, ¿qué sistemas y servicios están expresamente excluidos del alcance? En concreto, ¿[sistema indicado] está dentro o fuera del alcance del examen?"
Evidencia que debe esperar
- Declaración de alcance de la certificación o descripción del sistema que confirme la cobertura del servicio pertinente
- Lista de los sistemas expresamente excluidos de la descripción del sistema de SOC 2
- Declaración de Aplicabilidad de ISO 27001, si se solicita
- Controles complementarios de la entidad usuaria del informe SOC 2
A un proveedor que aporta un certificado ISO 27001 se le debe pedir que confirme que el alcance que figura en el certificado cubre el servicio y la infraestructura concretos relevantes para la relación con el cliente. El certificado es genuino. La cuestión es el alcance que cubre.
Cómo demostrarlo
- Registros de la revisión de las declaraciones de alcance de todas las certificaciones en las que se confía
- Documentación de la confirmación de la pertinencia del alcance
- Registros de la evaluación directa de los controles excluidos
- Registros de implementación de los controles complementarios de la entidad usuaria
Conclusión clave
La herencia de controles funciona cuando el alcance coincide. Falla en silencio cuando no coincide. La certificación ISO 27001 es real y los controles que cubre se evalúan realmente conforme a la norma. La plataforma de alojamiento en la nube donde residen los datos del cliente está fuera del alcance de la certificación. La garantía heredada de la certificación no se extiende a los activos de los que depende el riesgo del cliente. Leer la declaración de alcance es el paso de gobernanza que distingue la garantía pertinente de la garantía supuesta. El certificado es genuino. El alcance está delimitado. Lo que hay que leer es ese límite.