# Declaración de Aplicabilidad

**Norma de referencia:** ISO/IEC 27001:2022, Anexo A (93 controles)
**Organización:** Veritas Digital LLC
**Sistema en alcance:** Veritas UGC — plataforma de sellado y certificación de contenido
**Versión:** 1.0 · 5 de agosto de 2026
**Próxima revisión:** 5 de febrero de 2027

---

## Aviso de estatus — léase antes que nada

**Veritas Digital LLC no está certificada en ISO/IEC 27001 y este documento no es un
certificado.** Es una autoevaluación: la organización ha tomado el Anexo A de la norma como
marco de referencia, ha evaluado cada uno de sus 93 controles frente al sistema real y ha
declarado con honestidad cuáles están implementados, cuáles lo están parcialmente y cuáles no
aplican, con la justificación en cada caso.

Cualquier afirmación de este documento es verificable contra el código fuente, la configuración
desplegada o los registros del sistema. Donde no hay evidencia, se dice que no la hay.

**Por qué se publica igualmente.** Una certificación cuesta entre 15.000 y 50.000 USD el primer
año y acredita el sistema de gestión de la organización, no la calidad probatoria de los
certificados que emite. Para un servicio gratuito operado por una empresa pequeña, ese gasto no
mejora ni un ápice la posición del usuario ante un juzgado. Lo que sí la mejora es que los
controles existan de verdad y que cualquiera pueda comprobarlo. Eso es lo que hay aquí.

---

## Leyenda de estados

| Estado | Significado |
|---|---|
| **I** | Implementado y verificable |
| **P** | Parcialmente implementado — se indica qué falta |
| **N/A** | No aplicable — se justifica por qué |
| **Ø** | No implementado — se declara el riesgo aceptado |

---

## Contexto que determina la aplicabilidad

Veritas UGC es un servicio **sin empleados, sin oficina y sin infraestructura propia**. Lo opera
una sola persona sobre servidores virtuales alquilados. Esto no es una excusa para descartar
controles: es el contexto que hace que algunos sean genuinamente inaplicables (no hay proceso de
terminación de empleo si no hay empleados) y que otros sean **más** críticos, no menos (no hay
segregación de funciones posible, así que el registro inmutable de auditoría carga con todo el
peso).

Cuatro hechos del sistema condicionan casi todo lo que sigue:

1. **Los contenedores no tienen privilegios.** Los cuatro servicios de aplicación corren como
   usuario sin privilegios, con todas las capacidades del kernel retiradas, `no-new-privileges`
   activo y sistema de archivos raíz en solo lectura.
2. **La dirección IP real del cliente no llega a la aplicación.** El puerto 443 lo atiende un
   proxy TCP que no habla HTTP. Esto invalida toda defensa basada en IP y obliga a resolver
   la limitación de tasa por otra vía.
3. **La prueba no depende de Veritas.** El anclaje en Bitcoin y el sello RFC 3161 los emiten
   terceros. Aunque la organización desapareciera, los certificados seguirían siendo verificables.
4. **La infraestructura es rotatoria y redundante.** El servicio se despliega sobre varios
   servidores virtuales que rotan, lo que reduce la exposición de cualquier host individual.

---

## A.5 · Controles organizacionales (37)

