Operaciones y Legal

Introducción a SOC 2: lo que un asistente operativo debe documentar

5 de octubre de 2026 · Equipo Talento Bilingüe · 16 min de lectura

Cuando una empresa de Estados Unidos contrata talento remoto en Latinoamérica para roles de operaciones, el scorecard de selección ya no se limita a velocidad de respuesta en Slack o dominio de Notion. En los últimos ciclos de contratación que he revisado, el filtro silencioso que aparece después de la segunda entrevista es la capacidad del candidato de producir evidencia limpia y recuperable de tres controles: revisiones de accesos, registros de auditoría y gestión de cambios. SOC 2 no es un “plus de compliance” que solo toca al equipo de seguridad. Es el marco que obliga a la compañía a demostrar, ante auditores externos, que cada persona con privilegios —incluyendo un asistente operativo que administra usuarios en Google Workspace, aprueba cambios en HubSpot o mueve fondos en Stripe— deja rastro verificable. Si tú entras como independent contractor y firmas un W-8BEN, el cliente sigue siendo responsable de tu huella dentro de sus sistemas. Por eso el reclutador de Greenhouse o Ashby te pregunta, sin rodeos, si alguna vez generaste reportes de access review, exportaste logs o documentaste un change request. Quien no sabe qué se espera de esa documentación queda fuera aunque hable inglés perfecto y cobre por debajo del rango de mercado. Esta guía te muestra exactamente qué debes registrar, cómo presentarlo y qué errores convierten tu trabajo diario en un riesgo de auditoría.

¿Qué debe documentar un asistente operativo para cumplir con SOC 2?

Un asistente operativo que apoya a una empresa de EE. UU. sujeta a SOC 2 debe dejar evidencia recuperable de tres cosas: quién tiene acceso a qué sistema y cuándo se revisó ese acceso, qué acciones se ejecutaron en las plataformas críticas y quién las autorizó, y qué cambios se hicieron en configuraciones, flujos o integraciones junto con la aprobación y la prueba posterior. Esas tres piezas —access reviews, audit logs y change controls— son las que el auditor pide con mayor frecuencia cuando el rol toca datos de clientes, finanzas o identidad. Si no las documentas de forma consistente, el cliente no puede incluirte en el perímetro de control y, en la práctica, deja de renovar el contrato. El resto de esta guía detalla cómo producir esa evidencia sin convertirte en un auditor a tiempo completo.

La mayoría de los asistentes operativos que trabajan con startups y scale-ups de Estados Unidos tocan al menos cuatro o cinco sistemas que caen dentro del alcance de SOC 2 Type II: Google Workspace o Microsoft 365, Slack, un CRM (HubSpot o Salesforce), una herramienta de pagos o facturación (Stripe, QuickBooks o Xero) y, con frecuencia, un panel de administración de usuarios o de infraestructura ligera. Cada uno de esos sistemas genera logs. Tu trabajo no es interpretar el log completo; es asegurarte de que exista un registro de que alguien lo revisó, que las excepciones se escalaron y que los cambios quedaron aprobados antes de ejecutarse.

Empieza por las revisiones de accesos. En la práctica esto significa un ciclo trimestral o semestral (el periodo lo define la política del cliente) en el que exportas la lista de usuarios activos de cada herramienta, la contrastas con el roster actual de la empresa y marcas quién debe quedarse, quién debe bajar de privilegio y quién debe eliminarse. El entregable no es un screenshot suelto. Es un archivo con fecha, nombre del revisor, sistema revisado, lista de hallazgos y acciones tomadas. Si usas Deel o un portal similar para onboarding de contractors, incluye también la fecha en la que se revocó el acceso al terminar la relación.

Los registros de auditoría son el rastro de lo que ya ocurrió. Cuando un auditor pide “show me the audit trail for user provisioning in Q2”, espera ver exports o capturas con timestamp, usuario que ejecutó la acción, acción concreta y resultado. Tú no tienes que construir el SIEM; tienes que saber dónde vive el log nativo (Google Admin audit log, HubSpot audit log, Stripe dashboard events, Slack enterprise grid logs si aplica) y cómo exportarlo o enlazarlo a un repositorio controlado, normalmente un folder de Notion o un drive con permisos restringidos y naming convention clara.

