¿SOC 2 exige pentest y escaneo de vulnerabilidades?

¿SOC 2 exige hacer un pentest?

SOC 2 no exige un pentest. Los Trust Services Criteria lo citan en un punto de enfoque de CC4.1, como un ejemplo de las evaluaciones independientes con las que una organización puede comprobar que sus controles funcionan. Si necesitas uno, y cada cuánto, se deduce de tu evaluación de riesgos y de los controles que describes en tu informe.

Los criterios los publica el AICPA. Su versión vigente son los Trust Services Criteria de 2017 con los puntos de enfoque revisados en 2022, un documento gratuito al que solo se accede con una cuenta del AICPA. La redacción que citamos aquí viene de firmas de auditoría que lo reproducen. Linford & Co, una firma de CPA que realiza auditorías SOC 2, lo dice sin rodeos: «the simple answer is no», la respuesta corta es que no. CC4.1 pide a la organización evaluaciones continuas o independientes para asegurarse de que los componentes del control interno están presentes y funcionan. Su punto de enfoque cita el pentest junto a las certificaciones independientes, como las ISO, y la auditoría interna, como tipos de evaluación que puede usar la dirección. El artículo de Linford es de junio de 2021, anterior a la revisión de 2022.

La revisión de 2022 no lo convirtió en una regla. BARR Advisory, otra firma de auditoría SOC 2, cita al AICPA sobre los puntos de enfoque revisados: «do not, in any way, alter the criteria in the 2017 TSC», no alteran en modo alguno los criterios de los TSC de 2017.

Así que, sobre el papel, el pentest es opcional, y la decisión te toca justificarla a ti. Linford aconseja que cualquier empresa que ofrezca sus servicios a través de una web pública e interactiva se plantee seriamente hacer uno, con la frecuencia y el alcance fijados por una evaluación de riesgos rigurosa.

Hay un caso en el que la elección ya está hecha. Según la firma de auditoría TrustNet, la descripción del sistema es tu propio desglose de sistemas, servicios y controles, redactado por ti y revisado por el auditor. La opinión del auditor dice después si esos controles están bien diseñados (Type I) y si han funcionado a lo largo del tiempo (Type II). Si tu descripción o tu política dicen que haces un pentest al año, ese pentest se ha convertido en uno de tus controles, y el auditor te pedirá el informe.

¿SOC 2 obliga a escanear vulnerabilidades?

SOC 2 no nombra el escaneo de vulnerabilidades como requisito. CC7.1 pide procedimientos de detección y monitorización que identifiquen los cambios de configuración que introducen vulnerabilidades nuevas y tu exposición a las recién descubiertas. Su punto de enfoque «Conducts Vulnerability Scans» describe escaneos periódicos y tras cualquier cambio significativo, con las deficiencias encontradas corregidas a tiempo.

Linford & Co reproduce el punto de enfoque: los escaneos deben hacerse «on a periodic basis and after any significant change in the environment», de forma periódica y después de cualquier cambio significativo en el entorno, y la organización corrige a tiempo lo que encuentran. Su veredicto es el mismo que para el pentest, no hay requisito, con una advertencia: «it may be tough for a user organization to accept a clean SOC 2 report» sin ninguna referencia al escaneo, es decir, a una organización usuaria le puede costar aceptar un informe SOC 2 limpio que no mencione ningún escaneo.

El resumen de BARR Advisory sobre la revisión de 2022 no incluye CC7.1 entre los cambios: en operaciones del sistema, nombra el tratamiento de la información confidencial en CC7.3. El criterio de gestión de cambios, CC8.1, sí ganó puntos de enfoque sobre la «identification, testing, and implementation of software patches», la identificación, prueba e implantación de parches de software. Actualizar una dependencia vulnerable es aplicar un parche, así que la parte de corrección del escaneo también cae dentro de la gestión de cambios.

El punto de enfoque no nombra ninguna herramienta, frecuencia ni alcance. Tú decides qué abarca «el entorno» (tu código, sus dependencias, los contenedores, la configuración cloud, los hosts), lo escribes en tu política, y el auditor te exige lo que escribiste.

