Incident and crisis management software, from the first alert to the boardroom
One record that escalates from incident to major incident to crisis, so responders, the incident commander, the crisis team, the board and the regulator all work from the same facts, under ISO/IEC 27035, NIST SP 800-61r3, ISO 22320 and ISO 22361.
Incidents become crises in the gaps between teams
Most organisations run incident response, emergency command and crisis leadership as three separate disciplines. The security operations team works in a ticketing tool, the crisis team works from a plan document and a spreadsheet, and the board receives forwarded emails. Every hand-off between them loses time and context at exactly the moment both matter most.
The standards were never meant to be read that way. ISO/IEC 27035 covers how an incident is handled, ISO 22320 how a coordinated response is commanded, and ISO 22361 how top management leads when the organisation itself is threatened. They describe one escalation, and GRCLens treats it as one: an incident can be declared a major incident and then a crisis without anyone retyping what has already happened.
Incident, major incident and crisis on the same timeline
Handle it: ISO/IEC 27035 and NIST SP 800-61r3
Six stages from creation to closure, each mapped to the ISO/IEC 27035-1:2023 phases and the NIST SP 800-61r3 functions. Gates name what is still missing before a stage can move, clocks track acknowledgement, analysis, containment, resolution, review and regulator notification, and closing seals the evidence with a hash manifest.
Command it: ISO 22320
Declare a major incident and the command layer opens: one incident commander at a time with a recorded hand-over, an incident action plan for each operational period with objectives, owners, strategy, safety and a communications plan, a resources board from request to release, and a formal termination.
Lead it: ISO 22361
Declare a crisis and the crisis room opens on the same record: the crisis team roster with alternates, a decision log that records the options considered and what was known at the time, situation reports that cannot be edited once issued, external parties with their obligation clocks, stand-down criteria and a post-crisis review.
Escalation criteria agreed in advance, applied every time
Under pressure, escalation is usually late. GRCLens checks every open incident against criteria your organisation agrees in advance and shows a suggestion on the incident when one is met. It never changes the tier on its own: a named person declares a major incident or a crisis, and the triggers met are recorded as the basis for the declaration.
The default triggers, each of which can be switched off or tuned:
- A Critical incident
- A regulator-notifiable breach affecting 1,000 records or more
- A customer-facing service down for four hours or more
- A physical incident with safety implications
- Media interest recorded on the incident
- Three or more Critical or High incidents open at once
- A Critical or High incident more than a day past its resolution clock
Business impact in plain English, and pictures before tables
Directors should not have to read an incident register to understand a crisis. The crisis room opens on a board view that a non-technical reader can take in within thirty seconds.
- The narrativeFive sentences or fewer in plain English: what happened, what it means for the business, and what the board is asked to decide. Generated from recorded data, so the same facts always give the same words.
- Six impact tilesOperations, customers, finances, legal and regulatory, people and safety, and reputation, coloured from not affected to critical. An impact nobody has assessed yet is grey, never green.
- What we need from the boardThe decisions the crisis team needs, in one highlighted box, also carried to the top of the executive dashboard.
- Live clocksThe next situation report, every regulator and agency obligation due or late, and how many stand-down criteria have been met.
- Board briefThe same view as a one-page PDF or Word document, with the situation reports as an appendix.
Every obligation on a clock, every statement approved
In the worst cases a crisis brings in regulators, government agencies, law enforcement and insurers. Each one is recorded as a party with its obligation, due date, reference number, status and a named liaison from the crisis team. A party with no due date shows as not due, never as met, and anything late sorts to the top.
Notification deadlines are configured per regulator. Common examples:
| Regime | What is reported | Deadline |
|---|---|---|
| EU GDPR | Personal data breach to the supervisory authority | Within 72 hours of becoming aware |
| EU NIS2 | Significant incident to the CSIRT or competent authority | Early warning within 24 hours, notification within 72 hours, final report within one month |
| EU DORA | Major ICT-related incident to the competent authority | Initial notification within 4 hours of classification and no later than 24 hours after becoming aware |
| Australia SOCI Act | Cyber incident affecting a critical infrastructure asset | 12 hours for a significant impact, 72 hours for a relevant impact |
Communications run through one log. Updates to responders, stakeholders and the board send as before, while anything going to a regulator, government, customers, partners, the media or the public is held until a reviewer who did not write it approves it. For deadlines by country, see our guide to cyber incident reporting deadlines across Asia-Pacific and the Gulf.
A common operating picture for the people running the response
ISO 22320 asks for unity of command, objectives set in an action plan, resources allocated, tracked and released, and a formal hand-over when command ends. Each of those is a record in GRCLens rather than a slide:
- Command roster. Commander, deputy, operations, planning, logistics, liaison, safety, communications and scribe. Only one commander is ever open, and changing commander requires a hand-over note.
- Incident action plan. One per operational period, approved by the commander, with objectives that end as met, not met or carried into the next period.
- Resources board. People, teams, vendors, equipment, facilities and budget moving from requested to assigned, on site and released, with costs in your currency.
- Situation reports and decisions. Situation reports in six fixed sections that cannot be edited once issued, and a decision log whose text is never changed; a reversal is a new decision with a reason.
From the first report to the lesson learned
Baseerah AI briefs
An executive brief of two or three paragraphs for the board and a detailed report covering findings, gaps, decisions, communications, lessons learned and recommended actions. Written only from the recorded facts, with anything missing marked as not recorded.
Scored exercises
Three ready-made scenarios with timed injects, or your own. Twelve objective checks are scored from what the team actually recorded and reported as strong, adequate or needs work, followed by an after-action report.
Evidence that closes the loop
When the post-crisis review is complete, the records are published as evidence against the controls of your ISO 22361 assessment, so the next audit sees what actually happened rather than a plan on a shelf.
| Record | ISO 22361 controls it evidences |
|---|---|
| Declaration and the triggers met | 4.1 crisis concepts and escalation criteria, 5.9 activation and stand-down |
| Crisis team roster with alternates | 5.4 roles, responsibilities and alternates |
| Situation reports | 5.7 information management, 7.2 situational awareness |
| Decision log | 7.1 structured decision-making, 7.3 options analysis, 7.4 decision logging and rationale |
| Approved external statements | 8.1 communication strategy, 8.4 internal communication, 8.6 timeliness and accuracy |
| Regulators, agencies and partners | 8.7 coordination with authorities, 5.12 external relationships |
| Post-crisis review and lessons | 9.5 learning from crises, 9.6 continual improvement |
| Scored exercises | 9.2 crisis exercises, 9.3 validation of the capability, 9.4 learning from exercises |
See how GRCLens assesses the standard itself on the ISO 22361 crisis management page, alongside ISO 22301 business continuity and the NIST Cybersecurity Framework 2.0.
Silos compared with one record
| Typical approach | GRCLens | |
|---|---|---|
| Where the work lives | A ticketing tool for the SOC, a spreadsheet for the crisis team, email for the board | One record that escalates from incident to major incident to crisis |
| Escalation | Judgement under pressure, often late | Agreed triggers suggest the tier; a named person declares it |
| What the board reads | Technical updates forwarded from responders | A plain-English impact narrative, six impact tiles and the decisions needed |
| Regulators and agencies | Deadlines tracked in someone's calendar | Each party with its obligation, reference number, due date and liaison |
| External statements | Sent by whoever drafted them | Held until a reviewer who is not the author approves them |
| Lessons | A review document filed and forgotten | Records published as evidence into the ISO 22361 assessment |
Incident and crisis management: frequently asked questions
What is the difference between an incident, a major incident and a crisis?
An incident is handled by the responding team against agreed service levels. A major incident needs a coordinated command structure, an incident commander and an action plan, which is the subject of ISO 22320. A crisis threatens the organisation's strategy, reputation or viability and needs top management to lead it, which is the subject of ISO 22361. GRCLens keeps all three on one record, so escalating never means starting again in another tool.
Does GRCLens declare a crisis automatically?
No. Configurable triggers suggest a tier, for example a Critical incident or a regulator-notifiable breach affecting more than 1,000 records, and the suggestion is recorded once. A named person always makes the declaration.
Which standards does the module follow?
ISO/IEC 27035-1:2023 and NIST SP 800-61 Revision 3 for incident handling, ISO 22320:2018 for incident command, and ISO 22361:2022 for crisis management. Each lifecycle stage shows its ISO/IEC 27035 phase and NIST function, and crisis records are published as evidence against the ISO 22361 controls.
Is it only for cyber incidents?
No. It handles cyber security, privacy and data breach, IT and service outages, third-party, physical and other incidents, with routing and stakeholders configured by type and severity.
How are regulator and government deadlines handled?
Each regulator or agency is recorded as a party with its obligation, due date, reference number, status and a named liaison, and late obligations sort first on every screen. Notification deadlines are configured per regulator; the examples on this page are a starting point, not legal advice.
Does AI write the board report?
The board narrative and situation reports are rule-based, so the same data always gives the same words. Baseerah, the GRCLens AI agent, can additionally draft a one-page executive brief and a detailed report with findings, gaps and lessons learned. It sees only the recorded facts, marks anything missing as not recorded, and prints its data basis in the document.
Can we rehearse before a real crisis?
Yes. Exercises run through the same screens, clearly marked as exercises and excluded from live figures. Twelve objective checks are scored from the records, such as declaring within 30 minutes or approving every external statement before release, and the after-action report becomes ISO 22361 evidence.
Can it run on our own infrastructure?
Yes. GRCLens runs in our in-region hosting, in your private cloud tenancy, or fully on premises, with the same features in each.
See the crisis room with your own scenario
Bring a recent incident or a scenario your board worries about, and we will walk it from the first alert to the board brief.