Workflow: Backup Verification (Trimestral)

Runbook operativo. Garantiza que los backups de Lawra sean recuperables, íntegros y funcionales mediante pruebas de restauración trimestrales. La existencia de backups sin verificación no es evidencia de resiliencia; este proceso cierra esa brecha. Cumple controles SOC 2 (A1.2, A1.3), ISO 27001 A.12.3 y la Política de Backup y Recuperación. Aprobado por la Asamblea en [__]. Versión: 1.0.

1. Trigger

Cadencia: Una vez por trimestre calendario (enero, abril, julio, octubre). La verificación debe completarse dentro de los primeros 15 días del mes de inicio del trimestre.
Ad-hoc: Tras un incidente de pérdida de datos o corrupción detectada.
Ad-hoc: Antes de una migración de infraestructura mayor (ej. cambio de proveedor de base de datos).
Ad-hoc: Solicitud del equipo de auditoría (SOC 2, cliente Enterprise).

2. Roles y Responsabilidades (RACI)

Tarea	Responsable	Aprobador	Consultado	Informado
Planificación y ejecución de la verificación	Luishy Medina (CTO)	—	—	Carlos Miranda Levy
Selección aleatoria del backup a restaurar	Luishy Medina	—	—	—
Restauración técnica en ambiente aislado	Luishy Medina / Ingeniero senior	Luishy	—	—
Validación de integridad de datos	Luishy Medina	—	—	—
Documentación y reporte	Luishy Medina	Carlos Miranda Levy	Tanya Mejía-Ricart	CCO
Revisión del reporte por la Asamblea	Carlos Miranda Levy	Asamblea	—	Todos

3. Inventario de Backups a Verificar

Cada verificación trimestral cubre los siguientes sistemas (los que apliquen al stack actual):

Sistema	Tipo de backup	Proveedor	Frecuencia del backup	Retención
Firestore (base de datos principal)	Export automático a Google Cloud Storage	Google Cloud	Diario	30 días
Firebase Auth (configuración de usuarios)	Export manual / script	Firebase	Semanal o bajo demanda	90 días
Repositorio de código (GitHub)	Git distribuido + fork/mirror	GitHub	Continuo (cada push)	Permanente
Google Drive (contratos, documentos legales)	Google Vault o export periódico	Google Workspace	Diario (papelera 30 días)	Según política de retención
Configuración de infraestructura (firebase.json, firestore.rules, etc.)	En el repositorio Git	GitHub	Cada commit	Permanente
Emails y comunicaciones críticas	Google Vault	Google Workspace	Continuo	Según política

4. Pasos Numerados

Fase 1 — Planificación (Semana 1 del trimestre, Day 1–3)

Paso 1 — Confirmación del calendario: Luishy confirma que el ejercicio está agendado en las primeras 2 semanas del mes de inicio del trimestre. Si el mes de inicio coincide con una release mayor o un cambio de infraestructura, el ejercicio se realiza antes de dicho cambio.

Paso 2 — Selección aleatoria del backup a restaurar: Para cada sistema en el inventario, Luishy selecciona aleatoriamente un backup de la ventana de retención para restaurar:

Para Firestore: seleccionar un export de un día aleatorio de los últimos 30 días (no el más reciente).
Para Drive: seleccionar una carpeta o documento crítico de una fecha aleatoria del último trimestre.

Documentar la selección: sistema, fecha del backup seleccionado, hora de la selección. La aleatoriedad es importante para SOC 2 — se debe poder demostrar que no se “escogen” los backups más limpios.

Paso 3 — Preparación del ambiente de restauración: Luishy prepara un ambiente completamente aislado de producción para la restauración:

Proyecto GCP separado o namespace diferente en Firebase.
Sin acceso a datos reales de usuarios desde el ambiente de prueba.
Sin conexión a los sistemas de IA en producción.

Fase 2 — Restauración (Day 3–7)