¿Qué diferencia hay entre un escaneo de vulnerabilidades y un pentest?

Un escaneo de vulnerabilidades es automático: una herramienta compara tu código, tus dependencias o tus hosts con debilidades conocidas y enumera lo que encuentra. Un pentest lo hacen personas, que usan herramientas y su propio criterio para explotar debilidades y mostrar hasta dónde llegaría un atacante. En SOC 2, el escaneo apoya CC7.1, y el pentest, CC4.1.

Linford & Co traza la misma frontera. Una evaluación de vulnerabilidades «is an automated activity», una actividad automatizada que se hace con una herramienta, mientras que un pentest lo realizan una o varias personas que explotan vulnerabilidades y errores de configuración con herramientas automáticas y sus propias técnicas. Para un equipo que desarrolla software, «escaneo» abarca varios tipos de herramienta: el análisis estático del código (SAST), el análisis de dependencias (SCA), la detección de secretos y las comprobaciones de los ficheros de infraestructura y de las imágenes de contenedor.

¿Cada cuánto hay que escanear para SOC 2?

Escanea con la frecuencia que diga tu política, y después de cada cambio significativo. SOC 2 no fija ningún intervalo: el punto de enfoque «Conducts Vulnerability Scans» de CC7.1 pide escaneos periódicos y tras cualquier cambio significativo en el entorno. Un escaneo en cada pull request cubre los cambios, y un escaneo programado cubre el resto.

CC7.1 tiene dos mitades, y cada una necesita su propio disparador. La primera son los cambios de configuración que introducen vulnerabilidades, que detectas escaneando el propio cambio, en CI, antes del merge. La segunda es la exposición a vulnerabilidades recién descubiertas, que detectas escaneando según un calendario el código que no has vuelto a tocar, porque siguen saliendo avisos de seguridad nuevos sobre dependencias antiguas. En nuestro escaneo del 3 de noviembre, cuatro de los nueve hallazgos críticos de dependencias venían de avisos publicados entre julio y septiembre de 2026. Un escaneo lanzado en junio, sobre exactamente el mismo código, no podría haberlos señalado.

Escribe los dos disparadores en tu política, con un plazo de corrección por severidad para lo que encuentren los escaneos. El auditor puede elegir cualquier hallazgo del periodo y compararlo con tus plazos, así que elige plazos que puedas cumplir.

¿Qué evidencias pide un auditor de SOC 2?

El auditor pide registros: que los escaneos se ejecutaron cuando decía tu política, qué cubrieron, qué encontraron y qué pasó con cada hallazgo, corregido antes de su plazo o aceptado como excepción con un motivo y un aprobador. En un informe Type II la opinión cubre todo un periodo, así que los registros también tienen que cubrirlo.

Un informe SOC 2 es un examen que realiza un CPA independiente y con licencia conforme a las normas de atestación del AICPA, en palabras del propio comunicado del AICPA. En un Type II, la opinión del CPA cubre cómo funcionaron tus controles durante un periodo. Para la gestión de vulnerabilidades, eso se traduce en unas pocas preguntas:

¿Sirven los escáneres open source como evidencia para SOC 2?

Los escáneres open source aportan la detección, la mitad de la evidencia SOC 2. El 3 de noviembre de 2026 pasamos Trivy, Gitleaks y Opengrep sobre OWASP Juice Shop, con 383 hallazgos en bruto en cuatro ficheros JSON, en 56 segundos. Ninguno nombra el commit escaneado, un responsable, un plazo ni un estado: el registro que muestrea el auditor.

Usamos OWASP Juice Shop en su versión 20.3.0, publicada el 11 de octubre de 2026. Su README la presenta como «probably the most modern and sophisticated insecure web application», probablemente la aplicación web insegura más moderna y sofisticada, así que las cifras que siguen no dicen nada de un código normal: muestran la forma de lo que te entregan las herramientas. Juice Shop no incluye lockfile, así que para el escaneo de dependencias generamos uno ese mismo día a partir de una copia de su package.json, con los scripts de instalación de npm desactivados. Después lanzamos cuatro comandos:

