Historical Context & Motivation
The discipline of incident and problem management did not spring from information technology alone; it evolved at the intersection of enterprise risk management, audit standards, and the growing dependence of financial reporting on complex IT environments. In the 1970s and 1980s, mainframe-era organizations handled system failures in an ad hoc fashion—technicians fixed things as they broke, with limited documentation. As the Sarbanes-Oxley Act of 2002 (SOX) imposed rigorous internal-control requirements on publicly traded companies, it became clear that uncontrolled IT disruptions could compromise financial statement reliability. CPA auditors, already evaluating internal controls over financial reporting (ICFR), had to extend their assessments into the information systems domain, making structured incident and problem management a cornerstone of IT general controls (ITGCs).
The central question for CPA candidates is therefore not merely technical—how does an IT department fix a server outage?—but rather evaluative: Are the organization's processes for detecting, recording, escalating, resolving, and learning from IT disruptions designed and operating effectively enough to safeguard the integrity of financial data? This lesson equips you to answer that question with the analytical rigor expected on the CPA ISC examination.
Core Principles & Definitions
Before evaluating incident and problem management controls, a CPA must command precise definitions. The terms incident and problem are related but distinct. An incident is any unplanned interruption to an IT service or a reduction in the quality of an IT service—think of a payroll application crashing on payroll-processing day. A problem is the underlying, often unknown, root cause of one or more incidents—in our example, perhaps the payroll application crashed because a recent database patch introduced a memory leak. Incident management aims to restore normal service as quickly as possible, while problem management seeks to identify and eliminate root causes so that incidents do not recur.
Incident Management
Problem Management
Known Error Database (KEDB)
Service Level Agreements (SLAs)
Escalation Procedures
Visual Explanation — The Incident & Problem Management Lifecycle
As the diagram illustrates, incident and problem management are parallel but interconnected processes. The CPA evaluator's role is to assess each stage for the presence of adequate controls: Is every incident logged automatically or is there discretion that allows gaps? Are priority levels assigned using a documented matrix rather than subjective judgment? Are escalation thresholds defined and enforced? Does root cause analysis follow a structured methodology such as the Ishikawa (fishbone) diagram or the Five Whys technique? Each of these questions maps directly to a testable control objective.
How It Works — The Evaluation Framework
While incident and problem management are not primarily mathematical disciplines, the CPA evaluator relies on quantitative metrics and qualitative control assessments to determine whether these processes are operating effectively. Several key performance indicators (KPIs) underpin the evaluation, and understanding how they are computed allows the auditor to identify control deficiencies with precision.
Beyond metrics, the CPA evaluator applies a controls-based evaluation framework that mirrors the general approach to testing IT general controls. The evaluator first identifies the relevant control objectives from a recognized framework (such as COBIT DSS02 and DSS03), then assesses control design by reviewing policies, procedures, and system configurations. Finally, the evaluator tests operating effectiveness by examining a sample of incident and problem records, verifying that documentation is complete, escalation protocols were followed, and resolutions were applied within SLA windows. Any gap between the stated policy and actual practice constitutes a control deficiency, which is then assessed for severity—ranging from a simple deficiency through a significant deficiency to a material weakness, depending on the likelihood and magnitude of financial misstatement that could result.
Detailed Breakdown — Incident Severity & Priority Matrix
A well-designed incident management process classifies every incident along two dimensions: impact (the breadth and business significance of the disruption) and urgency (how quickly the business requires a resolution). The intersection of these two dimensions determines the priority level, which in turn governs SLA targets, resource allocation, and escalation paths. A CPA evaluating incident management must verify that this matrix exists, is consistently applied, and aligns with the organization's risk tolerance—particularly for incidents affecting financially significant applications such as the general ledger, accounts payable/receivable, and treasury management systems.
| Priority | Example Scenario | Financial Reporting Impact |
|---|---|---|
| P1 – Critical | ERP general ledger module down during month-end close | Direct: journal entries cannot be posted, closing delayed, potential for misstated period-end balances |
| P2 – High | Accounts payable batch processing fails for one supplier | Moderate: delayed payments, accrual misstatement, potential vendor relationship issues |
| P3 – Medium | Reporting dashboard intermittently slow | Indirect: management review controls hampered, but underlying data integrity preserved |
| P4 – Low | Single user unable to access training environment | Minimal: no impact on production financial data or processing |
Worked Example — Evaluating Incident Management at Zeta Corp
Consider Zeta Corp, a publicly traded manufacturing firm whose financial statements are subject to an integrated audit. You are a CPA evaluating IT general controls. During your review of Zeta Corp's incident management process for the fiscal year ended December 31, you obtain the following data from the IT service management (ITSM) system: 1,200 total incidents logged; 1,020 resolved within SLA targets; 180 that breached SLA; 60 P1-Critical incidents, of which 48 were resolved within the one-hour SLA window; and 15 incidents that recurred three or more times and were eventually linked to a single known problem (a recurring database timeout). Your task is to evaluate these metrics and determine whether any control deficiencies exist.
Strengths, Limitations, and Framework Comparisons
Evaluating incident and problem management is not a one-size-fits-all exercise. CPAs encounter organizations that follow different frameworks, and each has distinct strengths and limitations. Understanding these trade-offs helps the evaluator calibrate expectations and tailor testing procedures to the organization's specific maturity level.
| Framework / Approach | Strengths | Limitations |
|---|---|---|
| ITIL (v3/v4) | Comprehensive, widely adopted, separates incident and problem management clearly, supports SLA-based measurement, extensive guidance on escalation and knowledge management | Can be overly bureaucratic for small organizations; implementation is expensive; does not directly map to financial audit assertions without interpretation |
| COBIT (DSS02/DSS03) | Directly aligned with IT governance objectives; maps to COSO and SOX control requirements; provides maturity models for benchmarking; audit-oriented design | Less prescriptive on implementation details; assumes the organization has chosen a complementary operational framework (e.g., ITIL) |
| ISO/IEC 20000 | International standard, certifiable, provides formal requirements (not just best practices), strong emphasis on documented procedures | Certification process is costly; smaller firms may find compliance burden disproportionate; less widespread in North American enterprises compared to ITIL |
| Ad Hoc / Informal | Low overhead, flexible, may be sufficient for very small IT environments with limited complexity | Poor auditability, inconsistent documentation, high person-dependency risk, difficult to demonstrate control effectiveness to external auditors |
Connection to Advanced Theory — IT Governance, Risk, and Assurance
Incident and problem management do not exist in isolation. They are embedded within a broader IT governance, risk, and compliance (GRC) ecosystem. Advanced topics that build upon the foundational concepts in this lesson include IT service continuity management (ITSCM), which addresses disaster recovery and business continuity at a strategic level; change management, which is the formal process through which permanent fixes identified by problem management are safely deployed into production; and configuration management, which maintains an accurate record of IT assets and their relationships, enabling faster incident diagnosis. For CPA candidates pursuing deeper expertise, understanding how these processes interact is essential for evaluating enterprise-level controls.
| This Lesson: Incident & Problem Management | Advanced Extension |
|---|---|
| Incident detection and logging | Security Information and Event Management (SIEM) for automated detection; integration with cybersecurity incident response plans |
| Root cause analysis in problem management | Trend analysis and predictive analytics using machine learning to anticipate incidents before they occur (AIOps) |
| Permanent fix via Request for Change (RFC) | Formal change management processes (COBIT BAI06); integration with DevOps CI/CD pipelines for automated deployment |
| SLA-based performance measurement | Service level management and IT balanced scorecards aligned with enterprise KPIs and board-level risk reporting |
| Control deficiency classification | Integrated assurance models combining ITGC testing with SOC 1/SOC 2 reporting for service organizations |
As organizations increasingly adopt cloud-based financial systems, the locus of incident and problem management shifts from internal IT departments to third-party service providers. In such environments, the CPA must evaluate whether the organization obtains and reviews SOC 2 Type II reports from its cloud providers, which include detailed assessments of the provider's incident management controls. This evolution represents the frontier of the topic and is increasingly relevant on the CPA ISC examination.
Practice Problems
Lesson Summary
Evaluating incident management and problem management is a core competency for CPA candidates in the ISC domain. Incident management focuses on rapid service restoration through detection, logging, categorization via the impact × urgency priority matrix, escalation, and resolution within SLA targets. Problem management complements this by performing root cause analysis to eliminate recurring incidents and maintain the Known Error Database (KEDB). Key quantitative metrics—the Incident Resolution Rate, Mean Time to Resolve, and Recurrence Rate—provide auditable evidence of control effectiveness.
The CPA evaluator distinguishes between deficiencies in design (missing policies or matrices) and deficiencies in operating effectiveness (policies that exist but are not consistently followed). Frameworks such as ITIL and COBIT provide complementary lenses—COBIT defines control objectives aligned with SOX and COSO, while ITIL provides implementation guidance. In modern cloud environments, the evaluation extends to reviewing SOC 2 Type II reports from service providers and verifying that complementary user entity controls are in place. The ultimate objective is to ensure that IT disruptions do not compromise the integrity of financial reporting.