Pentesting para tu informe SOC 2

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 tus controles 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.

Un informe Type I describe si tus 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.

CC7.1 — Detección. Tienes que detectar cambios de configuración que introduzcan nuevas vulnerabilidades e identificar las recién descubiertas en tus componentes. El escaneo cumple con la letra. El testing que encadena hallazgos hasta un exploit que funciona es lo que te dice cuáles de esas vulnerabilidades importan de verdad.

Según tu 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 tu evidencia cubra la ventana de observación, no solo sus bordes.

Strike no emite informes SOC 2 y nunca lo va a hacer — solo una firma CPA con licencia puede. Lo que Strike entrega es la evidencia técnica detrás de ellos: pentesting continuo ejecutado por IA y validado por hackers expertos, con 97% de precisión y menos de 3% de falsos positivos, un retest documentado adjunto a cada hallazgo, y un rastro de evidencia fechado que dura todo tu período de observación en vez de terminar después de una sola contratación.

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 tu informe espera verlo.

¿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 le entrego al auditor?

El reporte, más alcance, metodología, calificaciones de los testers, severidades, fechas de remediación y evidencia del retest. Si tus 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 vas 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 de tu 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 lista para auditoría en la que ese examen se apoya.

¿Cuánto cuesta y cuánto tarda?

Strike es una suscripción continua dimensionada según tu 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.