A Practical Incident-Response Framework for Generative AI Systems

Abstract

Generative Artificial Intelligence (GenAI) systems have introduced new classes of security incidents that traditional response frameworks were not designed to manage, ranging from model manipulation and data exfiltration to misinformation cascades and prompt-based privilege escalation. This study proposes a Practical Incident-Response Framework for Generative AI Systems (GenAI-IRF) that bridges established cybersecurity standards with emerging AI assurance principles. Using a Design Science Research (DSR) approach, this study identifies six recurrent incident archetypes and formalises a structured playbook aligned with NIST SP 800-61r3, NIST AI 600-1, MITRE ATLAS, and OWASP LLM Top-10. The artefact was evaluated in controlled scenarios using scenario-based simulations and expert reviews involving AI-security practitioners from academia, finance, and technology sectors. The results suggest high inter-rater reliability (κ = 0.88), strong usability (SUS = 86.4), and improved incident resolution times compared to baseline procedures. The findings demonstrate how traditional response models can be adapted to GenAI contexts using taxonomy-driven analysis, artefact-centred validation, and practitioner feedback. This framework provides a practical foundation for security teams seeking to operationalise AI incident response and contributes to the emerging body of work on trustworthy and resilient AI systems.

1. Introduction

The rapid integration of Large Language Models (LLMs) into enterprise workflows represents a paradigm shift in how organisations innovate, automate, and interact with data. From powering customer-facing chatbots to augmenting complex internal analytics, the capabilities of Generative Artificial Intelligence (GenAI) have unlocked unprecedented efficiencies. Recent industry surveys indicate that GenAI adoption soared to 71% in 2024, driven by record private investment and accelerating business usage [1,2]. Simultaneously, reported AI-related incidents increased by 56.4% in 2024, reaching a record high [2].

This widespread deployment brings with it novel failure modes and threat vectors distinct from traditional cybersecurity incidents, including sophisticated techniques such as prompt injection, data poisoning, and the leakage of proprietary data via model inference. The real-world impact is significant, with nearly half of organisations reporting negative consequences from their use of GenAI. However, while adoption is accelerating, operational preparedness is lagging. Industry analysis reveals that 65% of security professionals lack education on GenAI implications, and less than one in seven companies globally are classified as fully prepared for AI security risks [3,4].

1.1. Problem Statement

The central problem is that enterprise adoption and regulatory scrutiny are rising faster than operational preparedness. Organisations lack clear policies, robust access controls, and, most critically, streamlined workflows for LLM-specific incidents. While foundational incident response frameworks exist, they are often ill-suited to the non-deterministic nature of Generative AI. As researchers highlight, unlike for traditional IT, there is an “absence of well-established risk assessment or threat modelling processes for LLM-based systems” [5]. This creates a critical industry blind spot: security teams are left without structured, repeatable, and auditable workflows for managing novel threats like jailbreaks or model hallucination loops.

This operational lag is further intensified by the significant cognitive load imposed on security teams when managing non-deterministic AI failures. Research indicates that the high-pressure nature of such incidents, coupled with technical ambiguity, makes responders more susceptible to errors, slower resolution times, and overlooked alerts. This challenge is fundamentally an operational synthesis gap: while the industry possesses the procedural “skeleton” (general IR steps) and the tactical “flesh” (specific AI threats), it lacks the connective tissue required to bridge the distance between high-level governance standards and tactical execution. Without this synthesis, organisations cannot transform strategic intent into the structured, repeatable workflows necessary for resilient and auditable AI incident management.

1.2. Research Contribution

This paper addresses this gap by proposing a Practical Incident-Response Framework for Generative AI systems. Using a Design Science Research (DSR) methodology, we synthesise fragmented guidance from disparate standards into a unified, operational playbook. This study introduces a novel “response-centric” taxonomy that clusters incidents not merely by vulnerability, but by the similarity of their containment and eradication workflows. The resulting artefact provides security practitioners with a validated, role-based, and standards-aligned tool to bridge the gap between high-level strategy and operational necessity.

2. Literature Review

This section analyses the evolution of cybersecurity standards, evaluates current AI-specific risk frameworks, and identifies the theoretical and operational gaps that necessitate a specialised GenAI incident response framework.

2.1. The Limits of Classical Incident Response Foundations

For decades, two standards have served as the bedrock of the Incident Response (IR) discipline: NIST SP 800-61 and ISO/IEC 27035. NIST SP 800-61r3 establishes the foundational four-phase lifecycle (Preparation; Detection and Analysis; Containment, Eradication, and Recovery; Post-Incident Activity). ISO/IEC 27035 adds critical governance layers through its five-phase approach, emphasising assessment and decision-making [6,7].

While these frameworks provide an essential procedural “skeleton,” they possess a critical weakness regarding Generative AI: they assume deterministic failures with static Indicators of Compromise (IoCs). Classical frameworks lack specific guidance for non-deterministic, application-layer threats like prompt injection, which has no single “deterministic fix” [8] for AI-native recovery steps such as model rollbacks and weight verification. Furthermore, research by Patterson et al. (2023) highlights that generic frameworks often fail to support the “adaptive learning” required for complex, evolving systems, suggesting a need to adapt industrial safety methodologies for modern incident management [9].

The field of cybersecurity possesses comprehensive, general-purpose incident response playbooks like CISA [10] and AWS [11], which provide robust, multi-phase structures aligned with NIST SP 800 standards. However, their focus on traditional network and infrastructure threats renders them operationally misaligned with the unique, application-layer challenges of LLM failures.

2.2. LLM-Specific Threat and Failure Taxonomies

Research provides a granular classification of LLM-specific failure modes to address the novel attack surfaces of Generative AI. Key taxonomies include adversarial prompts, which are categorised into direct prompt injection originating from user input and indirect prompt injection hidden within retrieved third-party data or RAG agents [12,13]. This category also encompasses jailbreaking, a manipulation technique used to bypass safety filters and force the generation of policy-violating content. Beyond input manipulation, output toxicity represents a significant risk where models generate harmful or biassed content rooted in training data. Furthermore, data exfiltration via prompts specifically targets confidentiality by attempting to reconstruct sensitive personally identifiable information (PII) memorised during training. Finally, Model Denial-of-Service and cost exhaustion involve “overhead attacks” that exploit computationally expensive processing paths to incur significant financial costs or cause service degradation for legitimate users [14].

Empirical evidence confirms the urgency of these taxonomies. Notable post-mortems include the March 2023 OpenAI ChatGPT history leak, where a caching library bug necessitated an emergency service shutdown and regulatory notification [15]. Beyond external attacks, Anthropic Research (2025) on “agentic misalignment” highlights a novel failure mode where models can exhibit malicious insider threat behaviours, such as blackmail or espionage, when their programmed goals are threatened in simulated corporate environments [16]. Additional documented failures, such as the 2024 Wiz report on AWS Bedrock hijacking and the 2025 Grok antisemitic rant, underscore the diversity of the threat landscape, ranging from compromised cloud credentials to indirect prompt injection via third-party data sources [17].

2.3. The Emergence of AI-Specific Threat and Risk Models

To address the inadequacies of classical frameworks, a second layer of AI-specific guidance has emerged.

• Threat Taxonomies: The OWASP Top 10 for LLM Applications identifies critical application-level vulnerabilities (e.g., LLM01: Prompt Injection; LLM02: Insecure Output Handling). Complementing this, MITRE ATLAS provides an adversary-centric taxonomy of tactics and techniques (TTPs), mapping the “how” of an attack from Reconnaissance to Exfiltration [18,19].
• Governance Frameworks: The NIST AI Risk Management Framework (AI RMF) and its Generative AI Profile (NIST AI 600-1) bridge the gap between governance and risk. NIST AI 600-1 explicitly calls for organisations to “establish incident response plans for third-party GenAI technologies”. Guidance from CERT-EU provides a policy perspective, emphasising organisational readiness and communication protocols, essential for governance [20,21,22].

However, while these frameworks provide the “what” (vulnerabilities) and the “why” (governance), they fall short of detailing the operational “how.” NIST AI 600-1 prescribes that a plan should exist, but does not provide the step-by-step containment workflows required during a crisis. Researchers underscore the necessity of integrating the NIST AI RMF, to secure LLM workloads critiques that RMF is primarily a high-level governance tool that “lacks technical details about threats or mitigations” and has gaps, including inadequate guidance on system interactions, sensitive data handling, quantitative risk assessment, and security auditing frameworks [23].

2.4. Crisis Management Theory and Cognitive Load

The necessity for a structured playbook is further supported by crisis management theory regarding cognitive load. The novel, high-pressure nature of LLM failures significantly increases the cognitive burden on response teams. Vaishnav & Goel (2025) argue that high cognitive load makes responders prone to errors, slower responses, and overlooked alerts [24].

In the context of GenAI, where attacks like “indirect prompt injection” can be ambiguous and technically complex, this risk is amplified. A well-designed playbook acts as a cognitive aid. By clustering complex risks into a manageable number of archetypes and providing pre-defined decision gates, a playbook reduces “procedural ambiguity,” freeing up the team’s attentional resources for technical analysis rather than process management.

To address the identified ‘operational synthesis gap’, this framework integrates Weick’s Theory of Sensemaking (1995), positioning the GenAI-IRF as a vital cognitive bridge during organisational crises [25]. Given the non-deterministic nature of GenAI, security incidents often present as ambiguous ‘shocks’ that impose a heavy cognitive load on responders. By providing six structured archetypes, the framework assists in ‘cue extraction’, the process of isolating critical indicators from chaotic model outputs to form a coherent frame for action. This facilitates rapid ‘enactment’ and supports the ‘incident learning’ cycles advocated by Ahmad et al. (2020), ensuring that tactical responses are not only faster, but are also systematically integrated into broader organisational governance and policy updates [26].

2.5. Governance and Organisational Dimensions

The EU AI Act establishes comprehensive governance requirements for AI incident response, particularly through Article 73, which mandates serious incident reporting. Providers of high-risk AI systems must report incidents to market surveillance authorities within strict timeframes [27]. This transforms the development of a structured, auditable IR playbook from a best practice into a legal necessity, compelling organisations to demonstrate procedural rigour in how they manage AI failures.

The Zero Trust principle of “never trust, always verify” is directly applicable to LLMs, where prompts and their outputs cannot be implicitly trusted. Recent research proposes applying this concept to preventative controls, using a Zero Trust-based guardrail framework with multiple validation steps through Policy Decision Point (PDP) and Policy Enforcement Point (PEP) structures to control responses to unethical queries [28]. An incident response playbook is the essential reactive component of such an architecture, providing the structured workflow for when preventative measures are bypassed and a breach is assumed.

Recent research offers LLM-native tools to aid incident response (IR). For example, the IRCopilot framework uses specialised LLM agents to automate technical tasks like evidence analysis [29], while other multi-agent systems simulate IR teams to improve collaboration [30]. However, these are automation tools, not organisational playbooks. They help individual technical responders but fail to orchestrate a complete, multi-disciplinary response. These frameworks omit non-technical roles (e.g., legal, communications) and do not cover the full organisational lifecycle, such as the governance reviews and policy updates needed to improve security processes (Bedoya, Palacios, Díaz-López, Laverde, & Nespoli, 2024) [31].

