CIS-ITSM Study Guide — Certified Implementation Specialist: IT Service Management

Independent study material. Not affiliated with or endorsed by ServiceNow. "ServiceNow", "Now Platform", and product/release names are trademarks of ServiceNow, Inc., used here for identification and study reference only.

This guide is organized by exam weight, heaviest domain first. The CIS-ITSM exam has 60 scored questions (allow up to ~90 minutes; some delivery windows publish 60–65 items). It targets your ability to configure, implement, and maintain ServiceNow ITSM — not merely recite ITIL theory. Wherever ITIL concepts appear, the exam expects you to map them onto concrete ServiceNow platform behavior (tables, states, flows, business rules, roles, and properties).

Domain weights:

Rank	Domain	Weight
1	Incident Management	25%
1	Change Management	25%
1	Request Fulfillment / Service Catalog	25%
4	Problem Management	10%
4	Knowledge Management	10%
6	Configuration Management Database (CMDB)	5%

The three 25% domains together are 75% of the exam. Spend your time accordingly.

1. Incident Management (25%)

Purpose and where it lives

Incident Management exists to restore normal service operation as quickly as possible while minimizing business impact. That is the single most-tested distinction: incidents are about speed of restoration, not about fixing the underlying cause (that is Problem Management). A workaround that gets the user productive again is a perfectly good incident resolution even when the root cause is unknown.

Incident records live on the incident table, which extends the base task table. Because of that inheritance, incidents share the task data model's common fields (number, state, assignment group, assigned to, work notes, comments, SLA attachment) with the rest of ITSM. Knowing the table inheritance chain (task → incident) matters for any question about fields, business rules, ACLs, or extending the model.

State model and lifecycle

The baseline incident state model moves a record through New → In Progress → On Hold → Resolved → Closed, with Canceled available for records logged in error. Two states cause the most confusion:

On Hold pauses active work and requires an On Hold reason (Awaiting Caller, Awaiting Change, Awaiting Problem, Awaiting Vendor). Selecting a reason is what distinguishes a legitimate hold from simply stalling.
Resolved means a fix or workaround has been applied and the incident is awaiting confirmation/auto-closure. Closed is the terminal state. Baseline behavior auto-closes resolved incidents after a configurable number of days (a system property), and resolution information (resolution code and resolution notes) is mandatory before resolving.

Priority, Impact, and Urgency

Priority is derived, not typed. It is calculated from the combination of Impact and Urgency through the Priority data lookup (Priority Lookup Rules in the data-lookup definitions), executed by a business rule. To let analysts set priority manually, you disable or modify those lookup rules and the recalculation business rule — you do not make the field read-only and you never delete the field. Knowing this calculation pipeline (Impact + Urgency → lookup → Priority) is a recurring exam theme.

Assignment

Incidents reach the right team through assignment rules, assignment groups, and (optionally) Predictive Intelligence / Agent Assignment. The assignment group drives queueing; the assigned-to person owns the work. VIP callers and affected CIs can influence impact/urgency through additional rules, but they do not by themselves set priority.

Major Incident Management (MIM)

A Major Incident is a high-impact, high-urgency incident requiring coordinated, accelerated response. ServiceNow MIM lets an authorized user (the Major Incident Manager) propose an incident as a candidate, after which it is promoted (confirmed) to a major incident; it can later be demoted if it no longer qualifies. MIM adds communication and coordination tooling: a major incident workbench / overview, communication tasks and stakeholder updates, and (in Service Operations Workspace) on-call engagement. After resolution, a Post Incident Review (PIR) report can be generated to capture timeline, contributing factors, and follow-up actions — this is the bridge into Problem Management.

Workspaces and channels

Modern incident work happens in Service Operations Workspace (SOW) (and historically the Agent Workspace), giving agents a list/form/inbox layout, agent assistance, and guided resolution. Incidents are created across channels — agent-logged, self-service portal, virtual agent, email inbound actions, and event/alert integrations from IT Operations Management.

Exam focus

