6. Incident Management and Operational Readiness

Introduction and Context

Site Reliability Engineering treats failure as an expected property of complex systems rather than as an exceptional event. Even well-designed services experience software defects, infrastructure failures, dependency outages, configuration errors, security events, capacity shortages, and human mistakes. Reliability therefore depends not only on prevention but also on the organisation’s ability to detect, understand, contain, communicate, and recover from incidents.

Incident management is the coordinated process through which an organisation responds to an event that threatens the availability, performance, security, correctness, or recoverability of a service. Operational readiness is the degree to which a service, team, and organisation are prepared to operate that service safely under normal conditions and during disruption. These ideas are closely connected. A service without effective monitoring, ownership, documentation, or escalation paths creates avoidable operational risk; a service with strong readiness can limit the duration and impact of failure even when prevention has been unsuccessful.

This chapter examines incident management as both a technical discipline and a socio-technical practice. It addresses detection, triage, classification, escalation, incident command, communication, recovery, runbooks, on-call work, operational readiness reviews, human factors, and responder well-being. The aim is not merely to restore systems quickly, but to create a disciplined response that preserves evidence, supports sound decisions, protects people, and produces organisational learning.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the purpose, scope, and lifecycle of incident management in SRE.

2. Distinguish detection, triage, diagnosis, mitigation, recovery, and learning activities.

3. Classify incidents according to impact, urgency, scope, and uncertainty.

4. Design escalation paths, incident-command structures, communication plans, and runbooks.

5. Evaluate on-call arrangements and operational readiness using meaningful evidence.

6. Analyse the effects of cognitive load, fatigue, ambiguity, and organisational culture on response quality.

7. Apply incident-management principles to a realistic production scenario.

8. Identify governance, ethical, security, and privacy considerations in incident response.

Incident Management as a Reliability Capability

An incident is not simply an alert. An alert is a signal generated by a monitoring or detection system; an incident is a situation requiring coordinated action because a service or business objective is at risk. A high-severity alert may be a false positive, while a serious incident may initially be reported by a customer before any automated alert fires.

Incident management normally includes six overlapping activities:

• Detection: recognising that an abnormal or harmful condition exists.
• Triage: establishing what is happening, how serious it may be, and what action is needed immediately.
• Diagnosis: developing and testing hypotheses about causes and contributing conditions.
• Mitigation: reducing customer or business impact, even if the underlying cause remains.
• Recovery: restoring the service to an acceptable and stable state.
• Learning: reviewing evidence, identifying systemic improvements, and tracking corrective actions.

The sequence is not always linear. Teams may mitigate before the cause is known, discover that recovery introduced a second fault, or revise severity as evidence changes. Mature practice therefore values controlled adaptation over rigid adherence to a predetermined script.

A useful distinction is between restoration and resolution. Restoration returns users to an acceptable level of service. Resolution explains and addresses the conditions that caused the incident sufficiently to prevent immediate recurrence or unacceptable residual risk. During a live event, restoration generally has priority. Pursuing a perfect root-cause explanation while users remain affected can increase harm.

Incident management also differs from problem management. Incident management focuses on reducing current impact; problem management investigates recurring or significant underlying causes and coordinates long-term corrective work. Change management, release management, security response, and business continuity may intersect with incident management, but they have different purposes and controls.

Detection, Signals, and the First Minutes

Detection quality determines how much time an organisation has to respond. Effective detection combines technical telemetry with human reporting. Metrics, logs, traces, synthetic tests, customer reports, support tickets, and security detections each reveal different aspects of system health.

Signals should be evaluated against service-level objectives (SLOs), not merely infrastructure thresholds. For example, CPU utilisation may be high without affecting users, whereas a modest increase in request latency may consume the available error budget. Good alerts are actionable, timely, sufficiently specific, and linked to an owner or response procedure. An alert that cannot lead to a clear decision creates noise and increases the risk that a genuine event will be ignored.

During initial triage, responders should establish four basic facts:

1. What is affected? Identify service, function, region, customer segment, or data flow.

2. Who is affected? Determine whether impact concerns internal users, external customers, partners, or regulated operations.

3. How large and urgent is the impact? Estimate severity, duration, scope, and trend.

4. What safe action can reduce harm now? Consider rollback, traffic shifting, feature disablement, isolation, or capacity changes.

