Paper deep dive

From Chasing Ghosts to Missed Attacks: Perspectives and Perceptions of SOC Practitioners on LLM Integration, Risks, and Readiness

Jonas Thurner, Nadine Jost, Stefan Albert Horstmann, Fabian Ising, Lea Groeber, Alena Naiakshina, Sebastian Schinzel

Year: 2026Venue: arXiv preprintArea: cs.CRType: PreprintEmbeddings: 97

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%

Last extracted: 8/4/2026, 4:49:38 AM

Summary

This study investigates the integration of Large Language Models (LLMs) into Security Operations Centers (SOCs) through semi-structured interviews with 25 practitioners. It identifies 15 use cases across six functional categories, revealing that while LLMs are valued for automating repetitive tasks like report generation, they are currently deemed unfeasible for high-impact tasks like incident analysis due to limitations in technical depth and context awareness. The research highlights a shift in risk perception from false positives to false negatives caused by over-reliance, and emphasizes the need for human-centered, operationally safe LLM-assisted workflows.

Entities (10)

Large Language Models · technology · 99%Security Operations Centers · organizationconcept · 98%SOC Practitioners · role · 95%Over-reliance · riskconcept · 94%Incident Analysis · taskuse-case · 92%Report Automation · taskuse-case · 92%Hallucinations · riskconcept · 91%False Negatives · riskconcept · 90%Cognitive Overload · human-factor · 89%Threat Intelligence · domain · 88%

Relation Signals (7)

Security Operations Centers → processes → Security Events

confidence 96% · Security Operations Centers (SOCs) process large volumes of security events...

Large Language Models → supports → Report Automation

confidence 95% · While LLMs are valued for automating repetitive, low-level tasks such as report automation...

Large Language Models → isnotfeasiblefor → Incident Analysis

confidence 93% · practitioners rate high-impact tasks such as incident analysis as not yet feasible...

Large Language Models → posesriskof → Hallucinations

confidence 92% · Prior research has shown that LLMs may overlook critical security details or generate plausible yet incorrect security recommendations... hallucinations

SOC Practitioners → experiences → Cognitive Overload

confidence 90% · SOC analysts frequently experience cognitive overload and alert fatigue...

Over-reliance → causes → False Negatives

confidence 88% · dominant concern shifts... toward the false negatives produced by over-reliance.

Threat Intelligence Summarization → supportedby → Large Language Models

confidence 85% · practitioners value LLMs for repetitive, low-level tasks such as reporting and Threat Intelligence (TI) summarization...

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Security Operations Centers (SOCs) process large volumes of security events, requiring analysts to accurately detect and assess ongoing cyberattacks under time pressure. Recent advances in Large Language Models (LLMs) suggest potential benefits for security operations, yet their practical suitability for real-world SOC workflows remains poorly understood. To address this gap, we conducted 25 semi-structured interviews with SOC practitioners who had prior experience with LLMs, complemented by interactive scenarios to anticipate challenges and identify opportunities for the responsible integration of LLM-based tools into SOC workflows. We identified 15 LLM use cases grouped into six functional categories. While LLMs are valued for automating repetitive, low-level tasks such as report automation, practitioners rate high-impact tasks such as incident analysis as not yet feasible, reporting limitations in technical depth, context awareness, and organization-specific knowledge. They locate these limitations less in the models than in the readiness of their SOCs and human factors driving over-reliance. Despite concerns, practitioners express a strong willingness to adopt LLMs, describing competitive pressure that leaves few alternatives. This work contributes an empirical, practitioner-driven analysis of LLM use across SOC roles and organizations and derives concrete design and integration requirements for human-centered, operationally safe LLM-assisted security operations.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

95,557 characters extracted from source content.

Expand or collapse full text

