It is a Tuesday in April, weeks after the sustainability statement was filed and assured, when a supplier emails to say the activity data they sent you was for the wrong facility. Your AI-assisted Scope 3 workflow ingested it, tagged it as primary, and it now sits inside a published, externally-assured emissions figure. The number is wrong. What you do in the next hours and days decides whether this becomes a controlled correction or a greenwashing headline.

This Is a Disclosure Incident, Not an IT Incident

Most organizations already own an IT incident runbook: detect the outage, contain the breach, restore the service, write the postmortem. It is a good instinct and the wrong template. An AI-related disclosure error is not a systems failure to be restored; it is a published number that no longer traces to the truth, sitting inside a document an external assurer signed and investors and regulators rely on. The clock that matters is not uptime. It is the moment a wrong figure remains in the public record while you decide what to do. A disclosure incident runbook borrows the discipline of IT (named roles, defined severities, a clock, a log) and points it at a different target: the integrity of an assured, public figure.

The stakes are set by the 2026 landscape. Under Directive (EU) 2026/470, the companies in CSRD scope are the largest undertakings, where a misstatement is a board-level event. With 73% of large global companies now obtaining external assurance, the wrong number was not just published; it was assured, which means correcting it may re-open the engagement. And because Scope 3 averages around 75% of the footprint and leans on supplier data that 79% of reporters call hard to get, the AI workflows built to close that gap are exactly where a plausible-but-wrong figure can enter unnoticed. The runbook exists because these errors are not hypothetical; they are the predictable failure surface of doing the work at all.

What Makes an AI-Related Error Distinct

Errors have always entered disclosures: a fat-fingered spreadsheet cell, a supplier who sent bad numbers, a factor applied to the wrong activity. What makes an AI-related error distinct is not that it is more common but that it can be more silent and more systematic. A human transcription error usually affects one number. An AI extraction step that mislabels a category, or a model update that shifts how a factor is selected, can affect a whole batch of numbers in the same way, quietly, without a person ever looking at each one. And because AI output is fluent and confident, the error arrives dressed as a clean, plausible figure rather than an obviously suspect one. A hallucinated emission factor does not look wrong; it looks like exactly the kind of number a carbon accountant would expect. This is why the runbook has to assume that when one AI-produced number is wrong, its siblings from the same process may be wrong too, and why containment has to think in batches, not single cells.

The Five Phases: Detect, Contain, Assess, Notify, Correct

A disclosure incident runbook moves through five phases. They are sequential in logic but overlapping in practice, and the discipline is to run all five deliberately rather than jumping straight to a public correction or, worse, hoping no one notices.

1. Detect: Recognize That a Published Figure Is Wrong

Detection is the phase organizations underinvest in and later regret. An error can surface from anywhere: a supplier correction, a prior-period reconciliation that finally flags an implausible jump, an internal reviewer re-running a calculation, an analyst noticing an emission factor that no longer matches its cited source after a model update, or the assurer during the next cycle. The runbook's job at detection is not to judge severity yet. It is to capture the report the moment it arrives: what figure, where it appears, who raised it, and when, logged with a timestamp. That timestamp starts the clock and, later, proves to the assurer and regulator that the organization acted rather than sat. A culture where an analyst is thanked for flagging a wrong number, not blamed, is the single biggest driver of early detection.

2. Contain: Stop the Error From Spreading or Repeating

Containment in disclosure has two meanings. First, stop the bad figure from propagating: if the same AI-extracted datum or hallucinated factor feeds other calculations, other frameworks (the same fact base often flows into ESRS, ISSB, and CBAM), or a pending filing, freeze those uses immediately. Second, stop the mechanism from repeating: if a model change or an ungoverned prompt caused it, pause that AI use case for the disclosure until the governance body clears it. Containment is not correction; it buys you time to assess without the error metastasizing across the reporting stack while you think.

The instinct to quietly fix it and say nothing is the instinct that turns a correctable error into misconduct. In an assured disclosure, the cover-up is always worse than the mistake.

3. Assess Materiality: Size the Error Against the Threshold

Not every error requires a restatement, and treating a rounding difference like a scandal is its own failure. This phase answers one question with discipline: is the error material? That is a judgment against quantitative and qualitative thresholds, and it belongs to the disclosure and finance owners, not to the person who found the error and not to the AI. Quantitatively, size the misstatement against the disclosed figure and the relevant metric: does it change a total, a trend, an intensity ratio, or a target-tracking number in a way that would influence a reasonable user? Qualitatively, consider whether it touches a sensitive claim, a negative impact, a regulated CBAM value, or a figure the assurer specifically tested. Document the assessment and its basis, because the materiality call is itself something the assurer will examine. The materiality assessment is the fork in the road: it determines whether the incident heads toward a formal restatement and re-assurance or toward a prospective fix.

