← All documentation

Incidents

The incident register records what went wrong: harmful or inaccurate AI output that reached someone, a biased outcome, an attack such as a jailbreak or prompt injection, data exposed, a lost or stolen device, records disposed of improperly, a system that drifted, or AI used without approval. Recording each incident, and the system it involved, is how a problem becomes a fix and how the system's approvers learn what has happened.

Every incident asks two questions, and its page opens what each answer calls for:

  • Was protected health information involved? Yes, No or Not yet known (pre-set to Not yet known when you log it from a system that handles ePHI). Yes opens the **breach risk assessment** on the incident's page (below).
  • Was a system that uses AI involved? Yes or No. For Yes, **Could this be a serious incident under the EU AI Act?** Yes, No or Not yet known; Yes is what starts the Article 73 reporting deadline (below).

Both can apply to one incident. Not yet known keeps the incident open: it cannot be resolved or reported until it is answered.

The register is for organization administrators: it can describe harm to people and name personal data, so contributors and auditors do not see it. A system's approvers see a summary of its incidents on its Approval page (title, type, severity, status, whether it is serious, and when it was found), without the timeline, notes or what was sent to an authority.

An administrator can tick several incidents on the register to assign their investigator in one step, or to export just those incidents. Closing is not offered in bulk: each incident is closed on its own page, once its own answers, breach risk assessment and notifications allow it.

Reporting an incident (any member)

Anyone in your organization who can edit records can report an incident. Contributors find Report an incident in the sidebar; anyone can open it from the command palette, and administrators can also log one from the register. The report asks what happened, when it was found, and the two questions above, and opens the incident as Open for an administrator to triage. The incident goes on the register and an email goes to your organization's administrators when it is sent. The reporter is not shown the register afterwards; an administrator sets the severity, links the system involved, and records the breach risk assessment where protected health information was involved. Describe the event, not the people: leave out the names of anyone involved.

An incident record

  • Type: harmful output, inaccurate output, biased outcome, performance degradation or drift, misuse or attack, data exposure, safety harm, impact on people's rights, AI used without approval, outage, unauthorized access or disclosure, theft or loss, improper disposal, hacking or IT incident, or other.
  • Severity: low, medium, high or critical.
  • AI system and model involved, if any. An incident about a tool that was never approved may have no system in the registry yet; record it anyway.
  • Discovery date: when your organization became aware of it.
  • Personal data involved, and people affected. Leave people affected blank while you do not yet know: blank means not yet known, which is different from none, and the register shows it that way.
  • Status: open, under review, resolved, or reported to an authority. The register's Open or in review filter (and its pill) counts the first two together: an incident under review is still open. A new incident starts open or under review, and is triaged (under review) before it can be resolved or reported. Marking it reported needs the time the authority was notified.
  • Timeline and investigation notes: how it was detected and contained, the root cause, and the corrective action.

Protected health information: the breach risk assessment

An acquisition, access, use or disclosure of protected health information that the Privacy Rule does not permit is presumed to be a breach unless one of the three exclusions in § 164.402(1) applies or a risk assessment of at least four factors demonstrates a low probability that the information has been compromised (45 CFR § 164.402). The notification duties apply only to a breach of unsecured protected health information, so information secured as the HHS guidance specifies needs no notice. On an incident whose answer is Yes, an administrator records the assessment:

  1. Whether there was an acquisition, access, use or disclosure the Privacy Rule does not permit at all. No means there is nothing to presume a breach from.
  2. Whether one of the exclusions in § 164.402(1) applies.
  3. Whether the information was secured (rendered unusable, unreadable or indecipherable to unauthorized persons as the HHS guidance specifies: encryption that meets it, with the key not also compromised, or destruction that meets it). Redaction, a password or access controls alone do not secure it. When devices are linked under Devices involved, the question states what each device record says about encryption. It never ticks the box. The information on a device recorded as encrypted was secured only if the encryption meets the HHS guidance, the information was encrypted when the device was lost (a device left on and unlocked, or a copy kept outside the encrypted storage, is not), and the key or password was not also compromised. Backsplice checks none of these. If you tick it while a linked device is recorded as not encrypted, or with encryption not known, you are asked to confirm and to say in the reasoning how the information was secured (the device record may be out of date). If the information was not secured, untick the box and assess the four factors. The page suggests recording the four factors too, so the assessment stands if the information proves not to have been secured. Each recorded determination keeps the devices as they stood at the decision, and whether you confirmed.
  4. Otherwise, the four factors of § 164.402(2), in the regulation's words, and whether together they demonstrate a low probability that the information has been compromised. A breach is presumed until they do, and your organization carries the burden of demonstrating it (§ 164.414(b)).
  5. The reasoning, in your own words. Describe the information by type and volume; never paste details that identify a person.

