Problem Management Procedure

1. Introduction

A problem is the cause, or the suspected cause, of one or more incidents. Incident management restores service; problem management finds out why it failed, removes that cause where it is worth doing so, and keeps users working in the meantime through documented workarounds.

This procedure covers reactive work, which starts from incidents, and proactive work, which starts from trends, monitoring and review findings before users are harmed. It works with the Problem Management Policy and Process of the information security management system, which sets the security view of recurring weaknesses.

2. Purpose

This procedure reduces the number and impact of incidents by identifying their causes, recording what is known about them, and following each problem to a permanent fix, an accepted risk, or a recorded decision not to act. It makes sure that effort goes to the problems that matter most, that investigations use proven methods, and that what is learned reaches the people who handle the next incident.

3. Objectives

• Open a problem record for every major incident, every cause that recurs [three] times in [30 days], and every trend that crosses a threshold.
• Complete root cause analysis within the target for the problem priority, and record the cause in a way that others can verify.
• Maintain a known error database in which every open known error has a tested workaround or a stated reason why none exists.
• Resolve problems through the Change Management Procedure and verify that the incident count falls afterwards.
• Reduce repeat incidents on the same cause by [20%] each year.
• Close no problem without evidence that the cause is removed, or without a decision signed by the service owner.

4. Scope

• In scope: problems affecting any service in the service catalogue, whether the cause lies in infrastructure, applications, processes, people, documentation or suppliers.
• In scope: proactive analysis of incident trends, monitoring data, audit findings and customer complaints.
• Out of scope: restoring service (see the Service Incident Management Procedure) and carrying out the fix, which is a change.
• Applies to: the problem manager, service desk, resolver groups, service owners, the change authority, and suppliers who own a cause.

5. Terms and definitions

6. Roles and Responsibilities

7. Problem Management Process

7.1 Inputs and outputs

7.2 Identifying problems

Problems are identified by six routes. The problem manager reviews the list weekly and may open a record on judgement as well as on a rule.

7.3 Logging

1. Create the recordThe problem manager opens a problem record in [the ticketing tool] with a clear title that names the symptom and the service, not a guess at the cause.
2. LinkAll related incidents, changes, alerts and configuration items are linked. The number of incidents and the total user hours lost are recorded.
3. Search the known error databaseIf a known error matches, the problem is linked to it. If its workaround has not worked, the problem is raised in priority.
4. AssignA problem owner is named within [2 business days]; a problem with no owner may not be classified as closed or as deferred.

7.4 Classification and prioritisation

Problems are classified by category, using the incident categories, and by origin: application, infrastructure, process, supplier, design or human factor. Priority is set from the effect and the frequency of the incidents it causes, and from the risk if it is not resolved.

7.5 Root cause analysis

The problem owner selects a method to fit the problem and records it, with the evidence used. The method is chosen for the type of failure; complex problems often use more than one.

1. Plan the analysisThe problem owner sets the questions, the data to collect, the people to involve and the date of the findings meeting.
2. Gather evidenceLogs, configuration history, change records, test results and supplier reports are collected and kept with the record. Where personal data or security evidence is involved, handling follows the Information Security Management for Services procedure.
3. Find the causeThe method is applied, hypotheses are tested, and the cause is recorded with evidence that proves it. A suspected cause is labelled as suspected.
4. ReviewThe problem manager and one person who was not part of the analysis review the findings for gaps before the cause is accepted.

7.6 Known errors and workarounds

A problem becomes a known error when its root cause is identified, or when a workaround is found that can reduce the effect of the incidents even if the cause is not yet known. Every known error is entered in the known error database.

• The problem manager tests the workaround with a resolver group before publishing it; an untested workaround is labelled as such.
• Analysts must check the known error database before diagnosing an incident, and link the incident to the known error when it matches.
• A workaround that needs elevated access is applied by the resolver group, not the service desk.
• Known errors are reviewed every [3 months]; those with no fix after [12 months] are put to the service owner for a decision to fix or accept.

7.7 Resolution through change

1. Propose the fixThe problem owner writes the proposed fix, its cost, its risk, and the effect on incidents if it is not done.
2. DecideThe service owner decides to fix, to defer to a named date, or to accept the risk. A decision to accept is recorded with the person's name and expires after [12 months].
3. Raise a changeThe problem owner raises a request for change under the Change Management Procedure, linked to the problem, and requests priority where the problem is Critical or High.
4. Implement and releaseThe fix is built, tested and released through the Release and Deployment Management Procedure.
5. VerifyAfter the fix, the problem manager watches the linked incident category for [30 days] or [one full business cycle]. If the incident recurs, the problem is reopened.

7.8 Closure

1. Check the evidenceThe problem manager checks that the cause is documented, the fix was released and verified, the known error is updated or closed, and linked incidents are annotated.
2. ApproveThe service owner signs the closure for Critical and High problems. For Medium and Low problems the problem manager may close with the problem owner's agreement.
3. Share lessonsThe problem manager adds the lessons learned to knowledge articles, change models, training notes or monitoring rules, and records where this was done.
4. RecordThe record is closed with a closure code: fixed, risk accepted, no cause found, or suspended with review date.

7.9 Process flow

1. A source (major incident, repeat incident, trend, monitoring, supplier or review) shows a possible problem.
2. The problem manager logs the problem, links incidents and checks the known error database.
3. The problem is classified, prioritised and given a problem owner.
4. The owner performs root cause analysis and the findings are reviewed.
5. If the cause or a workaround is known, a known error record is entered and published.
6. The service owner decides on a permanent fix, deferral or acceptance of the risk.
7. The fix goes through change management and release management.
8. The problem manager verifies that incidents have fallen, closes the problem and shares lessons.
9. Open problems and known errors are reviewed on their schedule and reported monthly.

8. Interfaces with Other Processes

9. Key Performance Indicators

10. Records and Evidence

Annexure A: Problem record

Annexure B: Root cause analysis report

Annexure C: Known error record

Annexure: Document history

11. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

12. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

13. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 20000-1:2018 references

Related documents

• Problem Management Policy and Process
• Service Incident Management Procedure
• Change Management Procedure
• Configuration and Asset Management Procedure
• Service Level Management Procedure
• Service Operating Model
• Release and Deployment Management Procedure
• Availability and Service Continuity Management Procedure