diff --git a/build_pdf/redborder_manual_book/en.yml b/build_pdf/redborder_manual_book/en.yml
index ec801c90..fd70ffbd 100644
--- a/build_pdf/redborder_manual_book/en.yml
+++ b/build_pdf/redborder_manual_book/en.yml
@@ -32,6 +32,7 @@ nav:
   - manager/more_in_detail/ch4_5_views.md
   - manager/more_in_detail/ch4_12_anomalies.md
   - manager/more_in_detail/ch5_dashboards.md
+  - manager/more_in_detail/ch5_1_incidents.md
   - manager/platform_configurations/ch6_sensors.md
   - manager/platform_configurations/ch7_tools_and_admin.md
   - manager/platform_configurations/ch7_4_general_config.md
diff --git a/build_pdf/redborder_manual_book/es.yml b/build_pdf/redborder_manual_book/es.yml
index a9e7103b..3e9e808c 100644
--- a/build_pdf/redborder_manual_book/es.yml
+++ b/build_pdf/redborder_manual_book/es.yml
@@ -32,6 +32,7 @@ nav:
   - manager/more_in_detail/ch4_5_views.es.md
   - manager/more_in_detail/ch4_12_anomalies.es.md
   - manager/more_in_detail/ch5_dashboards.es.md
+  - manager/more_in_detail/ch5_1_incidents.es.md
   - manager/platform_configurations/ch6_sensors.es.md
   - manager/platform_configurations/ch7_tools_and_admin.es.md
   - manager/platform_configurations/ch7_4_general_config.es.md
diff --git a/docs/guides/use_cases/ch9_detect_eternalblue.es.md b/docs/guides/use_cases/ch9_detect_eternalblue.es.md
index f25493f4..fcd5c94e 100644
--- a/docs/guides/use_cases/ch9_detect_eternalblue.es.md
+++ b/docs/guides/use_cases/ch9_detect_eternalblue.es.md
@@ -1,8 +1,13 @@
-# Detectar un ataque de Eternalblue con Redborder
+# Detección de un ataque Eternalblue con Redborder
 
-En este caso, veremos cómo Redborder puede usar las reglas de Snort para detectar un ataque de *Eternalblue*.
+En este caso, veremos cómo gestionar un incidente de ataque *Eternalblue*.
 
-Todo comienza con un correo electrónico malicioso que contiene un *dropper* que instala un *ransomware*.
+!!! info "Tenga en cuenta..."
+    Este caso está basado en un incidente real, pero las capturas tomadas corresponden enteramente a una simulación.
+
+## Contexto
+
+Todo comienza con un correo electrónico de phishing malicioso que contiene un *dropper* que instala un *ransomware*.
 
 El *ransomware* intentará utilizar un *exploit* conocido para tomar el control de todas las máquinas posibles.
 
@@ -10,30 +15,80 @@ El *ransomware* intentará utilizar un *exploit* conocido para tomar el control
 
 Ataque Eternalblue: escenario
 
-Redborder puede usar las reglas de Snort para detectar la respuesta de eco del protocolo *SMBv1* utilizada por el *ransomware*, por lo que podemos usar el módulo de intrusión para ver las firmas para identificar el ataque.
+## Gestión de Incidentes
+
+En la vista de incidentes, ha aparecido un nuevo incidente que necesita ser investigado. En este caso, tú eres el encargado de hacerlo.
+
+![Lista de Incidentes](images/eternalblue_incident_list.png)
+
+*Lista de Incidentes*
+
+Al hacer clic en el incidente se mostrarán los detalles del mismo. Comenzando por la visión general, puedes ver que el incidente está afectando a *algunas* máquinas.
+
+![Resumen del Incidente](images/eternalblue_incident_overview.png)
+
+*Resumen del Incidente*
+
+A partir de aquí, se puede deducir que el ataque es importante porque puede estar afectando a muchas máquinas.
+
+## Iniciar la investigación
+
+Puedes decidir iniciar la investigación manteniendo el incidente abierto. Sin embargo, en otras situaciones, puedes decidir rechazar el incidente porque es un falso positivo o trasladar la tarea a otra persona como informar del incidente. Hagas lo que hagas, añade la nota correspondiente en el **playbook**, en la sección **Respuesta**.
+
+![Respuesta al incidente](images/eternalblue_incident_response.png)
+
+*Respuesta al incidente*
 
