A group that reports incidents to regulators in several countries doesn’t need a separate list of software requirements for each one. Four questions sit behind most of the reports it will ever submit, and a platform can be tested against all four in one demo.
The usual starting point looks different. The requirements spreadsheet has a tab for each country: RIDDOR and the ICO on the UK tab, NIS2 and the accident insurer on the German one, and more for Canada and the UAE. Four tabs and 63 rows later, the head of risk and compliance still can’t say which of three shortlisted platforms would have helped in the group’s last real incident.
The group is an industrial services business with 6,000 people and sites in all four countries. All three vendors have ticked every row, and all three demos showed an alert sent in English, in office hours, to one country. None showed an incident starting at the UAE site at 05:00, with the UK and Germany asleep.
Global incident management system requirements get shorter when they are written from the other end. Start with what a regulator asks after an incident, in any of the four countries, and 63 rows fold into four questions: who was told, who decided, what was done, and whether the organisation can prove it.
Global Incident Management System Requirements Come From What Regulators Ask
Global incident management system requirements are the capabilities an organisation operating in several countries needs from the platform it uses to run an incident and to account for it afterwards. They cover reaching people in every country, recording decisions, tracking actions across time zones and keeping one record that each local team can report from.
Those requirements can be grouped under four questions. No regulator publishes the four as a list. They are a way of organising what the rules, each in its own words, ask an organisation to show. Four questions, in the order an incident raises them:
- Who was told, and when?
- Who decided, and on what information?
- What was done, by whom and by when?
- Can the organisation prove it?
The Financial Stability Board has worked on the same overlap from the regulators’ side. Its Format for Incident Reporting Exchange, published in April 2025, is a common framework of standardised information items for reporting operational incidents to multiple authorities. The FSB says organisations beyond the financial sector can use it (FSB 2025).
1. Who Was Told, And When?
The first requirement is a record of who was told about the incident, at what time, by which channel and whether each person confirmed. Regulators ask because most reporting duties are duties to tell someone quickly, and the people affected are often owed a warning too.
For a death, a specified injury or a dangerous occurrence in Great Britain, RIDDOR requires the responsible person to notify the enforcing authority by the quickest practicable means without delay, and then to send a report within 10 days in most cases. In the EU, Article 23 of the directive described on the European Commission’s NIS2 page requires an early warning within 24 hours of becoming aware of a significant incident, and a notice to service recipients where appropriate. In the UAE, all establishments are required to report work injuries and occupational diseases to the Ministry of Human Resources and Emiratisation, and the time limit should be confirmed with the ministry for the case in hand.
A platform has to produce that record in all four countries. Monday’s post on the Martyn’s Law lockdown procedure for venue staff shows how hard it is inside one building. The requirements to write down:
- Alert groups by country, site and on-call rota, so the message reaches whoever is on duty
- More than one channel per person, tested live to local mobile numbers during the demo
- Messages in the recipient’s language, with the wording that was sent kept in the record
- An acknowledgement logged for each person, because a delivered message is not a confirmed response
- Timestamps that state a time zone, so 05:00 in the UAE and 01:00 UTC are plainly the same minute
2. Who Decided, And On What Information?
The second requirement is a record of each decision: who made it, at what time and what they knew when they made it. Regulators ask because many reporting clocks start from a decision, or from the moment someone became aware, and a clock with no recorded start can’t be defended.
From 18 March 2027, the FCA’s finalised operational incident reporting framework introduces new reporting requirements for in-scope firms. Firms should consult the finalised guidance to confirm the applicable reporting triggers and deadlines.
The FCA’s current notification process applies until then, and the detail varies by type of firm.
Data protection turns on a decision too. The ICO’s guide to personal data breaches says an organisation which decides a breach doesn’t need reporting must be able to justify that decision, so it should document it.
A group in four countries makes that kind of decision more than once. The group classifies the incident, and each country then judges whether its own threshold is met. Tuesday’s post on reporting one incident to regulators in several countries sets out who should own which.
What to ask of a platform:
- A decision entry that stands apart from the message stream, with a name and a time
- Group and local decisions held against the same incident, so a difference between countries can be explained
- A named deputy for each decision-maker, and a record of who held the role at that hour
3. What Was Done, By Whom And By When?
The third requirement is a list of actions with an owner, a deadline and a completion time for each. Regulators ask because the later stages of most reports describe the response itself, and those stages are written days or weeks later.
A final report under NIS2 covers the mitigation measures applied and still under way. In Canada, OSFI asks federally regulated financial institutions for regular updates during an incident and for the post-incident review and lessons learned afterwards (OSFI 2021). Wednesday’s post on NIS2 incident reporting roles and responsibilities gives each of those facts an owner.
For the industrial services group, the actions cross time zones. The UAE site cordons off an area at 05:20, an engineer in Germany picks up a system fault when the working day starts there, and the compliance lead in Canada, where it is still the previous evening, drafts a customer notice. One site’s spreadsheet can’t follow that, so the platform needs:
- Tasks with a named owner and a deadline, assigned from the response plan
- A handover that passes an open task to the next time zone and records who accepted it
- Escalation of an overdue or unclaimed task to someone who is awake
- One view of open actions for the group, and a filtered view for each country
4. Can The Organisation Prove It?
The fourth requirement is a record that was made during the incident, is kept for as long as the strictest local rule demands and can be exported for each regulator. Regulators ask because the first three answers are only as good as the evidence behind them.
The National Cyber Security Centre’s guidance on incident response processes advises keeping a careful record of the response, the decisions made and the actions taken, especially where evidence may have to be presented to a regulatory body. RIDDOR is more exact. Under regulation 12, each entry in the record must be kept for at least three years, and extracts must be sent to the enforcing authority when it asks.
Thursday’s post on who is responsible for reporting RIDDOR shows what it costs when the person coordinating the report hears more than 58 hours after the injury. The requirements that follow:
- Entries written at the moment of each action, with the name of the person who took it
Configurable retention periods, aligned with the organisation’s applicable record-keeping requirements
- An export a local compliance lead can attach to a submission without retyping
- A choice of storage region and access controls, since the record holds names, phone numbers and sometimes locations
What To Look For In Incident Software When You Report To More Than One Regulator
An organisation that reports to more than one regulator should look for incident software that answers the four questions for the whole group and lets each country draw its own report from the answer. On the sheet below, a vendor scores on what it can show in the room and gets no marks for a tick.
Question | What scores in the demo |
Who was told, and when? | Each recipient in three countries shows a time and an acknowledgement, or a visible gap |
Who decided, and on what information? | A group decision and a local decision sit on one incident, each with a name and a time |
What was done, by whom and by when? | An overdue task escalates without anyone chasing it by phone |
Can the organisation prove it? | The session exports as it stands, with retention and storage region set by the customer |
The rules behind those rows are not equivalents of one another. Who must report, what triggers the duty and how long it allows all differ, so the lead in each country still confirms each obligation against the primary text.
One Tool Per Regulation Means One Version Of The Incident Per Tool
A common assumption in a multi-country selection is that each regulation needs its own tool. It is partly right. A safety team needs its accident reporting system and a compliance team needs the regulator’s portal, and an incident platform should replace neither.
The assumption fails one level down, at the response. An incident happens once. If the UK safety system, the German service desk and a spreadsheet at the UAE site each hold part of the story, the group has three records of one morning, and disconnected processes like these make an accurate record hard to keep.
So the specification should ask for one response record and drop the rows asking whether a platform “supports” a named regulation. The earlier post on incident platform evaluation for financial firms explains why: regulators supervise organisations, and a supplier can’t take the duty on.
A Vendor Brief That Tests Incident Management System Requirements
A second demo, run on the group’s own scenario, tests the four questions faster than a questionnaire can. The head of risk and compliance can send the same brief to every vendor on the shortlist. For example:
“For the second session, please replace the standard scenario with this one. An incident starts at the group’s UAE site at 05:00 local time, and the site lead is on leave. Alert the local response team in their own language, the group duty manager in the UK and the compliance leads in Germany and Canada. Record one group decision and one local decision. Assign three actions to owners in two time zones and let one go overdue. Then export the record and show where it answers each of the four questions.”
Two things are worth noting while each vendor runs it. How many steps needed the vendor’s own staff, and could the exported record be read as it stood?
How Crises Control Supports The Four Questions
Monitoring systems detect operational issues but don’t coordinate the people, tasks or decisions needed to resolve them. Communication tools send notifications but don’t coordinate the updates, acknowledgements and response activity that follow. The four questions sit in that gap.
Crises Control is an Operational Incident Coordination Platform. Our incident management software launches, coordinates and documents an incident from one structured workspace, and every communication, acknowledgement, update and decision is timestamped and retained as a complete incident record.
For a group reporting in several countries, the module to look at first is Audit and Reporting. The incident reporting software writes each notification, acknowledgement, task assignment and status change to the incident record at the moment it occurs, including who performed the action. Authorised users can generate reports for leadership, regulators and post-incident reviews, and records remain available after an incident has closed.
For multi-country organisations, Crises Control allows customers to select their primary data residency region from supported Microsoft Azure locations. Data retention periods are also configurable.
Crises Control can translate communications into multiple languages to support teams across different countries. Our accreditations include ISO 22301, ISO/IEC 27001 and Cyber Essentials Plus. We also support audit, governance and regulatory evidence through our Compliance Management Software.
The platform does not decide whether an incident is reportable in any country. It does not complete a regulator’s form or submit one, and using it does not make an organisation compliant with RIDDOR, NIS2 or any other rule. An exported record is evidence to attach to a submission, and the duty to report stays with the organisation’s own people.
From Individual Reporting Duties To One Incident Record
The reporting duties differ, and the operational problem underneath them is often the same. The four earlier posts in this series each take one part of it:
- Martyn’s Law lockdown procedure for venue staff: how venue teams give a lockdown instruction and confirm that staff received it
- Reporting one incident to regulators in several countries: how a multinational group coordinates the facts while local teams keep their own submissions
- NIS2 incident reporting roles and responsibilities: how reporting tasks, evidence and deadlines are assigned during a cyber incident
- Who is responsible for reporting RIDDOR: how the person who holds the duty finds out in time when an injury happens out of hours
Taken together, the four scenarios show why alerting, decisions, tasks and evidence have to work as one coordinated process. Each post covers its own rules and its own scenario in the detail this one leaves out.
Four Tabs Become Four Rows
The spreadsheet with a tab for each country can be retired. In its place the group has one sheet with four rows, a brief that every vendor runs and three exported records to compare. Each country lead still confirms the clock, the threshold and the form for its own regulator. The platform to shortlist is the one whose exported record answers all four questions without anyone having to explain it.
Frequently Asked Questions
What are global incident management system requirements?
Global incident management system requirements are the capabilities an organisation in several countries needs from the platform it uses to run an incident and account for it afterwards. They can be written as four questions: who was told, who decided, what was done and whether it can be proved.
What should you look for in incident software when you report to more than one regulator?
Look for one incident record that every country’s compliance lead can report from. The software should record who was told, each decision with a name and a time and each action with an owner, and export it without rework. Reporting clocks and thresholds are still confirmed locally.
Does a multi-country organisation need a different incident tool for each regulation?
No. Specialist tools are still needed for filing, such as a regulator’s portal or a safety reporting system, but the response itself should be recorded once. Global incident management system requirements should ask for a single record those tools can draw from, because several partial records of one incident rarely agree.
Which incident platform questions for international organisations matter most in a demo?
The questions that matter most are about an incident outside head office hours. Ask the vendor to alert people in three countries, record a group decision and a local one, let an action go overdue and export the record. Then check the export against the four questions.
Can incident management software make an organisation compliant in every country?
No. Regulators supervise organisations, and duties such as RIDDOR reporting or NIS2 notification stay with the organisation that holds them. Incident Management Software can keep the evidence in one place, and Compliance Management Software supports governance, audit and regulatory reporting. Neither replaces the judgement of the local duty holder.
This article was drafted with AI assistance and reviewed by the Crises Control team. Featured image: AI-generated.