| # | Control | Estado | Implementación y evidencia |
|---|---|---|---|
| 5.1 | Políticas de seguridad de la información | **I** | Manual de políticas aprobado por la dirección, publicado en `compliance/`. Revisión semestral fijada |
| 5.2 | Roles y responsabilidades | **I** | Un único responsable, declarado nominalmente. Se documenta que no hay segregación de funciones y cómo se compensa |
| 5.3 | Segregación de funciones | **Ø** | **Imposible con una sola persona.** Riesgo aceptado y compensado con registro de auditoría de solo-anexado y anclaje externo que la organización no puede reescribir |
| 5.4 | Responsabilidades de la dirección | **I** | La dirección es el operador. Aprobación documentada en el manual |
| 5.5 | Contacto con autoridades | **P** | Identificadas las autoridades relevantes (CRA, AEPD, DMCA). Falta registrar los canales formales |
| 5.6 | Contacto con grupos de interés especial | **P** | Seguimiento de OpenTimestamps, C2PA y avisos de seguridad de Node. Sin membresías formales |
| 5.7 | Inteligencia de amenazas | **I** | Módulo reproducible de inteligencia de amenazas con fuentes fechadas. Ver commit `f8438f6` |
| 5.8 | Seguridad en la gestión de proyectos | **I** | Cada cambio pasa por revisión de seguridad documentada antes del despliegue |
| 5.9 | Inventario de información y activos | **I** | Inventario en `ISMS-03-inventario-de-activos.md`: 6 contenedores, 6 volúmenes, 3 secretos, 23 tablas |
| 5.10 | Uso aceptable de la información | **I** | Términos de servicio y política de uso aceptable publicados en `/legal` |
| 5.11 | Devolución de activos | **N/A** | No hay empleados ni activos cedidos a terceros |
| 5.12 | Clasificación de la información | **I** | Cuatro niveles definidos: público, interno, confidencial y **material probatorio** (categoría propia, la más restrictiva) |
| 5.13 | Etiquetado de la información | **P** | Aplicado a las categorías del sistema. El etiquetado dentro de los documentos internos es informal |
| 5.14 | Transferencia de información | **I** | TLS 1.2+ obligatorio en tránsito. Transferencia a Drive cifrada con AES-256 antes de salir del servidor |
| 5.15 | Control de acceso | **I** | Autenticación por enlace mágico de un solo uso; roles de usuario y administrador; sin contraseñas almacenadas |
| 5.16 | Gestión de identidades | **I** | Identidad única por correo electrónico. Claves de agente con prefijo `vugc_`, hasheadas en reposo |
| 5.17 | Información de autenticación | **I** | No se almacena ninguna contraseña. Los enlaces mágicos caducan y son de un solo uso |
| 5.18 | Derechos de acceso | **I** | Concesión y revocación por consola de administración, con registro en `audit_logs` |
| 5.19 | Seguridad en relaciones con proveedores | **I** | Proveedores identificados y evaluados en `ISMS-04-proveedores.md` |
| 5.20 | Seguridad en acuerdos con proveedores | **P** | Se opera bajo los términos estándar de cada proveedor. Sin acuerdos negociados |
| 5.21 | Seguridad en la cadena de suministro de TIC | **I** | Cuarentena de dependencias, `ignore-scripts`, verificación con `osv-scanner`, SBOM publicado |
| 5.22 | Seguimiento de servicios de proveedores | **P** | Vigilancia del estado de calendarios OTS y de la TSA. Sin revisión formal periódica |
| 5.23 | Seguridad en servicios en la nube | **I** | Un único servicio en la nube externo (depósito en Drive), y cifrado de extremo a extremo antes del envío |
| 5.24 | Planificación de la gestión de incidentes | **I** | Procedimiento de respuesta con plazos del CRA: 24 h / 72 h / 14 días |
| 5.25 | Evaluación de eventos de seguridad | **I** | Criterios de gravedad definidos; `audit_logs` como fuente única |
| 5.26 | Respuesta a incidentes | **I** | Procedimiento documentado, con manuales por escenario |
| 5.27 | Aprendizaje de los incidentes | **I** | Cada incidente resuelto genera una entrada en el registro de lecciones. Cuatro entradas reales a fecha de hoy |
| 5.28 | Recolección de evidencias | **I** | **Es el negocio.** Cadena de custodia, hash, anclaje y registro de transparencia |
| 5.29 | Seguridad durante la disrupción | **I** | Plan de continuidad publicado, con compromiso de volcado final verificable |
| 5.30 | Preparación de las TIC para la continuidad | **I** | Copias verificadas por conteo, copia cifrada fuera del servidor, restauración probada |
| 5.31 | Requisitos legales y contractuales | **I** | Registro de obligaciones: RGPD, CRA, Ley de IA (art. 50), DMCA, eIDAS |
| 5.32 | Derechos de propiedad intelectual | **I** | Dependencias con licencia auditada; SPDX declarado en cada certificado |
| 5.33 | Protección de registros | **I** | `audit_logs` de solo-anexado; certificados firmados; raíces del árbol de transparencia ancladas **y confirmadas** en Bitcoin. La confirmación no se ejecutaba nunca con el registro en reposo; corregido y verificado el 05/08/2026 (bloque 960961) |
| 5.34 | Privacidad y datos personales | **I** | Minimización por diseño: sin analítica de terceros, sin cookies de seguimiento, retención de originales de 3 días |
| 5.35 | Revisión independiente de la seguridad | **P** | Revisiones adversariales automatizadas y programa de divulgación abierto. Sin auditor independiente contratado |
| 5.36 | Cumplimiento de políticas y normas | **I** | Esta declaración y su revisión semestral |
| 5.37 | Procedimientos operativos documentados | **I** | `docs/VPS_DEPLOY.md`, `docs/HARDENING.md`, `ARQUITECTURA.md` |