-![Ataque Eternalblue: intrusión](images/ch09_img017.png)
+![Primeras notas](images/eternalblue_first_notes.png)
 
-Ataque Eternalblue: intrusión
+*Primeras notas*
+
+Las notas pueden ampliarse en función de la información que tengas, como módulos extra, acceso a la máquina física o fuentes externas. Pero el lugar más interesante para revisar es la fuente de datos correspondiente, que en este caso es **redBorder Intrusion**. Al hacer clic en ella, te redirigirá a la vista correspondiente.
+
+## Entrando en la fuente
+
+Redborder puede utilizar reglas Snort para detectar la respuesta de eco del protocolo *SMBv1* utilizada por el *ransomware*, por lo que podemos utilizar el módulo de intrusión para ver las firmas que identifican el ataque.
+
+![Ataque Eternalblue: Intrusión](images/ch09_img017.png)
+
+Ataque Eternalblue: Intrusión
 
 Aquí podemos ver las firmas actuales recopiladas por Redborder.
 
-![Ataque Eternalblue: filtrando firmas](images/ch09_img018.png)
+![Ataque Eternalblue: filtrando firma](images/ch09_img018.png)
 
-Ataque Eternalblue: filtrando firmas
+Ataque Eternalblue: filtrando firma
 
-Una vez que hayamos filtrado la firma de *Eternalblue*, podemos mostrar la métrica *SRC Address* para rastrear las IP involucradas en el ataque.
+Una vez que hemos filtrado la firma de *Eternalblue*, podemos mostrar la métrica de Dirección SRC para rastrear las IPs involucradas en el ataque.
 
-![Ataque Eternalblue: selección de métrica SRC Address](images/ch09_img019.png)
+![Ataque Eternalblue: seleccionando métrica de Dirección SRC](images/ch09_img019.png)
 
-Ataque Eternalblue: selección de métrica SRC Address
+Ataque Eternalblue: seleccionando métrica de Dirección SRC
 
-Ahora tenemos las IP de las máquinas involucradas, por lo que es posible tomar medidas para resolver el agujero de seguridad.
+Ahora tenemos las IPs de las máquinas involucradas, por lo que es posible tomar acciones para resolver el agujero de seguridad.
 
-![Ataque Eternalblue: IPs envueltas en el ataque](images/ch09_img020.png)
+![Ataque Eternalblue: IPs involucradas en el ataque](images/ch09_img020.png)
 
-Ataque Eternalblue: IPs envueltas en el ataque
+Ataque Eternalblue: IPs involucradas en el ataque
 
 !!! info "Ten en cuenta..."
+  
+    Es importante tener una versión actualizada de las reglas Snort para detectar comportamientos y tráfico extraños con Redborder.
+
+## Volver al informe
+
+Volviendo a la vista de respuesta al incidente, debes añadir las notas sobre la investigación. En este caso, puedes informar de las IPs de origen descubiertas.
+
+![Añadiendo notas de hosts afectados](images/eternalblue_affected_notes.png)
+
+*Añadiendo notas de hosts afectados*
+
+E informar que el siguiente usuario necesita revisar esos hosts para iniciar la siguiente fase del incidente.
+
+![Confirmar notas del incidente](images/eternalblue_confirm_notes.png)
+
+*Confirmar notas del incidente*
+
+## ¿Qué sigue?
 