The determination follows from the answers, never picked from a list: Not a breach of unsecured PHI (with the reason) or Breach of unsecured PHI. It is your organization's determination, not legal advice. Recording it again keeps the earlier determination in the incident's history.

The deadlines run from discovery: the first day the breach is known to your organization, or would have been known by exercising reasonable diligence, including to any workforce member or agent other than the person who committed it (§§ 164.404(a)(2), 164.410(a)(2)). Set the incident's discovery date to that day. Until a determination says Not a breach of unsecured PHI, the page shows the notification deadlines, each an outer limit (notice is due without unreasonable delay, which can be sooner): individuals no later than 60 calendar days after discovery (§ 164.404(b)); HHS with them for 500 or more people, otherwise no later than 60 days after the end of the calendar year in which it was discovered (§ 164.408); prominent media only where more than 500 residents of a State or jurisdiction are affected (§ 164.406); and, for a business associate, the covered entity no later than 60 calendar days after discovery (§ 164.410). Which apply follows your organization's answer to the protected health information question in Settings. A law enforcement delay under § 164.412 is not included, and state law may set shorter deadlines and other notices. An incident that involved protected health information cannot be resolved or reported until its determination is recorded, and cannot be deleted once one is. Whether the rules apply to your organization is a legal judgment: this is not legal advice.

Viewing an incident that may hold protected health information (one where it was involved, is not yet known, or was never asked) is written to your organization's audit log as a phi.viewed event: who opened it, from the dashboard, the API or a connected assistant, and which breach records were shown with it. A page of the register, Breach notifications or a search records one event naming how many such incidents it listed. The event names the incident by its identifier, never by its title or narrative. A download of such incidents is recorded as an export. An API key or a connected assistant reading such an incident gets it without its title, description, notes or tags: only the dashboard shows them.

Drafting the reasoning with Watney

An admin can choose Draft the reasoning with Watney under an empty Reasoning. Watney reads the choices and the four factors as the form stands and drafts why the determination those choices give follows from them, factor by factor. It never chooses the determination or argues for another one: until you answer whether the factors demonstrate a low probability, the draft ends with a [To confirm] that asks you to. A factor you have not written is a [To complete]. The draft fills only an empty Reasoning, and nothing is recorded until you record the determination. The choices and the factors are sent to the AI model provider; the incident's title and narrative are not.

Breach notifications

Under the deadlines, Notifications lists each notice the incident still owes and each one given. Record a notice when it is given: who was notified, the date, how, and any receipt, such as the transaction number the HHS breach portal gives you. For individuals, the media and, as a business associate, the covered entity, Letter (PDF) downloads a draft letter with the content the rule requires; every fact only you can supply is marked "[To complete: …]", and the draft never copies the incident's own description, which is written for your organization rather than for the people affected.

Prominent media are owed notice for each State or jurisdiction where more than 500 residents are affected: once more than 500 people are affected, record each such State, or record that none passed 500. A state attorney general's notice depends on state law: add one for each State whose law requires it, with its deadline. Telephone notice in an urgent situation is in addition to written notice, never instead of it (§ 164.404(d)(3)); telephone stands in for written notice only as a substitute notice for fewer than ten people written notice could not reach (§ 164.404(d)(2)(i)).