---

## A.6 · Controles de personas (8)

El alcance es una organización de una persona. Seis de los ocho controles regulan la relación
laboral y **no aplican por ausencia de empleados**, no por decisión de la dirección. Se declaran
igualmente para que el lector compruebe que no se han omitido.

| # | Control | Estado | Justificación |
|---|---|---|---|
| 6.1 | Investigación de antecedentes | **N/A** | No hay contrataciones |
| 6.2 | Términos y condiciones de empleo | **N/A** | No hay contratos de trabajo |
| 6.3 | Concienciación y formación | **P** | Formación continua del operador en seguridad aplicada. Sin programa formal ni registro de horas |
| 6.4 | Proceso disciplinario | **N/A** | No hay empleados sujetos a régimen disciplinario |
| 6.5 | Responsabilidades tras la terminación | **N/A** | No hay terminaciones. **Cubierto por otra vía:** el plan de continuidad describe qué ocurre si el operador cesa |
| 6.6 | Acuerdos de confidencialidad | **P** | Los términos de servicio obligan a Veritas frente al usuario. Sin acuerdos internos, al no haber a quién obligar |
| 6.7 | Trabajo remoto | **I** | Toda la operación es remota. Acceso exclusivo por SSH con clave, sin contraseña, y estación de trabajo cifrada |
| 6.8 | Notificación de eventos de seguridad | **I** | Canal público de reporte en `/.well-known/security.txt` con compromiso de plazos |

---

## A.7 · Controles físicos (14)

Trece de los catorce controles son responsabilidad del proveedor del centro de datos. **Declarar
como propio un control físico que ejecuta otro sería falsear la declaración**, así que se marcan
como transferidos y se identifica a quién.

| # | Control | Estado | Responsable real |
|---|---|---|---|
| 7.1 | Perímetro de seguridad física | **N/A** | Proveedor del centro de datos |
| 7.2 | Controles de entrada física | **N/A** | Proveedor del centro de datos |
| 7.3 | Seguridad de oficinas y recintos | **N/A** | No hay oficina |
| 7.4 | Vigilancia de la seguridad física | **N/A** | Proveedor del centro de datos |
| 7.5 | Protección contra amenazas físicas y ambientales | **N/A** | Proveedor del centro de datos |
| 7.6 | Trabajo en áreas seguras | **N/A** | No hay áreas físicas propias |
| 7.7 | Puesto de trabajo despejado y pantalla limpia | **P** | Bloqueo automático de la estación de trabajo. Sin política escrita hasta ahora; se incorpora al manual |
| 7.8 | Emplazamiento y protección de equipos | **N/A** | Proveedor del centro de datos |
| 7.9 | Seguridad de activos fuera de las instalaciones | **I** | La única estación de trabajo tiene cifrado de disco completo |
| 7.10 | Soportes de almacenamiento | **I** | Sin soportes extraíbles en el flujo. Las copias salen cifradas con AES-256 |
| 7.11 | Servicios de soporte (suministro eléctrico, etc.) | **N/A** | Proveedor del centro de datos |
| 7.12 | Seguridad del cableado | **N/A** | Proveedor del centro de datos |
| 7.13 | Mantenimiento de equipos | **N/A** | Proveedor del centro de datos |
| 7.14 | Eliminación o reutilización segura de equipos | **P** | Al liberar un servidor virtual, el proveedor destruye el volumen. **Compensado:** los datos en reposo relevantes salen cifrados, de modo que un volumen no destruido no expondría material probatorio |

---

## A.8 · Controles tecnológicos (34)

Es el bloque donde el sistema realmente se juega la seguridad, y donde la implementación es más
completa.

