Políticas y procedimientos SOC 2: qué necesita documentar

Las políticas son la base de toda auditoría SOC 2. Documentan lo que su organización se compromete a hacer, y los auditores verifican si realmente lo hace. No hay atajos aquí — sin políticas bien redactadas y aplicables, su informe SOC 2 fracasará o estará tan cargado de salvedades que perderá valor ante los clientes.

Las empresas SaaS a menudo subestiman el esfuerzo de las políticas. Asumen que SOC 2 es principalmente un ejercicio técnico — configurar MFA, cifrar datos, establecer monitoreo. Esos controles importan, pero existen para implementar sus políticas. El primer paso del auditor es leer sus políticas. Su segundo paso es verificar si sus operaciones coinciden con lo que dicen las políticas. Si hay una brecha entre ambos, usted tiene un hallazgo.

Esta guía cubre cada política y procedimiento que una empresa SaaS necesita para SOC 2, qué hace que cada uno esté listo para la auditoría y los errores que causan más problemas durante la temporada de auditoría.

Políticas vs. procedimientos vs. estándares

Antes de entrar en la lista, comprenda la jerarquía. Estos tres tipos de documentos tienen propósitos diferentes, y su auditor espera ver las distinciones claramente.

Las políticas definen qué hará su organización y por qué. Establecen compromisos, asignan responsabilidades y fijan expectativas. Una política es aprobada por la dirección y se aplica ampliamente en toda la organización. Ejemplo: “Todo acceso de usuario seguirá el principio de mínimo privilegio.”

Los estándares definen los puntos de referencia específicos que su organización debe cumplir. Traducen los compromisos de las políticas en umbrales medibles. Ejemplo: “Las contraseñas deben tener al menos 14 caracteres y rotarse cada 90 días.”

Los procedimientos definen cómo se hace algo, paso a paso. Son instrucciones operativas que los empleados siguen para implementar las políticas y cumplir con los estándares. Ejemplo: “Para aprovisionar una nueva cuenta de usuario, envíe una solicitud en Jira usando la plantilla de Solicitud de Acceso, obtenga la aprobación del gerente y configure la cuenta en Okta con el rol especificado en el ticket.”

Un programa de cumplimiento bien estructurado combina los tres: las políticas establecen la dirección, los estándares fijan el nivel y los procedimientos le dicen a las personas exactamente qué hacer. Cuando los auditores ven esta estructura, indica madurez.

Políticas básicas requeridas

Todo informe SOC 2 — independientemente de qué Criterios de Servicio de Confianza incluya — requiere un conjunto de políticas fundamentales. Aquí están las diez políticas que las empresas SaaS deben tener documentadas y aplicadas.

1. Política de seguridad de la información

Este es su documento de seguridad general. Establece el alcance de su programa de seguridad, define los roles y responsabilidades y articula el compromiso de su organización con la protección de los activos de información.

Qué cubre: Objetivos del programa de seguridad, alcance (qué sistemas, datos y personal están incluidos), patrocinio ejecutivo, roles (CISO, equipo de seguridad, líderes de ingeniería) y la relación entre esta política y todas las políticas subordinadas.

En la práctica: Su política de seguridad de la información es el documento principal. Todas las demás políticas de seguridad deben hacer referencia a ella. Los auditores la utilizan para comprender los límites de su alcance SOC 2, así que sea preciso sobre lo que está incluido y lo que no.

Ejemplo SaaS: Su política establece que todos los sistemas de producción alojados en AWS, todos los endpoints de empleados y todas las integraciones de terceros que procesan datos de clientes están dentro del alcance del programa de seguridad. Las herramientas internas que no tocan datos de clientes están explícitamente fuera del alcance.

2. Política de control de acceso

El control de acceso es una de las áreas más intensamente probadas en cualquier auditoría SOC 2. Esta política define cómo su organización gestiona el acceso de usuarios a lo largo de su ciclo de vida.

Qué cubre: Aprovisionamiento y desaprovisionamiento de usuarios, control de acceso basado en roles (RBAC), mínimo privilegio, requisitos de autenticación multifactor (MFA), gestión de acceso privilegiado, gobernanza de cuentas de servicio y revisiones periódicas de acceso.