2.6. Synthesis and Research Gap

Table 1 summarises how existing standards and initiatives address AI or cybersecurity incidents and highlights the gap that motivated this research. While these frameworks contribute valuable perspectives, ranging from governance and taxonomy to technical vulnerabilities, none provide a fully integrated, operational process for managing incidents unique to Generative AI systems. The proposed GenAI-IRF seeks to bridge this gap by combining the lifecycle structure of traditional frameworks with AI-specific attack taxonomies and validation from practitioner feedback.

Table 1. Comparison of existing frameworks and the proposed GenAI-IRF.

Framework/Source	Primary Focus	Strengths	Limitations in GenAI Context	Position of the Proposed GenAI-IRF
NIST SP 800-61r3 (Computer Security Incident Handling Guide)	General cyber incident response lifecycle	Mature structure (Preparation → Detection → Containment → Eradication → Recovery → Lessons learned)	Not designed for AI or model-centric incidents; lacks taxonomy for prompt or model misuse	Builds on this lifecycle but tailors each phase to GenAI incidents (prompt injection, data leakage, hallucination)
ISO/IEC 27035-2 (Information security incident management)	Organisational process and roles	Strong governance orientation; role clarity	Non-specific to AI technologies; no mapping to model architectures	Provides RACI-based alignment for GenAI-specific roles (Data Scientist, Model Owner, Ethics Lead)
NIST AI RMF 1.0/AI 600-1 (AI Risk Management and Incident Handling)	AI system risk and accountability	Introduces risk functions (Map, Measure, Manage, Govern); early AI-incident principles	Still conceptual; lacks operational workflows and response playbooks	Integrates AI RMF principles into a structured, incident response playbook validated through DSR
MITRE ATLAS	Knowledge base of adversarial tactics for ML systems	Comprehensive attack taxonomy and MITRE ATT&CK alignment	No guidance on containment, recovery, or cross-team coordination	Uses ATLAS attack patterns to populate six archetypes (A1–A6) in the proposed framework
OWASP LLM Top-10 (2023)	Application-level security risks in LLMs	Widely recognised in industry; focuses on developer-side risks	Focused on prevention; limited post-incident guidance	Maps each OWASP LLM risk to specific detection and response steps
Industry Guidelines (e.g., ENISA 2024, Google/Anthropic AI Incident Taxonomies)	Emerging best practices for AI risk and safety reporting	Highlights need for transparency and responsible disclosure	Fragmented; lacks unified, practitioner-tested processes	Synthesises these into a single operational artefact evaluated with practitioners
Proposed GenAI-IRF (This Study)	Integrated GenAI incident response playbook	Synthesises NIST, MITRE, and OWASP perspectives; validated via expert review and scenario testing	—	Provides an actionable, practitioner-validated response structure addressing both technical and organisational aspects of GenAI incidents

Despite the availability of foundational standards and new threat intelligence, a significant operational synthesis gap remains.

• Lack of response-centric taxonomy: The current literature classifies incidents by vulnerability (OWASP) or adversary tactic (MITRE). There is a lack of classification based on response workflow similarity, a methodology necessary to create practical runbooks for distinct containment paths (e.g., distinguishing the response for “Data Leakage” vs. “Model Poisoning”).
• Disconnect between strategy and execution: While high-level guides exist (e.g., the OWASP GenAI Incident Response Guide), they often provide best practices rather than prescriptive, “run-card” style artefacts. They lack granular components such as Swimlane diagrams for cross-functional orchestration or RACI matrices with defined Service Level Agreements (SLAs).
• Disconnect between strategy and execution: While high-level guides exist (e.g., the OWASP GenAI Incident Response Guide), they often provide best practices rather than prescriptive “run-card”-style artefacts [32]. This observation is corroborated by Schlette et al. (2024), whose empirical analysis of over 1200 playbooks reveals that available resources are predominantly generic and “cannot be used outright” without significant transformation [33]. The study highlights that these playbooks intentionally abstract technical measures and often lack the specific commands required for execution. Consequently, organisations are left without granular components such as Swimlane diagrams for cross-functional orchestration or RACI matrices with defined Service Level Agreements (SLAs), forcing them to manually bridge the gap between abstract strategy and operational reality.
• The “Operational Synthesis” Gap: Beyond technical remediation, the GenAI-IRF addresses the conceptual gap identified by Shaked et al. (2023) regarding the lack of operational context in traditional cyber playbooks [34]. Most existing frameworks fail to communicate the impact of an incident on non-security business functions. By integrating ‘Operations-informed’ workflows, specifically through the use of multi-disciplinary RACI matrices and Swimlane diagrams that involve Legal, PR, and AI Engineering, this framework ensures that GenAI incident response is not confined to a technical silo. This alignment allows for a clearer understanding of the operational impact, shifting the focus from purely process-driven responses to a model that supports broader organisational resilience.

This research addresses these deficiencies by developing a framework that synthesises these disparate elements into operational playbooks, validated for usability and completeness.

3. Materials and Methods

3.1. Research Design: A Design Science Approach

To address the identified gap for a practical, operational solution, this study employed a Design Science Research (DSR) framework. DSR is uniquely suited for this research, as its primary objective is the creation and evaluation of a novel artefact, in this case, a suite of IR playbooks, to solve a recognised real-world problem [35]. This engineering-led approach ensures a tangible contribution beyond theoretical analysis [36]. The research was operationalised through a structured, three-phase workflow:

• Categorisation of LLM-specific incident archetypes;
• Artefact design and standards synthesis;
• Design of the playbook artefact, and empirical evaluation of its usability.

3.2. Phase 1: Categorisation of LLM-Specific Incident Archetypes

The initial phase focused on creating a foundational taxonomy of GenAI incidents. This involved a systematic process of document analysis and thematic clustering [37], synthesising data from authoritative threat taxonomies (e.g., OWASP Top 10 for LLMs), public incident post-mortems, and foundational security frameworks. A novel methodological decision was made to cluster threats not by their vulnerability type, but by the similarity of their operational incident response workflows, particularly their containment and eradication paths. This approach was chosen to maximise the practical utility of the resulting taxonomy for a security operations team requiring distinct runbooks for materially different incidents.

To ensure this classification process was rigorous and reproducible, a formal clustering codebook was developed. This codebook contained explicit inclusion and exclusion criteria, definitions, and boundary cases for each potential incident archetype. To validate the reliability of this classification scheme, an inter-rater reliability analysis was conducted. Two independent raters used the finalised codebook to classify a sample of 30 publicly documented GenAI incidents. The level of agreement between the raters was measured using Cohen’s Kappa coefficient, a robust statistical measure for inter-rater agreement [38]. The analysis yielded a coefficient of κ = 0.88, which is interpreted as “almost perfect agreement,” providing strong quantitative validation for the reliability and objectivity of the developed taxonomy.

The initial phase focused on the categorisation of LLM-specific incident archetypes through an analysis of public incident reports and authoritative threat taxonomies. These types were then clustered into distinct archetypes based on their unique response workflows. This process was undertaken to establish a foundational threat landscape for the incident response playbook. To ensure an objective and repeatable classification process, a detailed codebook was first developed. The reliability of this codebook was formally tested using an inter-rater reliability analysis. A sample of 30 publicly documented GenAI incidents from 2023 to 2025 was selected for classification by two independent raters. The level of agreement between the raters was measured using Cohen’s Kappa coefficient, a robust statistical measure for inter-rater agreement [38]. This metric was preferred over simple percentage agreement because it provides a more robust assessment of reliability by accounting for the probability of experts agreeing by random chance. A Cohen’s kappa coefficient of κ = 0.88 was calculated, indicating an ‘almost perfect’ level of agreement. The finalised codebook used for this process is presented in Figure 1.

Figure 1. Clustering codebook.

The central methodological decision was to cluster risks not by vulnerability type, but by the similarity of their incident response workflow, particularly the containment phase. This approach was chosen to maximise the operational utility of the final archetypes for a security operations team. The logic behind this clustering is best illustrated through examples of how initial risks were either split or merged. For instance, the OWASP risk ‘Prompt Injection’ was split into two separate archetypes: A1 (Direct) and A2 (Indirect). The analysis determined that while the root cause is similar, the containment paths are materially different.

A direct injection is contained by isolating the user session and patching input filters. An indirect injection requires a divergent workflow focused on identifying and cleansing the compromised upstream data source, which is a fundamentally different operational task. Conversely, the methodology led to the merging of ‘Training Data Poisoning’ (LLM03) and ‘Supply Chain Vulnerabilities’ (LLM05) into the single A4 (Model/Data Poisoning) archetype. The analysis of their respective response workflows revealed an approximately 80% overlap in containment and eradication steps, such as model rollback and hash verification of weights. As their response paths were not sufficiently distinct, they were consolidated into a single, more efficient runbook. This logic was applied systematically to the full set of known risks, with each resulting cluster being anchored to a real-world incident to ensure empirical relevance.

3.3. Phase 2: Artefact Design and Standards Synthesis

Following the development of the validated taxonomy, the research proceeded to the constructive design phase of the primary artefact. A key objective was to ensure the final playbook was not only practical, but also auditable and aligned with established governance standards. To achieve this, a dual-matrix system was developed to provide end-to-end traceability for every design choice within the playbook.

First, a threat and vulnerability traceability matrix was created for each of the six incident archetypes. This matrix served as the “red team” foundation, deconstructing the threat by mapping each archetype to its corresponding OWASP LLM vulnerabilities and the specific Tactics, Techniques, and Procedures (TTPs) from the MITRE ATLAS framework. Refer Figure 2.

Second, an incident response traceability matrix was developed to provide the “blue team” or defensive framework. This matrix used the six-phase incident response lifecycle adapted from NIST SP 800-61 as its procedural backbone. Crucially, every granular response action within the playbook was then explicitly mapped to a specific, auditable control from the NIST AI 600-1 framework (the Generative AI profile for the NIST AI RMF). This systematic synthesis ensures that every step in the playbook is traceable back to an authoritative source, making the entire framework auditable and demonstrating clear alignment with modern AI governance principles. Refer Figure 3.

3.4. Phase 3: Design of the Playbook Artefact and Empirical Evaluation of Its Usability

The final phase of the research was dedicated to the designing and empirical evaluation of the playbook artefact to confirm its fitness for purpose. A comprehensive, multi-component playbook was designed for each of the six incident archetypes. A scenario-based usability test was administered via a structured expert survey to validate the playbook for Archetype A1. This approach was chosen to move beyond theoretical validation and assess the playbook’s practical utility in a simulated crisis.