On the individuals notice, record how many were notified, how many deceased individuals were notified through their next of kin or personal representative, and how many written notice could not reach. For an individual you know is deceased, written notice goes by first-class mail to the next of kin or personal representative where you have their address (§ 164.404(d)(1)(ii)); Next-of-kin letter (PDF) drafts it. Anyone written notice could not reach because their contact information was insufficient or out of date is owed a Substitute notice (§ 164.404(d)(2)), listed as its own notice and recorded when given. For fewer than ten, it may be another form of written notice, telephone or other means. For ten or more, it is "either a conspicuous posting for a period of 90 days on the home page of the Web site of the covered entity involved, or conspicuous notice in major print or broadcast media in geographic areas where the individuals affected by the breach likely reside", with "a toll-free phone number that remains active for at least 90 days" (§ 164.404(d)(2)(ii)). For ten or more, the page shows the date until which the number stays active (and a home-page posting stays up), and your admins are reminded the week before; a substitute notice given for fewer is asked again once the count reaches ten. A substitute notice in the media is separate from the § 164.406 notice to prominent media, owed where more than 500 residents of a State are affected. Substitute notice need not be provided for a deceased individual where insufficient or out-of-date contact information precludes written notice to the next of kin or personal representative (§ 164.404(d)(2)).

When the notices account for fewer people than were affected (those notified, those notified through next of kin, and, once it is given, those given substitute notice), the incident lists People not yet accounted for and cannot close until the rest are recorded or you record why, under Law enforcement delay, and people not accounted for (for example, deceased individuals whose next of kin or personal representative could not be reached, or individuals a business associate or, for a shared breach, a client covered entity notified; a changed count of people affected is corrected on the incident instead).

Which notices apply follows your organization's answer to the protected health information question in Settings. An organization recorded as both a covered entity and a business associate, or one that has not answered, says on each breach whose information it was: its own, information it holds for a covered entity, or both. Until it does, both sets of notices are listed.

If a law enforcement official says a notice would impede a criminal investigation or damage national security, record the statement under Law enforcement delay: a written statement with the date it gives, or an oral one with the official's identity, which delays notice for no longer than 30 days unless a written statement follows (§ 164.412). While a delay runs, no federal deadline falls before its end, and nothing reads as late. A deadline set by state law is not moved.

A breach of unsecured PHI cannot be resolved until every notice it owes is dated; if a resolved incident is reassessed as a breach, it goes back to In review. A breach affecting fewer than 500 people does not wait for HHS: it is reported in your annual submission, no later than 60 days after the end of the calendar year in which it was discovered, and Risks & operations → Breach notifications counts each year's. That view shows every incident that involved protected health information and is not determined Not a breach of unsecured PHI, by the next notice it owes, and its export lists every notice, given or owed. Each dated notice still owed, the annual report included, is reminded to your organization's admins 7 days before its deadline, and again once the deadline has passed; a notice with no date yet has nothing to remind against.

A letter in plain language with Watney

Once the risk assessment records a breach, an admin can choose a letter your organization owes under Draft a letter in plain language and Draft with Watney. Watney rewrites the letter's narrative sections (what happened, what information was involved, what the people can do, what you are doing) in plain language, from what the risk assessment recorded. The opening, the contact details and the signature stay exactly as the PDF letter drafts them, and every fact the records do not hold stays a [To complete]. The draft appears below to copy into your letter: nothing is recorded or sent, and Watney's history keeps a copy of what it drafted. Check that the draft discloses nothing of your internal assessment beyond what the letter needs. Have your privacy officer or counsel review it before it is sent. Watney is sent the nature, acquisition and mitigation factors; the incident's title and narrative are not.

Serious incidents and authorities

Answer Yes to "Could this be a serious incident under the EU AI Act?" when your organization has judged it to be a serious incident under a law that applies to it. The EU AI Act, for example, defines serious incidents and requires providers of high-risk AI systems to report them; whether that duty falls on your organization depends on its role. For how bad an incident is in your own terms, use Severity. Record when an authority was notified, in your organization's time zone, and what was sent (authority notes).

Whether you must tell an authority, and by when, depends on the laws that apply to your organization. Backsplice records what you decide and when you acted, and this is not legal advice. Ask your legal or compliance team as soon as an incident might be serious.

The EU AI Act reporting deadline (Article 73)