The first report should be treated as evidence, not as a complete explanation. Prematurely naming a cause creates anchoring: responders begin interpreting every subsequent observation to fit the first theory. A disciplined initial message might state: “Checkout failures increased sharply in one region after 14:05 UTC; cause unknown; payment retries are being disabled while the team investigates.” This communicates facts, uncertainty, and immediate action without speculation.

Classification and Escalation

Classification creates a shared language for urgency. Organisations commonly use severity levels, but a label is useful only when it is connected to observable criteria and required actions. A practical classification model considers:

• customer and business impact;
• breadth of affected users or functions;
• duration and expected duration;
• safety, security, privacy, or regulatory implications;
• reversibility of harm;
• confidence in the diagnosis; and
• whether executive, legal, or external communication is required.

A critical incident may involve widespread unavailability, material data loss, a significant security compromise, or a threat to safety. A high-severity incident may affect an important service or a substantial customer group but have a workaround or limited scope. Lower-severity incidents may be handled within normal team processes, provided that their cumulative impact is not overlooked.

Severity should be revisited as conditions change. A small initial failure can become critical if it spreads, persists, affects a peak business period, or reveals compromised credentials. Conversely, an apparently broad event may be downgraded after traffic is isolated and customer impact is shown to be limited. Reclassification is not an admission of failure; it is evidence-based control.

Escalation should be time-bound and condition-based. A policy might specify escalation when impact exceeds a threshold, when diagnosis remains uncertain after a defined period, when a security or privacy concern arises, or when the primary responder cannot safely continue. Escalation paths should identify technical specialists, service owners, incident commanders, communications personnel, security and privacy contacts, executives, vendors, and relevant business representatives.

A common mistake is to equate escalation with loss of control. In reality, early escalation increases control by bringing the necessary authority and expertise into the response. Escalation should also include de-escalation criteria so that unnecessary participants can leave once their contribution is complete.

Incident Command and Coordination

For significant incidents, technical expertise alone is insufficient. Someone must coordinate priorities, maintain a shared operational picture, allocate work, control communication, and decide when the response is safe to close. This role is commonly called the incident commander (IC).

The IC is not necessarily the most senior engineer or the person who knows the affected system best. The role is one of coordination and decision-making. In larger incidents, responsibilities can be separated into distinct roles:

• Incident commander: sets objectives, priorities, and decision cadence.
• Operations or technical lead: directs investigation and mitigation tasks.
• Communications lead: prepares internal, customer, executive, and external updates.
• Scribe or historian: records timeline, decisions, hypotheses, and actions.
• Subject-matter experts: provide specialist knowledge without taking over overall coordination.
• Business or liaison lead: connects response decisions with customer, legal, regulatory, or commercial concerns.

Role separation reduces context switching. A technical lead should not be expected to debug a distributed system while simultaneously drafting executive updates and maintaining an accurate timeline. In small incidents, one person may perform several roles, but the responsibilities should still be explicit.

The IC should establish a response channel, declare severity, assign roles, state the current objective, and define the next update time. Useful objectives are concrete: “Restore successful payment authorisation for affected users,” or “Prevent further data exposure while preserving forensic evidence.” Broad instructions such as “find the root cause” are less useful during an active event.

Decision-making should favour reversible actions when uncertainty is high. Rollbacks, traffic shifting, feature flags, rate limiting, and isolation may be safer than broad configuration changes. Every significant action should have an owner, a stated expected effect, and a method for verifying the result.

Communication During Incidents

Communication is part of the technical response because uncertainty itself creates operational and business harm. Customers may retry requests, support teams may generate duplicate work, executives may make uninformed decisions, and regulators may require timely notification. Silence encourages speculation; excessive unverified detail creates confusion.

Effective incident communication is:

• factual rather than speculative;
• clear about scope and uncertainty;
• regular enough to establish confidence;
• adapted to the audience;
• consistent across channels; and
• respectful of security, privacy, and legal constraints.

Internal updates should normally include current impact, known facts, active hypotheses, actions in progress, decisions required, and the next update time. Customer updates should explain the user-visible effect, affected functions or regions, available workarounds, and the status of restoration. They should not disclose sensitive implementation details that could increase security risk.

A communication lead should maintain a single source of truth, such as an incident record or status page, while recognising that different audiences require different levels of detail. If information is unknown, it is better to say so and provide the next review time than to fill gaps with conjecture.

