Cumplimiento de SOC 2 para Google Workspace: lo que necesita saber

Si su organización está en proceso de obtener SOC 2 —y la mayoría de las empresas de software B2B eventualmente lo hacen, porque los clientes lo solicitan— Google Workspace estará dentro del alcance. Contiene identidades, documentos y controles de acceso que se corresponden directamente con los criterios que examina un auditor. Este artículo explica cómo se integra Workspace en un programa SOC 2 y cómo preparar el lado de Workspace sin las prisas de último momento.

Una aclaración sobre el lenguaje antes de continuar: SOC 2 es una *atestación* realizada por una firma de contadores públicos independiente (CPA), no una insignia que uno se otorga a sí mismo. El resultado es un informe de un auditor, no una etiqueta autodeclarada. Lo que se puede hacer internamente es construir y demostrar los controles, y reunir la evidencia, de modo que la atestación se desarrolle sin contratiempos. De eso trata este artículo.

Una orientación rápida sobre SOC 2

SOC 2 evalúa los controles de una organización de servicios frente a los Trust Services Criteria (TSC): Security (Seguridad, siempre incluido, a menudo llamado Common Criteria), y opcionalmente Availability (Disponibilidad), Processing Integrity (Integridad del Procesamiento), Confidentiality (Confidencialidad) y Privacy (Privacidad). Los criterios de Security —la serie CC— son donde Google Workspace aparece con más frecuencia.

Un informe Tipo I evalúa si los controles están *diseñados* apropiadamente en un momento determinado. Un informe Tipo II evalúa si *operaron de manera efectiva* durante un período (normalmente de 3 a 12 meses). El Tipo II es lo que los clientes suelen querer, y tiene una implicación importante: se necesitan controles que funcionen, y evidencia de que funcionaron, durante toda la ventana temporal, no solo el día de la auditoría.

Dónde se corresponde Google Workspace con los criterios

Varios Common Criteria se corresponden claramente con controles de Workspace que usted ya maneja:

• CC6.1 — Controles de acceso lógico. Quién puede acceder a la información protegida y cómo se restringe el acceso a usuarios autorizados. En términos de Workspace: aprovisionamiento de cuentas, aplicación de MFA, controles de compartición y el acceso que posee cada identidad, incluidas las cuentas externas y de servicio.
• CC6.2 — Registro y autorización. Los nuevos usuarios se registran y autorizan antes de que se otorgue el acceso; el acceso se elimina cuando ya no es necesario. Aquí entra la higiene de altas, cambios y bajas (joiner/mover/leaver).
• CC6.3 — Privilegio mínimo y segregación de funciones. El acceso se basa en roles y se mantiene al mínimo necesario. El acceso con permisos excesivos y la proliferación de privilegios administrativos son hallazgos contrarios a este criterio.
• CC6.6 — Protección frente a amenazas externas. La superficie accesible externamente: enlaces públicos, compartición externa y el acceso otorgado a identidades ajenas a la organización.
• CC7.x — Monitoreo y respuesta a incidentes. Detección de anomalías y respuesta a eventos de seguridad. Saber cuándo cambian la compartición o el acceso, y poder investigarlo, respalda estos criterios.

No es necesario memorizar la numeración. El punto es que el trabajo cotidiano en Workspace —aplicar MFA, controlar la compartición, eliminar accesos obsoletos, gobernar aplicaciones de terceros— *es* la evidencia de control que un auditor quiere ver.

Qué pide realmente el auditor

Los auditores no quieren garantías verbales; quieren evidencia. Para los controles relacionados con Workspace, espere solicitudes como:

• Prueba de que se aplica MFA (la política y su aplicación efectiva, no solo "la activamos").
• La lista de administradores y una justificación para cada rol privilegiado.
• Evidencia de revisiones de acceso: que usted verifica periódicamente quién puede acceder a datos sensibles y actúa según lo que encuentra.
• Registros de la baja de acceso cuando los empleados se van de la empresa.
• La configuración de compartición y cómo se controla la compartición externa.
• Un registro de cómo se rastrean los hallazgos de seguridad hasta su resolución.

El tema recurrente es un proceso documentado y repetible con un rastro de auditoría. Un control que existe pero no deja rastro es difícil de atestar. Un control que se ejecuta continuamente y registra lo que encontró es fácil.

Cómo preparar el lado de Workspace