4. Notify: Tell the People the Process Requires

Notification is where governance and legal earn their seats. Based on materiality, the runbook defines who is told and when: the internal chain first (the reporting lead, the governance body, the signing controller or CSO, and via the escalation path the audit committee), then the external assurer through the assurance liaison, and, where a material published figure is affected, the parties the law or listing rules require. The assurer is not an adversary to hide from; they signed the number, and an early, candid notification through the liaison is what preserves the relationship and shapes an orderly re-assurance rather than a defensive one. Legal scopes any regulatory or market-disclosure obligation. The runbook names these paths in advance so that, on the day, no one is inventing the notification list under pressure.

5. Correct: Fix the Record With a Version Trail

Correction is the visible act, and its form follows the materiality assessment. A material error typically drives a restatement of the affected figure with clear disclosure of what changed and why, coordinated with re-assurance (covered in depth in the next lesson). A non-material error may be handled as a prospective fix and an internal correction in the evidence file. Either way, two things are non-negotiable. The corrected figure must trace to evidence just like any other, so the fix cannot itself be an unsupported number. And the whole event must leave a version trail: the original figure, the corrected figure, the reason, the date, the approvals, and the notifications, so that a year from now anyone, including a regulator, can reconstruct exactly what happened. A correction without a version trail is just a second number of uncertain provenance.

The Materiality Fork in Practice

Because the materiality assessment decides everything downstream, it deserves a disciplined method rather than a gut call. Start with the quantitative test against the specific figure and its context: express the error as a change to the disclosed number, then ask whether that change is significant relative to the total, the trend, the intensity ratio, and any target the figure tracks. A small absolute error can still be material if it reverses a trend or moves a target-tracking number across a threshold the company has publicly committed to. Then apply the qualitative overlay, because materiality in sustainability is not purely numeric. Does the error touch a negative impact the company was already under scrutiny for? A regulated value like a CBAM embedded-emissions figure tied to certificate obligations? A claim an investor or NGO has specifically questioned? A figure the assurer tested and relied on? Any of these can make an otherwise small error material. Finally, document the conclusion and its reasoning in a short memo, because the materiality call is the single most examined judgment in the whole incident, and the choice not to restate is as scrutinized as the choice to restate. The fork determines whether the next lesson's restatement and re-assurance protocol activates or whether a prospective fix suffices.

Roles, Severity, and the Clock

The runbook is only as fast as its pre-assigned roles. Name them before the incident: an incident owner (usually the reporting lead) who drives the process; the materiality assessors (disclosure and finance owners); the assurance liaison who carries it to the external assurer; legal for regulatory scope; and the accountable executive, the signing CSO or controller, who owns the outcome. Define severities so the response is proportionate: a low-severity, immaterial internal error handled in the file; a high-severity, material error in a published, assured figure that triggers the full path to restatement, re-assurance, and possibly regulatory notification. And keep the clock visible, because in disclosure, elapsed time while a wrong figure sits public is itself a fact the assurer and regulator will weigh.

A Worked Example: The Wrong-Facility Supplier Datum

Return to the Tuesday email. A supplier reports that the activity data they submitted, used in your assured Scope 3 Category 1 (purchased goods) figure, was for the wrong facility and overstated their emissions. Watch the runbook run.

Detect. The analyst who receives the email does not sit on it. They log it the same day: figure affected (Scope 3 Category 1), where it appears (the published statement, note X), source (named supplier email), and timestamp. The clock starts.

Contain. The reporting lead, as incident owner, checks propagation. The same supplier datum feeds the intensity ratio in the ESRS narrative and was mapped toward an ISSB disclosure in progress. Those downstream uses are frozen. Because the datum entered via an AI parsing step that tagged it as primary, the lead confirms whether other responses parsed in the same batch share the risk, and flags the batch for review. The error is boxed in before it spreads further.

Assess materiality. The disclosure and finance owners quantify it: the correction reduces the Category 1 figure by an amount that moves the total Scope 3 number and the year-on-year trend beyond the threshold a reasonable user would care about, and Scope 3 is a figure the assurer tested under the limited-assurance engagement. Qualitatively, it touches the headline emissions total. They conclude it is material and document the basis. This is the fork: the incident is now on the restatement path.

