IT service management and ITIL

In short

IT service management (ITSM) is the discipline of planning, delivering, supporting and improving IT as a service to business users, rather than managing technology boxes in isolation. ITIL (originally the IT Infrastructure Library, now simply "ITIL", current edition ITIL 4) is the world's most widely used ITSM framework — a set of good-practice guidance, not a certifiable standard; the certifiable standard is ISO/IEC 20000-1:2018. The topic is examined in university papers on IT infrastructure management, software project management and IT service management electives, and it is the single most asked non-coding area in interviews for Indian IT services firms — TCS, Infosys, Wipro, HCLTech, Tech Mahindra, Cognizant, Capgemini, Accenture and LTIMindtree — where fresher roles start in a service desk, NOC or application-support team. Fresher induction at these firms often includes an ITIL 4 Foundation certification.

Explained

Service, value and the ITSM vocabulary

• Service: a means of enabling value co-creation by facilitating outcomes customers want, without the customer owning all the costs and risks. "Email for 40,000 staff at 99.9% availability" is a service; a mail server is not.
• Utility vs warranty: utility = *fit for purpose* (what it does); warranty = *fit for use* (how well — availability, capacity, continuity, security). A service needs both to deliver value.
• Value = outcomes + utility + warranty, weighed against cost and risk. Output is what the service produces; outcome is the result for the customer.
• Service provider types: internal (captive IT/shared-services unit), external (a vendor such as TCS or Wipro), and shared services.
• Four dimensions of service management (ITIL 4): (1) organisations and people, (2) information and technology, (3) partners and suppliers, (4) value streams and processes. All four must be covered or the service is unbalanced.
• Cost vs charge, risk, asset, configuration item (CI), service asset: a CI is anything under configuration control; an asset is anything of financial value.

ITIL v3 service lifecycle (still the exam backbone)

Many Indian syllabi and question papers still follow the five-stage ITIL v3 / 2011 lifecycle, so both editions should be known.

1. Service strategy — who the customer is, which services to offer, the business case. Processes: strategy management, service portfolio management, financial management (budgeting, accounting, charging), demand management, business relationship management.
2. Service design — designing new or changed services and the Service Design Package (SDP). Processes: service level management, availability, capacity, IT service continuity, information security, supplier management, design coordination, service catalogue management. The four Ps of design: people, processes, products, partners.
3. Service transition — moving a design safely into live use. Processes: change management, release and deployment, service asset and configuration management (SACM), knowledge management, validation and testing, change evaluation, transition planning.
4. Service operation — day-to-day delivery. Processes: incident, problem, event, request fulfilment, access management; functions: service desk, technical management, application management, IT operations management.
5. Continual service improvement (CSI) — the 7-step improvement approach and the Deming PDCA cycle (Plan-Do-Check-Act).

ITIL 4 structure: SVS, service value chain, guiding principles

• Service Value System (SVS): how all components fit together — inputs (demand and opportunity) → guiding principles, governance, service value chain, practices, continual improvement → output (value).
• Service value chain — six activities: Plan, Improve, Engage, Design & Transition, Obtain/Build, Deliver & Support. They are not a fixed sequence; different value streams combine them in different orders.
• Seven guiding principles: focus on value; start where you are; progress iteratively with feedback; collaborate and promote visibility; think and work holistically; keep it simple and practical; optimise and automate.
• 34 practices in three groups: general management (14, e.g. continual improvement, risk, information security, project management), service management (17, e.g. incident, problem, change enablement, service desk, SLM, monitoring), technical management (3: deployment, infrastructure & platform, software development & management). "Process" of v3 became "practice" in ITIL 4.
• ITIL 4 drops the rigid lifecycle and explicitly aligns with Agile, Lean and DevOps ways of working.

Core operational practices in detail

