By Nikitas Kladakis, General Manager of ADACOM, Published in NetWeek 504
A security breach is no longer a question of “if”, but “when”. The Incident Response Management System (IRMS) transforms incident response from an ad hoc reaction into a measurable, auditable and continuously improvable operational capability, aligned with NIS2, DORA and ISO 27035.
For years, the security strategy of most organizations was based on a simple assumption: if technological security mechanisms were sufficiently strong, we would not be breached. The experience of recent months, particularly with the use of Artificial Intelligence, has shown that this assumption no longer holds true.
New attack techniques, attacks exploiting vulnerabilities in security systems such as Firewalls and VPNs, supply chain attacks, and social engineering attacks have proven successful even against organizations with significant investments in security.
The Assume Breach philosophy starts precisely from this point. It does not underestimate an organization's organizational or technological protection mechanisms, but accepts that, at some point, an attacker will successfully overcome them and achieve their objective. The question facing management is no longer whether we will be breached, but how quickly we will detect the breach, respond to it and restore normal operations, with the lowest possible operational, legal and reputational cost.
In the area of detection, security has made significant progress. Security Operations Centers (SOCs), SIEM and XDR solutions, and Managed Detection and Response (MDR) services have considerably improved detection capabilities while reducing the time required to identify a cyberattack. However, the area where many organizations continue to fall short is the management of a successful cyberattack.
Anyone who has been in a crisis room during a ransomware attack knows that the technical component of the response process is difficult, but it is not the most difficult part. The response team knows how to isolate compromised endpoints or servers and collect digital evidence. Delays mainly occur when critical authorizations and decisions are required, such as which executive within the organization can order the shutdown of a critical production system, exactly when the Crisis Management Team should be notified and activated, who determines whether the incident falls within the scope of reporting obligations, and who takes responsibility for communicating with the insurer, the Data Protection Officer, supervisory authorities, customers and the media.
When the answers to these questions are sought during the crisis itself, valuable time during the first few hours is lost, decisions are made hastily, and evidence that may be needed for an investigation or even in court is often compromised. Incident response playbooks, however carefully designed, describe technical actions. They rarely define who makes decisions, at what point an issue is escalated, and through which independent communication channels the team communicates when the technological infrastructure has been compromised. An incident response plan in PDF format, stored in a shared folder that has already been encrypted, can hardly be considered preparedness.
The regulatory framework makes the issue even more pressing. The NIS2 Directive, transposed into Greek law through Law 5160/2024, requires an early warning within 24 hours from the moment an entity becomes aware of a significant incident, notification within 72 hours, and a final report within one month. For the financial sector, the DORA Regulation sets equally strict timelines for major ICT-related incidents, with initial notification required within just a few hours of their classification. Both frameworks assign explicit responsibility to members of management. Incident response has therefore ceased to be the responsibility of the IT Department and has become a compliance obligation.
The answer does not lie in yet another technology, but in a different perspective: transforming incident response from plans and procedures into a comprehensive management system, an Incident Response Management System (IRMS). ISO/IEC 27001 transformed information security from a set of measures into a management system, while ISO 22301 did the same for business continuity. Following the same logic, an IRMS transforms static incident response into a dynamic management system based on the well-known Plan-Do-Check-Act cycle: a management-approved policy, clearly defined roles, documented procedures, performance measurement, internal audits and regular reviews.
This approach is consistent with international standards. The third revision of NIST SP 800-61 (2025) now integrates incident response into all functions of the NIST Cybersecurity Framework 2.0 and places particular emphasis on governance, rather than treating it as a standalone process. The ISO/IEC 27035 series provides the principles and framework for incident management design. The IRMS specifies the response approach so that it is horizontally aligned with these standards and connects their respective guidelines into an integrated system that can be audited, measured and, where necessary, certified.
In practice, a mature IRMS is built around six (6) interconnected pillars.
The first is governance. The incident response policy is approved by management, roles are precisely defined, the Incident Manager and the Crisis Management Team are appointed, and it is determined in advance who is authorized to make critical operational decisions, such as shutting down production or disconnecting the organization from the internet.
The second pillar concerns classification and escalation. A unified severity scale, taking into account technical, operational and regulatory criteria, determines whether an incident is “significant” under NIS2 or “major” under DORA, based on predefined criteria rather than the personal judgement of executives or partners under pressure.
The third pillar is operational response: playbooks for the most likely scenarios, ranging from ransomware and Active Directory compromise to email fraud, aligned with MITRE ATT&CK, automation mechanisms, and digital forensics procedures that ensure the preservation of evidence.
The fourth pillar covers communication and notifications: pre-approved communication templates for CSIRTs, supervisory authorities, customers and the media, clear timelines, and alternative communication channels in case the corporate email system has been compromised or is suspected of having been compromised.
The fifth pillar concerns external partners. The security service provider, insurer, legal advisors and critical suppliers are integrated into the system through agreed activation times and clearly defined responsibilities, ensuring that no one is searching for phone numbers in the middle of a crisis.
The sixth pillar is measurement and continuous improvement: performance and risk indicators, tabletop exercises, technical simulations for teams, and a structured process for incorporating lessons learned, with corrective actions monitored through to completion.
The essence of Assume Breach is to prepare the organization effectively before a crisis occurs. The IRMS guides the organization in addressing, in advance, issues that could cost hours or even days during an attack, resulting in significantly greater damage. What is our position on a ransom demand? In what order should systems be restored? Do we have immutable and isolated backups, and have we actually tested their restoration? Can we regain control of Active Directory if the attacker has obtained administrative privileges?
The connection between the IRMS and the business continuity management system is particularly important. These two functions are often designed by different teams, following different directions. However, in a large-scale ransomware attack, they must operate in parallel: one contains and investigates the incident, while the other keeps critical services running. Without shared governance, the risk is twofold. Either recovery restores systems that are still compromised, or the investigation delays recovery beyond the acceptable recovery time.
Operational Technology (OT) environments require equal attention. In industry, energy and transportation, isolating a control system is not a simple technical action, as it may put people and facilities at risk. An IRMS aligned with the IEC 62443 standard provides for separate procedures, roles and responsibilities for OT security incidents, with the active participation of those responsible for their management and operations.
A management system has value only if it can be measured. Beyond the well-known indicators for mean time to detect and acknowledge an incident, an IRMS monitors indicators that reflect the organization's overall response capability: mean time to contain and recover, the percentage of notifications submitted within the required deadlines, the time required to convene the Crisis Management Team, the frequency of exercises, and the percentage of corrective actions completed on time.
These indicators serve a dual purpose. For the technical management team, they highlight areas where the process is delayed or malfunctioning. For the Board of Directors, they transform cyber resilience from a general assurance into a measurable metric that is continuously monitored, audited by internal and external auditors, and provides evidence of the organization's compliance to supervisory authorities and insurers.
The implementation of an IRMS takes place gradually, in phases. The first phase is an assessment of the existing level of maturity against the requirements of NIS2, DORA and ISO/IEC 27035, in order to identify critical gaps. This is followed by the establishment of the governance framework, including approval of the policy, formation of the Crisis Management Team, and definition of the severity scale and notification procedures. Next, playbooks are developed for the most likely scenarios and integrated into cybersecurity operations. The first phase concludes with a tabletop exercise involving management; its findings feed into the continuous improvement cycle.
This phase is completed within a few months and delivers immediate benefits: documented compliance and, most importantly, a team that knows exactly what to do when the phone rings at three in the morning. From that point onwards, maturity evolves at the pace of any management system, through internal audits and an annual management review.
For most organizations, maintaining a fully staffed internal response team on a 24/7 basis is not realistic. This is why a hybrid model prevails: the organization retains governance, decision-making and accountability, while the specialized provider undertakes continuous monitoring, detection, initial containment and digital forensics. For this model to be effective, however, both parties must speak the same language, with common incident classification, shared playbooks and a clear allocation of responsibilities at every stage of the response process.
Following this approach, ADACOM has developed a structured IRMS framework, which has already been presented to ELOT (the Hellenic Organization for Standardization). The objective is to provide Greek organizations with a practical and auditable framework that incorporates the requirements of NIS2, DORA, GDPR and international standards. The framework is directly connected to the ROC, Managed XDR and digital forensics services provided by the company through its Security Operations Centers in Athens and Nicosia, ensuring that incident response does not exist only in theory, but is also implemented and tested in practice.
Assume Breach is often misunderstood as defeatism. In reality, it reflects professional realism. Prevention remains essential, but no measure is infallible, and the difference between an incident that is brought under control and a crisis that threatens business operations is usually determined within the first few hours.
That is why the question every Board of Directors must ask today has changed. It is no longer enough to ask whether the organization is protected. It must ask whether, in the event of a breach tomorrow morning, everyone knows who makes the decisions, what needs to be done, who must be informed and how the business will return to operation, and whether all these processes have already been tested.
The Incident Response Management System developed by ADACOM provides a documented answer to this question, rather than merely an assurance.
You can read the article in Greek here: NW 504 Assume Breach