SOC 2 en 90 días: cómo un SaaS sanitario superó su primera auditoría

Proyecto representativo. Detalles del cliente anonimizados y datos específicos modificados bajo NDA.

El correo que lo desencadenó todo no venía de un equipo de seguridad. Lo reenvió un fundador, tres líneas, con el asunto “podríamos perder el contrato”. Una empresa de SaaS sanitario de unas 40 personas tenía un contrato enterprise en manos del departamento legal, y el grupo de riesgo de proveedores del comprador había respondido con una única condición: entregar un informe SOC 2 antes de la puesta en producción. La empresa no tenía ninguno. Le quedaban 90 días antes de que se cerrara la ventana de renovación.

Así es como empieza en realidad la mayoría del trabajo de preparación para SOC 2. No porque un equipo de seguridad decida madurar, sino porque un cliente retiene un contrato hasta que demuestras que te tomas la seguridad en serio. Noventa días es realmente ajustado, pero es viable para un Type II con una ventana de observación corta si te mueves rápido y dejas de tratar la auditoría como un trámite de papeleo. La trampa es el alcance. Los equipos suelen quemar el primer mes discutiendo qué incluir en lugar de recopilar evidencias.

Esto es lo que hicimos, lo que reveló la evaluación de brechas y el puñado de cambios que les permitió aprobar.

Puntos clave

• La preparación para SOC 2 consiste en demostrar que los controles funcionan a lo largo del tiempo, no en redactar políticas la semana antes de que llegue el auditor. Pon en marcha el reloj de las evidencias el primer día.
• Para un Type II con una ventana corta, la vía más rápida es un alcance ajustado: el sistema de producción que toca los datos de clientes, y nada más.
• Las brechas que hacen fracasar las primeras auditorías son mundanas. Sin revisiones de acceso, sin prueba de bajas, un registro de logs que corre pero que nadie lee. No ataques exóticos.
• Conecta la recopilación de evidencias con la identidad, la configuración de la nube y la gestión de tickets para que los controles generen su propia prueba en lugar de depender de capturas de pantalla.
• Una evaluación de preparación antes de la auditoría convierte el “esperamos que apruebe” en una lista conocida de brechas con responsables y fechas.

Qué exige SOC 2 realmente a una empresa

SOC 2 es un informe de atestación elaborado por una firma CPA autorizada frente a los Trust Services Criteria de la AICPA. Todo SOC 2 cubre Security, conocido como common criteria, y opcionalmente se añade Availability, Confidentiality, Processing Integrity o Privacy. Un informe Type I dice que tus controles estaban diseñados correctamente en una fecha concreta. Un Type II dice que realmente funcionaron durante un periodo, normalmente de tres a doce meses. Los compradores enterprise casi siempre quieren Type II, porque una instantánea centrada solo en el diseño no prueba nada sobre cómo te comportas en el día a día.

Para un SaaS sanitario, la Confidentiality suele estar dentro del alcance, y encima se apila una segunda realidad: si manejas datos de salud protegidos, HIPAA sigue aplicando. SOC 2 no sustituye a HIPAA. En este proyecto ambos se solapaban lo suficiente como para que mapeáramos cada control una vez y satisficiéramos ambos requisitos allí donde coincidían, lo que ahorró al equipo hacer el mismo trabajo dos veces.

Aquí está la parte que se le escapa a la gente. SOC 2 no te entrega una lista de controles que implementar. No existe una checklist maestra de la AICPA. Tú defines tus propios controles frente a los criterios, y el auditor comprueba si esos controles existen y funcionan. Esa libertad es precisamente la razón por la que los equipos sin guía se atascan.

El plan de 90 días que ejecutamos

Dividimos la ventana en tres fases y pusimos en marcha el reloj de las evidencias de inmediato, en lugar de esperar a que el conjunto de políticas fuera perfecto.

Días 1 a 20: alcance, evaluación de brechas y el reloj de las evidencias

Primero fijamos el alcance, y fue una batalla. El instinto del cliente era incluirlo todo: el sitio de marketing, una herramienta interna de analítica, tres cuentas de AWS separadas. Lo recortamos a la única cuenta de producción que aloja la aplicación y procesa los datos de clientes. La expansión del alcance es el error más caro de una primera auditoría. Cada sistema que incorporas multiplica las evidencias que tienes que producir y los controles que debes mantener en funcionamiento durante todo el periodo de observación.

Luego, la evaluación de preparación. Recorrimos cada control de los common criteria y lo marcamos como presente, parcial o ausente. El resultado fue un registro de brechas sencillo con un responsable y una fecha límite por fila, no un informe de 60 páginas que nadie abre después del arranque.

