Pentesting para el informe SOC 2
SOC 2 mide los controles de la organización contra los Trust Services Criteria del AICPA, y el pentesting es la evidencia técnica que el auditor espera para demostrar que esos controles resisten un ataque real. Strike testea de forma continua con IA y validación humana experta, durante todo el período de observación. Strike apoya la auditoría; el informe lo emite la firma CPA.
Pensado para el período de observación del Type II
Equipos de SaaS y fintech cuyo deal enterprise está esperando un informe que el área de compras del prospecto ya pidió.
Organizaciones dentro de una ventana Type II que necesitan evidencia fechada de todo el período, no un reporte al borde de él.
Equipos que quieren un solo programa de testing alimentando SOC 2, ISO 27001 y PCI DSS en vez de tres contrataciones desconectadas.
Qué pide SOC 2 — y dónde entra el pentesting
SOC 2 no es una certificación. Es un informe de atestiguamiento, escrito y firmado por una firma CPA con licencia, sobre cómo los controles de la organización se mapean a los Trust Services Criteria del AICPA — los criterios de 2017, todavía vigentes, con sus puntos de enfoque revisados en 2022. En ninguna parte de esos criterios se nombra al pentest como un control obligatorio. Aparece una sola vez, como uno de varios tipos de evaluación que la gerencia puede correr. Esa única mención es la razón por la que casi toda auditoría SOC 2 igual incluye uno. Fuente: AICPA, 2017 Trust Services Criteria (with revised points of focus – 2022) (fecha de acceso: 28 de julio de 2026).
Un informe Type I describe si los controles están adecuadamente diseñados en una fecha específica. Un Type II dice si operaron efectivamente a lo largo de un período de observación, normalmente de tres a doce meses. Para un Type I, un reporte de testing reciente suele alcanzar. En un Type II el auditor está muestreando una ventana — y un solo test fechado cuatro semanas antes de que esa ventana abriera no dice nada sobre los meses que vienen después.
CC4.1 — Actividades de monitoreo. Se espera que la gerencia corra evaluaciones continuas y separadas que confirmen que el control interno está presente y funcionando. Los puntos de enfoque listan las opciones: auditoría interna, evaluaciones de cumplimiento, escaneos de vulnerabilidades, evaluaciones de seguridad y pentesting. Es un menú, no un mandato — y el pentesting es el ítem de ese menú que el auditor reconoce más rápido. Fuente: AICPA, 2017 Trust Services Criteria (with revised points of focus – 2022) (fecha de acceso: 28 de julio de 2026).
CC7.1 — Detección. Hay que detectar cambios de configuración que introduzcan nuevas vulnerabilidades e identificar las recién descubiertas en los componentes propios. El escaneo cumple con la letra. El testing que encadena hallazgos hasta un exploit que funciona es lo que indica cuáles de esas vulnerabilidades importan de verdad.
Según el alcance, los criterios de control de acceso de CC6 y los de incidentes de CC7.2 también se apoyan en evidencia de testing: controles que resisten intentos reales de evadirlos, y anomalías que se detectan en lugar de quedar solo registradas.
En LATAM la mayoría de los programas SOC 2 no arrancan por un objetivo de seguridad. Arrancan porque un prospecto enterprise en Estados Unidos no firma sin el informe: la fintech, el SaaS o el procesador de pagos que quiere vender afuera descubre que el SOC 2 es la puerta de entrada. Esa fecha límite termina definiendo la decisión de testing: se contrata el test más barato que tape el hueco, llega un PDF, y en el Type II aparece que el auditor quería evidencia de todo el período y no un documento con una sola fecha.
Alcance y metodología, las calificaciones de quienes probaron, cada hallazgo con su severidad, la fecha en que se remedió y la evidencia de que la corrección fue reevaluada y aguantó. En un Type II las fechas importan más que cualquier otra cosa: el auditor está verificando que la evidencia cubra la ventana de observación, no solo sus bordes.
Strike no emite reportes SOC 2 y nunca lo hará — solo una firma de contadores públicos licenciada puede hacerlo. Lo que Strike entrega es la evidencia técnica detrás de esos reportes: pentesting continuo ejecutado por IA con validación humana experta antes de la entrega al cliente, retesting cuya disponibilidad depende del alcance suscrito, y un rastro de evidencia con fechas que recorre todo el período de observación en lugar de detenerse después de una sola contratación.
Métrica reportada por Strike en esta página: 97% de precisión / 3% de falsos positivos. Es una cifra que Strike reporta sobre su propia plataforma, no un benchmark de terceros; el alcance, la definición y las fechas de medición están en cómo medimos los resultados.
¿SOC 2 exige pentesting?
Más o menos. SOC 2 no exige explícitamente realizar pruebas de penetración en los Criterios de Servicios de Confianza de la AICPA. Sin embargo, dado que criterios como CC4.1 —actividades de supervisión— y CC7.1 —identificación de vulnerabilidades— requieren probar y supervisar los controles, los auditores esperan casi universalmente una prueba de penetración anual realizada por un tercero como evidencia estándar.
Conviene empezar por lo que es un reporte SOC 2. Es una atestación, escrita y firmada por una firma de contadores públicos licenciada, sobre cómo los controles de una organización se alinean con los Trust Services Criteria de la AICPA. No es una certificación y no existe un certificado SOC 2. Lo que se recibe es la opinión de esa firma, la descripción del sistema y las pruebas que esa firma ejecutó.
Dónde se ubica el pentesting es una pregunta distinta de si está nombrado. Es ampliamente aceptado como evidencia de auditoría. Eso es una afirmación sobre la práctica y no sobre una obligación: el auditor reconoce rápido un reporte de testing, quien lee el reporte espera verlo, y es el artefacto que muestra con más claridad un control resistiendo un ataque. Nada de eso lo convierte en un requisito nombrado.
Lo que no pudimos verificar, dicho sin vueltas. Si los Trust Services Criteria nombran el pentesting a nivel de criterio: no se encontró en los materiales públicos revisados el 29 de julio de 2026. Qué criterios específicos lo referencian: no se encontró en los materiales públicos revisados el 29 de julio de 2026. No vamos a citar números de criterio que no pudimos leer en una fuente pública, y conviene leer con cierta cautela una página de proveedor que sí lo haga.
Cómo usar esto cuando el auditor lo pide. Conviene preguntar en qué se apoya el pedido: en las propias descripciones de control o en un criterio que el auditor pueda señalar. En cualquier caso la evidencia a producir es la misma: alcance, método, competencia de quienes probaron, hallazgos con severidad, fechas de remediación y prueba de que la corrección se sostuvo, con fechas dentro del período de observación. Strike apoya ese programa; no emite reportes SOC 2.
Fuente: AICPA & CIMA, SOC 2 (audit and assurance), fecha de acceso: 29 de julio de 2026. Strike apoya programas de auditoría y cumplimiento; los reportes SOC 2 los emite una firma de contadores públicos licenciada después de su propio examen.
SOC 2 y pentesting, en preguntas
¿SOC 2 exige un pentest?
No. Los Trust Services Criteria nunca lo listan como un control obligatorio. El pentesting aparece como uno de los ejemplos de evaluaciones que la gerencia puede correr bajo CC4.1, junto con escaneos de vulnerabilidades, auditoría interna y evaluaciones de cumplimiento. En la práctica la mayoría de los auditores lo pide, y la mayoría de los compradores que leen el informe espera verlo. Fuente: AICPA, 2017 Trust Services Criteria (with revised points of focus – 2022) (fecha de acceso: 28 de julio de 2026); la descarga de este documento requiere una cuenta gratuita en AICPA.
¿Type I o Type II — qué cambia para el testing?
El Type I examina el diseño de los controles en una sola fecha, así que un reporte de testing reciente suele alcanzar. El Type II examina la efectividad operativa a lo largo de tres a doce meses, así que el auditor quiere evidencia repartida en esa ventana. Ahí es exactamente donde un test anual empieza a quedar corto y el testing continuo empieza a pagarse solo.
¿Qué evidencia se le entrega al auditor?
El reporte, más alcance, metodología, calificaciones de los testers, severidades, fechas de remediación y evidencia del retest. Si los hallazgos figuran corregidos y reverificados con fechas que caen dentro del período de observación, la conversación es corta.
¿Cuándo conviene testear?
Antes de que abra el período de observación si se va hacia un Type II, y después de forma continua durante todo el período. Testear solo al final deja los primeros meses sin evidencia, y un hallazgo crítico descubierto tarde se convierte en una corrida de remediación contra la fecha del informe.
¿Strike emite el informe SOC 2?
No. Los informes SOC 2 los emiten firmas CPA con licencia después de su propio examen. Strike aporta la evidencia de pentesting, los registros de retest y la documentación que apoya programas de auditoría y cumplimiento en la que ese examen se apoya.
¿Cuánto cuesta y cuánto tarda?
Strike es una suscripción continua dimensionada según la superficie de ataque, no un proyecto de precio cerrado, así que el costo sigue al alcance y a los activos. El setup toma menos de 5 minutos una vez que están listos los datos del objetivo y los accesos, y los primeros hallazgos suelen llegar dentro de 1–2 horas desde que arranca el testing, para alcances soportados — lo suficientemente rápido cuando hay un deal esperando el informe.
Con la confianza de los equipos de seguridad que lideran la industria.
Experiencia humana.
Poder de la IA.
Seguridad superior.
Ya sea que su empresa esté creciendo rápido, cerrando acuerdos con grandes compañías o simplemente cansada de reportes sin valor, la ayudamos a construir una estrategia de seguridad que avance más rápido que las amenazas.
