> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Carpeta de evidencias de cumplimiento

> Genera un paquete de evidencias con un solo clic para SOC 2, ISO 27001, GDPR o HIPAA: una carpeta firmada y lista para descargar que tu auditor o el equipo de compras de un cliente puede leer directamente.

# Carpeta de evidencias de cumplimiento

La carpeta de evidencias convierte los datos de cumplimiento que tu workspace ya produce (registros de auditoría, revisiones de acceso, registros de consentimiento, configuración de retención, conteos de brechas) en un único paquete de evidencias mapeado a un marco público, con una descarga lista para entregar a un auditor o a la revisión de seguridad de un cliente.

Elige un marco, genera, descarga. Se admiten cuatro marcos:

| Marco                                     | Solicitud típica                                                                                   |
| ----------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **SOC 2** (AICPA Trust Services Criteria) | Cuestionarios de seguridad de proveedores y revisiones de preparación para SOC 2                   |
| **ISO 27001**                             | Evidencia de controles del Anexo A para certificación o atestaciones contractuales                 |
| **GDPR**                                  | Historial de solicitudes de interesados, conteos de brechas, consentimiento y postura de retención |
| **HIPAA**                                 | Registro de accesos a PHI, postura de BAA, retención configurada                                   |

Cada generación queda registrada en tu registro de auditoría, solo los roles de propietario o administrador del workspace pueden generarla, y la descarga es un enlace firmado que caduca a las 24 horas.

## Generar una carpeta desde el panel

1. Abre **Settings → Compliance → Binder**.
2. Elige el marco y el formato de salida: un **PDF** renderizado para lectura humana, o un **ZIP** de archivos por control para importar a una herramienta GRC.
3. Selecciona **Generate**. La generación se ejecuta en segundo plano; la página muestra el trabajo pasando de *Pending* → *Generating* → *Completed*.
4. Cuando finalice, usa el enlace **Download** de la fila del trabajo. El enlace es válido durante 24 horas; si caduca, genera de nuevo o abre el trabajo para ver un enlace nuevo.

Si ya hay una solicitud en curso para el mismo marco, el panel muestra ese trabajo de nuevo en lugar de encolar un duplicado: los clics repetidos son seguros.

Si la verificación de integridad de auditoría de la plataforma señaló algo al construir el paquete, la carpeta se abre con un **aviso de alerta de alteración** en la parte superior. Trata una carpeta marcada como alterada como una señal para investigar antes de entregarla a cualquier tercero.

## Generar desde la API

```bash theme={null}
curl -X POST https://api.orbit.devotel.com/api/v1/compliance/binder/generate \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{"orgId": "org_...", "framework": "soc2", "format": "pdf"}'
```

La respuesta es `202` con un id de trabajo:

```json theme={null}
{
  "data": { "jobId": "binder_...", "status": "pending", "dedup": false }
}
```

Consulta el trabajo hasta que finalice:

```bash theme={null}
curl https://api.orbit.devotel.com/api/v1/compliance/binder/binder_... \
  -H "X-API-Key: dv_live_sk_..."
```

Un trabajo completado incluye `download_url` (enlace firmado de 24 horas), `download_sha256` para la verificación del archivo, `download_size_bytes` y `tamper_alert`. Enumer las generaciones anteriores con `GET /api/v1/compliance/binder?page=1`. El catálogo de marcos (nombres, texto de alcance, conteos de controles) está en `GET /api/v1/compliance/binder/frameworks`.

| Endpoint                                   | Propósito                                 |
| ------------------------------------------ | ----------------------------------------- |
| `GET /api/v1/compliance/binder/frameworks` | Catálogo de marcos para el selector       |
| `POST /api/v1/compliance/binder/generate`  | Encolar una generación (`202`)            |
| `GET /api/v1/compliance/binder/:jobId`     | Estado, URL de descarga firmada, checksum |
| `GET /api/v1/compliance/binder?page=`      | Historial de generaciones                 |

## SOC 2 — cobertura de los Trust Services Criteria