Post-incident communication should distinguish accountability from blame. Customers deserve accurate information about impact and remediation. Employees deserve an environment in which honest reporting is not punished. This does not eliminate responsibility; it directs responsibility toward decisions, controls, incentives, and system conditions rather than simplistic personal blame.

Runbooks, Playbooks, and Operational Knowledge

A runbook is an operational procedure for a known task or condition. It may explain how to verify a service, rotate credentials, fail over a database, roll back a release, or respond to a specific alert. A playbook is often broader, describing a class of incidents and the decisions associated with it. Both are forms of organisational memory.

A useful runbook contains:

1. purpose, scope, and assumptions;

2. prerequisites, permissions, and safety checks;

3. observable symptoms and relevant dashboards;

4. diagnostic steps in a sensible order;

5. mitigation and recovery actions;

6. verification criteria;

7. rollback or abort instructions;

8. escalation contacts and stopping conditions; and

9. links to authoritative architecture and ownership information.

Runbooks must be tested under realistic conditions. Documentation that assumes obsolete commands, expired credentials, unavailable dashboards, or a single expert is not operational readiness. A short, accurate runbook is more valuable than a long document that responders cannot navigate under pressure.

Automation can improve consistency, but automation must have guardrails. A remediation script should validate its target, limit scope, log actions, support dry runs where possible, and provide a recovery path. Automatic remediation is especially risky when the signal is ambiguous or when the action can destroy evidence, amplify traffic, or affect multiple tenants.

On-Call Practice and Responder Well-Being

On-call work is a form of operational labour that carries cognitive, emotional, and sometimes physical costs. A service may technically have an on-call rota while being operationally unsafe if alerts are excessive, ownership is unclear, handovers are poor, or responders cannot obtain assistance.

A sustainable on-call system includes adequate staffing, clear primary and secondary coverage, escalation to specialists, protected rest after disruptive events, tested contact mechanisms, and explicit authority to wake others. Rotations should account for time zones, local employment requirements, accessibility, and the cumulative effect of repeated interruptions.

Cognitive load increases when responders must search multiple systems, reconcile conflicting dashboards, remember undocumented procedures, or work under social pressure. Incident interfaces should therefore reduce unnecessary information and make important state visible. Checklists, role labels, timestamps, decision logs, and concise dashboards are cognitive aids, not signs of reduced expertise.

Fatigue is a reliability risk. After a prolonged incident, a handover may be safer than continued effort by the original responder. Handover notes should state what is known, what has been tried, current risks, pending decisions, and the next verification point. Psychological safety is equally important: responders must be able to report uncertainty, challenge unsafe actions, and acknowledge mistakes without fear of humiliation.

Operational Readiness Reviews

An operational readiness review (ORR) assesses whether a service is prepared to be launched or materially changed. It should occur before production exposure and at significant architectural, ownership, or dependency changes. The review is not merely a checklist approval; it is an evidence-based examination of operational risk.

Typical ORR evidence includes:

• documented service ownership and escalation contacts;
• defined SLIs, SLOs, and alert thresholds;
• tested dashboards and useful logs;
• capacity and dependency analysis;
• backup, restore, and disaster-recovery evidence;
• deployment, rollback, and feature-flag procedures;
• security, privacy, and access-control assessment;
• runbooks tested by someone other than the author;
• on-call readiness and training;
• failure-mode and resilience testing; and
• agreed launch criteria and residual-risk ownership.

A mature review distinguishes between a risk that is accepted, a risk that is mitigated, and a gap that blocks launch. It also identifies assumptions. For example, a recovery objective that depends on a vendor’s undocumented behaviour is not strong evidence of readiness. ORRs should remain proportionate: a low-risk internal service does not need the same process as a system handling safety-critical or regulated transactions.

Readiness is not permanent. Services drift as dependencies change, teams reorganise, traffic grows, and documentation decays. Periodic reviews, game days, disaster-recovery exercises, and learning from real incidents keep operational knowledge current.

Post-Incident Learning and Metrics

A post-incident review should reconstruct what happened, how the system behaved, how people understood it, and how decisions affected impact. A timeline should include detections, significant observations, changes, mitigations, communications, escalations, and recovery milestones. The review should also examine why existing controls did not prevent, detect, or limit the event.

