AI Incident Management Procedure

Document control

Document ID: B-002

Author(s): GRC & Compliance Team

Version: 1.0

Date: 09-Nov-2026

Disclaimer:

This controlled document is intended for authorized SecureXcel use. It may not be reproduced, distributed, quoted, or disclosed outside its approved audience without prior authorization from the document owner.

Document Details

Revision History

1. INTRODUCTION

1.1 Purpose (Clause 7.4, A.8.1 Objective)

The core purpose of this procedure is to establish the processes for determining and delivering timely, accurate, and relevant information about AI systems to all necessary internal and external interested parties. This ensures that interested parties have the necessary information to understand and assess the risks and their impacts (A.8.1 Objective), and facilitates the organization's legal and ethical obligations for transparency and accountability.

1.2 Scope (Clause 7.4)

This procedure applies to all internal and external communication activities relevant to the AI Management System (AIMS) and any AI system throughout its life cycle, specifically covering:

1. 1. Provision of system documentation and information to users (A.8.2).
2. 2. Handling of external reports of adverse impacts (A.8.3).
3. 3. Communication of incidents (A.8.4).
4. 4. Mandatory reporting obligations to authorities and regulators (A.8.5).

1.3 Objectives

The primary objectives are to ensure:

1. 1. Mandatory Compliance (7.4): All communication requirements (what, when, with whom, how) are determined and documented.
2. 2. Understandability (A.8.2): Information provided is appropriate to the recipient's technical expertise and includes system limitations and intended use, ensuring users are aware they are interacting with an AI system.
3. 3. Feedback Loop (A.8.3): A reliable capability exists for external parties to report adverse impacts, which feeds into the Concern Reporting Process.
4. 4. Regulatory Adherence (A.8.5, A.8.4): Timely and accurate reporting of system information and incidents is provided to regulatory authorities and interested parties as required by legal or contractual obligations.

2. ROLES, RESPONSIBILITIES, AND AUTHORITIES

3. PROCEDURE FOR AI SYSTEM COMMUNICATION LIFE CYCLE

This procedure is executed in four mandatory phases covering proactive, reactive, and mandatory communication activities.

3.1 PHASE 1: PROACTIVE COMMUNICATION (A.8.2)

This phase ensures all necessary information is made available to users and interested parties before the system is deployed or used, focusing on understandability and validation.

3.1.1 Determine Necessary Information and Risk Tiers (A.8.2)

The AI System Owner and Head of Communications jointly determine the necessary information using the Information Determination Criteria (Appendix A). This determination is further formalized by classifying the communication content into Communication Risk Tiers (Section 4.1.3).

3.1.2 Content Creation and Review Protocol

1. 1. Content Requirement: The content must cover all required aspects (Purpose, Limitations, Human Oversight, Impact Information, as detailed in B.8.2).
2. 2. Source Material: Content must be directly derived from the AI System Technical Documentation (A.6.2.7) and the approved AI System Impact Assessment .
3. 3. Content Approval: All content must be approved according to the Communication Risk Tiers (Section 4.1.3) before dissemination. Legal sign-off is mandatory for all content relating to limitations, accuracy claims, or legal compliance.

3.1.3 Communication Risk Tiers (Content Governance)

To ensure the appropriate level of scrutiny is applied to communication content, all AI-related documentation is categorized:

3.1.4 Develop, Validate, and Publish Documentation (A.8.2)

1. 1. Format and Accessibility: The Head of Communications ensures the information is accessible (e.g., meeting WCAG standards) and provided in the appropriate form for the target audience (B.8.2).
2. 2. User Validation: For all Tier 2 and Tier 3 content, the AI System Owner must coordinate a mandatory User Feedback and Validation process (using Appendix D) to ensure the language achieves the required understandability before final publication.
3. 3. Control: The final published documentation must be version controlled and stored in the central document repository (7.5.3).

3.2 PHASE 2: RECEIVING EXTERNAL REPORTS (A.8.3)

This phase establishes the mechanism for interested parties to provide adverse feedback and ensures seamless transfer to the internal accountability system.

3.2.1 Establish Adverse Impact Reporting Capability (A.8.3)

The Head of Communications, in conjunction with the Ethics & Concerns Officer, establishes publicly available capabilities (e.g., online form, dedicated email) for interested parties to report adverse impacts (e.g., unfairness, unexpected behavior) of the AI system (A.8.3).

Dedicated Email: security@securexcel.com, security@securexcel.com

3.2.2 Intake, Triage, and Internal Transfer (A.8.3)

