Incident management
The 3rdRisk incident register allows you to view and manage all your incidents in one centralised place. It enables aggregations across your internal organisation and all third parties. The incident register includes all information about each identified incident, such as the origin of the incident, type of the incident, response status, who owns it and what the lessons learned.
This document will first introduce and explain the concept and then describe how it is implemented on 3rdRisk.com.
One solution for all your internal- and external incidents
With the incident management module of 3rdRisk, you can manage all your internal- and external incidents in one place. There is no longer a need for a separate incident-/GRC solution or a standalone Excel file.
Incident management concept
Within the 3rdRisk platform, you can manage all incident management activities throughout your complete supply chain. It is also closely integrated with the other risk & compliance domains. The following graphic provides a conceptual overview of the integrated 3rdRisk incident management module:
Incident management aims to plan for, respond to, manage and escalate a critical incident quickly and effectively, bringing it under control and limiting the impact on your organisation and supply chain. The integrated 3rdRisk incident management module covers every aspect of an incident across its life cycle. Within the 3rdRisk platform, different modules can provide input for the incident management module. For example:
- Assessment module (e.g. A third party responded in one of your assessments that they are facing a significant data breach)
- Risk management module (e.g. A known DDoS risk manifests and causes a significant continuity incident)
- Third-party management module (e.g. Providing the third-party details of a third party currently in the news due to a malware attack).
But there are also different other channels of input sources:
- Internal monitoring systems
- Employees
- Incident updates from third-parties
- News bulletins
- External incident monitoring sources
- Etc.
The 3rdRisk platform lets you quickly and securely document all your incidents.
1. Detection
Incident detection
Incident detection is detecting and recording events that negatively affect anything from a single employee to your entire supply chain.
Description
You can give the incident a name and provide some contextual information.
Detection date
The date when the incident was detected.
Scope
The scope of an incident can differ, e.g. it could have impacted one asset, a small offshore team or a complete factory. It is critical to clearly define in the detection phase what the actual scope is, as this will provide input for the assessment phase.
Category
The platform uses incident categories to group incidents under a common area. Available categories in the platform are:
- Information security
- Privacy
- Quality
- Compliance
- Environmental
- Safety
- Continuity
- Political
- Financial
- Operational
- HR
- Reputation
- Other
You do not have to use all these categories; the advice is only to use the relevant ones for your type of incidents, business and reporting needs.
Location
Incident location
The organisation model defines the location of an incident within your organisation.
When one of your third parties is involved, the platform will automatically provide the possible locations within the organisation - as it knows via the contract catalogue where this third party is active.
Ownership and stakeholders
Per incident, you can define the following stakeholders:
- Incident owner *
- Other external parties (e.g. regulators, society, accountants), including their expectations
- Internal stakeholders, including their expectations
- Involved third-party (if applicable)
- Internal response coordinator (can be defined in the 3. Response phase)
- External response coordinator (can be defined in the 3. Response phase)
* Only the risk owner is a required field.
2. Assessment
Incident assessment
Risk assessment is the process of assessing identified risks on their potential severity of impact and the probability of occurrence. The assessment process is an essential step as it will prioritise your risk treatment.
Cause
The actions, omissions, events, conditions, or a combination thereof lead to this incident.
Origin
Where did this incident initially start?
Classification
The classification of an incident is performed to steer incident prioritisation and support response activities.
- Low
- Medium
- High
- Critical
As the segmentation of these levels differs per organisation and industry, we advise you to define your incident level criteria per level:
Example of incident classification criteria
| Category | Your organisation-specific criteria |
| Low | E.g. A routine incident that can be managed using standard operating procedures. |
| Medium | E.g. A severe situation that requires a coordinated and formalised operational response. |
| High | E.g. A severe incident that could threaten our reputation or license to operate. |
| Critical | E.g. A significant incident that could threaten the public. |
Reporting to authorities
Fatal and non-fatal injuries and specific privacy incidents must be reported to certain local authorities in the European Union. But this differs per legislation, location, industry and type of incident. That is why it is good practice to identify your global incident reporting requirements upfront. The legal department is the best place to start this analysis within most organisations.
3. Response
Incident response
Incident response is the process of addressing and manage the incident. The goal is to handle the situation in a way that limits damage and reduces recovery time and costs.
Status
The status of the incident. Within the platform, you have the following options:
- Registered - response not yet started
- Monitoring
- Response in progress
- Resolved
- Closed
Response coordinators
You can define internal and external response coordinators responsible for managing the incident response process for this specific risk.
Response
Definition of the organisation's actions to recover from this incident.
Closure date
The data that the incident was formally closed.
4. Lessons learned
This final stage is often skipped, as organisations tend to return to normal operations after recovering from an incident. Nonetheless, it is essential to define the lessons learned. It will allow you to incorporate additional activities and knowledge into your daily operations to produce better future outcomes and additional defences.
Prevention steps
Overview of possible steps the organisation can take to avoid or mitigate the impact of an incident reoccurrence. This can be additional monitoring, increased training activities, creating a Business Continuity Plan (BCP), replacing the associated third-party etc.
Documentation updates
Defines the need to update relevant policies, procedures and work instructions.
Estimated costs
It is always good to create an estimated cost overview of the containment of the incident. You can use this for lessons learned, support risk mitigation measure decisions, and input for third-party interactions and possible legal actions.
Chance of recurrence
If the chance of a recurrence is considered medium to high, it might be advisable to register a dedicated risk in your risk register. This will enable you to proactively monitor, act on mitigations and respond in case of a recurrence.
Add an incident
To add a new risk to your risk register:
- Navigate to: Left side menu: Incidents
- Click on [+ Add incident]
- Provide the risk details:
| Phase | Field | Explanation |
| 1. Detection | Incident title * | Title of the incident. |
| Incident description * | Short description of the incident. | |
| Incident scope | Scope of the incident, e.g. specific involved asset, process or team. | |
| Detection date * | The date when the incident was detected. | |
| Category * | Select the most relevant category of this incident. Incident categories within the platform are used to group risks under a common area. | |
| Incident owner * | The colleague that is the incident owner. | |
| Related external ticket number(s) | If you created a ticket in an internal system for the operational activities related to this incident, you could use this field to create a reference. | |
| External stakeholders | ||
| Is one of your third parties involved with this incident? * | Use this section if one of your third parties is involved with this incident. | |
| Are any other external parties involved, e.g. regulators, society, accountants, involved? * | Use this section to list additional stakeholders to ensure that external expectations and reporting needs are known and managed throughout the life cycle of the incident. | |
| Internal stakeholders | ||
| Internal stakeholders | List all internal stakeholders and define their roles and expectations in this section. Use the tab key on your keyboard to add multiple stakeholders. | |
| 2. Assessment | Cause of the incident | The actions, omissions, events, conditions, or a combination thereof, lead to the incident. You can select:
|
| Additional information incident cause | Additional contextual information about how the incident was caused. | |
| Origin of the incident | Where did the incident initially start? You can select:
| |
| Additional information on the origin of the incident | Additional contextual information about the origin of the incident. | |
| The incident affects (people, core service, shipments, data etc.) * | Describe how this incident affects your organisation and ecosystem. | |
| Classification of the incident * | Use your internal classification guidelines to assign an incident classification. You can use this value to support incident monitoring and reporting purposes and create lessons learned. | |
| Reasoning on the incident classification | Reasoning on incident classification, when available, make, e.g. a reference to the applied internal classification matrix. | |
| Is it required to report this incident to authorities? * | Verify internally if it is necessary to report this accident or incident to an authority. | |
| Additional information regarding incident reporting to relevant authorities | If you need to report this incident to an authority, use this field to list the requirements, e.g. the specific authorities, reasoning, timelines, format and responsible internal stakeholder. | |
| 3. Response | Response status | The current incident lifecycle status. You can select:
|
| Incident closed date | The date when the incident was closed. The value will initially be set to the date when the response status was close. | |
| Internal response coordinator | The colleague is responsible for assessing the situation, activating procedures, notifying and coordinating with external parties, including emergency services, and directing the shutdown of certain operations, if necessary. You can select all users that are registered on the platform. | |
| External response coordinator | The external counterpart of your internal response coordinator. This role is optional, e.g. in case of an internal incident. | |
| High-level response description * | Overview of the to be undertaken and taken response activities during the incident. | |
| 4. Lessons learned | Are relevant policies and contracts reviewed and updated to prevent reoccurrence? | Identify the improvements that need to be taken to refine and strengthen both your prevention and response protocols. |
| Which other steps have been taken to prevent the incident from happening again? | Which other steps have been taken to prevent the incident from happening again? | |
| What are other lessons learned from this incident? | What are the lessons learned that would help the organisation to build and improve the safety culture? | |
| What were the estimated costs of the incident (incl. containment/prevention) | You can use this value to prioritise lessons learned, improve the incident management process and discuss these during your third-party interactions. | |
| What is the chance that a similar incident will reoccur? | In case of a score of 4-5, creating a dedicated risk in your risk register is advisable to start actively managing the prevention of reoccurrence. | |
| Reasoning on reoccurrence | Description and reasoning on the potential chance of reoccurrence. | |
| Tags | You can use the tags-functionality to assign your own specific/internal labels to an incident record. You can search, filter, and create specific reports based on these tags. E.g. if you want to register all GDPR-related incidents, you can add a tag named “GDPR” to these records. At a later stage, you can effortlessly search and export these incidents. Use the tab key on your keyboard to add multiple tags. |
Required field *
4. Click 'Submit', and the incident is added to your incident register.
Update an incident
To update an incident in your incident register:
- Navigate to: Left side menu: Incidents
- Search for the applicable incident you would like to update
- Click on the sub-menu in the 'Actions column' and click 'Edit risk'
- Update the risk and click on the green coloured 'Save icon'.
Close an incident
To close an incident in your incident register:
- Navigate to: Left side menu: Incidents
- Search for the applicable incident you would like to close
- Click on the sub-menu in the 'Actions column' and click 'Edit risk'
- Navigate to 3. Response and set the 'Response status'-field to closed
- Click on the green coloured 'Save icon'.
Remove an incident
To remove an incident in your incident register:
- Navigate to: Left side menu: Incidents
- Search for the applicable incident you would like to remove
- Click on the sub-menu in the 'Actions column' and click 'Edit incident'
- Click on the red coloured 'Recycle bin'.
View audit log
Data integrity is critical for your incident register; that is why the incident management module comes with a protected audit log that registers all mutations in your incident register. It records:
- Timestamp
- Data adjustment (old value and new value)
- The user account that was used for this update
None of the platform roles (including the platform administrator) can delete or make mutations to this audit log.
To view the audit log of an incident in your incident register:
- Navigate to: Left side menu: Incidents
- Search for the applicable risk
- Click on the sub-menu in the 'Actions column' and click 'View audit log'
Known module limitations
- Please contact Support@3rdRisk.com to discuss options for mass upload of your current incident register.