Summary: An incident is rarely just an incident – a technical disruption can quickly become continuity, recovery, a supplier issue, personal data and crisis management all at once. Incident triage helps you decide early what needs to be activated, who to involve and which deadlines are already running. Here is a practical model that connects your existing plans.

An incident is rarely just an incident. A technical disruption can quickly become a continuity problem, require recovery from backup, involve a critical supplier, affect personal data and at the same time require decisions from management or the crisis organisation. Effective incident triage helps the organisation understand early not only how serious the event is – but what needs to be activated, who needs to be involved and which deadlines may already have started running.

Many organisations already have the plans and processes that are expected to exist.

There is an incident process. Continuity plans. A crisis plan. A technical recovery plan or DRP. Routines for personal data breaches. Supplier contacts and processes for regulatory reporting.

The challenge shows up when something actually happens.

Who decides that a technical incident has also become a business disruption? When should the continuity plan be activated? When does crisis management need to be brought in? Who assesses whether the incident should be reported to an authority? When does a supplier need to be escalated – and who holds the whole together?

This is where incident triage becomes an important part of the organisation’s actual incident capability.

Triage is more than a severity level

Incident triage is often associated with classifying an incident as low, medium, high or critical – or as, for example, P1, P2 or P3.

That is needed. But it is not enough.

Good triage also needs to answer another question: which parts of the organisation’s response need to be activated now?

The same event may need to be handled through several parallel tracks:

operational incident handling
continuity and alternative ways of working
technical recovery and DRP
crisis management
supplier and contract escalation
data protection and legal assessment
regulatory reporting
internal and external communication

Triage therefore becomes more than a classification. It also acts as a routing and decision function between the organisation’s different capabilities.

ISO/IEC 27035-1:2023 describes structured incident management including detection, reporting, assessment, response and learning. ISO 22301 addresses continuity capability and how the organisation prepares for, handles and recovers from disruptions. In real incidents, these perspectives need to meet.

The term incident triage is used here as a practical model for exactly that connection – not as yet another separate process the organisation needs to build.

The incident process can be the shared entry point

For IT and information-security related events, the operational incident process is often a natural entry point.

That is where the first questions are asked: What has happened? What is affected? How extensive is the event? Is it still developing? Are we in control?

But the incident team should not try to solve every perspective on its own. Triage needs to be able to identify early when other capabilities should be activated in parallel.

Question in triage	Possible activation
Can the event be contained and handled within normal operations?	Incident process
Can a critical service or process not be delivered normally?	Incident + continuity plan
Do systems, data or infrastructure need to be recovered?	Incident + DRP/recovery plan
Are decisions or priorities needed beyond the incident team’s mandate?	Incident + crisis management
Is an external supplier part of the cause or the solution?	Supplier and contract escalation
Are personal data or other regulated information affected?	Data protection/legal + possible reporting
Could regulatory reporting criteria be met?	Compliance/regulatory track
Is there significant customer, media or trust impact?	Communication + possible crisis management

The important thing is that the organisation does not wait for one track to finish before the next one starts. During a serious incident, several of these activities may need to run at the same time.

The incident triangle – incident, continuity, recovery and crisis

A simple way to illustrate the connection is through what we usually call the incident triangle.

At the centre is incident handling: detect, analyse, contain, remediate, communicate and follow up on the event. Around the incident process there are three main escalation directions.

Continuity

Continuity planning is activated when the business can no longer deliver a critical service or process in the normal way.

The focus is then not primarily to repair the root cause. The focus is to keep the business going at an acceptable level. That can mean manual fallback routines, alternative systems, other premises, re-prioritising resources or other temporary ways of working.

Technical recovery and DRP

Recovery planning is activated when systems, information, platforms or infrastructure need to be restored.

It can, for example, involve:

restoring information from backup
activating a standby environment
restoring a critical service
rebuilding infrastructure from scratch after a cyberattack

Continuity and recovery have different focuses. Continuity is about how the business continues during the disruption. DRP is about how the technical capability is restored. They often need to run in parallel.

Crisis management

Crisis management needs to be brought in when the incident requires decisions and coordination beyond the operational incident organisation’s mandate.

It can involve prioritisation between business areas, larger financial consequences, customer impact, security matters, media, authority contacts or trust impact.