First, a coverage assessment was conducted to evaluate the playbook’s procedural completeness. The evaluation was grounded in a realistic and sophisticated threat scenario, the “Echo Chamber” storytelling jailbreak—a multi-turn, context-poisoning attack that uses narrative framing to bypass safety controls [39]. The playbook for Archetype A1, ‘Direct Prompt Injection and Jailbreaks’, was evaluated against this scenario. A detailed coverage checklist was developed to map the playbook’s defined actions against the required response steps for the ‘Echo Chamber’ scenario. The ‘Echo Chamber’ jailbreak was introduced only at the evaluation stage as a realistic test scenario to assess whether the independently designed playbook provides procedural coverage and role-specific guidance for a sophisticated, multi-turn attack.

Following that, a usability test was conducted using a structured survey with a focused group of practitioners with relevant experience, representing the seven distinct multi-disciplinary roles required for a comprehensive response: Incident Commander, IR Team Lead, Security Engineer/SecOps-SRE, Forensic Lead, ML Engineer, Legal and Compliance, and Communications/PR.

Participants were recruited to represent the seven operational roles required for a comprehensive response. To ensure role validity, each participant met minimum expertise criteria relevant to their represented function (e.g., incident command experience for Incident Commander/IR Lead; operational on-call/SRE or SecOps experience for Security Engineer; case-handling or forensic investigation experience for Forensic Lead; model deployment/guardrails experience for ML Engineer; regulatory/compliance experience for Legal/Compliance; and crisis communications experience for Communications/PR). An anonymised summary of participant backgrounds is provided in Table 2.

Table 2. Expert panel profile (anonymised).

ID	Role Represented	Years in Role	Domain Context	Relevant Experience (Examples)	GenAI Exposure
P1	Incident Commander	8	Enterprise SOC	Led major incident bridges; regulator-facing reporting	Yes
P2	IR Team Lead	6	IR/Blue team	Playbook design; tabletop exercises	Yes
P3	SecOps/SRE	5	Cloud ops	On call; containment actions; SOAR workflows	Yes
P4	Forensic Lead	10	DFIR	Evidence handling; timeline reconstruction	Yes
P5	ML Engineer	4	MLOps	Model deployment; guardrails; rollback strategy	Yes
P6	Legal and Compliance	9	Reg/Legal	Breach assessment; notification obligations	Yes
P7	Comms/PR	7	Crisis comms	Incident comms templates; stakeholder mgmt	Yes

Figure 2. Threat and vulnerability traceability matrix for Archetype A1 [40].

Figure 2. Threat and vulnerability traceability matrix for Archetype A1 [40].

Figure 3. Incident response traceability matrix for Archetype A1.

Figure 3. Incident response traceability matrix for Archetype A1.

A mixed-methods approach was used for data collection. Quantitative data was collected to measure the playbook’s performance across three key metrics:

• Interpretation Accuracy (%): Measured using a task-based questionnaire to assess procedural clarity.
• Error Rate (%): Measured using a task-based questionnaire to assess the likelihood of error across diverse roles.
• Interpretation Efficiency (minutes): The time taken for participants to identify the correct course of action for their role in each IR phase.
• System Usability Scale (SUS): A validated, industry-standard ten-item questionnaire that yields a usability score from 0 to 100.

Qualitative data was also collected in the form of open-ended practitioner feedback to understand the playbook’s perceived benefits and operational value from the perspective of each distinct role. All research involving human participants was conducted in accordance with formal ethical approval guidelines.

4. Results

This section presents the primary outputs of the research, detailing the novel taxonomy of GenAI incidents, the structure of the playbook artefact, and the results of its empirical validation.

4.1. A Response-Centric Categorisation of GenAI Incidents

The thematic clustering process, validated by the inter-rater reliability analysis, resulted in the consolidation of numerous known GenAI risks into six distinct, operationally focused incident archetypes. The high inter-rater reliability score (κ = 0.88) validates that this logic, as captured in the codebook, is sufficiently robust and repeatable to be considered a reliable classification scheme. Each archetype is defined by a unique response and containment workflow, providing a practical foundation for tailored incident response plans. The six archetypes are summarised in Table 3.

Table 3. The six GenAI incident archetypes.

ID	Archetype	Definition/Attack Vector	Unique IR/Containment Path	Real-World Anchor
A1	Direct Prompt Injection and Jailbreaks	User’s direct input manipulates the LLM to bypass safety policies.	Isolate the user session and patch input filters before resuming service.	Bing “Skeleton Key” Jailbreak (2024) [40]
A2	Indirect Prompt Injection	Malicious instructions are hidden in an upstream data source (e.g., PDF, URL) and executed when the LLM ingests the content.	Identify and block the compromised upstream data source from the ingestion pipeline.	Grok Antisemitic Rant (2025) [41]
A3	Sensitive-Data Leakage	The LLM discloses confidential, proprietary, or personal information in its output due to a bug or model memorisation.	Immediately triggers data breach notification clocks, requiring engagement of Legal and DPO from the outset.	ChatGPT History Leak (2023) [42]
A4	Model/Data Poisoning	Tainted training data or compromised model weights are inserted into the AI supply chain, corrupting the model’s integrity.	Requires model rollback to a trusted “golden copy,” hash verification of weights, and a full dataset audit.	Trend Micro Tainted Weights (2025) [43]
A5	Plugin/Tool-chain Abuse	A vulnerability in an external plugin, API, or agent is exploited to perform unauthorised or destructive actions on downstream systems.	Requires immediate revocation of the plugin’s OAuth keys/API credentials and sandboxing of the service.	Replit “Vibe-Coding” Agent Escape (2025) [44]
A6	Resource Exhaustion/DoS (Cost-Drain)	An attacker uses stolen API keys or token-flood prompts to cause a denial of service or incur significant, unexpected financial costs.	Requires a cost freeze with the Cloud Service Provider (CSP), token-rate throttling, and credential rotation.	Sysdig LLMjacking Campaign (2024) [45]

4.2. The GenAI Incident Response Playbook Artefact

The primary research output is a suite of six comprehensive playbooks, one for each archetype. Each playbook is a multi-component artefact designed to guide a multi-disciplinary team through the full incident lifecycle. The structure is standardised across all archetypes to create a predictable mental model for responders, reducing cognitive load during a crisis. The playbook for Archetype A1 (direct prompt injection and jailbreaks) is used here as a representative example to illustrate the framework’s three core components.

The phase checklist (Table A1, Table A2, Table A3, Table A4, Table A5, Table A6, Table A7, Table A8, Table A9, Table A10, Table A11, Table A12, Table A13, Table A14, Table A15, Table A16, Table A17, Table A18, Table A19, Table A20, Table A21, Table A22, Table A23, Table A24, Table A25, Table A26 and Table A27) forms the procedural core of the playbook. It provides a granular, step-by-step workflow for each of the six IR phases (preparation, detection and analysis, containment, eradication, recovery, and post-incident review). Each phase is built with a standardised seven-part internal structure: objective, input triggers, actions step checklist, decision gate, communication hook, evidence to collect, and output as presented in Figure 4. This design transforms descriptive guidance into an actionable and auditable process. For example, the preparation phase includes actions like P5: develop guardrails (implementing input/output filters), while the containment phase includes C4: deploy emergency filter (deploying a temporary “hotfix” to block a specific exploit).

Figure 4. Playbook phase checklist structure.

The RACI Matrix is the playbook’s primary tool for role and responsibility management (Refer Figure A1, Figure A2, Figure A3, Figure A4, Figure A5 and Figure A6). It eliminates ambiguity by mapping every task from the phase checklists to the specific roles involved, defining each role function as Responsible, Accountable, Consulted, or Informed. A novel contribution to this framework is the inclusion of Target Service Level Agreement (SLA) Windows for time-critical actions and aggregate performance targets using industry-standard metrics. For instance, the RACI matrix for the detection and analysis phase of Archetype A1 specifies an SLA of <15 Mins for D1, Acknowledge Alert and Initial Triage, and sets an overall Target MTTD (Mean Time to Detect) of <1 h. This transforms the matrix from a simple responsibility chart into a measurable performance management tool.

The Swimlane diagram provides a high-level tool for visual workflow orchestration (Refer Figure A7, Figure A8, Figure A9, Figure A10, Figure A11 and Figure A12). It clearly represents the end-to-end process while delineating the responsibilities, hand-offs, and dependencies between the different functional teams. The diagram for the detection and analysis phase of Archetype A1, for example, visually illustrates the flow from an initial alert in the SecOps lane to a forensic analysis in the Forensic Lead lane and a crucial hand-off to the Legal and Compliance lane for an assessment of reporting obligations. This visual clarity is essential for managing the complex cross-functional coordination required during a GenAI incident [46]. Refer Figure 5.

Figure 5. Example RACI matrix for detection phase.

Diagrammatic Notation Selection: Several process-modelling notations could be used to visualise a multi-team incident response workflow (e.g., BPMN). Swimlane diagrams was selected because the primary objective of the visual artefact is cross-functional coordination under time pressure: explicitly representing roles, hand-offs, and dependencies across SecOps, Forensics, ML Engineering, Legal/Compliance, and Communications. Swimlanes align directly with the playbook’s responsibility-management layer (RACI), making accountability and handovers immediately legible in a crisis. In contrast, BPMN provides richer control-flow semantics, but introduces additional notation overhead that is not essential for the playbook’s intended use as a rapid cognitive aid during incident response. Refer Figure 6.

Figure 6. Example Swimlane diagram for containment phase.

4.3. Empirical Validation of Playbook Usability

To assess the playbook’s procedural completeness, a detailed coverage checklist was developed to map the Archetype A1 playbook’s defined actions against the required response steps for the ‘Echo Chamber’ scenario. The results confirmed that the playbook provided full procedural coverage for the incident. Every required checkpoint, across all phases of IR, was addressed by specific, referenced actions within the playbook, yielding an overall coverage score of 100% (Refer to Figure 7).

Figure 7. Coverage check for the “Echo Chamber” jailbreak scenario.

This suggests that the playbook for Archetype A1 provides comprehensive, end-to-end procedural coverage for a sophisticated and novel attack like the “Echo Chamber” jailbreak. The analysis shows that, for every critical stage of the incident, a clearly defined set of procedures exists within the playbook and demonstrates the artefact is fit for purpose as an operational guide.

The practical utility and operational effectiveness of the designed playbook artefact for Archetype A1 was measured through the scenario-based usability test (Refer Figure A13, Figure A14, Figure A15, Figure A16, Figure A17, Figure A18, Figure A19, Figure A20, Figure A21, Figure A22, Figure A23, Figure A24, Figure A25, Figure A26, Figure A27 and Figure A28, Appendix B). The results suggest strong quantitative and qualitative evidence of the playbook’s value. The quantitative metrics from the usability test demonstrated high performance across all measured dimensions. These key results are consolidated in Table 4.

Table 4. Summary of playbook usability test results.