trivy fs --scanners vuln --format json --output trivy-sca.json sca/
trivy fs --scanners misconfig,secret --format json --output trivy-repo.json juice-shop/
gitleaks dir juice-shop --report-format json --report-path gitleaks.json
opengrep scan --config opengrep-rules/javascript --config opengrep-rules/typescript \
  --config opengrep-rules/terraform --json --output opengrep.json juice-shop/

Resultados de cuatro escaneos open source de OWASP Juice Shop 20.3.0, lanzados el 3 de noviembre de 2026. Escaneamos la etiqueta v20.3.0 en el commit f189f52, con las reglas comunitarias de Opengrep en el commit f1d2b56, la configuración por defecto de Trivy y sin ningún ajuste. Las cuatro ejecuciones tardaron 56 segundos de tiempo real, con la actualización de la base de datos de Trivy incluida:

Cada herramienta encontró lo que estaba hecha para encontrar, y quedan cuatro obstáculos entre estos ficheros y una evidencia SOC 2:

1. Duplicados. Los cinco secretos que encontró Trivy están entre los 69 de Gitleaks, en el mismo fichero y la misma línea. De los 54 hallazgos de Terraform de Opengrep, 17 están en la misma línea que un hallazgo de Trivy y 34 a tres líneas o menos de uno. Sin fusión, un mismo problema se convierte en dos tickets y dos plazos.
2. Tres escalas de severidad. Trivy gradúa de critical a low, Opengrep de error a info, y Gitleaks no gradúa nada. Una política que dice «hallazgos críticos corregidos en N días» necesita una sola escala, así que alguien tiene que traducir las otras dos a esa.
3. Cobertura. Opengrep escaneó 1.306 ficheros y registró 32 errores de parseo y análisis parciales, en una sección de errores que solo ves si lees el fichero. Un auditor que pregunta si el escaneo cubrió el código necesita esa línea.
4. El propio registro. Los ficheros de Trivy llevan una marca de tiempo de creación y la ruta escaneada. Los de Opengrep no llevan ninguna marca de tiempo. En modo directorio, Gitleaks deja vacíos sus campos de commit y de fecha. Ningún fichero tiene responsable, plazo ni estado.

Los escáneres open source, por su parte, cumplen bien. Nuestras pruebas de herramientas SAST open source que comprobamos en GitHub y de seis escáneres de secretos open source probados sobre un repositorio con secretos plantados muestran que puedes cubrir el código y los secretos sin pagar por un escáner. El volumen es la otra mitad del trabajo, y nuestro artículo sobre lo que convierte los hallazgos SAST en ruido explica por qué 149 hallazgos de código en bruto son una cola de triaje, no 149 vulnerabilidades.

Para convertir esos ficheros en evidencia necesitas una cola por repositorio, donde se fusionan los hallazgos de todas las herramientas, cada uno recibe un responsable y un plazo según tu política, y su historial se conserva: abierto, corregido, aceptado como excepción. Se puede montar con una herramienta open source de gestión de vulnerabilidades como DefectDojo, con tickets o con una plataforma. CybeDefend Open Source se encarga de esta parte: ejecuta los escáneres que elijas, cualquier herramienta que escriba SARIF, y reúne lo que encuentran en una sola cola deduplicada, gratis y en tus servidores. Sale pronto, y la lista de espera de CybeDefend Open Source ya está abierta.

¿Qué cambia cuando el código lo escriben agentes de IA?

Los criterios SOC 2 son los mismos cuando programan agentes de IA, pero hay más cambios significativos, así que el escaneo de CC7.1 debe correr en cada cambio, no solo por calendario. Los criterios que el AICPA propone para 2027 añaden puntos de enfoque sobre IA, obligatorios solo en encargos que empiecen a partir del 31 de diciembre de 2027.

