Sustain: Problem Management, Post-Incident Learning and Knowledge

An incident ends when service is restored. Learning from it ends much later, and often not at all. This chapter concerns the part of operations that determines whether the next incident of the same kind happens: the problem record that collects what several incidents have in common, the post-incident review that establishes what was true, the actions that change the estate, and the knowledge (runbooks, articles, service records) that carries the change to the people and agents who work next. It concerns O5 Sustain, because learning is how an estate and the people who run it stay fit over time, and O2 Diagnose, because a review is a diagnosis carried out with the time and the evidence that an incident never allows.

The chapter makes four claims. A review that is blameless and evidence-based finds contributing conditions, and does not look for a single guilty cause or a single guilty person. A draft written by an AI system is a useful timeline and a poor analysis, and the way to keep it useful is to separate the two artefacts and to keep the people's own account independent of the draft. An action closes when its re-test passes, not when the review is signed, the ticket is moved or the change is merged. And knowledge that nobody owns decays into a hazard, which an assistant that retrieves it at machine speed makes worse. The chapter closes with what DORA Article 13 and NIS 2 Article 23 ask of the organisation after an incident, framed as architectural implications and not as legal advice.

Figure 12.1: From incident to problem to verified closure, with the re-test and the signature outside the team that made the change.

From incident to problem to change

Chapters 5 to 11 treated the loop in the present tense: observe, diagnose, change, restore, and keep the estate fit. This chapter treats the loop in the past tense. Three records carry an event from the moment it happens to the moment it is no longer a risk, and keeping them apart is the first discipline.

An incident record (INC-*) describes one event: what degraded, when, for whom, what was done and when service came back. Its purpose is restoration, and its author is the incident commander and the people on call. A problem record (PRB-*) describes a condition: a cause or a set of conditions that has produced, or could produce, one or more incidents. Its purpose is to remove or contain the condition, and its owner is a named role with the authority to change the estate. A post-incident review (PIR-*) describes what was learned from one or more incidents: the evidence-based account, the contributing conditions and the actions. The review is the bridge. It starts from the incident record and ends in a problem record, a change record, a runbook edit or a recorded decision to accept the risk.

The distinction is the book's own working definition. What matters for the loop is that each record answers a different question and has a different clock. The incident clock stops when service is restored. The review clock is set by how long evidence stays fresh: logs rotate, chat threads scroll away, and people forget the order of events within days. The problem clock stops when the condition is removed, contained or accepted, and it can run for months.

What turns an incident into a problem

Not every incident needs a problem record. Four triggers are worth writing down, because without them the choice is made by whoever has time.

The first is recurrence: two incidents within a defined period (the default in this book is 90 days) that share a contributing condition. The second is a restoration that depended on a workaround that nobody has removed. The third is impact above a threshold set in the service level objective record (SLO-*) of Chapter 5, such as an error budget consumed in a single event. The fourth is a regulatory trigger: an incident that was reportable under DORA or NIS 2 gets a review whatever its duration. A further source is not an incident at all. A failed restore test, such as the failed failover test RST-NR-2027-002 of Nordvik Region, is a finding with the same standing as an incident and enters the same process, because it shows a condition that would have produced an incident given a real failure.

A problem record carries a known-error flag and a workaround while the condition remains. The workaround is a runbook entry, linked from the service record, so that the next on-call engineer or agent finds it. This is where O5 meets O4 Restore: a workaround that lives only in a review document is not available at three in the morning.

From problem to change