-    Es importante tener una versión actualizada de las reglas de Snort para detectar comportamientos extraños y tráfico con Redborder.
+Se espera que el usuario informado recoja el incidente en este estado e inicie la fase de contención del malware, empezando por aislar las máquinas afectadas.
diff --git a/docs/guides/use_cases/ch9_detect_eternalblue.md b/docs/guides/use_cases/ch9_detect_eternalblue.md
index 52e7e1c7..3138ea1d 100644
--- a/docs/guides/use_cases/ch9_detect_eternalblue.md
+++ b/docs/guides/use_cases/ch9_detect_eternalblue.md
@@ -1,6 +1,11 @@
 # Detecting an Eternalblue Attack with Redborder
 
-In this case, we will see how Redborder can use Snort rules to detect an *Eternalblue* attack.
+In this case, we will see how to manage an *Eternalblue* attack incident. 
+
+!!! info "Please note..."
+    This case is based on a real incident, but captures taken corresponds entirely to a simulation.
+
+## Context
 
 It all starts with a malicious phishing email which contains a *dropper* that installs *ransomware*.
 
@@ -10,6 +15,38 @@ The *ransomware* will try to use a known *exploit* to take control of all possib
 
 Eternalblue attack: scenario
 
+## Incident Management
+
+On incidents view, a new incident has appeared that needs to be investigated. In this case, you are the one in charge of it.
+
+![Incident List](images/eternalblue_incident_list.png)
+
+*Incident List*
+
+Clicking on the incident will show the details of the incident. Starting from the overview, you can see the incident is affecting to SOME machines.
+
+![Incident Overview](images/eternalblue_incident_overview.png)
+
+*Incident Overview*
+
+From here, you can deduce that the attack is important because it can be affecting to a lot of machines.
+
+## Start the investigation
+
+You can decide to start the investigation by keeping the incident open. However, in other situations, you can decide to reject the incident because it is a false positive or move the task to another person as reporting the incident. Whatever you do, add the corresponding note in the playbook, in the **Response** section.
+
+![Incident response](images/eternalblue_incident_response.png)
+
+*Incident response*
+
+![First notes](images/eternalblue_first_notes.png)
+
+*First notes*
+
+Notes can be expanded based on the information you have, as extra modules, access to the physical machine or external sources. But the most interesting place to look at is the corresponding source, which in this case is **redBorder Intrusion**. By clicking on it, it will redirect you to the corresponding view.
+
+## Getting into the source
+
 Redborder can use Snort rules to detect the *SMBv1* protocol echo response used by the *ransomware*, so we can use the intrusion module to see the signatures to identify the attack.
 
 ![Eternalblue attack: Intrusion](images/ch09_img017.png)
@@ -37,3 +74,21 @@ Eternalblue attack: IPs involved in the attack
 !!! info "Keep in mind..."
   
     It is important to have an updated version of Snort rules to detect weird behaviour and traffic with Redborder.