A blameless review does not mean that every action was equally appropriate. It means that analysis begins with context: available information, system design, incentives, training, workload, interfaces, and organisational constraints. Corrective actions should be specific, owned, prioritised, and tracked to completion.

Useful measures include mean time to detect, acknowledge, mitigate, and recover; duration of customer impact; alert precision; escalation delay; repeat-incident rate; percentage of incidents with timely updates; and completion of remediation actions. These metrics require interpretation. A falling mean time to recovery may reflect better practice, or it may result from under-reporting, reduced severity classification, or premature closure. Metrics should support learning rather than encourage responders to conceal uncertainty or avoid escalation.

Applied Case: The Regional Checkout Failure

Background

This illustrative case concerns Nimbus Retail, an online retailer operating a checkout service across three regions. The service uses a payment provider, a distributed cache, and a feature flag controlling a new fraud-screening integration. The team has an SLO for successful checkout transactions and maintains a primary and secondary on-call rotation.

Situation

At 14:05 UTC, synthetic tests in the European region show a sharp decline in successful checkout transactions. Customer support begins receiving reports of failed payments. An alert is generated for elevated error rate, but the dashboard combines payment-provider errors with application validation errors, making the initial signal difficult to interpret.

The primary responder acknowledges the alert but initially assumes a provider outage. At 14:12, the error rate spreads to a second region. The responder disables the fraud-screening feature flag, but the action has no immediate effect. The team has not yet assigned an incident commander, and two engineers investigate independently without recording hypotheses.

Analysis

The event has broadening customer impact and uncertain cause, so it should be classified as high severity and escalated immediately. The absence of a clear commander creates duplicated work and inconsistent communication. The dashboard’s aggregation hides an important distinction between provider failure and application rejection. The feature flag change was reasonable but was not accompanied by a defined verification step.

Further investigation shows that a recently deployed client library sends a malformed currency code for a subset of transactions. The problem is amplified by a retry policy that causes additional requests and increases provider-side throttling. The original regional symptom was caused by traffic composition, while the cross-region spread resulted from a global deployment.

Approach and Solution

The engineering manager assumes the IC role, assigns a technical lead and communications lead, and establishes ten-minute update intervals. The technical lead confirms the deployment correlation, pauses further rollout, and rolls back the library. The team temporarily reduces retries and monitors successful transaction rate, provider throttling, and checkout latency separately. Support receives a concise customer message describing failed checkouts and advising customers not to repeat payment attempts unnecessarily.

The rollback restores the service gradually. The team keeps the incident open until error rates remain within the SLO and reconciliation confirms that no duplicate charges occurred. The post-incident review identifies four corrective actions: separate application and dependency error signals, test currency handling across regions, introduce retry-budget controls, and revise the deployment runbook to require staged verification.

Outcome and Learning Points

The case demonstrates that effective response depends on more than technical diagnosis. Classification must reflect expanding impact and uncertainty. Command roles prevent duplicated effort. Mitigation should be verified using user-centred indicators rather than infrastructure health alone. Communication can reduce secondary harm, such as repeated payment attempts. Finally, operational readiness must cover dependencies, rollback, observability, and the human process of coordination.

Challenges, Risks, and Common Mistakes

Incident programmes often fail through predictable patterns. Alert fatigue causes responders to ignore important signals. Excessive severity levels produce either over-escalation or normalisation of serious failure. Unclear ownership leads to delayed decisions. Root-cause fixation delays mitigation. A lack of communication causes customers and executives to invent their own explanations.

Other risks include unsafe automation, unauthorised emergency changes, inadequate preservation of security evidence, misleading status updates, and closure before verification. Runbooks can create false confidence when they are not exercised. On-call arrangements can become exploitative if organisations treat personal sacrifice as a substitute for engineering investment.

Governance should define who may make emergency changes, how those changes are recorded, how access is audited, and how privacy and regulatory obligations are handled. During a security incident, teams must coordinate with security, legal, privacy, and forensic specialists; deleting logs or resetting compromised systems prematurely may destroy evidence. Customer notifications must be accurate, proportionate, and consistent with applicable obligations.

Technology, Automation, and Emerging Practice