Metric	Overall Result	Interpretation
Interpretation Accuracy	98.80%	The playbook’s design is clear and effective in guiding practitioners towards the correct actions, minimising procedural error.
Error Rate	1.20%	The low error rate further confirms the procedural clarity of the artefact.
Interpretation Efficiency	5.3 min	The structure facilitates rapid comprehension and decision-making, enabling a more efficient response.
System Usability Scale (SUS) Score	86.43%	This score is well above the industry average of about 68 and falls within the “excellent/best imaginable” range on the Bangor adjective scale [47] and the A/A+ band on the Sauro–Lewis curved grading scale [48], indicating high overall usability for the multi-disciplinary team.

Qualitative feedback from the practitioners further validated the playbook’s practical value. Participants highlighted the artefact’s ability to provide “immediate structure” and “only actionable steps,” which eliminates guesswork. The Incident Commander noted that the clear decision gates and SLAs make the response “fast and defensible.” The Forensic Lead valued the explicit evidence requirements, stating they allow the team to “reconstruct the timeline and produce a defensible report without hunting for process.” The ML Engineer confirmed the practicality of the remediation path, noting that it “aligns with how we ship fixes safely”. In addition to positive feedback, practitioners noted areas requiring refinement: “more explicit escalation triggers for Legal/PR”, “more concrete evidence artefact examples for ML logs”, and “guidance for SMEs where roles are combined”. These points can be addressed in future research. This feedback indicates that the playbook successfully orchestrates a complex, multi-disciplinary response in a manner that is intuitive and effective for all stakeholders.

5. Discussion

5.1. A Novel Framework for Operationalising GenAI Incident Response

The findings of this research present a significant step forward in operationalising security incident response for Generative AI. The development of a response-centric taxonomy addresses a key deficiency in the existing literature. While vulnerability-centric models like the OWASP Top 10 are essential for risk identification, they do not inherently guide the operational response. By clustering incidents based on the similarity of their containment workflows, the six-archetype framework provides a more practical and intuitive model for a Security Operations Centre (SOC) team. This structure allows for the development of distinct, tailored runbooks that reduce the cognitive load on responders during a high-pressure crisis, a critical human factor in effective incident response.

Furthermore, the multi-component playbook artefact directly addresses the procedural ambiguity that plagues responses to novel threats. The detailed phase checklists provide a clear, sequential path, while the granular RACI matrix eliminates uncertainty about roles and responsibilities. The visual Swimlane diagram serves as a powerful cognitive aid, clarifying the complex web of interactions and hand-offs required to coordinate a response across technical, legal, and communications teams. Together, these components create a resilient and predictable process that allows responders to focus their limited attentional resources on complex technical analysis rather than process management. Accordingly, claims about broader process management improvements are framed as plausible operational implications rather than empirically generalised effects.

5.2. Bridging the Gap Between Strategy and Execution

The true novelty of the proposed framework lies in its function as a translational tool that bridges the gap between high-level strategic frameworks and the operational necessity of a live incident. The literature review identified a landscape of fragmented standards and guidelines, but this research provides the missing implementation layer that synthesises them into a cohesive and actionable whole.

This translational function can be seen in the direct mapping within the framework’s design. For example, the abstract governance principle of “Govern” from the NIST AI Risk Management Framework is translated into concrete, auditable actions in the playbook’s Preparation phase, such as P2: Establish Legal Compliance Readiness and P3: Risk Assessment and Severity Definition. Similarly, an adversarial TTP from the MITRE ATLAS framework, such as AML.T0051—LLM Prompt Injection, is translated into a specific, tactical response action in the playbook, like C4: Deploy Emergency Filter, to block the exploit string. By providing this explicit, traceable linkage, the playbook framework moves beyond simply recommending standards and instead demonstrates how to implement them in a practical, operational context. It serves as the “connective tissue” that transforms disparate lists of risks, tactics, and principles into a single, unified, and executable workflow.

5.3. Implications for Practice and Scalability

The findings of this research have directed and actionable implications for organisations seeking to mature their security posture for GenAI. Based on the validated framework, three key recommendations for practice are proposed:

• Adopt Archetypes and Playbooks for Operational Readiness: Enterprise security leaders and SOC managers should adopt the six incident archetypes as a primary model for GenAI incident triage. The associated playbook structure can serve as a robust baseline for developing or enhancing internal IR plans, leading to a reduction in responder cognitive load, shortened time-to-containment, and demonstrable compliance with emerging regulations like the EU AI Act.
• Use the Playbook as a Blueprint for Scalable Automation: As an organisation’s GenAI footprint grows, a purely manual response will become untenable. The playbook’s defined logical steps, input/output triggers, and decision gates provide a clear and structured blueprint for integration into Security Orchestration, Automation, and Response (SOAR) platforms. This provides a direct path to automating key containment and eradication actions, enabling a more consistent and scalable response.
• Adaptation for Organisations with Limited Resources (e.g., SMEs): The playbook was designed as a generic model with the potential to be adapted to different environments, and it has not yet been tested for organisations with limited resources. Future work could focus on developing a “portability note” or an “adaptation checklist” to guide organisations in tailoring the playbook to their specific environments. For organisations such as SMEs, we anticipate combining multiple roles defined in the RACI matrix under one person. As a default, the framework recommends assigning distinct personnel to roles like ‘Incident Commander’, ‘Forensic Lead’, and ‘Legal and Compliance’. We anticipate that SME might assign multiple responsibilities to a single senior technical leader or rely on external counsel for legal decisions. The “seven-part internal structure” of the phase checklists, specifically the “Decision Gates” and “Input Triggers”, can remain as the operational core, ensuring that even with a smaller team, the response remains structured and auditable.
• Integrate the Playbook into a Continuous Improvement Lifecycle: The playbook should be treated as a living artefact, not a static document. The findings from the playbook’s own post-incident review phase should be used to update procedures after every real-world incident. Furthermore, the playbooks should be proactively tested and refined through the regular red teaming exercises mandated in the preparation phase. This practice ensures the framework remains relevant and effective against the rapidly evolving GenAI threat landscape.

5.4. Limitations and Future Research

In the interest of academic rigour, it is important to acknowledge the inherent limitations of this study, each of which presents a valuable opportunity for future research.

• Performance Under Real-World Incident Conditions: A primary limitation is that only the playbook for Archetype A1 was validated in a controlled, simulated environment. While the usability test indicates procedural clarity, it could not replicate the significant psychological pressures and organisational friction of a genuine security crisis. Future research could address this through qualitative, ethnographic studies involving the observation of a SOC using the framework during a live-fire exercise or a real incident to assess its resilience under duress. Future research can be conducted on validating the usability of the playbooks for the remaining archetypes.
• Limited External Validity and Portability: The playbook was designed as a generic model, and its applicability has not been tested across diverse organisational contexts (e.g., large enterprises vs. SMEs, different industry sectors). Future work could focus on developing a “portability note” or an “adaptation checklist” to guide organisations in tailoring the playbook to their specific environment, which could then be validated through tabletop exercises with diverse partner teams.
• Static Nature in a Dynamic Threat Landscape: This study acknowledges that the six incident archetypes and specific technical actions are based on the known GenAI threat landscape documented between 2023 and 2025. However, the framework presented in this study was designed to support evolution by adopting a response-centric, archetype-based structure. By clustering incidents based on the similarity of their containment workflows rather than specific attack techniques, the framework allows for new threat patterns to be mapped to existing operational paths without altering the core structure.

Specifically, the rise of multimodal GenAI models introduces complex risks that extend beyond text.

Future iterations must address “cross-modal injections,” where malicious payloads are embedded in images or audio to bypass text-based safety filters. Because the framework is response-centric, these new vectors can likely be managed by adapting the “Input Triggers” and “Detection” phases of the existing archetypes (e.g., expanding logs to capture image metadata), rather than requiring entirely new workflows.

To manage this, the framework requires a mechanism for continuous updates. We suggest that future research tracks emerging threats over time, eventually establishing a community-driven process similar to the OWASP Top 10 to regularly refresh the incident archetypes.

6. Conclusions

This research commenced with the identification of a critical and escalating problem: the rapid enterprise adoption of GenAI has created an operational readiness gap, leaving organisations without the specialised workflows needed to manage its unique security failures. This paper has presented a comprehensive answer to the research question of how established incident response stages can be adapted for this new threat landscape.

This research concludes that a successful adaptation requires a multi-stage process of synthesis and validation. The generic nature of established frameworks must first be focused on creating a response-centric taxonomy of incident archetypes. The procedural lifecycle of standards like NIST SP 800-61 must then be enriched by synthesising it with the threat intelligence of AI-specific frameworks like MITRE ATLAS and the auditable governance controls of NIST AI 600-1. Finally, this unified structure must be translated into a prescriptive, multi-component artefact that is empirically validated to confirm its operational usability.

This study has designed, developed, and evaluated exactly such an adaptation. The key outputs, a validated taxonomy of six incident archetypes (κ = 0.88) and a suite of playbook artefacts with one of the playbooks empirically proven high usability (SUS score of 86.43%) suggests a tangible solution to the identified problem. However, it is important to acknowledge that the empirical validation was conducted in a simulated environment using a focused expert panel. While this confirmed the framework’s usability and procedural logic, future research is required to test its resilience under the full operational pressure of a live, large-scale security incident. Furthermore, as GenAI evolves, future work must focus on expanding these archetypes to address emerging multimodal threats and on developing automated, real-time playbook adaptation mechanisms. By moving beyond high-level principles to produce a detailed, practical, and standards-aligned framework, this work offers immediate utility for organisations seeking to mature their operational readiness for GenAI incidents and provides a robust foundation for future academic research in this critical domain.

Appendix A.1. Phase Checklist

Appendix A.1.1. Preparation Phase

Objective: Establish preventative controls to minimise the likelihood and impact of prompt injection attacks.

Input Triggers

• Business requirements for the LLM application.
• The organisation’s need for LLM Incident Response Plan.

Actions Step Checklist

High Level Flow: Govern > Build > Validate > Train

Table A4. Actions step checklist for preparation phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
P1	Define IR Roles and Responsibilities: Constitute a dedicated incident response team for LLM incidents.	IR Lead	GV-2.1-002
P2	Establish Legal Compliance Readiness: Map relevant legal and contractual obligations (e.g., EU AI Act, UK GDPR, SLAs).	Legal and Compliance	GV-1.1-001
P3	Risk Assessment and Severity Definition: Risk-assess each LLM application against Incident Severity Matrix defining severity criteria.	Security Governance/GRC	GV-1.2-002, MS-2.7-001
P4	Establish Stakeholder Communication Plan: Develop a comprehensive communication plan identifying all key internal and external stakeholders.	Communications/PR	GV-4.3-003
P5	Develop Guardrails: Implement robust input/output filters and strict meta prompts as a multi-layered defence against malicious prompts.	ML Engineer	MG-3.2-005, MG-4.2-001
P6	Logging and Monitoring: Enable logging and monitoring of user prompts, model outputs, and system behaviour for analysis.	SecOps/SRE	MG-4.3-002, MG-4.2-001
P7	Operationalise Response Toolchain: Ensure the IR team’s required incident analysis tools, such as LLM log parsers and testing tools, are procured, configured, and accessible.	Security Engineer/SecOps–SRE	MS-2.7-001
P8	Threat Modelling: Conduct regular threat modelling sessions focused on emerging prompt injection and jailbreak techniques.	AI Engineering Lead	GV-3.2-005
P9	Red Teaming Exercises: Proactively test defences by conducting regular adversarial testing to identify vulnerabilities and potential misuse.	AI Engineering Lead	MP-5.1-005, MS-2.7-007
P10	Team Training and Drills: Conduct regular training and realistic tabletop exercises to validate the IR team’s readiness and the playbook’s effectiveness.	IR Lead	GV-2.1-002