Purpose = restore service fast (vs. Problem = root cause).
incident extends task.
State flow and the meaning of On Hold (with reason) vs. Resolved vs. Closed.
Priority = Impact × Urgency via data lookup + business rule; how to make it manual.
Major incident propose → promote → demote; PIR follows resolution.

2. Change Management (25%)

Purpose and the three change types

Change Management controls the lifecycle of changes to the IT environment to deliver them with the least risk and disruption. Change records live on the change_request table (extends task). The exam leans heavily on distinguishing the three baseline change types:

Standard change — pre-authorized, low-risk, repeatable, with a proven implementation procedure. It is requested from the Standard Change Catalog as a pre-approved template, so it skips CAB and per-instance approval. Promoting recurring, low-risk normal changes into standard change templates is the recommended efficiency play.
Normal change — anything not standard or emergency. It requires risk assessment, planning, approvals, and (when applicable) CAB review before implementation. This is the full workflow path.
Emergency change — must be implemented fast to resolve a major incident, restore service, or close a critical security gap. Approval is expedited (an emergency CAB / e-CAB), and review may happen after the fact.

Change models and state flow

Baseline change uses change models (state-machine driven flows) rather than legacy workflows. The normal change moves through stages such as New / Assess → Authorize → Scheduled → Implement → Review → Closed, with Canceled available. Approvals are gated by state: a change typically cannot be implemented until it is approved and within its scheduled window.

Risk and the Change Risk assessment

Risk is central. ServiceNow offers two complementary mechanisms:

Change Risk Calculator / risk conditions — enabled by default; uses predefined conditions and properties to compute risk automatically.
Change Management – Risk Assessment plugin — lets you build a risk assessment questionnaire; the user's answers feed a scoring formula that sets the change's overall Risk (and often Impact). Newer releases also expose Change Risk via Predictive Intelligence.

Risk and impact together inform which approval path and CAB scrutiny a change needs.

CAB

The Change Advisory Board (CAB) is the group of IT decision-makers and technical experts who review and authorize changes (typically normal changes above a risk threshold). ServiceNow provides the CAB Workbench to schedule CAB meetings, build agendas from changes in scope, run the meeting, and record decisions. Standard changes do not go to CAB (already pre-approved); emergency changes use an expedited/emergency CAB.

Schedules, conflicts, and blackouts

Change scheduling uses maintenance windows, blackout windows, and the Change conflict detection engine, which flags overlapping changes on the same CI or conflicts with blackout/maintenance schedules. CIs are attached so impact and conflicts can be assessed against the CMDB.

Exam focus

Standard (pre-approved, from catalog, no CAB) vs. Normal (full risk + approval + CAB) vs. Emergency (expedited).
change_request extends task; change models drive state.
Two risk paths: default Change Risk Calculator vs. Risk Assessment plugin questionnaire.
CAB Workbench schedules and runs CAB; standard changes bypass it.
Conflict detection and blackout/maintenance windows.

3. Request Fulfillment / Service Catalog (25%)

The REQ → RITM → SCTASK model

This domain tests the request data model relentlessly. When a user orders from the Service Catalog:

One Request (REQ) record is created per order (the "shopping cart" container). Table: sc_request.
One Requested Item (RITM) is created per item in the cart, as a child of the REQ. Table: sc_req_item.
Zero or more Catalog Tasks (SCTASK) are created as children of each RITM to capture the actual fulfillment work. Table: sc_task.

All three extend task. The hierarchy is REQ (parent) → RITM (child) → SCTASK (grandchild). A REQ always has at least one RITM; SCTASKs are optional and exist only where work needs assigning. Closure flows up: SCTASKs close → RITM closes → REQ closes. A common exam trap: the RITM is what the customer requested and carries customer-facing additional comments; the SCTASK is where the assigned worker does the work and writes internal work notes.

Catalog building blocks

Catalog items — the orderable products/services, organized into categories within one or more catalogs.
Variables and variable sets — the questions presented to the requester; their answers (variable values) flow to RITM and can be passed to SCTASKs.
Record producers — catalog-style forms that create a record on any table (e.g., create an incident from the portal) rather than ordering an item.
Order guides — bundle multiple related items into a single guided ordering experience (e.g., onboarding).
Catalog UI policies and catalog client scripts — control variable behavior on the catalog form.