Los controles de cambios cubren cualquier modificación que altere la forma en que fluye la información o el dinero: nueva automatización en Zapier o Make, cambio de permisos de un pipeline en Salesforce, actualización de una plantilla de factura en QuickBooks, o la conexión de una nueva integración en Stripe. El mínimo viable es un registro con: descripción del cambio, quién lo solicitó, quién lo aprobó, fecha de ejecución, evidencia de prueba (aunque sea un Loom de 90 segundos) y confirmación de que no rompió controles existentes. Sin ese hilo, el auditor clasifica el cambio como “unauthorized” aunque haya sido inocente.

¿Qué herramientas exigen las empresas de EE. UU. para evidenciar estos controles?

Las compañías que ya pasaron por una o dos auditorías SOC 2 no improvisan. Te van a pedir que trabajes dentro del stack que ya tienen instrumentado. En el día a día de un asistente operativo remoto verás con mucha frecuencia:

• Google Workspace o Microsoft 365 para identidad y correo, con sus audit logs nativos.
• Slack para comunicación y, en planes Enterprise, para retención y export de mensajes.
• Notion o un repositorio equivalente como fuente de verdad de políticas, checklists y evidencias.
• HubSpot o Salesforce para CRM, ambos con audit logs de cambios de propiedad, exportaciones y modificaciones de campos.
• Stripe, QuickBooks o Xero para dinero; Stripe es especialmente estricto con los eventos de API y los cambios de configuración de webhooks.
• Deel (o similar) para la relación contractual del independent contractor, incluyendo la firma del W-8BEN y el registro de fechas de alta y baja.
• Loom para evidencia visual rápida de pruebas de cambio o de walkthroughs de procesos.
• Greenhouse o Ashby del lado del cliente cuando el proceso de hiring también está dentro del alcance (menos frecuente para un ops assistant, pero aparece).
• Checkr o HireRight cuando el background check del contractor forma parte del control de onboarding.

Además, muchas empresas medianas ya usan plataformas de continuous compliance como Vanta o Drata. Tú no las administras, pero sí subes evidencias a ellas o respondes requests de “evidence collection”. Si te piden un access review, el formato suele ser un CSV o un Google Sheet con columnas fijas que después se conectan a la herramienta de compliance. Aprende a generar esos exports sin pedir ayuda cada trimestre: es una de las habilidades que más rápido te sube de “asistente que ejecuta” a “asistente que sostiene el control”.

Los rangos de compensación para alguien que domina esto y trabaja full-time remoto desde Latinoamérica como independent contractor suelen moverse entre USD 3.200 y USD 5.800 mensuales según seniority y alcance (aproximadamente USD 40.000–70.000 anuales). Roles más cercanos a “Operations Specialist” o “Compliance Ops Coordinator” con responsabilidad directa sobre evidencias SOC 2 pueden llegar a USD 6.000–7.500 mensuales cuando el inglés es sólido y la persona ya sobrevivió al menos un ciclo de auditoría. Estos números se negocian casi siempre por hora o por mes vía Deel o similar, con el contractor asumiendo sus obligaciones fiscales locales y entregando el W-8BEN.

¿Cómo responder cuando te piden evidencia de revisiones de accesos o logs de auditoría?

La forma en que contestas define si te perciben como alguien que ya operó dentro de un entorno controlado o como alguien que solo “ayuda con tareas”. Los reclutadores y los hiring managers de operaciones en EE. UU. usan phrasal verbs muy concretos: “walk me through”, “pull the logs”, “close the loop”, “flag the exceptions”. Tu respuesta tiene que sonar natural en ese registro.

Aquí tienes un guion completo de una conversación típica en segunda o tercera entrevista. Úsalo como base; no lo memorices palabra por palabra, pero interioriza la estructura.

Interviewer: Walk me through how you’ve handled access reviews in your previous role. What did you actually own?

You: Sure. In my last engagement I owned the quarterly access review for Google Workspace, HubSpot and Stripe. I would pull the user lists the first week of the quarter, compare them against the active contractor and employee roster in Deel and Notion, and flag anyone who had left or changed roles. Then I’d send the exceptions to the hiring manager or the system owner, wait for written approval in Slack or email, execute the removals or downgrades, and save the dated spreadsheet plus the approval thread in a locked Notion database. That package was what we later uploaded to Vanta when the auditor asked for evidence.