Table A4. Actions step checklist for preparation phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
P1	Define IR Roles and Responsibilities: Constitute a dedicated incident response team for LLM incidents.	IR Lead	GV-2.1-002
P2	Establish Legal Compliance Readiness: Map relevant legal and contractual obligations (e.g., EU AI Act, UK GDPR, SLAs).	Legal and Compliance	GV-1.1-001
P3	Risk Assessment and Severity Definition: Risk-assess each LLM application against Incident Severity Matrix defining severity criteria.	Security Governance/GRC	GV-1.2-002, MS-2.7-001
P4	Establish Stakeholder Communication Plan: Develop a comprehensive communication plan identifying all key internal and external stakeholders.	Communications/PR	GV-4.3-003
P5	Develop Guardrails: Implement robust input/output filters and strict meta prompts as a multi-layered defence against malicious prompts.	ML Engineer	MG-3.2-005, MG-4.2-001
P6	Logging and Monitoring: Enable logging and monitoring of user prompts, model outputs, and system behaviour for analysis.	SecOps/SRE	MG-4.3-002, MG-4.2-001
P7	Operationalise Response Toolchain: Ensure the IR team’s required incident analysis tools, such as LLM log parsers and testing tools, are procured, configured, and accessible.	Security Engineer/SecOps–SRE	MS-2.7-001
P8	Threat Modelling: Conduct regular threat modelling sessions focused on emerging prompt injection and jailbreak techniques.	AI Engineering Lead	GV-3.2-005
P9	Red Teaming Exercises: Proactively test defences by conducting regular adversarial testing to identify vulnerabilities and potential misuse.	AI Engineering Lead	MP-5.1-005, MS-2.7-007
P10	Team Training and Drills: Conduct regular training and realistic tabletop exercises to validate the IR team’s readiness and the playbook’s effectiveness.	IR Lead	GV-2.1-002

Decision Gate

Table A5. Decision gate for preparation phase.

Decision	Triggers/Criteria for Action	Owner
IR Team Charter Approval	Formally approve the IR team’s structure, roles, and authority to grant them the official mandate to act during an incident.	CISO
Severity Matrix Approval	Approve the official criteria for classifying incident severity to ensure a consistent, organisation-wide standard.	CISO
Acceptable Use Policy	Formally define the boundary between a low-quality model output and a reportable security incident.	Security Governance/GRC
Tool and Function Access Policy	Define the tools and functions the LLM can use, and set their permission levels and sandboxing rules to limit potential harm.	AI Engineering Lead
Red Team Rules of Engagement	Approve the scope, methods, and disclosure process for all adversarial testing, balancing realistic simulation with operational risk.	Security Governance/GRC
Prompt and Output Log Retention Policy	Set the formal data retention period for all prompt and output logs, balancing forensic needs with compliance, privacy, and cost.	Legal and Compliance

Table A5. Decision gate for preparation phase.

Decision	Triggers/Criteria for Action	Owner
IR Team Charter Approval	Formally approve the IR team’s structure, roles, and authority to grant them the official mandate to act during an incident.	CISO
Severity Matrix Approval	Approve the official criteria for classifying incident severity to ensure a consistent, organisation-wide standard.	CISO
Acceptable Use Policy	Formally define the boundary between a low-quality model output and a reportable security incident.	Security Governance/GRC
Tool and Function Access Policy	Define the tools and functions the LLM can use, and set their permission levels and sandboxing rules to limit potential harm.	AI Engineering Lead
Red Team Rules of Engagement	Approve the scope, methods, and disclosure process for all adversarial testing, balancing realistic simulation with operational risk.	Security Governance/GRC
Prompt and Output Log Retention Policy	Set the formal data retention period for all prompt and output logs, balancing forensic needs with compliance, privacy, and cost.	Legal and Compliance

Communication Hook

Table A6. Communication hook for preparation phase.

Stakeholder	Method/Channel	Cadance/Trigger
Engineering and AI Dev Teams	Playbook Review Meeting	Quarterly, or following a significant change to the LLM application.
SOC and IR Teams	Training Session	Bi-annually, or after an incident to review this playbook and the results of Red Team exercises.

Table A6. Communication hook for preparation phase.

Stakeholder	Method/Channel	Cadance/Trigger
Engineering and AI Dev Teams	Playbook Review Meeting	Quarterly, or following a significant change to the LLM application.
SOC and IR Teams	Training Session	Bi-annually, or after an incident to review this playbook and the results of Red Team exercises.

Preparatory Artefacts

Table A7. Preparatory artefacts for preparation phase.

Artefact	Logging Requirement
IR Team Charter	The formally approved document detailing IR team roles, responsibilities, and authority levels, stored in the GRC system.
Legal Compliance Framework	The documented mapping of legal and regulatory obligations, along with pre-approved notification templates for authorities.
Risk Assessment Report and Severity Matrix	The final risk assessment report and the approved Incident Severity Matrix, stored with the playbook and distributed to the IR team.
Threat Model Document	A formal report detailing the identified threats, attack vectors, and required controls for direct prompt injection.
Red Team Report	The report from the most recent adversarial testing exercise, including findings and remediation tickets.
Guardrail Configuration File	The version-controlled configuration file for the input/output filters and metaprompts.
Stakeholder Communication Plan	The approved plan detailing all internal and external communication requirements.

Table A7. Preparatory artefacts for preparation phase.

Artefact	Logging Requirement
IR Team Charter	The formally approved document detailing IR team roles, responsibilities, and authority levels, stored in the GRC system.
Legal Compliance Framework	The documented mapping of legal and regulatory obligations, along with pre-approved notification templates for authorities.
Risk Assessment Report and Severity Matrix	The final risk assessment report and the approved Incident Severity Matrix, stored with the playbook and distributed to the IR team.
Threat Model Document	A formal report detailing the identified threats, attack vectors, and required controls for direct prompt injection.
Red Team Report	The report from the most recent adversarial testing exercise, including findings and remediation tickets.
Guardrail Configuration File	The version-controlled configuration file for the input/output filters and metaprompts.
Stakeholder Communication Plan	The approved plan detailing all internal and external communication requirements.

Output

• A fully documented and approved playbook for Prompt Injection and Jailbreaks.
• Configured and tested preventative controls (guardrails, logging).
• SOC and IR teams are trained on the execution of this playbook.

Appendix A.1.2. Detection Phase

Objective: Identify a successful direct prompt injection or jailbreak attack, confirm its scope, and begin the formal response process.

Input Triggers

• A SIEM alert, user report via a service desk ticket, or anomalous output monitoring alert.
• Active and comprehensive logging of all user prompts and model outputs.

Actions Step Checklist

High Level Flow: Triage > Activate > Analyse > Assess > Report

Table A8. Actions step checklist for detection and analysis phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
D1	Acknowledge Alert: Acknowledge Alert to start the response SLA clock and triage its relevance to the LLM application.	Security Engineer/SecOps–SRE	MG-4.1-002
D2	Confirm Incident, Triage and Collect Evidence: Retrieve session logs and initial IoCs (e.g., malicious prompt, anomalous output) to confirm a policy violation.	Security Engineer/SecOps–SRE	GV-4.3-002
D3	Formally Declare Incident and Activate IR Team: Formally declare a security incident and activate the full IR team by engaging all required on-call roles.	IR Team Lead	GV-2.1-002
D4	Determine Blast Radius: Identify the incident’s full scope by enumerating affected accounts, systems, and data, and mapping the attacker’s activity.	Forensic Lead	MP-5.1-006
D5	Perform Forensic Analysis: Correlate IoCs to reconstruct the attack timeline, classify the jailbreak method, and determine the root cause.	Forensic Lead and ML Engineer	MP-5.1-006
D6	Validate Forensic Findings: Cross-verify initial findings via multi-source log correlation and hash matching to eliminate false positives before containment.	AI Engineering Lead	MG-4.3-001
D7	Assess Business Impact: Determine the full business impact, including data exposure, brand damage, and operational disruption.	IR Team Lead and Product Owner	MP-5.1-006, MG-2.2-005
D8	Assign Final Incident Severity: Using the impact assessment, assign a formal severity level to the incident per the approved Incident Severity Matrix.	IR Team Lead	MP-5.1-006, MG-2.2-005
D9	Assess Reporting Obligations: Based on impact and severity, assess all legal and regulatory reporting obligations (e.g., ICO, NCSC).	Legal and Compliance	MG-4.3-003
D10	Produce Initial Incident Report: Produce a report with an IoC catalogue, signed chain-of-custody records, and findings mapped to legal obligations.	IR Team Lead	MP-5.1-006, MG-2.2-005

Table A8. Actions step checklist for detection and analysis phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
D1	Acknowledge Alert: Acknowledge Alert to start the response SLA clock and triage its relevance to the LLM application.	Security Engineer/SecOps–SRE	MG-4.1-002
D2	Confirm Incident, Triage and Collect Evidence: Retrieve session logs and initial IoCs (e.g., malicious prompt, anomalous output) to confirm a policy violation.	Security Engineer/SecOps–SRE	GV-4.3-002
D3	Formally Declare Incident and Activate IR Team: Formally declare a security incident and activate the full IR team by engaging all required on-call roles.	IR Team Lead	GV-2.1-002
D4	Determine Blast Radius: Identify the incident’s full scope by enumerating affected accounts, systems, and data, and mapping the attacker’s activity.	Forensic Lead	MP-5.1-006
D5	Perform Forensic Analysis: Correlate IoCs to reconstruct the attack timeline, classify the jailbreak method, and determine the root cause.	Forensic Lead and ML Engineer	MP-5.1-006
D6	Validate Forensic Findings: Cross-verify initial findings via multi-source log correlation and hash matching to eliminate false positives before containment.	AI Engineering Lead	MG-4.3-001
D7	Assess Business Impact: Determine the full business impact, including data exposure, brand damage, and operational disruption.	IR Team Lead and Product Owner	MP-5.1-006, MG-2.2-005
D8	Assign Final Incident Severity: Using the impact assessment, assign a formal severity level to the incident per the approved Incident Severity Matrix.	IR Team Lead	MP-5.1-006, MG-2.2-005
D9	Assess Reporting Obligations: Based on impact and severity, assess all legal and regulatory reporting obligations (e.g., ICO, NCSC).	Legal and Compliance	MG-4.3-003
D10	Produce Initial Incident Report: Produce a report with an IoC catalogue, signed chain-of-custody records, and findings mapped to legal obligations.	IR Team Lead	MP-5.1-006, MG-2.2-005