Fulfillment automation: Flow Designer

Modern fulfillment is driven by Flow Designer flows (and the legacy graphical Workflow in older content) attached to the catalog item. A flow generates the SCTASKs, routes approvals, updates state, and closes records. Knowing that Flow Designer is the current automation engine (replacing legacy workflows) is exam-relevant.

Access and presentation

Catalog item and category visibility is governed by User Criteria (the same Available For / Not Available For mechanism used in Knowledge), letting you target who can see and order each item. Items surface through the Service Portal and the Employee Center (the current self-service experience).

Exam focus

REQ (sc_request) → RITM (sc_req_item) → SCTASK (sc_task); all extend task.
One RITM per cart item; SCTASK optional; closure rolls upward.
Variables/variable sets carry the request data; record producers create records on other tables; order guides bundle items.
Flow Designer is the current fulfillment engine.
User Criteria controls catalog visibility; Employee Center / Service Portal deliver it.

4. Problem Management (10%)

Purpose

Problem Management finds and removes the underlying cause of one or more incidents to prevent recurrence. It is the deliberate counterpart to Incident Management's speed-focused restoration. Problem records live on the problem table (extends task).

Lifecycle and key artifacts

Recent ServiceNow releases use a state model with distinct phases: Assess → Root Cause Analysis → Fix in Progress → Resolved → Closed (with New at entry and Cancel available). Two outputs are heavily tested:

Workaround — a documented means of restoring service without resolving the root cause; it can be communicated back to related incidents so callers are unblocked immediately.
Known Error — a problem whose root cause and/or workaround are documented. Recording a known error lets future matching incidents be resolved quickly by reusing the known workaround.

A problem can be created from an incident, and incidents can be linked to a problem so a single fix resolves many tickets. Root Cause Analysis (RCA) is structured, owned work — you can spin RCA tasks off the problem record.

PIR vs. Problem

The exam may contrast the Post Incident Review (PIR) — generated after a major incident to capture timeline and lessons — with formal Problem Management. PIR is a review artifact; Problem Management is the ongoing process that drives permanent fixes. They are related but distinct.

Exam focus

Purpose = eliminate root cause / prevent recurrence (vs. Incident = restore fast).
problem extends task.
Workaround (restores service, no root cause) vs. Known Error (root cause/workaround documented).
Problems link to many incidents; one fix closes many; RCA is owned, scoped work.

5. Knowledge Management (10%)

Purpose and KCS

Knowledge Management captures, structures, and shares knowledge so issues are resolved faster and self-service deflects tickets. ServiceNow aligns to Knowledge-Centered Service (KCS) — capturing knowledge as a by-product of solving problems, reusing it, improving it on use, and rewarding contribution. KCS-enabled features include creating articles in the flow of incident/problem work and flagging articles for improvement.

Data model and lifecycle

Articles live on the kb_knowledge table and belong to a Knowledge Base (kb_knowledge_base) organized by categories. The article lifecycle is Draft → (Review/Approval) → Published → Retired, optionally governed by knowledge workflows (publish and retire approval flows) and an article Valid to date for review.

User Criteria — the central testable concept

Access is controlled by User Criteria at the knowledge base level via four settings:

Can Read — who may view articles.
Can Contribute — who may create, edit, and retire articles.
Cannot Read and Cannot Contribute — explicit exclusions, which take precedence over the "Can" settings when there is overlap.

User criteria match on roles, groups, companies, departments, locations, or scripted conditions. To let a group author articles in a base, they must be on Can Contribute (and generally hold a knowledge role). This precedence behavior (Cannot overrides Can) is a frequent exam item.

Feedback and search

Knowledge supports article feedback (helpful/flag, ratings, comments), knowledge search surfaced in workspaces and the portal, and contextual search that proposes relevant articles while logging an incident. Users can search/read in Employee Center and the Service Portal subject to user criteria.