1. Establezca una línea base de configuración. Documente el estado previsto de su configuración administrativa —compartición, verificación en dos pasos, restricciones de Marketplace, autenticación de correo electrónico— y verifique la realidad frente a ella según un calendario. La desviación (drift) es el enemigo de una auditoría limpia.
2. Realice revisiones de acceso que pueda evidenciar. Revise periódicamente quién puede acceder a datos sensibles, incluidas las identidades externas y no humanas, y conserve el resultado. "Revisamos el acceso trimestralmente, aquí están los registros" es exactamente lo que exige CC6.3.
3. Refuerce y documente la compartición. Corresponda con CC6.1 y CC6.6 controlando la compartición pública y externa y siendo capaz de mostrar el estado actual.
4. Rastree los hallazgos hasta su resolución. Cuando encuentre una exposición, regístrela, corríjala y conserve el rastro. Esto respalda los criterios de monitoreo y remediación.
5. Mantenga un registro de auditoría. Un registro con marca de tiempo de las acciones relevantes para la seguridad hace que las preguntas de "quién hizo qué, y cuándo" sean triviales de responder.

Gran parte de esto se superpone con una buena seguridad de Google Workspace en general —y ese es precisamente el punto. SOC 2 no es un proyecto aparte que se añade después; es su práctica de seguridad, hecha legible y evidenciada.

La evidencia continua vence a las prisas de la auditoría

El modo de fallo clásico es tratar el cumplimiento como un evento: un mes frenético de capturas de pantalla y hojas de cálculo antes de la auditoría, repetido cada año. Es estresante, propenso a errores y produce evidencia puntual que un auditor de Tipo II cuestionará, con razón.

La alternativa es continua: controlar la postura durante todo el año, generar la evidencia como subproducto y llegar a la auditoría con el rastro ya reunido. Una herramienta de gestión de postura que asocia los hallazgos con los criterios de SOC 2 y produce evidencia lista para el auditor convierte las prisas en una simple exportación.

Errores comunes en la parte de Workspace de una auditoría

Hay algunos errores que aparecen una y otra vez y conviene anticipar:

• Confundir "configurado" con "aplicado". Activar una política de verificación en dos pasos no es lo mismo que que se aplique a todas las cuentas. Los auditores prueban lo segundo. Verifique que la aplicación se mantenga en toda la organización; consulte nuestra guía sobre cómo aplicar MFA en Google Workspace.
• Tratar las revisiones de acceso como una simple casilla que marcar. "Revisamos el acceso" sin registros, alcance ni seguimiento no es evidencia. Conserve el resultado y demuestre que se actuó sobre los hallazgos.
• Olvidar las identidades no humanas. Las cuentas de servicio y los agentes de IA también poseen acceso, y un auditor que examine el privilegio mínimo (CC6.3) no aceptará "solo revisamos a las personas". Gobiérnelos; consulte cómo detectar agentes de IA riesgosos.
• Permitir que la configuración se desvíe entre auditorías. Una línea base que estaba limpia en enero y se desvió para junio produce un hallazgo de Tipo II. La verificación continua, y no una instantánea anual, es lo que mantiene la línea.

El cumplimiento es un subproducto de la buena seguridad

El replanteamiento más útil para el lado de Workspace en SOC 2 es que usted no está construyendo controles *para la auditoría*, sino ejecutando un programa de seguridad sólido y permitiendo que la auditoría lo observe. Todo lo que un auditor quiere ver bajo los criterios de control de acceso es algo que usted querría de todos modos: identidad aplicada, compartición controlada, acceso de terceros gobernado y una línea base de configuración mantenida. La auditoría simplemente le pide que lo haga legible y evidenciado.

Los equipos que internalizan esto dejan de temer el ciclo anual. Los controles se ejecutan todo el año, la evidencia se acumula como subproducto y la auditoría se convierte en una revisión de un trabajo ya hecho, en lugar de un proyecto en sí mismo. Esa es también, en la práctica, la diferencia entre las prisas y estar preparado.

8200.dev asocia la postura de su Google Workspace con las familias de controles de SOC 2, ISO 27001 y GDPR, y genera paquetes de evidencia que puede entregar a un auditor: honestos, acotados a lo que realmente observamos, nunca una afirmación de cumplimiento no fundamentada. Lea más sobre cómo funciona o sobre nuestras propias prácticas de seguridad.

¿Se está preparando para una auditoría? Inicie su auditoría de seguridad gratuita y vea cómo se corresponde la postura de su Google Workspace con los criterios de control de acceso que examinan los auditores.