DESIGN OF THE SOAR-BASED INCIDENT MANAGEMENT ECOSYSTEM FOR BANKING ORGANIZATION

ABSTRACT

Modern information security systems often function within rigid boundaries, creating blind spots that impede end-to-end threat mitigation. The increasing fragmentation of cybersecurity infrastructures presents significant challenges for automated incident response, particularly in financial institutions, where regulatory requirements such as General Data Protection Regulation and Payment Card Industry Data Security Standard mandate rapid breach notification and documented incident response procedures. This paper presents a method for implementing security incident response in banking organizations through an integrated SIEM-SOAR ecosystem, operationalizing human-machine collaboration through dynamic response playbooks. The architecture enables real-time remediation across heterogeneous security domains in critical banking systems. The method is explored through four controlled cyberattack simulations modelled on real-world financial threats: unauthorized personal data transfers, suspicious account modifications, dismissed employee activity, and targeted malware attacks. Pilot results suggest the method reduces Mean Time To Resolution (MTTR) by 66.6–94.2% across all scenarios, while minimizing toolset complexity and procedural overhead. This improvement stems from automated orchestration of response actions across security tools through standardized playbooks, eliminating manual request-response cycles. Specifically, email processing times reduced from 7–10 minutes to 6–10 seconds, and threat intelligence checks from 7 minutes to 6–10 seconds. The distinctive feature is SOAR automation specifically adapted to banking requirements, combining SIEM alert correlation with automated remediation workflows that maintain regulatory compliance. The scope includes banking organizations with established Security Operations Centers managing security tools, requiring existing SIEM infrastructure, network segmentation, defined incident procedures, and organizational readiness for semi-automated response protocols. This study contributes an exploratory, reproducible method for security incident detection and response, bridging the gap between conceptual cybersecurity frameworks and practical implementation strategies in banking security operations.

АННОТАЦИЯ

Современные системы информационной безопасности нередко функционируют в жёстко заданных рамках, формируя «слепые зоны», которые препятствуют комплексному противодействию угрозам. Нарастающая фрагментация инфраструктур кибербезопасности создаёт серьёзные трудности для автоматизированного реагирования на инциденты — особенно в финансовых организациях, где регуляторные требования, такие как Общий регламент о защите данных (GDPR) и Стандарт безопасности данных индустрии платёжных карт (PCI DSS), обязывают оперативно уведомлять об утечках и документировать процедуры реагирования на инциденты. В настоящей работе представлен метод реализации реагирования на инциденты информационной безопасности в банковских организациях посредством интегрированной экосистемы SIEM-SOAR, обеспечивающей взаимодействие человека и систем через динамические сценарии реагирования (плейбуки). Предложенная архитектура позволяет осуществлять устранение угроз в режиме реального времени в рамках разнородных доменов безопасности критических банковских систем. Метод исследован на основе четырёх контролируемых симуляций кибератак, смоделированных по реальным финансовым угрозам: несанкционированная передача персональных данных, подозрительные изменения учётных записей, активность уволенного сотрудника и целевые атаки с применением вредоносного программного обеспечения. Результаты пилотного тестирования свидетельствуют о том, что метод сокращает среднее время устранения инцидента (MTTR) на 66,6–94,2% по всем сценариям при одновременном снижении сложности инструментальной базы и процедурных издержек. Данное улучшение достигается за счёт автоматизированной оркестрации действий по реагированию между инструментами безопасности посредством стандартизированных плейбуков, исключающих ручные циклы запрос-ответ. В частности, время обработки электронной почты сократилось с 7–10 минут до 6–10 секунд, а время проверки данных об угрозах — с 7 минут до 6–10 секунд. Отличительной особенностью является автоматизация SOAR, адаптированная к требованиям банковского сектора и сочетающая корреляцию алертов SIEM с автоматизированными рабочими процессами устранения угроз при соблюдении нормативных требований. Область применения охватывает банковские организации с действующими центрами управления безопасностью (SOC), управляющими инструментами безопасности и располагающими существующей инфраструктурой SIEM, сетевой сегментацией, задокументированными процедурами реагирования на инциденты, а также организационной готовностью к полуавтоматическим протоколам реагирования. Настоящее исследование представляет собой воспроизводимый поисковый метод обнаружения инцидентов информационной безопасности и реагирования на них, устраняя разрыв между концептуальными фреймворками кибербезопасности и практическими стратегиями их реализации в банковских операциях по обеспечению безопасности.

Keywords: Incident Response, Automation, Attacks, Banking Security, Mean Time To Resolution.

Ключевые слова: Реагирование на инциденты, Автоматизация, Атаки, Безопасность банковского сектора, Среднее время устранения инцидента.

Introduction

The accelerated digital transformation of financial services, intensified by recent global events such as COVID-19 [1], has fundamentally reshaped the banking sector's operational landscape. New industry requirements for business performance, such as the need for contactless financial products and services [2], are increasing the formation of digital infrastructure in banks and other financial institutions. This shift moves institutions away from the traditional approach to the sector. However, the growing number of digital banking customers and the large volume of personal information managed by financial institutions have created significant vulnerabilities. The banking sector is now permanently exposed to a wide range of threats. Credential stealing, phishing schemes, investment fraud, identity theft, coercion, and other sophisticated hacking tactics are the main threats banks must monitor [3]. The banking sector's position as custodian of financial assets, processor of high-volume real-time transactions, and critical component of economic infrastructure makes it a disproportionately attractive target for cybercriminals and creates unique incident management requirements. Therefore, banking organizations should be ready for such situations by using advanced threat detection and rapid incident response [4]. The dynamic and unpredictable nature of cyber threats underscores the need for effective incident management planning. Proper planning can minimize financial, operational, and reputational losses.

