Remediación
Convierta Findings gobernados en trabajo con responsable sin perder el contexto.
Un Finding sin responsable llega a la siguiente auditoría. OTReady lo lleva, mediante una decisión de tratamiento explícita, a trabajo seguido, mantiene unida la arquitectura de la que trata y lo cierra solo cuando el trabajo ha sido realmente revisado.
- Un tablero canónico: marco y fuente son filtros, no productos separados
- Una tarea conserva sus Findings, su arquitectura afectada y su evidencia
- La revisión precede a la aprobación, y el cierre tiene una regla
Ciclo de vida
Cada paso es la decisión de alguien.
- Finding gobernado
- Decisión de tratamiento
- Remediar
- Tarea de remediación
- Trabajo
- En revisión
- Aprobada
- Cierre del Finding
Ninguna fuente de evaluación crea una tarea de remediación directamente, ni tampoco una alerta operativa. El trabajo existe porque una decisión de tratamiento lo dispuso.
En revisión y aprobada son dos afirmaciones distintas.
Esa distinción es la razón de tener un paso de revisión: en una habla quien implementa, en la otra quien revisa.
Aprobada significa que el trabajo de remediación fue revisado y aceptado. No es una declaración de que un control, un marco, un activo o un proyecto cumplan.
En revisión
Quien hizo el trabajo lo ha ofrecido para revisión. Es una afirmación del implementador y no cambia nada del Finding hasta que un revisor actúa.
Aprobada
La implementación ha sido verificada y aceptada por un revisor. Este es el estado que puede contribuir a cerrar el Finding correspondiente.
El tablero
Un tablero, con filtros, no un tablero por marco.
Una tarea pertenece exactamente a un marco y nunca cuenta en otro, pero eso es aislamiento dentro de un tablero canónico y no una razón para tener varios. Marco y fuente son vistas del mismo trabajo.
El tablero lleva la posición, los recuentos por estado, el desglose de severidad y las brechas que aún no se han planificado como trabajo, junto a las propias columnas.
Contexto de la tarea
Qué lleva consigo una tarea.
Mantener el contexto en la tarea tiene un objetivo: quien la recoja no debería tener que reconstruir por qué existe.
- Findings enlazados
- Qué Findings gobernados responde este trabajo. Una tarea puede atender varios, y un Finding puede necesitar varias tareas.
- Arquitectura afectada
- El Site, Zone, Subzone, Conduit, Channel o activo del que trata el trabajo: el objeto mismo, no una nota de texto libre.
- Fuente y marco
- De dónde vino el Finding subyacente y a qué marco pertenece la tarea.
- Tratamiento
- La decisión que creó el trabajo en primer lugar.
- Responsable y plazo
- Una persona asignada, una fecha límite y un estado de retraso visible.
- Actividad y evidencia
- Un historial de mensajes solo-añadir, y la evidencia ofrecida para la verificación, de modo que una aprobación no pueda cambiar en silencio después.
El cierre es una regla, no un botón.
Un Finding queda remediado cuando el trabajo de remediación enlazado cumple la regla de cierre: no puede simplemente afirmarse. Un Finding puede relacionarse con varias tareas y una tarea puede responder a varios Findings, así que el cierre se evalúa sobre los enlaces y no se infiere de la tarea que se terminó la última.
Hoy no hay integración nativa con sistemas de tickets.
El trabajo se sigue en el propio tablero de OTReady. Existe una vía de API genérica para conectar otros sistemas, y se describe exactamente como eso. No hay integración con Jira, ni con ServiceNow, ni conector nativo con ningún producto de tickets: nombrar uno aquí sería describir algo que no existe.
Capacidades relacionadas
Findings y evidencia
De dónde viene el trabajo, y la evidencia que lo verifica.
Gobierno
Quién puede aprobar, y qué registra el historial de auditoría.
Informes
Cómo llega el progreso de remediación a un registro emitido.
Vea trabajo que conserva su contexto.
Siga un Finding desde una decisión de tratamiento hasta una tarea revisada y aprobada en un tablero real.