Incidentes y soporte¶

Objetivo¶

Esta página ofrece un camino común para reportar problemas, abrir solicitudes de soporte y responder a incidentes en Cafh.

Por qué importa esta página¶

Cuando algo falla, las personas necesitan una ruta que puedan recordar. Un flujo de reporte sereno reduce demoras, cuida la evidencia y ayuda a Cafh a mantenerse coordinada con proveedores y responsables internos. También convierte un momento tenso en un proceso compartido, en lugar de reacciones aisladas. Un buen registro ayuda al comité a aprender de cada caso y a reconocer patrones con el tiempo.

Riesgos que esta página busca reducir¶

• Respuesta tardía
• Pérdida de evidencia
• Caídas largas
• Confusión pública
• Repetición del mismo incidente
• Daño mayor sobre datos, miembros o marca

Qué debe reportarse¶

El umbral para reportar debe quedar bajo. Cafh gana más con un aviso temprano que luego resulta menor que con un aviso tardío que llega tras un daño mayor. Las personas no necesitan prueba completa antes de reportar una sospecha.

• Caída del sitio web
• Caída del área de miembros
• Compromiso de cuenta
• Phishing o acceso sospechoso
• Pérdida o robo de dispositivo personal usado para tareas de Cafh
• Sospecha de compromiso de un dispositivo personal usado para tareas de Cafh
• Abuso de una cuenta oficial de correo
• Toma de control de red social
• Abuso de una cuenta oficial de red social
• Exposición o pérdida de datos
• Falla grave en aplicación interna
• Falla de un proveedor en un servicio contratado

Ruta de reporte¶

1. Enviar el problema al comité de inmediato.
2. Registrar nombre del servicio, fecha e impacto visible.
3. Marcar el caso como urgente o estándar.
4. Nombrar a la persona que hablará con el proveedor.
5. Registrar cada acción y cada respuesta del proveedor.

El comité debe definir y mantener la vía de entrada para estos reportes. Esa vía puede ser un correo compartido, un formulario, una herramienta de tickets u otro canal aprobado. La vía elegida debe ser conocida, fácil de encontrar y revisada con una frecuencia regular. Una vía simple y confiable vale más que una herramienta compleja.

Diagrama del proceso¶

Este diagrama muestra un camino simple desde la entrada hasta el cierre.

flowchart LR
  A["Llega el problema o la solicitud"] --> B["Abrir registro del caso"]
  B --> C{"Es urgente o estándar?"}
  C -- "Urgente" --> D["Iniciar contención"]
  C -- "Estándar" --> E["Revisar y asignar responsable"]
  D --> F["Contactar a proveedor o responsable interno"]
  E --> F
  F --> G["Seguir acciones y novedades"]
  G --> H{"Está resuelto?"}
  H -- "No" --> I["Escalar y actualizar registro"]
  I --> G
  H -- "Sí" --> J["Registrar causa, acciones y seguimiento"]
  J --> K["Cerrar caso"]

Diagrama de estados¶

Este ejemplo ayuda a mantener un lenguaje común para el estado de cada caso.

stateDiagram-v2
  [*] --> Nuevo
  Nuevo --> Triaje
  Triaje --> EnTrabajo
  Triaje --> EsperaProveedor
  EsperaProveedor --> EnTrabajo
  EnTrabajo --> Monitoreo
  Monitoreo --> Cerrado
  EnTrabajo --> Escalado
  Escalado --> Monitoreo
  Triaje --> Cerrado

Casos urgentes¶

Urgente significa que el daño está activo o puede crecer rápido. La primera meta no es una explicación completa. La primera meta es contención, registro y una persona clara para el siguiente paso.

Los casos urgentes incluyen:

• Sitio público caído
• Área de miembros caída
• Compromiso de cuenta
• Exposición de datos
• Uso indebido de marca en un canal oficial

Para casos urgentes:

• Reportar el mismo día
• Contactar al proveedor por la vía más rápida aprobada
• Limitar acceso o bajar el servicio si hace falta
• Avisar a la conducción del comité de inmediato