• Incident: an unplanned interruption or reduction in quality of a service. Goal of incident management: restore normal service as quickly as possible — a workaround is a perfectly acceptable fix.
• Incident flow: identification → logging → categorisation → prioritisation (impact × urgency) → initial diagnosis → functional escalation (L1 service desk → L2 → L3/specialist) or hierarchic escalation (to management) → investigation → resolution → recovery → closure (with user confirmation).
• Major incident: highest-impact category, handled by a separate procedure with a major-incident manager and a bridge call; a war room / crisis bridge is common Indian practice.
• Problem: the cause, or potential cause, of one or more incidents. Problem management finds the root cause (RCA using 5 Whys, Ishikawa/fishbone, Kepner-Tregoe, Pareto), records a known error with a workaround in the Known Error Database (KEDB), then raises a change to remove it permanently.
• Change enablement (v3: change management): maximise successful changes by assessing risk, authorising and scheduling. Types: standard (pre-authorised, low risk, e.g. password reset tooling), normal (assessed and authorised by a Change Advisory Board / CAB), emergency (ECAB, minimal paperwork, documented after). Artefacts: RFC, change schedule (CAB calendar), backout/rollback plan, PIR (post-implementation review), freeze window (common around Indian financial year-end, 31 March, and festive peaks).
• Release and deployment: release unit, big-bang vs phased, push vs pull, blue-green and canary deployments; releases go through the DML (Definitive Media Library).
• Service request: a user-initiated, pre-defined, low-risk demand (access, a laptop, information) — handled by request fulfilment against a service catalogue with a published request model; it is *not* an incident.
• Event management: monitoring detects events classified as informational, warning or exception; exceptions may auto-generate incidents.
• Service desk: single point of contact (SPOC) for users. Structures: local, centralised, virtual (followed by most Indian GDCs serving US/EU clients), follow-the-sun (the model behind 24×7 shifts in Bengaluru/Pune/Hyderabad delivery centres).
• SACM and the CMDB: the CMDB stores CIs and, crucially, their relationships; a federated set of CMDBs plus the DML forms the CMS. Used for impact assessment of a change and for RCA.
• Service level management: SLA with the customer; OLA between internal teams; underpinning contract (UC) with an external supplier. SLA types: service-based, customer-based, multi-level (corporate / customer / service).
• Availability, capacity and continuity: availability management works on MTBF, MTRS and MTBSI; capacity management on business, service and component capacity plus demand forecasting; ITSCM on BIA, risk assessment, recovery options (manual workaround, reciprocal, gradual/cold, intermediate/warm, immediate/hot standby) feeding a DR plan with RTO and RPO targets.

Standards, certification and the Indian regulatory setting

• ISO/IEC 20000-1:2018 — the auditable ITSM standard an organisation (not a person) is certified against; ITIL is guidance aligned to it, never "ITIL-certified company".
• Related: ISO/IEC 27001:2022 (information security management, with Annex A controls), ISO 22301 (business continuity), ISO 9001:2026 (quality; succeeded the 2015 edition on 16 September 2026), COBIT 2019 (governance of enterprise IT), CMMI-SVC (service maturity, 5 maturity levels), Six Sigma / Lean for improvement, eSCM-SP for sourcing.
• Individual ITIL 4 certification path: Foundation → Managing Professional (CDS, DSV, HVIT, DPI) / Strategic Leader (DPI, DITS) → Master. Scheme owner PeopleCert (ITIL is an AXELOS/PeopleCert trademark); details and module names are revised periodically, so verify the current scheme before quoting it.
• Indian practice and law: the Information Technology Act, 2000 (with the 2008 amendment) governs electronic records, cyber-contraventions and Section 43A / 72A liability for failure to protect sensitive personal data — directly relevant to service-desk handling of user data. The Digital Personal Data Protection Act, 2023 adds consent, purpose-limitation, breach-intimation and other Data Fiduciary duties; its Rules were notified on 13 November 2025 and these duties apply from 13 May 2027, when s.43A is also omitted from the IT Act — until then s.43A and the SPDI Rules, 2011 apply. CERT-In directions of 28 April 2022 require reporting specified cyber incidents within 6 hours of noticing them and mandate log retention (180 days, within India) and clock synchronisation to NIC/NPL NTP — these obligations sit on top of incident management in every Indian ITSM setup. RBI, SEBI and IRDAI add sector-specific IT governance, outsourcing and incident-reporting norms for BFSI clients. Public IT contracts commonly use MeitY/GeM service-level and penalty templates.
• Service contracts in India are priced in rupees against measured SLAs, with service credits/penalties (often 5–15% of monthly billing at risk) and earn-back clauses.

Benefits, limitations and comparisons

• Advantages: common vocabulary across client and vendor; predictable, auditable delivery; fewer repeat incidents through problem management; clear accountability via SLAs; easier audit for ISO/IEC 20000 and client due-diligence; cost transparency.
• Limitations: can become heavy and bureaucratic ("ticket for everything"); certification of people does not improve a process; v3's process orientation slowed fast release cycles; ITIL tells *what* and *why*, not *how* to configure a tool; metric gaming (closing tickets to meet SLA, "ping-pong" reassignment).
• ITIL vs DevOps/SRE: not rivals — ITIL 4 absorbs flow-based work; change enablement supplies standard pre-authorised changes so a CI/CD pipeline is not blocked by a CAB.

