Listas de comprobación de pruebas

Por qué importa

La mayoría de los controles de dispositivos se responden solos. Tu MDM informa del cifrado de disco, tu proveedor de identidad da cuenta de la MFA y la plataforma de cumplimiento recoge ambos datos de forma periódica. Hasta que el auditor pregunta por los cuatro contratistas, el diseñador con un portátil personal y el asesor que nunca ha estado dentro del alcance del agente — y la automatización no tiene nada que decir.

Esa brecha suele cerrarse con una hoja de cálculo y una carpeta de capturas de pantalla en el almacenamiento compartido. Funciona hasta que alguien pregunta quién confirmó un control concreto, cuándo se hizo la captura y si seguía en vigor durante la ventana de auditoría. Para entonces, la respuesta está enterrada en un hilo de chat.

Una lista de comprobación de pruebas es un programa de formación cuyo contenido es un conjunto de ajustes del dispositivo en lugar de diapositivas. El participante recibe instrucciones paso a paso para su propio sistema operativo, cambia el ajuste, sube la prueba y firma la misma declaración con redacción legal que usa el resto de tu formación. Lo que sale al otro lado es un registro de finalización que un auditor acepta.

Listas de comprobación frente a cursos

Ambos son programas de formación y ambos terminan en una declaración firmada. La diferencia está en lo que hay en medio.

	Curso	Lista de comprobación
Contenido	Diapositivas y después una comprobación de conocimientos	Puntos de control, cada uno con instrucciones por plataforma
Demuestra	Que la persona entendió el material	Que su máquina está configurada de una forma concreta
Finalización	Todas las diapositivas vistas, cuestionario superado, declaración firmada	Todos los puntos de control confirmados, declaración firmada
Prueba	El registro de finalización	El registro de finalización más las capturas de pantalla subidas

Un programa es una cosa o la otra, según la plantilla desde la que lo generes. Todo lo demás — invitaciones, fechas límite, recordatorios, el registro de finalización, la exportación a Vanta — funciona exactamente igual en ambos.

Las dos plantillas de lista de comprobación

Endpoint Hardening (bastionado del dispositivo)

Los siete ajustes del dispositivo que un auditor pide demostrar a un contratista:

Punto de control	Prueba
Cifrado de disco completo — FileVault, BitLocker o LUKS	Captura de pantalla
Bloqueo de pantalla con contraseña al salir del reposo	Captura de pantalla
Actualizaciones automáticas del sistema operativo activadas	Captura de pantalla
Protección contra malware en funcionamiento	Captura de pantalla
Gestor de contraseñas en uso	Captura de pantalla
Cortafuegos activado	Captura de pantalla
La contraseña del dispositivo cumple la política	Solo declaración

La contraseña del dispositivo es de solo declaración a propósito: ningún panel de ajustes muestra la longitud de tu contraseña, así que una captura de pantalla no demostraría nada.

La protección contra malware es el único punto de control que no pretende equivalencia entre plataformas. En Linux la instrucción dice sin rodeos que un escritorio sin análisis en tiempo real es una respuesta normal, y pide capturar los controles que hacen de sustituto — el parcheado automático y un cortafuegos de host que rechaza por defecto el tráfico entrante — y dejarlo dicho en la nota. Una equivalencia fingida empeoraría la prueba, no la mejoraría.

Dos valores se piden como preguntas de la plantilla en lugar de venir fijados, porque las tres grandes plataformas de cumplimiento no se ponen de acuerdo y la que manda es tu propia política:

• Tiempo de bloqueo de pantalla, 15 minutos por defecto. Vanta acepta hasta 60, Drata quiere contraseña 60 segundos después de un bloqueo de 15 minutos y Secureframe comprueba que sean 900 segundos o menos.
• Longitud mínima de la contraseña, 8 por defecto.

Policy Acknowledgment (aceptación de políticas)

