Topics in this domain
- IT Service Management
- Hardware Components and Architecture
- Operating Systems
- OSI Model
- TCP/IP and Common Protocols
- Network Devices: Switches, Routers, Gateways
- LAN/WAN Topologies
- Database Models and DBMS
- Database Controls and Normalization
- Asset Management
- Configuration Management
- Job Scheduling and Batch Processing
- Incident Management
- Problem Management
- Change Management
- Release and Patch Management
- Service Level Management
- Capacity and Performance Monitoring
- End-User Computing
- BCP Lifecycle
- Business Impact Analysis
- RTO, RPO, MTD, SDO
- Recovery Strategies
- Alternate Sites: Hot, Warm, Cold
- Backup Types: Full, Incremental, Differential
- Backup Storage and Rotation
- DRP Contents
- Testing BCP/DRP
- High Availability, RAID, Insurance
- Auditing BCP
IT Service Management
IT as a service business
Think of a hotel. Guests call one number: reception. Reception logs the request, fixes what it can, and passes the rest to housekeeping, maintenance or the kitchen. Behind the scenes each team has its own process, and the manager tracks how quickly guests are looked after.
IT service management (ITSM) runs IT the same way: as a provider of services to the business, each with agreed quality levels. Frameworks such as ITIL and ISO/IEC 20000 describe the processes; COBIT’s DSS and BAI domains give auditors the criteria.
The service desk
The service desk is reception: the single point of contact between users and IT. It:
- logs every incident and service request
- classifies and prioritises them
- resolves what it can at first line and escalates the rest
- tracks progress and keeps users informed
- closes tickets only once the user confirms the problem is fixed
Logging everything matters. Incidents fixed informally (“just a quick favour”) can’t be analysed for trends or root causes, and SLA reports become unreliable.
The service desk also shouldn’t grant access or make changes without the normal approvals, however urgent the caller sounds.
Setting priority
Priority comes from two things:
- impact: how many users, and how critical the service
- urgency: how quickly it starts to hurt
It doesn’t come from who shouts loudest or who’s most senior.
The core processes
| Process | Purpose |
|---|---|
| Incident management | Restore normal service as quickly as possible |
| Problem management | Find and remove the root causes of incidents |
| Change management | Make sure changes are authorised, tested and implemented safely |
| Release management | Plan and deploy approved changes into production |
| Configuration management | Keep accurate records of IT components and how they relate (the CMDB) |
| Service level management | Agree, monitor and report on service levels |
| Capacity and availability management | Meet current and future demand and uptime targets |
| IT service continuity | Recover services after major disruptions |
| Service request management | Handle standard requests such as password resets and new equipment |
Each has its own article. The point here is that they feed each other: problem management analyses incident data; change management uses the CMDB to judge impact; release management deploys what change management approved. Weak data in one process weakens the others.
Auditing ITSM
- Are the processes documented, with clear roles and tools?
- Is everything logged? Compare incident counts with monitoring alerts or user surveys.
- Are priorities set consistently, using a defined matrix?
- Are SLAs met, and are the reports accurate?
- Are repeat incidents linked to problem records, and fixes to change records?
Example. The service desk reports 98% of incidents resolved within target. The auditor finds that technicians often close tickets and open new ones when the deadline approaches, which resets the clock. Real performance is much lower than reported.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Single point of contact for IT users | Service desk |
| How incident priority is determined | Impact and urgency |
| Why all incidents must be logged | Enables trend analysis, problem management and SLA measurement |
| Process that maintains information about IT components | Configuration management |
In short
- IT service management (ITSM) delivers IT as a set of services that meet agreed business requirements.
- The service desk is the single point of contact for users: it logs, classifies, prioritises and routes incidents and requests.
- Core processes: incident, problem, change, release, configuration, service level, capacity, availability and continuity management.
- Processes depend on each other; for example, problem management relies on accurate incident data and the CMDB.
- Every ticket should be logged, so trends can be analysed and SLAs measured.
- The auditor reviews whether processes are defined, followed, measured and improved.
Exam traps
- Incidents resolved informally without a ticket undermine trend analysis and problem management.
- The service desk shouldn't grant access or make changes without the normal approvals.
- Priority is based on impact and urgency, not on who complains loudest.
- Closing tickets without user confirmation inflates performance metrics.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The service desk and its processes
Setting priority