Notify. The incident owner briefs the governance body and the signing CSO; the escalation path informs the audit committee. The assurance liaison contacts the external assurer promptly and candidly: here is the error, here is our materiality assessment, here is our proposed correction. Legal assesses whether any market or regulatory notification is triggered by a material change to a published figure. Nobody learns of this from a journalist.

Correct. The team obtains the supplier's corrected, provenance-tagged datum, re-runs the calculation, and produces the restated figure, itself fully traceable. The correction is disclosed with a plain explanation of what changed and why, coordinated with the assurer's re-assurance of the affected figure. The version trail records the original number, the corrected number, the supplier correction, the materiality assessment, every approval, and every notification, with dates. Six months later, when the assurer's file review asks "walk us through the Category 1 correction," the answer is not a shrug; it is a folder.

Contrast the alternative: the analyst mentions it to no one, the wrong number stays public, the assurer finds it next cycle, and now the story is not "a supplier sent bad data and the company corrected it cleanly" but "an assured figure was wrong and the company sat on it." The error was the same. The runbook is the difference between a correction and a crisis.

Building the Runbook Before You Need It

The worst time to design an incident response is during an incident. The runbook is an artifact you write in calm conditions and keep current, so that on the day it runs itself. A usable disclosure incident runbook fits on a few pages and contains: the trigger definition (what counts as a potential disclosure error worth logging); the intake and log format with a timestamp field; the named roles and their backups, because the incident owner cannot be on holiday when the supplier emails; the severity matrix with worked examples so the classification is not argued from scratch; the pre-named notification paths, internal and external, with the assurer route through the liaison; the decision rights, which mirror the governance body's, on who can halt a use case and who approves a public correction; and the version-trail template so nobody has to invent the documentation under pressure. Rehearse it at least once, ideally with a tabletop exercise on a realistic scenario like the wrong-facility datum, so the team has run the motions before the stakes are real. A runbook that has never been tested is a document; a runbook that has been rehearsed is a capability.

The runbook also needs an explicit tie to the governance body and the two lessons that bracket this one. Detection and containment are operational and fast; the materiality fork hands off to the restatement and re-assurance protocol when the error is material; and the whole reason the file can be reconstructed quickly during an incident is that assurance readiness kept it reconstructable all along. An organization that treats these as one connected system, governance body, incident runbook, restatement protocol, and standing readiness, responds to a wrong number the way a well-run finance function responds to a misstatement: not with panic, but with a process that has already thought the hard parts through.

The No-Blame Imperative

None of this works without a culture that separates the person from the error. The single biggest determinant of how much damage a disclosure error does is how early it is caught, and the single biggest determinant of how early it is caught is whether the person who notices feels safe raising it. If flagging a wrong number gets an analyst blamed, punished, or buried in process, the rational move for a frightened employee is to stay quiet and hope, which is exactly the behavior that turns a small error into a scandal. A no-blame imperative does not mean no accountability; the governance body and the sign-off standard keep accountability firmly human. It means accountability sits on the process and the controls, not on the individual who honestly detects and escalates. The message from leadership has to be explicit and repeated: the person who raises the wrong number is doing their job well, and the failure the organization punishes is concealment, not detection. A team that believes this catches errors in April; a team that does not learns about them from the assurer, or the journalist, a year later.

Key Takeaways

• An AI-related disclosure error is not an IT incident to be restored; it is a published, assured figure that no longer traces to the truth, and the runbook borrows IT discipline for a different target: the integrity of a public number.
• Run all five phases deliberately: detect, contain, assess materiality, notify, correct, rather than jumping to a public fix or hoping no one notices.
• Detection depends on culture: thank the analyst who flags a wrong number, log every report with a timestamp, and start the clock, because elapsed time while a wrong figure sits public is itself a fact the assurer weighs.
• Contain in two senses: stop the bad figure from propagating across calculations and frameworks, and pause the AI use case or model change that caused it until the governance body clears it.
• The materiality assessment is the fork in the road: it decides restatement-and-re-assurance versus a prospective fix, it belongs to the disclosure and finance owners, and its basis must be documented because the assurer will examine it.
• Notify along pre-named paths: the internal chain and governance body, the external assurer through the assurance liaison early and candidly, and any legally required parties, so no one invents the list under pressure.
• The corrected figure must trace to evidence like any other, and the whole event must leave a version trail (original, corrected, reason, date, approvals, notifications) so anyone can reconstruct it later.
• The cover-up is always worse than the mistake: quietly fixing an assured figure and saying nothing turns a correctable error into misconduct.