Article 73 of the EU AI Act sets reporting deadlines for providers of high-risk AI systems. A deployer must immediately inform the provider, then the importer or distributor and the market surveillance authorities (Article 26(5)). Article 73's deadlines apply to a deployer that cannot reach the provider. Backsplice shows that deadline on an incident when all of these are recorded:

  • the incident is recorded as serious (the answer Yes to the serious question);
  • its AI system is classed high-risk (Annex I or Annex III), and is not an Annex I Section B product (for those, Article 2(2), as amended, applies only Article 6(1), Article 60a and Articles 102 to 112, and Articles 57 to 59 only in so far as the high-risk requirements have been integrated into that product legislation, so Article 73 does not apply);
  • your organization is recorded as the system's provider or deployer;
  • the system has a link to the EU.

The deadline counts from when your organization became aware of the serious incident: 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure, 10 days for a death, and 15 days otherwise. Each deadline is a latest date; Article 73 requires the report immediately. While the category is not yet known, the shortest period (2 days) is shown. If you leave Became aware at blank, the discovery date is used; it is earlier, so it shortens the deadline.

Article 73(5) allows an initial report that is incomplete, followed by a complete report, where necessary to ensure timely reporting. Record when you submitted it (Initial report sent at); the deadline is shown as met from the earlier of that and Authority notified at. A deployer also records when it informed the provider (Article 26(5): immediately).

For each class, the high-risk rules apply from a set date: 2 December 2027 for Annex III and 2 August 2028 for Annex I (Regulation (EU) 2026/1744). For an incident before that date, the deadline is shown for readiness and marked as not yet in force on this service's reading of Articles 111(2) and 113, as amended; confirm with counsel. After that date, a high-risk system placed on the market or put into service before it is covered only once its design changes significantly (Article 111(2), as amended); one intended for use by public authorities must comply by 2 August 2030. The deadline shown does not take this into account. Record when the system was placed on the market and put into service on its page (Market dates and EU database registration in the registry entry), and the incident page then says how those dates stand against the date for its class; with neither recorded, it says so. The deadline reminders, the register (Article 111(2) caveat beside the deadline), the CSV export and the API carry the same caveat. It never judges whether a design change was significant: confirm that, and whether Article 73 applies, with counsel. The people on the incident and the system's owners are reminded at the halfway point and on the due day, and the dashboard lists every serious incident still awaiting a report.

On an incident with a deadline, Draft the Article 73 report downloads a draft (PDF or Markdown) assembled from the incident and its AI system's records: the system's identification, the incident, the deadline as shown here, the people affected, the investigation notes, corrective actions, the oversight roster and monitoring plan, and when the provider and the authority were told. It is not a submission and follows no official form; every point the records do not hold says so. See EU AI Act regulator documents.

Whether Article 73 applies to an incident is a legal judgment for your organization. The category definitions on the form quote the Regulation. This is not legal advice.

Devices involved

An incident's page lists the devices involved: a lost laptop, a stolen phone, a drive sent to the wrong place. An admin links a device from the Devices register, or unlinks one linked by mistake; linking or unlinking changes neither the device nor the breach risk assessment. When a device still recorded In use is linked to a theft or loss incident, the page offers to mark it Lost or Stolen; nothing changes its status unless you choose it. A device linked to an incident is kept on the register as evidence. An admin also sees whether each device handles ePHI and when it was linked. An auditor whose access covers incidents sees each linked device's name, kind, status and encryption on the incident.

Corrective actions

An incident page lists its corrective actions: what is being done about it. Use Add a corrective action to record one; it becomes a task in the remediation register, linked to the incident, with a priority and, if you choose, an assignee (an active member who is not an auditor) and a due date, and is tracked and reminded there like any other task. Each task's page links back to its incident, and an organization admin can link an existing task to an incident, or unlink it, from the task's page. The Article 73 report draft lists the incident's own corrective actions, and says so when none is recorded.

An incident with corrective actions recorded cannot be deleted, and a task linked to an incident cannot be deleted either: an organization admin unlinks it from the task's page first, and the audit log records the unlink. An unlinked task stays in the remediation register, so deleting the incident afterwards does not delete the tasks that were its corrective actions.

From an incident to the system

Open an AI system's page to see the incidents recorded against it, and use Log an incident with this system to start one with the system already chosen. An incident is part of the system's history: a system with incidents cannot be deleted, only retired.

Score and exports

Incidents left open or under review for more than 30 days lower the Incident Response dimension of the compliance score. The register exports as CSV and PDF, with the same filters as the screen.