En la práctica: Los auditores extraerán sus listas de acceso de usuario y las cruzarán con esta política. Verificarán que los empleados terminados fueron desaprovisionados dentro del plazo que su política especifica. Verificarán que el MFA se aplica donde usted dice que se aplica. Cada afirmación en esta política se convierte en verificable.

Ejemplo SaaS: Su política requiere MFA para todo acceso al sistema de producción, revisiones trimestrales de acceso con remediación documentada y desaprovisionamiento dentro de las 24 horas de la terminación del empleado.

3. Política de gestión de cambios

La gestión de cambios gobierna cómo se proponen, revisan, aprueban y despliegan las modificaciones a sus sistemas — código, infraestructura, configuraciones. Para empresas SaaS que despliegan código diariamente, esta política debe reflejar su flujo de trabajo de desarrollo real.

Qué cubre: Requisitos de revisión de código, procesos de despliegue, requisitos de pruebas, flujos de trabajo de aprobación, procedimientos de cambio de emergencia, procedimientos de reversión y documentación de cambios.

En la práctica: Los auditores muestrearán pull requests y despliegues de su período de observación. Verificarán que las revisiones de código ocurrieron antes del merge, que los despliegues siguieron su proceso documentado y que los cambios de emergencia fueron documentados y aprobados retroactivamente.

Ejemplo SaaS: Su política requiere que todos los cambios de producción pasen por un pull request con al menos una revisión por pares, pasen las pruebas del pipeline de CI/CD y se desplieguen a través de su sistema de despliegue automatizado. Los hotfixes de emergencia pueden omitir la revisión estándar pero requieren revisión post-despliegue dentro de las 48 horas y una justificación documentada.

4. Política de respuesta a incidentes

Su política de respuesta a incidentes define cómo su organización detecta, responde y se recupera de los incidentes de seguridad. Esta es una de las políticas más escrutadas porque afecta directamente la protección de datos de los clientes. Para profundizar en la construcción de una capacidad efectiva de respuesta a incidentes, consulte nuestra guía de respuesta a incidentes.

Qué cubre: Clasificación de incidentes y niveles de severidad, mecanismos de detección, procedimientos de escalamiento, pasos de contención y erradicación, procedimientos de recuperación, protocolos de comunicación (internos y externos), proceso de revisión post-incidente y preservación de evidencias.

En la práctica: Los auditores solicitarán registros de incidentes del período de observación. Si tuvo incidentes, rastrearán su respuesta contra esta política. Si tuvo cero incidentes, probarán sus capacidades de detección para confirmar que realmente detectaría uno.

Ejemplo SaaS: Su política define cuatro niveles de severidad (P1-P4), requiere una sala de crisis para incidentes P1 dentro de los 15 minutos de la detección, exige la notificación al cliente dentro de las 72 horas para brechas de datos y requiere un post-mortem escrito para todos los incidentes P1 y P2 dentro de cinco días hábiles.

5. Política de evaluación de riesgos

La evaluación de riesgos es fundamental para SOC 2 — los Common Criteria requieren explícitamente un proceso formal y repetible para identificar y evaluar el riesgo. Para un recorrido completo del proceso de evaluación de riesgos, consulte nuestra guía de evaluación de riesgos.

Qué cubre: Metodología de evaluación de riesgos (cualitativa, cuantitativa o híbrida), frecuencia de evaluación (al menos anualmente), enfoque de identificación de riesgos, criterios de puntuación de probabilidad e impacto, umbrales de aceptación de riesgos, opciones de tratamiento de riesgos (mitigar, transferir, aceptar, evitar) y roles responsables de la propiedad del riesgo.

En la práctica: Los auditores quieren ver una metodología documentada, una evaluación de riesgos completada dentro del período de observación y evidencia de que los riesgos identificados fueron rastreados y tratados. Una evaluación de riesgos que permanece en un estante sin tocar durante 11 meses es un hallazgo.

6. Política de gestión de proveedores

Su informe SOC 2 es tan fuerte como su ecosistema de proveedores. Esta política gobierna cómo evalúa, incorpora, monitorea y desvincula a terceros. Para el marco completo de gestión de proveedores, consulte nuestra guía de gestión de proveedores.

Qué cubre: Clasificación de proveedores por nivel de riesgo, requisitos de debida diligencia (revisión de informes SOC 2, cuestionarios de seguridad), requisitos contractuales de seguridad, cadencia de monitoreo continuo, gestión de sub-encargados y procedimientos de desvinculación de proveedores.