Key points

• ITSM - managing IT as services delivered to customers, end-to-end, not as isolated technology.
• ITIL - best-practice framework (current edition ITIL 4); guidance, adopt-and-adapt, not auditable.
• ISO/IEC 20000-1:2018 - the certifiable ITSM standard for an organisation.
• Utility + warranty - fit for purpose plus fit for use; both needed for value.
• Four dimensions - organisations/people, information/technology, partners/suppliers, value streams/processes.
• Service value chain - Plan, Improve, Engage, Design & Transition, Obtain/Build, Deliver & Support.
• Guiding principles - focus on value; start where you are; iterate with feedback; collaborate and promote visibility; think holistically; keep it simple; optimise and automate.
• Incident - unplanned interruption; aim is fastest restoration, workaround allowed.
• Problem - underlying cause of incidents; aim is permanent removal via RCA and a change.
• Priority = impact × urgency - set from a priority matrix, not from how loudly the user complains.
• Escalation - functional (to higher skill, L1→L2→L3) vs hierarchic (to higher authority).
• Change types - standard (pre-authorised), normal (CAB), emergency (ECAB); every change needs a rollback plan.
• Request fulfilment - pre-approved routine requests from the service catalogue; not incidents.
• CMDB/CMS - CIs and their relationships; the basis of impact assessment and RCA.
• SLA / OLA / UC - customer agreement / internal agreement / external supplier contract.
• Availability metrics - MTBF (reliability), MTRS or MTTR (maintainability/serviceability), MTBSI = MTBF + MTRS.
• CSI 7-step and PDCA - measure, analyse, improve, repeat; Deming's Plan-Do-Check-Act.
• CERT-In 2022 directions - specified cyber incidents reportable within 6 hours; 180-day logs retained in India.

Formulas and examples

1. Availability against an SLA. A banking portal has AST = 24×7 for a 30-day month = 720 h. Outages in the month: 45 min + 30 min + 105 min = 180 min = 3 h.

• Availability = (720 − 3)/720 × 100 = 717/720 × 100 = 99.583%.
• Against a 99.9% SLA, allowed downtime = 0.001 × 720 = 0.72 h = 43.2 min. Actual 180 min → SLA breached by 136.8 min.
• If the contract puts 10% of a ₹40,00,000 monthly fee at risk and the credit is 2% per 0.1% availability shortfall: shortfall = 99.9 − 99.583 = 0.317 ≈ 3 full bands of 0.1% → 6% credit = ₹2,40,000, within the ₹4,00,000 cap.

2. MTBF, MTRS and availability. A server ran for 2,000 h of agreed service time with 4 failures and total downtime of 10 h.

• Uptime = 2,000 − 10 = 1,990 h → MTBF = 1,990/4 = 497.5 h.
• MTRS = 10/4 = 2.5 h. MTBSI = 497.5 + 2.5 = 500 h.
• Availability = 497.5/500 × 100 = 99.5% (same as (2,000 − 10)/2,000 = 99.5%).

3. Service desk staffing and cost per ticket. 9,000 incidents a month; average handling time 12 min; agent works 8 h/day, 22 days, at 70% utilisation; fully loaded cost ₹45,000 per agent-month.

• Work content = 9,000 × 12 = 1,08,000 min = 1,800 h.
• Productive hours per agent = 8 × 22 × 0.70 = 123.2 h → agents = 1,800/123.2 = 14.6 → 15 agents.
• Cost = 15 × ₹45,000 = ₹6,75,000 → cost per ticket = 6,75,000/9,000 = ₹75.
• If self-service deflects 20% (1,800 tickets), remaining 7,200 need 7,200 × 12/60 = 1,440 h → 1,440/123.2 = 11.7 → 12 agents, cost ₹5,40,000, cost per ticket = ₹75 per handled ticket but ₹60 per original demand — the saving is ₹1,35,000/month.

4. Priority matrix. Payroll fails on the 28th for all 5,000 employees: impact High, urgency High → P1. A single user's printer fails with a spare nearby: impact Low, urgency Low → P4.

5. Incident vs problem vs change vs request.

Where it is used

