DEEN
Discuss a project
Menu

How we work on incidents, changes and patches

For every incident, change, problem and patch, you should know who is responsible and what happens next. That is why we follow the ITIL® framework.

Incidents: incident management

Every incident has one owner, from alert to reportITIL® practice: incident management, simplifiedEvery incident has one owner, from alert to reportITIL® practice: incident management, simplifiedCustomerMonitoringEngineerTeamReportAlertLog theincidentPrioritiseP1 to P4Status updateto customerP1/P2: per SLADiagnose &workaroundresolved?Swarm:add expertsnoFixconfirmedyesRecurring?→ problem mgmt.

Move the mouse over a step or tap it. What happens before it and what comes after stays highlighted.

Every incident has one owner, from the report or alert to the confirmed fix.
Every incident has one owner, from the report or alert to the confirmed fix.
An incident, from logging to reviewIncident management
Logged
In progressChange
ResolvedPatch
ReviewProblem
P2Incident

Either you report an incident or our monitoring raises an alert. An engineer logs it, sets the priority and sends you a first status update. Next comes the diagnosis, and where needed a workaround that gets your system running again.

If that is not enough, more people from the team join in. The incident stays open until the fix is confirmed. Should the same incident come back, problem management takes over.

Priorities: impact and urgency

Priorities run from P1 to P4 and follow from an incident’s impact and urgency. P1 means production is down, or data or security is at risk. Together with your service level, the priority sets the response time. The service levels page explains what we count as a response and which response times apply at each level.

Impact × urgency sets the response timeITIL® practice: incident management · priority · response means an engineer is on itImpact × urgency sets the response timeITIL® practice: incident management · priority · response means an engineer is on itUrgencyImpacthighmediumlowhighmediumlowP1P2P3P2P3P4P3P4P4Response time per service tierBasicBusiness24/7CoverageMon to Fri8 to 17Mon to Fri7 to 20P1: 24/7P14 h¹1 h¹on requestP2+1 working day4 h¹4 h¹¹ within service hours; 24/7: P1 around the clockP1 Production down or security at riskP2 Major function degradedP3 Degraded, workaround existsP4 Request or minor defect

Move the mouse over a cell or tap it. Below it says what the priority means and how fast we respond.

Impact and urgency set the priority and with it the response time.
Impact and urgency set the priority and with it the response time.

Changes: change enablement

Every change to your system counts as a change. How fast we roll it out depends on the risk. There are three paths:

  • Standard changes come up again and again and carry little risk. They follow a template approved in advance and need no individual approval.
  • For a normal change we assess the risk, plan the rollback and obtain approval from the change authority.
  • When someone has to act at once, we get a fast approval for the emergency change and do the review and documentation afterwards.

Standard and normal changes go in during the agreed maintenance window. Afterwards we check the result and update the configuration in our documentation.

Three paths for a change: speed follows riskITIL® practice: change enablementThree paths for a change: speed follows riskITIL® practice: change enablementNeedChangerequestStandardNormalEmergencyTemplate,approved upfrontno individual approvalImplement inthe windowAssess risk,plan rollbackApproval bychange authorityImplement inthe windowFast approval,implement nowreview followsDocumentafterwardsVerify &updateconfiguration

Move the mouse over a step or tap it. What happens before it and what comes after stays highlighted.

Three paths for a change, faster or slower depending on the risk.
Three paths for a change, faster or slower depending on the risk.

Causes: problem management

Behind every symptom there is a cause, and problem management goes looking for it. It starts from recurring incidents, monitoring trends or vendor advisories.

First we look for patterns in incidents and trends, which ITIL calls problem identification. Problem control is where we analyse the cause and record a workaround. Last comes error control, where we assess and plan the permanent fix.

Known errors go into our knowledge base together with their workaround, so the next incident takes less time. We plan the permanent fix as a change.

Fix the cause once instead of the symptom every timeITIL® practice: problem managementFix the cause once instead of the symptom every timeITIL® practice: problem managementRecurringincidentsMonitoringtrendsVendoradvisoriesProblem identificationFind patterns inincidents and trendsProblem controlAnalyse the cause,record a workaroundError controlAssess and planthe permanent fixKnown error+ workaroundChange requestfor the permanent fix→ incident managementand the knowledge base→ change enablement

Move the mouse over a step or tap it. What happens before it and what comes after stays highlighted.

From a recurring incident to a permanent fix of the cause.
From a recurring incident to a permanent fix of the cause.

Patches and end of support

It starts with our inventory of what runs where, in which version. Against that inventory we track end of support dates and vulnerabilities. When something is due, we assess the risk, plan the change and roll it out, then test that everything works. This repeats at a fixed cadence. Every round ends with evidence in the report.

Critical patches go in out of turn. Which versions fall out of support and when is in our EOL calendar, and the patch window cadence per service level is on the service levels page.

Patching is a loop, not a projectLifecycle and patch management with ITIL® practicesPatching is a loop, not a projectLifecycle and patch management with ITIL® practices1 InventoryWhat runs where, which versionService configuration mgmt.2 WatchEOL calendar, CVE advisoriesIT asset management3 AssessRisk and urgencyInformation security mgmt.4 PlanChange, maintenance windowChange enablement5 Roll out & verifyDeployment, functional testDeployment management6 ProveReport, NISG § 32Service level managementFixed cadenceevery round ends with evidencecritical: out of cycle

Move the mouse over a step or tap it. The step before and the one after stay highlighted.

We keep the inventory, watch end of support dates, assess the risk, plan the change, roll it out and record it in the report. Then the next round starts.
We keep the inventory, watch end of support dates, assess the risk, plan the change, roll it out and record it in the report. Then the next round starts.

In ITIL terms, the inventory belongs to service configuration management and IT asset management, the assessment to information security management, the rollout to change enablement and deployment management, and the report to service level management.

Monitoring and event management

Our monitoring collects events from uptime checks, logs and metrics, and from cron jobs and imports. Every event belongs to one of three types:

  • Informational events go into the log, and nobody needs to act.
  • Warnings get an automatic fix where possible. If they repeat, we open a ticket.
  • An exception becomes an incident with a priority.

If a job stops reporting, we treat the missing signal as an exception. That is how we catch jobs that silently stopped running months ago.

Silence is an event, tooITIL® practice: monitoring and event management · three event typesSilence is an event, tooITIL® practice: monitoring and event management · three event typesUptime checksLogs & metricsCron jobs & importsHeartbeat missingDetect andfilter eventsType?InformationalWarningExceptionLog it,no actionFix automatically,ticket if repeatedRaise incident,set priorityEngineerpagedmissing signal = exceptionA missing signal is treated like a failure. That is how we catch jobs that silently stopped running months ago.

Move the mouse over a step or tap it. What happens before it and what comes after stays highlighted.

Three types of event. A missing signal counts as an exception.
Three types of event. A missing signal counts as an exception.

Who is responsible

Maintenance and operations are the job of our solutions architect. He holds the ITIL Expert Certificate in IT Service Management and the ITIL 4 Managing Professional, both personal certifications rather than company ones. You can verify them in the PeopleCert register. More about the team is on the about page.

Why we work with ITIL practices

Incident, change and problem have fixed names and boundaries in the ITIL framework. When we say change, your team and your auditors mean the same thing. ITIL prescribes no notation for diagrams; ours use the names of the ITIL practices. Version 5 of the ITIL framework has been current since early 2026. We only use practice names that are the same in versions 4 and 5.

ITIL® is a registered trade mark of PeopleCert group.