La proporción de código escrito por agentes puede ser alta. El 3 de noviembre de 2026, 482 de los 509 commits fusionados en la rama principal del repositorio de nuestra propia web durante los 90 días anteriores llevaban un trailer de coautoría de Claude Code. A ese ritmo, tres cosas cambian para SOC 2:

• El escaneo hace la lectura línea a línea. Un gate de merge que escanea cada pull request es la comprobación que se ejecuta en cada cambio, que es justo lo que piden CC7.1 y CC8.1. Nuestro artículo sobre las comprobaciones de seguridad de la pull request de un agente de IA recorre ese gate.
• Las dependencias llegan con las funcionalidades. Un agente que añade un paquete añade una entrada que el escaneo programado tiene que vigilar, y cada actualización que hace es un parche según CC8.1.
• Los tests en verde prueban menos. Un agente suele escribir una funcionalidad y sus tests en la misma sesión. Sus tests comprueban lo que quería construir, así que una regla que se le escapó en el código puede faltar también en los tests, y la CI sigue en verde. Un escáner que se ejecuta desde la CI es una comprobación que el agente no escribió.

Los propios criterios se están moviendo. El 28 de octubre de 2026, el AICPA sometió a comentarios un borrador (exposure draft) de nuevos Trust Services Criteria para SOC 2. Su comunicado enumera nuevos puntos de enfoque sobre «AI governance, model monitoring, prompt manipulation, data poisoning», es decir, gobernanza de la IA, monitorización de modelos, manipulación de prompts y envenenamiento de datos, además de la transparencia de los resultados generados por IA, la gestión de los datos de entrenamiento y la toma de decisiones automatizada. Los comentarios están abiertos hasta el 15 de enero de 2027. Si se aprueban, los nuevos criterios se aplicarían a los encargos que empiecen a partir del 31 de diciembre de 2027, con adopción anticipada permitida. El comunicado no dice si estos puntos de enfoque alcanzan a los agentes de código, y el borrador en sí exige una cuenta del AICPA, así que no lo hemos leído. Hasta que los nuevos criterios sean definitivos y estén en vigor, tu auditoría usa los criterios de 2017 con los puntos de enfoque de 2022.

¿Qué tienes que tener listo antes de la auditoría SOC 2?

Necesitas una política escrita de gestión de vulnerabilidades, escaneos que se ejecuten según un calendario y en cada cambio, un registro por hallazgo con su responsable, su plazo y su desenlace, excepciones aprobadas y, si tu evaluación de riesgos lo pide, un informe de pentest, todo ello cubriendo el periodo de auditoría completo.

1. La política dice qué, cuándo y con qué rapidez. El alcance del escaneo, el calendario, los disparadores, un plazo por severidad y quién puede aprobar una excepción.
2. Se escanea cada cambio. Código, dependencias, secretos y ficheros de infraestructura en cada pull request, la abra una persona o un agente, tras un gate que rechace cualquier hallazgo crítico.
3. El calendario detecta los avisos nuevos. Un escaneo nocturno o semanal de la rama principal y de las imágenes que tienes en producción, para las vulnerabilidades publicadas después de escribir el código.
4. Un hallazgo, un registro. Fusionado entre herramientas, en una sola escala de severidad, con su responsable, su plazo, su estado y su historial.
5. Las excepciones quedan por escrito. El alcance, el motivo, el aprobador y la fecha de caducidad.
6. El pentest está planificado. Un alcance sacado de tu evaluación de riesgos, el informe guardado, los hallazgos graves corregidos y vueltos a comprobar.
7. El informe cubre el periodo. Un documento generado a partir de los registros, no una hoja de cálculo montada la semana antes de que llegue el auditor.

Escaneo en cada cambioUn registro por hallazgoResponsable y plazoCorregido, o excepción aprobadaEn el informe del periodo