Modern incident response increasingly uses event correlation, distributed tracing, anomaly detection, automated rollback, status-page integration, and collaborative incident platforms. Machine-learning systems may help identify unusual patterns or summarise large volumes of telemetry, but they should support rather than replace accountable human decision-making. Automated recommendations need confidence indicators, evidence links, and mechanisms for challenge.

OpenTelemetry-style instrumentation, service dependency maps, error-budget policies, and progressive delivery can improve detection and containment. ChatOps can centralise commands and records, but sensitive credentials and personal data must not be exposed in shared channels. Digital twins, chaos experiments, and game days allow teams to rehearse failure without waiting for production incidents.

Emerging practice is moving toward resilience engineering: studying how systems succeed under varying conditions, not only how they fail. This perspective recognises adaptation, workload, communication, and organisational design as components of reliability. The most mature organisations combine automation with human judgement, invest in responder well-being, and treat operational learning as a product of normal engineering work rather than an exceptional administrative exercise.

Best-Practice Principles

A dependable incident-management capability generally follows these principles:

1. Define incidents in terms of user and business impact.

2. Alert on meaningful SLO symptoms and continuously reduce noise.

3. Escalate early when impact, uncertainty, or risk is high.

4. Separate coordination, technical investigation, and communication when scale requires it.

5. Prefer reversible, verifiable mitigation under uncertainty.

6. Maintain concise, tested, and owned runbooks.

7. Make handovers, logs, decisions, and assumptions visible.

8. Communicate facts, uncertainty, and next-update times consistently.

9. Protect responders from avoidable fatigue and excessive cognitive load.

10. Use blameless, evidence-based reviews with tracked corrective actions.

11. Treat readiness as a continuing condition, not a one-time launch approval.

12. Measure outcomes without creating incentives to hide incidents or uncertainty.

Chapter Summary

Incident management is the coordinated practice of detecting, assessing, containing, communicating, recovering from, and learning from events that threaten service objectives. Effective response depends on meaningful signals, evidence-based severity classification, timely escalation, clear incident command, audience-appropriate communication, and safe mitigation. Runbooks and automation improve consistency only when they are current, tested, controlled, and reversible.

Operational readiness extends beyond technical functionality. It includes ownership, observability, dependency understanding, recovery procedures, security and privacy controls, on-call capability, and evidence that people can operate the service under stress. Human factors such as fatigue, cognitive load, ambiguity, and psychological safety directly influence reliability. Operational readiness reviews, post-incident learning, resilience exercises, and carefully interpreted metrics help organisations improve without blame or misleading performance incentives.

Key Terms

Incident: An event requiring coordinated action because service, business, security, or safety objectives are threatened.

Alert: A signal indicating a condition that may require investigation or response.

Triage: The initial assessment of impact, urgency, scope, and immediate action.

Mitigation: An action that reduces harm or customer impact without necessarily removing the underlying cause.

Recovery: Restoration of a service to an acceptable and stable operating condition.

Incident commander: The person responsible for coordinating priorities, roles, decisions, and response objectives.

Severity: A classification of incident impact and urgency used to determine response requirements.

Escalation: Transfer or expansion of response responsibility when impact, uncertainty, or expertise requirements exceed current capacity.

Runbook: A documented procedure for performing a specific operational task or responding to a known condition.

Playbook: A broader response guide covering a class of incidents, decisions, and possible actions.

On-call: An arrangement in which designated personnel are available to respond to operational events.

Operational readiness review: An evidence-based assessment of whether a service is prepared for production operation or major change.

Service-level objective: A target level of service performance or reliability measured through defined indicators.

Error budget: The tolerable amount of unreliability implied by an SLO over a specified period.

Blameless review: An analysis that examines system conditions and decisions without simplifying failure into personal fault.

Cognitive load: The mental effort required to understand information, make decisions, and perform tasks.

Game day: A planned exercise in which teams practise responding to failure or disruption.

Mean time to recovery: The average time required to restore service after an incident.

Post-incident review: A structured examination of events, decisions, impact, and improvement actions after an incident.

Review Questions

Short Answer Questions

1. Distinguish an alert from an incident.

2. What are the principal responsibilities of an incident commander?

3. Why should severity be reassessed during an incident?

4. Identify four elements that should appear in a runbook.

5. How can fatigue affect incident response quality?

Long Answer Questions

1. Explain the incident lifecycle from detection through post-incident learning, including the relationship between mitigation and recovery.