Interviewer: How long did that usually take you, and what happened when someone didn’t respond?

You: The export and first pass took me about three to four hours. Follow-ups were the longer part. If a manager didn’t get back within five business days I escalated once in the ops channel and once directly. We had a hard rule: no response after the second ping meant we disabled the account and documented the disable as “temporary pending confirmation.” That kept us from carrying open exceptions into the audit window.

Interviewer: And audit logs? Have you ever had to pull those for a specific incident or for the auditor?

You: Yes. Twice for the auditor and once for an internal investigation. I know where the native logs live—Google Admin audit log, HubSpot’s audit log under settings, and Stripe’s Events and Logs section. I export with the date range they ask for, keep the raw file immutable, and add a one-page summary that says what I looked for and what I found. I never edit the raw export. That habit saved us time when the auditor wanted to re-perform the test.

Fíjate en los phrasal verbs: walk me through, pull the lists, flag the exceptions, close the loop, get back, carry open exceptions. Esos son los que esperan oír. Si respondes con abstracciones (“me aseguro de que todo esté compliant”), pierdes credibilidad.

Segundo guion, esta vez en una llamada operativa real con un cliente que ya te contrató y te pide evidencia para el ciclo actual:

Client: Hey, the auditor is coming in three weeks and they asked for the Q1 access review evidence for HubSpot and Stripe. Can you put that together by Friday?

You: Absolutely. I’ll pull both user exports today, cross-check them against the current Deel roster and the offboarding list we keep in Notion, and highlight any accounts that should have been removed. I’ll drop the draft spreadsheet in the Compliance Evidence channel by end of day tomorrow so you can review the exceptions. Once you sign off I’ll execute the changes, attach the Slack approval thread, and upload the final package to the Vanta folder with the naming convention we used last quarter. Does that timeline work, or do you need the raw exports sooner?

Client: That works. Just make sure the timestamps are visible and that we don’t have any shared logins still active.

You: Got it. I’ll specifically call out any shared or generic accounts in the exception column and recommend we rotate or eliminate them before the auditor samples. I’ll also add a short Loom walking through the two or three riskiest findings so you can brief the rest of the team without digging into the sheet. I’ll ping you once the draft is up.

Este segundo diálogo muestra ownership, timeline claro, y anticipación de lo que el auditor va a odiar (shared logins, timestamps faltantes). Eso es lo que separa a un contractor que “ayuda” de uno que el cliente quiere renovar.

¿Qué errores te descartan en una auditoría o en el onboarding de un cliente con SOC 2?

Los errores más costosos no son técnicos; son de higiene documental y de criterio. La tabla siguiente resume las situaciones que veo repetirse, la percepción que generan y el enfoque que sí funciona.

Cualquiera de las columnas de “error común” es suficiente para que un cliente con SOC 2 Type II decida no renovar o, peor, te saque del perímetro de sistemas sensibles y te deje solo con tareas de bajo valor.

¿Qué revisan realmente en el background check y en los controles de cambios cuando entras como independent contractor?

El background check (casi siempre vía Checkr o HireRight) confirma identidad, historial criminal básico y, en algunos casos, educación o employment. No sustituye los controles SOC 2; solo es el primer gate de onboarding. Una vez dentro, lo que sostiene tu acceso es la combinación de:

1. Contrato de independent contractor + W-8BEN correctamente cargado en Deel u otra plataforma.
2. Provisioning con least privilege (solo los sistemas y roles que necesitas).
3. Inclusión en el ciclo de access review desde el primer trimestre.
4. Obligación contractual de seguir la change management policy del cliente.

Cuando el cliente te da acceso a Stripe, a la consola de Google Admin o a los settings de HubSpot, automáticamente quedas dentro del alcance de los controles de cambios y de los logs. Por eso es inteligente, desde el día uno, preguntar: “¿Dónde registramos los change requests y quién es el approver para este sistema?” Esa sola pregunta te posiciona como alguien que ya entiende el juego.