From Chasing Ghosts to Missed Attacks: Perspectives and Perceptions of SOC Practitioners on LLM Integration, Risks, and Readiness Jonas Thurner ∗ , Nadine Jost † , Stefan Albert Horstmann ‡ , Fabian Ising § , Lea Groeber ¶ , Alena Naiakshina ‡ , Sebastian Schinzel ∗§ ∗ FH Münster, Germany † Ruhr University Bochum, Germany ‡ University of Cologne, Germany § Fraunhofer SIT and National Research Center for Applied Cybersecurity ATHENE, Germany ¶ ICSI, UC Berkeley, USA j.kaspereit, schinzel@fh-muenster.de nadine.jost@rub.de stefan.horstmann, alena.naiakshina@uni-koeln.de fabian.ising@sit.fraunhofer.de lgrober@icsi.berkeley.edu Abstract—Security Operations Centers (SOCs) process large vol- umes of security events, requiring analysts to accurately detect and assess ongoing cyberattacks under time pressure. Recent advances in Large Language Models (LLMs) suggest potential benefits for security operations, yet their practical suitability for real-world SOC workflows remains poorly understood. To address this gap, we conducted 25 semi-structured interviews with SOC practitioners who had prior experience with LLMs, complemented by interactive scenarios to anticipate challenges and identify opportunities for the responsible integration of LLM-based tools into SOC workflows. We identified 15 LLM use cases grouped into six functional categories. While LLMs are valued for automating repetitive, low-level tasks such as report automation, practitioners rate high-impact tasks such as incident analysis as not yet feasible, reporting limitations in technical depth, context awareness, and organization-specific knowledge. They locate these limitations less in the models than in the readiness of their SOCs and human factors driving over-reliance. Despite concerns, practitioners express a strong willingness to adopt LLMs, describing competitive pressure that leaves few alternatives. This work contributes an empirical, practitioner-driven analysis of LLM use across SOC roles and organizations and derives concrete design and integration requirements for human-centered, operationally safe LLM- assisted security operations. 1. Introduction Security Operations Centers (SOCs), operated either in- house or as managed services (MSOCs), are organizational units run by medium-to-large enterprises, governmental organizations, and critical infrastructure providers to monitor, detect, and respond to cyber threats [1]. However, the effec- tiveness of SOCs heavily relies on the human expertise of the professionals who operate them [2], [3]. SOC practitioners span a broad range of roles within the SOC. At their core, security analysts monitor networks and endpoints, analyze alerts, and identify threats. Security engineers design and maintain the technical infrastructure, deploying intrusion detection systems and automated response mechanisms. Red team specialists contribute to stronger defenses by identifying weaknesses and blind spots in detection logic. Overseeing these efforts, the SOC manager or Chief Information Security Officer (CISO) aligns operational activities with organiza- tional risk profiles and regulatory compliance requirements. However, SOC analysts frequently experience cogni- tive overload and alert fatigue due to an overwhelming influx of alerts, many of which are false positives [4], [5], [6]. Consequently, analysts spend substantial time manu- ally verifying these false positives, increasing the risk of overlooking genuine threats [5], [6], [7]. Simultaneously, security engineers are often distracted from strategic tasks by repetitive, low-level duties such as fine-tuning detection rules to minimize false positives. These tasks reduce their capacity to develop robust defenses against sophisticated cyberattacks [4], [7]. Ultimately, these inefficiencies strain SOC resources, impairing their ability to proactively respond to evolving threats and underscoring the critical need for innovative solutions to enhance SOC effectiveness. While Artificial Intelligence (AI) systems are already deployed in SOCs to detect and classify anomalies [8], [9], the recent rise of Large Language Models (LLMs) has introduced new possibilities to support practitioners and automate security workflows [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22]. However, deploying LLMs in security-specific contexts introduces new risks. Prior research has shown that LLMs may overlook critical security details or generate plausible yet incorrect security recommendations [15], [18], [19]. While LLM integration in SOCs is still emerging, the associated opportunities and risks call for guidance on responsible adoption. By prioritizing practitioners’ insights, this study addresses the socio-technical nature of SOCs, ensuring that LLM integration is grounded in the practical realities of their operators. To this end, we conducted a qualitative study with 25 SOC practitioners spanning the full spectrum of SOC roles [2]. To support participants in articulating abstract concepts and encourage critical reflection, we combined semi-structured interviews with interactive brainstorming and visualization tasks [23], [24]. We addressed the following Research Questions (RQs): RQ1:Which use cases do practitioners identify for LLMs arXiv:2608.00672v1 [cs.CR] 1 Aug 2026 in SOCs? RQ2:What are the perceived technical and operational challenges of integrating LLMs in SOC workflows? RQ3:How do practitioners perceive LLM-specific risks in the context of security operations and what counter- measures do they propose? Our study surfaces 15 use cases across six categories and reveals a gap between the envisioned capabilities of LLMs and the operational realities of SOCs: practitioners value LLMs for repetitive, low-level tasks such as reporting and Threat Intelligence (TI) summarization, but reject them for core security decisions such as detection and incident analysis. Notably, as practitioners delegate more to LLMs, their dominant concern shifts from the false positives that drive conventional SOC work [4], [7] toward the false negatives produced by over-reliance. Overall, our study contributes a practitioner-driven, empirical characterization of LLM integration across multiple SOCs and roles, highlighting over-reliance as a central concern and deriving practitioner- grounded recommendations for the design of human-centered, assistive LLM systems in security operations. 2. Related Work In this section, we present prior research on human factors, Machine Learning (ML), and Usable Security of ML in SOCs. 2.1. Human Factors in SOCs Related work on human factors in SOCs reveals a range of challenges affecting practitioner performance and well- being, including alert fatigue, burnout, cognitive overload, and poor workforce management [2], [4], [5], [6], [7], [25], [26], [27], [28], [29], [30]. Burnout in particular is driven by workload, insufficient management support, and the volume of false-positive alerts [4], [7]. Unlike most studies, Kokulu et al. [25] found that practitioners did not view false positives as a primary issue, instead identifying organizational misalignments, such as management’s focus on metrics versus analysts’ emphasis on usability and operational constraints. Other work points to human-centered and socio- technical design as key to stronger defenses [31], [32], to organizational support and tool integration for mitigating SOC skill shortages [33], to outsourcing models for human- resource limitations [34], and to the impact of Incident Response (IR) playbooks on analyst performance [26], [35]. Stevens et al. [36] found many such playbooks lacked clarity and detail, especially for less experienced analysts, urging iterative refinement. We extend this line of research to the LLM era, examining how practitioners perceive LLM capabilities, limitations, risks, and anticipated changes in real-world integration. 2.2. Machine Learning in SOCs ML, and LLMs in particular, are a promising but contro- versial technology. Recent studies investigate LLMs for SOC- specific tasks such as TI processing [13], [14], [15], intrusion TABLE 1: Empirical practitioner studies of AI/ML and LLM tooling in SOCs, compared across generative-AI focus, breadth of LLM use cases, SOC and practitioner coverage, and role diversity. StudyGenAI LLM use cases Scope Sample size Roles Oesch et al. [9]nononesingle-org6analysts Alahmadi et al. [7] nononecross-org21all Mink et al. [8]nononecross-org18all Vermeer et al. [39] nononecross-org17all Hahn et al. [41]yescompanionsingle-orgco-devall Singh et al. [42]yesmultiplesingle-orgnoneanalysts This workyesmultiplecross-org25all detection [11], [37], threat modeling [16], investigation [10], [17], and triage [10], alongside systematic reviews of LLM applications in SOCs [12], [18], [19], [20], [38]. While largely encouraging, several studies flag risks: Mezzi et al. [15] find that LLMs omit critical details, making them too risky for SOCs, where a small oversight can let adversaries go undetected, while Hassanin et al. [18] and Pasupuleti et al. [19] warn about hallucinations. We complement these technical studies with a user-centered approach, exploring practitioner perspectives and the constraints of real-world security workflows. 2.3. Usable Security of ML in SOCs Practitioner studies report low adoption of AI/ML in SOCs and attribute it to unreliable alarms and models that cannot be adequately tested for high-security environ- ments [7], [39]. LLMs differ from these tools in that they are readily accessible, and it is tempting to delegate security questions to them. Klemmer et al. [40] found that software professionals already use AI assistants for security-related development despite quality and security concerns, which suggests LLMs may see similar uptake in SOCs. Earlier practitioner studies of SOC tooling are pre-LLM, analyst-centric, and detection-focused [8], [9], and the two studies of LLMs inside a single SOC are each bound to one tool and one analyst population [41], [42]. No prior study combines the properties of ours (Table 1). We study generative LLMs across 17 organizations, the full SOC role spectrum [2], and the full workflow, pairing practitioner perceptions with a structured assessment of LLM-specific risks. This vantage reveals a perceived shift in risk concern from false positives to false negatives that single-site studies may not capture. 3. Methodology We conducted 25 semi-structured interviews with SOC practitioners who were screened with a demographic survey to ensure prior experience with LLMs. At the time of the study, it was unclear whether and how LLMs were being used in SOCs. We therefore chose an open and exploratory interview design, which allowed us to capture a wide range of insights and perspectives. We therefore enhanced the interviews by interactive Miro board [43] sections incorporating brainstorming and flowchart creation Figure 1: Example of the impact and feasibility assessment. for in-depth, participant-driven exploration of novel topics as they emerged. 3.1. Study Design We developed an interview guide grounded in our RQs, which was refined through discussions with researchers experienced in security and human factors to ensure compre- hensive coverage and clear phrasing. To test the interview guide, we conducted three pre-tests with security researchers taking on the persona of a SOC analyst. The following adjustments were made to the interview guide: (1) We shifted the interview guide from a research question-based guideline to a topic-focused structure for smoother flow and more cohesive responses (e.g., we rephrased existing topics, introduced new ones, and moved questions). (2) To capture the participants’ thoughts in detail, we replaced general questions (e.g., “What are the challenges of integrating LLMs?”) with more specific questions (e.g., “What are the technical challenges of LLM integrations?”). Interviews were conducted between 2025 and 2027, offering participants the choice of English or German. All interviews were conducted by the first author via Zoom [44], advertised as 90-minute sessions, averaging 79 minutes, with a 5-minute break to counteract fatigue effects. We collected a total of 32 hours and 56 minutes of interview material. 3.2. Interview Guideline Before each interview, we obtained written consent and conducted a short demographic survey (see Section 3.3). To establish a shared understanding, we introduced the term general-purpose LLM as a reference point for models such as ChatGPT, Gemini, and Llama. While the discussion was not limited to these systems, this distinction helped participants differentiate them from security-specific or embedded tools such as Microsoft Security Copilot. Afterwards, we obtained oral consent and started the recording to discuss the following topics. Figure 2: Example flowchart created by a participant. Green boxes indicate LLM-assisted tasks. General Questions: We asked participants about their daily work routines and challenges, their familiarity with LLMs, including perceived strengths and weaknesses. We also explored their predictions for LLM development in SOCs. Additionally, we inquired about their current use of LLMs in security operations, the challenges they have encountered and how they addressed them, the areas where LLMs have succeeded or failed, and the reasons for these outcomes. This section served both as an ice-breaker prior to the interactive tasks, and as a means to verify participants’ statements in the demographic screening survey. Brainstorming: Next, we conducted a brainstorming session on a Miro board [43], encouraging participants to share potential LLM applications in security operations without any limitations. Some reflected on their own practical experiences, while others proposed novel applications, allow- ing us to capture both real-world insights and forward-looking perspectives grounded in their professional background. Each participant worked with an individual Miro board to ensure responses were not influenced by others. We asked them to think aloud as they added their ideas to the board. We provided optional questions to stimulate brainstorming if needed. Impact and Feasibility Assessment: Subsequently, we asked the participant to place their identified use cases on a grid. We asked them to think aloud and explain (1) their perceived impact of the solution and (2) its feasibility (see Figure 1 for an example). During this step, we also noted, for each application, whether the participant grounded it in hands-on experience or envisioned the use case. Integration Flowchart: After that, we prompted partici- pants to create a flowchart visualizing their ideal LLM-driven SOC workflow (see Figure 2 for an example). Participants were asked to think aloud. If necessary, participants were provided technical assistance, e.g., when drawing arrows. The first author used a checklist and asked additional questions to verify that participants covered key aspects such as integration details or stakeholders. Critical Engagement: Next, we discussed the flowchart, focusing on technical, organizational, and regulatory chal- lenges. We questioned the economic viability of the proposed solution and investigated performance metrics. Participants were asked to challenge their own design by arguing against the LLM-based approach and to highlight essential points Figure 3: Illustrative example of the risk assessment. where human involvement remained critical. Throughout this discussion, participants raised each challenge in direct reference to one or more elements of their flowchart, so challenges surfaced together with the use-case context in which they would manifest. LLM-Specific Risk Assessment: We presented participants with LLM-specific challenges (hallucinations [45], bias [46], model drift [47], over-reliance [48], data leakage and privacy issues [49]) one by one, asking them to: (1) assess each challenge’s risk and likelihood while thinking aloud and (2) suggest ways to detect it early or mitigate the consequences within the context of the designed flowchart (see Figure 3). This list is not exhaustive. Within the 90-minute interview budget we scoped to five risks that are well-documented in the LLM literature and that could affect security decision- making once LLMs are introduced into the SOC. We did not present the attack mechanisms themselves, such as prompt injection, jailbreaks, or data poisoning, but only data leakage as a primary consequence, given the time budget. However, participants raised them continuously unprompted. We therefore report this as an additional emerging risk in Section 4.3.1. Two senior AI/ML researchers reviewed the set for SOC relevance and conceptual overlap. In the end, we invited participants to share final thoughts, thanked them for their time, and concluded the session. 3.3. Participants To recruit participants, we leveraged our research team’s industry network (n=10), promoted the study on LinkedIn (n=9), and asked participants to suggest additional contacts (n=6), following the recommendations of prior work [50]. We did not provide financial compensation, and participation was entirely voluntary. Previous research found that intrinsic motivation is a key driver of creativity [24], [51], [52], which, due to the wide range of creative brainstorming tasks, was central to our study. Consistent with findings by Serafini et al. [53], they expressed a willingness to contribute altruistically while simultaneously gaining insights applicable to their work. Most participants reported that the structured reflection was valuable, as it helped them identify previously unconsidered risks. To ensure we invited only participants with relevant ex- perience to take part in the study, we defined two acceptance criteria. First, participants had to be practitioners embedded in a SOC, i.e., engaged in the day-to-day operations of an identifiable SOC. We deliberately sampled across the full spectrum of SOC roles including analysts, security engineers, managers, CISOs, and red teamers [3] because LLM adoption in a SOC is decided and enacted across this entire hierarchy rather than by any single role. We verified each participant’s role and current SOC engagement via their LinkedIn profile and the demographic screening survey. Second, participants were required to have a clear understanding of LLMs and hands-on experience. These criteria were queried through a demographic survey, resulting in the inclusion of 25 participants (17 distinct organizations) from an initial pool of 29. An overview of participants’ demographics is provided in Table 2. 3.4. Data Analysis We analyzed all interview transcripts using the six- step thematic analysis approach by Braun and Clarke [54], [55], consistent with established practices in qualitative research [40], [56], [57], [58], [59]. We first familiarized ourselves with the material by conducting the interviews and reading the transcripts (step 1). All researchers then collectively analyzed an initial set of four transcripts to inductively develop a first codebook (step 2). Subsequently, the first and second authors independently coded each interview. Interviews were coded in rounds of three to four. After each round, they merged and reviewed their codes, discussing new codes and resolving disagreements. We began grouping codes into candidate themes based on their commonalities (step 3). The codebook and higher- level themes developed iteratively, refined in each round with the insights from newly coded interviews (step 4). For example, both authors initially coded LLM-assisted scripting and detection rule writing separately, but later agreed that both reflected security engineering activities and merged them into a single theme. As the coding process progressed, this theme was further refined into the sub- themes Rule Development and Tool Development. Throughout the analysis, we repeatedly reviewed the codebook and themes. We continued until each theme captured a clear and distinct central concept and the overall thematic structure was coherent; we stopped recruitment after 25 interviews (step 5). We report the themes, their codes, and example quotes in Section 4 (step 6). In total, we assigned 3,822 codes across 48 unique code categories, yielding a median of 147 per interview. In line with Braun and Clarke’s approach, which treats coding as an interpretative, researcher-situated process rather than a consensus-seeking procedure [60], [61], [62], we did not calculate Inter-Rater Reliability (IRR), consistent with broader qualitative methodological literature [59]. TABLE 2: Overview of interviews and participants’ self-described demographics. IDDuration (h:m) Codes (count) LocationEducationOccupationExperience (yrs) Environment (ppl) LLM DeploymentCommercial CloudPrivate CloudSelf-HostedLLM ExperienceInteractive ChatScriptingEmbeddedAutonomous AgentUsage Frequency A101:19159EUM. Sc.SOC Analyst+ 20< 1,000G###G####monthly A201:25165EU-SOC Analyst11-20< 10,000 # #multiple/week A300:5085EUM. Sc.SOC Analyst6-10< 10,000G###G## #monthly A401:13208EUM. Sc.SOC Analyst11-20< 1,000 G##multiple/week A500:52113EUM. Sc.SOC Analyst2-5< 1,000# # ###weekly A601:0659USB. Sc.SOC Analyst2-5< 10,000 ## ##multiple/week A701:1067EUM. ScSOC Analyst2-5< 1,000##G###G#G#monthly E101:22259EUB. Sc.Sec. Engineer2-5< 200 # G#G#daily E201:44258EUPh. D.Sec. Engineer2-5< 200 ## G#G#G#multiple/week E301:13159EUM. Sc.Sec. Engineer0-2< 1,000 ## ###multiple/week E401:12162EUM. Sc.Sec. Engineer0-2< 50 # G##G#daily E501:36206EUB. Sc.Sec. Engineer6-10< 10,000 G## ##multiple/week E601:08147USM. Sc.Sec. Engineer2-5< 10,000 G# G# multiple/week E701:49148EUB. Sc.Sec. Engineer11-20> 10,000 daily E801:16104EUM. Sc.Sec. Engineer6-10> 10,000G#G##G## #multiple/week E900:56100EUM. ScSec. Engineer6-10< 10,000 # ##multiple/week R101:31122EUPh. D.Red Teamer11-20< 200 G#G# G###daily R201:21159EUPh. D.Red Teamer6-10< 1,000 #G# ###weekly R301:16176USB. Sc.Red Teamer11-20< 1,000 # #G##multiple/week M102:15441EUM. Sc.CISO6-10> 10,000 G#G#daily M201:32184USM. Sc.CISO11-20< 200 G## ##weekly M301:0456USPh. D.CISO11-20< 10,000G#G#G#G#G#G#G#daily M401:1793EUM. ScCISO2-5< 200 G#G# G#G##daily M501:0892EUM. Sc.SOC Manager11-20< 10,000 G#G# ###multiple/week M601:21100USM. Sc.SOC Manager6-10< 10,000 # G# #daily Total32:563,822-----1977201052multiple/week : Used in a SOC G#: Used privately #: No usage 3.5. Experience-Based and Envisioned Claims Our exploratory design captured both real-world insights and forward-looking perspectives. Consequently, participants’ statements could be experience-based if grounded in practice and actual use or envisioned if based on an anticipated use or risk that had not yet materialized. To avoid conflating current practices and anticipations, we classified each claim as experience-based , if a participant described an LLM use in practice, or envisionedG#, if the claim was not validated in practice. The first author tracked during the interviews and interactive tasks whether participants referred to actual use or envisioned scenarios. If unclear, the first author verified this through a short follow-up question asking whether the participant was referring to an actual use case. After the interviews, we labeled each claim. For instance, M1’s SOC operated a Retrieval-Augmented Generation (RAG)- based onboarding assistant in production. Consequently, we classified the claims made in the context of this use case as experience-based. In contrast, if M1 later discussed a potential risk that had not yet materialized in practice, we classified it as envisioned, even though their assessment was informed by their professional SOC and LLM experience. This approach allowed us to analyze the data with a nuanced understanding of the current state of LLM adoption in SOCs and practitioners’ expectations for its future development. We apply this distinction per cell in Table 3 and Table 5. For example, while describing a Security Engineering use case during flowchart creation, one participant identified interoperability as a challenge, because it was not tied to a system they had operated, we marked it as envisionedG#, whereas grounding the same challenge in a deployed system would have marked it experience-based . A table cell is experience-based if at least one participant grounded it in practice, envisionedG#if it was only anticipated, and not identified # if no participant raised it. 3.6. Limitations First, given the early stage of LLM adoption in SOCs, our insights reflect initial developments. Second, use case rankings came from participant brainstorming and were not completed by all participants. Third, self-reported data is subject to social desirability bias: participants may have with- held unauthorized LLM usage or overstated how thoroughly they validate LLM output. We mitigated this by assuring anonymity and stating that their security practices would not be evaluated. Participants’ intrinsic motivation in the topic may still have led to over-reporting of positive aspects. The walkthrough of well-documented LLM-specific risks may also have amplified their salience. Yet participants surfaced concerns freely beforehand and raised adversarial attacks unprompted. We accepted this trade-off so that hype and possible over-reporting would not leave well-documented risks overlooked. Finally, despite targeted LinkedIn recruit- ment, our sample predominantly comprised individuals from Western Europe, reflecting existing networks, and included only four women, mirroring the gender imbalance in cyber- security [63] and sampling challenges reported in previous studies [7], [8], [64], [65], [66]. Figure 4: High-level overview of use cases for LLM applications in SOCs. We identified six categories where LLMs may provide operational support:1Security Engineering,2Incident Detection, 3Incident Analysis,4Incident Response,5Communication, and 6Knowledge. This diagram maps these categories to key SOC roles and workflows. 4. Results We outline the findings from our qualitative analysis and address our research questions. We present our findings at the level of themes and perspectives. We distinguish experience- based and envisionedG#claims (see Section 3.5). Figure 4 provides a high-level overview of the use cases we identified, grouping 15 use cases into six categories and mapping them to key SOC roles and workflows. We detail each category, including its anticipated impact and feasibility, in Section 4.1. We then examine the technical and operational challenges practitioners associate with integrating LLMs (Section 4.2) and the LLM-specific risks they perceive, together with the countermeasures they propose (Section 4.3). 4.1. Applications, Impact, and Feasibility (RQ1) In this section, we discuss all identified use cases for LLMs in SOCs, along with their perceived impact and feasibility. Figure 1 illustrates our interactive think-aloud assessment, and Figure 5 provides an overview of the dis- cussed use cases and their anticipated impact and feasibility across the interviews. 4.1.1. Security Engineering. [Sec. Tool Development ] Security engineers described LLMs as valuable aids in developing security tools, particularly in SOC environments where engineers regularly interact with unfamiliar tools and technologies. For example, R1 used an LLM to build a cus- tom script to stress-test a Cisco device without first studying its documentation, illustrating how LLMs enable engineers to “jumpstart” coding efforts even on previously unknown systems. Yet this same shortcut concerned practitioners. E3 stressed: “You must understand what’s happening before running LLM-generated scripts in customer environments.” [Rule DevelopmentG#] One specific area of security engineering is detection rule development, since poorly Figure 5: Practitioners’ rankings of anticipated impact and feasibility of LLM use cases in SOCs, based on participants’ brainstorming and ranking activities conducted on the interactive Miro board (see fig. 1). designed rules generate excessive false positives, leading to issues such as alert fatigue [7]. In particular, security engineers emphasized that, for this reason, rule creation “requires careful fine-tuning.” (E5) Moreover, E9 characterized it as “time-consuming” and “labor-intensive,” underscoring the impact on their daily workload. They had already experimented with LLMs to save time: “I used it to create detection rules, although this didn’t always work perfectly [...] the domain-specific knowledge about the products was missing [...] things were mixed up.” (E5) They emphasized that security rule engineering requires in-depth knowledge of the customer’s environment, which limits LLMs in SOCs. 4.1.2. Incident Detection. [Anomaly DetectionG#] Partici- pants envisioned LLMs independently detecting anomalies in log data and triggering alarms. However, they raised two major concerns. First, they argued that alarm generation must not be left to chance and requires a deterministic approach: “You cannot roll the dice when generating alarms.” (R2) Second, participants emphasized that real-time anomaly detection requires processing vast datasets, demanding sub- stantial computational resources: “We generate millions of logs daily, we can’t just dump tons of gigabytes in there [LLM].” (M2) [Phishing DetectionG#] Participants identified phishing detection as a special case. They agreed that “traditional methods” had been exhausted. They suggested that LLMs could be used to augment these approaches via semantic analysis. [Phishing Detection ] The SOC of A2 built an LLM- based application to analyze over 300 emails that had evaded their spam filters, and reflected on this: “So far, I am pleasantly surprised by the phishing [prevention] skills that these models demonstrate.” 4.1.3. Incident Analysis. [TriageG#] In a SOC, triage is a Tier 1 task in which analysts validate and prioritize alerts by confirming their criticality and filtering false positives [3]. In this context, M2 suggested: “LLMs could triage alerts by comparing them to historical data. If an alert matches a previous pattern, the LLM could provide a summary and recommend actions based on past responses.” However, analysts cautioned and anticipated a central limitation: “LLMs can’t detect alerts they weren’t trained on, so it’s really just handling the Tier 1, repetitive stuff.” (A7) Overall, they considered an LLM-based triage tool, especially when enriched with historical data, as both feasible and valuable. [Triage ] A3 experimented with LLM-based triage and found: “LLMs are often too generic to effectively address the unique systems of our customers.” A limitation that historical data enrichment may help overcome. However, none of our participants reported such a solution. [Malware AnalysisG#] Participants considered using LLMs for malware analysis tasks such as analyzing obfus- cated JavaScript code. They also saw potential for LLMs to assist in behavior analysis within a sandbox environment, noting: “We use a Detonation Chamber, where you throw it [malware] in and see what it does. An LLM would be useful, for example, to summarize that.” (A2) Beyond this, however, participants considered the actual de-obfuscation task an “unsolvable problem” for LLMs, since they lack understanding of obfuscated code and thus cannot reliably reverse-engineer it. In the same vein, A4 located the limit in the model rather than its inputs, describing an LLM as “a puzzle” that “can puzzle well, but in the end does not know what the motive is.” [Threat Hunting ] Threat hunting is a Tier 2 activity in which analysts proactively search for indicators of compro- mise described in the latest TI [3]. Participants valued LLMs as a translation layer between analysts and the Security Information and Event Management (SIEM), generating query syntax (e.g., KQL for Sentinel) from natural language. M1 pointed out that vendor-integrated solutions such as Microsoft Security Copilot [67] or Splunk AI [68] work well: “My SIEM creates the query for me, which is extremely helpful because I don’t need any technical knowledge”. Others found that general-purpose LLMs frequently produced incorrect queries. R1 tied this to their lack of domain understanding: “ChatGPT, is like one LLM for the whole world, so it doesn’t work very well for security purposes.” 4.1.4. Incident Response. [IR PlanningG#] IR aims to contain detected security threats before they escalate. This is typically achieved through structured workflows and playbooks that define mitigation steps [3] to be taken in certain scenarios. Our participants noted that LLMs could support these structured planning processes, for instance, by analyzing existing playbooks to uncover overlooked risks. However, they stressed that such systems must remain pure supportive tools, with final responsibility resting on humans. [IR ExecutionG#] Analysts presented both advantages and critical arguments regarding the use of LLMs for automation in IR. For example, A4 warned that automated actions are too risky and directly questioned their feasibility, while A1 argued that the risk of acting delayed is greater than the risk of LLM-based misclassification: “If an account is accidentally locked, it’s not a big deal, the admin can unlock it the next day.” [IR Execution ] Our CISOs added another perspective to this discussion. They explained that billions of alerts are triggered daily and that automation is therefore not optional but essential. For instance, M1, the CISO of an international enterprise with more than 150,000 employees, reported that they had already deployed an LLM-based application to automate parts of IR, such as triaging an “impossible traveler” alert, where a single account logs in from geographically distant locations within an implausibly short time. [IR Reporting ] As a part of IR, SOC teams inform stakeholders about detected threats through structured inci- dent reports [3]. Our participants described this process as “tedious”, and E7 clarified: “It is not an analyst’s favorite task. Thus, the quality varies.” In addition, E2 explained: “Analysts spend a significant amount of time to fill report templates and write summaries for alerts.” Then E2 continued: “We’re currently testing LLMs to automate the text production in reports, but we’re unsure if the quality will be sufficient for our customers.” We later received an update from E2, who reported that it is now in production use at their SOC. 4.1.5. Communication. [Communication ] Participants noted that LLMs already enhance communication tasks such as drafting executive summaries. For example, by bridging gaps in technical terminology with executives or customers. 4.1.6. Knowledge. [TI Summarization ] Practitioners must continuously maintain an overview of the threat landscape, which is a challenging task given the sheer volume of TI available. Our participants reported that LLMs are helpful for summarizing and contextualizing TI data. For instance, M2 pointed out: “There’s a ton of threat intel every day, it’s hard to know where to start or what to look for, manually processing it all is impossible [...] summarizing large volumes of threat intelligence [with LLMs] is incredibly useful for day- to-day security operations.” M3 added: “TI summarization is pretty straightforward. They are language-generation tasks, and that’s exactly what these tools [general-purpose LLMs] were built for, and as they save a lot of time, they have impact.” [Context Enrichment ] In a SOC, analysts must assess alerts and logs and correlate them with contextual data such as asset information, historical events, and TI [3]. SOCs deal with many systems that even seniors lack familiarity with. For instance, R1 explained: “I got a log of a wireless LAN controller from Cisco. I didn’t know the structure and the device, scrolling through it was impossible. So I fed the LLM the documentation for the device, and then I entered the log file and asked to process it. [...] That helped a lot because I’m not familiar with these wireless controller logs.” This kind of context enrichment was perceived as very useful across multiple scenarios, including log analysis, alert triage, incident investigation, malware analysis, threat intelligence correlation, and understanding unfamiliar tools, systems, or vendor-specific technologies, in particular, under time pressure. [Onboarding ] For instance, M1 reported that they had already deployed a RAG-based LLM solution in production to support onboarding, especially in their Indian office, where turnover is high. They explained: “Onboarding is now much faster. We even built a badge system to certify analysts’ skills. It’s cool, it generates training content by itself, classified by skill level and topic, and no one can just memorize old questions.” E7 reported positively on deploying a knowledge database searchable with an interactive LLM as an interface between, in particular, junior analysts and the diverse technical systems of the SOC: “We humans aren’t designed to search and analyze 10,000 pieces of information. That’s where LLMs are super helpful because they offer us this human-like way to search through data based on questions and answers ... and if the juniors ask the tool instead of us, then we have more time to take care of more important things.” Summary RQ1 Participants not only envisioned but also actively used and deployed LLM-based tools across 15 use cases. Successful deployments clustered at high-impact, high- feasibility tasks that are language-centric, such as summarization and reporting. For more technical or organization-specific tasks, such as query generation, practitioners found effectiveness diminished sharply, judged general-purpose models “too generic” and saw a clear need for specialized solutions. 4.2. Technical and Operational Challenges (RQ2) During each interview, participants sketched a flowchart of either their current or envisioned ideal SOC workflow and identified potential points for LLM integration. We then asked participants to identify technical and operational challenges. In the following we report about the technical and operational challenges identified by our practitioners. Table 3 presents an overview of all identified challenges; we mapped every challenge to the flowchart element that prompted it. 4.2.1. Technical Challenges. [Reliability ] Participants emphasized that the success of LLM integration hinges on the reliability of model outputs. In particular, they warned that hallucinations can lead to overlooking genuine threats or interrupt legitimate business activities, thereby “harming reputation” and potentially “deterring customers.” (E2) However, participants attributed these issues to inadequate TABLE 3: Technical and operational challenges of LLM integration across SOC use cases. Use Case Categories 1 Sec. Engineering 2 Incident Detection 3 Incident Analysis 4 Incident Response 5 Communication 6 Knowledge Overall Response Count65101381425 Technical Challenges ReliabilityG# G#G#G# InteroperabilityG#G# G#G# Generic Outputs Fine-Tuning###G##G#G# Explainability##G#G##G#G# Operational Challenges Economic PressureG#G#G#G#G#G#G# AI GovernanceG#G#G# G# MisconceptionsG#G#G#G#G#G#G# Legal UncertaintyG#G# #G# : experience-based G#: envisioned #: not identified contextualization: “I think models today lack a lot of context and not only technical but also business priorities.” (M6) In addition, R3 noted: “You can train a perfectly good model, but if you’re giving it bad data, then that won’t go well.” They argued that the LLM itself may not be to blame. Instead, they pointed out “the inability of the SOC to feed the LLM with the correct data,” (E7) questioning whether most SOCs have reached the maturity necessary for effective LLM integration. [Interoperability ] E5 stated: “Many customers have bought a variety of security solutions that don’t play well together, aren’t well-configured, or haven’t even been de- ployed,” underlining persistent interoperability challenges within SOCs. Further, E5 emphasized: “The significant challenge is making these data sources accessible to LLMs.” Our findings clearly show that connecting diverse customer systems and thus adequately contextualizing LLMs is per- ceived as a significant technical challenge. Interoperability only emerged when participants discussed LLM-based tools that ingest customer telemetry, for example, rather than general-purpose manual use (e.g., ChatGPT). [Generic Outputs ] Practitioners complained about generic responses. They emphasized that general-purpose models such as ChatGPT and Gemini often lack the neces- sary technical depth and nuanced understanding of specific customer contexts. As R2 put it: “A pure LLM [i.e., an LLM without adequate contextualization] does not know in which environment the alarm occurred. However, this is crucial for determining whether it is a false positive or a true positive. A pure LLM cannot see this, it does not know the corporate environment.” M6 illustrated this: “it [the LLM] kept flagging our nightly backup jobs as suspicious. Big encrypted data transfers running at night ticked all the boxes for an exfiltration alert, but of course, these were just our scheduled backups. The LLM didn’t know that because it had no understanding of our environment or normal processes.” [Fine-TuningG#] While participants communicated a demand for more specialized models, they foresaw another technical challenge in the lack of suitable training data for fine-tuning. In this context, E1 explained that due to the highly specific SOC requirements, each SOC would be obliged to fine-tune models independently in the absence of third-party vendors. In this context, R2 made the following statement: “You need a training dataset, and we [SOCs] simply don’t have that.” Later, M6 added that SOCs also lack the necessary ML expertise to successfully carry out fine-tuning. [Explainability ] Moreover, participants identified lack of explainability as a key challenge in security operations: “We are now at a point where we have moved from ‘I can explain why I got from A to B’ to ‘I got from A to B and that’s it’,” (A4) and, particularly in the case of incident assessment, wanted both reasoning and sources in order to verify the assessment: “As we operate in a critical environment I want the decision to be reasonable, do fact checking. Does this decision make sense?” (E1) 4.2.2. Operational Challenges. [Economic PressureG#] Participants perceived an economic pressure driving the LLM integration into SOCs. For example, E1 predicted: “Those who engage intensively with this topic will have a significant advantage in a few years.” [Economic Pressure ] In practice, E7 described the situation in their SOC as follows: “We are already using LLMs in some areas, but we are still in the early stages. The pressure to adopt is immense, and we are trying to keep up with the pace of change. ... The train is moving at full speed, and many companies are investing heavily. There’s no turning back now. It’s like building a house, if you’re standing on a greenfield site, it’s not the right move to install solar panels.” A4 experienced something similar and explained: “If your ticket system doesn’t work and you build an LLM on top of it, you’re just creating chaos.” [AI GovernanceG#] In particular, CISOs and Managers expressed concerns about human governance. They ques- tioned who controls the use of LLMs in SOC workflows. M6 warned: “I think the tool is in place, and habits shift. People use it in their day-to-day life, and it works. They start trusting the LLM. They also use it in security operations, and it works fine, so at one point, they skip the review, because it’s easier, right? And then they skip it again and again. Habits shift, and in the end, the LLM makes more and more decisions, and we are not even noticing it.” This statement highlights the risk of delegating decision-making to a proprietary system without clear organizational approval or oversight. They further raised questions about accountability. For instance M2 stated: “If an LLM makes a mistake, who is responsible? The analyst? The SOC manager? The CISO? The vendor?” and continued “If you have to explain to a customer that they have been encrypted [by ransomware] because an LLM made a mistake, how do you think they will react? They won’t care about fancy tech. They want accountability.” [Misconceptions ] We found that security practitioners acknowledged they do not understand LLM capabilities. Figure 6: Practitioners’ risk assessments of selected LLM-specific risks, based on the corresponding interactive Miro-board activity (see fig. 3). Participants stressed that these systems act as “black boxes,” (A2) making it nearly impossible to trace how decisions are reached. For instance, E6 admitted, “I don’t fully understand LLMs. I’m not really sure what they do in the background, even though I use them daily for various tasks.” R1 added: “It’s not just non-technical people; even technical people struggle with them. They expect it to do things it can’t.” [MisconceptionsG#] According to M2, such misconceptions “can lead to a false sense of security”, where blind trust in technology replaces critical thinking and expertise, which our practitioners described as particularly dangerous in security operations, highlighting that SOCs are handling “sensitive customer logs and systems.” [Legal UncertaintyG#] We noticed a surprising number of contradictions regarding compliance among our EU practitioners. For instance, A4 (EU) was convinced that there were no regulations “at all,” and demanded that “lawyers have to speak up,” while E2 (EU) thought that they were “showstoppers,” especially for LLM-driven automation, with R1 (EU) adding: “I think law enforcement is not ready for what’s happening.” In contrast, our practitioners based in the US expressed far less concern about legal restrictions. Summary RQ2 Practitioners identified the core technical challenge not in the LLMs themselves but in the SOC, attribut- ing unreliable outputs to inadequate contextualization stemming from interoperability issues. This reframes LLM readiness as a question of organizational maturity that SOCs perceive themselves to lack. At the same time, intense economic pressure drives adoption while operational challenges such as legal uncertainty and governance remain unresolved. Consequently, our find- ings suggest that LLM integration may currently be premature and, without such safeguards, irresponsible. 4.3. Risk Perceptions and Countermeasures (RQ3) In this section, we report on the final interview segment, in which participants evaluated LLM-related risks in SOCs and discussed potential mitigation strategies. 4.3.1. Risk Perceptions. Figure 6 shows practitioners’ assess- ments of predefined LLM-specific risks during the interactive Miro-board activity (cf. section 3.2). [HallucinationsG#] Participants perceived the impact of hallucinations as critical, particularly because of the potential to mislead decision making: “If it’s wrong and I handle TABLE 4: Human factors that contribute to over-reliance on large language models in SOCs according to our participants. Human factorExplanation Lack of expertiseAnalysts with limited domain knowledge tend to trust automated suggestions more than seniors. FamiliarizationConstant use over time reduces the ability to perform independent checks. NormalizationAs trust increases, behavior gradually drifts toward uncritical acceptance. Time pressureTime pressure and heavy workloads encourage SOC analysts to accept LLM outputs as a shortcut. Burnout & fatigueMental exhaustion reduces cognitive resources for critical evaluation. Presentation biasLLMs can produce logically coherent but incorrect explanations, even when wrong. IdentificationWhen decision-making is shared with an AI system, analysts feel less personally accountable. an incident incorrectly, it might not be contained properly, leaving attackers active in the network” (A3). M6 added: “If it wrongly escalates, triggers a containment action, like blocking a legitimate partner domain or isolating a critical server, it disrupts business.” It is worth highlighting that participants did not attribute hallucinations to the model itself: “It’s pure mathematics, if the data set is so sparse that 1+1 equals 3, the machine will present it as fact.” (E7) Instead, they attributed hallucinations to a lack of context regarding technical details, customer processes, and systems (cf. Section 4.2.1). [Hallucinations ] They observed that LLMs will “al- ways” hallucinate when confronted with unseen, sophisti- cated attacks. E9 explained, “When an APT group attacks, it is not possible for the LLM to detect them because they use their own tools that no one has seen before [...] and there is no data that the LLMs could use to identify these attacks.” They suggested that LLMs struggle to detect threats beyond their training data or contextual inputs. Interestingly, practitioners argued that only experts can reliably spot errors in LLM output, which conflicts with the view that LLMs are most helpful for junior staff. Overall, the fear of missing critical alerts, especially in decision-making tasks, drove a strong preference for assistance systems. [Over-Reliance ] Overall, over-reliance received the highest risk rating, primarily because it could lead to false negatives, which participants considered particularly hazardous in SOC environments: “In a SOC, there’s no safe environment to see what happens. If the model gets something wrong and an analyst blindly trusts the response, that could mean a breach slips through, or we waste resources ... You don’t get a second chance to patch the mistake.” (M3) Practitioners admitted to not always verifying LLM outputs and attributed this behavior to human factors, which we summarize in Table 4. [Over-RelianceG#] Interestingly, practitioners argued that LLMs should lean toward false positives. R2 captured the reasoning: “If something goes wrong, it can go seriously wrong. Therefore, LLMs should probably lean toward false positives, leaving the final verification to humans.” R1 echoed: “When an LLM is involved in security decision- making, it’s better to overreact.” Moreover, A4 anticipated an erosion of skills as analysts grow accustomed to LLMs, asking, “How many people can still read a conventional map nowadays?” A4 warned that this problem would become “exponentially worse over time,” eventually leading to a SOC that “raises a generation that relies on it [LLMs] 100%” and can no longer function without them. [BiasG#] Bias was among the risks practitioners engaged with least, and their ratings diverged sharply, tracking whether they expected it to cause false negatives. The clearest concern was detection, where E6 warned that a model assisting alert prioritization might favor frequent threats and overlook rarer, more sophisticated attacks. Yet E6 still felt unable to act, since “it’s really not up to us, we’re talking about the training data and the company providing the model.” (E6) Many dismissed bias outright, as M3 put it, a “technical system is not biased, unless it [bias] is implemented.” [Bias ] In practice, participants observed bias mainly in phishing detection, where broken English or foreign-language patterns led the model to flag messages as malicious. For other tasks such as TI summarization, they doubted bias mattered at all. [Model-DriftG#] Participants linked model-drift to the evolving threat landscape. E2, for instance, explained: “It’s critical, as the situation in security is constantly changing.” Interestingly, others contradicted this: “When I look at the types of attacks that we have faced over the last five to ten years, they are still largely the same” (M2). Overall, practitioners considered the risk manageable. [Data LeakageG#] The impact of data leakage was perceived as high, because of the sensitive data handled in SOCs (e.g., patient records, financial transactions): “Most of the data we deal with in a SOC is highly critical, customer logs, incidents, sensitive systems. [...] the criticality of the environment demands people to be much more cautious” (A7). Our practitioners distrusted LLM providers; they were concerned about misconfigurations. For instance, M1 drew parallels to incidents such as Snowflake’s unprotected S3 buckets [69] and warned that “the same might happen with OpenAI tenants.” They anticipated that such leaks would significantly “harm [their] reputation” and “deter customers.” (E2) However, they agreed that the risk is easily mitigated by hosting LLMs on-premises. [Data Leakage ] In particular, managers worried about analyst carelessness and data protection violations. M1 recounted: “Employees even forward data to private email to input it into ChatGPT” and bypass organizational safeguards. Moreover, engineers expressed concerns about the risk of data leakage between customer environments. [Adversarial Attacks ] Although adversarial attacks were not a separate item in our predefined risk list, we later decided to report them separately because participants raised diverse attack vectors, such as prompt injection and data poisoning, unprompted, and expressed strong concerns about them. Red team members were especially concerned about LLM tools granted powerful permissions. R2 found TABLE 5: Mentioned countermeasures mapped to discussed risks. RisksHallucinationsOver-RelianceBiasModel-DriftData LeakageOverall Input Optimization Prompt Engineering #### RAGG#G##G##G# Context Enrichment G#G## Output Verification HITL G#G## 4-Eye Principle G### LLM-CrosschecksG#G####G# Model Management Training & Fine-TuningG#G#G#G##G# Model Updates### # Data Government Data Segmentation#### Secure Deployment#### Explainability CitationG#G#G###G# Reasoning G### Confidence IndicatorG#G####G# Organizational Measures Internal Policies ## Awareness TrainingsG#G###G#G# CI/CD IntegrationG#G##G##G# : experience-based G#: envisioned #: not identified a Copilot misconfiguration that allowed them to access sensitive information, including salary data for all employees. Participants observed that LLMs are becoming a primary attack target: “Most data now goes through an LLM, so that’s where hackers go.” (R1) [Adversarial AttacksG#] Participants also cited demon- strations of prompt injections and data poisoning. Through prompt injection, A2 warned, “you can completely take over individual LLMs and even inject malicious code,” emphasizing that no reliable defense exists yet. E8 made the risk conditional on deployment, assigning a high risk to publicly accessible LLMs while rating risk for private applications lower. R3 cautioned that on-premises hosting does not eliminate the threat, since “even if I have an LLM on an on-prem server, it is still a target for attackers,” and asked for SOC-specific preparation, such as “incident response playbooks for LLM attacks”. 4.3.2. Countermeasures. Table 5 summarizes the counter- measures that participants proposed for each risk. [Input Optimization ] The most immediate countermea- sure participants reached for was prompt engineering. For instance, E6 reported that hallucinations became less frequent once they decomposed tasks, “I’m not bombarding it with a lot of data and questions [...] I’m giving it very specific, small tasks,” and emphasized the importance of prompt engineering. Context enrichment was likewise perceived as an effective way to reduce hallucinations. Practitioners also perceived this as an indirect safeguard against over-reliance. By reducing errors in the first place, they reasoned that analysts’ reliance would be less consequential. As E3 put it, “if the quality of the LLMs is so good that errors never occur, over-reliance plays no role.” [Input OptimizationG#] Looking ahead, participants envisioned RAG as the natural way to ground outputs in data and thereby mitigating hallucinations. However, while RAG was invoked in almost all interviews, only one participant mentioned using it in practice. [Output Verification ] Consistent with their preference for assistive over autonomous systems, participants empha- sized verifying LLM output before it takes effect. They described keeping a human in the loop as standing practice. E8 explained that “experienced colleagues review the LLM’s output and manually cross-check it.” [Output VerificationG#] Moreover, practitioners invoked established principle: “One person creates a playbook, and only after the four-eyes principle, when at least two say it’s okay, do we officially release it.” (A3) E5 extended the same logic to reject full automation: “an analyst should review the assessment [...] as of today I don’t see fully automated handling.” Others envisioned LLM cross-checks, using a second model to verify the first. In this context, E6 described an agentic setup in which one agent is responsible for highlighting the other’s mistakes. [Model ManagementG#] Participants envisioned training and fine-tuning as a universal countermeasure. E4, for instance, imagined fine-tuning a model to reliably “recognize registry keys or other IOCs.” In practice, however, they conceded they lacked the data, resources, or expertise to do so. A3 dismissed self-training as “disproportionate,” noting “we can’t go and train such a model for this task ourselves”, leaving market offerings as the only realistic, “plug-and-play” option. [Model Management ] Practitioners reported always using up-to-date models and described routinely tracking the best-performing models as part of their workflow. [Data Governance ] Participants viewed measures to prevent data breaches as the most feasible, primarily because they build on practices that SOCs already employ. In this context, M4 noted that each customer “gets their own server with their own customer instance [...] because they all have to be physically separated,” and that the LLM tooling simply inherited this separation. [Data GovernanceG#] E1 similarly insisted that mixing customer data “should [...] at its core not even be possible,” treating strict separation as an architectural default. They further suggested on-premises or private tenant hosting of LLMs, which we categorized under the theme of secure LLM deployment. M3 considered it “daily business [...] the same [as] for the SIEM and SOAR” and concluded data leakage was “not a big risk when self-hosting or running models locally.” Interestingly, this contrasts with the fact that 19 practitioners in our demographic survey also reported using commercial cloud environments in SOCs. [ExplainabilityG#] To make outputs easier to scrutinize, and avoid blind trust, thereby reducing over-reliance, partic- ipants wished for models to explain the reasoning behind their decisions and to cite sources: “I want the decision to be reasonable, and do fact checking. Does this decision make sense?” (E1) [Explainability ] Yet others questioned this. A4 cau- tioned that “source citations are not always reliable” and E5 observed that LLMs can provide sound reasoning even when wrong, suggesting explainability can drive over-reliance rather than mitigate it. [Organizational Measures ] Finally, participants pointed to organizational measures. M4 explained that their policy limits the data that may be entered into LLMs and prohibits the use of uncontrolled AI outputs. Practitioners stressed the importance of clear organizational guidelines, as R1 put it: “we [SOC practitioners] are good at technical problems, but we are bad at solving human problems [i.e., over-reliance].” [Organizational MeasuresG#] Moreover, Participants sug- gested regular awareness training and CI/CD-style validation pipelines as safeguards against over-reliance. Summary RQ3 Practitioners located the source of failure outside the model, attributing over-reliance to human factors, hal- lucinations to inadequate contextualization, and bias to people. Their dominant fear was missing a genuine threat, and they warned that LLMs would always fail on novel attacks. They raised adversarial attacks unprompted and viewed the LLM as a new privileged attack target, while bias and model drift drew little engagement. Countermeasures revealed a gap between envisioned and actual safeguards. In particular, technical safeguards such as RAG and fine-tuning remained mostly envisioned. 5. Discussion 5.1. SOC Readiness, Not Model Capabilities When our participants reasoned about the limits of LLMs in SOCs, a recurring theme was locating the failure outside the model. Hallucinated outputs were attributed to data problems, and biases to human error. Participants grounded this in “the inability of the SOC to feed the LLM with the correct data” (E7 ) (cf. section 4.2.1); participants also pointed to interoperability issues consistent with prior work [2], [4]. Taken together, these observations reframe the central question from whether an LLM is capable to whether the SOC is mature enough to deploy it safely. What sets the SOC apart is not the readiness challenge itself, common to LLM adoption anywhere, but rather what is at stake: missed intrusions or unnecessary damage to business processes. Design Recommendation: Before integrating LLMs into context-dependent tasks, SOCs should assess and strengthen the readiness of their data and processes. Research Opportunity: Future work could identify readiness factors that inform practitioners whether their SOC is mature enough for a given LLM use case, rather than assessing model capability in isolation. 5.2. Adoption Despite Concerns Previous studies have reported low adoption due to concerns about the reliability of AI in SOCs [7], [8], [9]. Our participants echoed these concerns. They ranked over-reliance above hallucinations (cf. fig. 6) and largely insisted on keeping a human in the loop, with only a minority willing to trust LLMs to make autonomous decisions (cf. section 4.3.2). These concerns reflect the asymmetric costs in cybersecurity: a false positive can be manually reviewed and discarded, whereas a missed attack is far more expensive. E1 (G#) pushed this logic further, arguing that LLMs should be fine-tuned to “tend more towards false positives” (cf. section 4.3.2). As practitioners delegate security decisions to LLMs, their major concern moves toward the false negative an over-relied-upon model might wave through, away from the false positive concern that dominated in previous SOC work [4], [7]. As M1 captured it, “We went from chasing ghosts to missed attacks.” Yet while these concerns previously led to low adoption and outright rejection of AI systems, our participants ex- pressed a strong willingness to adopt them anyway, citing competitive pressure. They argued that defenders must keep pace with attackers, which leaves organizations little choice but to adopt LLMs despite unresolved reliability concerns. Indeed, a growing number of reports describe cyberattacks facilitated by LLMs [70], [71], [72], [73], [74] and organizations are rapidly integrating them [75], [76]. At the same time, participants noted that LLMs embedded in SOC workflows become a highly privileged attack target, adding to the existing challenges (cf. section 4.3.1). Design Recommendation: Until LLMs demonstrate reliable security reasoning, they should remain assistive, and every high-impact output should be paired with an explicit verifi- cation step in which the person best positioned to catch the error checks it. Research Opportunity: Over-reliance warrants further in- vestigation. Future work could compare senior and junior analysts triaging alerts with and without LLM assistance under time pressure, varying the model’s output features, including reasoning, source citations, or confidence indicators, to identify factors that foster over-reliance and the safeguards that mitigate it. 5.3. Envisioned Versus Actual Use We found a disconnect between envisioned and actual LLM use. Practitioners deploy LLMs in production for language-centric tasks (e.g., report automation, onboarding), while rating high-impact tasks such as incident analysis as low in feasibility (cf. fig. 5). Based on their experience with current general-purpose LLMs, participants judged these models insufficient for use cases requiring specialized security expertise or organization-specific knowledge ( ). This amplified concerns about over-reliance and the fear of missing genuine threats. They called for security-specific solutions (G#), citing vendor-integrated threat hunting as a positive example. Singh et al. [42] analyzed 3,090 LLM queries from 45 an- alysts in a single SOC over 10 months, finding that usage was dominated by on-demand sensemaking and context building rather than high-stakes security decisions. Notably, 93% of queries aligned with established cybersecurity competencies, suggesting analysts are already directing general-purpose LLMs toward security-specific tasks. However, it remains unclear whether the pattern generalizes across SOCs. If so, it suggests that using general-purpose LLMs for security- specific tasks is a consistent pattern, reinforcing the demand for purpose-built solutions. Design Recommendation: LLMs should be adopted in phases. They can support language-centric and knowledge-processing tasks today, while high-impact tasks such as triage, detection, and response should be deferred until safeguards are in place. Research Opportunity: Future work should develop security- specific (e.g., RAG-based or fine-tuned) SOC models on contextual data such as logs, TI, and historical incidents and benchmark them against general-purpose baselines. 5.4. Envisioned Versus Actual Safeguards A recurring theme across our findings is the disconnect between the safeguards practitioners advocated and those they actually deployed (cf. section 4.3.2). For instance, RAG was widely envisioned as a mitigation against hallucinations and over-reliance, cited by nearly all participants, yet only one participant reported actual use. Similarly, fine-tuning was proposed for the same purpose but not implemented by any participants. This pattern extends to data governance: despite recommending to use on-premises hosting as a safeguard against data leakage, the same participants reported relying on commercial cloud LLMs (cf. Table 2). A similar gap appeared in governance: participants envisioned AI governance and policies, yet M1 reported that employees forwarded data to private email accounts to access ChatGPT and bypass these safeguards (cf. section 4.3.1). Likewise, while practitioners anticipated that model-provided reasoning and citations would build trust and reduce over-reliance, E5 ( ) warned that an LLM “can provide a persuasive argument even when it is incorrect,” undermining the assurances these features are meant to offer. Taken together, these observations raise the question of which proposed mitigations translate into meaningful protection under real operational conditions. Design Recommendation: Given the sensitivity of SOC data, LLMs should be deployed on-premises or in private tenants. However, they must offer capabilities comparable to commercial models, or practitioners may continue to favor external services. SOC managers should also assume shadow LLM use, which can circumvent policies and safeguards. Research Opportunity: Field studies should deploy LLMs across the use cases identified in this work and evaluate which countermeasures and safeguards hold in practice. Hahn et al. [41] co-developed an LLM companion; such work should be extended to the broader set of use cases identified here. 6. Conclusion To understand how LLMs are being integrated into security operations, we conducted a qualitative study with 25 SOC practitioners who had prior LLM experience, combining semi-structured interviews with interactive brainstorming and visualization tasks. Across the 15 use cases we discussed with participants, we found that practitioners integrate LLMs for language-centric tasks such as report automation, but perceive high-impact tasks such as incident analysis as low in feasibility. They judged current general-purpose models insufficient for work that requires security- and organization- specific knowledge. Yet they attributed these limitations less to the models than to the readiness of their SOCs and to human factors. Despite concerns, practitioners expressed a strong willingness to adopt LLMs, citing competitive pressure. Moreover, the safeguards they recommended to mitigate risks — RAG, fine-tuning, and on-premises deployment — were widely advocated but rarely deployed in practice. We conclude that LLMs are entering SOCs not because reliability concerns have been resolved, but because practitioners see few alternatives. The more practitioners delegate security decisions to LLMs, the more their concern shifts from false positives towards false negatives, driven by over-reliance and the fear of missing genuine threats. As M1 put it, “We went from chasing ghosts to missed attacks.” References [1]IBM, “What is a security operations center (SOC)?” 2024, [Online; accessed 2025-03-31]. [Online]. Available: https://w.ibm.com/thin k/topics/security-operations-center [2]M. Vielberth, F. Bohm, I. Fichtinger, and G. Pernul, “Security operations center: A systematic study and open challenges,” IEEE Access, vol. 8, 2020. [3]“Security Operations Center (SOC) Roles and Responsibilities,” [Online; accessed 2025-07-16]. [Online]. Available: https://w. paloaltonetworks.com/cyberpedia/soc-roles-and-responsibilities#:~: text=Its%20primary%20function%20is%20to,security%20solutions %2C%20tools%20and%20products. [4] S. Nepal, J. Hernandez, R. Lewis, A. Chaudhry, B. Houck, E. Knudsen, R. Rojas, B. Tankus, H. Prafullchandra, and M. Czerwinski, “Burnout in cybersecurity incident responders: Exploring the factors that light the fire,” Proc. ACM Hum.-Comput. Interact., vol. 8, 2024. [5]S. C. Sundaramurthy, A. G. Bardas, J. Case, X. Ou, M. Wesch, J. McHugh, and S. R. Rajagopalan, “A human capital model for mitigating security analyst burnout,” in Eleventh Symposium On Usable Privacy and Security (SOUPS 2015). Ottawa, Canada: USENIX Association, 2015. [6]S. C. Sundaramurthy, J. Case, T. Truong, L. Zomlot, and M. Hoffmann, “A tale of three security operation centers,” in Proceedings of the 2014 ACM Workshop on Security Information Workers, ser. SIW ’14. New York, NY, USA: Association for Computing Machinery, 2014. [7]B. A. Alahmadi, L. Axon, and I. Martinovic, “99% False Positives: A Qualitative Study of SOC Analysts’ Perspectives on Security Alarms,” in 31st USENIX Security Symposium (USENIX Security 22). Boston, MA: USENIX Association, 2022. [8]J. Mink, H. Benkraouda, L. Yang, A. Ciptadi, A. Ahmadzadeh, D. Votipka, and G. Wang, “Everybody’s got ML, tell me what else you have: Practitioners’ perception of ML-based security tools and explanations,” in 2023 IEEE Symposium on Security and Privacy (SP). San Francisco, CA, USA: IEEE Computer Society, 2023. [9]S. Oesch, R. Bridges, J. Smith, J. Beaver, J. Goodall, K. Huffer, C. Miles, and D. Scofield, “An assessment of the usability of machine learning based tools for the security operations center,” in 2020 International Conferences on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData) and IEEE Congress on Cybermatics (Cybermatics). Rhodes, Greece: IEEE, 2020. [10]S. Freitas, J. Kalajdjieski, A. Gharib, and R. McCann, “AI-driven guided response for security operation centers with microsoft copilot for security,” 2024, [Online; accessed 2025-03-21]. [Online]. Available: https://arxiv.org/pdf/2407.09017 [11] M. A. Ferrag, M. Ndhlovu, N. Tihanyi, L. C. Cordeiro, M. Debbah, T. Lestable, and N. S. Thandi, “Revolutionizing cyber threat detec- tion with large language models: A privacy-preserving BERT-based lightweight model for IoT/IIoT devices,” IEEE Access, vol. 12, 2024. [12]M. A. Ferrag, F. Alwahedi, A. Battah, B. Cherif, A. Mechri, N. Tihanyi, T. Bisztray, and M. Debbah, “Generative AI in cybersecurity: A comprehensive review of LLM applications and vulnerabilities,” Internet of Things and Cyber-Physical Systems, 2025, [Online; accessed 2025-03-21]. [Online]. Available: https: //w.sciencedirect.com/science/article/pii/S2667345225000082 [13] V. R. Saddi, S. K. Gopal, A. S. Mohammed, S. Dhanasekaran, and M. S. Naruka, “Examine the Role of Generative AI in Enhancing Threat Intelligence and Cyber Security Measures,” in 2024 2nd International Conference on Disruptive Technologies (ICDT). Greater Noida, India: IEEE, 2024. [14]P. Tseng, Z. Yeh, X. Dai, and P. Liu, “Using LLMs to automate threat intelligence analysis workflows in security operation centers,” 2024, [Online; accessed 2025-03-21]. [Online]. Available: https://arxiv.org/pdf/2407.13093 [15]E. Mezzi, F. Massacci, and K. Tuma, “Large Language Models are Unreliable for Cyber Threat Intelligence,” Mar. 2025, [Online; accessed 2025-04-11]. [Online]. Available: https://arxiv.org/pdf/2503.23175 [16]I. Elsharef, Z. Zeng, and Z. Gu, “Facilitating threat modeling by leveraging large language models,” in Proceedings 2024 Workshop on AI Systems with Confidential Computing. San Diego, CA, USA: Internet Society, 2024. [17]A. Hartsock, L. M. Pereira, and G. Fink, “Towards characterizing cyber networks with large language models,” 2024, [Online; accessed 2025-03-21]. [Online]. Available: https://arxiv.org/pdf/2411.07089 [18]M. Hassanin and N. Moustafa, “A comprehensive overview of large language models (LLMs) for cyber defences: Opportunities and directions,” 2024, [Online; accessed 2025-03-21]. [Online]. Available: https://arxiv.org/pdf/2405.14487 [19]R. Pasupuleti, R. Vadapalli, and C. Mader, “Cyber security issues and challenges related to generative AI and ChatGPT,” in 2023 Tenth International Conference on Social Networks Analysis, Management and Security (SNAMS). Abu Dhabi, United Arab Emirates: IEEE, 2023. [20]H. Xu, S. Wang, N. Li, K. Wang, Y. Zhao, K. Chen, T. Yu, Y. Liu, and H. Wang, “Large language models for cyber security: A systematic literature review,” 2024, [Online; accessed 2025-03-21]. [Online]. Available: https://arxiv.org/pdf/2405.04760 [21]H. Sajid, “AI Security Trends 2025: Market Overview & Statistics | Lakera – Protecting AI teams that disrupt the world.” [Online; accessed 2025-07-10]. [Online]. Available: https: //w.lakera.ai/blog/ai-security-trends [22]“Generative AI: What Is It, Tools, Models, Applications and Use Cases,” [Online; accessed 2025-07-10]. [Online]. Available: https://w.gartner.com/en/topics/generative-ai [23]A. F. B. Nathan Crilly, “Graphic Elicitation: Using Research Diagrams as Interview Stimuli,” ResearchGate, 2006, [Online; accessed 2025-07-10 | Request PDF]. [Online]. Available: https: //w.researchgate.net/publication/258182426_Graphic_Elicitation _Using_Research_Diagrams_as_Interview_Stimuli [24] T. M. Amabile, M. A. Collins, R. Conti, E. Phillips, M. Picariello, J. Ruscio, and D. Whitney, “Creativity in Context: Update to The Social Psychology of Creativity,” 2018. [25]F. B. Kokulu, A. Soneji, T. Bao, Y. Shoshitaishvili, Z. Zhao, A. Doupé, and G.-J. Ahn, “Matched and mismatched SOCs: A qualitative study on security operations center issues,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’19. New York, NY, USA: Association for Computing Machinery, 2019. [26]D. Schlette, M. Caselli, and G. Pernul, “A comparative study on cyber threat intelligence: The security incident response perspective,” IEEE Communications Surveys & Tutorials, vol. 23, no. 4, 2021. [27]S. C. Sundaramurthy, J. McHugh, X. Ou, M. Wesch, A. G. Bardas, and S. R. Rajagopalan, “Turning contradictions into innovations or: How we learned to stop whining and improve security operations,” in Twelfth Symposium on Usable Privacy and Security (SOUPS 2016). Denver, CO, USA: USENIX Association, 2016. [28] S. Tariq, M. Baruwal Chhetri, S. Nepal, and C. Paris, “Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities,” ACM Comput. Surv., vol. 57, Mar. 2025. [29]Jack Tilbury and Stephen Flowerday, “Humans and automation: Augmenting security operation centers,” Journal of Cybersecurity and Privacy, vol. 4, 2024. [30] L. Yang, Z. Chen, C. Wang, Z. Zhang, S. Booma, P. Cao, C. Adam, A. Withers, Z. Kalbarczyk, R. K. Iyer, and G. Wang, “True attacks, attack attempts, or benign triggers? an empirical measurement of network alerts in a security operations center,” in 33rd USENIX Security Symposium (USENIX Security 24). Philadelphia, PA, USA: USENIX Association, 2024. [31]K. Helkala, B. J. Knox, Ø. Jøsok, R. G. Lugo, S. Sütterlin, G. O. Dyrkolbotn, and N. K. Svendsen, “Supporting the human in cyber defence,” in Computer Security, S. K. Katsikas, F. Cuppens, N. Cup- pens, C. Lambrinoudakis, C. Kalloniatis, J. Mylopoulos, A. Antón, and S. Gritzalis, Eds. Cham: Springer International Publishing, 2018. [32]G. Gerontakis, I. Voyiatzis, and P. Yannakopoulos, “Security operations center in education: Building an educational environment for attack and defense scenarios,” in Proceedings of the 26th Pan-Hellenic Conference on Informatics, ser. PCI ’22. New York, NY, USA: Association for Computing Machinery, 2023. [33] M. Nyre-Yu, “Identifying expertise gaps in cyber incident response: Cyber defender needs vs. technological development,” in Proceedings of the 54th Hawaii International Conference on System Sciences. Honolulu, HI: Annual Hawaii International Conference on System Sciences, 2021. [34] A. Shah, R. Ganesan, S. Jajodia, and H. Cam, “An outsourcing model for alert analysis in a cybersecurity operations center,” ACM Trans. Web, vol. 14, no. 1, 2020. [35] D. Schlette, P. Empl, M. Caselli, T. Schreck, and G. Pernul, “Do You Play It by the Books? A Study on Incident Response Playbooks and Influencing Factors,” in 2024 IEEE Symposium on Security and Privacy (SP). San Francisco, CA, USA: IEEE Computer Society, 2024. [36]R. Stevens, D. Votipka, J. Dykstra, F. Tomlinson, E. Quartararo, C. Ahern, and M. L. Mazurek, “How Ready is Your Ready? Assessing the Usability of Incident Response Playbook Frameworks,” in CHI Conference on Human Factors in Computing Systems. New Orleans LA USA: ACM, 2022. [37] Q. Zhang, A. Imran, E. Bardhi, T. Swamy, N. Zhang, M. Shahbaz, and K. Olukotun, “Caravan: Practical online learning of in-network ML models with labeling agents,” in Proceedings of the 3rd Workshop on Practical Adoption Challenges of ML for Systems. Austin TX USA: ACM, 2024. [38]I. Hasanov, S. Virtanen, A. Hakkala, and J. Isoaho, “Application of large language models in cybersecurity: A systematic literature review,” IEEE Access, vol. 12, 2024. [39]M. Vermeer, N. Kadenko, M. van Eeten, C. Gañán, and S. Parkin, “Alert Alchemy: SOC Workflows and Decisions in the Management of NIDS Rules,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’23. New York, NY, USA: Association for Computing Machinery, Nov. 2023. [40]J. H. Klemmer, S. A. Horstmann, N. Patnaik, C. Ludden, C. Burton, C. Powers, F. Massacci, A. Rahman, D. Votipka, H. R. Lipford, A. Rashid, A. Naiakshina, and S. Fahl, “Using AI Assistants in Software Development: A Qualitative Study on Security Practices and Concerns,” in Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’24. New York, NY, USA: Association for Computing Machinery, Dec. 2024. [41]F. Hahn, M. Mamoon, A. G. Bardas, M. Collins, J. Dudek, D. Lende, X. Ou, and S. R. Rajagopalan, “Non Disruptive Disruption: An Empirical Experience of Introducing LLMs in the SOC.” [Online]. Available: https://par.nsf.gov/biblio/10665797-non-disruptive-disrupt ion-empirical-experience-introducing-llms-soc [42] R. Singh, S. Tariq, F. Jalalvand, M. B. Chhetri, S. Nepal, C. Paris, and M. Lochner. LLMs in the SOC: An Empirical Study of Human-AI Collaboration in Security Operations Centres. arXiv.org. [Online]. Available: https://arxiv.org/abs/2508.18947v2 [43]Miro, “Miro,” 2025, [Online; accessed 2025-04-10]. [Online]. Available: https://miro.com/ [44]I. Zoom Communications, “Video Conferencing, Web Conferencing, Webinars, Screen Sharing,” Zoom, 2025, [Online; accessed 2025-04- 10]. [Online]. Available: https://zoom.us [45]L. Huang, W. Yu, W. Ma, W. Zhong, Z. Feng, H. Wang, Q. Chen, W. Peng, X. Feng, B. Qin, and T. Liu, “A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions,” ACM Trans. Inf. Syst., vol. 43, no. 2, Jan. 2025. [46]J. Echterhoff, Y. Liu, A. Alessa, J. McAuley, and Z. He, “Cognitive Bias in Decision-Making with LLMs,” Oct. 2024, [Online; accessed 2025-08-06]. [Online]. Available: https://arxiv.org/pdf/2403.00811 [47]S. Abdelnabi, A. Fay, G. Cherubin, A. Salem, M. Fritz, and A. Paverd, “Get My Drift? Catching LLM Task Drift with Activation Deltas,” in 2025 IEEE Conference on Secure and Trustworthy Machine Learning (SaTML), Apr. 2025. [48]S. E. Spatharioti, D. Rothschild, D. G. Goldstein, and J. M. Hofman, “Effects of LLM-based Search on Decision Making: Speed, Accuracy, and Overreliance,” in Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, ser. CHI ’25. New York, NY, USA: Association for Computing Machinery, Apr. 2025. [49]X. Zhou, M. Weyssow, R. Widyasari, T. Zhang, J. He, Y. Lyu, J. Chang, B. Zhang, D. Huang, and D. Lo, “LessLeak-Bench: A First Investigation of Data Leakage in LLMs Across 83 Software Engineering Benchmarks,” Feb. 2025, [Online; accessed 2025-08-06]. [Online]. Available: https://arxiv.org/pdf/2502.06215 [50]H. Kaur, S. Klivan, D. Votipka, Y. Acar, and S. Fahl, “Where to Recruit for Security Development Studies: Comparing Six Software Developer Samples,” in 31st USENIX Security Symposium (USENIX Security 22). Boston, MA: USENIX Association, 2022. [51] R. M. Ryan and E. L. Deci, “Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being.” American Psychologist, vol. 55, no. 1, 2000. [52]M. R. Lepper, D. Greene, and R. E. Nisbett, “Undermining children’s intrinsic interest with extrinsic reward: A test of the "overjustification" hypothesis,” Journal of Personality and Social Psychology, vol. 28, no. 1, 1973. [53]R. Serafini, S. A. Horstmann, and A. Naiakshina, “Engaging Company Developers in Security Research Studies: A Comprehensive Literature Review and Quantitative Survey,” in 33rd USENIX Security Symposium 2024. Proceedings, 2024. [54]V. Clarke, V. Braun, and N. Hayfield, “Thematic analysis,” in Qualitative Psychology: A Practical Guide to Research Methods, J. A. Smith, Ed. SAGE, 2015, vol. 3, p. 222–248. [55] V. Braun and V. Clarke, “Using thematic analysis in psychology,” Qualitative Research in Psychology, vol. 3, no. 2, p. 77–101, 2006. [56]D. Wermke, N. Wöhler, J. H. Klemmer, M. Fourné, Y. Acar, and S. Fahl, “Committed to Trust: A Qualitative Study on Security & Trust in Open Source Software Projects,” in 2022 IEEE Symposium on Security and Privacy (SP). San Francisco, CA, USA: IEEE, May 2022. [57]L. Gröber, R. Mrowczynski, N. Vijay, D. A. Muller, A. Dabrowski, and K. Krombholz, “To Cloud or not to Cloud: A Qualitative Study on Self-Hosters’ Motivation, Operation, and Security Mindset,” in 32nd USENIX Security Symposium (USENIX Security 23). Anaheim, CA: USENIX Association, 2023. [58]P. Klostermeyer, S. Amft, S. Höltervennhoff, A. Krause, N. Busch, and S. Fahl, “Skipping the Security Side Quests: A Qualitative Study on Security Practices and Challenges in Game Development,” in Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’24. New York, NY, USA: Association for Computing Machinery, Dec. 2024. [59] N. McDonald, S. Schoenebeck, and A. Forte, “Reliability and Inter- rater Reliability in Qualitative Research: Norms and Guidelines for CSCW and HCI Practice,” Proc. ACM Hum.-Comput. Interact., vol. 3, 2019. [Online]. Available: https://dl.acm.org/doi/10.1145/3359174 [60]V. Braun, V. Clarke, and N. Hayfield, “‘a starting point for your journey, not a map’: Nikki hayfield in conversation with virginia braun and victoria clarke about thematic analysis,” Qualitative research in psychology, vol. 19, no. 2, p. 424–445, 2022. [61] V. Braun and V. Clarke, “Reflecting on reflexive thematic analysis,” Qualitative Research in Sport, Exercise and Health, vol. 11, no. 4, p. 589–597, 2019. [62]—, “One size fits all? What counts as quality practice in (reflexive) thematic analysis?” Qualitative Research in Psychology, vol. 18, no. 3, p. 328–352, 2021. [63]Statista, “Share of women in cybersecurity teams by industry 2023,” Statista, 2025, [Online; accessed 2025-04-10]. [Online]. Available: https://w.statista.com/statistics/1465456/share-of-women-in-cyb ersecurity-teams-worldwide/ [64]J. Hielscher, M. Schöps, U. Menges, M. Gutfleisch, M. Helbling, and M. A. Sasse, “Lacking the tools and support to fix friction: Results from an interview study with security managers,” Usenix, Aug. 2023. [65]J. Hielscher, U. Menges, S. Parkin, A. Kluge, and M. A. Sasse, “Employees who Don’t accept the time security takes are not aware Enough”: The CISO view of Human-Centred security,” in 32nd USENIX Security Symposium (USENIX Security 23). Anaheim, CA: USENIX Association, Aug. 2023. [66]A. Danilova, A. Naiakshina, A. Rasgauski, and M. Smith, “Code Re- viewing as Methodology for Online Security Studies with Developers - A Case Study with Freelancers on Password Storage,” in Seventeenth Symposium on Usable Privacy and Security (SOUPS 2021). USENIX Association, Aug. 2021. [67] “Microsoft Security Copilot | Microsoft Security,” [Online; accessed 2025-07-25]. [Online]. Available: https://w.microsoft.com/en-us/se curity/business/ai-machine-learning/microsoft-security-copilot [68] “Splunk AI,” [Online; accessed 2025-07-25]. [Online]. Available: https: //w.splunk.com/en_us/solutions/splunk-artificial-intelligence.html [69]S. Team, “Snowflake Data Breach: What Happened and How to Prevent It,” StrongDM Team, 2024, [Online; accessed 2025-04-10]. [Online]. Available: https://w.strongdm.com/what-is/snowflake-data-breach [70] B. Holley. The zero-days are numbered | The Mozilla Blog. [Online]. Available: https://blog.mozilla.org/en/privacy-security/ai-security-zer o-day-vulnerabilities/ [71] C. Leng and C. Ho-him, “Arup lost $25mn in Hong Kong deepfake video conference scam.” [Online]. Available: https://w.ft.com/con tent/b977e8d4-664c-4ae4-8a8e-eb93bdf785ea?syn-25a6b1a6=1 [72] L. C. Ming. Fake military IDs, bogus résumés: How North Korean and Chinese hackers use AI tools to infiltrate companies and other targets. Business Insider. [Online]. Available: https: //w.businessinsider.com/north-korea-china-hackers-infiltrate-com panies-ai-resumes-military-id-2025-9 [73] N. Robins-Early, “CEO of world’s biggest ad firm targeted by deepfake scam.” [Online]. Available: https://w.theguardian.com/te chnology/article/2024/may/10/ceo-wpp-deepfake-scam [74]Claude Mythos Preview \ red.anthropic.com. [Online]. Available: https://red.anthropic.com/2026/mythos-preview/ [75]The State of AI: Global Survey 2025 | McKinsey. [Online]. Available: https://w.mckinsey.com/capabilities/quantumblack/our-insights/th e-state-of-ai?os=wtmbrgj5xbah&utm_source=chatgpt.com [76](27/10/2025-12:14:00) Generative AI shows rapid growth but yields mixed results. S&P Global Market Intelligence. [Online]. Available: https://w.spglobal.com/market-intelligence/en/news-insights/rese arch/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-r esults [77]M. Bailey, E. Kenneally, D. Maughan, and D. Dittrich, “ The Menlo Report ,” IEEE Security & Privacy, vol. 10, no. 02, Mar. 2012. [78]T. E. Parliament and the Council of the European Union, “General Data Protection Regulation (GDPR) Compliance Guidelines,” GDPR.eu, 2025, [Online; accessed 2025-04-10]. [Online]. Available: https://gdpr.eu/ [79]M. van Braak, E. de Groot, M. Veen, L. Welink, and E. Giroldi, “Eliciting tacit knowledge: The potential of a reflective approach to video-stimulated interviewing,” Perspectives on Medical Education, vol. 7, no. 6, Dec. 2018. [Online]. Available: https://pmc.ncbi.nlm.nih.gov/articles/PMC6283779/ [80]G. Rose, Visual Methodologies: An Introduction to Researching with Visual Materials. London: SAGE Publications Ltd, 2016. [81]Miro security and compliance FAQ. Miro Help Center. [Online]. Available: https://help.miro.com/hc/en-us/articles/360012346599-Mir o-security-and-compliance-FAQ [82]OpenAI, “openai/whisper,” Mar. 2025, [Online; accessed 2025-04-10]. [Online]. Available: https://github.com/openai/whisper Appendix A. Ethics Considerations We proactively considered the ethical and legal implica- tions for all stakeholders potentially affected by this study. We adhered to the ethical principles outlined in the Menlo Report [77] and handled all study data and participant information in accordance with the General Data Protection Regulation (GDPR) [78]. In the following, we discuss the potential risks and benefits for the identified stakeholder groups, as well as the measures implemented to protect them throughout the study. At the time the study was conducted, our institution did not maintain an Institutional Review Board (IRB). Recruitment Strategy Our recruitment strategy (see sec- tion 3.3) allowed us to invite practitioners who actively work in or closely collaborate with SOCs. Alternative recruitment channels, such as social media platforms, were avoided, as they would have limited our ability to verify participants’ professional roles. Participation was voluntary and unpaid. This decision was made to avoid financial incentives. Prior work indicates that intrinsic motivation plays an important role in creative and reflective tasks, which were central to this study [24], [51], [52]. Consistent with findings by Serafini et al. [53], none of the participants reported discomfort. Instead, they expressed appreciation for the opportunity to reflect critically on the use of LLMs in real-world SOC environments. Participants’ Rights Potential participants were first sent an invitation explaining the purpose of the study and empha- sizing that participation was entirely voluntary. Those who expressed interest were then asked to review and complete a written consent form. The consent form described the study process, how data would be collected and used in accordance with the GDPR, how it would be protected, that participants could terminate their involvement in the study at any time without repercussions. After providing written consent, participants completed a short demographic and screening survey. Those who met the study criteria were then invited to take part in an interview. At the start of each interview, participants were reminded of their rights, includ- ing the option to withdraw at any time without consequence, to skip questions they felt uncomfortable answering, and to disable the video. Recording began after verbal consent had been confirmed. Interactive Task Design (Miro Board) To support reflec- tion on LLM integration in SOC workflows, we incorporated interactive tasks using individual Miro [43] boards during the interviews. An alternative approach would have been to conduct these activities purely verbally. However, prior work shows that visual and interactive elicitation techniques support deeper reflection and help participants externalize tacit knowledge [24], [79], [80]. The tasks were designed to focus on abstract workflows rather than concrete incidents or customer data, and we explicitly instructed participants not to enter any customer-specific, operationally sensitive, or personally identifying information. Prior to the interview session, participants received instructions on how to access their individual board, including the option to join via a guest account without creating or logging into a personal Miro account. We also informed them that using a guest account reduces potential privacy risks (i.e., interactions linked to the account), but that Miro may still collect technical metadata, including IP address, browser, and device information. We note that some participants may nonetheless have accessed the board while logged in to their existing Miro accounts. While no directly identifying information (e.g., names or demographic details) was collected within the Miro boards, all participant contributions constitute personal data. Miro processes data in compliance with the GDPR [81]. To further mitigate associated risks, each board was individually password- protected and accessible only to the respective participant and the interviewer. Immediately following each interview, the Miro boards were exported as PNGs and then permanently deleted from the Miro platform to ensure that no potential personal accounts remained linked to the data. Prior to analysis, one researcher reviewed each exported board to confirm that no personally identifiable, customer-specific, or sensitive operational information was present, anonymizing it where necessary. No directly identifying information (e.g., names) was found. The anonymized boards and interview transcripts were stored on secure university servers with restricted access to the research team. Data Collection Data were collected at multiple stages of the study, including the demographic and screening survey, interview recordings, and artifacts produced during the interactive Miro board tasks. Only anonymized data were retained. We stored all participants’ data encrypted using GDPR-compliant services. We used Whisper [82] locally for GDPR-compliant transcriptions of the recordings. After transcription, one researcher checked all transcripts for errors and ensured all transcripts were anonymized. Once transcription was finalized, we deleted the recording. Naturally, the artifacts related to this study are accessible exclusively to the members directly involved in the study. At no stage do we share any raw or processed data with any third-party entities. Participant Benefits This study was designed to provide direct and indirect benefits to both participants and the broader SOC community. During the interviews, participants were given structured opportunities to reflect on their own use of LLMs, anticipated risks, and integration strategies. Participants explicitly stated that this process helped them identify previously unconsidered challenges, clarify their assumptions, and articulate organizational concerns related to governance, accountability, and over-reliance. Participants responded positively to the study and expressed appreciation for the opportunity to share their perspectives. Benefits to the SOC Community Beyond the individual benefits, this study aims to provide researchers, tool builders, and SOC decision-makers with aggregated insights into practitioners’ expectations, constraints, and risk perceptions regarding LLM adoption. By grounding discussions of LLM integration in practitioners’ experiences, our findings will help ensure that future integration is more realistic, human- centred, and operationally safe.

Instant research discovery