1 Incident, Problem, Change & Service Request
Ticket management in large enterprises is commonly influenced by ITIL practices. You don't need to memorise every ITIL term, but these four categories are not interchangeable:
- Incident — an unplanned interruption or degradation of a service (VPN unavailable, authentication failing, a certificate expired). The immediate objective is to restore service; finding the underlying cause can happen later.
- Problem — the underlying cause of one or more incidents. If VPN authentication fails on Monday, Wednesday and Friday, and investigation finds a memory leak in the authentication server, that recurring issue becomes a problem record (e.g.
PRB0004712) with the objective of eliminating the cause, not just responding to each occurrence. - Change — a controlled modification to the environment: a firewall rule, a software upgrade, a certificate replacement, a DNS change. Most organisations require formal approval before a production change (e.g.
CHG0018823) goes ahead in a defined maintenance window. - Service request — a standard user request rather than a fault: create a user account, reset a password, request VPN access, provision a mailbox. These usually follow predefined workflows rather than an investigation.
2 SLAs: Response vs. Resolution
An SLA (Service Level Agreement) defines expectations for providing a service — response time, resolution target, availability, support hours, escalation requirements. A typical (illustrative) table:
| Priority | Response Target | Resolution Target |
|---|---|---|
| P1 Critical | 15 minutes | 4 hours |
| P2 High | 1 hour | 8 hours |
| P3 Medium | 4 hours | 3 business days |
| P4 Low | 1 business day | 5 business days |
Every organisation defines these differently — treat the table as an example, not a standard. The important distinction is that response and resolution are different clocks: if a P1 is reported at 10:00 with a 15-minute response target and the engineer replies at 10:10, the response SLA is met — but if the issue remains unresolved six hours later against a four-hour resolution target, the resolution SLA is still breached, even though you responded on time.
SLA clocks may also pause under certain conditions — for example while waiting for customer logs — but never assume a clock pauses just because a ticket is sitting in a pending state; different contracts implement this differently, and it's worth confirming rather than guessing. Larger enterprises may also define an OLA (Operational Level Agreement) between internal teams, separate from the customer-facing SLA — e.g. a customer SLA promising a P1 response within 30 minutes, backed by an internal OLA requiring SOC to acknowledge an escalation within 10 minutes.
3 Priority = Impact + Urgency
Priority is one of the most misunderstood ticket fields. It should represent impact plus urgency — not "the customer is angry." A customer writing "URGENT!!!" does not automatically make something a P1.
Impact describes how much of the organisation is affected — one user, one department, one region, the entire company, all customers, or one critical production service. Urgency describes how quickly the problem must be resolved — the payroll system being unavailable one hour before payroll processing is high urgency; the payroll test environment being unavailable with testing scheduled next week is low urgency, even though the technical fault might be identical. A typical impact/urgency matrix:
| Impact | Urgency | Priority |
|---|---|---|
| High | High | P1 |
| High | Medium | P2 |
| Medium | High | P2 |
| Medium | Medium | P3 |
| Low | Low | P4 |
Naming schemes vary — P1–P4, Critical/High/Medium/Low, or Severity 1–4 — but the underlying logic is usually this same two-axis model.
4 Priority vs. Severity, and What Makes a P1
Priority and severity are not the same thing. Severity describes technical seriousness; priority describes business urgency. A severe software bug in a feature nobody currently uses might be Severity: High, Priority: Low. A bug with low technical complexity that breaks every customer's login might be Severity: Moderate, Priority: Critical.
Which of these is more likely to justify a P1: "10 users unable to reset passwords," or "150,000 employees cannot authenticate"?
Reveal the answer
The second. Typical P1 scenarios involve a complete production outage, critical authentication unavailability, large-scale customer impact, a major security incident, payment processing unavailable, critical infrastructure failure, large-scale data access failure, or severe business disruption. Ten users unable to reset a password is real impact, but it's narrow enough that it's very unlikely to justify a P1 on its own.
5 Security Priority Can Be Different
Security incidents don't always follow traditional availability-based priority models. "No production outage" does not mean "low priority." Consider: an attacker successfully authenticating as an administrator. The system may still be completely available — but the security impact is critical. Security teams weigh confidentiality, integrity, availability, data sensitivity, attacker access, privilege level, persistence, scope, and regulatory exposure, and any one of those can outweigh "nothing is technically down" (Module 12 covers this from the incident-response side in depth).