Recopilación de evidencias SOC 2: lo que realmente buscan los auditores
Descubra exactamente qué evidencias solicitan los auditores SOC 2, cómo recopilarlas eficientemente y los errores comunes que provocan retrasos en la auditoría. Una guía práctica para equipos de ingeniería y cumplimiento SaaS.
GRCTrail Team
La recopilación de evidencias es donde el cumplimiento de SOC 2 se vuelve real. Sus políticas describen lo que se compromete a hacer. Sus controles son los mecanismos que aplican esos compromisos. Las evidencias son la prueba de que esos controles realmente operaron — de manera consistente, durante todo su período de observación.
Para un informe SOC 2 Type I, las evidencias demuestran que los controles están adecuadamente diseñados en un momento específico. Para un informe Type II, el nivel es más alto: las evidencias deben demostrar que los controles operaron eficazmente durante un período sostenido — generalmente de 6 a 12 meses. Cada mes de esa ventana importa. Una sola brecha en las evidencias puede resultar en una opinión con salvedades o una excepción en su informe que los clientes empresariales examinarán.
Las empresas SaaS que tratan la recopilación de evidencias como una carrera de último minuto antes de la temporada de auditoría terminan con registros incompletos, equipos en pánico e informes retrasados. Las empresas que integran la recopilación de evidencias en sus operaciones diarias descubren que la auditoría en sí se convierte en un ejercicio sencillo. Esta guía cubre exactamente qué evidencias solicitan los auditores, organizadas por área de control, y cómo construir un sistema de recopilación que haga que SOC 2 sea sostenible.
Tipos de evidencias SOC 2
Antes de profundizar en áreas de control específicas, comprenda las categorías de evidencia con las que trabajan los auditores. Los diferentes controles requieren diferentes tipos de prueba.
Capturas de pantalla. Capturas puntuales de configuraciones del sistema, ajustes de seguridad y vistas de paneles. Las capturas de pantalla son útiles para demostrar que una configuración está habilitada (aplicación de MFA, configuración de cifrado, reglas de firewall) pero solo prueban el estado en el momento de la captura. Para auditorías Type II, puede necesitar capturas de pantalla de múltiples puntos durante el período de observación.
En la práctica: Siempre incluya la barra de URL del navegador, una marca de tiempo y suficiente contexto para identificar el sistema. Una captura de pantalla de una página de configuración de MFA es útil. Una captura recortada de un interruptor sin identificación del sistema no lo es.
Logs. Registros generados por el sistema de eventos: logs de acceso, logs de cambios, pistas de auditoría, logs de autenticación. Los logs son la forma más sólida de evidencia porque se generan automáticamente y son difíciles de fabricar. Los auditores prefieren los logs sobre los registros manuales porque representan lo que realmente sucedió, no lo que alguien recuerda que sucedió.
En la práctica: Asegúrese de que la retención de logs cubra todo su período de observación más un margen. Si su período de observación es de enero a diciembre y sus logs rotan después de 90 días, perderá evidencia de los primeros nueve meses.
Tickets. Registros de seguimiento de incidencias de sistemas como Jira, Linear o ServiceNow. Los tickets proporcionan evidencia de gestión de cambios (cambios de código que pasan por flujos de trabajo de aprobación), manejo de incidentes (cronogramas de respuesta y resolución) y gestión de acceso (solicitudes de aprovisionamiento y desaprovisionamiento).
En la práctica: Los tickets solo son útiles si contienen los metadatos correctos: marcas de tiempo, asignados, registros de aprobación, transiciones de estado y artefactos vinculados. Un ticket que dice “Desplegar actualización” sin registro de revisión o aprobación no demuestra gestión de cambios.
Informes. Salidas formales de herramientas y procesos de seguridad: resultados de escaneo de vulnerabilidades, informes de pruebas de penetración, resúmenes de revisión de acceso, documentos de evaluación de riesgos. Los informes típicamente demuestran actividades de control periódicas.
En la práctica: Los informes deben estar fechados, atribuidos a la persona o herramienta que los generó, y mostrar hallazgos claros y acciones de remediación. Un informe de escaneo de vulnerabilidades que enumera 47 hallazgos críticos sin evidencia de trabajo de remediación es peor que ningún informe — demuestra que identificó riesgos y no hizo nada al respecto.
Documentos. Políticas firmadas, registros de capacitación, actas de reuniones, aserciones de la gerencia. Los documentos demuestran actividades de gobernanza que pueden no producir evidencia generada por el sistema.
En la práctica: Los documentos necesitan fechas, firmas o aprobaciones e información de versión. Las actas de reuniones deben incluir asistentes, temas discutidos y decisiones tomadas — no solo “reunión de revisión de seguridad” sin contenido.
Configuraciones. Plantillas de Infraestructura como Código, configuraciones de pipeline de CI/CD, reglas de firewall, ACLs de red. Para empresas SaaS que gestionan infraestructura a través de código, estas configuraciones son evidencia poderosa porque tienen control de versiones y son auditables.
En la práctica: Dirija a los auditores a su repositorio de IaC con hashes de commit específicos. Una configuración de Terraform que aplica cifrado en todos los buckets S3, registrada en Git con historial de revisión, es evidencia más limpia que una captura de pantalla de la consola de AWS.
Atestaciones. Reconocimientos firmados, aserciones de la gerencia y declaraciones formales. Se utilizan donde la evidencia automatizada no está disponible — por ejemplo, reconocimientos de políticas por parte de empleados o la aserción de la gerencia sobre la completitud de la descripción del sistema.
En la práctica: Las atestaciones deben estar firmadas y fechadas. Las firmas digitales (DocuSign, sistemas internos de reconocimiento) son aceptables y preferidas sobre las firmas físicas porque incluyen marcas de tiempo a prueba de manipulaciones.
Evidencias por área de control
Los auditores SOC 2 organizan sus solicitudes de evidencia alrededor de las categorías de Common Criteria. Esto es lo que esperan para cada área principal, con ejemplos específicos relevantes para empresas SaaS.
Controles de acceso (CC6)
El control de acceso es el área más intensiva en evidencias de una auditoría SOC 2. Los auditores prueban todo el ciclo de vida del acceso de usuario — aprovisionamiento, gestión continua y desaprovisionamiento — y muestrean extensamente.
Listas de acceso de usuario con roles. Proporcione listas de acceso actuales para todos los sistemas en el alcance mostrando el rol de cada usuario, los permisos y la fecha en que se otorgó el acceso. Los auditores las cruzarán con su directorio de empleados y registros de RRHH.
Ejemplo SaaS: Exporte listas de usuarios de AWS IAM, Okta, GitHub y su base de datos de producción mostrando nombres de usuario, roles asignados, membresías de grupo y fechas de último inicio de sesión.
Evidencia de aplicación de MFA. Demuestre que la autenticación multifactor se aplica — no solo está disponible — para todos los sistemas requeridos. Capturas de pantalla de configuración mostrando que MFA es obligatorio, más logs de autenticación mostrando desafíos MFA durante eventos de inicio de sesión.
Ejemplo SaaS: Configuración de política de Okta mostrando que MFA es requerido para todos los usuarios que acceden a sistemas de producción, más logs de eventos de autenticación mostrando verificación de factor MFA para una muestra de eventos de inicio de sesión.
Revisiones trimestrales de acceso con remediación. Aquí es donde muchas empresas SaaS tropiezan. Los auditores quieren ver cuatro revisiones de acceso completadas durante un período de observación de 12 meses, cada una mostrando el revisor, los sistemas revisados, las discrepancias encontradas y la remediación tomada. Si una revisión encontró una cuenta que debía eliminarse, el auditor quiere ver el ticket de eliminación y la confirmación.
Ejemplo SaaS: Un informe trimestral mostrando que todos los usuarios de AWS IAM fueron revisados por el líder de ingeniería, se identificaron dos cuentas pertenecientes a antiguos contratistas, se crearon tickets de Jira para su eliminación y las cuentas se deshabilitaron dentro de las 48 horas con capturas de pantalla de confirmación.
Tickets de incorporación y desvinculación. Proporcione tickets mostrando que el aprovisionamiento de acceso sigue su procedimiento documentado y que los empleados terminados se desaprovisionan dentro del plazo que especifica su política.
Ejemplo SaaS: Un ticket de Jira mostrando la solicitud de acceso de un nuevo ingeniero, la aprobación del gerente, la creación de cuenta en Okta con el rol especificado y la marca de tiempo de finalización — todo dentro del SLA de su política. Un ticket de desvinculación correspondiente para un empleado que se fue mostrando la revocación de acceso en todos los sistemas dentro de las 24 horas de la terminación.
Logs de acceso privilegiado. Proporcione logs de auditoría para cuentas privilegiadas — acceso root, cuentas de administrador de base de datos, roles de administrador de infraestructura. Los auditores quieren ver quién usó acceso privilegiado, cuándo y con qué propósito.
Gestión de cambios (CC8)
La evidencia de gestión de cambios demuestra que sus procesos de desarrollo y despliegue siguen sus procedimientos documentados. Para empresas SaaS que despliegan código frecuentemente, esta área debería producir abundante evidencia automatizada.
Historial de pull requests con revisiones de código. Los auditores muestrearán pull requests de todo el período de observación y verificarán que las revisiones de código ocurrieron antes del merge. Verificarán las aprobaciones del revisor, los comentarios de revisión y que el revisor sea alguien distinto al autor.
Ejemplo SaaS: Logs de pull requests de GitHub mostrando que cada PR fusionado a la rama principal tuvo al menos una revisión aprobatoria de un miembro del equipo que no es el autor, con comentarios de revisión y una marca de tiempo de aprobación antes del merge.
Logs de despliegue. Proporcione registros de despliegues a producción mostrando qué se desplegó, cuándo, por quién y a través de qué mecanismo. Los auditores quieren ver que los despliegues pasaron por su pipeline de CI/CD, no a través de acceso SSH manual a servidores de producción.
Ejemplo SaaS: Logs de ejecución del pipeline de CI/CD de GitHub Actions o CircleCI mostrando el activador del despliegue (PR fusionado), resultados de pruebas automatizadas, pasos de compilación y despliegue exitoso a producción con marcas de tiempo.
Flujos de trabajo de aprobación de cambios. Para cambios que requieren aprobación explícita más allá de la revisión de código — cambios de infraestructura, migraciones de base de datos, modificaciones de configuración — proporcione los registros de aprobación.
Procedimientos de reversión probados. Evidencia de que ha probado su capacidad para revertir un despliegue fallido. Esto podría ser una prueba documentada, un evento de reversión real con un ticket de incidente o un manual de procedimientos con registros de ejecución.
Documentación de cambios de emergencia. Si ocurrieron cambios de emergencia durante el período de observación (hotfixes desplegados sin la revisión estándar), proporcione los tickets de cambio de emergencia mostrando la justificación, el cambio en sí y la revisión y aprobación retroactiva dentro del plazo de su política.
Operaciones del sistema (CC7)
La evidencia de operaciones del sistema cubre el monitoreo, la gestión de incidentes, la gestión de vulnerabilidades y la salud operativa. Esta área prueba si usted está vigilando activamente sus sistemas y respondiendo a los problemas.
Paneles de monitoreo y configuraciones de alertas. Muestre que el monitoreo está configurado para sistemas críticos y que las alertas se enrutan a las personas correctas. Exportaciones de configuración de herramientas como Datadog, PagerDuty o CloudWatch demostrando umbrales de alerta, canales de notificación y políticas de escalamiento.
Tickets de incidentes con cronogramas de respuesta. Para cada incidente durante el período de observación, proporcione el ticket mostrando el tiempo de detección, el inicio de la respuesta, las acciones de contención, la resolución y la finalización del post-mortem. Las marcas de tiempo importan — los auditores medirán su respuesta contra los SLAs definidos en su política de respuesta a incidentes.
Ejemplo SaaS: Un registro de incidente de PagerDuty mostrando que la alerta se disparó a las 02:15 UTC, fue reconocida por el ingeniero de guardia a las 02:18 UTC, un ticket de incidente de Jira vinculado con pasos de contención documentados a las 02:45 UTC, resolución a las 03:30 UTC, y un documento de post-mortem completado tres días hábiles después con análisis de causa raíz y acciones preventivas.
Resultados de escaneo de vulnerabilidades y tickets de remediación. Proporcione resultados de escaneo de sus herramientas de escaneo de vulnerabilidades (Snyk, Qualys, Nessus, AWS Inspector) a intervalos regulares durante el período de observación, más tickets mostrando que las vulnerabilidades identificadas fueron remediadas dentro del SLA de su política.
Ejemplo SaaS: Informes mensuales de escaneo de Snyk mostrando vulnerabilidades identificadas en dependencias, con tickets de Jira vinculados para hallazgos críticos y altos mostrando remediación (actualizaciones de dependencias, parches) completada dentro de 7 y 30 días respectivamente.
Informes de pruebas de penetración. Al menos una prueba de penetración durante el período de observación, realizada por un tercero calificado. El informe debe incluir metodología, hallazgos, calificaciones de severidad y su plan de remediación con evidencia de finalización para hallazgos críticos y altos.
Registros de gestión de parches. Evidencia de que los sistemas operativos, frameworks y dependencias se mantienen actualizados. Configuraciones de parcheo automatizado, logs de despliegue de parches y registros mostrando el tiempo de aplicación para actualizaciones de seguridad críticas.
Evaluación de riesgos (CC3)
La evidencia de evaluación de riesgos demuestra que su organización identifica, evalúa y trata los riesgos de manera sistemática. Esta área se conecta con su política de evaluación de riesgos y alimenta múltiples otras áreas de control.
Documento formal de evaluación de riesgos. Una evaluación de riesgos completada fechada dentro del período de observación, siguiendo su metodología documentada. Debe incluir el proceso de identificación de riesgos, calificaciones de probabilidad e impacto, puntuaciones de riesgo y decisiones de tratamiento.
Registro de riesgos con planes de tratamiento. Un documento vivo que muestra los riesgos identificados, su estado actual, propietarios asignados y acciones de tratamiento. Los auditores quieren ver que los riesgos no solo se identifican — se gestionan activamente con propiedad clara y cronogramas.
Actas de reuniones de revisión de riesgos. Evidencia de que el riesgo se discute a nivel de gobernanza — reuniones de la dirección, actualizaciones al consejo o sesiones dedicadas de revisión de riesgos. Las actas deben incluir asistentes, riesgos discutidos, decisiones tomadas y acciones asignadas.
Evaluaciones de riesgo de proveedores. Evaluaciones de riesgo para sus proveedores de riesgo crítico y alto, demostrando que el riesgo de terceros está integrado en su programa general de gestión de riesgos. Para detalles, consulte nuestra guía de gestión de proveedores.
Comunicación (CC2)
La evidencia de comunicación demuestra que las expectativas de seguridad se establecen y comunican a todas las partes relevantes — empleados, dirección, clientes y proveedores.
Registros de finalización de capacitación en concienciación de seguridad. Proporcione registros mostrando que todos los empleados completaron la capacitación en concienciación de seguridad dentro del plazo de su política. Los registros deben incluir el nombre del empleado, el tema de la capacitación, la fecha de finalización y el estado de aprobado/reprobado si aplica.
Ejemplo SaaS: Exportación de la plataforma de capacitación mostrando que todos los empleados activos completaron la capacitación anual en concienciación de seguridad, con fechas de finalización dentro del período de observación y antes de la fecha límite de cada empleado exigida por la política.
Firmas de reconocimiento de políticas. Registros de empleados reconociendo la recepción y comprensión de las políticas clave. Como mínimo, la Política de Seguridad de la Información y la Política de Uso Aceptable deben tener reconocimientos de cada empleado, recopilados durante la incorporación y después de actualizaciones significativas de políticas.
Informes de seguridad al consejo o la dirección. Evidencia de que la postura de seguridad se comunica al liderazgo — actas de reuniones del consejo con elementos de la agenda de seguridad, informes de seguridad trimestrales a la dirección o revisiones de paneles ejecutivos.
Compromisos de seguridad externos. Su página de seguridad pública, SLAs con disposiciones de seguridad y cualquier certificación o atestación de seguridad externa que comunique a los clientes.
Construcción de un sistema de recopilación de evidencias
Recopilar evidencias manualmente es insostenible. Las empresas SaaS que dependen de hojas de cálculo y carreras trimestrales de recopilación de evidencias agotan a sus equipos de cumplimiento y producen registros incompletos. Así es como construir un sistema que funcione.
Automatice donde sea posible. Cada herramienta de su pila tiene una API. La API de GitHub proporciona datos de pull requests y revisiones de código. AWS CloudTrail proporciona logs de acceso y cambios. Okta proporciona eventos de autenticación y aprovisionamiento. Jira proporciona historial de tickets. Construya integraciones — o use una plataforma de cumplimiento — que extraiga evidencias automáticamente de forma programada.
Ejemplo SaaS: Un trabajo nocturno que exporta los logs de despliegue a producción del día anterior de GitHub Actions, eventos de acceso de Okta y eventos de alerta de PagerDuty a su repositorio de evidencias con nombres y metadatos estandarizados.
Establezca la cadencia de recopilación. No todas las evidencias necesitan recopilación diaria. Defina la frecuencia apropiada para cada tipo de evidencia:
- Diaria: Logs de acceso, logs de despliegue, eventos de monitoreo
- Semanal: Resultados de escaneo de vulnerabilidades, actualizaciones de estado de tickets
- Mensual: Registros de finalización de capacitación, actualizaciones de reconocimiento de políticas
- Trimestral: Revisiones de acceso, revisiones de proveedores, actualizaciones del registro de riesgos
- Anualmente: Informes de pruebas de penetración, evaluaciones de riesgos completas, revisiones de políticas
Centralice el almacenamiento de evidencias. Todas las evidencias deben vivir en un sistema con organización consistente. Use una estructura de carpetas o sistema de etiquetado organizado por categoría de Common Criteria y control. Cada pieza de evidencia debe estar vinculada al control específico que respalda. Considere conectar su programa de evidencias a sus flujos de trabajo de monitoreo continuo para que las brechas se detecten en tiempo real.
Asigne propietarios de evidencias. Cada área de control necesita un propietario identificado responsable de asegurar que las evidencias se recopilen según el cronograma. Los líderes de ingeniería son dueños de la evidencia de gestión de cambios. El equipo de seguridad es dueño de la evidencia de control de acceso. RRHH es dueño de los registros de capacitación. La propiedad distribuida evita que la recopilación de evidencias se convierta en la carga de una sola persona.
Nombre de manera consistente. Adopte una convención de nombres que incluya el tipo de evidencia, el área de control, el rango de fechas y el sistema. Ejemplo: revision-acceso_aws-iam_2026-Q1.pdf. Cuando su auditor recibe 200 archivos de evidencia, los nombres consistentes ahorran horas de clasificación.
Errores comunes con las evidencias
Estos errores causan retrasos en la auditoría, hallazgos y, en algunos casos, opiniones con salvedades. Evítelos.
Brechas en el período de observación. Si su período de observación es de enero a diciembre y tiene evidencia de revisión de acceso para Q1, Q2 y Q4 pero no Q3, eso es una brecha. Los auditores no pueden asumir que el control operó durante períodos sin evidencia. Para controles continuos (como monitoreo), una brecha de varias semanas en la recopilación de logs podría resultar en una opinión con salvedades cubriendo ese período.
Capturas de pantalla sin marcas de tiempo o contexto. Una captura de pantalla de una pantalla de configuración no significa nada sin el nombre del sistema, la URL, la fecha de captura y la persona que la capturó. Desarrolle una plantilla o lista de verificación para evidencia de capturas de pantalla que incluya todos los metadatos necesarios.
Evidencia que contradice sus políticas. Su política dice que las revisiones de acceso ocurren trimestralmente con remediación dentro de 14 días hábiles. Su evidencia muestra una revisión trimestral donde una cuenta señalada no se eliminó durante 45 días. Esto es una falla de control — ha proporcionado evidencia contra usted mismo. Antes de enviar evidencia, verifique que demuestre el cumplimiento de sus propias políticas.
Recopilar evidencia en el momento de la auditoría en lugar de continuamente. Si intenta reunir las evidencias de un año en las dos semanas antes de su auditoría, descubrirá que los logs rotaron, las capturas de pantalla no se tomaron y nadie recuerda los detalles de un incidente de hace ocho meses. La recopilación continua previene esto por completo.
No preservar evidencia de cuentas de empleados terminados. Cuando un empleado se va, sus cuentas se desaprovisionan — correctamente. Pero si ese empleado era propietario de evidencia o realizaba revisiones de acceso, sus registros podrían perderse. Asegúrese de que las evidencias generadas por individuos se almacenen en sistemas compartidos, no en cuentas personales.
Sobre-recopilar sin organización. Descargar cientos de archivos en una unidad compartida sin convenciones de nombres, mapeo de controles o atribución de fechas crea trabajo para los auditores y su equipo. Más evidencia no es mejor evidencia. Evidencia organizada, relevante y bien etiquetada es lo que los auditores necesitan.
Trabajando con su auditor en las evidencias
La relación con el auditor afecta directamente lo bien que funciona la recopilación de evidencias. Invierta tiempo por adelantado para alinear expectativas. Para una descripción detallada de todo el ciclo de vida de la auditoría, consulte nuestra guía del proceso de auditoría.
Solicite la lista de solicitud de evidencias temprano. La mayoría de las firmas de auditoría proporcionan una lista PBC (Preparado por el Cliente) — un inventario detallado de cada elemento de evidencia que necesitarán, organizado por área de control. Obtenga esta lista lo antes posible, idealmente antes de que comience su período de observación, para que pueda configurar sus procesos de recopilación en consecuencia.
Acuerde formato de evidencia y convenciones de nombres. Pregunte a su auditor cómo prefiere recibir las evidencias. Algunas firmas usan portales con estructuras de carga específicas. Otras aceptan carpetas organizadas compartidas. Acuerde formatos de archivo — algunos auditores prefieren PDFs para documentos y CSVs para exportaciones de datos. Alinear por adelantado previene retrabajo.
Use un portal compartido o estructura de carpetas segura. Evite enviar archivos de evidencia por correo electrónico. Use un mecanismo dedicado para compartir evidencias — el portal de su auditor, una unidad segura compartida o la función de acceso del auditor de su plataforma de cumplimiento. Organice los archivos para que coincidan con la estructura de la lista PBC para que los auditores puedan encontrar lo que necesitan sin preguntar.
Responda rápidamente a las preguntas de seguimiento. Los auditores tendrán preguntas de seguimiento. Un log de despliegue que no muestra el nombre del revisor. Una revisión de acceso con un estado de remediación poco claro. Responda dentro de 24 a 48 horas. Las respuestas retrasadas extienden el cronograma de la auditoría y señalan desorganización.
No ofrezca evidencia que le perjudique. No se trata de ocultar problemas — se trata de no crear confusión innecesaria. Si su auditor pide evidencia de revisión de acceso y usted proporciona 15 documentos suplementarios que incluyen una plantilla de revisión de acceso obsoleta junto con la actual, ha creado una pregunta. Proporcione exactamente lo que se solicita, organizado y contextualizado.
Cómo ayuda GRCTrail
GRCTrail transforma la recopilación de evidencias de una carrera manual a un proceso automatizado y continuo que mantiene a su equipo SaaS listo para la auditoría durante todo el año.
- Recopilación automatizada de evidencias de sus herramientas existentes — GitHub, AWS, Okta, Jira y más — extrayendo evidencias de control de forma programada sin intervención manual
- Evidencias vinculadas a controles y criterios específicos para que cada artefacto recopilado se mapee directamente a la categoría y control de Common Criteria que respalda, eliminando la pregunta de “¿a dónde va cada evidencia?”
- Paquetes de evidencia listos para auditoría que organizan sus evidencias en el formato que los auditores esperan, con nombres consistentes, metadatos y mapeo de controles que se pueden compartir directamente con su firma de auditoría
- Detección de brechas para períodos de evidencia faltantes que le alerta cuando las evidencias esperadas no se han recopilado — antes de que su auditor descubra la brecha meses después durante el trabajo de campo
- Recopilación continua con automatización programada que reemplaza las carreras trimestrales de recopilación de evidencias con un proceso de recopilación constante y automatizado que se ejecuta durante todo su período de observación
Guías relacionadas
Artículos relacionados
El proceso de auditoría SOC 2: cronograma, pasos y qué esperar
Un recorrido paso a paso por el proceso de auditoría SOC 2, desde la selección del auditor hasta la recepción de su informe. Cubre cronogramas, preparación y lo que evalúan los auditores.
Controles Common Criteria (CC) de SOC 2 explicados
Un desglose detallado de las nueve categorías de Common Criteria de SOC 2 (CC1-CC9), qué requiere cada una y cómo las empresas SaaS deben implementar controles para cada categoría.
Lista de verificación de cumplimiento SOC 2 para empresas SaaS
Una lista de verificación completa de cumplimiento SOC 2 que cubre cada paso desde el alcance hasta la finalización de la auditoría. Diseñada para equipos SaaS que preparan su primer o próximo informe SOC 2.