A problem becomes a change by a recorded decision, not by a conversation. The record names the layer that failed (monitoring, change control, capacity, a supplier, a runbook, a person's access), the routes considered, the route chosen, the owner, the reviewer, the cost and an expiry. This is the decision record that AI Purple, Chapter 10, required of a finding in the purple loop, applied here to an operational problem. Three outcomes are legitimate and one is not. The condition can be removed by a change (CHG-*), contained by a compensating control, transferred by a contract, or accepted by a named person for a stated period. What is not legitimate is silence: a problem that is neither changed, contained, transferred nor accepted, and that ages in a list. Chapter 4 treats the autonomy budget as consumed by errors; the unaccepted problem is the human counterpart, a debt that has no owner.

Handovers are where problem management usually fails. The incident commander closes the incident, the review facilitator writes up the review, the problem owner is a different person in a different team, and the change belongs to a platform team whose backlog is set by someone else. The record that travels must therefore stand on its own: it carries the evidence links, the contributing conditions in plain language and the proposed re-test, so that the receiver does not need the author. The practice that makes this work is cheap. The review closes with the problem owner present and agreeing to the actions in the room, and a record without an accepted owner is not published.

The blameless, evidence-based review

The site reliability engineering literature put the blameless postmortem at the centre of its practice. The postmortem chapter of Google's book describes a written record of an incident, its impact, the actions taken, the root causes and the follow-up actions, and says that writing one is not a punishment but a learning opportunity. It assumes that everyone involved acted with good intentions and the best information they had, and it argues that removing blame gives people the confidence to escalate issues without fear, while an atmosphere of blame risks a culture in which incidents are swept under the rug (259, Lunney & Lueder, 2017). That is a statement of practice from one organisation, and it is not an empirical finding, but it names the mechanism that matters for the design: what a review can learn is limited by what people are willing to say, and what they are willing to say depends on what happens to those who say it.

Blamelessness has a limit that the same chapter states. A blameless review does not simply vent frustration by pointing fingers, and it still calls out where and how services can be improved. The aim is to shift attention from who acted to why the action made sense at the time, and what in the estate made it possible. A review that cannot say why a reasonable engineer, with the information on the screen, chose the step that preceded the outage has not finished.

Contributing conditions, not a single cause

Richard Cook's short paper on how complex systems fail makes the point that matters most for the structure of a review. Because overt failure requires multiple faults, he argues, there is no isolated cause of an accident, and no isolation of a root cause is possible; and hindsight bias remains the primary obstacle to accident investigation, because knowledge of the outcome makes events seem more noticeable to practitioners beforehand than they were (260, Cook, 2000). The experimental result behind the second claim is older. Fischhoff asked participants to judge the likelihood of outcomes with and without being told how events turned out, and found that those who knew the outcome rated it as more inevitable and overestimated what they would have known without that knowledge, largely unaware that the outcome had shifted their judgement (226, Fischhoff, 1975). The studies concern judgements of historical and everyday events and not incident reviews; the application to reviews is the book's inference, but it is a close one, because a reviewer is always in the position of someone who knows the outcome.

Three consequences follow for the form of a review. The timeline records what was observable at each step and by whom, with the information then available; a statement such as "the alert should have been noticed" is replaced by what the alert looked like, where it appeared and what else was on the screen. The analysis lists contributing conditions, each with its evidence, and does not name one cause. And the review separates three kinds of statement so that a reader can see how firm each is: observed (a log line, a trace, a configuration diff, a change record), reported (what a person says they saw or did, attributed by role) and inferred (a reviewer's reasoning from the other two). A timeline in which every entry has a kind and an evidence link can be checked. A narrative that reads well cannot.

The word root cause in regulation

The regulations that follow an incident use the term root cause, and the review has to meet them without giving up its own method. DORA Article 17 requires financial entities to ensure that root causes are identified, documented and addressed so that incidents do not recur, and Article 19(4) provides that the final report on a major incident is submitted when the root cause analysis has been completed (2, European Union, 2022). NIS 2 Article 23(4) requires a final report no later than one month after the incident notification, containing among other things the type of threat or the root cause that is likely to have triggered the incident (3, European Union, 2022). The practical reading is that the organisation records, for the regulator, the root cause it identified, and records in its own review the conditions that together allowed it. The two are consistent when the review says explicitly which condition it selected as the root cause for reporting purposes and why, and states that the selection is a reporting convention and not the whole account. Where the review and the report differ, the difference is explained in the record, not left for a supervisor to find.

Who attends, who writes, who is measured

A review has four roles. The facilitator did not take part in the incident, which is why the Hansa Mutual group runs reviews through its site reliability function and not through the team that owned the service. The participants include the people who acted, by role, and the service owner. The scribe, which may be an AI system under the rules of the next section, produces the timeline. The problem owner accepts the actions. The record names roles for decision points, and individuals only where the works agreement and the individual's consent allow.

What is measured follows AI Blue, Chapters 11 and 20, which concluded that learning is measured by the time from finding to verified control, by the recurrence of conditions and by the share of controls verified, reported for the team and never for the individual (F103) (302, Nordqvist, 2026). The number of reviews held, or of actions opened or closed, is not a measure of learning, and the operations annex KBV-IT-2024-OPS-02 of Hansa Mutual requires, from 2028-01-01, that operational metrics are reported for teams and services and never per named engineer, with a minimum group size of five. Chapter 20 returns to the metrics that mislead.

AI-drafted reviews

AI systems can write a first timeline. They retrieve the incident record, the chat transcript, the alert history, the deployment log and the change calendar, order the events and write them up. This is observable in the products and the practice of operations teams today, and it saves the scribe's hours. The question for the design is what the draft may be used for and what it may not conclude.

What the research reports

Three bodies of work bear on this, and each should be described before it is interpreted. Ahmed and colleagues studied whether large language models could recommend root causes and mitigations for cloud incidents, using more than 40,000 incidents from Microsoft services, with the incident's title and summary as the input, and added an evaluation by the incident owners. They report that lexical similarity metrics correlated only weakly and inconsistently with the owners' judgements, that the human study was small, and that the models were evaluated on one provider's services (227, Ahmed et al., 2023). The result supports caution about how recommendations are scored, and it measures a different task from drafting a timeline. Maynez and colleagues studied abstractive summarisation with the neural models of 2020 and found, through human annotation, substantial amounts of hallucinated content, meaning statements not supported by the source document, in the output of every model they tested (228, Maynez et al., 2020). The models are older and the task is news summarisation. What survives to the present argument is the mechanism: fluent text can contain statements that the source does not support, and a reader who finds the text fluent is less likely to check it.

The third body is the research on human use of automation. Parasuraman and Manzey reviewed the empirical studies and reported that automation complacency and automation bias appear in expert as well as naive participants, that they are not overcome by simple practice, and that automation bias leads to both omission and commission errors when the aid is imperfect (218, Parasuraman & Manzey, 2010). Bainbridge had argued the underlying point in 1983: the more reliable the automation, the more the person's remaining task is to monitor and to intervene in what the automation cannot do, and the less opportunity the person has to keep the skill that task needs (217, Bainbridge, 1983). None of these studies measured incident reviews drafted by an AI system. The inference to review is the book's own: a draft that is fluent, complete and written with knowledge of the outcome is exactly the artefact that invites a reviewer to accept it.

Three risks

The first risk is the plausible but wrong narrative. A timeline drafted from tickets and chat will tidy what happened. It will fill an unrecorded gap with the most probable event, give a decision an explanation that the person did not hold at the time, and merge two similar alerts into one. Each step is reasonable and the output reads as a coherent story, which is what makes it dangerous.

The second risk is hindsight written into the draft. The system that drafts the timeline holds the whole incident, including its end. A timeline that says "the configuration push, which was the cause, was approved at 14:02" has already decided the analysis. The draft must be written in the form that the evidence supports, each event described by what was observable then, and the analysis kept apart.

The third risk is anchoring and deference. When a draft exists, the review starts from it, the participants correct details in the draft instead of stating their own account, and the group's conclusion is close to the draft's. AI Governance, Chapters 10 and 21, recorded the same pattern in human oversight: approvals given in seconds are a signal of rubber-stamping (F21) (296, Nordqvist, 2026). In a review the equivalent signal is an analysis that adds nothing to the machine's account.

A fourth risk arises when the agent was part of the incident. If the IT-operations agent restarted a component and the same platform drafts the account, the account of the agent's action is written by the agent's own ecosystem, in the same model family and with the same context. This is the observer principle of Chapter 4 applied to learning: what describes an action must be independent of what performed it. The agent's action log is evidence and enters the timeline as observed. Its explanation of why it acted is reported, attributed to the agent, and never allowed to stand as the reason. The drafting system should be a different service from the system that acted, and a person checks the entries that concern the agent.

Separating the artefacts

The design that follows is simple. The review produces two artefacts with different authors.

The timeline may be drafted by an AI system at Level 1 Assisted (Chapter 4). Each entry carries a time, a source link and a kind (observed, reported, inferred). It contains no cause and no judgement, and it is checked by a person against the sources before the group session. The draft is marked as machine-drafted in the record, with the version of the drafting service, so that a reader can tell which parts a person verified.

The analysis is written by people. It contains the contributing conditions, the evidence for each, the alternatives considered and the actions. AI systems may take part under two rules. Because the drafting service reads incident text and chat that can contain instructions addressed to an agent (Chapter 18 treats the threat), it has read access only and no tool that changes the estate. They may search for similar past incidents and clusters of the same condition, and present them after the participants have written their own accounts, not before. And they may propose actions, which the group accepts, changes or rejects, with the reason recorded. They may not write the analysis section and they may not assign a cause.

Two controls test whether the arrangement holds. The first is the independent account: before the group sees the draft, each participant writes a short account of what they saw and did, in their own words and in at most ten minutes. The facilitator compares the accounts with the draft. Where they differ, the difference is the first thing the session discusses. The second is the seeded error, borrowed from The Transformed Security Architect, Chapter 14, and AI Blue, Chapter 14: the facilitator plants one deliberate false entry in a sample of machine drafts, say one in five, and records whether the reviewers found it (300, Nordqvist, 2026). A catch rate that falls over successive quarters is the signal that the review has become approval of the draft. The rate is reported for the review function and never for a reviewer.

What AI may and may not do in the review

Task	Allowed	Not allowed	Why
Timeline from records	Draft, with evidence links and kinds	Fill gaps with probable events	A gap is a finding, and an invented entry hides it
Retrieval of similar incidents	After the participants' accounts	Before them	Prior cases anchor the account
Clustering of incidents and alerts	Propose clusters and trend	Open or close a problem record alone	The grouping fixes what is treated as one condition
Contributing conditions	Suggest hypotheses for the group to test	Assign the cause	The review is a diagnosis that people own
Action proposals	Propose, with expected effect and re-test	Accept, schedule or close	An action is a commitment made by a named owner
Summary for management	Draft from the signed review	Draft from the incident record alone	The signed review is the verified account

Outlook, labelled

AI-drafted timelines are observable: they exist in current operations and observability products and in the practice described above. AI-proposed problem records inside a service-management workflow, where the system clusters incidents and opens a candidate record for a person to confirm, are expected, because they follow directly from existing clustering features and from the design in this chapter. Automated closure of an action on the system's own evidence, with no independent re-test and no named signature, is speculation, and the closure rule of the next section is written to make it fail, because a verifier that is the performer is the pattern that Chapter 17 sets out to prevent.

Action closure

A review that produces actions and no closure rule produces a list. The rule in this book takes over the closure rule of the purple loop (F116, AI Purple, Chapters 4 and 11) and applies it to operations.

An action is closed only when four things are true. Its re-test has passed: the condition that the action addressed has been exercised again, by a test, a game day or a restore test, and the result is the one the action promised. The evidence is attached: the result, the date, the environment and the test version. A named person signs, who is neither the person who implemented the action nor the system that ran the test. And the closure carries an age, the date of the re-test, so that a reader can tell how old the claim "this is fixed" is and when it expires. Chaos engineering is, in the words of Basiri and colleagues, the discipline of experimenting on a distributed system to build confidence in its capability to withstand turbulent conditions in production (239, Basiri et al., 2016); this book extends the idea, with game days, to the machinery around the fix, such as the rollback path and the stop path.

Five states keep the register auditable.

State	Meaning	Reported as
Open	Accepted by the owner, not yet implemented	Open
Implemented, unverified	The change is made and the re-test has not run	Open
Re-test failed	The re-test ran and did not give the promised result	Open, with the failure recorded
Closed and verified	Re-test passed, evidence attached, named person signed	Closed, with age
Risk accepted	A named person has accepted the condition until a stated date	Reported apart from closure

Two rules follow. An implemented but unverified change is reported as open, because "implemented" is a statement about the change and says nothing about the condition. And an accepted risk is reported separately from closure, with an expiry, because acceptance is a decision about exposure and not evidence of a fix. A risk acceptance that expires returns the action to open.

Not every action can be re-tested by a test written for it. Where the condition is rare, the closure may rest on a game day or a chaos experiment that reproduces its mechanism under control, at an authorised time, in a scope signed in advance and with a stop path outside the system being stopped. Where no re-test is possible at an acceptable cost, the honest closure is a risk acceptance, not a closed action.

Recurrence

A closed action can still prove wrong. The closure carries a recurrence check: 90 days after closure, the register is searched for incidents that share the problem's contributing conditions. A recurrence reopens the problem record and counts, for the team, as evidence about the quality of the closure and not as a failure of a person. The recurrence rate of conditions and the age of the oldest open action are the learning measures this book recommends, in line with F103.

Worked example: PIR and PRB records with an action closure rule

The records below are illustrative. They follow INC-HM-2027-0833 of Hansa Mutual, the configuration push to the AI gateway routing that broke the claims assistant in four markets for 47 minutes on 2027-09-30, with the canary stage skipped on a change classified as standard. The incident was not classified as major under the DORA criteria, so Article 13(2) did not require a review; group policy requires one for every incident of Tier 1 or 2 services above 30 minutes.

pir:
  id: PIR-HM-2027-0833
  incident: INC-HM-2027-0833
  held: 2027-10-07
  facilitator_role: group-site-reliability-reviewer   # not on the incident
  participants: [incident-commander-hamburg, platform-engineer-on-call, ai-platform-owner, claims-product-ops]
  timeline:
    drafted_by: HM-OPS-002 incident assistant        # AIDR-0951, Level 1 Assisted
    drafting_service_version: incident-drafter-2.4
    entries: 23
    verified_by_person: 23
    seeded_errors: {planted: 1, found: 1}
  independent_accounts_written_before_session: 4
  contributing_conditions:
    - id: C1
      text: "Routing configuration pushes were classed as standard change"
      evidence: [CHG-HM-6101, change-policy-v7]
    - id: C2
      text: "The canary stage was optional in the standard-change pipeline template"
      evidence: [pipeline-template-std-3, run-log-8841]
    - id: C3
      text: "Pre-production checks validated the schema, not the per-market overlays"
      evidence: [precheck-config-report-8841]
  root_cause_for_reporting: C2          # reporting convention; the account is C1 to C3
  analysis_author_roles: [group-site-reliability-reviewer, ai-platform-owner]
  ai_in_analysis: "similar-incident retrieval, after accounts; no cause assigned"
  decision_record: AIDR-0962            # drafting and analysis policy for incident reviews
  problem: PRB-HM-0019

prb:
  id: PRB-HM-0019
  opened: 2027-10-07
  owner_role: head-group-ai-platform
  service: SVC-HM-007
  linked_incidents: [INC-HM-2027-0833]
  known_error: true
  workaround: "RBK-HM-0031 section 4: roll back routing config to last signed version"
  as_of: 2027-12-15
  actions:
    - id: A1
      text: "Config pushes to AI gateway routing are normal change; canary stage mandatory"
      change: CHG-HM-6112
      state: closed_verified
      retest: {type: game-day, id: GD-HM-2027-04, date: 2027-11-25, result: "push without canary blocked by pipeline policy"}
      signed_by_role: head-operational-resilience
    - id: A2
      text: "Rollback of routing config within 10 minutes of the decision"
      state: retest_failed
      retest: {id: GD-HM-2027-04, date: 2027-11-25, result: "14 minutes; approval waited for a second approver"}
      next_retest: 2027-12-09
    - id: A3
      text: "Pre-production checks validate per-market overlays"
      change: CHG-HM-6118
      state: implemented_unverified      # reported as open
      next_retest: GD-HM-2028-01
    - id: A4
      text: "Cell-based split of the gateway per market"
      state: risk_accepted
      accepted_by_role: group-cio
      expires: 2028-06-30

The closure rule is a small piece of code in the register, so that the reported state does not depend on who edits the file. The rule below computes what the dashboard shows.

from datetime import date

REPORTED = {
    "open": "open",
    "implemented_unverified": "open",
    "retest_failed": "open",
    "closed_verified": "closed",
    "risk_accepted": "accepted",
}

def reported_state(action, today):
    state = action["state"]
    if state == "closed_verified":
        retest = action["retest"]
        if not (action.get("signed_by_role") and retest.get("result")):
            return "open", None            # closure needs a signature and evidence
        return "closed", (today - retest["date"]).days
    if state == "risk_accepted" and action["expires"] < today:
        return "open", None                # an expired acceptance reopens the action
    return REPORTED[state], None

Applied at 2027-12-15, the rule reports A1 as closed with an age of 20 days, A2 and A3 as open and A4 as accepted until 2028-06-30. The group site reliability function reports the register to the head of group site reliability and the head of operational resilience, who owns the independence of the re-test. Neither is the owner of the change. The dashboard shows two figures for the quarter: the age of the oldest open action and the share of conditions that recurred within 90 days.

Knowledge hygiene

Runbooks, knowledge articles, service records and architecture notes are the means by which a review changes the next incident. They are also where a review's value is lost, because stale knowledge looks identical to current knowledge.

The Hansa Mutual baseline shows the cost. During INC-HM-2026-0224, a storage degradation in a Cloud A region slowed the claims core for 2 hours 50 minutes, and failover to Cloud B was not attempted because the runbook was out of date. The knowledge existed and nobody trusted it enough to act on it. Nordvik Region's INC-NR-2026-0071, an expired signing certificate in the identity provider that blocked sign-in for 95 minutes, had the opposite cause: no inventory of certificates existed, so no article could say who owned renewal.

Ownership, review dates and verification

Four properties make a piece of knowledge usable in operations. It has a named owning role, so that someone is accountable for it. It is linked to a service record, so that an incident on SVC-HM-001 finds its runbooks and articles. It carries a last-verified date and a method, which is the strongest of the four, because "verified by game day on 2027-11-25" is evidence and "reviewed" is not. And it has an expiry: when the date passes without verification, the article is shown as unverified, in the search results and to any assistant that retrieves it.

The Knowledge-Centered Service method of the Consortium for Service Innovation describes the organisation of this work as two loops. The Solve Loop is the responder's work of capturing, structuring, reusing and improving articles while resolving requests, and the Evolve Loop is the team's work of reviewing many such events, assessing the health of the content and improving the process (261, Consortium for Service Innovation, n.d.). The method is aimed at the service desk and its knowledge base, and not at SRE runbooks, but its separation is useful: responders repair articles in the course of their work, and a smaller group measures whether the collection is healthy.

Retrieval makes staleness fast

Assistants such as the operations assistant NR-OPS-001 of Nordvik Region and the incident assistant HM-OPS-002 of Hansa Mutual retrieve over runbooks, past incidents and articles. Retrieval changes what staleness costs. A person who reads an old runbook may notice that the screenshots show a retired console. An assistant that retrieves the same text will quote it in a fluent recommendation. Three design rules follow, all by mechanism and none dependent on a product. The retrieval index carries the last-verified date, the method and the owner as metadata, and the assistant's answer shows them. Articles past expiry are excluded from recommendations for Tier 1 services, or are marked as unverified in the answer. And an AI system may propose an edit to an article (for example after a review shows that a step no longer works), while the owning role approves it, because an article that edits itself with no owner is a runbook that nobody has verified (Chapter 10 on runbook manifests).

Retiring knowledge

Hygiene includes deletion. The rule is mechanical: an article with no owner after a 30-day notice is archived, an article for a decommissioned service is archived with its service record, and an article not retrieved for 12 months is reviewed by its owner. Archived articles remain available to the audit trail under the archives rules and retention periods that apply.

Regulatory follow-up

The post-incident process is where the organisation's own learning and its reporting duties meet. This section attributes each statement to the instrument and the article, and it treats them as architectural implications.

DORA applies to Hansa Mutual's EU entities as an insurance undertaking and does not apply to Nordvik Region. Article 13 on learning and evolving sets out five duties for financial entities. They must have capabilities and staff to gather information on vulnerabilities and cyber threats. They must put in place post-incident reviews after a major ICT-related incident that disrupts core activities, examining causes and what needs to be improved, including speed of response, forensics, escalation and communication. They must feed lessons from the resilience testing of Articles 26 and 27, from real incidents and from recovery challenges into the ICT risk assessment and the review of the framework. They must monitor the effectiveness of the digital operational resilience strategy and the frequency, types and evolution of incidents. And they must report on the findings at least yearly to the management body, with recommendations. Entities other than microenterprises must also communicate changes made after post-incident reviews to the competent authorities on request (2, European Union, 2022).

The architectural implication is a data model and not a document set. The review record, the problem record, the action register and the re-test evidence must be linkable, so that the yearly report to the management body is a query over the register and not a writing exercise. The register already holds the three figures the management body can use: incident frequency and type, age of the oldest open action and recurrence. Where a review follows a major incident, the final report under Article 19(4) is due when the root cause analysis has been completed, which the review process must be able to meet. The time limits themselves are set in the regulatory technical standards provided for in Article 20 (2, European Union, 2022), which Delegated Regulation (EU) 2025/301 adopted (12, European Commission, 2025), and not in Article 19, and the group's compliance function owns them.

NIS 2 applies to Nordvik Region as the national transposition determines, and the Region plans as if its Tier 1 services are in scope. Article 23(4) sets the staged report: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, an intermediate report on request, and a final report no later than one month after the incident notification, with a progress report where the incident is still ongoing and a final report within one month of the handling's end (3, European Union, 2022). The architectural implication is that the review for a reportable incident must reach a defensible account of severity, impact and cause inside one month, and that a monthly forum, which is Nordvik's practice, can fall in the wrong place in the calendar. The Region's rule is that a reportable incident has its review scheduled within ten working days and does not wait for the forum.

GDPR Article 33(5) requires the controller to document any personal data breach, including the facts, its effects and the remedial action taken, so that the supervisory authority can verify compliance (6, European Union, 2016). Where an incident is also a personal data breach, the review record is part of that documentation, and the review's evidence links must therefore be kept for the retention period that applies to breach records. The same data protection rules apply to the review itself: incident chat and logs contain personal data, and a drafting service that reads them is a processor of it. For Nordvik Region the drafting service runs on the Region's reserved capacity for that reason.

NIST offers a framework view, not law. Special Publication 800-61 Revision 3 places improvement in the CSF 2.0 category ID.IM and notes that improvements are often identified when follow-up reports are written or lessons-learned meetings are held as an incident's recovery concludes, especially for a major incident, and that such a meeting is an opportunity to review what happened, what actions were taken and how effective they were. It also recommends an after-action report that documents the incident, the response and recovery actions, and lessons learned (41, NIST, 2025). The chapter's design satisfies both, and adds the re-test that the framework does not require.

Practical guide: running a review with an AI-drafted timeline and a human-written analysis

Purpose. Hold a review that uses a machine-drafted timeline without letting the draft determine the analysis, and that ends in actions with an owner, a re-test and a closing rule.

Roles. Facilitator (not on the incident), incident commander, on-call engineers and agent operators involved, service owner, problem owner, a person who verifies the timeline, and, where the works agreement requires it, an employee representative as observer. Where an AI system took part in the incident, the agent operator for that system attends.

Steps.

1. Within 24 hours of the incident's closure, preserve the evidence: export the alert history, deployment and change log, chat transcript, agent action log and relevant traces to the review folder, with a hash and a retention date.
2. Run the drafting service on the preserved evidence, at Level 1 Assisted, with read access only. Require each entry to have a time, a source link and a kind (observed, reported, inferred). Reject a draft in which an entry has no source.
3. A person who was not on the incident verifies every entry against its source and marks gaps as gaps. Plant one seeded false entry in one draft in five and record whether it is found.
4. Before the session, ask each participant to write their own account in at most 10 minutes, without the draft. Collect the accounts.
5. Hold the session within five working days for a Tier 1 incident and within ten for others. Start with the differences between the accounts and the draft. Then build the contributing conditions, each with evidence, and state which condition is the root cause for any regulatory report.
6. Only now ask the retrieval service for similar past incidents and clusters. Record what the group accepted and what it rejected, with reasons.
7. Agree no more than five actions. Each has a named owner, a due date within 90 days, a change or runbook reference, and a re-test method and date. The problem owner accepts the actions in the session.
8. Publish the review within ten working days, with names replaced by roles for decision points, and file the problem record.
9. Run the closure rule. An action is reported as closed only after the re-test passes, the evidence is attached and the named person signs. Review the register monthly, and run the recurrence check 90 days after each closure.

Definition of done. The review is published; the timeline's entries are verified; the contributing conditions have evidence; every action has an owner, a date and a re-test; the problem owner has accepted them; and the register reports the oldest open action and the recurrence rate for the team.

Adaptation. The time limits assume a Tier 1 service and must be adapted to the contract, the works agreement and the risk appetite. The seeded-error rate and the five-action cap are defaults, and teams should adjust both after two quarters of measured results. Any scoring of reviewers, including the catch rate of seeded errors, is reported for the team and never for a person.

Across the usage modes

The table shows, for each usage mode, how AI takes part in five learning tasks. The mode describes how the AI is deployed and whose identity it uses; the right-hand column gives the highest degree of delegation this chapter allows for the task.

Mode	Drafting a timeline	Clustering and trend	Proposing actions	Closing an action	Ceiling for the task
Mode 0 Ambient AI	Provider summaries in the service-management tool and the observability product, not under the group's control	Provider clustering of alerts and tickets, not configurable	Suggested categories and priorities	Not applicable	Treat as input only: never evidence in a review
Mode 1 Conversational assistants	Person pastes records into an assistant; allowed only for data classes the tool permits	Person asks for themes in a set of reviews	Person asks for ideas	Not applicable	Level 0 Advisory
Mode 2 Embedded workplace assistants	Incident summariser inside the observability product (Hansa: Lumenscope)	Trend summaries over the register	Suggested follow-ups in chat	Not applicable	Level 1 Assisted for the draft
Mode 3 Agentic work tools	Engineer uses a tool to assemble evidence and draft	Engineer asks for clusters	Engineer asks for a draft action list	Not applicable	Level 1 Assisted, read-only
Mode 4 Built AI applications	Drafting service under a mandate (HM-OPS-002, NR-OPS-001)	Clustering service that proposes candidate problem records	Action proposals with expected effect and re-test	Evidence pack for the signer	Level 1 Assisted for draft and proposals; Level 2 Supervised for candidate problem records
Mode 5 Autonomous production agents	Agent writes the account of its own actions	Agent groups conditions into one problem and opens the record	Agent schedules the changes it proposed	Agent closes the action on its own evidence	None of these at Level 3 or 4; the agent's action log is evidence, written to a store it cannot edit

Two limits recur. No system closes an action: a system may prepare the evidence pack and recommend, and a named person signs. And no system that took part in the incident drafts the account of its own contribution.

Nordvik Region and Hansa Mutual

The two organisations run the same loop with different machinery and different weak points.

Nordvik Region reviews incidents in a monthly incident and problem forum, organised by the IT management office, and tracks actions in ServiceFlow, its service-management tool, where the service desk lead, Sara Ekdahl, owns the knowledge base. The weak point is closure. After the failed failover test RST-NR-2027-002 of 2027-10-12 (5 hours 20 minutes against a 2-hour objective, because of a DNS time-to-live and an unrenewed certificate at the recovery site), the tracker showed the two corrective actions as done once the changes were made. The re-test had not been run at the commission of 2028-09-12, about eleven months later. Under the closure rule both actions are implemented but unverified and are reported as open, with an age of 336 days, and the portal's failover claim has no valid evidence. The same rule catches PRB-NR-0007, the problem record for the storage controller failure of INC-NR-2027-0034, whose failover took 3 hours 40 minutes against a 2-hour objective: the problem is closed only when a failover test of the portal meets the objective. The Region's second weak point is calendar: the monthly forum is too slow for a reportable incident, so such a review is scheduled within ten working days. Its drafting is done by the operations assistant NR-OPS-001 at Level 0 Advisory for retrieval only, with the timeline drafted by a platform engineer, and the Region records the policy as AIDR-0912. The agreement MBL-NR-IT-2027-01 forbids reporting closure counts or response times by name.

Hansa Mutual runs reviews through Group Site Reliability and Incident Management under Tobias Richter, with the drafting done by the incident assistant HM-OPS-002 at Level 1 Assisted under AIDR-0962 and the analysis written by people. It closes a review action only when a game-day re-test passes, which is why PRB-HM-0019 in the worked example reports one action closed in the quarter and two as open despite their changes being in production. Its weak point is the one this chapter's third risk names: the IT-operations agent HM-OPS-001 takes part in many incidents, so the independence of the account of its actions matters, and the group keeps the agent's action log in a store the agent cannot edit and has a person verify every entry about it. The register is reported to the management body for DORA purposes through the head of operational resilience, which is the Article 13(5) report in practice. The group extends the post-incident review that Article 13(2) requires for major incidents to every incident on a Tier 1 or Tier 2 service over 30 minutes, which is group policy and not law.

Summary

This chapter treated problem management and post-incident learning as the part of O5 Sustain that determines whether an incident recurs, and as an extension of O2 Diagnose that has the time and the evidence the incident never had. An incident record, a problem record and a post-incident review answer different questions with different clocks. A problem becomes a change by a recorded decision with one of four outcomes, and a problem that is neither changed, contained, transferred nor accepted is a debt without an owner.

A blameless, evidence-based review lists contributing conditions with evidence and separates observed, reported and inferred statements. It resists hindsight, which Fischhoff measured and Cook argued is the main obstacle to learning from accidents, and it meets the regulatory demand for a root cause by selecting one for reporting while recording the conditions that together allowed the incident. AI systems can draft a timeline at Level 1 Assisted, with evidence links and a person verifying every entry; they may cluster incidents and propose actions; they may not write the analysis, assign a cause or close an action. The drafting service is independent of any agent whose actions it describes, participants write their own accounts before they see the draft, and seeded errors measure whether review has become approval.

An action closes when its re-test passes, the evidence is attached, a named person signs and the closure carries an age; an implemented change is reported as open, and an accepted risk is reported apart from closure. Knowledge is owned, linked to a service record, carries a last-verified date and a method, and expires; retrieval by assistants makes stale knowledge fast, so freshness travels with the text. DORA Article 13, DORA Articles 17 and 19, NIS 2 Article 23 and GDPR Article 33(5) all depend on a register in which reviews, problems, actions and re-test evidence can be linked. Nordvik Region's open failover actions and Hansa Mutual's game-day closure show the same rule applied with different resources.

The reader can act on one thing this week: take the oldest action in the problem register that is marked done and find its re-test. If there is none, report the action as open. Chapter 13 turns from the loop to what it operates when the operated system is itself an AI system, where model updates, drift and provider change create incidents of a new kind.

Sources

1. Lunney, J. & Lueder, S. (2017). Postmortem Culture: Learning from Failure. In Site Reliability Engineering, Chapter 15. O'Reilly Media and Google. (259, Lunney & Lueder, 2017)
2. Cook, R. I. (2000). How Complex Systems Fail. Cognitive Technologies Laboratory, University of Chicago. (260, Cook, 2000)
3. Fischhoff, B. (1975). Hindsight is not equal to foresight: The effect of outcome knowledge on judgment under uncertainty. Journal of Experimental Psychology: Human Perception and Performance 1(3), 288-299. (226, Fischhoff, 1975)
4. Ahmed, T., Ghosh, S., Bansal, C., Zimmermann, T., Zhang, X. & Rajmohan, S. (2023). Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models. ICSE 2023; arXiv:2301.03797. (227, Ahmed et al., 2023)
5. Maynez, J., Narayan, S., Bohnet, B. & McDonald, R. (2020). On Faithfulness and Factuality in Abstractive Summarization. Proceedings of ACL 2020, 1906-1919. (228, Maynez et al., 2020)
6. Consortium for Service Innovation. KCS v6 Practices Guide: The Evolve Loop. (261, Consortium for Service Innovation, n.d.)
7. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
8. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
9. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). (6, European Union, 2016)
10. National Institute of Standards and Technology. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. NIST SP 800-61 Rev. 3. (41, NIST, 2025)
11. Basiri, A. et al. (2016). Chaos Engineering. IEEE Software 33(3). (239, Basiri et al., 2016)
12. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6). (217, Bainbridge, 1983)
13. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3). (218, Parasuraman & Manzey, 2010)
14. Nordqvist, G. (2026). AI Governance. The Transformed Architecture, Book 2. (296, Nordqvist, 2026)
15. Nordqvist, G. (2026). The Transformed Security Architect. The Transformed Architecture, Book 6. (300, Nordqvist, 2026)
16. Nordqvist, G. (2026). AI Blue. The Transformed Architecture, Book 8. (302, Nordqvist, 2026)