El paquete de SOC 2 recorre los Common Criteria de AICPA **CC1.0 a CC9.0**, una sección por categoría. Cada sección empareja la narrativa de política de la plataforma con filas de evidencia contadas a partir de la propia cadena de auditoría de tu workspace:

| Control   | Categoría                            | Filas de evidencia de ejemplo                                                                              |
| --------- | ------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| **CC1.0** | Control Environment                  | Antigüedad del workspace en días; eventos de cambio de rol en los últimos 12 meses                         |
| **CC2.0** | Communication and Information        | Incidentes registrados, clasificados o resueltos en 12 meses                                               |
| **CC3.0** | Risk Assessment                      | Versión actual del registro de riesgos base                                                                |
| **CC4.0** | Monitoring Activities                | Eventos de autenticación en 90 días                                                                        |
| **CC5.0** | Control Activities                   | Despliegues en producción en 90 días                                                                       |
| **CC6.0** | Logical and Physical Access Controls | Fecha de la última revisión de acceso; revisiones de acceso completadas en 12 meses                        |
| **CC7.0** | System Operations                    | Última copia de seguridad verificada; la postura de retención de copias de 30 días; incidentes en 12 meses |
| **CC8.0** | Change Management                    | Ejecuciones de build en 90 días; la postura de bloqueo de migraciones                                      |
| **CC9.0** | Risk Mitigation                      | Postura de cifrado en reposo y en tránsito; la lista publicada de subprocesadores                          |

Si la verificación previa de integridad falló durante la generación, la alerta de alteración no es una nota a pie de página: se renderiza como un aviso con borde antes de CC1.0, de modo que lo primero que lee el auditor es que la reproducción de la cadena encontró problemas. Esa ubicación es deliberada: el lector debe ver la advertencia antes de cualquier fila de evidencia.

## ISO 27001 — correspondencia de controles del Anexo A

El paquete de ISO/IEC 27001:2022 cubre las cuatro categorías de controles del Anexo A más dos cláusulas numeradas individualmente que los equipos de compras preguntan con más frecuencia. Las filas se dividen en dos clases: **fijas de plataforma** (idénticas para cada workspace, que heredan la postura de la propia plataforma) y **derivadas del workspace** (contadas a partir de los datos de tu tenant en el momento de la generación):

| Correspondencia Anexo A | Sección                                         | Filas fijas de plataforma                                                                                           | Filas derivadas del workspace                                             |
| ----------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| **A.5**                 | Controles organizativos                         | Conjunto de políticas documentadas; cadencia anual de revisión del ISMS                                             | Referencia de tenant con hash                                             |
| **A.6**                 | Controles de personas                           | Verificación de antecedentes, concienciación en seguridad, SLA de desvinculación de 24 horas                        | —                                                                         |
| **A.7**                 | Controles físicos                               | Región de producción (Google Cloud europe-west1); atestación de alojamiento                                         | —                                                                         |
| **A.8**                 | Controles tecnológicos                          | Postura de cifrado (CMEK + TLS 1.2+); cadena de auditoría a prueba de alteraciones                                  | Conteo de claves de API activas; conteo agregado de registros de contacto |
| **A.5.19**              | Relaciones con proveedores                      | URL de la lista de subprocesadores; periodo de aviso de cambios de 30 días                                          | —                                                                         |
| **A.5.30**              | Preparación TIC para la continuidad del negocio | Cadencia diaria de copias de seguridad; pruebas trimestrales de restauración; referencia al runbook de recuperación | —                                                                         |

Los controles de personas y físicos no tienen filas derivadas del workspace porque el tenant no los opera: la carpeta declara la postura de la plataforma y lo dice claramente, en lugar de insinuar un rastro de evidencia que no puede producir.

## GDPR — evidencia artículo por artículo

El paquete de GDPR mapea los artículos que una autoridad de supervisión, un DPO o el equipo de privacidad de un cliente consulta. Los conteos que reúne provienen de las mismas superficies que gestionas a diario:

