ServiceNow CIS - ITSM

Domain 1: Incident Management — 25%

Incident Management is about restoring service quickly and safely, not spending hours proving the perfect root cause while users remain impacted.

You’ll need to understand categorization, prioritization, assignment, SLAs, major incidents, communication, resolution, and closure. Watch for impact-versus-urgency scenarios, because priority should reflect the real business effect rather than the emotional tone of the caller. Follow the lifecycle: log the incident, classify it, route it, investigate it, restore service, validate the result, and close it with useful information. Know where automation, templates, knowledge articles, assignment rules, and related records can reduce handling time without skipping accountability or creating incomplete records.

Domain 2: Problem Management — 15%

Problem Management reduces recurring impact by organizing root-cause investigation, workarounds, known errors, and permanent fixes.

Incidents provide the operational evidence, while problem records support deeper analysis across time. You’ll need to understand problem identification, assessment, investigation, known-error handling, resolution, closure, and connections to changes or knowledge. Not every isolated incident needs a problem record, but repeated or high-impact failures shouldn’t remain a pile of disconnected tickets. Study proactive and reactive problem creation, major problem reviews, workaround communication, and the difference between restoring service and removing the underlying cause. A mature process captures reusable workarounds quickly, then tracks corrective action without losing ownership.

Domain 3: Change Management — 25%

Change Management is controlled deployment. The goal is to move work into production while keeping risk, timing, approvals, and recovery options visible.

You’ll compare standard, normal, and emergency changes, along with change models, policies, risk calculations, conflict detection, blackout schedules, and change calendars. Follow the full path: request the change, assess risk, obtain the correct approval, schedule the work, execute a tested plan, validate the result, and close it with evidence. A repeatable, preauthorized change shouldn’t be slowed by unnecessary approval, while an urgent change still needs accountability and review. Trace affected CIs, dependencies, implementation steps, test plans, rollback conditions, and the business reason for the change.

Domain 4: Service Portfolio Management — 5%

A service portfolio should explain what the organization offers, who owns it, who consumes it, and where each service stands in its lifecycle.

You’ll need to distinguish services, service offerings, categories, commitments, owners, and portfolio states. Don’t turn the portfolio into a dumping ground for every technical component. The business-facing service view should remain distinct from the infrastructure that supports it, while still maintaining useful relationships between them. Common failures include duplicate offerings, vague ownership, promises nobody measures, and retired services that still appear available. A clean portfolio helps leaders fund, govern, publish, improve, and retire services based on value and demand rather than institutional memory.

Domain 5: Service Catalog and Request Management — 25%

Request Fulfillment can look like Incident Management with a shopping cart, but the records and workflows serve a different purpose.

You’ll need to understand catalog items, record producers, order guides, requests, requested items, catalog tasks, variables, approvals, flows, SLAs, and user-facing status. A user requesting a standard product, service, or access follows a defined fulfillment path. An unexpected service interruption does not. Pay close attention to the record hierarchy: the request represents the overall submission, a requested item represents one item being fulfilled, and catalog tasks represent the individual work required to deliver it. Follow the process from submission through approvals, assignment, fulfillment, delivery, and closure.

Domain 6: Configuration Management Database (CMDB) — 5%

The CMDB gives ITSM processes a shared model of the technology and services affected by operational work.

You’ll need to understand CI classes, relationships, identification concepts, lifecycle status, ownership, and the difference between assets and configuration items. Incident impact, change risk, problem analysis, and service visibility all improve when CI data and relationships are trustworthy. Don’t assume that linking any CI makes a ticket more valuable. The selected CI should accurately represent the affected, changed, or investigated component. Study how dependency context supports impact assessment, routing, outage communication, risk analysis, and historical reporting across ITSM records. The value comes from dependable context, not simply having more records in the CMDB.