Tipos de caso e información requerida¶

No todos los casos piden la misma velocidad ni los mismos campos. Un tipo de caso claro ayuda al comité a pedir los datos correctos sin cargar de más a quien reporta.

Usar un registro claro para cada tipo de caso.

Procedimiento ante pérdida o compromiso de dispositivo personal¶

Usar esta ruta para un teléfono o computadora personal perdido, robado o comprometido que se haya usado para tareas de Cafh. La acción en el mismo día importa mucho aquí. La demora puede dejar sesiones abiertas, datos expuestos o rutas de recuperación en manos equivocadas.

1. Detener de inmediato el trabajo de Cafh en ese dispositivo.
2. Desconectar el dispositivo de la red si existe sospecha de compromiso.
3. Avisar al comité el mismo día.
4. Desde un dispositivo limpio, cambiar contraseñas de las cuentas de Cafh usadas allí.
5. Revocar sesiones o tokens activos en servicios que lo permitan.
6. Registrar qué datos, cuentas o apps de Cafh estaban en el dispositivo.
7. Rotar credenciales compartidas o rutas de recuperación que puedan haber quedado expuestas.
8. Definir si el caso también es incidente de datos, incidente de cuenta o caso con proveedor.
9. Restituir acceso sólo tras completar la revisión.

Diagrama de respuesta ante incidente de dispositivo personal¶

flowchart LR
  A["Dispositivo personal perdido, robado o comprometido"] --> B["Detener trabajo de Cafh en ese dispositivo"]
  B --> C["Reportar al comité el mismo día"]
  C --> D["Usar un dispositivo limpio"]
  D --> E["Cambiar contraseñas y revocar sesiones"]
  E --> F["Registrar cuentas, apps y archivos locales"]
  F --> G{"Hay datos restringidos en riesgo?"}
  G -- "Sí" --> H["Abrir revisión de incidente de datos"]
  G -- "No" --> I["Seguir tareas y restituir acceso"]
  H --> I

Modelo de solicitud estándar¶

Usar este formato para un caso normal de soporte.

Modelo de incidente urgente¶

Usar este formato para caídas, compromisos o eventos de seguridad.

Modelo de reporte de abuso¶

Usar este formato para mal uso de correo oficial, red social o canal de marca.

Modelo de incidente de datos¶

Usar este formato para pérdida, exposición o compartición errónea de datos.

Modelo de reporte de seguridad en dispositivo personal¶

Usar este formato para un dispositivo personal perdido, robado o comprometido.

Reporte de abuso¶

Usar esta ruta para abuso o mal uso de correo oficial o de una cuenta oficial de red social. Los casos de abuso afectan confianza tanto como los sistemas. Una publicación falsa, una respuesta hostil o una suplantación pueden expandirse antes de que la corrección técnica termine. El reporte debe cuidar evidencia e impacto público desde el inicio.

• Registrar nombre de la cuenta
• Registrar fecha y hora
• Guardar captura, copia del mensaje o enlace
• Registrar quién reportó el caso
• Registrar impacto público e impacto de marca
• Enviar el caso al comité para revisión
• Pausar acceso o publicación con riesgo alto

Pedidos estándar¶

El soporte estándar igual necesita disciplina. Un mensaje vago trae demora, preguntas repetidas y seguimiento débil. Una solicitud clara ahorra tiempo para Cafh y para el proveedor.

• Enviar una solicitud clara
• Incluir pasos para repetir el problema
• Incluir capturas o enlaces
• Incluir fecha deseada e impacto del problema
• Esperar revisión del comité antes del contacto con proveedor

Tabla modelo de registro de casos¶

Esta tabla puede vivir en una hoja compartida o más adelante en un servicio de solicitudes.

Cierre¶

El cierre no llega sólo cuando la herramienta vuelve a funcionar. El cierre llega después de registrar qué falló, qué cambió y qué queda por revisar.

• Registrar causa raíz
• Registrar acciones del proveedor
• Registrar cambios de cuenta o de contraseña
• Registrar tareas de seguimiento
• Registrar aprendizajes