The banking industry faces sector-specific challenges that make effective incident management particularly critical. The criticality of incident management in banking stems from several factors that distinguish it from other sectors. To begin with, financial institutions face unique regulatory pressures. These include compliance with international standards and regional frameworks that prescribe specific incident response times and reporting requirements. For example, Article 33 of the General Data Protection Regulation (GDPR) requires breach notification to supervisory authorities within 72 hours of detection [5]. The Payment Card Industry Data Security Standard (PCI DSS) Requirement 12.10 also requires documented incident response procedures and regular testing [6]. In addition, the financial consequences of security incidents in the banking sector go beyond direct losses. Consequences include regulatory fines, reputational damage affecting customer confidence, and potential systemic risks to financial stability. Banks represent disproportionately high-value targets—according to IBM's 2024 Cost of a Data Breach Report, the financial services sector incurs average breach costs of USD 6.08 million per incident, 22% higher than the global average of USD 4.88 million [7]. Also, banks operate complex, heterogeneous IT infrastructures with legacy systems integrated alongside modern digital platforms, creating unique challenges for incident response processes that generic management cannot address. Finally, the requirement for continuous operation (24/7 availability) and high transaction volumes in the banking environment leaves minimal tolerance for long incident response times, making effective incident management planning not only beneficial but necessary to ensure business continuity. The effectiveness of incident management systems directly determines whether financial institutions can maintain business continuity, protect customer trust, and comply with increasingly stringent regulatory requirements.

Therefore, research on the development of incident management systems in banking organizations is relevant.

Literature review and problem statement

The state, as the highest governing body, sets the requirements that organizations must comply with, including those related to security, thereby establishing an absolute benchmark. The paper [8] presents the results of research on traditional cyber defense methods based on monitoring the network and end devices. Shown that they are becoming ineffective in the face of modern threats, which is why organizations and countries must collectively create systems to track and control critical infrastructure from attackers. Other authors [9] similarly reveal that at the national level, there is a lack of evidence-based knowledge sharing and a structured practical framework for these requirements. This gap makes national security teams vulnerable when adopting and recommending new strategies. Moreover, the results of focus group discussions with 15 national CSIRT team members from different countries [9] and theoretical research performed during the mentioned study [8] show the high requirement for response and preventive measures. Despite the rapid development of security tools, frameworks, and international standards, there are unresolved issues related to a clear technical explanation for incident management in banking organizations. The reasons for this may be that official materials still focus on "how security should be" rather than "how it should be done" in practice [10]. Paper [8] only focuses on analyzing current threats and disadvantages of traditional defense methods, but does not detail possible new counteraction strategies.

Another study [10] introduces the vision of forming and evaluating the IM process of the company by assessing the current instance concerning the reference model, such as ISO 27035. For that, they provide the concept of process deviation and assign the loss cost of the incident by validating the input event logs dataset through the mandatory phases of the incident investigation. The authors conclude that deviation at the detection phase is more severe because it results in the further loss of information necessary for accurate incident processing. But there were unresolved issues related to handling unstructured log formats and incomplete data. The reason for this may be objective difficulties associated with privacy concerns and the ethical aspect of the research topic. There is a limited number of publicly available datasets for framework and model testing. For example, the authors in [9] were limited to using only free tools, open-source software, and publicly available data, excluding closed-source and commercial tools or datasets. Similarly, in the study [10], only structured log formats were considered, with no attention given to issues like missing, incomplete, or incorrect data – factors that are crucial for creating a simulation environment that closely resembles real-world conditions.

Continuing the detection phase's topic, many SOC (Security Operation Centre) teams rely on the SIEM (Security Information and Event Management) system, which helps to normalize and correlate large volumes of logs to recommend triggers for analysis [11]. The author's proposed modular architecture illustrates the system's influence on improving threat detection, which depends on the accurate and extended development of event-matching criteria for generating offences. But there were unresolved issues related to technical implementation details beyond basic system concepts. The reason for this is that, despite the widespread use of tools like SIEM, the limited number of openly available articles and papers means that authors often focus only on the essential information – basic system concepts – without addressing technical implementation or improvements to incident management (IM) [11].

On the other hand, some papers deny the sufficiency of the SIEM as the response implementation tool. The authors of the work [12] conducted a qualitative study in the form of a survey on the topic of implementing single-response management tools by security researchers and industry practitioners. Also, they analyzed the latest views on the usage of AI/ML by reviewing works published in academic journals, conferences, websites, blogs, white papers, etc. Paper [12] states that it is essential to involve automation and orchestration solutions to effectively investigate and make decisions that increase the effectiveness of incident response processes – by going from a human-in-the-loop (HITL) model to human-on-the-loop (HOTL), where machines handle tasks separately while analysts’ step in only when necessary. Authors in paper [13], by performing testing experiment of the usage of security protection solutions to collect background opinions from the industry and research experts, state that even when all the critical services and log sources are being connected and processed by SIEM, their user experience suffers from the burden of sorting through the large amount of information generated by different vendors' interpretation. As a result, such an inconsistent workflow and ineffective monitoring directly affect human involvement in the entire process of incident response and slow the process down because machines should wait for the analyst's decision before taking action [12]. But there were unresolved issues related to participant engagement affecting real-world performance representation. The reason for this may be that even if experiment was performed in a specially formed network environment, differences in participant effort and engagement may have affected results, making it unclear whether variations reflect real-world analyst performance [13].

Considering the mentioned issue, various approaches were taken to analyze this problem and provide a reliable solution. Some researchers used case studies with a projection of the conceptual framework, while others concentrated on conducting experiments to prove the effectiveness of technical IM project design. The first method is used by two different groups of researchers in papers [14, 15], who similarly claim that alert fatigue – loss of sensitivity to warnings due to a growing number of false positives- exists because of the lack of a single automation coordination management component that will combine all servers and security tools in one place. Both present a unique framework model for improving typical infrastructure with minimum SIEM usage.

Paper [14] formalizes the divide-and-conquer strategy to avoid the alert problem by introducing the optimization of filtering and correlation processes of SIEM. Additional visualization of generated offenses and usage of the algorithm formed to summarize alerts into closely related events effectively reduces FP and increases the recall rate. At the same time, another paper's [15] suggested a framework that introduces the idea that the problem should be resolved by adequately supporting SOC operators, adding automation and orchestration, and resolving overwhelming alert issues. It stands for AI usage in the Automated, Augmented, and Collaborative modes of decision-making for human teaming as a distinct service. Despite the high level of flexibility and minimum level of human involvement, there were unresolved issues related to human decision and AI system biases that the suggested framework creates from limited training data and algorithm choices.