+
+## Back to report
+
+Going back to the incident response view, you should add the notes about the investigation. In this case, you can report the Source IPs discovered.
+
+![Adding affected hosts notes](images/eternalblue_affected_notes.png)
+
+*Adding affected hosts notes*
+
+And report that the next user need to review those hosts to start the next phase of the incident.
+
+![Confirm incident notes](images/eternalblue_confirm_notes.png)
+
+*Confirm incident notes*
+
+## What's next?
+
+It is expected that the reported user is picking up the incident on this state and start the containment phase fo the malware, starting with the affected hosts.
diff --git a/docs/guides/use_cases/images/eternalblue_affected_notes.png b/docs/guides/use_cases/images/eternalblue_affected_notes.png
new file mode 100644
index 00000000..af595253
Binary files /dev/null and b/docs/guides/use_cases/images/eternalblue_affected_notes.png differ
diff --git a/docs/guides/use_cases/images/eternalblue_confirm_notes.png b/docs/guides/use_cases/images/eternalblue_confirm_notes.png
new file mode 100644
index 00000000..6dcaa8e1
Binary files /dev/null and b/docs/guides/use_cases/images/eternalblue_confirm_notes.png differ
diff --git a/docs/guides/use_cases/images/eternalblue_first_notes.png b/docs/guides/use_cases/images/eternalblue_first_notes.png
new file mode 100644
index 00000000..a88f33c4
Binary files /dev/null and b/docs/guides/use_cases/images/eternalblue_first_notes.png differ
diff --git a/docs/guides/use_cases/images/eternalblue_incident_list.png b/docs/guides/use_cases/images/eternalblue_incident_list.png
new file mode 100644
index 00000000..3b8918a0
Binary files /dev/null and b/docs/guides/use_cases/images/eternalblue_incident_list.png differ
diff --git a/docs/guides/use_cases/images/eternalblue_incident_overview.png b/docs/guides/use_cases/images/eternalblue_incident_overview.png
new file mode 100644
index 00000000..9ecda87d
Binary files /dev/null and b/docs/guides/use_cases/images/eternalblue_incident_overview.png differ
diff --git a/docs/guides/use_cases/images/eternalblue_incident_response.png b/docs/guides/use_cases/images/eternalblue_incident_response.png
new file mode 100644
index 00000000..32886c5c
Binary files /dev/null and b/docs/guides/use_cases/images/eternalblue_incident_response.png differ
diff --git a/docs/index.es.md b/docs/index.es.md
index 1c3929bd..e9f80528 100644
--- a/docs/index.es.md
+++ b/docs/index.es.md
@@ -39,7 +39,7 @@ La plataforma cuenta con una función de búsqueda integral. Puede utilizarla pa
 
 Para abrir una página en los resultados de la búsqueda simplemente haga clic (o toque en el móvil) en la página deseada en la lista mostrada.
 
-## Primeros Pasos
+### ¿Qué es lo siguiente?
 
 Si esta es su primera vez visitando esta plataforma de documentación, puede visitar la página [primeros pasos](guides/getting_started/first_steps.es.md) para ver la información inicial para aprender sobre RedBorder.
 
diff --git a/docs/index.md b/docs/index.md
index d22eedd8..d4a6b461 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -39,7 +39,7 @@ The platform features a comprehensive search function. You can use it to quickly
 
 To open a page in the search results, simply click (or tap on mobile) on the desired page in the displayed list.
 
-## First steps
+### What's next
 
 If this is your first time visiting this documentation platform, you can visit the [getting started](guides/getting_started/first_steps.md) page to see initial information when learning about RedBorder.
 
