Monitoreo continuo SOC 2: mantener el cumplimiento todo el año

El mayor error que cometen las empresas SaaS después de recibir su primer informe SOC 2 es tratarlo como un proyecto terminado. El informe llega, el equipo celebra y el cumplimiento se desvanece en segundo plano hasta que comienza el siguiente ciclo de auditoría — momento en el cual se produce una preparación frenética de tres meses, se descubren brechas de evidencia y las fallas de control que podrían haberse detectado en enero aparecen en octubre.

SOC 2 Type II examina la eficacia operativa de sus controles durante todo el período de observación — generalmente 12 meses. Una revisión de acceso que se completó en todos los meses excepto julio es un hallazgo de auditoría. Una vulnerabilidad que no se parcheó durante 90 días porque nadie estaba rastreando el SLA de remediación es un hallazgo de auditoría. Un proveedor cuyo informe SOC 2 expiró hace seis meses sin renovación es un hallazgo de auditoría. El monitoreo continuo detecta estos problemas cuando son corregibles, no cuando son evidencia de falla.

Esta guía cubre qué monitorear, cómo construir un sistema de monitoreo que escale con su empresa SaaS, las métricas que importan y cómo manejar los momentos inevitables en que el monitoreo revela que un control no está funcionando.

Por qué el monitoreo continuo importa para SOC 2

Type II cubre todo el período de observación. Una auditoría Type II no evalúa sus controles el día que llega el auditor. Evalúa si esos controles operaron eficazmente durante todo el período de observación. Si su aplicación de MFA estuvo deshabilitada durante dos semanas en marzo mientras migraba proveedores de identidad, esa brecha aparecerá en su informe — ya sea como excepción o como opinión con salvedades, dependiendo de la severidad. El monitoreo continuo asegura que usted conozca las brechas cuando ocurren, no cuando el auditor las encuentra.

Los controles deben funcionar los 365 días del año. Una revisión trimestral de acceso que se realizó en Q1, Q2 y Q4 pero se omitió en Q3 no tiene un 75% de cumplimiento. Es una falla de control para todo el trimestre. SOC 2 no califica con curva. El control operó según lo diseñado durante el período de observación, o no lo hizo. El monitoreo continuo verifica que los controles están funcionando según su cadencia definida.

La detección temprana permite la remediación. Cuando el monitoreo detecta una falla de control en tiempo real, tiene la oportunidad de remediarla, documentar la remediación y demostrar a su auditor que la falla fue un evento aislado en lugar de un problema sistémico. Un control que falló una vez pero fue detectado y corregido en días se categoriza de manera muy diferente en un informe de auditoría que un control que falló silenciosamente durante meses.

La preparación de auditoría pasa de meses a días. Las empresas SaaS con programas maduros de monitoreo continuo no tienen una fase de “preparación para la auditoría”. Las evidencias se recopilan continuamente, el estado de los controles es visible en tiempo real y el auditor recibe un paquete de evidencias completo desde el primer día. Esto reduce la duración de la auditoría, los honorarios del auditor y la interrupción operativa causada por sacar a los ingenieros para la recopilación de evidencias.

Qué monitorear — categorías de control

Su programa de monitoreo debe cubrir cada dominio de control en su alcance SOC 2. Los controles específicos varían según la organización, pero las siguientes categorías se aplican a prácticamente toda empresa SaaS.

Controles de acceso

Las fallas de control de acceso están entre los hallazgos más comunes de SOC 2. El monitoreo debe cubrir todo el ciclo de vida del acceso de usuario.

Oportunidad del aprovisionamiento y desaprovisionamiento de usuarios. Cuando se contrata un empleado, ¿qué tan rápido recibe el acceso apropiado? Más críticamente, cuando se termina a un empleado, ¿qué tan rápido se revoca el acceso? SOC 2 espera el desaprovisionamiento dentro de un SLA definido — típicamente dentro de las 24 horas de la terminación. Monitoree su proveedor de identidad y sistema de RRHH para brechas entre la fecha de terminación y la revocación de acceso. Sus políticas y procedimientos deben definir el SLA esperado, y su monitoreo debe verificar el cumplimiento.

