Plantillas documentales — esqueletos para producir documentación normativa
Esta carpeta contiene 9 plantillas razonadas de los documentos normativos que un QTSP de QTSA + QERDS debe producir, validar legalmente y (algunos) publicar.
Por qué existe esta carpeta
Para entrar en la TSL, no basta con tener un sistema funcionando: eIDAS y ETSI exigen un conjunto de documentos formales que el QTSP debe tener en regla. El CAB (auditor) los lee y los compara contra la realidad operativa. Si hay desalineación → no conformidad. Si no existen → no entras en la TSL.
Estas plantillas:
- No son los documentos finales del cliente. Son esqueletos con la estructura completa que exige la norma, con secciones, subsecciones y referencias cruzadas a las cláusulas que cada cosa debe cubrir.
- Activo metodológico reusable: vive en el repo del consultor, no en el sistema documental del cliente.
- Acelera el trabajo: redactar esto desde cero te puede llevar 6 meses; tener la estructura pre-mapeada a las cláusulas te ahorra ese trabajo de arquitectura.
Reglas de uso
- No se rellenan en la fase de gap analysis. En la fase 2 (revisión de controles) las plantillas se leen como referencia para evaluar lo que tiene el cliente, pero no se modifican. Ver sección Cuándo se rellenan.
- No se rellenan sin haber completado el discovery + gap analysis primero. Las decisiones de alcance (modalidad QERDS, identificación remota, CA interna…) condicionan el contenido.
- Asesoría legal obligatoria antes de publicar la versión final.
- Firma con sello cualificado en todos los documentos públicos antes de publicarlos.
Cómo se relacionan los documentos — la jerarquía
No son 9 documentos sueltos. Hay un orden:
┌──────────────────────────────────────┐
│ politica-seguridad-info.md │ ← política PARAGUAS del SGSI
│ (ISMS Top-Level Policy) │ (la dirección la firma una sola
└──────────────────────────────────────┘ vez; todo lo demás depende de ella)
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ politica-gestion │ │ plan-continuidad │ │ plan-cese- │ ← políticas/planes
│ -claves.md │ │ .md (BCP/DRP) │ │ actividad.md │ transversales
│ (KMS Policy) │ │ │ │ │
└──────────────────┘ └──────────────────┘ └──────────────────┘
│
┌───────────────┴───────────────┐
▼ ▼
┌────────────────────┐ ┌────────────────────┐
│ QTSA │ │ QERDS │ ← documentación
│ ┌──────────────┐ │ │ ┌──────────────┐ │ específica de cada
│ │ politica- │ │ │ │ politica- │ │ servicio
│ │ servicio- │ │ │ │ servicio- │ │
│ │ tsa.md (CP) │ │ │ │ erds.md (CP) │ │
│ └──────────────┘ │ │ └──────────────┘ │
│ ┌──────────────┐ │ │ ┌──────────────┐ │
│ │ practicas- │ │ │ │ practicas- │ │
│ │ tsa.md (CPS) │ │ │ │ erds.md(CPS) │ │
│ └──────────────┘ │ │ └──────────────┘ │
└────────────────────┘ └────────────────────┘
│
┌──────────────────────────────────────┐
│ declaracion-pds.md │ ← cara pública resumida
│ (PKI Disclosure Statement) │ para usuarios finales
└──────────────────────────────────────┘
Política vs Prácticas — el patrón clave
Para QTSA y para QERDS hay siempre dos documentos: uno de Política y otro de Prácticas. Son distintos:
| Política (Policy / CP) | Prácticas (Practice Statement / CPS) | |
|---|---|---|
| Pregunta que responde | ¿Qué garantiza el servicio? | ¿Cómo se garantiza operativamente? |
| Nivel de detalle | Alto, conceptual, semi-comercial | Bajo, operativo, técnico |
| Cambia con frecuencia | No (estable años) | Sí (cada cambio operativo significativo) |
| Identificada por | OID propio referenciado en el TST/evidencia | Versión |
| Audiencia | Cliente, parte que confía, juez | CAB, supervisor, equipo interno |
| Ejemplo de lo que dice | "Garantizamos exactitud ≤ 1 segundo respecto a UTC" | "Sincronizamos con GNSS en TIME-01 + NTP estrato 1; drift se mide cada 5 min; > 0.5s se levanta alerta y se aísla la TSU" |
Los TSTs y las evidencias QERDS llevan en su contenido un OID que apunta a la Política, no a las Prácticas. La Política es el "contrato" inmutable; las Prácticas son el "manual interno" que evoluciona.
Las 9 plantillas
| Archivo | Documento | Pública / Interna | Quién la firma | Norma base |
|---|---|---|---|---|
politica-seguridad-info.md | ISMS Top-Level Policy | Interna (extracto público) | Director General | ISO 27001 §5.2 + ETSI EN 319 401 §6 |
politica-gestion-claves.md | KMS Policy | Interna | CISO + CTO | ETSI EN 319 401 §7.5 + 421 §7.6 |
plan-continuidad.md | BCP / DRP | Interna | CISO + dirección | ETSI EN 319 401 §7.11 + ISO A.5.29-30 |
plan-cese-actividad.md | Plan de cese | Verificada por supervisor | Consejo de Administración | eIDAS art. 24.2.h/i + Ley 6/2020 §9.3.c |
politica-servicio-tsa.md | Time-Stamp Policy (CP) | Pública | QTSP (sello cualificado) | ETSI EN 319 421 §6 + RFC 3628 |
practicas-tsa.md | TSA Practice Statement (CPS) | Normalmente pública | QTSP (sello cualificado) | ETSI EN 319 421 §6 |
politica-servicio-erds.md | ERDS Policy (CP) | Pública | QTSP (sello cualificado) | ETSI EN 319 521 §6 + eIDAS art. 44 |
practicas-erds.md | ERDS Practice Statement (CPS) | Normalmente pública | QTSP (sello cualificado) | ETSI EN 319 521 §6 |
declaracion-pds.md | PKI Disclosure Statement | Pública, una página | QTSP (sello cualificado) | ETSI EN 319 411-1 Anexo A |
El plan de cese es el único que el supervisor revisa explícitamente antes de meterte en la TSL (eIDAS art. 24.2.i). El PDS es un documento corto de cara al usuario final, debe estar accesible en la web del QTSP en una URL estable.
Mapeo plantilla → controles auditados
Cada plantilla cubre un conjunto concreto de controles de las matrices en ../02-gap-analysis/. Cuando estás auditando un control y necesitas saber "¿cómo debería ser un cumplimiento bueno?", abres la plantilla correspondiente.
politica-seguridad-info.md (ISMS Top-Level)
| Matriz fuente | Controles | Tema |
|---|---|---|
27001-sgsi.md | 27001 §5.1 (Liderazgo), §5.2 (Política), §5.3 (Roles), §4.1-4.4 (Contexto) | T01 |
27001-sgsi.md | A.5.1 (Políticas), A.5.2 (Roles), A.5.4 (Responsabilidades dirección) | T01 |
401-general-tsp.md | §6.3 (REQ-6.3-01 a -09) (Information security policy) | T01 |
politica-gestion-claves.md (KMS Policy)
| Matriz fuente | Controles | Tema |
|---|---|---|
401-general-tsp.md | §7.5 (REQ-7.5-01 a -05) (Cryptographic controls) | T04 |
421-qtsa-policy.md | §6.5 (OVR-6.5-x) (TSU certificate / política), §7.6 (TIS-7.6.x) (gestión claves TSU completa) | T04 |
422-qtsa-protocol.md | §6.x (TSU certificate profile), §9.x (qcStatements) | T04 |
27001-sgsi.md | A.8.24 (Uso de criptografía) | T04 |
plan-continuidad.md (BCP/DRP)
| Matriz fuente | Controles | Tema |
|---|---|---|
401-general-tsp.md | §7.11.1 (BCM general), §7.11.2 (recovery), §7.11.3 (testing) | T10 |
27001-sgsi.md | A.5.29 (Información durante interrupción), A.5.30 (Preparación TIC para BC), A.8.13 (Backup), A.8.14 (Redundancia) | T10 / T06 |
plan-cese-actividad.md (Termination Plan)
| Matriz fuente | Controles | Tema |
|---|---|---|
401-general-tsp.md | §7.12 (REQ-7.12-01 a -11) (Termination plans) | T10 |
eidas-legales.md | eIDAS §24.2.h (registrar/mantener), eIDAS §24.2.i (plan verificado supervisor) | T10 |
eidas-legales.md | Ley 6/2020 §9.3.a (conservación 15 años), Ley 6/2020 §9.3.c (cese 2 meses) | T10 |
politica-servicio-tsa.md (TSA Policy / CP)
| Matriz fuente | Controles | Tema |
|---|---|---|
421-qtsa-policy.md | §5 (OVR-5.x) (políticas overview), §6 (OVR-6.x) (políticas y prácticas), §8 (cualificación eIDAS) | T07 |
eidas-legales.md | eIDAS §41.2 (efecto), §42.1.a/b/c (requisitos TST) | T07 |
practicas-tsa.md (TSA Practice Statement / CPS)
| Matriz fuente | Controles | Tema |
|---|---|---|
421-qtsa-policy.md | §6.1 (TSPS), §7.7 (TIS-7.7.x) (sellado y UTC), §7.14 (físico) | T07 / T05 |
401-general-tsp.md | §7.1 (org), §7.7 (operations), §7.8 (network), §7.9 (incidentes), §7.10 (logs) | T01 / T06 / T10 |
La TSPS se solapa con otras plantillas (KMS, BCP, plan de cese). En la práctica suele referenciarlas en lugar de duplicar contenido.
politica-servicio-erds.md (ERDS Policy / CP)
| Matriz fuente | Controles | Tema |
|---|---|---|
521-qerds-policy.md | §4.1.1-x (publication of practice statement), §4.1.2-x (qualified-specific), §4.2-x (T&C) | T08 |
eidas-legales.md | eIDAS §43.2 (efecto QERDS), §44.1.a-f (los 6 requisitos QERDS) | T08 / T09 |
practicas-erds.md (ERDS Practice Statement / CPS)
| Matriz fuente | Controles | Tema |
|---|---|---|
521-qerds-policy.md | §5.x (operación: identificación, mensajes, evidencias, retención) | T08 |
522-qerds-protocol.md | 522-1 §5/§6 (interfaces y eventos), 522-2/-3 (semántica/formato), 522-4-x (perfiles) | T09 |
401-general-tsp.md | §7.7/7.8/7.10 (operaciones que aplican a QERDS) | T06 |
declaracion-pds.md (PKI Disclosure Statement)
| Matriz fuente | Controles | Tema |
|---|---|---|
eidas-legales.md | eIDAS §24.2.d (Información clara al usuario antes del contrato) | T11 |
421-qtsa-policy.md | §5.2 (OVR-5.2-x) (TSA disclosure statement con OID), §6.2 (OVR-6.2-x) (especificación) | T07 |
521-qerds-policy.md | Indirectamente — la plantilla resume la política QERDS | T08 |
Mapeo inverso: tema → plantillas
Si vas por la matriz consolidada y quieres saber qué plantillas tocan un tema:
| Tema | Plantillas relevantes |
|---|---|
| T01 Gobierno y SGSI | politica-seguridad-info.md |
| T02 RR.HH. | (Ninguna directa — son procedimientos internos no normados como plantilla) |
| T03 Activos y accesos | (Ninguna directa) |
| T04 Cripto y claves | politica-gestion-claves.md |
| T05 Físico | practicas-tsa.md (sección física), practicas-erds.md (idem) |
| T06 Operación, red, monitorización | practicas-tsa.md, practicas-erds.md |
| T07 QTSA | politica-servicio-tsa.md, practicas-tsa.md, declaracion-pds.md |
| T08 QERDS política e identificación | politica-servicio-erds.md, practicas-erds.md, declaracion-pds.md |
| T09 QERDS protocolo y evidencias | practicas-erds.md |
| T10 Continuidad, incidentes, cese | plan-continuidad.md, plan-cese-actividad.md |
| T11 Cumplimiento, supply chain, admin | declaracion-pds.md, plan-cese-actividad.md (parcial) |
Hay gaps notables: T02 (RR.HH.) y T03 (activos y accesos) no tienen plantilla específica en este repo. En la práctica esos viven en el SGSI del cliente como procedimientos derivados de la política de seguridad. Los WP-01 / WP-02 los producen sin que tengamos plantilla raíz aquí.
Cuándo se rellenan
Las plantillas no se rellenan en T+0. Se rellenan a partir de T+10 mes aproximadamente, cuando ya hay plataforma operativa que documentar.
T+0 ─────────────── T+10 ─────────────── T+13 ──── T+15 ──── T+18
│ │ │ │ │
Discovery Plataforma Documentación CAR Alta
cerrado en producción publicada CAB TSL
(no cualificada)
| Fase | ¿Qué pasa con las plantillas? |
|---|---|
| Discovery (T+0 a T+2) | Se ojean para entender la documentación que tendrá que producir el cliente. No se modifican. |
| Gap analysis (T+2 a T+8) | Se usan como patrón de referencia al evaluar controles. No se modifican. |
| Roadmap (T+8 a T+10) | Se identifica el WP-10 como el que las llenará. No se modifican. |
| WP-10 (T+10 a T+13) | El cliente, ayudado por su asesoría legal, rellena cada plantilla con datos reales. Aquí se materializa el documento del cliente. |
| Publicación (T+13+) | Documento firmado con sello cualificado y publicado en URL pública del QTSP. |
Las plantillas de este repo siguen siendo activos del consultor. Lo que el cliente recibe son los borradores rellenados a partir de ellas, no la plantilla raíz.
Formato común de cada plantilla
Todas tienen esta estructura mínima:
- Identificación del documento — nombre del QTSP, OID, versión, fecha, autor, aprobador.
- Alcance — qué servicio cubre, qué está fuera de alcance.
- Audiencia — pública / interna / clientes / supervisores.
- Definiciones — referencia al
../00-marco-regulatorio/glosario.md. - Cuerpo del documento — secciones específicas según norma de referencia, mapeadas a cláusulas concretas.
- Aprobación — firmas / sellos.
- Histórico de versiones.
Convención de versionado
v0.x — borradores internos
v1.0 — primera versión publicada (post-CAR positivo)
v1.x — actualizaciones menores
v2.0 — cambios mayores que requieren re-comunicación al supervisor
Cómo recibe el cliente la documentación final
Una vez rellenadas y validadas legalmente, los documentos públicos se publican en el sitio web del QTSP en una zona estable (típicamente https://qtsp.example/legal/ o similar). Cada documento:
- Va firmado con sello cualificado del propio QTSP.
- Tiene URL permanente — los TSTs y evidencias QERDS pueden referenciar OIDs que apuntan a estos documentos durante 15+ años.
- Cualquier cambio sustantivo se comunica al supervisor antes de publicar la nueva versión.
Los documentos internos (KMS Policy, BCP/DRP, política ISMS detallada) viven en el sistema documental interno del QTSP, accesibles solo al personal autorizado y al CAB durante la auditoría.