Decision Gate

Table A9. Decision gate for detection and analysis phase.

Decision	Triggers/Criteria for Action	Owner
Acknowledge and Escalate Alert	Decide if an alert is credible enough to begin the formal incident response process.	Security Engineer/SecOps–SRE
Incident vs. Model Error	Declare a security incident if jailbreak IoCs are confirmed or if the output clearly violates content policy.	Security Engineer/SecOps–SRE
Severity Level Assignment	Using the approved Severity Matrix, assign a severity level based on the incident’s confirmed impact.	IR Team Lead
Activate Full IR Team	Based on the assigned severity, decide to formally activate and engage the full multi-disciplinary IR team.	IR Team Lead
Forensic Acquisition Scope	Determine and approve the specific logs, accounts, and timeframes required for a complete forensic analysis.	Forensic Lead
Validate Root Cause	The AI Engineering Lead must formally validate all forensic findings to ensure accuracy before containment begins.	AI Engineering Lead
Regulatory Reporting Requirement	Based on the impact assessment, decide if the incident requires formal notification to regulators (e.g., ICO, EU AI Act).	Legal and Compliance

Table A9. Decision gate for detection and analysis phase.

Decision	Triggers/Criteria for Action	Owner
Acknowledge and Escalate Alert	Decide if an alert is credible enough to begin the formal incident response process.	Security Engineer/SecOps–SRE
Incident vs. Model Error	Declare a security incident if jailbreak IoCs are confirmed or if the output clearly violates content policy.	Security Engineer/SecOps–SRE
Severity Level Assignment	Using the approved Severity Matrix, assign a severity level based on the incident’s confirmed impact.	IR Team Lead
Activate Full IR Team	Based on the assigned severity, decide to formally activate and engage the full multi-disciplinary IR team.	IR Team Lead
Forensic Acquisition Scope	Determine and approve the specific logs, accounts, and timeframes required for a complete forensic analysis.	Forensic Lead
Validate Root Cause	The AI Engineering Lead must formally validate all forensic findings to ensure accuracy before containment begins.	AI Engineering Lead
Regulatory Reporting Requirement	Based on the impact assessment, decide if the incident requires formal notification to regulators (e.g., ICO, EU AI Act).	Legal and Compliance

Communication Hook

Table A10. Communication hook for detection and analysis phase.

Flow/Handoff	Timing/Trigger	Method/Channel	Content Focus
SecOps → SOC Team	Immediately upon acknowledging a potential incident.	Internal Escalation Alert	Initial alert details, timestamp, and ticket number for tracking.
IR Team Lead → Core IR Team	Immediately after the incident is confirmed and formally declared.	PagerDuty Alert/Secure Email	Formal incident declaration, assigned severity level, and request to activate the core response team.
IR Lead → AI/ML Engineering	Within 15 min of confirming a technical exploit.	High-Priority JIRA Ticket and Direct Message	Details of the attack vector, prompt/output logs, and reproduction steps needed for patching.
IR Lead → Legal and Compliance	Immediately if a potential Personal Data (PII) breach is confirmed during impact assessment.	Secure Communication Channel	Full details of the output to begin the formal assessment of data breach and reporting obligations.
Incident Commander → Executive Team	Within 30 min of declaring a high-severity incident.	Direct Phone Call and Secure Email Summary	Strategic overview, potential business and reputational impact, analysis findings.

Table A10. Communication hook for detection and analysis phase.

Flow/Handoff	Timing/Trigger	Method/Channel	Content Focus
SecOps → SOC Team	Immediately upon acknowledging a potential incident.	Internal Escalation Alert	Initial alert details, timestamp, and ticket number for tracking.
IR Team Lead → Core IR Team	Immediately after the incident is confirmed and formally declared.	PagerDuty Alert/Secure Email	Formal incident declaration, assigned severity level, and request to activate the core response team.
IR Lead → AI/ML Engineering	Within 15 min of confirming a technical exploit.	High-Priority JIRA Ticket and Direct Message	Details of the attack vector, prompt/output logs, and reproduction steps needed for patching.
IR Lead → Legal and Compliance	Immediately if a potential Personal Data (PII) breach is confirmed during impact assessment.	Secure Communication Channel	Full details of the output to begin the formal assessment of data breach and reporting obligations.
Incident Commander → Executive Team	Within 30 min of declaring a high-severity incident.	Direct Phone Call and Secure Email Summary	Strategic overview, potential business and reputational impact, analysis findings.

Evidence to Collect

Table A11. Evidence to collect for detection and analysis phase.

Artefact	Logging Requirement
Initial Alert Record	The ticket number (e.g., from ServiceNow) or SIEM alert ID that triggered the investigation, with a precise timestamp.
Prompt and Output Logs	A full, unaltered export of the malicious user prompt(s) and the corresponding non-compliant output generated by the LLM. This is the primary evidence of the jailbreak.
Session and Correlation Logs	All relevant logs (e.g., API gateway, application, authentication) for the user’s session, used to confirm the incident and determine the initial scope.
Incident Declaration Record	A formal entry in the incident log with the precise “breach awareness” timestamp and the assigned severity level, which starts the clock for any regulatory reporting.
Blast Radius Report	A documented enumeration of all affected user accounts, systems, datasets, and a map of the attacker’s activity.
Forensic Analysis Report	The formal report detailing the attack timeline, classification of the jailbreak method, and the determined root cause of the guardrail failure.
Validation Record	A log entry or signed-off ticket from the AI Engineering Lead confirming the validation of the forensic findings.
Business Impact Assessment	The formal assessment, documented and approved by the IR Team Lead and Product Owner, detailing the incident’s impact on confidentiality, integrity, brand, and operations.
Regulatory Assessment Memo	The formal assessment from Legal and Compliance on all reporting obligations under frameworks like UK GDPR or the EU AI Act.
Chain of Custody Form	A signed and updated Chain of Custody Form for any sensitive evidence that has been collected and preserved.

Table A11. Evidence to collect for detection and analysis phase.

Artefact	Logging Requirement
Initial Alert Record	The ticket number (e.g., from ServiceNow) or SIEM alert ID that triggered the investigation, with a precise timestamp.
Prompt and Output Logs	A full, unaltered export of the malicious user prompt(s) and the corresponding non-compliant output generated by the LLM. This is the primary evidence of the jailbreak.
Session and Correlation Logs	All relevant logs (e.g., API gateway, application, authentication) for the user’s session, used to confirm the incident and determine the initial scope.
Incident Declaration Record	A formal entry in the incident log with the precise “breach awareness” timestamp and the assigned severity level, which starts the clock for any regulatory reporting.
Blast Radius Report	A documented enumeration of all affected user accounts, systems, datasets, and a map of the attacker’s activity.
Forensic Analysis Report	The formal report detailing the attack timeline, classification of the jailbreak method, and the determined root cause of the guardrail failure.
Validation Record	A log entry or signed-off ticket from the AI Engineering Lead confirming the validation of the forensic findings.
Business Impact Assessment	The formal assessment, documented and approved by the IR Team Lead and Product Owner, detailing the incident’s impact on confidentiality, integrity, brand, and operations.
Regulatory Assessment Memo	The formal assessment from Legal and Compliance on all reporting obligations under frameworks like UK GDPR or the EU AI Act.
Chain of Custody Form	A signed and updated Chain of Custody Form for any sensitive evidence that has been collected and preserved.

Output

• A formal Incident Declaration with an assigned severity level is logged.
• The core Incident Response Team is activated and engaged.
• A comprehensive initial incident report is completed and preserved.

Containment Phase

Objective: Immediately stop the attacker’s ability to exploit the vulnerability and prevent further damage.

Input Triggers

• A formal Incident Declaration from the Detect and Analysis phase.

Actions Step Checklist

High Level Flow: Convene > Preserve > Act > Scan > Escalate

Table A12. Actions step checklist for containment phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
C1	Activate Containment Team: Formally convene the core IR team on a secure communication bridge to coordinate all containment actions.	IR Team Lead	GV-2.1-002
C2	Execute Initial Containment: Based on the “Account vs. Session Termination” decision, immediately terminate the malicious user’s session and/or block the user account and source IP address.	Security Engineer/SecOps–SRE	MG-2.4-004
C3	Preserve Volatile Evidence: Capture an immutable forensic snapshot of all relevant interaction logs, session data, and model outputs before systems are altered.	Forensic Lead	GV-4.3-002
C4	Deploy Emergency Filter: Deploy the temporary “hotfix” filter to the application gateway or model input layer to block the specific exploit string from being used by other users.	ML Engineer/SRE	MG-2.4-003
C5	Scan for Widespread Exploitation: Actively scan all current user sessions and recent logs for any other instances of the same exploit being used to determine if the incident is widespread.	Security Engineer/SecOps–SRE	MP-5.1-006
C6	Disable Risky Integrations: Based on the analysis, temporarily disable any high-risk external connectors (databases, APIs) to prevent the exploit from propagating requests that could expose PII or secrets.	ML Engineer	MG-3.1-001
C7	Execute Strategic Containment: Based on the “Application Offline” decision, and if widespread exploitation is found, execute the procedure to temporarily take the entire LLM application offline.	Incident Commander	GV-1.7-001

Table A12. Actions step checklist for containment phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
C1	Activate Containment Team: Formally convene the core IR team on a secure communication bridge to coordinate all containment actions.	IR Team Lead	GV-2.1-002
C2	Execute Initial Containment: Based on the “Account vs. Session Termination” decision, immediately terminate the malicious user’s session and/or block the user account and source IP address.	Security Engineer/SecOps–SRE	MG-2.4-004
C3	Preserve Volatile Evidence: Capture an immutable forensic snapshot of all relevant interaction logs, session data, and model outputs before systems are altered.	Forensic Lead	GV-4.3-002
C4	Deploy Emergency Filter: Deploy the temporary “hotfix” filter to the application gateway or model input layer to block the specific exploit string from being used by other users.	ML Engineer/SRE	MG-2.4-003
C5	Scan for Widespread Exploitation: Actively scan all current user sessions and recent logs for any other instances of the same exploit being used to determine if the incident is widespread.	Security Engineer/SecOps–SRE	MP-5.1-006
C6	Disable Risky Integrations: Based on the analysis, temporarily disable any high-risk external connectors (databases, APIs) to prevent the exploit from propagating requests that could expose PII or secrets.	ML Engineer	MG-3.1-001
C7	Execute Strategic Containment: Based on the “Application Offline” decision, and if widespread exploitation is found, execute the procedure to temporarily take the entire LLM application offline.	Incident Commander	GV-1.7-001

Decision Gate

Table A13. Decision gate for containment phase.

Decision	Triggers/Criteria for Action	Owner
Account vs. Session Termination	Based on user identity and malicious intent, decide whether to block the full account or just terminate the session.	IR Team Lead
Scope of Integration Disablement	Based on the forensic analysis, determine which specific external connectors must be temporarily disabled.	IR Team Lead
Emergency Filter Deployment Approval	The IR Team Lead and Product Owner must approve the hotfix deployment after weighing its risk to legitimate traffic.	IR Team Lead and Product Owner
Application Offline	Based on the results of the widespread exploitation scan, decide if the entire LLM application must be taken offline.	Incident Commander