Moving on to the point of automation and orchestration in the previously mentioned papers, a way to overcome these difficulties can be through such security solutions as the SOAR (Security Orchestration Automation Response) system. This approach was applied and evaluated during IM project design in the studies conducted by the authors in works [16, 17]. In these studies, the researchers emphasize the importance of team preparedness in the event of an incident by simulating response and investigation scenarios, including the automated assignment of tasks and notifications. To test this claim, both papers base their experiments on the design of a playbook and its testing in the case of an attack. However, paper [16], by checking the designed playbooks against four vignettes formed as a result of the qualitative survey with experts, has limitations in representing SOAR as the activity diagram and integrating it into the MITRE ATT&CK framework, significantly focusing on the specific component (Microsoft Sentinel) and covering a small part of the measurement against social engineering. Another author [17] provides the design of a standardized playbook for any incident category that requires a testing environment to test its effectiveness.

The paper [17] presents the results of research on designing a comprehensive cyber incident operational playbook for the 5 main subcases. However, there were unresolved issues related to the validation and testing of this scenario in the real SOC environment. Similarly, for further research and a conclusions paper [8] shows the necessity to conduct practical verifications in various infrastructures and organizations to test new defense methods.

Additionally, strategies for security function take the form of a general approach. However, depending on the domain-based environment's features, incident response and detection may also vary and require unique protection resolutions.

When the company experiences growth across all quantitative metrics, from server proliferation to an expanding fleet of end-user machines, it becomes much more vulnerable to attackers [18]. It is no secret that banking organizations implement countermeasures to these risks through the Cybersecurity Operation Center (CSOC). However, a multitude of security protection tools such as Intrusion Detection Systems (IDS), Endpoint Detection and Response (EDR), Next-Generation Firewalls (NGFW), Data Loss Prevention (DLP), and more, which form a traditional vision of security architecture, produce a significant challenge of extra analysis, decision-making, and manual response activation, due to the influx of alerts from diverse systems and applications [18].

The manual and protracted incident response process slows down infrastructure recovery. More importantly, it creates blind spots where vulnerabilities can go unnoticed. Even to perform ordinary tasks, such as blocking a malicious address, an analyst has to submit a separate request and wait for a response from the responsible administrator. As a result, the resolution of incidents is delayed, leading to a growing financial and operational impact on the organization.

All this suggests that it is advisable to conduct a study on forming incident management processes for banking organizations by implementing and validating SOAR-based automation solutions.

The novelty of this study lies in the combination of elements that existing work has not addressed simultaneously: a banking-domain-specific adaptation of SOAR automation with playbooks shaped by GDPR and PCI DSS constraints; a four-phase structured implementation method connecting conceptual frameworks with practical deployment; cross-system orchestration across six integrated security tools validated in a controlled environment; and exploratory quantitative evidence of MTTR reductions establishing a replicable benchmark for future studies in banking cybersecurity.

The aim and objectives of the study

The aim of the study is to design, implement, and conduct exploratory pilot validation of a method for implementing security incident response in banking organizations through an integrated SIEM-SOAR ecosystem, that provides effective detection, analysis, response, and recovery after cyberattacks by formalizing detection and response procedures as structured, reproducible steps and ensuring compliance with regulatory requirements.

To achieve this aim, the following objectives were accomplished:

1) To formalize a method for security incident detection and response and implement an incident management ecosystem architecture that integrates disparate security systems into a unified SOAR platform for banking organizations;

2) To develop automated incident response playbooks for selected cyberattack types that leverage the ecosystem's integrated capabilities;

3) To provide exploratory quantitative evidence of the ecosystem's effectiveness through controlled attack simulations by comparing incident response time improvements with traditional manual approaches.

Methods and Materials

Object and hypothesis of the study

The object of this study is incident management processes in banking organizations, where rapid threat response and regulatory compliance are critical. The hypothesis is that a SOAR-based incident management ecosystem reduces incident response times compared to traditional manual approaches using predefined playbooks and systems integrations. Several assumptions were made. Banking organizations are assumed to operate heterogeneous security infrastructures with multiple protection tools capable of integration with SOAR platforms. All systems are assumed to generate logs and alerts suitable for SOAR platform analysis. The study focuses specifically on the incident response phase; threat detection is considered already completed within the dataset, with attacks pre-identified and classified. To simplify the analysis, the study focuses on four primary attack scenarios without modelling all possible variations. The complexity of real-world banking operations, including transaction volumes and system interdependencies, is not fully represented in simulations. Organizational factors such as change management and training requirements are considered outside the scope. Network latency and potential integration issues are assumed minimal. Playbook execution is assumed to proceed without human intervention delays, enabling accurate measurement of automated response capabilities.

Method for Implementing the Security Incident Response Ecosystem

The proposed method is implemented through four sequential phases that together constitute a structured procedure for deploying and operationalizing security incident detection and response in a banking environment.

Phase 1: Capability Assessment. This phase involves studying the SOAR platform capabilities to understand possibilities for incident management. The assessment examines core platform functionalities, including workflow development, incident tracking, integrations with external security tools, and task orchestration mechanisms. The phase determines which incident management processes can be automated and identifies technical requirements for connecting disparate security systems.

Phase 2: Component Identification. This phase identifies security systems to be included in the ecosystem based on their role in incident investigation and response. The analysis examines standard incident workflows to determine required system categories (detection and correlation systems, identity management systems, communication systems, threat intelligence platforms, and endpoint protection solutions, etc).

Phase 3: System Deployment and Integration. The testing environment is deployed in an isolated network segment with the SOAR platform configured as the central orchestration component. Integration architecture is established by defining information flows and communication protocols between the platform and selected security systems. For each integrated system, connection parameters are configured, query and action interfaces are defined, and bidirectional communication is verified through integration testing to confirm successful interaction capabilities.    