Crisis management should not take over the technical incident handling. Its role is to handle the strategic and business-wide consequences.

Three perspectives cut across the whole incident

The incident triangle needs to be complemented with three perspectives that can become relevant regardless of which part of the triangle is activated: suppliers, regulatory compliance and communication.

They are not always separate steps in the incident process. They are rather questions that need to be assessed continuously as the incident develops.

The supplier needs to enter triage early

A large part of today’s IT environments consists of external dependencies. Cloud services, SaaS solutions, operations providers, SOC services, network operators and other IT partners can both be part of the cause of a disruption and be decisive for resolving it.

That is why one question should come early: are we dependent on someone else to understand, contain or recover from the incident?

It is not enough to have a supplier list. The organisation also needs to know:

who is allowed to escalate
which contact paths apply
which SLAs and contract requirements are relevant
what information the supplier is expected to be able to provide
which subcontractors may be affected
what alternative solutions exist if the supplier itself cannot deliver

The Swedish Cybersecurity Act clearly shows how these areas connect. The requirements on security measures include, among other things, risk management, incident and continuity handling, supply-chain security and follow-up of the security work. The new regulations on security measures and management training take effect on 1 October 2026 for the entities concerned.

Supplier risk, incident handling and continuity therefore cannot be treated as entirely separate areas.

Reporting needs to be assessed while the incident is ongoing

A common weakness is that the regulatory assessment comes too late.

The incident team focuses on understanding the cause and restoring the systems. Only when the technical work starts to wind down are information security, data protection, legal or compliance involved.

The problem is that several reporting deadlines start running long before the technical investigation is complete.

The Swedish Cybersecurity Act

Entities covered by the Swedish Cybersecurity Act must report significant incidents to the NCSC. For most affected entities, reporting happens in three steps:

an early notification within 24 hours
an incident report within 72 hours
a final report within one month, or a status report if the incident is still ongoing

The NCSC also emphasises that the organisation should not delay the first report just because all information is not yet available.

GDPR

In the event of a personal data breach, the controller needs to assess whether the incident poses a risk to the rights and freedoms of natural persons.

If the incident is notifiable, the starting point is that it must be reported to the Swedish Authority for Privacy Protection (IMY) within 72 hours of the organisation becoming aware of it.

DORA

For financial firms covered by DORA, specific deadlines apply for major ICT-related incidents.

The initial report must be submitted as soon as possible, but no later than four hours after the incident is classified as major and no later than 24 hours after the firm became aware of the incident. After that, an intermediate report must be submitted within 72 hours of the initial report, and a final report no later than one month after the intermediate report, or the most recent updated intermediate report.

Cyber Resilience Act

From 11 September 2026, the CRA’s reporting obligations start to apply for manufacturers of products with digital elements.

This includes, among other things, actively exploited vulnerabilities and serious incidents affecting the security of the product. Here too there are early reporting deadlines: an early warning within 24 hours and a full notification within 72 hours.

The point is not that the same incident is automatically covered by all of these regulations. The point is that triage must identify which legal, sector and contractual requirements may be relevant before the deadlines become a problem.

One incident – several simultaneous activities

Imagine that an organisation is hit by ransomware and a business-critical system becomes unavailable.

The incident team tries to understand the attack and contain the spread. At the same time, the business may need to switch to fallback routines because the normal process no longer works.

If servers or data have to be restored from backup, the DRP or recovery plan is activated. If the infrastructure is managed by an external operations provider, the supplier needs to be escalated.

If there is suspicion that personal data has been exfiltrated, the data protection organisation needs to begin its assessment. If the business is covered by the Cybersecurity Act, DORA or other sector regulation, the reporting obligation needs to be assessed.

And if the impact becomes extensive enough – customers start calling, important services are down or the media picks up the event – crisis management and the communication function may also need to be activated.

It is still one incident. But the organisation’s response consists of several simultaneous activities. That is exactly what incident triage needs to capture.

Six questions for the first triage

The first triage does not have to be complicated. But it needs to force the organisation to look wider than the technical fault.

1. Business

Which services, processes, customers or other stakeholders are affected? Is there a risk that critical time limits, RTO or tolerable outage times will be exceeded?