Paso 4 — Restauración de Firestore: Luishy ejecuta la restauración del export de Firestore seleccionado al proyecto/ambiente de prueba:

# Ejemplo de restauración de Firestore desde GCS
gcloud firestore import gs://lawra-backups/{fecha-seleccionada}/firestore-export \
  --collection-ids=users,submissions,newsletter-subscribers,trial-simulations \
  --project=lawra-backup-test

Documentar: hora de inicio, comando ejecutado, salida del comando (éxito / errores), hora de finalización.

Paso 5 — Verificación de integridad del backup restaurado: Luishy ejecuta consultas de validación contra la base de datos restaurada:

Conteo de documentos por colección: ¿los números son plausibles comparados con la producción de esa fecha?
Verificar que documentos muestra (IDs conocidos) existen y tienen la estructura de datos esperada.
Verificar que no hay colecciones faltantes o con 0 documentos cuando se esperaba contenido.
Verificar checksums o hashes si el proveedor los genera.

Paso 6 — Restauración de configuración de infraestructura (Git): Verificar que el repositorio de código tiene el historial completo y es recuperable:

git log --oneline -20  # Verificar historial reciente
git clone {URL del repo} lawra-recovery-test  # Clonar en directorio local temporal
npm run build  # Verificar que el último commit buildea sin errores

Paso 7 — Restauración de documentos de Drive (muestra): Luishy verifica que 3–5 documentos críticos de Drive (contratos, actas) son accesibles y tienen el contenido correcto (apertura + revisión visual de la primera página).

Fase 3 — Validación Funcional (Day 7–10)

Paso 8 — Prueba de lectura funcional: Con la base de datos restaurada (en ambiente aislado), Luishy ejecuta una instancia local de la aplicación conectada al ambiente de prueba y verifica:

Que un usuario de prueba puede autenticarse.
Que los datos del usuario de prueba están presentes (historial, preferencias).
Que las funciones básicas de lectura operan sin errores.

Paso 9 — Medición del RTO (Recovery Time Objective): Luishy registra el tiempo total transcurrido desde el inicio de la restauración (Paso 4) hasta la validación funcional completada (Paso 8). Este es el RTO observado para el trimestre.

Objetivo RTO: < 4 horas para restauración completa de Firestore + validación funcional básica.

Si el RTO observado supera el objetivo → documentar el gap y planificar mejoras de infraestructura.

Paso 10 — Verificación de RPO (Recovery Point Objective): Luishy confirma cuál es la pérdida máxima de datos si se usara este backup en una recuperación real:

Para backups diarios: RPO máximo = 24 horas.
Si el RPO observado es mayor (ej. el último backup disponible tiene más de 24 horas de antigüedad), documentar como hallazgo y escalar.

Fase 4 — Limpieza y Documentación (Day 10–12)

Paso 11 — Limpieza del ambiente de restauración: Luishy destruye o limpia el ambiente de prueba creado:

Eliminar el proyecto GCP de prueba o las colecciones restauradas.
Confirmar que no quedan datos reales de usuarios en el ambiente de prueba.
Eliminar archivos temporales locales.

Paso 12 — Documentación del ejercicio: Luishy completa el Reporte de Verificación de Backup Trimestral con:

Fecha y período del trimestre.
Sistemas verificados.
Backups seleccionados (sistema, fecha del backup).
Resultados de integridad (éxito / fallo / hallazgos parciales).
RTO observado vs. objetivo.
RPO observado vs. objetivo.
Hallazgos o problemas identificados.
Acciones correctivas necesarias (si aplica).

Fase 5 — Reporte y Acciones Correctivas (Day 12–15)

Paso 13 — Revisión del reporte: Carlos Miranda Levy revisa el reporte. Si hay hallazgos críticos (backup corrupto, RTO fuera de objetivo, backups faltantes), se escala inmediatamente como un riesgo operativo.

Decisión A: ¿Se identificaron hallazgos críticos?

