# Texas AI Incident Reporting Supplement

Reviewed: August 24, 2026

This checklist supports technical documentation. It is not legal advice and
does not decide whether an event is reportable. The presence of AI, an agent,
an MCP server, or a model does not by itself make an event reportable.

## Current Texas public-sector timing boundary

Texas DIR states that covered state agencies and local governments must report
a qualifying security incident within 48 hours after discovery. If election
data is involved, the secretary of state is the stated notification recipient.
DIR also states that incident details and an analysis of cause are due within
10 days after incident eradication, closure, and recovery.

The DIR page describes the covered-entity and incident tests, an exception for
certain local-government utility incidents, related breach-notification duties,
and the current reporting channel. Confirm the current facts, law, recipient,
and channel with the entity's authorized incident lead and counsel.

Primary sources:

- Texas DIR, SB 271 Security Incident Reporting:
  https://dir.texas.gov/information-security/cybersecurity-incident-management-and-reporting/sb-271-security-incident
- Texas Government Code § 2054.603:
  https://statutes.capitol.texas.gov/Docs/GV/htm/GV.2054.htm#2054.603

## 1. Establish the event and authority

- [ ] Name the affected state agency, local government, school, or other entity.
- [ ] Record occurrence, discovery, collection, decision, and submission times
      separately.
- [ ] Identify the affected system, application, agent, model, MCP server,
      tool, data class, and environment using metadata only.
- [ ] Record who is authorized to classify the incident and decide whether,
      where, and when it must be reported.
- [ ] Ask authorized counsel and the incident lead which cybersecurity,
      privacy, election-data, education, utility, contract, insurance, or other
      requirements apply.

## 2. Preserve evidence without changing its meaning

- [ ] Preserve source event IDs, product and version, collector, occurrence
      time, collection time, time zone, and source visibility ceiling.
- [ ] Keep source observations, vendor verdicts, detector conclusions,
      investigator conclusions, approvals, contradictions, and unknowns
      distinct.
- [ ] Retain the evidence manifest, SHA-256 digests, custody links, signatures,
      and timestamp receipts with separately supplied trust fingerprints.
- [ ] Keep prompts, responses, tool arguments and results, credentials,
      regulated records, and forensic images in the approved incident system,
      not Briard-AI.

## 3. Execute the authorized reporting workflow

- [ ] If the authorized decision is that the incident is reportable, record the
      deadline, recipient, channel, and person responsible for submission.
- [ ] Confirm whether DIR, the secretary of state, affected individuals, the
      Texas Attorney General, law enforcement, a customer, an insurer, or
      another recipient must be notified.
- [ ] Use the current authorized channel. Do not rely on an old saved link or
      this checklist as proof that the reporting method has not changed.
- [ ] Preserve the confirmation, external incident ID, submitter, submitted
      time, and exactly what evidence or facts were included or referenced.

## 4. Track response and closure as separate records

- [ ] Track containment, eradication, recovery, notifications, law-enforcement
      coordination, policy changes, and cause analysis separately.
- [ ] Reconcile the final technical timeline with the preserved evidence.
- [ ] Record unresolved gaps and conflicting source assertions.
- [ ] Obtain named reviewer approval or a terminal rejection with rationale.
- [ ] Verify the final fictional or customer-authorized package independently
      at https://briard.ai/verify before relying on its technical consistency.

Verification establishes package consistency only. It does not establish source
truth, causation, legal sufficiency, admissibility, certification, or approval.