2. Technology and information

Which systems and information assets are affected? Is there a risk of loss, manipulation, encryption or unauthorised access? Does anything need to be restored?

3. Control of the situation

Are the cause and scope known? Is the incident contained or does it keep developing? Is there a risk of spread?

4. External dependencies

Is a supplier, partner or other external party affected? Does any of them need to act for the incident to be contained or resolved?

5. Compliance and contracts

Could the incident be covered by reporting requirements under, for example, the Cybersecurity Act, GDPR, DORA, CRA or other sector rules? Are there contractual requirements to inform customers, suppliers or other parties?

6. Management and communication

Are decisions needed beyond the incident team’s mandate? Is there significant impact on customers, staff, authorities, media or the organisation’s trust?

Answers to these questions provide a much better basis for decisions than a classification that only says Critical or P1.

Scoring models can help – but some events should trigger directly

A simple scoring model can be good support in triage. Business impact, technical recovery need, information impact, control of the situation, supplier dependency and the need for management decisions can, for example, be assessed on a common scale. It provides structure and makes assessments more consistent.

But the total score must never become the only truth. Certain conditions should be able to act as direct triggers for escalation. Examples could be:

suspected ransomware
an extensive or sensitive information leak
a critical service that is unavailable
a risk to physical safety or life and health
extensive impact at a critical supplier
a likely regulatory reporting obligation
rapidly growing customer or media impact

When information is still limited, the organisation sometimes needs to escalate once too often rather than discover too late that the situation was more serious than first thought.

Triage is not a one-off decision

Another important principle is that triage needs to be repeated.

An incident judged as contained at 09:00 may have developed into a business-critical disruption by 10:30. New information may show that more systems are affected, that data has leaked, that a supplier is also affected or that recovery will take considerably longer than first thought.

The organisation therefore needs to decide when re-triage should be done. It can be:

when significant new information appears
when the impact changes
when the incident passes a defined time limit
when a critical service is affected
when reporting criteria may be met
when responsibility or management level changes

Triage follows the entire lifecycle of the incident.

From separate plans to a unified incident capability

An organisation can have well-written incident, continuity, recovery and crisis plans and still struggle to handle a serious event.

What is decisive is not just the quality of each document. It is how the plans fit together when they need to be used at the same time.

The organisation therefore needs to know:

who carries out the first triage
which criteria lead to escalation
who is allowed to activate each plan
which functions should be involved
which suppliers should be contacted
which regulatory and contractual assessments should be made
how a common situational picture is maintained
who makes which decisions
how and when triage should be reassessed

Only then do documented processes start to become a real incident-handling capability.

Good incident triage therefore does not only answer the question “How serious is the incident?”. It should also answer “What do we need to do now, who needs to be involved and which other processes need to start?”.

It is that connection that makes the difference between several separate plans and a coordinated business response when something actually happens.

How Kristensson i Skåne can support the work

Kristensson i Skåne helps organisations develop and improve the interplay between incident handling, continuity, technical recovery, crisis management, supplier management and regulatory reporting.

The support can, for example, include:

current-state and gap analysis of the incident capability
developing the incident process and a triage model
classification and escalation criteria
connecting the incident process, BCP, DRP and crisis plan
processes for regulatory reporting
integration of supplier and third-party escalation
roles, responsibilities and decision mandates
playbooks for different incident types
tabletop exercises and other tests
follow-up and improvement after incidents and exercises
ongoing support within information security, GRC and the CISO function

Our starting point is practical: the organisation should not have to figure out how the plans fit together while the incident is already ongoing. That connection needs to be established, anchored and exercised in advance.

Would you like to discuss how incident triage can be built into your existing incident, continuity and crisis management? Read more about our work with information security and governance or contact us and we will have a first conversation about your current state and next steps.

Sources and further reading: ISO/IEC 27035-1:2023; ISO 22301; the Swedish Cybersecurity Act and the NCSC’s guidance on incident reporting; GDPR (Article 33) and the Swedish Authority for Privacy Protection (IMY); DORA (reporting of major ICT-related incidents); the Cyber Resilience Act (reporting obligations).

This is an overview and not legal advice. Every organisation needs to assess its requirements based on its operations, sector, risk picture and applicable regulations.