Sí → Abrir un plan de acción correctiva con Luishy en < 5 días hábiles. Si el sistema de backup está comprometido → notificar a Tanya (implicaciones de DPA con clientes Enterprise).
No → El reporte se archiva como evidencia SOC 2 y se presenta en la próxima Asamblea trimestral.

Paso 14 — Comunicación a la Asamblea: En la reunión trimestral de socios, Luishy presenta un resumen de 2–3 minutos:

Sistemas verificados.
RTO / RPO observados.
Hallazgos y estado de acciones correctivas.

5. Procedimiento de Backup Mensual (Verificación Ligera)

Entre las verificaciones trimestrales completas, Luishy realiza una verificación ligera mensual:

Confirmar que los backups automáticos de Firestore se ejecutaron correctamente en el último mes (revisar logs de GCS).
Confirmar que el repositorio GitHub está activo y recibiendo pushes.
Confirmar que Google Vault está retiendo emails según la política.
Documentar en un log mensual (5 minutos de trabajo).

6. Puntos de Decisión

Decisión	Opciones
A — ¿Hallazgos críticos en la verificación?	No → archivar y presentar / Sí → plan correctivo + notificar Tanya si aplica DPA
B — ¿RTO observado supera el objetivo?	No → documentar / Sí → planificar mejoras de infraestructura en el trimestre siguiente
C — ¿Backup no disponible para la fecha seleccionada?	Investigar fallo del sistema de backup → hallazgo crítico → Decisión A

7. Outputs / Artifacts

Reporte de Verificación de Backup Trimestral (por trimestre).
Log de verificación ligera mensual.
Plan de acción correctiva (si aplica).
Evidencia de comandos ejecutados y resultados (capturas o logs).

8. Checklist Final

9. Métricas / KPIs

Métrica	Objetivo
Verificaciones trimestrales completadas en el año	4 de 4
RTO observado (Firestore + validación funcional)	< 4 horas
RPO observado (antigüedad del último backup disponible)	≤ 24 horas
Backups sin disponibilidad en la fecha seleccionada	0
Hallazgos críticos sin plan correctivo en 5 días	0
Reportes archivados y disponibles para auditoría SOC 2	100 %

10. Referencias

Política de Backup y Recuperación
Plan de Respuesta a Incidentes (orden 31) — para brechas durante la restauración
Política de Gestión de Cambios — coordinación de ejercicios antes de migraciones
SOC 2 Criterios de Disponibilidad A1.2 (backups) y A1.3 (recuperación)
ISO 27001 A.12.3 — Copias de seguridad de la información
NIST SP 800-34 Rev.1 — Contingency Planning Guide for Federal Information Systems

11. Auditoría

Registro	Retención	Evidencia SOC 2
Reporte de verificación trimestral	5 años	A1.2 — Environmental protections / A1.3 — Recovery
Log de verificación ligera mensual	5 años	A1.2
Planes de acción correctiva	5 años	A1.2
Evidencia de selección aleatoria del backup	5 años	CC9.1 — Risk management

Adoptado por la Asamblea General de Socios en fecha [__]. Próxima revisión: [fecha + 12 meses]. Próximo ejercicio trimestral: [mes de inicio del próximo trimestre].

Por LAWRA, S.R.L. — Gerente

Workflow: Backup Verification (Trimestral)

Workflow: Backup Verification (Trimestral)

1. Trigger

2. Roles y Responsabilidades (RACI)

3. Inventario de Backups a Verificar

4. Pasos Numerados

Fase 1 — Planificación (Semana 1 del trimestre, Day 1–3)

Fase 2 — Restauración (Day 3–7)

Fase 3 — Validación Funcional (Day 7–10)

Fase 4 — Limpieza y Documentación (Day 10–12)

Fase 5 — Reporte y Acciones Correctivas (Day 12–15)

5. Procedimiento de Backup Mensual (Verificación Ligera)

6. Puntos de Decisión

7. Outputs / Artifacts

8. Checklist Final

9. Métricas / KPIs

10. Referencias

11. Auditoría

Comments