Un informe SOC 2 Tipo II comprueba si los controles operaron durante todo un periodo. Las aprobaciones de cambios suelen ser donde los equipos de ingeniería dedican más tiempo a la auditoría, reuniendo tickets y capturas de pantalla de una muestra de cambios.
Hoy el blueprint de SOC 2 aporta evidencia de código para siete criterios en cada pull request. Desde v1.4.0, cada pull request fusionado se sella como un registro de cambio con sus aprobaciones, checks y firmas: evidencia para CC8.1. El mapa completo está más abajo, incluidos los 45 criterios que quedan en manos de su organización.
Toevan aporta evidencia para controles; nunca los certifica ni afirma que un marco esté cubierto. Si la evidencia es suficiente lo juzga su auditor.
Los controles se muestran por id con los nombres cortos propios de Toevan. Los títulos oficiales y el texto de los requisitos pertenecen al editor del marco.
Activo7
Evidencia de código hoy, sellada en cada pull request. Siempre parcial: el control también exige cosas fuera del código. Evidencia de código hoy: las reglas del blueprint SOC 2 comprueban parte de esto en cada pull request.
CC6.1Diseño de límites de acceso
CC6 Protección del acceso
CC6.3Cambios de permisos por rol
CC6 Protección del acceso
CC6.6Defensa frente a amenazas externas
CC6 Protección del acceso
CC6.7Límites al movimiento de datos
CC6 Protección del acceso
CC7.2Vigilancia de anomalías
CC7 Operaciones de seguridad
C1.1Marcado de datos confidenciales
C1 Datos confidenciales
C1.2Eliminación de datos confidenciales
C1 Datos confidenciales
Próximamente en v1.4.01
Evidencia de proceso: pull requests fusionados, aprobaciones, checks obligatorios, protección de ramas, rulesets y bypasses, sellada por cada cambio.
CC8.1Aprobaciones de cambios
CC8 Gestión de cambios
Evidencia de proceso: cada pull request fusionado se sella como un registro de cambio con sus aprobaciones sobre el commit final, los checks obligatorios al fusionar, quién lo fusionó, sus firmas y los veredictos de código que llevaba.
De apoyo1
Toevan registra evidencia relacionada, hoy o en v1.4.0, pero la obligación es organizativa, así que nunca cuenta como cubierta.
CC7.4Pasos de respuesta a incidentes
CC7 Operaciones de seguridad
Evidencia de apoyo hoy: una regla registra evidencia relacionada con esta obligación. La obligación en sí es un proceso operativo.
Planificado7
Se puede evidenciar desde el código o GitHub. La regla o el mapeo aún no están construidos.
CC6.2Emisión de credenciales de usuario
CC6 Protección del acceso
CC7.1Vigilancia de desvíos de debilidades
CC7 Operaciones de seguridad
A1.2Salvaguardas de copias de seguridad
A1 Capacidad y copias de seguridad
PI1.2Entradas completas y exactas
PI1 Exactitud del tratamiento
PI1.3Errores de pérdida en el tratamiento
PI1 Exactitud del tratamiento
P4.2Conservación de datos personales
P4 Uso y conservación
P4.3Eliminación de datos personales
P4 Uso y conservación
Su organización45
Política, personas, seguridad física, contratos, trámites regulatorios, operaciones o auditoría externa. Su organización aporta la evidencia.
Mostrar los 45 controles
CC1 Conducta de la dirección
CC1.1Compromiso de conductauna política de la organizaciónCC1.2Supervisión del consejouna política de la organizaciónCC1.3Líneas de reporteuna política de la organizaciónCC1.4Contratación de personal capazun asunto de personas y RR. HH.CC1.5Responsabilidad por deberesun asunto de personas y RR. HH.
CC2 Intercambio de información
CC2.1Buena información de controluna política de la organizaciónCC2.2Comunicación de deberes al personaluna política de la organizaciónCC2.3Diálogo con terceros externosuna política de la organización
CC3 Revisión de riesgos
CC3.1Objetivos de riesgouna política de la organizaciónCC3.2Ponderación de riesgosuna política de la organizaciónCC3.3Revisión del riesgo de fraudeuna política de la organizaciónCC3.4Revisión del impacto de cambiosuna política de la organización
CC4 Monitorización de controles
CC4.1Revisiones continuas de controlesun proceso operativoCC4.2Notificación de debilidadesun proceso operativo
CC5 Selección de controles
CC5.1Controles que reducen el riesgouna política de la organizaciónCC5.2Elección de controles tecnológicosuna política de la organizaciónCC5.3Políticas implantadasuna política de la organización
CC6 Protección del acceso
CC6.4Límites de entrada físicaseguridad físicaCC6.5Eliminación de datos de activosseguridad físicaCC6.8Bloqueo de software no deseadoun proceso operativo
CC7 Operaciones de seguridad
CC7.3Valoración de eventosun proceso operativoCC7.5Aprendizaje tras la recuperaciónun proceso operativo
CC9 Riesgo de proveedores
CC9.1Reducción del riesgo de interrupcionesuna política de la organizaciónCC9.2Gestión del riesgo de proveedorescontratos y proveedores
A1 Capacidad y copias de seguridad
A1.1Vigilancia de capacidadun proceso operativoA1.3Pruebas de recuperaciónun proceso operativo
PI1 Exactitud del tratamiento
PI1.1Objetivos de tratamiento definidosun proceso operativoPI1.4Revisión de la entrega de salidasun proceso operativoPI1.5Integridad de elementos almacenadosun proceso operativo
P1 Deberes de aviso
P1.1Aviso de privacidaduna política de la organización
P2 Deberes de elección
P2.1Opciones de consentimientouna política de la organización
P3 Deberes de recogida
P3.1Recogida lícitauna política de la organizaciónP3.2Consentimiento explícito sensibleuna política de la organización
P4 Uso y conservación
P4.1Límites de finalidad declaradauna política de la organización
P5 Solicitudes individuales
P5.1Respuestas a solicitudes de accesoun proceso operativoP5.2Gestión de correccionesun proceso operativo
P6 Deberes de comunicación
P6.1Consentimiento antes de compartiruna política de la organizaciónP6.2Registros de comunicaciónuna política de la organizaciónP6.3Registros de comunicación no autorizadauna política de la organizaciónP6.4Compromisos de privacidad de proveedorescontratos y proveedoresP6.5Aviso de incidentes de proveedorescontratos y proveedoresP6.6Avisos de brechasun trámite regulatorioP6.7Contabilidad de comunicacionesun proceso operativo
P7 Calidad de los datos
P7.1Datos personales exactosun proceso operativo
P8 Gestión de reclamaciones
P8.1Gestión de reclamacionesun proceso operativo
Cómo usarlo en una auditoría
Tome la población de los registros de cambio (desde v1.4.0)
Cada fusión en una rama protegida y cada push directo del periodo, capturados de GitHub en el momento, es un registro sellado que puede exportar para el muestreo. Puede repetir la población de la rama por defecto a partir del historial de git; las ramas de producción designadas están planificadas para v1.4.1.
Lea la evidencia de código del periodo
Cada pull request lleva resultados de código sellados frente a las reglas del blueprint, fijados al commit y a la versión del conjunto de reglas vigente.
Pruebe una muestra
Para cada registro muestreado, compruebe sus resultados y luego verifique su firma y su lugar en la cadena sin conexión.
toevan audit verify --path evidence-clone --pub-key toevan.pub
Cómo se obtuvo cada dato
Cada dato de un registro y de un informe lleva una de seis etiquetas, para que su auditor sepa hasta qué punto puede fiarse.
- Recalculado
- Toevan lo calculó a partir del propio código o del historial de git.
- Repítalo con las mismas entradas y obtenga el mismo resultado.
- Informado + sellado
- GitHub lo informó; Toevan lo capturó en el evento y lo firmó.
- Fíese de ello tanto como se fía de GitHub. Cualquier cambio posterior es detectable.
- Declarado + sellado
- La organización lo declaró, como un cambio en lo que se comprueba; Toevan firmó la declaración y su historial.
- Vea quién declaró qué, cuándo, y cada cambio posterior.
- Registro de Toevan, sin sellar
- Guardado en la base de datos de Toevan pero no sellado en el libro, como una exención hoy. Ninguna firma lo protege.
- Trátelo como una declaración de Toevan y pida a la organización la aprobación que hay detrás.
- Consumido
- Tomado del registro firmado de otro sistema, como la procedencia de una compilación, y enlazado por commit o digest. Planificado.
- Compruebe el registro original de forma independiente.
- No capturado
- No había una fuente fiable. Toevan no lo infiere.
- Obténgalo de la organización por otros medios.
Véalo en un informe
El informe de muestra de evidencia de cambios muestra la evidencia tal como la recibe su auditor, con cada dato rotulado.
Abrir el informe de muestraPonga a prueba el mapeo en una auditoría real.
Traiga un repositorio y una auditoría próxima. Configuraremos el blueprint y guiaremos a su auditor por la verificación.