Aplicación de MFA en todos los sistemas. La autenticación multifactor es un control base de SOC 2. Monitoree usuarios o cuentas de servicio que no tengan MFA habilitado, y sistemas que permitan autenticación sin MFA. Preste especial atención a las cuentas recién aprovisionadas (MFA puede no aplicarse por defecto en todos los sistemas) y las cuentas de servicio (que a menudo se excluyen de las políticas de MFA pero no deben tener capacidad de inicio de sesión interactivo).

Revisiones trimestrales de acceso completadas y documentadas. Las revisiones de acceso verifican que los usuarios aún requieren el acceso que se les ha otorgado. Monitoree que las revisiones se realicen según el calendario, que los revisores realmente evalúen cada entrada de acceso (no solo sellen la lista) y que las revocaciones identificadas se ejecuten. Rastree el porcentaje de entradas de acceso revisadas y el porcentaje de entradas señaladas remediadas.

Uso y justificación de acceso privilegiado. El acceso a bases de datos de producción, el acceso de administrador a la consola de la nube y el uso de root/sudo deben monitorearse continuamente. Cada instancia de acceso privilegiado debe tener una justificación correspondiente — un ticket, un incidente, una ventana de mantenimiento. El acceso privilegiado sin explicación es una señal de alerta para los auditores y un potencial indicador de compromiso.

Gestión de cuentas de servicio. Las cuentas de servicio a menudo acumulan permisos excesivos con el tiempo y carecen del monitoreo aplicado a las cuentas humanas. Rastree el inventario de cuentas de servicio, los permisos, los calendarios de rotación de claves y los patrones de uso.

Gestión de cambios

Los controles de gestión de cambios aseguran que las modificaciones a sus sistemas estén autorizadas, probadas y desplegadas de manera segura.

Todos los cambios de código tienen revisión por pares antes del despliegue. Monitoree su repositorio de código para merges a ramas de producción que eludieron las revisiones requeridas. Las reglas de protección de ramas de GitHub, las aprobaciones de merge requests de GitLab y controles similares deben aplicarse a nivel de plataforma — pero el monitoreo verifica que no hayan sido eludidos o temporalmente deshabilitados.

Sin acceso directo a producción. Los ingenieros deben desplegar código a través de su pipeline de CI/CD, no mediante SSH a servidores de producción. Monitoree los eventos de acceso directo a producción y asegúrese de que cada uno tenga una justificación documentada (cambio de emergencia, respuesta a incidentes, etc.). Si su arquitectura requiere acceso directo a producción para ciertas operaciones, documente esas excepciones y monitoree que el acceso se limite a escenarios aprobados.

Flujos de trabajo de aprobación de cambios funcionando. Para cambios que requieren aprobación más allá de la revisión de código (cambios de infraestructura, cambios de configuración, migraciones de base de datos), verifique que las aprobaciones se obtengan antes del despliegue. Monitoree su sistema de tickets y pipeline de despliegue para cambios desplegados sin las aprobaciones requeridas.

Procedimientos de cambio de emergencia seguidos correctamente. Los cambios de emergencia — hotfixes desplegados fuera de los procesos normales debido a un incidente activo — son aceptables, pero requieren documentación retrospectiva y revisión. Monitoree los cambios de emergencia y verifique que cada uno tenga un registro de incidente correspondiente, revisión post-despliegue y reconocimiento de la gerencia.

Operaciones del sistema

El monitoreo de operaciones del sistema cubre la salud y seguridad continua de su infraestructura.

Cadencia de escaneo de vulnerabilidades cumplida. Su evaluación de riesgos probablemente identificó la gestión de vulnerabilidades como un control clave. Monitoree que los escaneos se ejecuten según el calendario — semanalmente para infraestructura, en cada compilación para dependencias de aplicación, y según lo definido para imágenes de contenedor. Un escaneo omitido es una oportunidad de detección perdida.

Vulnerabilidades críticas y altas remediadas dentro del SLA. Encontrar vulnerabilidades no significa nada si no se corrigen. Defina SLAs de remediación por severidad (ej., Crítico: 7 días, Alto: 30 días, Medio: 90 días) y monitoree el cumplimiento. Rastree la antigüedad de cada vulnerabilidad abierta y alerte cuando los SLAs se acerquen o se incumplan.

Protección de endpoints desplegada en todos los dispositivos. Cada dispositivo de empleado que acceda a sistemas corporativos o datos de clientes debe tener protección de endpoint instalada y actualizada. Monitoree su plataforma de gestión de endpoints para dispositivos sin protección, dispositivos con firmas desactualizadas o dispositivos que no se han registrado recientemente.

