Gestión de incidentes en outsourcing: prioridad, escalado y plan de respuesta
Un error de envío, la pérdida de acceso, un destinatario equivocado o un proceso detenido requieren más que un ticket. Cliente y proveedor necesitan un único plan de respuesta.
En outsourcing, un incidente nunca permanece únicamente «del lado del proveedor». El cliente sufre el resultado: documentos que no se enviaron a tiempo, correspondencia entregada al destinatario equivocado, escaneos no disponibles o un informe que no cuadra con el número de expedientes. Si ambas partes utilizan definiciones distintas de urgencia, la primera hora se pierde decidiendo quién debe actuar.
Un modelo sólido combina respuesta operativa, seguridad de la información, protección de datos, comunicación y decisiones de negocio. NIST SP 800-61 Rev. 3 recomienda integrar la respuesta a incidentes en la gestión de riesgos; el NCSC británico la conecta con la continuidad de negocio y la gestión de crisis. Esto exige un procedimiento coordinado entre cliente y proveedor.
¿Qué se considera incidente en un servicio externalizado?
Conviene separar cuatro categorías: calidad (por ejemplo, impresión incorrecta), plazo (envío tardío), disponibilidad (caída de sistema o falta de recursos) y seguridad (pérdida, alteración o divulgación de información). Un evento puede abarcar varias. Una carta enviada a una dirección errónea es un fallo de producción y una posible violación de datos personales.
El procedimiento también debe registrar los casi incidentes. Si una muestra detiene una versión incorrecta de 10.000 documentos antes del envío, no se ha producido la entrega, pero existe una debilidad de control que debe corregirse.
1. Acordar una matriz P1–P4
La prioridad debe combinar impacto y urgencia. P1 es crítico: el proceso está parado, puede afectar a muchas personas o a datos sensibles, o existe riesgo para un plazo legal. P2 tiene un impacto alto pero acotado. P3 es local y dispone de una solución alternativa. P4 es una desviación menor sin efecto material.
No clasifique únicamente por el número de registros. Un sobre con datos de categoría especial puede suponer más riesgo que cien folletos comerciales retrasados. La matriz debe incluir ejemplos del proceso, quién puede elevar la prioridad y los tiempos de acuse, contención, alternativa y siguiente actualización.
2. Definir cuándo empieza el reloj
Muchas disputas de SLA nacen de un inicio ambiguo. El reloj debe comenzar cuando cualquiera de las partes detecta el evento o cuando el aviso llega al canal acordado, no cuando el especialista adecuado lee el correo.
El primer aviso debe indicar hora de detección, proceso y lote, síntoma, alcance conocido, impacto posible, medidas realizadas y responsable. La falta de información completa no debe retrasar la alerta. Una comunicación inicial puede ser provisional si separa hechos confirmados de hipótesis.
3. Separar funciones de cliente y proveedor
Para P1 y P2 identifique cinco funciones: responsable del incidente, líder técnico u operativo, propietario de negocio del cliente, contacto de seguridad o privacidad y responsable de comunicación. En una organización pequeña una persona puede cubrir varias funciones, pero las responsabilidades deben ser visibles.
El proveedor suele detener la operación defectuosa, proteger materiales, determinar el alcance y preparar una alternativa. El cliente decide prioridades, contacto con sus destinatarios y notificaciones. El acuerdo de encargo debe asegurar que el responsable del tratamiento reciba información suficiente para evaluar una violación de datos.
4. Planificar los primeros 60 minutos
- 0–15 minutos: confirmar recepción, contener la propagación y conservar evidencias.
- 15–30 minutos: asignar prioridad provisional y responsable; separar elementos seguros y potencialmente afectados.
- 30–60 minutos: definir alcance conocido, activar alternativa, avisar a las funciones necesarias y fijar la siguiente actualización.
La regla es contener primero sin destruir el rastro. Sobrescribir un archivo, borrar una cola o repetir la producción sin conservar identificadores puede impedir determinar el alcance.
5. Mantener un único registro de decisiones y evidencias
Cada incidente necesita un identificador y una cronología: quién lo detectó, qué datos se comprobaron, cuándo cambió la prioridad, quién aprobó la alternativa y qué comunicaciones se enviaron. Según el proceso, adjunte versiones, cantidades de control, logs, fotografías del lote inmovilizado, justificantes del operador y excepciones.
El registro evita instrucciones contradictorias y facilita el relevo entre turnos. Limite el acceso a las evidencias y defina su conservación según el caso y la política de retención.
6. Establecer un ritmo de comunicación
La actualización debe responder: qué ocurrió, qué está confirmado, qué se desconoce, cuál es el impacto, qué se hace ahora y cuándo llegará el siguiente comunicado. En P1 puede ser necesario actualizar cada 30–60 minutos incluso sin avances decisivos.
Separe la comunicación de trabajo de los mensajes a clientes, interesados, autoridades o medios. El texto externo debe basarse en hechos confirmados y una decisión autorizada. El proveedor no debe contactar a los interesados salvo que el contrato y las instrucciones del responsable lo permitan.
7. Incluir plazos legales sin aplicarlos de forma automática
El RGPD exige que el encargado informe al responsable de una violación de datos personales sin dilación indebida. Cuando procede, el responsable notifica a la autoridad sin dilación indebida y, cuando sea posible, dentro de las 72 horas desde que tuvo constancia. No son tres días para esperar: la recopilación de información empieza inmediatamente.
El artículo 23 de NIS2 prevé para las entidades incluidas una notificación por fases, con alerta temprana en 24 horas y notificación del incidente en 72 horas. La aplicación depende del sector, el estatus de la entidad, el derecho nacional y normas sectoriales. El plan debe indicar quién evalúa la obligación.
8. Cerrar solo después de la revisión posterior
Restablecer el servicio no termina el trabajo. En pocos días haga una revisión sin culpabilizar: qué control debía impedir el evento, por qué falló, qué lo detectó y qué redujo el daño. Distinga causa inmediata, condiciones contribuyentes y causa sistémica.
Cada acción correctiva necesita responsable, fecha y prueba de aceptación. «Formar al equipo» es insuficiente si faltaba control de versiones. Puede ser más eficaz bloquear la producción sin dos identificadores coincidentes, automatizar la conciliación o exigir una muestra para un nivel de riesgo.
¿Cómo medir la preparación y la eficacia?
Además del SLA, mida tiempo de detección (MTTD), acuse e inicio de acciones, contención, restauración, puntualidad de comunicados, registros afectados, recurrencia y porcentaje de acciones correctivas cerradas en fecha. Un cierre rápido engaña si el incidente vuelve.
Playbook mínimo cliente–proveedor
- Catálogo de eventos y matriz P1–P4.
- Canal de emergencia fuera de horario para eventos críticos.
- Funciones, sustitutos y contactos actualizados.
- Formulario inicial y plantilla de actualización.
- Reglas de conservación de evidencias y datos.
- Ruta de decisiones legales, sectoriales y de comunicación.
- Alternativas para procesos críticos.
- Plantilla de revisión y registro de acciones.
- Ejercicio después de un cambio material de proceso o proveedor.
Fuentes y lectura adicional
- NIST SP 800-61 Rev. 3.
- Guía de gestión de incidentes del NCSC.
- Reglamento (UE) 2016/679 (RGPD), especialmente el artículo 33.
- Directiva (UE) 2022/2555 (NIS2), especialmente el artículo 23.
Este material práctico no sustituye el análisis jurídico o sectorial. Adapte los requisitos a los datos, el proceso, el contrato y la normativa aplicable.
Preguntas frecuentes
¿Todo error operativo es un incidente de seguridad?
No. Un incidente operativo puede afectar al plazo, la calidad o la disponibilidad; uno de seguridad afecta a la confidencialidad, integridad o disponibilidad de la información. Un mismo evento puede pertenecer a ambas categorías.
¿Quién debe asignar la prioridad?
El proveedor debe hacer la primera clasificación con la matriz acordada, pero el cliente debe poder elevarla cuando conoce un impacto empresarial, legal o reputacional que el equipo operativo no ve.
¿Basta con el SLA?
No. El SLA fija tiempos y niveles de servicio. El plan de incidentes también debe definir funciones, canales, primer comunicado, conservación de evidencias, decisiones legales y cierre de acciones correctivas.
¿Cuándo hace falta una revisión posterior?
Después de incidentes relevantes o repetitivos y cuando el evento revela una debilidad de control. La revisión debe centrarse en el mecanismo del fallo y en el cambio de proceso, no en buscar culpables.