diff --git a/docs/manager/more_in_detail/ch5_1_incidents.es.md b/docs/manager/more_in_detail/ch5_1_incidents.es.md
new file mode 100644
index 00000000..fb532447
--- /dev/null
+++ b/docs/manager/more_in_detail/ch5_1_incidents.es.md
@@ -0,0 +1,123 @@
+# Incidentes
+
+Los incidentes son el punto de entrada principal de la plataforma RedBorder. Son el resultado del análisis de los eventos y alertas generados por el sistema que esperan ser revisados por el usuario, ya sea para ser reportados o descartados.
+
+![Vista de incidentes](images/ch05_1_incidents_view.png)
+*Vista de incidentes*
+
+## Partes de la vista
+
+Puedes ver las diferentes partes de la vista en la imagen anterior:
+
+* Una barra de búsqueda para encontrar un incidente.
+* Una barra de filtros para filtrar los incidentes.
+* La lista de incidentes.
+
+Por defecto, no se aplica ningún filtro y la lista está ordenada por fecha, de más reciente a más antiguo.
+
+## Campos de un incidente
+
+Los campos de un incidente son los siguientes:
+
+* ID: Identificador único del incidente.
+* Prioridad: La prioridad del incidente a gestionar.
+* Nombre: Un nombre explicativo del incidente.
+* Source: La fuente de datos desde la cual se generó el incidente.
+* Creado hace: La fecha y hora en que se detectó el incidente.
+* Asignado: El usuario de la web que tiene actualmente asignado el incidente.
+* Estado: El estado actual del incidente. Los valores posibles incluyen:
+
+Los posibles estados son:
+
+* Nuevo: El incidente ha sido creado pero aún no ha sido revisado.
+* Abierto: El incidente está siendo investigado actualmente.
+* Cerrado: La investigación del incidente está completa y no se requiere ninguna acción adicional.
+* Contención exitosa: El incidente ha sido contenido y se ha evitado que se propague más.
+* Incidente Reportado: El incidente ha sido oficialmente reportado a las partes interesadas o autoridades relevantes.
+* Rechazado: Se ha determinado que el incidente es un falso positivo o no requiere acciones adicionales.
+* Restauración exitosa: Los sistemas y datos afectados por el incidente han sido restaurados exitosamente.
+* Detenido: La investigación o resolución del incidente se ha detenido temporalmente debido a varios factores.
+## Acciones sobre un incidente
+
+Las acciones que se pueden realizar sobre un incidente son las siguientes:
+
+* Hacer clic en el nombre del incidente para ver los detalles del incidente.
+* Hacer clic en la fuente del incidente para ir a la vista de la fuente del incidente.
+* Hacer clic en el estado para cambiar el estado del incidente.
+* Hacer clic en el icono de configuración para comenzar a gestionar el incidente.
+* Hacer clic en el icono de papelera para eliminar el incidente.
+
+Al hacer clic en el nombre del incidente se mostrarán los detalles del incidente, ampliando su explicación. Hacer clic en **Ver Detalle del Incidente** tendrá el mismo efecto que hacer clic en el icono de configuración. En ambos casos, si el estado del incidente era **Nuevo**, cambiará a **Abierto**; y el usuario será asignado a ti mismo.
+
+![Resumen del incidente](images/ch05_1_incident_sum.png)
+
+*Resumen del incidente*
+
+## Adentrándose en el incidente
+
+El propósito principal de esta vista es proporcionar al usuario toda la información sobre el incidente y la posibilidad de documentar el proceso de **detección** y **respuesta**.
+
+![Detalle del incidente](images/ch05_1_incident_detail.png)
+
+*Detalle del incidente*
+
+### Vista general
+
+La visión general del incidente muestra la siguiente información relacionada con el incidente:
+* La lista de **activos**.
+* La lista de **observables**.
+* La lista de **indicadores**.
+
+Además, la información se resume en una vista de gráfico interactivo que permite al usuario ver la conexión entre los observables.
+
+![Visión general del incidente](images/ch05_1_overview.png)
+
+*Visión general del incidente*
+
+### Detección
+
+La sección de detección muestra la lista de alertas relacionadas (mensajes), observables y activos que componen el incidente.
+
+![Detección](images/ch05_1_detection.png)
+
+*Detección del incidente*
+
+### Respuesta
+
+La sección de respuesta muestra un **playbook**, que es una guía estructurada para manejar el incidente. Un playbook proporciona un enfoque sistemático para la respuesta a incidentes, asegurando que todos los pasos necesarios se sigan de manera consistente. Hay diferentes tipos de playbooks, que se definen por el tipo de incidente. El playbook se divide en fases. Cada fase puede tener diferentes tareas a realizar, y cada tarea tiene una descripción y un espacio específico para escribir los comentarios del proceso de respuesta. Se espera que los usuarios ejecuten las fases y tareas en el orden propuesto.
+
+![Respuesta](images/ch05_1_response.png)
+*Respuesta del incidente*
+
+En este ejemplo, el playbook tiene cuatro fases: **Identificación**, **Contención**, **Erradicación** y **Recuperación**. Cada fase tiene una lista de tareas a realizar en orden. El usuario puede agregar comentarios a las tareas y marcarlas como completadas.
+
+### Worklog
+
+El worklog es un registro de las acciones realizadas por cada usuario que trabajó en el incidente. Cualquier cambio en él se registrará y se podrá filtrar y mostrar aquí. Además, cualquier usuario puede agregar comentarios manualmente al worklog según sea necesario.
+
+![Worklog](images/ch05_1_worklog.png)
+
+*Worklog*
+
+#### Búsqueda en el worklog
+
+Los **registros** se pueden filtrar por **Tipo** y **Usuario**, y ordenar por fecha. Hay tres tipos de registros:
+* Cambios en el incidente: Estos registros son generados automáticamente por el sistema cuando cambia el estado del incidente, como cuando cambia el estado o el usuario.
+* Registros de respuesta: Estos son agregados manualmente por el usuario durante el proceso de investigación y respuesta.
+* Notas: Además, el usuario puede agregar notas manualmente al worklog. Útil cuando la información detallada no encaja en el resto de los tipos.
+
+#### Agregar notas
+
+Además, el usuario puede agregar notas al worklog. Al hacer clic en **Agregar Nota**, aparecerá el editor de texto para agregar la nota. La nota se agregará al worklog después de hacer clic en **Guardar**. El editor de texto tiene características útiles como:
+* Insertar enlaces
+* Insertar bloques de código y otro texto formateado
+* Adjuntar archivos
+* Entre otras opciones
+
+![Agregar nota](images/ch05_1_add_note.png)
+
+*Agregar nota*
+
+# ¿Qué es lo siguiente?
+
+Ve a la sección de **Incidentes** para comenzar a gestionar un incidente. El playbook probablemente te guiará para ver la **fuente** del incidente. O ve a **Herramientas/Playbooks** para definir nuevos playbooks para nuevos tipos de incidentes.
diff --git a/docs/manager/more_in_detail/ch5_1_incidents.md b/docs/manager/more_in_detail/ch5_1_incidents.md
new file mode 100644
index 00000000..987a0c84
--- /dev/null
+++ b/docs/manager/more_in_detail/ch5_1_incidents.md
@@ -0,0 +1,123 @@
+# Incidents
+
+Incidents are the main entry point of the RedBorder platform. They are the result of the analysis of the events and alerts generated by the system waiting to be reviewed by the user, either to be reported or dismissed.
+
+![Incidents view](images/ch05_1_incidents_view.png)
+*Incidents view*
+
+## Parts of the view
+
+You can see the different parts of the view in the previous image:
+
+* A search bar to find an incident.
+* A filter bar to filter the incidents.
+* The list of incidents.
+
+By default, no filter is applied and the list is ordered by date from most recent to oldest.
+
+## Fields of an incident
+
+The fields of an incident are the following:
+
+* ID: Unique identifier of the incident.
+* Priority: The priority of the incident to be managed.
+* Name: An explanatory name of the incident.
+* Source: The datasource from which the incident was generated.
+* Created at: The date and time when the incident was detected.
+* Assigned: The user of the web that currently has the incident assigned.
+* Status: The current state of the incident. Possible values include:
+
+Possible status are:
+
+* New: The incident has been created but not yet reviewed.
+* Open: The incident is currently being investigated.
+* Closed: The incident investigation is complete and no further action is required.
+* Containment Achieved: The incident has been contained and prevented from spreading further.
+* Incident Reported: The incident has been officially reported to relevant stakeholders or authorities.
+* Rejected: The incident has been determined to be a false positive or not requiring further action.
+* Restoration Achieved: Systems and data affected by the incident have been successfully restored.
+* Stalled: The investigation or resolution of the incident has been temporarily halted due to various factors.
+  
+## Actions on an incident
+
+The actions that can be performed on an incident are the following:
+
+* Click on the name of the incident to see the details of the incident.
+* Click on the source of the incident to go to the view of the source of the incident.
+* Click on status to change the status of the incident.
+* Click on the settings icon to start managing the incident.
+* Click on trash icon to delete the incident.
+
+Clicking on the name of the incident will explanain the incident. Clicking on **View Incident Detail** will have the same effect as clicking on the settings icon. In both cases, if the incident's status was **New**, it will change to **Open**; and the user will be assigned to yourself.
+
+![Incident summary](images/ch05_1_incident_sum.png)
+
+*Incident summary*
+
+## Getting into the incident
+
+The main purpose of this view is to provide the user with all the information about the incident and the possibility to document the process.
+
+![Incident detail](images/ch05_1_incident_detail.png)
+
+*Incident detail*
+
+### Overview
+
+The overview of the incident shows the following related information with the incident:
+* The list of **assets**.
+* The list of **observables**.
+* The list of **indicators**.
+
+Moreover, the information is summarized in an interactive graph view that allows the user to see the connection between the observables.
+
+![Overview of the incident](images/ch05_1_overview.png)
+
+*Overview of the incident*
+
+### Detection
+
+The detection section shows the list of related alerts (messages), observables and assets that makes the incident up.
+
+![Detection](images/ch05_1_detection.png)
+
+*Detection of the incident*
+
+### Response
+
+The response section displays a **playbook**, which is a structured guide for handling the incident. A playbook provides a systematic approach to incident response, ensuring that all necessary steps are followed in a consistent manner. There are different types of playbooks, which are defined by the type of incident. The playbook is divided by phases. Each phase can have different tasks to be performed, and each task has a description of it and a specific space for writing the comments of response process. Phases and tasks are supposed to be executed in order.
+
+![Response](images/ch05_1_response.png)
+*Response of the incident*
+
+In this example, the playbook has four phases: **Identification**, **Containment**, **Eradication** and **Recovery**. Each phase has a list of tasks to be performed in order. The user can add comments to the tasks and mark them as completed.
+
+### Worklog
+
+The worklog is a log of the actions performed by every user who worked on the incident. Any change to it will be registered and can be filtered and shown here. Additionally, any user can add comments manually to the worklog as necessary.
+
+![Worklog](images/ch05_1_worklog.png)
+
+*Worklog*
+
+#### Searching in the worklog
+
+**Logs** can be filtered by **Type** and **User**, and ordered by date. There are three kinds of logs:
+* Incident changes: These logs are automatically generated by the system when the state of the incident changes, such as when the status changes or when the user does.
+* Response logs: These are manually added by the user during the investigation and response process.
+* Notes: Additionally, the user can add notes manually to the worklog. Useful when the detailed information doesn't fit in the rest of the types.
+
+#### Adding notes
+Additionally, the user can add notes to the worklog. By clicking on **Add Note** the text editor will appear to add the note. The note will be added to the worklog after clicking on **Save**. The text editor has useful features such as:
+* Insert links 
+* Insert code blocks and other formatted text
+* Attach files
+* Among other options
+
+![Add note](images/ch05_1_add_note.png)
+
+*Add note*
+
+# What's next?
+
+Go to **Incidents** section to start managing an incident. The playbook will probably guide you to watch the **source** of the incident. Or go to **Tools/Playbooks** to define new playbooks for new types of incidents.
diff --git a/docs/manager/more_in_detail/images/ch05_1_add_note.png b/docs/manager/more_in_detail/images/ch05_1_add_note.png
new file mode 100644
index 00000000..eacf011b
Binary files /dev/null and b/docs/manager/more_in_detail/images/ch05_1_add_note.png differ
diff --git a/docs/manager/more_in_detail/images/ch05_1_detection.png b/docs/manager/more_in_detail/images/ch05_1_detection.png
new file mode 100644
index 00000000..de3f4c2f
Binary files /dev/null and b/docs/manager/more_in_detail/images/ch05_1_detection.png differ
diff --git a/docs/manager/more_in_detail/images/ch05_1_incident_detail.png b/docs/manager/more_in_detail/images/ch05_1_incident_detail.png
new file mode 100644
index 00000000..11af0a71
Binary files /dev/null and b/docs/manager/more_in_detail/images/ch05_1_incident_detail.png differ
diff --git a/docs/manager/more_in_detail/images/ch05_1_incident_sum.png b/docs/manager/more_in_detail/images/ch05_1_incident_sum.png
new file mode 100644
index 00000000..438e62e1
Binary files /dev/null and b/docs/manager/more_in_detail/images/ch05_1_incident_sum.png differ
diff --git a/docs/manager/more_in_detail/images/ch05_1_incidents_view.png b/docs/manager/more_in_detail/images/ch05_1_incidents_view.png
new file mode 100644
index 00000000..18877669
Binary files /dev/null and b/docs/manager/more_in_detail/images/ch05_1_incidents_view.png differ
diff --git a/docs/manager/more_in_detail/images/ch05_1_overview.png b/docs/manager/more_in_detail/images/ch05_1_overview.png
new file mode 100644
index 00000000..6421cc00
Binary files /dev/null and b/docs/manager/more_in_detail/images/ch05_1_overview.png differ
diff --git a/docs/manager/more_in_detail/images/ch05_1_response.png b/docs/manager/more_in_detail/images/ch05_1_response.png
new file mode 100644
index 00000000..0ed3e71b
Binary files /dev/null and b/docs/manager/more_in_detail/images/ch05_1_response.png differ
diff --git a/docs/manager/more_in_detail/images/ch05_1_worklog.png b/docs/manager/more_in_detail/images/ch05_1_worklog.png
new file mode 100644
index 00000000..ef52a0ad
Binary files /dev/null and b/docs/manager/more_in_detail/images/ch05_1_worklog.png differ
diff --git a/docs/manager/redborder_basics/ch3_web_platform.es.md b/docs/manager/redborder_basics/ch3_web_platform.es.md
index ab5da632..801dad45 100644
--- a/docs/manager/redborder_basics/ch3_web_platform.es.md
+++ b/docs/manager/redborder_basics/ch3_web_platform.es.md
@@ -66,6 +66,12 @@ Vamos a realizar una descripción rápida de las opciones que se pueden encontra
 
 Dashboard
 