2. Discuss how role separation improves coordination during a high-severity incident.

3. Explain the purpose, evidence, and limitations of an operational readiness review.

4. Analyse the relationship between communication quality, customer impact, and organisational trust.

5. Describe how a blameless post-incident review can produce accountability without creating a culture of fear.

Analytical / Application Questions

1. A service has frequent alerts, unclear ownership, and a runbook that has never been tested. Design a prioritised improvement plan and justify the order of actions.

2. During a regional outage, the cause is uncertain but customer impact is increasing. Explain how you would classify, escalate, command, communicate, and mitigate the incident.

3. Analyse the Nimbus Retail case and propose two additional controls that would reduce either the probability or impact of a similar failure.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes an incident from an alert?

A. An incident is always caused by a security event, whereas an alert is caused by infrastructure.

B. An alert is a signal; an incident requires coordinated action because objectives are threatened.

C. An alert always has higher severity than an incident.

D. An incident is a historical record, whereas an alert is a recovery procedure.

Correct Answer: B. An alert is a signal; an incident requires coordinated action because objectives are threatened.

Question 2

During an uncertain, high-impact incident, which action is generally most appropriate?

A. Delay mitigation until the complete root cause is proven.

B. Make broad irreversible changes immediately.

C. Choose a reversible mitigation, assign an owner, and define verification criteria.

D. Allow every available engineer to investigate independently.

Correct Answer: C. Choose a reversible mitigation, assign an owner, and define verification criteria.

Question 3

What is the primary purpose of the incident commander?

A. To perform every technical diagnostic task personally.

B. To coordinate objectives, priorities, roles, decisions, and communication.

C. To approve all routine software deployments permanently.

D. To replace the service owner after every incident.

Correct Answer: B. To coordinate objectives, priorities, roles, decisions, and communication.

Question 4

Which condition most strongly supports escalating an incident?

A. The responder has already formed a confident hypothesis.

B. The impact is expanding and diagnosis remains uncertain.

C. The incident affects only a test environment with no users.

D. A runbook exists for the affected service.

Correct Answer: B. The impact is expanding and diagnosis remains uncertain.

Question 5

Which item is most important in a safe operational runbook?

A. A long description of the organisation’s history.

B. Unverified commands copied from an old incident.

C. Prerequisites, safety checks, recovery actions, verification, and rollback instructions.

D. A requirement that only its author may use it.

Correct Answer: C. Prerequisites, safety checks, recovery actions, verification, and rollback instructions.

Question 6

Why should incident communications state what is unknown?

A. To avoid recording any facts until the incident ends.

B. To make the organisation appear less responsible.

C. To prevent speculation from being presented as fact and establish realistic expectations.

D. To eliminate the need for technical investigation.

Correct Answer: C. To prevent speculation from being presented as fact and establish realistic expectations.

Question 7

Which evidence would be most relevant to an operational readiness review?

A. The popularity of the development team’s internal chat channel.

B. Tested rollback procedures, ownership, observability, recovery evidence, and on-call readiness.

C. The number of lines of code in the service.

D. The seniority of the person who requested production access.

Correct Answer: B. Tested rollback procedures, ownership, observability, recovery evidence, and on-call readiness.

Question 8

In the Nimbus Retail case, why was separating application and dependency error signals important?

A. It would eliminate the need for customer communication.

B. It would help distinguish malformed application requests from payment-provider failures.

C. It would ensure every incident received the lowest severity.

D. It would prevent all future deployment defects.

Correct Answer: B. It would help distinguish malformed application requests from payment-provider failures.

Question 9

Which practice best reduces cognitive load during a major incident?

A. Requiring every responder to monitor every available dashboard.

B. Keeping roles, decisions, timestamps, objectives, and key information visible.

C. Discouraging written notes to preserve speed.

D. Changing the incident channel repeatedly to reduce message volume.

Correct Answer: B. Keeping roles, decisions, timestamps, objectives, and key information visible.

Question 10

What is the central idea of a blameless post-incident review?

A. No action or decision may ever be criticised.

B. The review should examine system conditions and decision context rather than reducing failure to personal blame.

C. Only automated systems should be investigated.

D. All incidents should be attributed to process documentation.

Correct Answer: B. The review should examine system conditions and decision context rather than reducing failure to personal blame.