SOC 2: procedimientos listos para auditoría sin sprint de doc
Un auditor SOC 2 no quiere páginas de Notion bonitas. Quiere la prueba de que un control se ejecutó. Una guía grabada por el responsable del proceso, con marcas de tiempo en cada clic, es la prueba más limpia que la mayoría de auditores ve en todo el año.
- Biblioteca reconstruida
- 6 semanas
- Cobertura de la auditoría
- 100%
- Seguimientos post-auditoría
- 0
- Cierre de la auditoría
- 2 semanas antes
Lo esencial.
Una auditoría SOC 2 rara vez cae por los controles. Cae por la prueba. Los equipos tienen los controles montados. No saben demostrar que se ejecutan. La salida cabe en una regla: cada responsable graba su proceso una vez, la grabación lleva marcas de tiempo y capturas de pantalla, y el mismo artefacto sirve de SOP en el día a día y de evidencia en la semana de auditoría. Seis semanas, 21 SOP, fintech B2B española de 38 personas en Series A: 100% de los controles cubiertos, cero documentos redactados desde cero.
El agujero en la documentación SOC 2 del que nadie avisa
La mayoría de fintechs early-stage se preparan para SOC 2 contratando una plataforma de conformidad (Vanta, Drata, Secureframe) y dedicando seis semanas a las políticas. Las políticas son la parte fácil. La plataforma plantillea el noventa por ciento.
El agujero aparece en el fieldwork. El auditor pide la prueba de que un control concreto se ejecutó durante el periodo de auditoría. No la política. La ejecución. Con ejemplos.
Revisión de accesos (CC6.3): pide la última revisión trimestral, la lista de usuarios revisados y las acciones tomadas. El equipo la ha hecho. La prueba es una captura archivada en el Drive de alguien, que cuadra más o menos con el calendario de la política.
Gestión del cambio (CC8.1): pide el recorrido de un cambio de código hasta producción. El equipo tiene el proceso. El recorrido acaba siendo un ingeniero senior explicando frente a una pizarra durante treinta minutos en plena semana de auditoría.
Gestión de proveedores (CC9.2): pide el proceso de incorporación de un nuevo subencargado y la prueba de la evaluación. La prueba es una página de Notion con cinco pestañas, la mitad de las cuales describe al proveedor anterior.
No son agujeros de política. Son agujeros de prueba. El coste de taparlos en la semana de auditoría ronda las cuarenta horas de tiempo senior por control. Esa es la factura que sorprende a todo el mundo en la primera auditoría.
El instinto de "reescribir las SOP" empeora la situación: dieciocho SOP a dos horas cada una son treinta y seis horas de redacción para una doc que caduca dos meses después. Los Trust Services Criteria SOC 2 de la AICPA lo dejan claro: la prueba es el artefacto del trabajo, no la descripción del trabajo.
Lo que el auditor quiere de verdad, frente a lo que el equipo redacta
La evaluación de una prueba pasa por tres tests.
1. ¿El proceso se ejecutó durante el periodo de auditoría? Una página de Notion no responde. Una grabación con marca de tiempo, sí. Un log de clics, sí. El auditor no busca una descripción, busca una traza. La investigación de NNGroup sobre por qué los lectores web escanean en vez de leer describe el mismo patrón cognitivo que aplica un auditor delante de un pack de pruebas: la mirada salta a los timestamps y a los nombres de responsables; el texto descriptivo se ignora.
2. ¿El proceso es reproducible? Un Loom único de enero de 2024 no es prueba reproducible. Una guía que dice "Responsable: Carmen; última revisión: abril de 2026; revisión de accesos Q1 adjunta" sí lo es. El auditor quiere saber que el mismo proceso corrió en Q1, Q2, Q3 y Q4.
3. ¿El proceso aguanta sin su autor? La pregunta donde la mayoría se cae. La CFO grabó la SOP, luego se fue, y la nueva CFO no la ejecuta igual. Los auditores lo llaman "dependencia de persona clave" y lo marcan en CC1.4.
La página de Notion bien colocada falla en los tres. La guía grabada por el responsable pasa los tres. Cuando una fintech B2B de 38 personas reconstruyó su biblioteca de SOP en seis semanas para SOC 2, la nota del auditor cabía en una frase: "la prueba SOC 2 más limpia que he visto este año". Veintiuna guías, grabadas por los responsables, con marcas de tiempo y capturas integradas. Para los temas de datos personales, la AEPD espera una lógica equivalente desde el lado RGPD: la prueba de ejecución pesa más que la descripción.
| Pregunta del auditor | Respuesta floja | Respuesta sólida |
|---|---|---|
| Enséñeme la revisión de accesos del Q1 | "Aquí tiene la política" | "Aquí tiene la revisión grabada con marcas de tiempo, la lista de usuarios al 31 de marzo y los desaprovisionamientos hechos" |
| ¿Cómo llega un cambio de código a producción? | "Un ingeniero senior se lo cuenta al auditor" | "Aquí tiene la SOP grabada con prueba en pantalla de los checks CI, la review del PR y el paso de despliegue" |
| ¿Qué pasa cuando se añade un subencargado? | "Aquí tiene la página de Notion" | "Aquí tiene la guía grabada de onboarding de proveedor y la prueba de las tres últimas evaluaciones" |
El patrón: SOP grabada por el responsable
El patrón que produjo el 100% de cobertura cabe en una regla única: graba la SOP el responsable del proceso, no un equipo de doc centralizado.
Tres motivos.
1. La grabación capta el proceso real. Un redactor central que entrevista al responsable produce una descripción. El responsable que ejecuta su workflow produce el workflow. El auditor nota la diferencia al instante.
2. El bucle de mantenimiento es corto. Cuando el proceso cambia (nueva herramienta, nuevo aprobador, nuevo umbral), el responsable regraba el paso en dos minutos. Un redactor central es un cuello de botella que rompe el bucle al primer trimestre.
3. La responsabilidad se vuelve auditable. SOC 2 CC1.4, dentro de la suite SOC for Service Organizations de la AICPA, exige responsabilidades definidas. Una SOP con responsable nombrado, localizable para demostrar el proceso, satisface CC1.4. Una página de Notion sin propietario, no.
El setup tiene cuatro pasos.
Paso 1. Listar los controles del perímetro SOC 2. Entre quince y treinta controles en el scope de un Type 2. Cada control tiene un responsable y una SOP.
Paso 2. Asignar un responsable por control. El responsable es la persona que ejecuta el proceso hoy. No el dueño de la política. No el autor de la política. La persona que clica en el workflow real cuando se ejecuta. Revisión de accesos: en general el lead de IT, no el CISO. Gestión de proveedores: Operaciones, no Legal.
Paso 3. Cada responsable graba la SOP una vez. Veinticinco minutos la primera. Diez la tercera. El responsable ejecuta su proceso como un día normal, comenta el razonamiento, y para cuando el proceso acaba. Salida: una guía con marcas de tiempo, capturas y audio del narrador si el auditor lo pide.
Paso 4. Regrabar el paso que cambia. Cambia un paso, se regraba ese paso. La biblioteca se mantiene viva sin sprint de redacción.
La herramienta usada en el encargo era una extensión de Chrome que captura clics y pantallas automáticamente. Otras herramientas funcionan; el modelo de operación importa más que la herramienta. Lo que nunca funciona son las páginas de Notion monolíticas sin dueño.
Cómo grabar la prueba sobre la marcha
El patrón anterior produce SOP. Lo que pide la semana de auditoría es la SOP más la prueba de ejecución reciente. El truco está en hacer que sean el mismo artefacto.
Tres patrones.
1. Marcar la ejecución con timestamp. Cada grabación produce un artefacto datado. Cuando la revisión de accesos corre en Q1, el responsable graba la sesión. La misma grabación sirve de SOP para Q2 y de prueba para Q1. A los auditores les gusta porque la SOP y la prueba son el mismo objeto, trazable a una fecha.
2. Captar la vista de los datos, no la traza de código. La prueba que el auditor espera es el dato que el operador vio, no los pasos que el operador hizo. Una grabación de revisión de accesos capta la lista de usuarios tal y como aparece en el IDP, los roles asignados y los desaprovisionamientos. Esa es la prueba. La secuencia de clics es la SOP.
3. Exportar como PDF brandeado para el pack de prueba. La mayoría de plataformas de auditoría ingiere PDF o HTML. Capture exporta con marcas de tiempo, contadores de clics y capturas paso a paso. El responsable lo deposita en la carpeta de la auditoría. Sin paquete de pruebas que montar aparte.
El efecto de capitalización es la sorpresa. La primera auditoría pide más trabajo, porque la biblioteca se está construyendo. La segunda lleva una fracción del tiempo: la biblioteca ya existe, los responsables conocen el gesto y el pack de prueba se monta solo desde la SOP en producción.
Si el equipo aún no ha elegido la herramienta de doc para el esfuerzo SOC 2, el comparativo de mejores alternativas a Scribe en 2026 cubre los siete candidatos que los auditores ven con más frecuencia en los packs de prueba. Y si la pregunta del precio del entregable de doc surge en paralelo, ver cómo fijar el precio del entregable de documentación.
La checklist de la semana de auditoría
A una semana de la auditoría, la biblioteca tiene que responder a todas las preguntas estándar de auditor sin que un senior escriba contenido nuevo. La checklist que sigue es la que cierra la auditoría dos semanas antes de plazo.
- Cada control tiene un responsable nombrado en la metadata de la SOP. "Quién pilota esto" se lee en el artefacto, no en una cabeza.
- Cada SOP se ha regrabado o refrescado en los últimos seis meses. Más allá, la presión sube.
- La última ejecución tiene marca de tiempo y cae dentro del periodo. Q1 grabado en Q2, vale. Enero sin actualización en Q3, no.
- La SOP y la prueba son el mismo artefacto. El PDF del pack es la guía con la que se pilota el proceso. Sin gap entre política y práctica.
- La metadata de grabación es auditable. Contador de clics, marcas de tiempo y audio del narrador son exportables. El auditor verifica que la grabación sale del sistema real, no de una recreación.
- La biblioteca tiene una página de índice única. El auditor pide la lista maestra, el equipo manda una URL.
Al revés, la semana de auditoría que no cierra a tiempo tiene al menos cuatro de estos puntos en falta. Lo más habitual es los puntos 3 y 4.
Para el COO del encargo, el scope SOC 2 cabía en tres líneas: la responsabilidad es auditable, la prueba en pantalla es auditable, regrabar un paso va más rápido que reescribir una página de wiki. Tres líneas, veintiún controles, auditoría cerrada dos semanas antes de la fecha prevista. Para los frentes RGPD que se solapan (registro de tratamientos, subencargados), la AEPD espera la misma lógica desde el lado de protección de datos.
Preguntas frecuentes.
- ¿El patrón funciona para SOC 2 Type 1 o solo para Type 2?
Los dos. Type 1 es un test a fecha fija: las SOP deben estar grabadas a la fecha del test. Type 2 es un test sobre periodo, y ahí es donde el patrón capitaliza: cada ejecución trimestral pasa a ser la prueba del periodo anterior y la SOP del siguiente. La mayoría de equipos construyen para Type 2 porque la inversión por control se amortiza sobre toda la ventana de la auditoría.
- ¿En qué se diferencia esto de usar Vanta, Drata o Secureframe?
Las plataformas de conformidad gestionan las plantillas de políticas, el monitoring de controles y la recogida de pruebas desde los sistemas conectados (cloud, IDP, ticketing). No generan las SOP. El patrón de grabación-primero rellena ese hueco. Los equipos hacen rodar la plataforma para el monitoring y una herramienta de guías para las SOP. Las dos juntas producen el pack listo para auditoría.
- ¿Y para ISO 27001 o HIPAA?
Mismo patrón. ISO 27001 pesa más en doc que SOC 2, lo que vuelve aún más rentable el enfoque por responsable: la carga capitaliza con el número de controles. HIPAA tiene un perímetro más estrecho pero el mismo principio de prueba de ejecución. El patrón es agnóstico al framework; al auditor le importa la prueba con marca de tiempo y trazable, no la sigla de arriba.
- ¿Cómo se gestionan las SOP que tocan datos sensibles (PII, financieros)?
Dos enfoques. Primero, la redacción: la mayoría de herramientas de guía permiten difuminar o tapar una zona de la pantalla. Con Capture, el responsable coloca un parche sobre la zona PII antes de publicar. Segundo, el sandbox: se graba la SOP en un entorno de staging con datos sintéticos. Los auditores aceptan los dos, siempre que la SOP coincida con el proceso de producción y la redacción o el sandbox queden documentados. Por el lado RGPD, la AEPD espera una lógica equivalente sobre registros y accesos.
- ¿Cuánto se tarda en construir la biblioteca desde cero?
La fintech española de 38 personas del encargo produjo veintiuna SOP en seis semanas, con un responsable por SOP y una sesión de grabación por responsable y semana. El patrón escala: un equipo de 60 personas con treinta SOP cierra en la misma ventana de seis semanas, porque el trabajo va en paralelo entre responsables. El cuello de botella es la disponibilidad de los responsables, no el tiempo de grabación. La grabación en sí lleva veinticinco minutos para la primera SOP y baja a diez minutos a la tercera.
¿Ya doblan tus SOP como prueba de auditoría?
Capture graba la SOP, capta la prueba en pantalla y exporta un PDF brandeado para el pack de la auditoría. Extensión de Chrome gratuita, sin registro. Cada responsable graba una vez, la biblioteca se actualiza paso a paso.
Alternativa a Tango para equipos de IT Ops en 2026
Un equipo IT en una scale-up de 220 personas convirtió sus veinte tickets recurrentes en guías Capture. El volumen Tier-1 cayó un 35 % en ocho semanas. El resto es la aritmética del puesto.
Cómo documentar un flujo de onboarding de clientes en 2026
La mayoría de las guías de onboarding caducan en ocho semanas porque nadie las regraba cuando la UI cambia. La salida no es un mejor redactor. Es un método recording-first que cuesta diez minutos por actualización.
La regla de los 12 pasos: por qué la longitud predice el fracaso
Casi todo equipo de documentación escribe guías más largas de lo que debería. La longitud juega en tu contra, y 12 pasos es el techo operativo a partir del cual la tasa de finalización se desploma.
Graba un workflow.
Extensión de Chrome gratuita. Sin registro.