1. 1. Intake and Logging: The Ethics & Concerns Officer is the designated point of receipt and immediately logs the report into a preliminary External Reports Log.
2. 2. Triage and Severity: The officer classifies the report based on severity (Minor, Significant, Critical) and confirms if the report concerns an AI system within the AIMS scope.
3. 3. Transfer: All valid external reports are immediately transferred to the internal Concern Investigation Log (AIMS-B-004, Appendix C) for formal investigation (A.8.3). The external report acts as the official trigger for the internal investigation process.
4. 4. Acknowledge and Track: The reporting party must receive an automated acknowledgement and, if feasible and legally permissible, be provided with a reference number to track the internal investigation status, maintaining confidentiality as required (B.3.3 g).

3.3 PHASE 3: REACTIVE INCIDENT COMMUNICATION (A.8.4)

This phase dictates the rapid, controlled process for communicating incidents to users and external parties.

3.3.1 Develop and Maintain Incident Communication Plan (A.8.4)

The Head of Communications, in collaboration with the Head of Legal & Compliance, maintains the documented Incident Communication Plan (Appendix B). The plan must:

1. 1. Define Thresholds: Specify the types of incidents (e.g., Critical Safety Failure, Systemic Bias Incident) that trigger external communication (A.8.4).
2. 2. Pre-Approve Templates: Include pre-approved communication templates for high-risk, time-sensitive events (e.g., system rollback notification).
3. 3. Define Timelines and Escalation: Specify internal and external notification timelines, strictly adhering to regulatory reporting deadlines (B.8.4).

3.3.2 Execute Incident Communication (A.8.4)

Upon confirmation of an AI-related incident (following the resolution of a Nonconformity, 10.2):

1. 1. Activation: The Head of Communications activates the Incident Communication Plan based on the severity and nature of the nonconformity.
2. 2. Content Approval: All communication content (Tier 3 or Tier 4, Section 4.1.3) must undergo mandatory, rapid review and approval by the Head of Legal & Compliance and the AI System Owner.
3. 3. Notification: Communicate the incident according to the plan, ensuring the message clearly outlines (B.8.4):
   • The nature of the incident (e.g., "The system experienced concept drift").
   • The impact (e.g., "5% of legitimate security or compliance records were incorrectly classified by the AI-assisted workflow").
   • The immediate and planned corrective actions taken (e.g., "System has been rolled back to V2 and subject to human oversight").

3.4 PHASE 4: MANDATORY OBLIGATION REPORTING (A.8.5)

This phase ensures all required information is reported to regulators and authorities, addressing the organization's highest-level accountability commitment.

3.4.1 Determine and Register Obligations (A.8.5)

The Head of Legal & Compliance shall maintain the Regulatory Reporting Obligations Register (Appendix C). This register must document:

• Obligation Source: The specific law, regulation, or contract.
• Required Content: The specific data or documentation required (e.g., training data provenance, Impact Assessment results, log data, A.6.2.8).
• Reporting Cadence: Frequency (annual, ad-hoc) and deadlines (B.8.5).

3.4.2 Content Assembly and Technical Vetting (A.8.5)

For all non-incident mandatory reports, the following internal coordination is required:

1. 1. Request: Legal issues a formal request to the AI System Owner, specifying the required technical documentation (e.g., A.6.2.7).
2. 2. Assembly: The AI System Owner compiles the data (e.g., risk profiles, verification records).
3. 3. Vetting: The AI System Owner must provide documented sign-off confirming the accuracy and completeness of all technical information submitted to Legal.

3.4.3 Execute Reporting (A.8.5)

The DPO is accountable for ensuring that the approved information is submitted to the correct authorities within the required timeframe (B.8.5).

• Retention: Documentation related to the submission (including internal sign-offs) must be retained in the central document repository (7.5.3).

4. PROCESS MAP: COMMUNICATION AND REPORTING FLOW

5. APPENDIX A: INFORMATION DETERMINATION CRITERIA (A.8.2)

The organization uses these criteria (B.8.2) to determine whether and what information must be provided to users and interested parties.

6. APPENDIX B: INCIDENT COMMUNICATION PLAN (A.8.4)

The Head of Communications maintains a detailed plan for executing timely communications during an AI incident.

7. APPENDIX C: REGULATORY REPORTING OBLIGATIONS REGISTER (A.8.5)

The Head of Legal & Compliance maintains this register to track mandatory reporting obligations.

More in AI incidents

• Artificial Intelligence (AI) Incident Recording and Reporting Policy