Table A13. Decision gate for containment phase.

Decision	Triggers/Criteria for Action	Owner
Account vs. Session Termination	Based on user identity and malicious intent, decide whether to block the full account or just terminate the session.	IR Team Lead
Scope of Integration Disablement	Based on the forensic analysis, determine which specific external connectors must be temporarily disabled.	IR Team Lead
Emergency Filter Deployment Approval	The IR Team Lead and Product Owner must approve the hotfix deployment after weighing its risk to legitimate traffic.	IR Team Lead and Product Owner
Application Offline	Based on the results of the widespread exploitation scan, decide if the entire LLM application must be taken offline.	Incident Commander

Communication Hook

Table A14. Communication hook for containment phase.

Stakeholder	Method/Channel	Timing/Trigger
IR Team Lead → IR Team	Secure Communication Bridge	Immediately upon entering the Containment phase.
IR Team Lead → Engineering Team	High-Priority JIRA Ticket	After the initial containment action is underway.
IR Team Lead → Legal and PR Teams	Secured Email	As soon as brand-damaging output is confirmed.

Table A14. Communication hook for containment phase.

Stakeholder	Method/Channel	Timing/Trigger
IR Team Lead → IR Team	Secure Communication Bridge	Immediately upon entering the Containment phase.
IR Team Lead → Engineering Team	High-Priority JIRA Ticket	After the initial containment action is underway.
IR Team Lead → Legal and PR Teams	Secured Email	As soon as brand-damaging output is confirmed.

Evidence to Collect

Table A15. Evidence to collect for containment phase.

Artefact	Logging Requirement
System Logs	An export of the system audit log showing the user session termination or account block.
Change Records	The change management ticket number for the emergency filter deployment.
Forensic Snapshot	An immutable snapshot of all interaction logs. The SHA-256 hash must be recorded in the Chain of Custody Form.
Widespread Exploitation Scan Report	A formal report detailing the methodology and results of the scan for other instances of the exploit.
Decision Log	A log entry in the master incident record detailing the outcomes of the decisions made, including the rationale.

Table A15. Evidence to collect for containment phase.

Artefact	Logging Requirement
System Logs	An export of the system audit log showing the user session termination or account block.
Change Records	The change management ticket number for the emergency filter deployment.
Forensic Snapshot	An immutable snapshot of all interaction logs. The SHA-256 hash must be recorded in the Chain of Custody Form.
Widespread Exploitation Scan Report	A formal report detailing the methodology and results of the scan for other instances of the exploit.
Decision Log	A log entry in the master incident record detailing the outcomes of the decisions made, including the rationale.

Output

• The exploit is contained and cannot be actively used by the attacker.
• The attacker’s access has been revoked.
• All required evidence for this phase has been preserved and logged.

Appendix A.1.3. Eradication Phase

Objective: Remove the root cause of the vulnerability and restore normal operations securely.

Input Triggers

• A fully contained system and a report from the Containment phase.
• Analysis from the Engineering team on the root cause of the vulnerability.

Actions Step Checklist

High Level Flow: Remediate > Validate > Deploy > Cleanse > Verify

Table A16. Actions step checklist for eradication phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
E1	Develop Permanent Filter Patch: Develop a robust, permanent patch for the model’s input validation, system prompt, or filtering logic that addresses the root cause.	ML Engineer	MG-2.4-003
E2	Execute Model Rollback (Alternative): If the “Model Rollback” decision is made, execute the procedure to roll back the LLM to a known good, previous version.	ML Engineer	MS-2.6-005
E3	Validate Remediation Patch: Submit the patch to the Red Team or a dedicated testing process to validate its effectiveness against the exploit.	AI Engineer Lead	MS-2.5-006
E4	Deploy Patch to Production: Deploy the validated patch to the production environment following formal change management procedures.	ML Engineer	MG-2.4-003
E5	Purge Malicious Content: Search logs and system outputs for all instances of content generated by the exploit and purge or remediate it based on the “Purge vs. Amend” decision.	Security Engineer/SecOps–SRE	MS-2.6-005
E6	Post-Deployment Verification Scan: After deployment, conduct a final verification scan of the production environment to ensure the fix is working as expected and no remnants of the exploit are active.	Security Engineer/SecOps–SRE	MS-2.6-005

Table A16. Actions step checklist for eradication phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
E1	Develop Permanent Filter Patch: Develop a robust, permanent patch for the model’s input validation, system prompt, or filtering logic that addresses the root cause.	ML Engineer	MG-2.4-003
E2	Execute Model Rollback (Alternative): If the “Model Rollback” decision is made, execute the procedure to roll back the LLM to a known good, previous version.	ML Engineer	MS-2.6-005
E3	Validate Remediation Patch: Submit the patch to the Red Team or a dedicated testing process to validate its effectiveness against the exploit.	AI Engineer Lead	MS-2.5-006
E4	Deploy Patch to Production: Deploy the validated patch to the production environment following formal change management procedures.	ML Engineer	MG-2.4-003
E5	Purge Malicious Content: Search logs and system outputs for all instances of content generated by the exploit and purge or remediate it based on the “Purge vs. Amend” decision.	Security Engineer/SecOps–SRE	MS-2.6-005
E6	Post-Deployment Verification Scan: After deployment, conduct a final verification scan of the production environment to ensure the fix is working as expected and no remnants of the exploit are active.	Security Engineer/SecOps–SRE	MS-2.6-005

Decision Gate

Table A17. Decision gate for eradication phase.

Decision	Triggers/Criteria for Action	Owner
Model Rollback vs. Patch Forward	If a permanent patch will take too long (>24 h), decide whether to roll back the model to a prior, secure version.	Incident Commander
Purge vs. Amend Content	Based on legal and PR guidance, decide whether to delete or amend any harmful content generated during the incident.	Legal and Communications/PR
Approval for Production Deployment	The Incident Commander must approve the production deployment, based on a successful Red Team validation report.	Incident Commander

Table A17. Decision gate for eradication phase.

Decision	Triggers/Criteria for Action	Owner
Model Rollback vs. Patch Forward	If a permanent patch will take too long (>24 h), decide whether to roll back the model to a prior, secure version.	Incident Commander
Purge vs. Amend Content	Based on legal and PR guidance, decide whether to delete or amend any harmful content generated during the incident.	Legal and Communications/PR
Approval for Production Deployment	The Incident Commander must approve the production deployment, based on a successful Red Team validation report.	Incident Commander

Communication Hook

Table A18. Communication hook for eradication phase.

Stakeholder	Method/Channel	Timing/Trigger
ML Engineer → Change Advisory Board	Change Management Ticket	Before deploying the permanent patch to production.
IR Team Lead → IR Team	Daily Status Update	Provide a daily summary of eradication progress to the incident response team.
IR Team Lead → Product Owner	Email Notification	Upon successful completion of the post-deployment verification scan.

Table A18. Communication hook for eradication phase.

Stakeholder	Method/Channel	Timing/Trigger
ML Engineer → Change Advisory Board	Change Management Ticket	Before deploying the permanent patch to production.
IR Team Lead → IR Team	Daily Status Update	Provide a daily summary of eradication progress to the incident response team.
IR Team Lead → Product Owner	Email Notification	Upon successful completion of the post-deployment verification scan.

Evidence to Collect

Table A19. Evidence to collect for eradication phase.

Artefact	Logging Requirement
Patch Development Records	The version control records for the code changes and the final test results from the Red Team validating the fix.
Model Rollback Verification Log	The deployment and validation logs confirming the successful rollback to a previous version.
Deployment Records	The change management ticket showing approval and a post-implementation review confirming successful deployment.
Content Purge Logs	An auditable log confirming that all identified non-compliant content has been successfully located and deleted or remediated.
Post-Deployment Scan Report	The formal report from the final verification scan confirming the system is clean.
Remediation Validation Report.	Sign-off from the AI Engineering Lead that serves as the crucial input for the “Approval for Production Deployment” decision.

Table A19. Evidence to collect for eradication phase.

Artefact	Logging Requirement
Patch Development Records	The version control records for the code changes and the final test results from the Red Team validating the fix.
Model Rollback Verification Log	The deployment and validation logs confirming the successful rollback to a previous version.
Deployment Records	The change management ticket showing approval and a post-implementation review confirming successful deployment.
Content Purge Logs	An auditable log confirming that all identified non-compliant content has been successfully located and deleted or remediated.
Post-Deployment Scan Report	The formal report from the final verification scan confirming the system is clean.
Remediation Validation Report.	Sign-off from the AI Engineering Lead that serves as the crucial input for the “Approval for Production Deployment” decision.

Output

• The vulnerability that allowed the prompt injection has been permanently fixed.
• All malicious or harmful artefacts created by the exploit have been removed from the system.
• The system is in a clean and in secure state, ready for recovery.

Appendix A.1.4. Recovery Phase

Objective: Securely restore all affected services to normal operation, validate system stability, and formally conclude the incident response process.

Input Triggers

• A clean and secure system, confirmed by the Eradication phase.
• A successful post-patch validation report from the Red Team.

Actions Step Checklist

High Level Flow: Restore > Monitor > Normalise > Close

Table A20. Actions step checklist for recovery phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
R1	Restore Service Functionality: Based on the “Phased vs. Full Rollout” decision, re-enable the full functionality of the LLM application that was restricted during containment.	ML Engineer	MS-2.6-005 MS-2.5-006
R2	Re-enable User Accounts: Based on the “Account Re-instatement” decision, re-enable any user accounts that were blocked, ensuring they are placed in a heightened monitoring state.	Security Engineer/SecOps–SRE	MS-2.6-005
R3	Confirm System Stability: Monitor system health and performance metrics for a pre-defined period (e.g., 24 h) to confirm that the system is stable and the remediation was successful.	Security Engineer/SecOps–SRE	MS-2.6-005, MG-4.1-002
R4	Execute Final Communications: Based on the communication plan, notify business owners and all employees that the incident is resolved and normal service has been restored.	Communications/PR	GV-4.3-003
R5	Formally Close Incident: Once the system is confirmed stable and stakeholders are notified, the Incident Commander will formally close the active incident response ticket and process.	Incident Commander	GV-1.5-002

Table A20. Actions step checklist for recovery phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
R1	Restore Service Functionality: Based on the “Phased vs. Full Rollout” decision, re-enable the full functionality of the LLM application that was restricted during containment.	ML Engineer	MS-2.6-005 MS-2.5-006
R2	Re-enable User Accounts: Based on the “Account Re-instatement” decision, re-enable any user accounts that were blocked, ensuring they are placed in a heightened monitoring state.	Security Engineer/SecOps–SRE	MS-2.6-005
R3	Confirm System Stability: Monitor system health and performance metrics for a pre-defined period (e.g., 24 h) to confirm that the system is stable and the remediation was successful.	Security Engineer/SecOps–SRE	MS-2.6-005, MG-4.1-002
R4	Execute Final Communications: Based on the communication plan, notify business owners and all employees that the incident is resolved and normal service has been restored.	Communications/PR	GV-4.3-003
R5	Formally Close Incident: Once the system is confirmed stable and stakeholders are notified, the Incident Commander will formally close the active incident response ticket and process.	Incident Commander	GV-1.5-002