Phase 4: Playbook Development. Response workflows are formalized as structured playbooks that define incident handling procedures following standard incident management phases: detection, collection, enrichment, analysis, approval, remediation, and notification. Each playbook specifies the sequence of automated tasks, integration points with security tools, conditional logic based on incident attributes, and decision gates where human judgment is required. The playbooks are designed to handle routine data collection and action execution automatically while escalating to analysts only for decisions requiring expertise.

The resulting ecosystem integrates multiple security systems through central orchestration that automates incident response workflows.

Dataset and Testing Environment

For the experimental conditions, the dataset from the QRadar Experience Center [19] is used to test the hypothesis that SOAR-based automation is expected to reduce incident response time compared to manual workflows. Unlike static log collections, the QRadar Experience Center dataset operates as an event-driven simulation: each scenario is triggered by a minimal set of qualifying events that satisfy the corresponding correlation rule, upon which SIEM continuously generates matching activity for the duration of the simulation. Consequently, incident response timing begins at the moment of first offence generation and ends at case closure; total event volume is not a fixed parameter and does not affect the comparative MTTR measurement.

The four experimental scenarios are described in Table 1, classified by attack vector and level of complexity.

Table 1.

Simulation Cases Overview

GDPR: Personal data transferred to a third country: The Correlation Rule triggers when an Event Category of FTP In Progress, SSH In Progress, SSL Session In Progress, TFTP Session In Progress, P2P In Progress, Data Transfer, SMB Session In Progress, or SMTP In Progress is detected in Check Point firewall logs, and the Destination IP falls outside the defined regional scope. The Rule applies if the Source and Destination IPs are valid, not equal, and Payload Normalization detects Email, Passport Number, Birth Date, or IBAN. Log samples of the SSL Tunneling event type were used from the QRadar Experience Center dataset. The selected records capture outbound communication over port 8444 originating from the IBM_SALES network group. The events contain an identified user context — username sampleuser (user1) and email address user1@experiencecenter.qradar.ibm.test — which serve as the PII artifacts that trigger the GDPR correlation rule in SIEM and initiate the offence generation.

Suspicious account modification: The Correlation Rule monitors Windows Security Event Log for account lifecycle events using Reference Sets with a Time-to-Live of 24 hours. The Target Username from Authentication.User Account Added and Authentication.User Login Success events are stored in the UserAccountCreated and UserAccountUsed Reference Sets, respectively. An offence is triggered when Authentication.User Account Removed or Authentication.Computer Account Removed events are detected with a username present in both Reference Sets within the 24-hour window, indicating a full create-use-delete cycle of a temporary account. Log samples of Windows Security Event Log were used from the QRadar Experience Center dataset: account creation of tempuser by badadmin (EventID 4720: A user account was created), subsequent workstation login (EventID 4624: An account was successfully logged on), and account deletion (EventID 4726: A user account was deleted).

Dismissed employee activity: After an employee was fired, their account wasn't disabled as required. The ex-employee used this still active account to access company systems and perform suspicious activities, which were only discovered during a later security check. The Correlation Rule monitors Windows Security Event Log against a Reference Set of dismissed employee usernames maintained by the security team. The offence is triggered when EventID 4767 (A user account was unlocked) or EventID 4722 (A user account was enabled) is detected for a username present in the dismissed employees Reference Set, indicating unauthorized reactivation of a terminated account.

Targeted attack: The Correlation Rule detects a multi-stage attack chain across heterogeneous log sources: Bluecoat proxy, Check Point firewall, Oracle DB, and Linux OS. Three correlation rules operate in conjunction: suspicious data transfer activity from a critical asset by an identified compromised user; local-to-local database port scanning exceeding 29 events to different destinations within 10 minutes; and excessive firewall denies from a single source exceeding 40 events across 40 destinations within 5 minutes. All three conditions are chained into a single offence for investigation. Log samples from the QRadar Experience Center dataset include: Misc GET Request and Firewall Drop events from Check Point firewall, ESTABLISH connection from Oracle DB, and SFTP Session Open and SFTP Session Closed events from Linux OS, initiating the offence generation in QRadar SIEM.

Experimental Scenarios

To evaluate the effectiveness of SOAR integration in the incident response process, controlled testing was conducted by launching the attacks described in Table 1 in an isolated testing environment using the QRadar Experience Center dataset. For each attack scenario, a standardized incident response workflow was developed based on ISO 27035 guidelines, documenting the sequence of steps required for detection, analysis, containment, eradication, recovery, and notification to stakeholders.

The same experienced cybersecurity engineer executed both workflow variants for each scenario, ensuring equivalent analyst experience across conditions. To control for order effects, the Standard Workflow was always executed first, followed by a full environment reset — clearing active cases, restoring baseline system state, and reloading the original event dataset — before the SOAR-Optimized Workflow execution. Response times were recorded using system-generated timestamps from the IBM Security SOAR platform and QRadar SIEM audit logs; no manual timing was applied, eliminating analyst-introduced timing bias. For Analysis and Approval steps, timestamps were recorded automatically; since these steps are identical in both workflows, any residual variance does not bias the comparative MTTR results.

1) Standard Workflow: Manual SIEM-based incident response representing current operational practice in the organization's Security Operations Center (SOC). Analysts manually query QRadar SIEM, access security tools through native interfaces, and coordinate via email following documented standard operating procedures;

2) SOAR-Optimized Workflow: Integrated SIEM-SOAR ecosystem approach with automated playbooks orchestrating response actions across multiple security tools.

Evaluation Metrics

The fundamental metric, MTTR (Mean Time to Resolve), is used to test the suggested framework's response efficiency. It represents the average time to perform mitigation steps from detection to resolution [17], excluding the preparation of the post-incident report. MTTR was calculated for both the standard workflow and SOAR-optimized workflow across all four attack scenarios to enable comparative analysis.

The percentage improvement in MTTR is computed as:

where  is the mean resolution time under the standard workflow and  is the mean resolution time under the SOAR-optimized workflow. This metric is applied consistently across all four attack scenarios reported in Tables 2–5.

Response time was measured from the moment of attack detection (simulation start) until incident closure (status changed to "resolved"). For the standard workflow, time measurements captured manual analyst actions including SIEM queries, tool navigation, and inter-departmental coordination. For the SOAR-optimized workflow, measurements included both automated task execution and required human intervention points (analysis and approval steps). All simulations were conducted in an isolated testing environment with consistent system configurations, using the QRadar Experience Center dataset to ensure reproducible attack patterns. The detailed breakdown of time consumption for each workflow step is presented in Results Section (Tables 2–5).

Results and discussion

Ecosystem Overview

Infrastructure Overview: The central area of focus in recent cybersecurity advancements is the integration of multiple security technologies, which has proven instrumental in strengthening defenses [20]. All of them have unique functionality for protecting digital assets. For example, the firewall acts as a security barrier between trusted and untrusted networks by filtering data packets to prevent unauthorized access; the antivirus scans for and isolates malicious threats like viruses and ransomware; Intrusion Detection Systems (IDS) monitor network activity, detecting suspicious behaviors through either host-based or network-based monitoring; access control mechanisms regulate user permissions, incorporating multi-factor authentication and role-based access control to prevent unauthorized access [20]. Each server and machine generate a ton of logs that should be managed and analyzed for threat conditions. This analysis examines a knowledge base that includes attack signatures, attack behavior rules, network security policies and network configuration information through SIEM integration [21].

Tools Outline: To evaluate incident response resilience and continuity, we will use the standard infrastructure described above as our foundation. Our proposed framework, illustrated in Fig. 1, integrates two key components: advanced detection technologies (SIEM) and structured automation and orchestration capabilities (SOAR) (Fig. 2).

Figure 1. Framework of the proposed approach

Figure 2. SIEM-SOAR Workflow

The framework features comprehensive playbook scenarios that align with incident handling phases [22]. The implementation of other protection systems will be described separately for each simulation case.

Testing Environment:

1) SIEM: IBM Security QRadar SIEM;

2) SOAR: IBM Security SOAR;

3) AD: Microsoft Active Directory;

4) Email Server: Microsoft Exchange Server;

5) TI: Threat Intelligence platform Virus Total;

6) EDR: Fidelis Endpoint EDR.

Method for Security Incident Response: Per-Scenario Procedures 

Demonstration – GDPR: Personal data transferred to a third country: According to the security policy, employees are strictly prohibited from distributing personal information. An employee shares personally identifiable data (PII) — email addresses, passport information, social security numbers — to a third country not governed by GDPR, whether intentionally or accidentally. For banks, such violations carry exceptionally high penalties and can result in immediate regulatory sanctions and loss of operating licenses.

1) Response: The demonstrated incident violates our internal security rules and requires immediate investigation – Fig. 3.

2) Optimized Response: SOAR technology enables automated data enrichment regarding user behavioral patterns by initiating query requests, eliminating the need for manual SIEM searches. Additionally, it provides functionality to check artifacts associated with the incident case for Indicators of Compromise through widely used databases. This automated enrichment is particularly critical in banking, where GDPR's 72-hour breach notification window leaves minimal time for manual investigation — automated IOC checking eliminates delays that could result in regulatory penalties.

Figure 3. Response Workflow for Demo#1

Demonstration – Suspicious account modification: Account creation and usage are controlled by the IT Department. To obtain an additional account, an employee submits a request through a specialized platform or sends an official letter via email with an explanation of the reason for the request. This type of attack shows a violation of the access control procedure — an account is created, used, and deleted within a short time, which is considered potentially malicious behavior. In the banking domain, this activity may indicate privilege escalation for unauthorized fund transfers or manipulation of financial records, making rapid detection critical.

1) Response: The following algorithm of actions is used as a response to these incidents – Fig. 4.

2) Optimized Response: For SOAR optimisation, the workflow will be updated by automatically matching requests using Reference Set Enrichment, correlation between events inside the system, and integration with the Email Server for immediate custom notification. In the banking context, immediate notification to the IT Department is mandated by PCI DSS access control requirements — automated email delivery reduces the risk of delayed remediation that could expose financial systems to unauthorized access.

Figure. 4. Response Workflow for Demo#2

Demonstration – Dismissed employee activity: The accounts of dismissed employees are immediately deactivated as a mandatory part of the offboarding procedure. The IT team revokes all access credentials from all corporate systems according to established security protocols. Post-termination activity detected from a dismissed employee's account represents a critical security violation requiring urgent investigation. In the banking sector, terminated employees may retain access to customer accounts, transaction systems, and sensitive financial data, potentially leading to fraud or data breaches with substantial financial and legal repercussions.

1) Response: A suggested foundation for the incident response is outlined in the process workflow presented in Fig. 5.

2) Optimized Response: Apart from the previously mentioned email server integration, the SOAR solution features a robust integration with Active Directory, providing instant access to detailed employee information that powers both manager notifications and account control functions. This connection enables seamless disable and enable actions when required. In the banking sector, PCI DSS Requirement 8.2 mandates immediate access revocation upon employee termination — automated AD account disabling eliminates the multi-department coordination delays typical in banking environments where HR, IT, and security teams must act in sequence.

Figure 5. Response Workflow for Demo#3

Demonstration – Targeted attack: A phishing email delivered malware to an employee workstation, establishing a Command-and-Control (C&C) connection that enabled the attacker to move laterally through the network in search of critical company assets. For banking organizations, such attacks carry uniquely severe consequences — lateral movement reaching payment processing systems, SWIFT infrastructure, or customer databases can result in direct financial theft, large-scale compromise of customer records, and systemic disruption to financial services that generic enterprise environments do not face at the same scale. The incident indicates gaps in endpoint protection coverage, outbound traffic monitoring, and application whitelisting enforcement. Regular employee awareness training on phishing detection remains an essential preventive control.

1) Response: To remediate such a case, the response workflow in Fig. 6 is used.