| Artículo    | Asunto                                          | Filas de evidencia que reúne la carpeta                                                                                  | Superficie del día a día                                                 |
| ----------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------ |
| **Art. 6**  | Base jurídica del tratamiento                   | Bases jurídicas admitidas en tus registros de consentimiento                                                             | [Gestión del consentimiento](/compliance/consent-management)             |
| **Art. 15** | Derecho de acceso (DSAR)                        | Totales de DSAR por estado; tiempo mediano de resolución frente al límite legal de 30 días                               | [DSAR](/compliance/dsar)                                                 |
| **Art. 17** | Derecho de supresión                            | Solicitudes de supresión por estado (ejecutadas, pendientes/en ejecución, canceladas); la ventana de reflexión de 7 días | [DSAR](/compliance/dsar)                                                 |
| **Art. 28** | Subprocesadores                                 | Lista publicada de subprocesadores; el periodo de aviso de cambios de 30 días                                            | [Acuerdo de tratamiento de datos](/compliance/data-processing-agreement) |
| **Art. 30** | Registro de actividades de tratamiento          | Categorías de interesados y datos personales; la retención de mensajes por defecto de 365 días                           | [Registro de privacidad (ROPA + DPIA)](/compliance/privacy-register)     |
| **Art. 32** | Seguridad del tratamiento                       | Postura de cifrado; seudonimización de los sujetos de la cadena de auditoría; ejercicios trimestrales de DR              | [Legal](/legal/index)                                                    |
| **Art. 33** | Notificación de brechas                         | Eventos de brecha notificables en 12 meses; el SLA de notificación de 72 horas                                           | [Registro de incidentes de brecha](/compliance/breach-incident-register) |
| **Art. 35** | Evaluación de impacto en la protección de datos | Contacto del DPO; disponibilidad de la plantilla DPIA                                                                    | [Registro de privacidad (ROPA + DPIA)](/compliance/privacy-register)     |

La postura de consentimiento entra en el Art. 6 como agregado (qué bases jurídicas aparecen en tus [registros de consentimiento](/compliance/consent-management)), nunca como filas individuales de concesiones, porque la carpeta se envía a partes que no deben recibir identificadores de tus contactos. El historial de DSAR y los conteos de supresión se acumulan en la [cola DSAR](/compliance/dsar) por estado; el [registro de privacidad](/compliance/privacy-register) posee las categorías del Art. 30 y la postura de DPIA del Art. 35 que los Arts. 30 y 35 reafirman como filas de evidencia.

## HIPAA — salvaguardas y postura de BAA

El paquete de HIPAA recorre las salvaguardas de la Security Rule (45 CFR §§ 164.302–318) más la Breach Notification Rule, y lee la configuración de HIPAA de tu workspace de los mismos ajustes que describe la referencia de [controles HIPAA](/compliance/hipaa):

| Sección                 | Salvaguarda                      | Filas de evidencia                                                                                                                                                    |
| ----------------------- | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **§ 164.308**           | Salvaguardas administrativas     | Modo HIPAA activado/desactivado; fecha de ejecución del BAA; contacto del Security Officer                                                                            |
| **§ 164.310**           | Salvaguardas físicas             | Región de producción; postura de seguridad de estaciones de trabajo                                                                                                   |
| **§ 164.312**           | Salvaguardas técnicas            | Eventos de acceso a PHI en 90 días; postura de cifrado; declaración de integridad de la cadena de auditoría                                                           |
| **§ 164.314**           | Requisitos organizativos (BAA)   | Si hay un BAA del tenant en el archivo; eventos relacionados con BAA en 12 meses                                                                                      |
| **§ 164.316**           | Documentación                    | Tu ventana de retención de PHI configurada (o el valor por defecto de plataforma de 365 días si no se configura); la postura de registro de auditoría de solo anexión |
| **Breach Notification** | Regla de notificación de brechas | Eventos de brecha de PHI en 12 meses; el SLA de notificación de 60 días                                                                                               |

La fecha del BAA y la ventana de retención que ves en la carpeta son los valores fijados en **Settings → Compliance → HIPAA**. Actualízalos antes de generar: la [guía de incorporación HIPAA](/guides/hipaa-onboarding) ordena la ejecución del BAA, la habilitación del modo HIPAA, la restricción de roles y la retención en el orden que el paquete espera.

## Lectura del paquete