En la práctica: Los auditores revisarán su inventario de proveedores, verificarán que los proveedores críticos hayan sido evaluados y verificarán que usted revisó sus informes SOC 2 durante el período de observación.

7. Política de clasificación de datos

La clasificación de datos define cómo su organización categoriza la información según su sensibilidad y los requisitos de manejo para cada categoría. Esta política impulsa las decisiones de cifrado, acceso, retención y eliminación en toda su pila tecnológica.

Qué cubre: Niveles de clasificación (ej., Público, Interno, Confidencial, Restringido), criterios para asignar clasificaciones, requisitos de manejo por nivel (almacenamiento, transmisión, acceso, eliminación), expectativas de etiquetado de datos y quién tiene autoridad para clasificar datos.

Ejemplo SaaS: Los datos de clientes en su base de datos de producción se clasifican como Confidenciales, requiriendo cifrado en reposo y en tránsito, acceso restringido a servicios y personal autorizados, y eliminación segura al terminar el contrato. La documentación interna se clasifica como Interna, requiriendo autenticación pero no cifrado en reposo.

8. Política de uso aceptable

La política de uso aceptable define las responsabilidades de los empleados al utilizar los sistemas, redes y datos de la empresa. Establece las expectativas de comportamiento y sienta las bases para acciones disciplinarias cuando se violan esas expectativas.

Qué cubre: Usos permitidos y prohibidos de los sistemas de la empresa, políticas de dispositivos personales, uso de internet y correo electrónico, directrices de redes sociales, responsabilidades de manejo de datos, reglas de instalación de software y consecuencias por violaciones.

En la práctica: Cada empleado debe firmar esta política durante la incorporación. Los auditores verificarán los registros de reconocimiento. Esta política también sirve como base para los procedimientos disciplinarios relacionados con violaciones de seguridad.

9. Política de continuidad del negocio y recuperación ante desastres

Si incluye el criterio de Disponibilidad en su alcance SOC 2 — y la mayoría de las empresas SaaS lo hacen — necesita una política de BC/DR documentada. Incluso sin Disponibilidad, los Common Criteria del criterio de Seguridad abordan la recuperación del sistema.

Qué cubre: Objetivo de Tiempo de Recuperación (RTO) y Objetivo de Punto de Recuperación (RPO) para sistemas críticos, procedimientos de respaldo y verificación, mecanismos de conmutación por error, frecuencia y metodología de pruebas de recuperación ante desastres, planes de comunicación durante interrupciones y roles y responsabilidades durante un evento de desastre.

Ejemplo SaaS: Su política establece un RTO de 4 horas y un RPO de 1 hora para su aplicación de producción. Los respaldos se ejecutan cada hora a una región separada de AWS. La conmutación por error de DR se prueba trimestralmente con resultados documentados, y la última prueba exitosa restauró el servicio completo en 2,5 horas.

10. Política de seguridad de recursos humanos

Las personas son una capa de control crítica. Esta política cubre los aspectos de seguridad del ciclo de vida del empleado, desde la precontratación hasta la post-terminación.

Qué cubre: Requisitos de verificación de antecedentes, capacitación de seguridad durante la incorporación (y anualmente a partir de entonces), acuerdos de confidencialidad y no divulgación, responsabilidades de seguridad basadas en roles, procedimientos de desvinculación (revocación de acceso, devolución de activos, entrevistas de salida) y proceso disciplinario por violaciones de seguridad.

En la práctica: Los auditores muestrearán expedientes de empleados para verificar que las verificaciones de antecedentes se completaron, que existen registros de capacitación y que los empleados terminados fueron desvinculados adecuadamente. Si su política dice que las verificaciones de antecedentes se completan antes de la fecha de inicio, verificarán las fechas.

Qué hace que una política esté lista para la auditoría

Redactar una política no es suficiente — debe cumplir estándares de calidad específicos que los auditores evalúan. Esto es lo que separa una política que aprueba de una que genera hallazgos.

Control de versiones y fechas de aprobación. Toda política debe mostrar cuándo fue creada, cuándo fue revisada por última vez, aprobada y por quién. Los auditores observan la fecha de aprobación en relación con el período de observación. Una política aprobada hace tres años sin evidencia de revisión es un problema.