Días 20 a 55: remediación

Aquí es donde ocurre el trabajo de verdad. Levantamos los controles que faltaban, conectamos la recopilación de evidencias con las herramientas que el equipo ya usaba y pusimos en marcha la ventana de observación para que el auditor tuviera un historial operativo genuino que muestrear en lugar de una semana de actividad falsificada a toda prisa.

Días 55 a 90: operar, recopilar y la auditoría

Los controles funcionaban mientras las evidencias se acumulaban solas. Hicimos un simulacro interno frente a la lista de solicitudes previstas del auditor, corregimos los dos puntos que aún estaban flojos y entregamos un paquete de evidencias limpio a la firma CPA.

Qué encontramos en la evaluación de brechas

Ninguna de las brechas serias era glamurosa. Ese es el patrón en casi todos los proyectos de primera preparación para SOC 2 que llevamos. Lo que hace fracasar las auditorías es la higiene operativa, no los zero-days.

Sin revisiones de acceso de usuarios. Nadie se había sentado nunca a preguntar quién podía llegar a producción y si todavía lo necesitaba. Dos antiguos contratistas seguían teniendo usuarios IAM activos, uno de ellos casi un año después de terminar el contrato. A CC6.1 y CC6.2 les importa esto, y el acceso es una de las primeras cosas que un auditor muestrea.

Las bajas eran informales. Cuando alguien se iba, el portátil volvía, pero el acceso se revocaba “cuando alguien se acordaba”. Sin ticket, sin marca de tiempo, sin prueba. Un auditor no acepta el “siempre lo hacemos”. Elige a una persona que se fue del listado de RR. HH. y te pide que muestres el registro de desaprovisionamiento con una fecha.

El registro de logs estaba activado pero desatendido. CloudTrail estaba habilitado, algo que a los equipos les encanta señalar. Los logs aterrizaban en un bucket de S3 que ningún humano y ninguna alerta tocaron jamás. La detección que nunca miras no es un control. Es almacenamiento con una factura mensual.

Sin gestión formal de cambios. Los ingenieros fusionaban y desplegaban mediante pull requests revisadas por pares en GitHub, lo que en realidad era una práctica sólida. Pero nada por escrito ataba esa práctica a un control, así que desde la silla del auditor no existía.

La gestión de proveedores era una hoja de cálculo tocada por última vez en 2023. Un SaaS sanitario se apoya en subprocesadores, y los criterios esperan que los tengas controlados y vigiles su postura de seguridad.

Fíjate en cuántos de estos son problemas de documentación y de prueba, y no de “esto no lo hacemos en absoluto”. Una gran parte de la preparación para SOC 2 consiste en hacer legibles, para alguien que no estaba en la sala, prácticas buenas pero invisibles.

Cómo cerramos las brechas sin frenar a ingeniería

La regla que fijamos con el cliente fue tajante: automatizar la evidencia para que un control produzca su propia prueba, y recurrir a un proceso manual solo donde la automatización no merezca el esfuerzo.

Para identidad y acceso, pusimos a todo el mundo detrás de SSO, forzamos MFA y establecimos una revisión de acceso trimestral recurrente, con el resultado almacenado como un artefacto fechado en lugar de un hilo de Slack que se pierde al desplazarse. Para el desaprovisionamiento, atamos las bajas a una plantilla de ticket, de modo que cada salida genera ahora un registro con marca de tiempo de la eliminación de acceso. Ese único cambio convirtió un control imposible de probar en uno auditable.

Para el registro de logs y la monitorización no fuimos a comprar una gran plataforma. Encaminamos los logs de CloudTrail y de la aplicación hacia un destino con alertas sobre los eventos que importan: uso de la cuenta root, cambios en las políticas de IAM e inicios de sesión fallidos en la consola por encima de un umbral. Luego documentamos quién revisa las alertas y con qué frecuencia. Así se leía en su matriz de controles:

Control ID : CC7.2
Statement  : Security events are logged and monitored; anomalies alert the on-call.
Evidence   : CloudTrail -> log sink; alert rules (root use, IAM change, failed logins);
             on-call rotation; sample alert + triage ticket from the observation window.
Frequency  : Continuous; reviewed weekly.
Owner      : Head of Engineering

Para la gestión de cambios no cambiamos nada en cómo trabajaban los ingenieros. Redactamos la política para que coincidiera con la realidad ya existente: pull request, revisión obligatoria, comprobaciones de CI, rama main protegida. Luego usamos el historial de GitHub existente como evidencia. Alinear el documento con la práctica es mucho más rápido, y mucho más honesto, que injertar un proceso nuevo la semana en que aparece el auditor.