En la práctica, muchos asistentes operativos terminan siendo los que “corren” el access review porque el security owner está saturado y confía en que tú eres ordenado. Si lo haces bien dos ciclos seguidos, tu tarifa sube y tu contrato se vuelve sticky. Si lo haces mal una vez, el cliente prefiere contratar a alguien más caro pero con experiencia demostrable en entornos auditados.

¿Cómo estructurar tu documentación diaria para que sea audit-ready sin volverte loco?

No necesitas un sistema perfecto el primer mes. Necesitas un ritmo mínimo que produzca evidencia sin fricción. Este checklist operativo es el que recomiendo a todo contractor que toca sistemas dentro de alcance SOC 2. Cópialo, ajústalo a las herramientas de tu cliente y córrelo.

CHECKLIST OPERATIVO SOC 2 – ASISTENTE OPERATIVO
(Frecuencia y owners pueden variar; esto es el mínimo viable)

DIARIO / POR EVENTO
[ ] Todo cambio en HubSpot, Salesforce, Stripe, QuickBooks, Xero o Google Admin queda registrado el mismo día en el Change Log (Notion/DB).
    Campos mínimos: Date | System | Description | Requested by | Approved by | Executed by | Test evidence (Loom/link) | Status
[ ] Cualquier alta o baja de usuario se refleja el mismo día en el roster maestro y se confirma revocación en todos los sistemas listados.
[ ] No se usan shared logins. Si aparece uno, se documenta como excepción y se agenda su eliminación.

SEMANAL
[ ] Revisar canal de Compliance / Security en Slack por requests abiertos de evidencia.
[ ] Confirmar que los exports automáticos (si existen) cayeron en la carpeta correcta.
[ ] Cerrar tickets de change que hayan quedado en “pending test”.

MENSUAL
[ ] Snapshot de usuarios activos de los 3–5 sistemas críticos (export CSV + fecha).
[ ] Verificar que no haya cuentas de contractors terminados con acceso residual.
[ ] Actualizar la página de “Systems in scope” si se agregó o retiró alguna herramienta.

TRIMESTRAL (o según política del cliente)
[ ] Access Review formal:
    - Export de usuarios por sistema
    - Cruce contra roster Deel + empleados
    - Lista de excepciones con owner y deadline
    - Ejecución de removes/downgrades
    - Paquete final (sheet + approvals + timestamp) subido al repositorio de evidencia
[ ] Revisión de change log del trimestre: todos los items en “closed” o con excepción aprobada.
[ ] Confirmación de que los audit logs nativos siguen habilitados y con retención adecuada (no los configuras tú, pero sí verificas que no se apagaron).

ONBOARDING DE UN NUEVO SISTEMA
[ ] Confirmar si entra en alcance SOC 2.
[ ] Definir quién aprueba changes.
[ ] Crear la plantilla de export de users y de logs.
[ ] Agregar al checklist de offboarding.

OFFBOARDING (mismo día del end date en Deel)
[ ] Google / Microsoft account suspended then deleted per policy
[ ] Slack deactivated
[ ] HubSpot / Salesforce access removed
[ ] Stripe / QuickBooks / Xero access removed
[ ] Any admin or API keys rotated or revoked
[ ] Confirmation comment left in the offboarding ticket with timestamps

Guarda este checklist en el Notion del cliente, no solo en tu drive personal. La evidencia tiene que vivir donde el auditor y el compliance owner puedan llegar sin pedirte un favor.

Si llegaste hasta aquí, ya tienes el mapa concreto de lo que un asistente operativo debe documentar para no convertirse en el eslabón débil de un SOC 2. La diferencia entre quien cobra en el rango bajo y quien negocia la parte alta del mercado no es “saber de compliance” en abstracto; es poder mostrar, en una llamada de 20 minutos, que ya produjo access reviews, que sabe dónde viven los logs y que deja change records que un auditor puede re-performar sin drama.

Para ver qué roles de operaciones, compliance ops o executive assistance encajan hoy con tu experiencia y qué rangos de tarifa en dólares son realistas para tu perfil, puedes hacer el diagnóstico gratuito de 2 minutos en el portal: /diagnostico/. El resultado te muestra caminos concretos, no promesas genéricas, y te deja listo para entrar a las conversaciones sabiendo exactamente qué evidencia te van a pedir.