Toda carpeta, independientemente del marco, consta de las mismas tres capas:

1. **Narrativa estática por control**: la política de la plataforma para ese control, enunciada una vez. Este texto es idéntico entre workspaces a propósito: describe el comportamiento de la plataforma, y solo un cambio en el comportamiento de la plataforma (no una regeneración sobre datos sin cambios) lo edita.
2. **Filas de evidencia del tenant por control**: conteos agregados y postura que difieren por workspace: volumen de registro de auditoría, distribución de roles del equipo, conteos de estado de DSAR y supresión, conteos de claves de API activas, incidentes de brecha, retención configurada. Un control sin nada aplicable hoy muestra "No tenant-specific evidence recorded for this control" en lugar de una tabla vacía.
3. **Resumen de integridad en la cabecera**: cuántas filas de la cadena de auditoría se reprodujeron y verificaron durante la construcción del paquete. Una ruptura de la cadena no bloquea la generación; pone la carpeta en el aviso de alerta de alteración para que el lector lo sepa desde el principio.

La evidencia está redactada por construcción: solo conteos agregados y referencias con hash, nunca números de teléfono, direcciones de correo electrónico, nombres de clientes, cuerpos de mensajes, claves de API ni secretos de webhook. Una carpeta es segura para reenviar al equipo de compras de un cliente.

Dos generaciones sobre los mismos datos producen salida idéntica byte a byte, y los paquetes completados llevan un checksum SHA-256, de modo que un auditor puede verificar que el archivo recibido es el que generaste, y una regeneración meses después es comparable línea por línea.

## Runbook operativo

**Importar a una herramienta GRC.** Genera con `format: "zip"`. El ZIP contiene un `00_README.md` (el resumen de integridad y los metadatos de generación) más un archivo Markdown por control: `01_CC1_0.md`, `02_CC2_0.md`, … (SOC 2), `01_A_5.md`, … (ISO 27001), los ids de artículo para GDPR y los ids de sección para HIPAA. Cada archivo lleva la narrativa del control y una tabla `| Evidence | Value |`, que es el formato que las plataformas de cumplimiento (importadores de clase SecureFrame, clase Drata) analizan al subir una carpeta.

**Comparar dos generaciones.** Como la salida es determinista, comparar dos ZIP aísla exactamente lo que cambió: una lista de archivos idéntica con checksums idénticos significa "sin cambios relevantes para el cumplimiento"; un archivo de control modificado reduce la diferencia a un control; un `00_README.md` distinto con archivos de control idénticos significa que solo se movió el conteo de filas de la cadena de auditoría. Regenera con una cadencia fija y guarda cada SHA-256 de la respuesta de estado del trabajo para que la comparación sea una igualdad de checksums, no una lectura manual.

**Manejar una marca de alteración.** Abre la carpeta marcada y anota el conteo de problemas del aviso. Comprueba si una generación posterior despeja la marca: la alerta cubre una ventana de repetición de 12 meses, así que un problema resuelto se despeja cuando queda fuera de ella. Si la marca persiste, mantén la carpeta internamente y contacta con [security@devotel.io](mailto:security@devotel.io) antes de remitirla a un auditor; el archivo sigue siendo evidencia de tu propia línea temporal, pero nunca debería entregarse sin discutir primero la advertencia.

## Ejemplo práctico — cuestionario de proveedor SOC 2

El portal de compras de un cliente lista una pregunta por categoría de los Trust Services Criteria y acepta un adjunto opcional. La carpeta responde al hueco de adjunto que el cuestionario deja abierto:

1. **Settings → Compliance → Binder**, elige **SOC 2**, formato **PDF**, selecciona **Generate**.
2. Espera a *Completed* y descarga el paquete.
3. Lee primero el resumen de integridad de la cabecera. Si el aviso está presente, resuélvelo (runbook anterior) antes de continuar.
4. Asigna las categorías del cuestionario a secciones de la carpeta una a una: "Gobernanza" → CC1.0, "Personas" → CC2.0/CC6.0, "Gestión de cambios" → CC8.0, y así por CC1.0–CC9.0.
5. Adjunta el PDF. Donde una pregunta exige un número ("¿cuándo fue tu última revisión de acceso?"), la respuesta es la fila de evidencia, citada literalmente (`Last access review: 2026-07-31T…`).
6. Guarda el `download_sha256` del trabajo en el campo de notas del cuestionario. El cliente puede volver a calcular el hash del adjunto y confirmar que el documento recibido es el que generaste.