• Indian IT services and GCCs: TCS, Infosys, Wipro, HCLTech, Tech Mahindra, Cognizant, Capgemini, Accenture and captive centres run managed-services contracts entirely on ITSM processes with contractual SLAs.
• Tooling: ServiceNow (dominant in large Indian accounts), BMC Helix/Remedy, Jira Service Management, Freshservice (Freshworks, Chennai), Zoho Desk (Chennai), ManageEngine ServiceDesk Plus, SolarWinds, Ivanti.
• Job roles for freshers and early career: service desk analyst (L1), NOC/monitoring engineer, application support, incident/change coordinator, problem manager, SLA/reporting analyst, ServiceNow developer or administrator, CMDB/asset analyst.
• BFSI and regulated sectors: banks, NBFCs, insurers and exchanges apply ITSM under RBI/SEBI/IRDAI IT-governance and outsourcing norms, with CERT-In incident reporting.
• Government and public digital infrastructure: NIC, UIDAI, GSTN, IRCTC and state data centres run service desks and change control under MeitY SLA frameworks.
• Telecom and ISPs: Jio, Airtel and Vi NOCs use event and incident management; TRAI quality-of-service reporting mirrors availability metrics.

Interview questions

• Q: Difference between an incident and a problem? A: An incident is an unplanned interruption or quality reduction in a service; a problem is the underlying cause of one or more incidents. Incident management restores service fast, problem management removes the cause.
• Q: Is closing an incident with a workaround acceptable? A: Yes — the objective is fastest restoration of service. The underlying cause is then tracked as a problem with the workaround recorded in the KEDB.
• Q: How is incident priority decided? A: From a priority matrix combining business impact (how many users or how critical a service) and urgency (how fast it must be fixed) — not from who is asking.
• Q: Functional vs hierarchic escalation? A: Functional passes the ticket to a team with more technical skill (L1→L2→L3); hierarchic informs higher management, typically for major incidents or SLA risk.
• Q: Difference between SLA, OLA and underpinning contract? A: An SLA is with the customer, an OLA between internal support teams, a UC with an external supplier; the OLAs and UCs must be tight enough to support the SLA.
• Q: What is a CMDB and why does it matter? A: A database of configuration items and their relationships; it enables impact assessment before a change and faster root-cause analysis during incidents.
• Q: Difference between a standard change and an emergency change? A: A standard change is pre-authorised, low-risk and repeatable; an emergency change fixes an urgent issue with ECAB approval and reduced paperwork, documented retrospectively.
• Q: What changed from ITIL v3 to ITIL 4? A: The 5-stage lifecycle and 26 processes were replaced by the Service Value System, a six-activity service value chain, 34 practices, four dimensions and seven guiding principles, with explicit Agile/Lean/DevOps alignment.
• Q: Is ITIL a standard you can be audited against? A: No — ITIL is best-practice guidance; organisations are certified against ISO/IEC 20000-1:2018, while individuals hold ITIL certifications.
• Q: Does ITIL conflict with DevOps? A: No. ITIL 4 is designed to coexist: pipelines use pre-authorised standard changes, while governance, SLAs and problem management still apply.
• Q: A service shows 99.95% availability but users are unhappy. Why? A: The measurement may exclude the agreed service time that matters, count only full outages and ignore degradation, or the outage fell at a peak business hour — availability alone is not experience; add user-journey and response-time measures.
• Q: Under Indian rules, how fast must a cyber incident be reported? A: CERT-In's April 2022 directions require specified incidents to be reported within 6 hours of noticing them, with logs retained for 180 days in India; sectoral regulators such as RBI add their own timelines.

Common mistakes

• Treating a service request (new laptop, access) as an incident, which distorts SLA and volume reporting.
• Confusing priority with severity, or setting priority from the caller's seniority instead of impact × urgency.
• Keeping an incident open until the root cause is found — that is problem management's job.
• Computing availability over calendar hours instead of agreed service time, or ignoring the SLA's excluded maintenance windows.
• Saying a company is "ITIL certified" — only people are; organisations certify to ISO/IEC 20000-1.
• Reciting ITIL v3's five stages as the current model, or mixing v3 and ITIL 4 terms in one answer without flagging the edition.
• Forgetting the rollback plan and PIR for a change, and assuming a CAB "approves" rather than assesses and authorises.

Related topics

Monitoring and site reliability engineering · DevOps and CI/CD basics · Information security management and ISO/IEC 27001 · IT governance: COBIT and audit · Software project management and quality models (CMMI) · Business continuity and disaster recovery planning