Política de Continuidad de Negocio y Recuperación ante Desastres
Política operativa interna. Define los mecanismos que permiten a Lawra, S.R.L. mantener o restablecer sus operaciones ante eventos disruptivos, garantizando la disponibilidad de los servicios comprometidos con los clientes. Aprobada por la Asamblea en [__]. Versión: 1.0.
1. Propósito y Alcance
1.1. Esta política establece el marco de continuidad de negocio (BCP) y recuperación ante desastres (DRP) de Lawra, S.R.L., incluyendo los objetivos de tiempo y punto de recuperación, los escenarios de riesgo contemplados, los procedimientos de activación y restauración, y el plan de comunicaciones.
1.2. — Objetivos estratégicos:
- Proteger la continuidad de los servicios de la plataforma Lawra frente a interrupciones.
- Minimizar el tiempo de inactividad y la pérdida de datos en caso de desastre.
- Cumplir los compromisos de disponibilidad adquiridos con los clientes en los SLAs y DPAs correspondientes.
- Alinearse con los controles SOC 2 Trust Services Criteria: CC9.1 (identificación y gestión de riesgos operativos), A1.2 (capacidad de procesamiento + objetivos de disponibilidad) y A1.3 (recuperación de infraestructura).
1.3. — Aplica a: todos los sistemas productivos de Lawra, incluyendo la plataforma web, servicios de IA, datos de clientes, comunicaciones corporativas y el equipo de operaciones.
2. Sistemas en Alcance y Clasificación de Criticidad
2.1. Los sistemas se clasifican en tres niveles según su impacto en la prestación del servicio:
| Sistema | Criticidad | Descripción |
|---|---|---|
| Firebase Auth | Crítica | Autenticación de usuarios finales. Sin esto, ningún usuario puede iniciar sesión. |
| Firestore (Base de Datos) | Crítica | Almacena conversaciones, simulaciones, suscripciones, envíos. Pérdida equivale a pérdida de datos de cliente. |
| Gemini AI (Google AI / Firebase AI) | Alta | Motor de IA que alimenta los asistentes. La degradación impacta la propuesta de valor central. |
| GitHub (repositorio + CI/CD) | Alta | Código fuente, pipelines de despliegue. Sin acceso, no se pueden publicar hotfixes. |
| Sitio web estático (GitHub Pages) | Media | Frontend visible al público. Caída impacta adquisición y acceso de usuarios. |
| Google Workspace | Media | Correo corporativo, documentación interna, comunicaciones de equipo. |
| 1Password / Bitwarden (gestor de credenciales) | Alta | Sin acceso a credenciales no se pueden operar otros sistemas. |
3. Objetivos de Recuperación (RTO / RPO)
3.1. Los objetivos de recuperación se definen por nivel de criticidad:
| Sistema | RTO (tiempo máximo de inactividad aceptable) | RPO (pérdida máxima de datos aceptable) |
|---|---|---|
| Firebase Auth | 4 horas | N/A (sin estado en Lawra) |
| Firestore | 4 horas | 24 horas (último backup diario) |
| Gemini AI | 8 horas | N/A (servicio externo sin estado local) |
| GitHub + CI/CD | 8 horas | 0 (mirror actualizado en tiempo real cuando aplique) |
| Sitio web estático | 12 horas | N/A (se regenera desde código fuente) |
| Google Workspace | 12 horas | 48 horas |
| Gestor de credenciales | 2 horas | N/A (se accede desde copia de emergencia sellada) |
3.2. En caso de que los objetivos RTO/RPO no puedan cumplirse por causas fuera del control de Lawra (fallo de proveedor cloud extendido), el Gerente o CTO notificará a los clientes afectados en un plazo no mayor a 4 horas desde la detección del evento.
4. Escenarios de Desastre Contemplados
4.1. — Interrupción regional de nube (Outage de Google Cloud / Firebase):
- GCP experimenta una caída regional que afecta
us-east1o la región primaria de Firestore/Firebase. - Respuesta: Activar failover a región secundaria si está configurado; verificar en Google Cloud Status; comunicar a clientes; estimar ETA con base en actualizaciones del proveedor. Si el outage supera 4 horas, activar protocolo de comunicación de incidente.
4.2. — Ransomware o ataque de destrucción de datos:
- Un atacante cifra o elimina datos en Firestore o repositorios.
- Respuesta: Aislar inmediatamente los sistemas afectados; revocar credenciales comprometidas; restaurar desde el último backup verificado (ver
backup-recovery-policy); activar Plan de Respuesta a Incidentes (incident-response-plan); notificar a clientes y a la Agencia de Protección de Datos si hay violación de datos personales bajo Ley 172-13.
4.3. — Pérdida de personal clave (founder / CTO):
- Incapacidad temporal o permanente de Carlos Miranda Levy, Luishy Medina u otro responsable técnico o directivo.
- Respuesta: Activar la cadena de suplencia documentada en la sección 7. Las credenciales de emergencia (break glass) permiten que un segundo socio acceda a los sistemas críticos sin el principal responsable.
4.4. — Corrupción de datos (sin ataque externo):
- Error de despliegue o bug en producción que produce escrituras erróneas en Firestore.
- Respuesta: Identificar alcance de la corrupción revisando los logs de Firestore; ejecutar restauración selectiva desde el backup más reciente previo al evento; verificar integridad post-restauración; redactar post-mortem.
4.5. — Pérdida de acceso al dominio / DNS:
- Expiración accidental del dominio o compromiso de la cuenta del registrador.
- Respuesta: Contactar al registrador con prueba de identidad; activar DNS de contingencia si está configurado; verificar que el dominio tiene autorenew activo y el correo de notificación es una cuenta corporativa activa.
4.6. — Pérdida del repositorio principal en GitHub:
- Borrado accidental de organización o repositorio.
- Respuesta: Restaurar desde mirror o backup de repositorio (ver
backup-recovery-policy); contactar soporte de GitHub; evaluar impacto en pipeline de CI/CD.
5. Playbook de Activación del DRP
5.1. — Criterios de activación: El DRP se activa cuando:
- Un sistema de Criticidad Alta o Crítica está inaccesible por más de 1 hora sin ETA de resolución del proveedor.
- Se detecta pérdida o corrupción de datos de clientes.
- Se recibe un alerta de ransomware u otro ataque destructivo.
- Una persona con acceso exclusivo a sistemas críticos queda incapacitada.
5.2. — Roles de respuesta:
| Rol | Responsable primario | Suplente |
|---|---|---|
| Coordinador de Recuperación | CTO (Luishy Medina) | Gerente (Carlos Miranda Levy) |
| Comunicaciones externas | Gerente / CCO (Ydarlis Cabrera) | VP Law (Tanya Mejía-Ricart) |
| Restauración técnica | CTO | Segundo ingeniero designado |
| Notificación legal / regulatoria | VP Law (Tanya Mejía-Ricart) | Gerente |
5.3. — Pasos de activación:
- Detección y verificación (0–15 min): Confirmar que el evento es real y no una falsa alarma. Documentar hora de detección.
- Notificación interna (15–30 min): Alertar a los roles de respuesta vía canal de emergencia (ver sección 6). Gerente y CTO deben confirmar recepción.
- Evaluación de impacto (30–60 min): Determinar sistemas afectados, alcance de pérdida de datos, usuarios impactados y causa raíz provisional.
- Activación del DRP (60 min): Si el impacto supera el umbral RTO, el Coordinador de Recuperación declara formalmente el evento como “Desastre Activo” y activa los procedimientos de recuperación correspondientes.
- Ejecución de recuperación: Seguir los pasos técnicos del escenario correspondiente (sección 4). Actualizar el canal de incidentes cada 60 minutos.
- Verificación y validación: Antes de declarar la recuperación completa, verificar la integridad de los datos y el funcionamiento de los servicios.
- Comunicación de restauración: Notificar a los usuarios y clientes afectados que el servicio ha sido restaurado.
- Post-mortem (dentro de 72 horas): Redactar informe con causa raíz, cronología, impacto y acciones correctivas. Archivar en el sistema de gestión de incidentes.
6. Plan de Comunicaciones
6.1. — Canal de emergencia primario: Canal privado en la herramienta de mensajería corporativa (Slack / Google Chat) denominado #dr-emergencia con alertas habilitadas 24/7 para los miembros del equipo de respuesta.
6.2. — Canal de emergencia secundario (si lo primario falla): WhatsApp / llamada telefónica directa. Los números de contacto de emergencia de cada miembro clave están almacenados en la guía de contactos de DR (documento separado, acceso restringido a socios).
6.3. — Comunicación a clientes:
- Primera notificación: dentro de 4 horas desde la declaración del evento como desastre activo.
- Canal: correo electrónico desde
operaciones@lawra.coma los clientes afectados. - Mensaje mínimo: qué está afectado, qué se está haciendo, ETA estimado de resolución.
- Actualizaciones subsiguientes: cada 2–4 horas mientras el evento esté activo.
6.4. — Comunicación regulatoria: Si el evento implica violación de datos personales, la VP Law activa el protocolo de notificación a la Agencia de Protección de Datos conforme a la Ley 172-13 (plazo: 72 horas desde conocimiento del breach). Ver incident-response-plan.
7. Cadena de Suplencia y Personas Clave
7.1. En caso de incapacidad del Gerente principal (Carlos Miranda Levy), la siguiente en asumir la coordinación operativa es Tanya Mejía-Ricart (VP Law & Regulations).
7.2. Las credenciales de acceso de emergencia (break glass) para sistemas críticos están almacenadas en un sobre sellado físico custodiado por dos socios diferentes, requiriéndose la presencia de ambos para su apertura. Procedimiento detallado en access-control-policy.
7.3. Lawra reconoce el riesgo de dependencia de personal clave y se compromete a:
- Mantener documentación técnica actualizada (wikis, runbooks) accesible a cualquier socio autorizado.
- Rotar el conocimiento de los sistemas críticos entre al menos dos personas.
- Revisar la cobertura de conocimiento técnico de forma semestral.
8. Ejercicios y Pruebas
8.1. — Prueba de restauración de backups: trimestral (ver backup-recovery-policy).
8.2. — Tabletop exercise (TTX): semestral. Ejercicio de simulación en mesa donde el equipo de respuesta recorre un escenario de desastre de forma teórica, validando los procedimientos y actualizando el playbook. Participantes mínimos: CTO + Gerente + VP Law. Resultado documentado con hallazgos y acciones de mejora.
8.3. — Simulacro técnico: anual. Activación controlada del DRP sobre un ambiente de staging para verificar que los procedimientos técnicos de recuperación funcionan como se espera. Resultado documentado.
8.4. Los resultados de los ejercicios son revisados por la Asamblea en la reunión trimestral de cumplimiento.
9. Mantenimiento del Plan
9.1. El DRP se revisa y actualiza:
- Anualmente de forma programada.
- Cuando se incorpora un nuevo sistema de criticidad Media o superior.
- Tras cualquier activación real del plan (en el post-mortem correspondiente).
- Cuando cambian los proveedores de infraestructura crítica.
9.2. El CTO es responsable de mantener este documento actualizado y de asegurar que el equipo conozca los procedimientos actuales.
10. Referencias Normativas y Técnicas
- Ley No. 172-13 (R.D.) — Protección de Datos Personales (obligaciones de disponibilidad y notificación de brechas)
- Ley No. 53-07 (R.D.) — Crímenes y Delitos de Alta Tecnología
- NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems
- ISO/IEC 27031:2011 — Guidelines for information and communications technology readiness for business continuity
- SOC 2 Trust Services Criteria: CC9.1 (identificación y mitigación de riesgos), A1.2 (capacidad y disponibilidad), A1.3 (recuperación de infraestructura)
incident-response-plan— Plan de Respuesta a Incidentes de Lawra, S.R.L.backup-recovery-policy— Política de Respaldo y Recuperación
11. Revisión y Modificación
Esta política se revisa anualmente o ante cambios materiales en operaciones, infraestructura o normativa. Modificaciones requieren aprobación del Gerente; modificaciones materiales requieren aprobación de la Asamblea.
Próxima revisión: [fecha de adopción + 12 meses].
Adoptada por la Asamblea General de Socios de LAWRA, S.R.L. en fecha [__], conforme consta en el Libro de Actas.
Por LAWRA, S.R.L. — Gerente
Comments
Loading comments...