Política de Contingencia y Continuidad del Negocio

Yisrael Technology SRL
Versión: 1.0 — Draft
Fecha: 2026-05-08
Próxima revisión: 2027-05-08

1. Propósito

Esta Política define los procedimientos para mantener la continuidad del servicio ecf-api ante eventos disruptivos, minimizando el impacto a clientes y cumpliendo los compromisos de SLA.

2. Alcance

Cubre los siguientes escenarios:

1. Caída total del servicio (servidor caído)
2. Caída de la base de datos (Neon)
3. Caída de DGII (los servicios DGII no responden)
4. Compromiso de seguridad (data breach, credenciales filtradas)
5. Pérdida de personal clave
6. Eventos de fuerza mayor (huracán, apagón nacional, falla de infraestructura cloud)

3. Compromisos cuantificables

4. Mecanismos preventivos

4.1 Redundancia y respaldos

• Base de datos: Neon PostgreSQL con PITR (Point-in-Time Recovery) hasta 24h en plan free, configurable a 30 días en plan paid
• Backups completos: semanales a S3 STANDARD_IA, retención 7 años con tier-aware lifecycle (Glacier IR → Deep Archive)
• Versionado de código: GitHub con historial completo
• Versionado de configuración: Git + GitHub Secrets para variables de entorno

4.2 Monitoreo

• Endpoint /status público con métricas en tiempo real (24h)
• Health check /health/full que verifica DB y env vars críticos
• Alerter automático: errores 5xx envían email a info@yisraeltech.com
• Logs estructurados en audit_logs y dgii_webhook_logs consultables en cualquier momento

4.3 Validación de respaldos

• Cada backup automático ejecuta pg_restore --list para validar integridad
• Drill semestral documentado con restore real en ambiente temporal (docs/backup-restore.md sección 6)

4.4 Hardening del servicio

• Rate limiting global (@nestjs/throttler)
• Security headers (Helmet) — HSTS, X-Frame-Options, etc.
• Cifrado at-rest de datos sensibles (AES-256-GCM)
• TLS 1.2+ obligatorio en producción

5. Procedimientos de respuesta por escenario

5.1 Caída total del servicio

Detección: falla en monitoreo /status, alertas externas, reportes de clientes.

Procedimiento (RTO objetivo 4 horas):

1. 0–10 min: confirmar caída desde múltiples ubicaciones / monitor externo
2. 10–30 min: publicar incidente en /status con ETA preliminar; notificar clientes vía email
3. 30 min – 2 h: ejecutar diagnóstico, redeploy o failover a réplica
4. 2 h – 4 h: restaurar servicio; ejecutar smoke tests
5. Post-incidente: post-mortem documentado en docs/legal/incidentes/YYYY-MM-DD.md

5.2 Caída de la base de datos (Neon)

Detección: error en /health/full con database.status: down.

Procedimiento:

1. Confirmar estado en https://neon.tech/status
2. Si es problema de Neon: esperar restauración de su parte; comunicar a clientes
3. Si es problema de credenciales: rotar DATABASE_URL desde GitHub Secrets
4. Si es corrupción: ejecutar restore PITR desde portal Neon (RTO < 30 min)
5. Si Neon no responde por > 1 hora: ejecutar restore desde S3 a nueva instancia

5.3 Caída de DGII

Detección: webhooks DGII fallan masivamente, o tasa de aceptación cae.

Procedimiento — Modo Contingencia DGII:

1. Verificar estado oficial DGII (https://dgii.gov.do)
2. Activar modo contingencia DGII según Norma 01-2020:
   • Las emisiones se acumulan localmente con estado PENDIENTE_ENVIO_DGII
   • Se reintentarán automáticamente cuando DGII responda (poller cada 5 min)
3. Notificar a clientes vía email + status page que DGII está caído (no es nuestra culpa)
4. Tras restauración: el EmisionStatusPoller reenvía pendientes en orden FIFO

5.4 Compromiso de seguridad

Detección: alerta de acceso no autorizado, patrón anómalo en audit_logs, reporte externo.

Procedimiento (acción inmediata < 1 hora):

1. Contener: revocar todas las API keys sospechosas (PATCH /v1/admin/empresas/:id/api-keys/:keyId/revocar)
2. Aislar: cambiar DATABASE_URL, CRYPTO_MASTER_KEY, credenciales AWS
3. Investigar: analizar audit_logs y dgii_webhook_logs para alcance del compromiso
4. Notificar:
   • Clientes afectados: dentro de 72 horas (Ley 172-13)
   • DGII: si los datos fiscales fueron tocados, inmediato
   • Autoridad competente Ley 172-13: si aplica
5. Remediar: parchar vulnerabilidad, rotar todas las credenciales, post-mortem público

5.5 Pérdida de personal clave

Dado que actualmente Alexander Ferreras es el único responsable técnico, se establecen los siguientes mitigantes:

• Documentación completa: este repositorio + docs/ debe poder permitir a otro ingeniero NestJS senior tomar control en < 1 día
• Acceso de emergencia: credenciales críticas guardadas en gestor de contraseñas con acceso a [persona de respaldo a designar]
• Continuidad legal: el Authorized Agent del LLC tiene autoridad para designar nuevo administrador

5.6 Eventos de fuerza mayor

Si la infraestructura cloud (Neon, AWS) cae globalmente:

1. La situación queda fuera del control de Yisrael Technology SRL
2. Se notifica a clientes la naturaleza del evento
3. Se mantiene comunicación periódica (cada 2 horas durante el incidente)
4. Una vez restaurada la infraestructura, se ejecutan smoke tests antes de declarar servicio operativo
5. Esta situación está cubierta por el SLA como exclusión (sección 8 del SLA)

6. Plan de comunicación durante incidentes

Template de comunicación de incidente:

Asunto: [INCIDENTE P1] Servicio ecf-api con interrupción parcial

Estimado cliente:

Le informamos que a las HH:MM AST detectamos una interrupción
en el servicio ecf-api afectando [descripción]. Nuestro equipo
está trabajando en la restauración con ETA de XX horas.

Impacto en su operación: [descripción]
Workaround temporal: [si aplica]
Próxima actualización: HH:MM AST

Status en tiempo real: https://api.yisraeltech.com/status

Atte,
Equipo Yisrael Technology SRL

7. Cumplimiento DGII bajo contingencia

Conforme al Instructivo de Contingencia DGII, ante interrupción del servicio:

• Los e-CF generados durante la contingencia mantienen su validez fiscal
• El plazo máximo para reenvío a DGII es de 24 horas tras restauración del servicio
• Se mantiene bitácora de los e-CF emitidos en modo contingencia
• DGII puede requerir explicación formal del evento; Yisrael Technology SRL debe responder dentro de 5 días hábiles

8. Drills y pruebas

9. Lecciones aprendidas e historial

Cualquier incidente real (no drill) se documenta en docs/legal/incidentes/YYYY-MM-DD-titulo.md con:

• Timeline detallado
• Root cause
• Acciones correctivas
• Mejoras a esta política

10. Aprobación y revisión

Esta Política se revisa anualmente o tras cualquier incidente que requiera ajuste.