Exam focus

KCS = capture/reuse/improve/reward in the flow of work.
kb_knowledge articles in a kb_knowledge_base; Draft → Published → Retired.
User Criteria: Can Read / Can Contribute / Cannot Read / Cannot Contribute; Cannot overrides Can.
Contextual search proposes articles during incident logging.

6. Configuration Management Database (CMDB) (5%)

Purpose

The CMDB is the trusted record of Configuration Items (CIs) and their relationships, underpinning impact analysis, change conflict detection, and service mapping. The lowest-weighted domain, but the exam still expects core literacy.

Data model

CIs are stored in classes that extend the base cmdb_ci table; specific classes (server, application, network gear, etc.) extend it in an inheritance hierarchy. CI relationships are stored in cmdb_rel_ci and describe dependencies (Runs on, Depends on, Hosted on) that power impact maps. The Common Service Data Model (CSDM) is ServiceNow's prescribed framework for modeling services and applications consistently (business/technical/application services, business applications) — populate the CMDB to align with CSDM.

IRE — Identification and Reconciliation Engine

The Identification and Reconciliation Engine (IRE) is the single entry point that keeps the CMDB clean:

Identification rules decide whether an incoming CI already exists (using identifier entries/criteria). If matched, the existing record is updated; if not, a new CI is created — this prevents duplicates.
Reconciliation rules decide which data source is authoritative for which attributes, so that, for example, Discovery can be trusted over a manual edit for certain fields.

Data enters the CMDB via Discovery, integrations, Service Mapping, IntegrationHub ETL, and manual entry — all funneled through IRE so the same identification/reconciliation logic applies.

Exam focus

CMDB = CIs + relationships; CIs extend cmdb_ci; relationships in cmdb_rel_ci.
CSDM is the modeling framework to align to.
IRE: identification rules prevent duplicates (match/update vs. insert); reconciliation rules pick the authoritative source per attribute.
CMDB feeds change conflict detection and incident/problem CI context.

Fast-recall cheat list

Process purposes: Incident = restore service fast; Problem = remove root cause; Change = control change with least risk; Request = fulfill service requests; Knowledge = capture & reuse knowledge; CMDB = trusted CI/relationship record.
Tables (all extend task unless noted): incident, problem, change_request, sc_request (REQ), sc_req_item (RITM), sc_task (SCTASK). Knowledge: kb_knowledge (not task). CMDB: cmdb_ci, relationships cmdb_rel_ci (not task).
Priority = Impact + Urgency via data lookup + business rule; make manual by disabling those rules (never make read-only, never delete the field).
Incident states: New → In Progress → On Hold (needs reason) → Resolved → Closed; Canceled for errors.
Major incident: propose → promote → (demote); PIR after resolution.
Change types: Standard = pre-approved from catalog, no CAB; Normal = full risk + approval + CAB; Emergency = expedited e-CAB.
Change risk: default Change Risk Calculator vs. Risk Assessment plugin questionnaire.
CAB Workbench schedules/runs CAB; standard changes bypass it; conflict detection + blackout/maintenance windows.
Request hierarchy: REQ (1 per order) → RITM (1 per item) → SCTASK (optional work). RITM = what's requested; SCTASK = where work happens; closure rolls upward.
Catalog parts: catalog items, variables/variable sets, record producers (create records on any table), order guides (bundle items). Flow Designer = current fulfillment engine.
User Criteria controls visibility for both Service Catalog items and Knowledge bases: Can Read / Can Contribute / Cannot Read / Cannot Contribute — Cannot overrides Can.
Problem outputs: Workaround (restores service, no root cause) vs. Known Error (root cause/workaround documented).
KCS: capture knowledge in the flow of work, reuse, improve on use, reward.
CMDB IRE: identification rules (dedupe: match→update / insert) + reconciliation rules (authoritative source per attribute); align to CSDM.
Experiences: Service Operations Workspace for agents; Employee Center / Service Portal for self-service.
Exam logistics: 60 scored questions, ~90 minutes, single- and multiple-select; CSA is the prerequisite certification.