Las 22 políticas de SOC 2 como puntos de control de solo declaración, agrupadas para que se lean en bloques coherentes y no como una lista plana: conducta, seguridad de la información, datos, resiliencia y gobernanza. Cada una enlaza a donde vivan tus políticas, y la declaración firmada enumera cada política por su nombre — una firma genérica de «he leído las políticas» no sobrevive a la pregunta de cuáles.

Crear una lista de comprobación

1. Genérala. Desde el panel de Formación, haz clic en Crear desde plantilla y elige Endpoint Hardening o Policy Acknowledgment. Responde las preguntas de la plantilla guiada: el nombre de tu empresa, tu gestor de contraseñas, tu tiempo de bloqueo de pantalla.
2. Revisa los puntos de control. Cada uno tiene un título, una nota de «por qué importa» que lee el participante, las reglas de la prueba e instrucciones por sistema operativo. Edita los que quieras, añade los tuyos o cambia el orden.
3. Añade instrucciones para las plataformas que necesites. Las plantillas incluidas cubren macOS, Windows 11 y Linux. Los pasos de Linux están escritos de otra forma a propósito: en vez de una ruta de clics por un escritorio que no conocemos, nombran el control y dan una orden independiente de la distribución cuya salida es la captura — lsblk mostrando el dispositivo crypt de LUKS, systemctl list-timers mostrando el temporizador de actualizaciones, ufw status verbose mostrando el rechazo por defecto. De todos modos, una captura de terminal es mejor prueba que un panel de ajustes. Un participante en una plataforma sin instrucciones propias sigue viendo las de la primera plataforma redactada en lugar de una tarjeta en blanco, y la página le dice sin rodeos de qué plataforma son los pasos que está leyendo.
4. Publica e invita. Idéntico a un curso. Una lista de comprobación no se publica sin al menos un punto de control y una declaración.

Lo que ve el participante

Una sola página, una tarjeta abierta cada vez. Kit deduce el sistema operativo a partir del navegador y muestra las instrucciones correspondientes; el participante puede cambiarlas, y la elección se recuerda.

Cada tarjeta lleva los pasos numerados, la razón por la que importa el control y las reglas de la prueba. El participante hace una captura de pantalla, la arrastra o la pega en la tarjeta, pone nombre al dispositivo y fecha la captura. Al confirmar, la tarjeta se pliega y se abre la siguiente.

La atribución de la captura se escribe, no se fotografía. En lugar de exigir que el nombre de la máquina aparezca en la captura, Kit pide el nombre del dispositivo y la fecha de captura como campos. Esos datos están cifrados, se pueden buscar y sobreviven cuando la propia imagen ya se ha eliminado.

Los textos de ayuda le indican que silencie las notificaciones antes de capturar y que envíe una captura del panel de ajustes en lugar de fotografiar la pantalla con el móvil. Ambas cosas encabezan las razones por las que un auditor rechaza una prueba.

Revisión de pruebas

Enviar la prueba completa el punto de control. La revisión es un triaje posterior, no una barrera de entrada: ningún contratista se queda esperando a que alguien mire su bandeja de entrada.

La cola muestra los envíos confirmados pero sin revisar con la atribución que hace auditable una captura: plataforma, nombre del dispositivo, fecha de captura y cuántos días antes de la confirmación se hizo. Una prueba con fecha atrasada se indica sin rodeos, porque eso es precisamente lo que busca un revisor.

Aceptar retira el elemento de la cola. Rechazar exige una nota, reabre el punto de control y envía un correo al participante con tu motivo. No revoca su registro de finalización: la formación sí la completó, y reescribir eso sería falsificar la historia, no pedir una captura mejor.

Reabrir un punto de control es acceso real, no solo un estado: la página de la lista de comprobación sigue accesible para quien ya ha terminado y muestra tu nota en la única tarjeta cuya captura hay que repetir. La nueva captura devuelve el punto de control a la cola de revisión como un envío nuevo. La prueba que se envió antes de tu revisión sigue adjunta y no se puede eliminar — es justo lo que un auditor pide ver — así que se muestra al lado de la que la sustituye, marcada como reemplazada.