+*Incidentes*: Actúa como un gestor de tareas donde los usuarios pueden ver y gestionar eventos marcados como incidentes. Cada usuario puede tener asignados incidentes que requieren investigación, permitiendo un seguimiento y resolución eficiente de los eventos de seguridad.
+
+![Vista de Incidentes](../more_in_detail/images/ch05_1_incidents_view.png)
+
+*Vista de Incidentes*
+
 *Eventos*: A continuación, el usuario podrá ver eventos cuya información proviene de los sensores registrados en su sección correspondiente. Más adelante, se explicará en detalle qué función tiene cada uno y cómo se registran estos sensores. En la captura de pantalla adjunta: Vault
 
 ![Eventos](images/ch03_img005.png)
diff --git a/docs/manager/redborder_basics/ch3_web_platform.md b/docs/manager/redborder_basics/ch3_web_platform.md
index 86de7ff7..0d0b0db5 100644
--- a/docs/manager/redborder_basics/ch3_web_platform.md
+++ b/docs/manager/redborder_basics/ch3_web_platform.md
@@ -66,6 +66,12 @@ Let's make a quick description of the options that can be found in the menu bar,
 
 Dashboard
 
+*Incidents*: Acts as a task manager where users can view and manage events marked as incidents. Each user can have assigned incidents that require investigation, allowing for efficient tracking and resolution of security events.
+
+![Incidents View](../more_in_detail/images/ch05_1_incidents_view.png)
+
+*Incidents View*
+
 *Events*: Next, the user can view events whose information comes from sensors registered in their corresponding section. Later, each function and how these sensors are registered will be explained in detail. In the attached screenshot: Vault
 
 ![Events](images/ch03_img005.png)