Completación de respaldos y verificación de integridad. Los respaldos deben completarse exitosamente según su calendario definido, y deben probarse para confirmar la recuperabilidad. Monitoree las fallas de respaldo y rastree la última prueba de restauración exitosa para cada sistema crítico. Un respaldo que nunca se ha probado no es un respaldo — es una esperanza.

Tiempo de actividad y rendimiento contra los SLAs. Si su SOC 2 incluye el criterio de Disponibilidad, monitoree el tiempo de actividad del servicio y las métricas de rendimiento contra sus SLAs publicados. Rastree incidentes, minutos de inactividad y tasas de cumplimiento de SLA mensualmente.

Gestión de proveedores

Su cumplimiento SOC 2 depende en parte del cumplimiento de sus proveedores. El monitoreo debe extenderse a su ecosistema de terceros.

Informes SOC 2 de proveedores vigentes. Rastree las fechas de vencimiento de los informes SOC 2 de sus proveedores críticos y señale las renovaciones que estén vencidas. Un proveedor cuyo informe expiró hace seis meses puede haber experimentado degradación de controles que afecta sus datos. Consulte nuestra guía de gestión de proveedores para el marco completo de evaluación de proveedores.

Nuevos proveedores evaluados antes de la incorporación. Cada nuevo proveedor que vaya a acceder, almacenar o procesar datos de clientes debe ser evaluado antes de entrar en producción. Monitoree su proceso de adquisición e incorporación de proveedores para asegurar que las evaluaciones de seguridad se completen — no se omitan porque la integración es “urgente.”

Cambios de proveedores monitoreados. Rastree los cambios en la postura de seguridad de los proveedores — brechas reportadas en las noticias, cambios en su alcance SOC 2 o modificaciones a su lista de sub-encargados. Estos cambios pueden afectar el perfil de riesgo que documentó en su registro de riesgos.

Capacitación y concienciación

Las personas son tanto su control más fuerte como su mayor vulnerabilidad. La efectividad de la capacitación debe monitorearse.

Tasas de finalización de capacitación en concienciación de seguridad. Rastree qué empleados han completado la capacitación requerida y cuáles están vencidos. Una tasa de finalización del 95% significa que el 5% de su fuerza laboral no ha recibido capacitación en seguridad — y los auditores preguntarán por la brecha. Apunte al 100% de finalización dentro del plazo definido (típicamente dentro de los 30 días de la contratación y anualmente a partir de entonces).

Reconocimientos de políticas vigentes. Los empleados deben reconocer las políticas clave (seguridad de la información, uso aceptable, manejo de datos) anualmente. Monitoree las tasas de reconocimiento y haga seguimiento de los reconocimientos pendientes antes de la ventana de auditoría.

Resultados de simulaciones de phishing. Si ejecuta simulaciones de phishing (y debería hacerlo), rastree las tasas de clics, las tasas de reporte y las tendencias a lo largo del tiempo. Las tendencias de mejora demuestran que su programa de capacitación es efectivo. Las tendencias de deterioro indican un problema que necesita atención antes de que su auditor pregunte al respecto.

Construcción de su sistema de monitoreo

El monitoreo efectivo requiere tanto verificaciones automatizadas como revisiones humanas periódicas. Ninguna es suficiente por sí sola.

Monitoreo automatizado

La automatización es la columna vertebral del monitoreo continuo. Las verificaciones manuales no escalan y son propensas a los mismos errores humanos que pretenden detectar.

Integre con sus herramientas existentes. Su sistema de monitoreo debe extraer datos de las herramientas que su equipo ya utiliza:

• Proveedor de nube — AWS Config Rules, AWS Security Hub, GCP Security Command Center, Azure Policy. Estos evalúan la configuración de su nube contra líneas base de seguridad continuamente.
• Proveedor de identidad — Okta, Azure AD, Google Workspace. Extraiga estado de usuario, inscripción de MFA, membresía de grupo y datos de último inicio de sesión.
• Repositorio de código — GitHub, GitLab, Bitbucket. Monitoree las reglas de protección de ramas, requisitos de revisión y actividad de merge.
• Sistema de tickets — Jira, Linear, Asana. Rastree aprobaciones de cambios, registros de incidentes y finalización de tareas de remediación.
• Gestión de endpoints — Jamf, Intune, CrowdStrike. Monitoree el cumplimiento de dispositivos, el estado de protección y el cifrado.
• Escáner de vulnerabilidades — Qualys, Rapid7, Snyk, Dependabot. Extraiga resultados de escaneo, conteos de vulnerabilidades y cronogramas de remediación.