2) Optimized Response: The implemented automated response plan incorporates EDR integration to quarantine affected workstations immediately upon detection, prioritizing containment speed over extended manual investigation — a banking-specific design choice where the cost of a false positive isolation is far lower than the risk of lateral movement reaching financial systems. The system performs data enrichment to identify current victims and potential phishing patterns, enabling proactive alerting to employees about possible vulnerabilities. 

Figure 6. Response Workflow for Demo#4

Fig. 7 illustrates how our optimised workflow transforms the security analyst experience within SOC environments.

Figure 7. Standard vs Optimized Workflow

As shown, the traditional workflow (left) involves numerous tools, complex decision paths, and extended response times measured in hours or days. In contrast, our unified analyst workflow (right) simplifies the process, reducing the number of tools and steps. This transformation is particularly valuable in modern SOCs facing increasing alert volumes and analyst fatigue. The unified workflow not only reduced response time from hours/days to minutes, but also reduced the cognitive load on analysts.

Attack Simulation Result

Tables 2–5 present the comparative time consumption of each stage for the standard workflow and SOAR-based approach across all four attack scenarios.

Table 2.

Comparison of Response Time Results for Demo#1

Table 3.

Comparison of Response Time Results for Demo#2

Table 4.

Comparison of Response Time Results for Demo#3

Table 5.

Comparison of Response Time Results for Demo#4

Across all four attack scenarios, SOAR-based response indicated reductions in total response time, with improvements ranging from 66.6% to 94.2%. The most significant improvement was in Demo #2 (Suspicious account modification), with a 94.2% reduction, followed by Demo #4 (Targeted attack) and Demo #3 (Dismissed employee activity), with improvements of 74.3% and 77.4%, respectively. Even Demo #1 (GDPR: Personal data transferred to a third country), which showed the smallest change, still indicated a considerable 66.6% reduction in resolution time.

Additionally, the automated correlation of security events in the SOAR workflow enabled faster identification of attack patterns, particularly beneficial in the complex scenarios presented in Demo #3 (Dismissed employee activity) and Demo #4 (Targeted attack).

Our detailed analysis revealed specific patterns in time reduction across different process types:

– Email processing showed notable improvement across all scenarios, reducing from 7–10 minutes to just 6–10 seconds (over 98% reduction);

– IOC checking processes were reduced from 7 minutes to as little as 6–10 seconds (over 97% reduction);

– Collection activities typically improved from 10 minutes to 1.12–2.08 minutes (79–89% reduction).

Discussion of SOAR-based optimization results

The practical significance of this research lies in providing banking organizations with an exploratory implementation framework that provides initial evidence of incident response time reductions through SOAR automation. For financial institutions facing regulatory pressures (GDPR's 72-hour breach notification requirement, PCI DSS incident response mandates), the documented reduction in email processing (from 7–10 minutes to 6–10 seconds) and threat intelligence checks (from 7 minutes to 6–10 seconds) directly addresses compliance challenges where response speed determines regulatory penalties. The framework's ability to centralize coordination across six heterogeneous security systems (SIEM, EDR, Active Directory, email, threat intelligence, endpoint protection) solves the operational challenge faced by banking SOCs managing fragmented tool ecosystems that generate alert fatigue and analyst burnout. By automating routine data collection and handoffs while preserving human oversight for analytical decisions, the approach enables banks to maintain 24/7 incident response capabilities with existing analyst resources. The reproducible four-phase implementation methodology (Capability Assessment, Component Identification, System Integration, Playbook Development) provides financial institutions with practical guidance for deploying similar automation, addressing the industry gap where theoretical security frameworks lack implementation specifics. For banking organizations managing high transaction volumes and customer data, the reduction in Mean Time to Resolution translates directly to minimized financial losses, reduced regulatory exposure, and preserved customer trust during security incidents. It should be noted that this study focused exclusively on response time; whether SOAR automation maintains or improves response quality — including decision accuracy, false positive rates, and analyst workload — remains an open question for future investigation.

The scientific contribution of this study addresses three critical gaps in cybersecurity automation research. First, it provides exploratory evidence of SOAR effectiveness in domain-specific incident management, quantifying automation impact across different process categories: routine tasks achieve 79–98% time reduction (data collection, IOC checking, notifications) while analytical processes remain constant, establishing evidence-based boundaries for automation investment in security operations. This addresses the validation gap identified in [16, 17] where playbook frameworks lacked real-world performance metrics. Second, the research establishes a structured methodology connecting conceptual incident management frameworks (ISO 27035) with practical automation implementation through four documented design phases, REST API integration patterns, and Python-based orchestration scripts. This bridges the theory-practice gap noted in prior work [8, 10] where security guidelines describe "what should be done" without technical implementation details. Third, the study contributes domain-specific knowledge for banking cybersecurity by documenting how regulatory requirements (GDPR, PCI DSS), operational constraints (24/7 availability, high transaction volumes), and infrastructure complexity (heterogeneous systems, legacy integration) create unique automation requirements that generic incident management approaches cannot address. The controlled experimental methodology with standardized attack scenarios (QRadar Experience Center dataset) and reproducible testing conditions establishes an exploratory approach for comparing automated versus manual security operations, providing a replicable research framework for future SOAR effectiveness studies across different organizational contexts and attack vectors.

In contrast to [17], where operational playbooks were designed but validation and testing in real SOC environments remained unresolved without quantitative performance metrics, this study provides initial evidence for SOAR-based incident management through four controlled attack scenarios with documented MTTR reductions of 66.6–94.2%. This is made possible by REST API and Python-based integration scripts that enable seamless communication between disparate security systems (QRadar SIEM, Fidelis EDR, Active Directory, Exchange Server), eliminating manual data transfer processes that typically consume significant analyst time.

In contrast to [16], where playbook designs were tested but had limitations in comprehensive integration and focused on specific components (Microsoft Sentinel) without measuring response time performance, this implementation provides evidence of cross-system orchestration across Email, TI, EDR, and AD that reduces email notification times from 7–10 minutes to 6–10 seconds (Tables 2–5). The underlying mechanism relies on pre-defined email templates with dynamic content insertion that automatically populates with necessary case information and automated handoffs that provide immediate task activation through orchestrated workflows, addressing the substantial time losses that occur in standard response workflows (Fig. 7) due to non-immediate task activation when human involvement is required and when waiting for case performance by another department.

In contrast to [14, 15], where frameworks addressed alert fatigue through SIEM optimization and AI-based decision support but created system biases from limited training data, this SOAR-based approach reduces multi-specialist coordination dependencies by centralizing information and automating handoffs. This result allows a single analyst to effectively manage incidents that previously required coordination across multiple specialists from different security domains, enabling analysts to maintain focused attention on critical analytical tasks rather than system navigation. This is made possible by automated context-switching and centralized information management.

In all scenarios (Tables 2–5), processes requiring human intervention (Analysis and Approval steps, both at 10 minutes) remain unchanged between standard and SOAR approaches, indicating that human analytical work and decision-making remain constant factors that cannot be fully automated – a limitation also observed in [12, 13] regarding the necessity of maintaining human oversight in incident response processes.

Limitations

The study has certain limitations:

1) the proposed ecosystem is created based on specific infrastructure requirements: security tools with REST API support (tested with QRadar SIEM, Fidelis EDR, Active Directory, Exchange Server), network connectivity with latency < 100ms, and dedicated SOAR platform resources;