| # | Control | Estado | Implementación y evidencia |
|---|---|---|---|
| 8.1 | Dispositivos de usuario final | **I** | Estación única con cifrado de disco y bloqueo automático |
| 8.2 | Derechos de acceso privilegiado | **I** | Acceso al servidor solo por clave SSH. **Ningún contenedor corre como root** |
| 8.3 | Restricción del acceso a la información | **I** | Autorización por propietario en cada consulta; las obras privadas no son enumerables |
| 8.4 | Acceso al código fuente | **I** | Repositorio privado, acceso por clave |
| 8.5 | Autenticación segura | **I** | Enlace mágico de un solo uso con caducidad. Sin contraseñas que robar ni reutilizar |
| 8.6 | Gestión de capacidades | **P** | Vigilancia de disco y memoria con umbrales. Sin previsión formal de capacidad |
| 8.7 | Protección contra malware | **I** | **ClamAV real, en modo fail-closed:** si el antivirus no responde, el archivo no pasa. Antes invocaba un binario inexistente; corregido y verificado |
| 8.8 | Gestión de vulnerabilidades técnicas | **I** | `osv-scanner` en cada compilación, cuarentena de dependencias recientes, procedimiento CRA con plazos |
| 8.9 | Gestión de la configuración | **I** | Toda la infraestructura declarada en `docker-compose.yml`, versionada |
| 8.10 | Borrado de información | **I** | Purga automática de originales cada 3 días, con barrera de rutas que impide borrar fuera de las carpetas purgables |
| 8.11 | Enmascaramiento de datos | **I** | La vía pública muestra huella y metadatos, nunca el archivo original salvo consentimiento explícito |
| 8.12 | Prevención de fuga de datos | **P** | Salida de red del worker restringida a destinos conocidos. Sin inspección de contenido saliente |
| 8.13 | Copias de seguridad | **I** | Copia diaria **verificada por conteo de archivos**, copia cifrada fuera del servidor y **restauración probada**. Este control falló silenciosamente durante días y se corrigió |
| 8.14 | Redundancia de instalaciones | **P** | Varios servidores virtuales rotatorios. Sin conmutación automática por error |
| 8.15 | Registro de eventos | **I** | `audit_logs` de solo-anexado, 295+ eventos, con actor, acción, objetivo y momento |
| 8.16 | Actividades de seguimiento | **I** | Punto público de estado que informa de base de datos, cola, canalización, anclajes y transparencia |
| 8.17 | Sincronización de relojes | **I** | NTP en el host. **Y más importante:** la fecha probatoria no depende del reloj de Veritas, sino de Bitcoin y de una TSA RFC 3161 externa |
| 8.18 | Uso de programas de utilidad privilegiados | **I** | Todas las capacidades del kernel retiradas; `no-new-privileges` impide escalada por binarios setuid |
| 8.19 | Instalación de software en sistemas operativos | **I** | Sistema de archivos raíz en **solo lectura** en los contenedores de aplicación: no se puede instalar nada en caliente |
| 8.20 | Seguridad de redes | **I** | Red interna de Docker aislada; solo el proxy expone puertos |
| 8.21 | Seguridad de los servicios de red | **I** | TLS 1.2+ con certificados renovados automáticamente |
| 8.22 | Segregación de redes | **I** | Cada proyecto del servidor tiene su propia red de contenedores, sin rutas entre ellas |
| 8.23 | Filtrado web | **I** | Protección contra falsificación de peticiones del lado del servidor en el capturador: resuelve el DNS y rechaza direcciones privadas, de bucle local, de enlace local y de metadatos de nube, revalidando en cada redirección |
| 8.24 | Uso de criptografía | **I** | SHA-256 para huellas; firma del certificado con clave privada montada en solo lectura; AES-256 con derivación PBKDF2 en las copias |
| 8.25 | Ciclo de vida de desarrollo seguro | **I** | Revisión de seguridad previa a cada despliegue, con hallazgos verificados de forma adversarial |
| 8.26 | Requisitos de seguridad de las aplicaciones | **I** | Validación estricta de entrada, listas de tipos permitidos, límites de tamaño y de tasa |
| 8.27 | Arquitectura y principios de ingeniería segura | **I** | Mínimo privilegio, fallo cerrado, defensa en profundidad. Documentado en `ARQUITECTURA.md` |
| 8.28 | Codificación segura | **I** | TypeScript estricto; consultas parametrizadas vía Prisma; escapado por defecto de React |
| 8.29 | Pruebas de seguridad | **I** | Pruebas de límite de tasa con ráfagas paralelas; pruebas de restauración de copias; verificación de pruebas de inclusión |
| 8.30 | Desarrollo externalizado | **N/A** | No hay desarrollo externalizado |
| 8.31 | Separación de entornos | **P** | Producción aislada. **No hay entorno de preproducción**: los cambios se validan en producción con reversión inmediata. Riesgo reconocido |
| 8.32 | Gestión de cambios | **I** | Cambios versionados, con reversión probada. Ejemplo real: la política de contenido con nonce se revirtió el mismo día al detectar que rompía el sitio |
| 8.33 | Información de prueba | **I** | Sin datos de producción en pruebas; se generan obras sintéticas |
| 8.34 | Protección durante auditorías | **I** | Las consultas de auditoría son de solo lectura y no interrumpen el servicio |

