Seguridad informática para pymes: post‑entrega

Cuando la firma del contrato se convierte en un apretón de manos, la verdadera prueba comienza: ¿qué pasa después de que el sistema de seguridad informática para pymes está en producción? En este artículo encontrarás los puntos críticos que debes vigilar para que la solución no se convierta en una carga inesperada.

Lo que empieza el día de la entrega

Nadie menciona que el día de la entrega no es el “fin” del proyecto, sino el inicio de una fase de transición. En ese momento el proveedor debe:

• Transferir todos los accesos y credenciales a tu equipo de TI o al responsable designado.
• Entregar la documentación completa: arquitectura, diagramas de red, políticas de contraseñas y guías de recuperación.
• Ejecutar una auditoría de seguridad informática preliminar para validar que los controles de acceso y los permisos de usuarios están configurados según lo acordado.
• Definir un plan de pruebas de aceptación (UAT) con criterios medibles, por ejemplo, que el 99,5 % de los intentos de acceso no autorizados sean bloqueados en la primera capa.

Esta lista suele quedar fuera del contrato porque se asume que ya está cubierta en la fase de implementación. Sin embargo, sin estos entregables claros, la empresa se queda sin referencias para gestionar incidentes futuros.

Quién responde cuando algo falla

Una vez que el sistema está en producción, la responsabilidad se reparte entre tres actores principales:

1. El proveedor – debe garantizar un tiempo de respuesta máximo de 4 horas para incidentes críticos (pérdida total de acceso, brecha de datos) y 24 horas para incidentes de nivel medio (fallos en la generación de logs, alertas falsas). Estas condiciones deben estar plasmadas en un anexo de nivel de servicio (SLA).
2. Tu equipo interno – es quien debe reportar el incidente con la información requerida (fecha, hora, logs, usuarios involucrados). Sin un reporte estructurado, el proveedor no puede cumplir el SLA.
3. El responsable de seguridad – debe validar que el incidente ha sido cerrado mediante una revisión post‑mortem y actualizar la documentación de control de accesos y permisos.

Exigir por escrito:

• Plazos de respuesta y resolución por tipo de incidente.
• Un canal de comunicación único (por ejemplo, ticketing system) y la persona de contacto del proveedor.
• Un informe de cierre que incluya causas raíz y acciones preventivas.

Mantenimiento: qué es y qué no

El mantenimiento suele confundirse con “cualquier trabajo que haga el proveedor”. En realidad, hay tres niveles diferenciados:

• Correctivo – reparación de fallos que impiden el funcionamiento normal (p.ej., un módulo de autenticación que deja de validar tokens). Se factura habitualmente dentro del contrato de soporte.
• Evolutivo – incorporación de nuevas funcionalidades o ajustes regulatorios (como cambios en la normativa de la SUNAT). Requiere un presupuesto adicional y un plazo de entrega que suele oscilar entre 2 y 6 semanas, según la complejidad.
• Preventivo – actividades planificadas que no reparan un problema, sino que lo evitan: actualizaciones de parches, revisión de listas de permisos, pruebas de restauración de copias de seguridad. Estas se programan cada 30 días y forman parte del acuerdo de mantenimiento.

Lo que no está incluido es la re‑arquitectura completa del sistema o la migración a otra plataforma sin un nuevo contrato. Si el cliente solicita una transformación mayor, se trata como un proyecto nuevo.

Cómo evitar quedar atrapado

1. Accesos y propiedad – Asegúrate de que el contrato especifique la transferencia total de la propiedad intelectual del código y de los scripts de automatización. El proveedor debe entregar los repositorios (Git, SVN) con historial completo.
2. Copias de seguridad para empresas – Implementa una política de backup 3‑2‑1: tres copias, en dos medios diferentes, una fuera del sitio. Verifica mensualmente la restauración de al menos el 95 % de los datos críticos.
3. Documentación viva – La documentación no debe quedar estática. Usa un wiki interno donde cada cambio en permisos o configuraciones se registre con fecha y responsable.
4. Auditoría de seguridad informática – Programa auditorías externas cada 12 meses. El informe debe incluir:
   • Evaluación de control de accesos y permisos de usuarios.
   • Verificación de la integridad de los backups.
   • Recomendaciones de mejora y plan de acción.
5. Cláusula de salida – Define en el contrato un proceso de transición en caso de rescisión: plazo de 30 días para la entrega de todos los artefactos y asistencia para migrar a otro proveedor.

Al cumplir con estos puntos, tu empresa mantiene el control y evita depender exclusivamente del proveedor para operar la solución de seguridad.

Conclusión

Quien ha llegado hasta aquí entiende que la entrega de un proyecto de seguridad informática para pymes es solo el primer paso. El éxito depende de que la empresa establezca claramente quién responde ante fallos, qué incluye el mantenimiento y cómo protege la propiedad del sistema mediante accesos, copias y auditorías. Con estos mecanismos, la solución seguirá protegiendo tu negocio sin sorpresas inesperadas.