2) experiment validation is limited to the four tested attack scenarios (GDPR violation, account modification, dismissed employee activity, targeted attack). The experimental response model was simplified for controlled testing; real-world implementations may require additional workflow to meet the specifics of a particular company's production infrastructure. Scalability to real-world banking SOC conditions — including concurrent incident handling, high alert volumes, and large-scale deployments across distributed teams — was not evaluated and represents a necessary direction for future validation;

3) the research focused primarily on optimizing technical integration processes between security systems. Organizational factors such as team training requirements, change management procedures, cost-benefit analysis, and long-term maintenance overhead were not comprehensively evaluated, limiting understanding of full implementation complexity;

4) response times documented in Tables 2–5 may vary based on incident volume (tested with 1 incident at a time), analyst experience level (tested with a single analyst), time of day affecting system load, and SIEM database size. Performance under different conditions requires additional validation. Each scenario was executed once per workflow type; no repeated trials, variance measures, or confidence intervals were computed. Results should therefore be interpreted as exploratory pilot evidence rather than statistically validated findings;

5) this study measured response time as the primary metric; the impact of SOAR automation on response quality was not assessed. False positive rates of automated containment actions, over-blocking risk, correctness of automated remediation decisions, and analyst cognitive workload under automation-assisted conditions remain unmeasured. Faster resolution does not inherently guarantee better resolution — future research must evaluate these quality dimensions to provide a comprehensive assessment of SOAR effectiveness in banking SOC environments.

For further research, several development directions are planned to address the identified limitations and enhance the ecosystem's capabilities.  First, and most immediately, repeated experimental trials with variance analysis and confidence intervals are required to elevate the current exploratory results to statistically validated findings. Second, integrating AI-based assistants or machine learning models to predict incident classifications and suggest response actions for widespread attack types while maintaining human oversight for final decision-making. Third, developing dynamically adaptive workflows that adjust response procedures based on real-time incident context, severity levels, and threat intelligence would address the static logic limitation and improve handling of unpredictable attack scenarios. Fourth, we plan to develop comprehensive response plans incorporating critical parameters such as service level agreements (SLAs), automated task escalation mechanisms, and integration with international incident management frameworks.

Conclusions

1. A method for security incident detection and response was formalized and implemented for banking organizations through an integrated incident management ecosystem, establishing SOAR as the central orchestration platform connecting six heterogeneous security systems: SIEM (IBM QRadar), Active Directory, email server (Exchange), threat intelligence platform (VirusTotal), and EDR (Fidelis Endpoint). The method follows a four-phase structured procedure: Capability Assessment identified automation opportunities within incident management processes; Component Identification determined required security system categories based on their roles in investigation and response; System Deployment and Integration established bidirectional communication protocols through REST API connections and Python-based integration scripts; Playbook Development formalized response workflows aligned with ISO 27035 incident management phases (detection, collection, enrichment, analysis, approval, remediation, notification). This method addresses the banking sector's specific requirements for regulatory compliance (GDPR, PCI DSS), continuous operation demands, and heterogeneous IT infrastructure management by providing a unified orchestration layer that eliminates the fragmentation inherent in traditional multi-tool security operations.

2. Automated incident response playbooks were developed for four critical attack scenarios specific to banking operations: GDPR violations involving unauthorized personal data transfers, suspicious account modifications indicating privilege escalation attempts, dismissed employee activity representing insider threats, and targeted attacks through malware infection and lateral movement. These playbooks operationalize the ecosystem's integrated capabilities by automating routine tasks (data collection, artifact verification, IOC checking, notification generation) while preserving human oversight for analytical decisions and approval gates. The approach enables the integration of security's three critical components – human resources, procedural frameworks, and technological solutions – into a unified operational workflow. By eliminating manual coordination delays and procedural bottlenecks, the SOAR-based automation supports the security function's transition from a primarily reactive posture toward more proactive security management practice.

3. Testing through four controlled attack simulations provided initial evidence that SOAR-optimized workflows reduced Mean Time to Resolution by 66.6–94.2% compared to traditional manual approaches. Specific improvements included email processing reduced from 7–10 minutes to 6–10 seconds, threat intelligence checks from 7 minutes to 6–10 seconds, and event collection from 10 minutes to 1.12–2.08 minutes. Tasks requiring human judgment (analysis and approval) remained unchanged at 10 minutes, suggesting these cannot be fully automated. These quantitative improvements result from eliminating delays caused by manual handoffs between departments and systems. This operational optimization consequently allows security engineers to allocate their skills toward addressing complex anomalies and sophisticated threat scenarios. As a result, banking organizations can achieve more efficient incident management due to reduced response time, minimized switching between systems, and fewer negative consequences of incidents for the business.