Configure verificaciones automatizadas para controles críticos:

• Estado de MFA para todos los usuarios (diario)
• Seguimiento de finalización de revisiones de acceso (semanal)
• Ejecución de escaneo de vulnerabilidades (según calendario)
• Estado de finalización de respaldos (diario)
• Estado de reglas de protección de ramas (diario)
• Cobertura de protección de endpoints (diario)
• Vencimiento de certificados (diario)
• Cumplimiento de configuración en la nube (continuo)

Alerte sobre desviaciones del comportamiento esperado. Configure alertas para condiciones que indiquen que un control no está operando según lo diseñado: MFA deshabilitado para una cuenta de usuario, un merge a producción sin las aprobaciones requeridas, una falla de respaldo o un escaneo de vulnerabilidades que no se ejecutó según el calendario. Enrute las alertas al propietario apropiado con suficiente contexto para tomar acción.

Revisiones periódicas

El monitoreo automatizado detecta fallas de control en tiempo real. Las revisiones periódicas detectan problemas sistémicos, tendencias y brechas de proceso que las alertas individuales no captan.

Revisiones mensuales:

• Finalización de revisiones de acceso del mes — ¿se realizaron todas las revisiones programadas?
• Estado de vulnerabilidades — conteo de vulnerabilidades abiertas por severidad, tasa de cumplimiento de SLA, análisis de antigüedad
• Completitud de evidencias — ¿se están recopilando y almacenando todos los artefactos de evidencia esperados?
• Revisión de incidentes — ¿se manejaron todos los incidentes según los procedimientos? (enlace a respuesta a incidentes)
• Revisión de alertas — ¿son razonables los volúmenes de alertas? ¿Son aceptables las tasas de falsos positivos? ¿Se está desarrollando fatiga de alertas?

Revisiones trimestrales:

• Actualización del registro de riesgos — ¿han surgido nuevos riesgos? ¿Han cambiado las puntuaciones de riesgo existentes? (enlace a evaluación de riesgos)
• Revisión de proveedores — ¿están vigentes los informes SOC 2 de los proveedores? ¿Algún proveedor ha experimentado eventos de seguridad?
• Revisión de políticas — ¿siguen siendo las políticas precisas y reflejo de las prácticas actuales?
• Análisis de tendencias de métricas — ¿están mejorando, estables o degradándose las métricas clave de cumplimiento?

Revisiones anuales:

• Evaluación de riesgos completa — reevaluación exhaustiva de todos los riesgos, no solo actualizaciones incrementales
• Actualización de políticas — revisión y aprobación formal de todas las políticas de seguridad y cumplimiento
• Revisión del marco de controles — evaluar si el conjunto actual de controles es suficiente dados los cambios en el panorama de amenazas, su arquitectura y su negocio
• Evaluación del programa de capacitación — evaluar la efectividad de la capacitación y actualizar el contenido

Integración con la recopilación de evidencias

El monitoreo continuo debe generar automáticamente la evidencia de auditoría que su auditor solicitará. Este no es un flujo de trabajo separado — es un resultado natural de sus actividades de monitoreo.

Cada verificación automatizada produce un registro con marca de tiempo. Cuando su sistema verifica que MFA está aplicado para todos los usuarios a las 2:00 AM del 11 de marzo, ese resultado de verificación es evidencia. Cuando su seguimiento de revisiones de acceso muestra que las revisiones del Q1 fueron completadas por todos los gerentes el 15 de marzo, eso es evidencia. Almacene estos registros en un sistema centralizado y a prueba de manipulaciones.

Mapee las evidencias a los objetivos de control. Cada pieza de evidencia debe etiquetarse con el control SOC 2 que respalda. Cuando su auditor solicite evidencia para CC6.1 (controles de acceso lógico), debería poder producir un conjunto completo de evidencias con una sola consulta — no pasar días buscando en correo electrónico, Slack y unidades compartidas.

