Build:
Establish
Your
CIRT
A CIRT that is not clearly defined is not truly in control.
Many organizations only discover who is actually responsible for incident response once an incident is already underway. Without a clearly defined CIRT — agreed roles, escalation paths, and communication structure — every incident starts with a debate about ownership instead of a response. Establishing your CIRT means these decisions are made once, in advance, and simply followed when it matters.
Structure decides how fast you move.
When an incident hits, if the first hour is spent figuring out who is in charge, who needs to be told, and what to do next instead of fighting the attacker . Organizations without a defined CIRT lose that hour, and often several more, before the actual response even begins.
A defined CIRT matters because it:
Removes ambiguity when it's most costly. Clear roles and a RACI matrix mean nobody is guessing who decides what during an incident.
Speeds up escalation and communication. A documented escalation flow and communication structure get the right people involved immediately, internally and externally.
Satisfies regulatory and compliance requirements. NIS2, ISO 27001, KRITIS, IEC 62443, and the CRA all expect a defined, governed incident response capability — not just goodwill.
Turns policy into practice. An Incident Response Policy and sector-specific playbooks give your team something concrete to follow, rather than reconstructing a process from memory mid-crisis.
Creates the foundation exercises build on. You can only stress-test a plan that exists. A defined CIRT is what a tabletop exercise validates.
Most organizations write their incident response plan for the first time the week after their first real incident. Establishing your CIRT before that happens means the structure is agreed and ready — not improvised.
Two packages, one goal:
A CIRT that works before, during, and after an incident.
Small Package:
CIRT Foundation
Define the fundamentals. Fast.
A structured engagement that establishes the core of your incident response capability: who does what, how incidents are classified, and how information flows once something goes wrong.
- Defined CIRT structure
- Roles & responsibilities matrix (RACI)
- Incident classification scheme
- Escalation flow
- Communication structure
- Regulator communication template (baseline version)
- Basic templates
- Alignment workshop
- Summary report
Best for: Organizations starting their structured incident response journey, or those who need a documented CIRT foundation without a full compliance build-out.
sales package
Extended Package: CIRT Foundation, Governance & Compliance
From structure to regulator-ready governance.
Includes everything from the Foundation package, plus the policy, playbooks, and documentation needed to operate under regulatory scrutiny.
- Everything in the Foundation package
- Incident Response Policy
- Playbooks aligned with:
- NIS2
- ISO 27001
- BSI
- KRITISIEC 62443 (for OT environments)
- CRA (Cyber Resilience Act) - Full regulator communication template
- Reporting timelines mapping (e.g., 24h/72h obligations)
- Management escalation guidelines
Best for: Regulated industries, teams with reporting obligations, or those ready to formalize an existing CIRT foundation.
What Every Package Includes
Documentation regulators can verify - not just claim to have.
- NIS2 Directive — Article 21 requires essential and important entities to have documented incident handling procedures and defined responsibilities. Our Foundation and Governance packages give you both.
- ISO 27001 — Annex A requires incident response procedures to be established, documented, and assigned to defined roles. Our RACI matrix and IR Policy feed directly into your ISMS.
- KRITIS — German critical infrastructure operators must be able to name who reports what, to whom, and by when. Our escalation flow and reporting timelines mapping cover this directly.
- IEC 62443 — For OT environments, our playbooks translate general incident response structure into IEC 62443-2-1 program requirements.
- CRA (Cyber Resilience Act) — Manufacturers of products with digital elements face defined reporting obligations for actively exploited vulnerabilities and severe incidents; our Governance package maps these into your existing structures.
Following a Build engagement, you have documentation and defined ownership in place — ready to be tested, and ready to withstand audits and regulatory reviews.
Frequently Asked Questions
Got questions? We’ve got answers. Here are some common queries about our CIRT360: Build
Each exercise is customized based on your industry, threat landscape, regulatory requirements, and organizational structure to ensure scenarios are realistic and relevant to your specific risks.
Key stakeholders involved in incident response should participate, including IT/security teams, management, legal, communications, and relevant business units.
A tabletop exercise focuses on decision-making, communication, and processes at an organizational level, whereas technical simulations or penetration tests focus on identifying technical vulnerabilities.
It is recommended to conduct tabletop exercises at least annually, or more frequently when there are significant changes in the organization, threat landscape, or regulatory environment.