References:

1. L. Yarovaya, R. Matkovskyy, and A. Jalan, “The covid-19 black swan crisis: Reaction and recovery of various financial markets,” Research in International Business and Finance, vol. 59, p. 101521, 09 2021. Available at: https://doi.org/10.1016/j.ribaf.2021.101521
2. N. M. Doran, R. Badircea, and A. Manta, “Digitization and financial performance of banking sectors facing covid-19 challenges in central and eastern european countries,” Electronics, vol. 11, p. 3483, 10 2022. Available at: https://doi.org/10.3390/electronics11213483
3. A. Q. Stanikzai and M. Shah, “Evaluation of cyber security threats in banking systems,” 12 2021, pp. 1–4. Available at: https://doi.org/10.1109/SSCI50451.2021.9659862
4. D. Ghelani, T. Hua, and S. K. R. Koduru, “Cyber security threats, vulnerabilities, and security solutions models in banking,” 09 2022. Available at: https://doi.org/10.22541/au.166385206.63311335/v1
5. General Data Protection Regulation. (2016). Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016. Official Journal of the European Union, L119, 1–88. Available at: https://eur-lex.europa.eu/eli/reg/2016/679/oj.
6. PCI Security Standards Council. (2024). Payment Card Industry Data Security Standard: Requirements and testing procedures (Version 4.0.1). Available at: https://www.pcisecuritystandards.org/document_library
7. IBM. (2024). Cost of a data breach 2024: Financial industry. IBM Think. Available at: https://www.ibm.com/think/insights/cost-of-a-data-breach-2024-financial-industry
8. M. F. Kryshtanovych, , P. Loˇsonczi, U. Lukashevska, M. Kryshtanovych, I. Britchenko, and T. Baranovska, “State management mechanisms for the exchange of information regarding cyberattacks, cyber incidents and information security incidents,” IJCSNS International Journal of Computer Science and Network Security, vol. 22, 2022. [Online]. Available at: https://doi.org/10.22937/IJCSNS.2022.22.4.5
9. S. R. B. M. Kassim, S. Li, and B. Arief, “Understanding how national csirts evaluate cyber incident response tools and data: Findings from focus group discussions,” Digital Threats: Research and Practice, vol. 4, 10 2023. Available at: https://doi.org/10.1145/3609230
10. A. Palma, G. Acitelli, A. Marrella, S. Bonomi, and M. Angelini, “A compliance assessment system for incident management process,” Computers and Security, vol. 146, 11 2024. Available at: https://doi.org/10.1016/j.cose.2024.104070
11. M. Sheeraz, M. A. Paracha, M. U. Haque, M. H. Durad, S. M. Mohsin, S. S. Band, and A. Mosavi, “Effective security monitoring using efficient siem architecture,” Human-centric Computing and Information Sciences, vol. 13, 2023. Available at: https://doi.org/10.22967/HCIS.2023.13.023
12. J. Kinyua and L. Awuah, “Ai/ml in security orchestration, automation and response: Future research directions,” Intelligent Automation and Soft Computing, vol. 28, pp. 527–545, 2021. Available at: https://doi.org/10.32604/iasc.2021.016240
13. R. A. Bridges, A. E. Rice, S. Oesch, J. A. Nichols, C. Watson, K. Spakes, S. Norem, M. Huettel, B. Jewell, B. Weber, C. Gannon, O. Bizovi, S. C. Hollifield, and S. Erwin, “Testing soar tools in use,” COMPUTERS SECURITY, 8 2022. [Online]. Available at: https://doi.org/10.1016/j.cose.2023.103201 
14. T. Ban, T. Takahashi, S. Ndichu, and D. Inoue, “Breaking alert fatigue: Ai-assisted siem framework for effective incident response,” Applied Sciences (Switzerland), vol. 13, 6 2023. Available at: https://doi.org/10.3390/app13116610
15. M. B. Chhetri, S. Tariq, R. Singh, F. Jalalvand, C. Paris, and S. Nepal, “Towards human-ai teaming to mitigate alert fatigue in security operations centres,” ACM Transactions on Internet Technology, vol. 24, pp. 1–22, 8 2024. Available at: https://doi.org/10.1145/3670009
16. S. Waelchli and Y. Walter, “Reducing the risk of social engineering attacks using soar measures in a real world environment: A case study,” Computers and Security, vol. 148, 1 2025. Available at: https://doi.org/10.1016/j.cose.2024.104137
17. C. Onwubiko and K. Ouazzane, “Soter: A playbook for cybersecurity incident management,” IEEE Transactions on Engineering Management, vol. 69, pp. 3771–3791, 12 2022. Available at: https://doi.org/10.1109/TEM.2020.2979832
18. R. Karpiuk, P. Venherskyi, A. Korchenko, and Y. Khokhlachova, “Machine learning as one of the highly effective methods of reducing the load on csoc’s analysts,” 09 2023, pp. 132–136. Available at: https://doi.org/10.1109/ELIT61488.2023.10310808
19. IBM QRADAR Security Intelligence Platform, “QRadar Experience Center App.” [Online]. Available at: https://www.ibm.com/docs/en/qradar-common?topic=apps-qradar-experience-center-app
20. M. Iavich, G. Akhalaia, R. Odarchenko, and A. Imnadze, “Fortifying the digital fortress: A multi-layered defense strategy with siem, mail gateway, and sandbox technologies,” in ADP, 2024. [Online]. Available at: https://api.semanticscholar.org/CorpusID:275692153 
21. A. Madani, S. Rezayi, and H. Gharaee, “Log management comprehensive architecture in security operation center (soc),” 10 2011, pp. 284–289. Available at: https://doi.org/10.1109/CASON.2011.6085959
22. A. Sridharan and V. Kanchana, “Siem integration with soar,” in 2022 International Conference on Futuristic Technologies (INCOFT), 2022, pp. 1–6. Available at: https://doi.org/10.1109/INCOFT55651.2022.10094537