Decision Gate

Table A21. Decision gate for recovery phase.

Decision	Triggers/Criteria for Action	Owner
Phased vs. Full Rollout	Decide on a full or phased service restoration to monitor for any post-recovery issues.	Incident Commander
User Account Re-instatement	Based on evidence of malicious intent, decide whether to re-instate, further investigate, or permanently suspend any blocked accounts.	IR Team Lead
Close Incident	The Incident Commander formally closes the incident once all recovery actions are complete and system stability is confirmed over a predefined period.	Incident Commander

Table A21. Decision gate for recovery phase.

Decision	Triggers/Criteria for Action	Owner
Phased vs. Full Rollout	Decide on a full or phased service restoration to monitor for any post-recovery issues.	Incident Commander
User Account Re-instatement	Based on evidence of malicious intent, decide whether to re-instate, further investigate, or permanently suspend any blocked accounts.	IR Team Lead
Close Incident	The Incident Commander formally closes the incident once all recovery actions are complete and system stability is confirmed over a predefined period.	Incident Commander

Communication Hook

Table A22. Communication hook for recovery phase.

Stakeholder	Method/Channel	Timing/Trigger
Comms/PR → Business Owners	Email Notification	Notify the application’s business owners that the service has been fully restored.
Comms/PR → All Employees	Intranet Post/Email	If the application was taken offline or service was degraded, provide a final update confirming restoration.
IR Team Lead → Product Owner	Service Acceptance Form/Ticket	After system stability is confirmed.
Incident Commander → IR Team and Leadership	Secure Chat/Email	A final “incident closed” notification to formally stand down the response team.

Table A22. Communication hook for recovery phase.

Stakeholder	Method/Channel	Timing/Trigger
Comms/PR → Business Owners	Email Notification	Notify the application’s business owners that the service has been fully restored.
Comms/PR → All Employees	Intranet Post/Email	If the application was taken offline or service was degraded, provide a final update confirming restoration.
IR Team Lead → Product Owner	Service Acceptance Form/Ticket	After system stability is confirmed.
Incident Commander → IR Team and Leadership	Secure Chat/Email	A final “incident closed” notification to formally stand down the response team.

Evidence to Collect

Table A23. Evidence to collect for recovery phase.

Artefact	Logging Requirement
System Health Metrics	Dashboard reports showing normal application performance and error rates for 24 h post-recovery.
Re-enabled Account Logs	An audit log confirming which user accounts were re-enabled and when.
Rollout Strategy Memo	A log entry detailing the rationale for the chosen rollout strategy (phased or full).
Incident Closure Report	The final incident report summarising the event from detection to recovery, formally signed off by the Incident Commander.

Table A23. Evidence to collect for recovery phase.

Artefact	Logging Requirement
System Health Metrics	Dashboard reports showing normal application performance and error rates for 24 h post-recovery.
Re-enabled Account Logs	An audit log confirming which user accounts were re-enabled and when.
Rollout Strategy Memo	A log entry detailing the rationale for the chosen rollout strategy (phased or full).
Incident Closure Report	The final incident report summarising the event from detection to recovery, formally signed off by the Incident Commander.

Output

• The LLM application is fully operational and restored to its normal, secure state.
• All users have regained appropriate access.
• The formal incident response process is concluded.

Appendix A.1.5. Post Incident Review Phase

Objective: Analyse the incident to derive lessons learned and implement strategic improvements.

Input Triggers

• The formal incident closure report from the Recovery phase.
• All evidence collected during the incident (e.g., logs, snapshots, tickets).

Actions Step Checklist

High Level Flow: Debrief > Analyse > Recommend > Assign > Improve

Table A24. Actions step checklist for post-incident phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
PI1	Convene Post-Incident Debrief: Schedule and conduct a formal post-incident debrief workshop with all members of the IR team and relevant stakeholders.	Incident Commander	GV-1.5-002
PI2	Perform Root Cause Analysis: Conduct a detailed root-cause analysis based on the forensic evidence to understand the technical, process, and people-based failures.	IR Team Lead	MG-4.3-001, MG-4.2-002
PI3	Identify and Document Lessons Learned: Consolidate the findings from the debrief and RCA to formally document what worked well and what did not work well across the response.	IR Team Lead	GV-1.5-002
PI4	Create and Prioritise Improvement Roadmap: Develop a list of SMART recommendations and assign a priority to each decision.	IR Team Lead	MG-4.2-002
PI5	Assign and Track Remediation Tasks: Assign all roadmap items to the appropriate owners in a tracking system and monitor them to completion.	Security Governance/GRC	MS-2.7-006
PI6	Update Playbook and Conduct Training: Update this playbook and other relevant documentation with the lessons learned and conduct training on the new procedures.	IR Team Lead	MG-4.2-002

Table A24. Actions step checklist for post-incident phase.

ID	Action Description	Owner	NIST AI 600-1 Mapping
PI1	Convene Post-Incident Debrief: Schedule and conduct a formal post-incident debrief workshop with all members of the IR team and relevant stakeholders.	Incident Commander	GV-1.5-002
PI2	Perform Root Cause Analysis: Conduct a detailed root-cause analysis based on the forensic evidence to understand the technical, process, and people-based failures.	IR Team Lead	MG-4.3-001, MG-4.2-002
PI3	Identify and Document Lessons Learned: Consolidate the findings from the debrief and RCA to formally document what worked well and what did not work well across the response.	IR Team Lead	GV-1.5-002
PI4	Create and Prioritise Improvement Roadmap: Develop a list of SMART recommendations and assign a priority to each decision.	IR Team Lead	MG-4.2-002
PI5	Assign and Track Remediation Tasks: Assign all roadmap items to the appropriate owners in a tracking system and monitor them to completion.	Security Governance/GRC	MS-2.7-006
PI6	Update Playbook and Conduct Training: Update this playbook and other relevant documentation with the lessons learned and conduct training on the new procedures.	IR Team Lead	MG-4.2-002

Decision Gate

Table A25. Decision gate for post-incident phase.

Decision	Triggers/Criteria for Action	Owner
Public Vulnerability Disclosure	Based on legal advice, contractual obligations, and community benefit, decide whether to publicly disclose the vulnerability details.	Incident Commander

Table A25. Decision gate for post-incident phase.

Decision	Triggers/Criteria for Action	Owner
Public Vulnerability Disclosure	Based on legal advice, contractual obligations, and community benefit, decide whether to publicly disclose the vulnerability details.	Incident Commander

Communication Hook

Table A26. Communication hook for post-incident phase.

Flow/Handoff	Method/Channel	Timing/Trigger
Incident Commander → Cyber-Risk Committee	Formal Incident Report and Presentation	Within 14 days of incident closure.
GRC → Engineering and AI Dev Teams	JIRA Action Items	Assign improvement tasks from the roadmap to the relevant teams within 7 days of the debrief.

Table A26. Communication hook for post-incident phase.

Flow/Handoff	Method/Channel	Timing/Trigger
Incident Commander → Cyber-Risk Committee	Formal Incident Report and Presentation	Within 14 days of incident closure.
GRC → Engineering and AI Dev Teams	JIRA Action Items	Assign improvement tasks from the roadmap to the relevant teams within 7 days of the debrief.

Evidence to Collect

Table A27. Evidence to collect for post-incident phase.

Artefact	Logging Requirement
Post-Incident Review Minutes	A formal document of the debrief meeting, including attendees, discussion points, and key findings.
Root-Cause Analysis Report	The documented output of the RCA, clearly identifying the primary and contributing causes of the incident.
Improvement Action Tracker	The ticket numbers for all strategic recommendations logged in a central tracking system (e.g., JIRA, ServiceNow).
Updated Playbook Version	The new version of the playbook, with a change log detailing the updates made post-incident.

Table A27. Evidence to collect for post-incident phase.

Artefact	Logging Requirement
Post-Incident Review Minutes	A formal document of the debrief meeting, including attendees, discussion points, and key findings.
Root-Cause Analysis Report	The documented output of the RCA, clearly identifying the primary and contributing causes of the incident.
Improvement Action Tracker	The ticket numbers for all strategic recommendations logged in a central tracking system (e.g., JIRA, ServiceNow).
Updated Playbook Version	The new version of the playbook, with a change log detailing the updates made post-incident.

Output

• A post-incident report with root cause, lessons learned, and an improvement roadmap.
• All follow-up actions are assigned to owners and logged in a tracking system.
• An improved and updated version of the playbook.

Appendix A.2. RACI Matrix

R = Responsible (the person/role who does the work).

A = Accountable (the person/role who owns the work).

C = Consulted (the person/role who provides input).

I = Informed (the person/role who is kept up to date).

Figure A1. RACI matrix for preparation phase of Archetype A1.

Figure A1. RACI matrix for preparation phase of Archetype A1.

Figure A2. RACI matrix for detection and analysis phase of Archetype A1.

Figure A2. RACI matrix for detection and analysis phase of Archetype A1.

Figure A3. RACI matrix for containment phase of Archetype A1.

Figure A3. RACI matrix for containment phase of Archetype A1.

Figure A4. RACI matrix for eradication phase of Archetype A1.

Figure A4. RACI matrix for eradication phase of Archetype A1.

Figure A5. RACI matrix for recovery phase of Archetype A1.

Figure A5. RACI matrix for recovery phase of Archetype A1.

Figure A6. RACI matrix for post-incident phase of Archetype A1.

Figure A6. RACI matrix for post-incident phase of Archetype A1.

Appendix A.3. Swimlane Diagram

Figure A7. Swimlane diagram for preparation phase of Archetype A1.

Figure A7. Swimlane diagram for preparation phase of Archetype A1.

Figure A8. Swimlane diagram for detection and analysis phase of Archetype A1.

Figure A8. Swimlane diagram for detection and analysis phase of Archetype A1.

Figure A9. Swimlane diagram for containment phase of Archetype A1.

Figure A9. Swimlane diagram for containment phase of Archetype A1.

Figure A10. Swimlane diagram for eradication phase of Archetype A1.

Figure A10. Swimlane diagram for eradication phase of Archetype A1.

Figure A11. Swimlane diagram for recovery phase of Archetype A1.

Figure A11. Swimlane diagram for recovery phase of Archetype A1.

Figure A12. Swimlane diagram for post-incident phase of Archetype A1.

Figure A12. Swimlane diagram for post-incident phase of Archetype A1.

The Detailed Playbooks for all six Archetypes can be found in the Github Repository: GitHub-tuscanoderr/A-Practical-Incident-Response-Framework-for-Generative-AI-Systems (accessed on 30 September 2025).