Los puntos 2, 5 y 7 son lo que hace la plataforma AppSec de CybeDefend. Analiza cada repositorio en busca de debilidades del código (SAST), dependencias (SCA), secretos, infraestructura como código, contenedores y pipelines de CI/CD. Una política de seguridad escrita como código bloquea el merge ante un hallazgo crítico y deja salir los riesgos menores con un aviso, y cada excepción se acota a una ruta, lleva fecha, justificación y la aprobación de una persona con nombre, y deja una línea en el registro de auditoría. Los informes de seguridad relacionan los hallazgos con el OWASP Top 10 y el CWE Top 25, por organización, equipo o proyecto, y se exportan en PDF para el auditor o en JSON para una herramienta GRC. Nosotros estamos haciendo el mismo ejercicio: la auditoría SOC 2 Type II de CybeDefend está en curso. Si preparas la tuya con un equipo que programa con agentes, podemos revisarla contigo paso a paso.

Preguntas frecuentes

¿Necesito un pentest para el SOC 2 Type 2?

No. Los informes Type I y Type II usan los mismos criterios, y ninguno de ellos exige un pentest. Un Type II comprueba que tus controles funcionaron durante un periodo, así que si tu política incluye un pentest anual, el auditor comprobará que se hizo dentro del periodo y que se gestionaron sus hallazgos.

¿Cada cuánto hay que hacer un pentest para SOC 2?

Los criterios no fijan ningún intervalo. Lo fijan tu evaluación de riesgos y tu política, y el auditor comprueba que cumpliste lo que escribiste. Un cambio grande en lo que expone tu sistema, como una API pública nueva o un producto nuevo, es un buen motivo para repetir el pentest antes de la siguiente fecha prevista.

¿Basta con escanear vulnerabilidades para la auditoría SOC 2?

Para CC7.1, un programa de escaneo es lo que los auditores esperan ver, con registros de cómo se gestionó cada hallazgo. Un escaneo no sustituye la evaluación de tus controles según CC4.1, que puede ser un pentest, una auditoría interna o una certificación independiente.

¿Hace falta SAST o análisis de código para SOC 2?

Ningún criterio nombra el SAST. El punto de enfoque de CC7.1 cubre las vulnerabilidades y los errores de configuración de tu entorno, y CC8.1 pide que los cambios de software se prueben y se aprueben antes de implantarse. Si desarrollas software, escanear el código y sus dependencias en cada cambio es la forma más sencilla de demostrar ambas cosas.

¿Valen los escáneres open source para una auditoría SOC 2?

Sí. Los criterios no nombran ninguna herramienta, y el auditor comprueba que los escaneos se ejecutaron como dice tu política y que se gestionaron los hallazgos. Los escáneres open source funcionan si mantienes el registro que los rodea: las fechas, el commit escaneado, los hallazgos fusionados entre herramientas, los responsables, los plazos y los desenlaces.

¿Qué es el CC7.1 de SOC 2?

CC7.1 es el criterio común de detección y monitorización. Pide a la organización que use procedimientos que identifiquen los cambios de configuración que introducen vulnerabilidades nuevas y su exposición a vulnerabilidades recién descubiertas. Uno de sus puntos de enfoque es hacer escaneos de vulnerabilidades de forma periódica y después de los cambios significativos.

¿Qué pide el criterio CC4.1 de SOC 2?

CC4.1 es el criterio común de actividades de supervisión. Pide a la organización evaluaciones continuas o independientes para confirmar que los componentes del control interno están presentes y funcionan. Su punto de enfoque cita el pentest, las certificaciones independientes como las ISO y la auditoría interna como ejemplos de esas evaluaciones.

¿Qué cambia con los criterios SOC 2 que se proponen para 2027?

El AICPA publicó el 28 de octubre de 2026 un borrador que reestructura partes de los criterios y añade puntos de enfoque sobre IA, entre ellos la gobernanza de la IA, la manipulación de prompts, el envenenamiento de datos y la transparencia de los resultados generados por IA. Los comentarios se cierran el 15 de enero de 2027. Si se aprueban, los criterios serían obligatorios en los encargos que empiecen a partir del 31 de diciembre de 2027, con adopción anticipada permitida.