Una prueba rechazada sí cambia el registro: esa persona deja de contar como completada y pasa a la etapa Prueba rechazada, ordenada por encima de todo lo demás. El recuento de personas que han terminado es lo que entregas a un auditor, así que excluye a cualquiera con pruebas pendientes.

Acceso y conservación

Solo los administradores de formación de la cuenta pueden ver las pruebas, y cada descarga queda registrada con quién abrió qué archivo y cuándo. Los archivos se sirven mediante enlaces efímeros que se generan en cada clic, no mediante URL incrustadas en la página, de modo que el acceso termina cuando termina el acceso de la persona.

Las pruebas se eliminan de forma programada. Cada programa tiene un plazo de conservación, 395 días por defecto: un año más el margen que necesita la ventana de una auditoría de Tipo II. Un barrido nocturno elimina los archivos en cuanto un envío lo supera. Puedes fijar un plazo distinto para cada programa con evidence_retention_days en training_create_program.

El registro de finalización sobrevive a la eliminación, igual que el nombre y el hash del contenido de cada archivo. Cuando las capturas ya no están, todavía puedes demostrar qué se envió, cuándo, quién lo envió y que no se sustituyó por otra cosa.

Exportación

La exportación CSV para Vanta gana columnas de pruebas en los programas de lista de comprobación: estado de revisión, puntos de control confirmados, puntos de control totales, número de archivos, nombre del dispositivo y la ventana de captura. Las exportaciones de cursos no cambian ni un byte: Vanta exige el orden y la redacción exactos de las columnas.

El registro en PDF añade una tabla aparte con las pruebas de los puntos de control debajo de la principal.

Una persona, un archivo

Las exportaciones del registro cubren a todo el mundo de golpe. Cuando un auditor pregunta por una sola persona, usa Paquete de pruebas en su fila. El ZIP se genera en segundo plano y la descarga empieza en cuanto está listo.

Dentro está todo lo registrado sobre esa persona, renombrado para que la carpeta se entienda sin que tú estés delante:

training-evidence-jane-doe-endpoint-hardening-20260114.zip
└── jane-doe-endpoint-hardening-20260114/
    ├── jane-doe-00-manifest.csv
    ├── jane-doe-01-certificate.pdf
    ├── jane-doe-checkpoint-01-full-disk-encryption-01.png
    ├── jane-doe-checkpoint-02-screen-lock-01.png
    └── jane-doe-checkpoint-02-screen-lock-02-superseded.png

El índice es lo que un auditor lee de verdad: una fila por archivo con la plataforma, el nombre del dispositivo, la fecha de captura, la de confirmación, el veredicto del revisor y su nota, además del nombre original del archivo y su huella. Una carpeta de capturas sin él no le dice nada a quien no estuvo allí.

Hay dos estados que se etiquetan en lugar de esconderse. Las pruebas enviadas antes del veredicto de un revisor se incluyen con -superseded en el nombre: omitirlas borra el rastro e incluirlas sin marcar da a entender que se aceptaron. Los archivos que la política de retención ya ha borrado aparecen como una nota .purged.txt justo donde habría estado la captura, con el nombre y la huella conservados; un paquete que los omitiera en silencio falsearía el expediente.

Quienes hacen un curso no tienen capturas, así que su paquete son el certificado y el índice, y el botón dice Paquete del certificado.

Los paquetes caducan a los siete días y cada descarga queda registrada: quién se llevó el archivo y cuándo, más una entrada por archivo en el mismo historial de pruebas que escribe una descarga individual. Así, «¿quién ha visto alguna vez las capturas de esta persona?» tiene una única respuesta completa.

Recordatorios

Las listas de comprobación usan el mismo goteo que los cursos: un empujón tras la invitación, un último aviso cuando se acerca la fecha límite, un recordatorio de firma para quien terminó el contenido pero nunca firmó, y un recordatorio de vencimiento limitado a tres envíos con una semana entre cada uno.