Anexo 1.2 Documentación DGII — Proveedores de Facturación Electrónica

Política de Contingencia

Última actualización: 10 de abril de 2026 · SSD Smart Software Development SRL (RNC: 131460941)

1. Objetivo

Definir los procedimientos y controles para asegurar la continuidad operativa de la plataforma ECF SSD ante eventos disruptivos, minimizando el impacto en la emisión, recepción y consulta de Comprobantes Fiscales Electrónicos (E-CF).

2. Escenarios de Contingencia

2.1 Falla en servicios de la DGII

Cuando los servicios web de la DGII no están disponibles (mantenimiento programado o fallas).

Acción: Los comprobantes se encolan automáticamente en el sistema de mensajería (RabbitMQ/Azure Service Bus) y se reintenta el envío con backoff exponencial hasta que el servicio se restablezca. El usuario es notificado del estado pendiente.

2.2 Falla en base de datos

Interrupción del servicio PostgreSQL.

Acción: Failover automático a réplica de lectura. Backups automáticos cada 24 horas con retención de 30 días. Point-in-time recovery disponible dentro de la ventana de retención.

2.3 Falla en servicios de aplicación

Caída de APIs o workers de procesamiento.

Acción: Azure Container Apps escala automáticamente y reinicia contenedores fallidos. Health checks cada 30 segundos. Si un servicio no responde en 3 intentos consecutivos, se reemplaza automáticamente.

2.4 Falla en almacenamiento

Interrupción en Azure Storage (archivos XML, certificados, documentos).

Acción: Azure Storage con redundancia geográfica (GRS). Los archivos se replican automáticamente a una región secundaria. RPO < 15 minutos.

2.5 Compromiso de seguridad

Detección de acceso no autorizado o vulnerabilidad explotada.

Acción: Activación del plan de respuesta a incidentes (ver Política de Seguridad, sección 8). Aislamiento inmediato del componente afectado. Rotación de credenciales comprometidas.

2.6 Expiración de certificados digitales

Certificado .p12 del cliente próximo a vencer o vencido.

Acción: Alertas automáticas 30, 15 y 7 días antes del vencimiento. El sistema bloquea la emisión con certificados vencidos e indica al usuario cómo actualizar su certificado.

3. Indicadores de Recuperación

Indicador Objetivo
RTO (Recovery Time Objective)< 4 horas
RPO (Recovery Point Objective)< 1 hora
Disponibilidad objetivo99.9% mensual
Tiempo de detección< 5 minutos (monitoreo automatizado)

4. Backups y Recuperación

  • Base de datos: Backups automáticos diarios con retención de 30 días. Point-in-time recovery disponible.
  • Archivos (XML, certificados): Azure Storage con redundancia geográfica (GRS), replicación automática.
  • Configuración: Infraestructura como código (IaC) versionada en Git. Reproducible en < 2 horas.
  • Secretos: Azure Key Vault con versionado y políticas de acceso auditadas.

5. Comunicación

En caso de incidente que afecte la disponibilidad del servicio:

  • Notificación inicial por correo electrónico dentro de los primeros 30 minutos.
  • Actualizaciones de estado cada 2 horas durante el incidente.
  • Post-mortem publicado dentro de las 72 horas posteriores a la resolución.
  • Eventos programados de mantenimiento notificados con 48 horas de anticipación.

6. Pruebas

Los procedimientos de contingencia se prueban semestralmente, incluyendo: restauración de backups, failover de base de datos, escalamiento de contenedores y simulación de falla en servicios de la DGII.

Documentos Relacionados