---

## Resumen cuantitativo

| Estado | A.5 | A.6 | A.7 | A.8 | **Total** |
|---|---|---|---|---|---|
| Implementado | 27 | 2 | 2 | 27 | **58** |
| Parcial | 8 | 2 | 2 | 7 | **19** |
| No aplicable | 1 | 4 | 10 | 1 | **16** |
| No implementado | 1 | 0 | 0 | 0 | **1** |
| **Controles del tema** | 37 | 8 | 14 | 34 | **93** |

**De los 77 controles aplicables, 58 están implementados (75 %), 19 parcialmente (25 %) y uno no
lo está.** El único control aplicable no implementado es la segregación de funciones, imposible
por definición en una organización de una persona; se declara como riesgo aceptado y se compensa
con registros de solo-anexado y anclaje externo fuera del control de la organización.

---

## Los 19 controles parciales, sin adornos

Un porcentaje alto de implementación no dice nada si no se detalla qué falta. Esto es lo que
falta, ordenado por lo que más importaría a un auditor:

1. **8.31 · Sin entorno de preproducción.** Es la brecha más incómoda. Los cambios se validan en
   producción confiando en la reversión rápida. Ha funcionado —hay un caso real documentado— pero
   es suerte gestionada, no control.
2. **5.35 · Sin revisión independiente.** Hay revisión adversarial automatizada y canal de
   divulgación abierto, pero nadie externo ha auditado el sistema.
3. **8.14 · Sin conmutación automática por error.** Hay redundancia de servidores, pero el relevo
   es manual.
4. **8.12 · Sin inspección de contenido saliente.** Se restringen destinos, no contenidos.
5. **5.20 y 5.22 · Proveedores sin acuerdos negociados ni revisión periódica formal.**
6. **6.3 · Formación sin registro.**
7. **8.6 · Sin previsión de capacidad.**
8. **7.14 · Destrucción de soportes delegada** en el proveedor, sin certificado de destrucción.
9. **5.5, 5.6, 5.13, 6.6, 7.7, 8.6** · Formalización documental pendiente de controles que en la
   práctica ya se ejercen.

Ninguno de estos huecos afecta a la validez probatoria de un certificado ya emitido. Todos
afectan a la resiliencia de la organización que los emite. Es una distinción importante y se
declara expresamente.

---

## Cómo verificar lo que dice este documento

| Afirmación | Comprobación |
|---|---|
| Contenedores sin privilegios | `docker inspect` sobre cualquiera de los cuatro servicios |
| Antivirus en fail-closed | Subir un archivo de prueba EICAR |
| Registro de solo-anexado | Consultar `audit_logs`; no existe ruta de borrado en el código |
| Anclaje independiente | Descargar el `.ots` y verificarlo con cualquier cliente OpenTimestamps |
| Transparencia | Pedir una prueba de inclusión y validarla contra la raíz publicada |
| Copias verificadas | El script de copia falla en voz alta si el conteo no cuadra |

---

*Aprobado por la dirección de Veritas Digital LLC el 5 de agosto de 2026. Documento vivo: cualquier
cambio en el sistema que altere un estado de esta tabla obliga a actualizarla antes del despliegue.*