Propiedad clara. Cada política necesita un propietario designado responsable de su contenido, aplicación y revisión. “El equipo de seguridad” no es lo suficientemente específico. Nombre el rol: “El CISO es responsable de la Política de Seguridad de la Información.”

Requisitos específicos y medibles. “El acceso debe revisarse regularmente” no aprueba. “Las revisiones de acceso se realizan trimestralmente, con la remediación completada dentro de 14 días hábiles” sí aprueba. Cada compromiso en una política se convierte en una afirmación verificable.

Cadencia de revisión regular. Las políticas deben revisarse al menos anualmente. Documente la fecha de revisión, quién la realizó y qué cambios se hicieron (o declare explícitamente “no se requirieron cambios”). Los auditores verificarán que esto sucedió durante el período de observación.

Reconocimiento del empleado. Los empleados deben reconocer formalmente las políticas clave — como mínimo la Política de Seguridad de la Información y la Política de Uso Aceptable. Rastree los reconocimientos con fechas y conserve los registros.

Alineación con la práctica real. Este es el criterio más importante y el que causa más hallazgos de auditoría. Si su política dice algo, usted debe hacerlo. Los auditores probarán la política contra la realidad operativa. Una política aspiracional que no coincide con sus operaciones es peor que no tener política, porque demuestra una falla de control.

Errores comunes en las políticas

Después de trabajar con cientos de empresas SaaS, estos son los errores de política que vemos con más frecuencia.

Copiar y pegar plantillas sin personalización. Las plantillas genéricas usan lenguaje como “la organización mantendrá controles de acceso físico a las salas de servidores.” Si usted es una empresa SaaS nativa de la nube que funciona en AWS, no tiene salas de servidores. Los auditores señalarán inmediatamente las políticas que no reflejan su entorno real. Las plantillas son un punto de partida, no un producto terminado.

Redactar políticas aspiracionales. Su política dice que las revisiones de acceso ocurren mensualmente. Su evidencia de revisión de acceso muestra que ocurren trimestralmente — a veces. Esto crea una falla de control que es peor que tener una política trimestral, porque ha demostrado que no cumple con sus propios compromisos. Redacte políticas que coincidan con lo que realmente hace, luego mejore iterativamente.

Falta de metadatos de revisión y aprobación. Una política sin fecha de aprobación, número de versión o aprobador nombrado está incompleta. Algunas organizaciones escriben excelente contenido de política pero olvidan el marco administrativo que lo rodea. Los auditores verifican los metadatos primero.

Políticas excesivamente complejas que nadie lee. Una política de seguridad de la información de 40 páginas que cubre cada escenario concebible es técnicamente exhaustiva y prácticamente inútil. Si sus ingenieros no pueden encontrar rápidamente los requisitos relevantes para su trabajo, la política no está cumpliendo su propósito. Mantenga las políticas enfocadas y legibles. Traslade las instrucciones detalladas a los procedimientos.

No actualizar después de cambios organizacionales. Migró de AWS a GCP, promovió un nuevo CISO o reestructuró su equipo de ingeniería. Si sus políticas aún hacen referencia al entorno antiguo, al antiguo CISO o a la antigua estructura del equipo, los auditores notarán la inconsistencia.

Procedimientos: los detalles operativos

Los procedimientos son donde las políticas se vuelven operativas. Mientras que una política establece “el acceso de usuario se revisará trimestralmente,” el procedimiento define exactamente cómo se realiza esa revisión, quién la hace, qué herramientas se utilizan y cómo se rastrea la remediación.

Procedimientos clave para empresas SaaS

Procedimiento de revisión de acceso de usuario. Instrucciones paso a paso para realizar revisiones trimestrales de acceso: quién extrae las listas de acceso, qué sistemas se revisan, cómo se documentan las discrepancias, cómo se asigna y rastrea la remediación, y cómo se almacena la revisión completada como evidencia.

Procedimiento de despliegue de cambios. El flujo de trabajo detallado para llevar el código del branch de un desarrollador a producción: convenciones de nombres de branches, requisitos de plantilla de PR, asignación de revisores, etapas del pipeline de CI/CD, pasos de verificación en staging, proceso de despliegue a producción y requisitos de pruebas de humo.