Almacene las evidencias en un sistema centralizado accesible para el auditor. Las evidencias dispersas — algunas en Google Drive, algunas en Confluence, algunas en archivos de correo electrónico — son operativamente dolorosas y crean riesgo de brechas. Use una plataforma de cumplimiento centralizada donde todas las evidencias estén almacenadas, organizadas por control y accesibles para su auditor.

Métricas y paneles

Lo que se mide se gestiona. Defina métricas clave de cumplimiento, rastréelas a lo largo del tiempo y hágalas visibles para la dirección.

Métricas clave de cumplimiento SOC 2 a rastrear:

• Tasa de efectividad de controles — Porcentaje de controles operando según lo diseñado. Objetivo: 100%. Realidad: rastree cada desviación, sin importar cuán menor sea, y tienda hacia el 100% con el tiempo.
• Tiempo medio de remediación de hallazgos — ¿Qué tan rápido corrige las fallas de control una vez detectadas? Un MTTR bajo demuestra que su monitoreo es efectivo y su equipo es receptivo.
• Completitud de recopilación de evidencias — Porcentaje de artefactos de evidencia requeridos que están recopilados y vigentes. Las brechas aquí indican puntos ciegos del monitoreo.
• Tasa de finalización de revisiones de acceso — Porcentaje de revisiones de acceso programadas completadas a tiempo. Este es uno de los controles probados con más frecuencia.
• Cumplimiento de SLA de remediación de vulnerabilidades — Porcentaje de vulnerabilidades remediadas dentro de los SLAs definidos, desglosado por severidad.
• Tasa de finalización de capacitación — Porcentaje de empleados vigentes en la capacitación requerida.
• Vigencia de evaluaciones de proveedores — Porcentaje de proveedores críticos con evaluaciones de riesgo e informes SOC 2 vigentes.

Panel para visibilidad de la dirección. Construya un panel de cumplimiento que dé a su CISO, CTO o VP de Ingeniería una vista en tiempo real de su postura de cumplimiento. El panel debe hacer inmediatamente obvio dónde las cosas están en verde (operando según lo esperado), amarillo (acercándose a una fecha límite o umbral) y rojo (falla de control o incumplimiento de SLA que requiere atención).

Análisis de tendencias. Una métrica puntual le dice dónde está. Una tendencia le dice hacia dónde se dirige. Rastree todas las métricas clave mensualmente y analice tendencias trimestralmente. Las tendencias de mejora demuestran la madurez del programa ante los auditores. Las tendencias de degradación son señales de advertencia tempranas que requieren investigación antes de que se conviertan en hallazgos.

Manejo de fallas de monitoreo

Cuando el monitoreo detecta que un control no está operando según lo diseñado — y lo hará — su proceso de respuesta determina si la falla se convierte en un hallazgo de auditoría o en una demostración de efectividad del programa.

Documente la falla inmediatamente. Registre qué sucedió, cuándo se detectó y cuál es el impacto potencial. No espere a comprender la causa raíz antes de documentar — capture los hechos iniciales de detección y actualice el registro a medida que avanza la investigación.

Investigue la causa raíz. Determine por qué falló el control. ¿Fue un error humano puntual (un ingeniero olvidó agregar un revisor a un PR)? ¿Una brecha de proceso sistémica (la lista de verificación de incorporación no incluye la inscripción de MFA)? ¿Una falla técnica (la verificación automatizada no se ejecutaba debido a un token API expirado)? La causa raíz determina la remediación apropiada.

Remedie y documente la corrección. Corrija la falla inmediata y aborde la causa raíz para prevenir la recurrencia. Documente ambas acciones con marcas de tiempo. Por ejemplo: “MFA no estaba aplicado para el usuario X debido a un error de configuración en la asignación de grupo de Okta. Se habilitó el MFA del usuario el 11 de marzo a las 14:30 UTC. Se actualizó la automatización de asignación de grupo de Okta para prevenir la recurrencia el 12 de marzo a las 10:00 UTC.”

Evalúe si impacta el informe SOC 2. No toda falla de control se convierte en una excepción de auditoría. Los incidentes aislados que fueron detectados y remediados con prontitud típicamente se describen en el informe como operando eficazmente con una desviación anotada. Las fallas sistémicas o las brechas prolongadas son más propensas a resultar en excepciones o una opinión con salvedades. Si no está seguro del impacto, discútalo con su auditor de manera proactiva.