## Ejemplo práctico — paquete de respuesta ante una autoridad GDPR

Una autoridad de supervisión solicita documentación de las actividades de tratamiento, la gestión de solicitudes de interesados y la postura de brechas en una sola respuesta:

1. Trae las superficies de origen al día: los estados de la [cola DSAR](/compliance/dsar), las entradas del [registro de privacidad](/compliance/privacy-register) y el [registro de incidentes de brecha](/compliance/breach-incident-register).
2. Genera **GDPR** como **ZIP**: la ingesta de gestión de casos de la autoridad suele analizar mejor archivos por artículo que un único PDF.
3. El capítulo del Art. 30 responde "qué procesas"; los capítulos del Art. 15 y del Art. 17 responden "cómo gestionas las solicitudes" con medianas de resolución frente a los 30 días legales; el capítulo del Art. 33 responde "cómo lo sabrías y lo notificarías" con el conteo de brechas de 12 meses y el SLA de 72 horas.
4. Cita el conteo del Art. 33 con su ventana ("brechas notificables en los últimos 12 meses"): la carpeta reporta conteos móviles, no totales históricos.
5. Adjunta el ZIP y guarda el SHA-256 con tu expediente. Si la autoridad vuelve para un seguimiento, regenera después de que la ventana se mueva y compara los dos ZIP (runbook anterior) para enumerar exactamente lo que cambió.

## Límites

* **La URL firmada caduca a las 24 horas.** El enlace de descarga de la fila del trabajo deja de funcionar tras un día; abre el trabajo para un enlace nuevo o regenera, el historial mantiene el registro del trabajo de cualquier modo.
* **Se requiere rol de propietario o administrador.** La generación (y la lectura del estado del trabajo) está restringida a propietarios y administradores del workspace, también mediante claves de API; los superadministradores de Devotel también pueden generar contra un workspace, por ejemplo ante una solicitud de soporte.
* **Toda acción queda registrada en auditoría.** El encolado escribe una entrada `compliance.binder_generated` en tu registro de auditoría con el marco, formato y rol solicitante; la finalización escribe una segunda entrada. Las generaciones fallidas quedan en el historial con el mensaje de error.
* **Las ventanas son móviles.** Los conteos de evidencia cubren ventanas móviles (90 días o 12 meses, según el control), no totales históricos; dos carpetas generadas con semanas de diferencia difieren legítimamente.
* **La redacción no puede levantarse.** La carpeta nunca contiene PII ni secretos; si un auditor necesita datos por sujeto detrás de un agregado, dirígelo a la superficie subyacente ([DSAR](/compliance/dsar), [registro de auditoría](/guides/audit-log)) en lugar de la carpeta.

## Auditoría y control de acceso

* La generación requiere el rol de **propietario** o **administrador** del workspace; las claves de API siguen el mismo filtro de rol.
* Cada generación escribe una entrada `compliance.binder_generated` en tu registro de auditoría con el marco, formato y rol solicitante; la finalización escribe una segunda entrada.
* Las generaciones fallidas quedan en el historial con un mensaje de error en lugar de desaparecer en silencio.

## Relacionados

* [DSAR](/compliance/dsar) — la cola de la que se cuentan las filas de GDPR Art. 15 y Art. 17
* [Registro de privacidad (ROPA + DPIA)](/compliance/privacy-register) — origen de las categorías del Art. 30 y la postura del Art. 35
* [Controles HIPAA](/compliance/hipaa) e [incorporación HIPAA](/guides/hipaa-onboarding) — la configuración que el paquete de HIPAA lee en su respuesta
* [Mercado de plugins de cumplimiento](/compliance/plugin-marketplace) — explora paquetes de evidencia y bundles de activación en un solo lugar
* [Legal](/legal/index)