Procedimiento de gestión de vulnerabilidades. Cómo se identifican las vulnerabilidades (herramientas de escaneo, frecuencia), se clasifican (clasificación de severidad), se asignan a propietarios, se remedian dentro del SLA (crítico: 7 días, alto: 30 días, medio: 90 días) y se verifican como resueltas. Incluya el proceso para excepciones y riesgos aceptados.

Procedimiento de respaldo y restauración. Pasos detallados para configurar respaldos, verificar la integridad del respaldo (cadencia de verificación automatizada y manual), realizar una restauración y documentar los resultados. Incluya el calendario para las pruebas de restauración.

Procedimiento de respuesta a incidentes. El manual paso a paso para cada nivel de severidad de incidente: a quién se notifica y cómo, qué canales de comunicación se utilizan, cómo se configura la sala de crisis, pasos de contención por tipo de incidente, requisitos de preservación de evidencias, plantillas de comunicación al cliente, y plantilla y cronograma de post-mortem.

Cada procedimiento debe hacer referencia explícita a la política principal que implementa. Esta trazabilidad es algo que los auditores buscan — demuestra que sus detalles operativos están gobernados por compromisos aprobados.

Evidencia de cumplimiento de políticas

Los auditores no confían en su palabra. Prueban si sus operaciones coinciden con sus políticas examinando evidencias durante todo el período de observación. Para una guía completa de recopilación de evidencias, consulte nuestra guía de recopilación de evidencias.

Evidencia de control de acceso: Informes de revisión de acceso trimestral que muestran quién revisó qué, discrepancias encontradas y remediación tomada. Configuraciones de aplicación de MFA. Tickets de desaprovisionamiento con marcas de tiempo que muestran el cumplimiento con su SLA.

Evidencia de gestión de cambios: Historial de pull requests que muestra revisiones de código antes del merge. Logs de despliegue que coinciden con su proceso documentado. Tickets de cambio de emergencia con aprobaciones retroactivas.

Evidencia de respuesta a incidentes: Tickets de incidentes con marcas de tiempo que muestran la detección, respuesta y resolución. Informes post-mortem para incidentes significativos. Registros de comunicación que muestran notificaciones a clientes cuando fueron requeridas.

Evidencia de capacitación: Registros de finalización de capacitación con fechas. Registros de reconocimiento de políticas. Registros de incorporación de nuevos empleados que muestran que la capacitación de seguridad se completó dentro del plazo requerido.

Evidencia de evaluación de riesgos: Documentos de evaluación de riesgos completados fechados dentro del período de observación. Registro de riesgos que muestra planes de tratamiento y actualizaciones de estado. Actas de reuniones de sesiones de revisión de riesgos.

La brecha más común entre política y práctica es el tiempo. Su política dice que las revisiones de acceso ocurren trimestralmente. Usted completó tres revisiones durante un período de observación de 12 meses en lugar de cuatro. Eso es un hallazgo — no porque sus revisiones fueran inadecuadas, sino porque no cumplió con su propia frecuencia declarada. Por eso importa tanto redactar políticas realistas.

Cómo ayuda GRCTrail

GRCTrail ofrece a los equipos SaaS un enfoque estructurado para construir y mantener el marco de políticas que requiere SOC 2.

• Plantillas de políticas alineadas con los Common Criteria de SOC 2 que cubren cada área de política requerida, escritas específicamente para empresas SaaS para que no tenga que editar referencias a centros de datos físicos
• Gestión de políticas con control de versiones con flujos de trabajo de aprobación integrados, seguimiento de revisiones y historial de cambios que los auditores pueden verificar de forma independiente
• Seguimiento de reconocimiento de empleados que registra cuándo cada miembro del equipo revisó y aceptó las políticas, con recordatorios automatizados para nuevas contrataciones y actualizaciones de políticas
• Recordatorios de revisión de políticas que se activan antes de la fecha límite de su revisión anual, asegurando que nunca se pierda un ciclo de revisión durante su período de observación
• Recopilación de evidencias vinculada que conecta las políticas con los controles que las implementan y las evidencias que prueban el cumplimiento — para que siempre sepa si hay una brecha entre lo que se comprometió y lo que realmente está haciendo

Comience con GRCTrail →

Guías relacionadas

• ¿Qué es SOC 2? Una guía práctica para empresas SaaS
• Recopilación de evidencias SOC 2: lo que realmente buscan los auditores
• Guía de evaluación de riesgos SOC 2
• Common Criteria de SOC 2 explicados