Las políticas fueron lo último. Redactamos las políticas de seguridad, control de acceso, respuesta a incidentes, gestión de cambios y gestión de proveedores para describir controles que ya estaban funcionando. Las políticas escritas antes que la práctica describen una fantasía, y los auditores son muy buenos detectando la brecha entre una política reluciente y lo que los logs dicen que ocurrió de verdad.

El resultado

Aprobaron. La firma CPA emitió un informe SOC 2 Type II sin excepciones en el alcance de los common criteria, lo que es un resultado sólido para una primera auditoría. Planteado como un resultado representativo para una empresa de este tamaño: la evaluación de preparación sacó a la luz alrededor de una docena de brechas significativas, la mayoría se cerraron dentro de la fase de remediación, y el contrato enterprise que puso todo en marcha llegó a la puesta en producción.

La victoria más duradera fue más silenciosa. La recopilación de evidencias se convirtió en un proceso de fondo. Las revisiones de acceso, los registros de bajas y el triaje de alertas generan ahora sus propios artefactos, de modo que el próximo periodo de auditoría es sobre todo mantenimiento en lugar de otra carrera de 90 días. Esa es la verdadera línea entre perseguir un informe y operar un programa de seguridad.

Cómo ayuda CyberXplore

Ejecutamos la preparación para SOC 2 igual que ejecutamos esta. Acotar el alcance, evaluar con honestidad, cerrar las brechas que los auditores prueban de verdad e integrar evidencias para que tus controles se demuestren solos. Mapeamos los controles a los Trust Services Criteria, hacemos el simulacro previo a la auditoría frente a la lista de solicitudes y trabajamos junto a tu firma CPA para que nada te embosque de camino al informe. Si tienes un comprador esperando un informe o un plazo que no elegiste, pide un presupuesto y te diremos con honestidad si tu ventana es realista y qué hace falta para cumplirla.

FAQ

¿De verdad se puede obtener SOC 2 en 90 días?

Puedes alcanzar la preparación para SOC 2 y completar un Type II con una ventana de observación corta en unos 90 días si el alcance es ajustado y empiezas a recopilar evidencias de inmediato. La restricción es el periodo de observación, ya que un Type II exige que los controles funcionen a lo largo del tiempo y eso no se puede comprimir a cero. Algunas firmas CPA no observan por debajo de tres meses, así que un recurso habitual es hacer primero un Type I para satisfacer a un comprador urgente, seguido de un periodo Type II.

¿Cuál es la diferencia entre SOC 2 Type I y Type II?

El Type I certifica que tus controles están diseñados de forma apropiada en una única fecha. El Type II certifica que esos controles realmente funcionaron de forma eficaz durante un periodo, normalmente de tres a doce meses. Los compradores enterprise suelen exigir el Type II porque prueba el comportamiento a lo largo del tiempo, no solo la intención un día concreto.

¿Cubre SOC 2 el cumplimiento de HIPAA para un SaaS sanitario?

No. SOC 2 y HIPAA están separados. SOC 2 es una atestación frente a los Trust Services Criteria de la AICPA, mientras que HIPAA es una regulación estadounidense que cubre los datos de salud protegidos. Se solapan en muchos controles de seguridad, así que puedes mapear el trabajo para satisfacer ambos, pero un informe SOC 2 no te hace cumplir HIPAA por sí solo.

¿Qué Trust Services Criteria deberíamos incluir?

Todo SOC 2 debe incluir Security, los common criteria. Añades Availability, Confidentiality, Processing Integrity o Privacy en función de lo que prometes a los clientes. La mayoría de las empresas SaaS empiezan con Security más Availability y Confidentiality, y añaden Privacy solo cuando asumen compromisos de privacidad concretos.

¿Qué hace que las empresas fracasen en su primera auditoría?

Casi nunca fallos de seguridad exóticos. Son evidencias que faltan: sin revisiones de acceso, sin registros de bajas fechados, un registro de logs que nadie monitoriza y políticas que describen un proceso que el equipo no sigue en realidad. Una evaluación de preparación antes de que llegue el auditor es la forma más barata de encontrar esas brechas mientras aún tienes tiempo de corregirlas.

¿Cuánto de esto se puede automatizar?

Una gran parte. Las evidencias de identidad y acceso, las comprobaciones de configuración de la nube, el historial de cambios y la monitorización de logs pueden generar todos sus propios artefactos de forma programada. Automatizar la recopilación de evidencias es lo que convierte SOC 2 de un simulacro de incendio recurrente en una tarea de mantenimiento, y es el único cambio que más rentabilidad da a lo largo de los futuros periodos de auditoría.