Divulgue proactivamente a su auditor si es material. Si una falla de control es significativa — afecta a múltiples clientes, persiste durante un período prolongado o involucra un control de seguridad central — divúlguela a su auditor antes de que la descubran durante las pruebas. La divulgación proactiva demuestra transparencia y le da la oportunidad de presentar la falla junto con su remediación. Los auditores responden mucho más favorablemente a la divulgación honesta que a descubrir fallas que parecen haber sido ocultadas.

Actualice el registro de riesgos. Cada falla de control es relevante para su evaluación de riesgos. ¿La falla reveló un riesgo que no había identificado? ¿Se calificó un riesgo demasiado bajo? ¿La falla indica que un control no es tan efectivo como asumía? Actualice su registro de riesgos para reflejar lo que aprendió.

Errores comunes

Monitorear solo durante la temporada de auditoría. Las empresas SaaS que intensifican el monitoreo tres meses antes de la auditoría y lo reducen después anulan completamente el propósito del monitoreo continuo. Un período de observación Type II cubre 12 meses. Las brechas en cualquier mes son visibles en la evidencia — o más precisamente, la ausencia de evidencia durante esos meses le dice al auditor exactamente cuándo no estaba monitoreando.

Demasiadas alertas causando fatiga de alertas. Un sistema de monitoreo que genera cientos de alertas por día es un sistema de monitoreo que se ignora. Ajuste sus alertas con rigor. Cada alerta debe requerir acción. Si una alerta se dispara regularmente y la respuesta siempre es “ignorar,” el umbral de la alerta está mal. La fatiga de alertas es un riesgo de seguridad — el problema real queda enterrado en el ruido y su equipo deja de prestar atención.

Sin SLAs de remediación definidos. Detectar una falla de control es solo la mitad del trabajo. Si no hay un cronograma definido para la remediación, las fallas persisten sin resolución. Defina SLAs para la remediación por severidad: fallas de control críticas remediadas dentro de 24 horas, altas dentro de una semana, moderadas dentro de 30 días. Rastree el cumplimiento de estos SLAs como una métrica clave.

No rastrear métricas a lo largo del tiempo. Una métrica instantánea le dice el estado de hoy. Una tendencia le dice si su programa está mejorando o degradándose. Sin métricas históricas, no puede identificar patrones (las tasas de finalización de revisiones de acceso caen cada trimestre), demostrar mejora ante los auditores o justificar inversiones en herramientas o personal adicional.

Monitorear la existencia del control pero no su efectividad. Verificar que un WAF esté desplegado no es lo mismo que verificar que el WAF esté bloqueando tráfico malicioso. Verificar que se realizó una revisión de acceso no es lo mismo que verificar que el acceso inapropiado identificado durante la revisión fue realmente revocado. Los programas de monitoreo maduros verifican no solo si los controles existen sino si están produciendo los resultados de seguridad previstos.

Cómo ayuda GRCTrail

GRCTrail transforma el monitoreo continuo de un ejercicio manual basado en hojas de cálculo a un sistema automatizado que funciona en segundo plano mientras su equipo se enfoca en construir producto.

• Monitoreo automatizado de controles con integraciones que se conectan a su proveedor de nube, proveedor de identidad, repositorio de código y otras herramientas para verificar continuamente la operación de los controles sin verificaciones manuales
• Panel de cumplimiento con estado de control en tiempo real mostrando cada control como verde, amarillo o rojo — para que su equipo de liderazgo tenga visibilidad de la postura de cumplimiento en cualquier momento, no solo durante la preparación de la auditoría
• Recopilación y almacenamiento automatizado de evidencias que captura evidencias con marca de tiempo de cada verificación de monitoreo y las organiza por control SOC 2, eliminando la carrera de evidencias de fin de año
• Gestión de alertas con flujos de trabajo de escalamiento que enrutan las fallas de control al propietario correcto con contexto, rastrean los SLAs de remediación y escalan los problemas sin resolver antes de que se conviertan en hallazgos de auditoría
• Informes listos para auditoría en cualquier momento — genere un paquete de evidencias completo para su auditor bajo demanda, cubriendo cualquier rango de fechas dentro de su período de observación

Comience con GRCTrail →

Guías relacionadas

• ¿Qué es SOC 2? Una guía práctica para empresas SaaS
• Evaluación de riesgos SOC 2: marco, proceso y mejores prácticas
• Recopilación de evidencias SOC 2: lo que los auditores quieren ver
• Guía de gestión de proveedores SOC 2