Study + admin quick reference
CIS – IT Service Management (CIS-ITSM)
High-density exam reference you can read on-screen or print. Everything on this page is visible without logging in.
Remember these
- Incident restores service now. Problem finds root cause. Change controls risk when modifying the live environment.
- Task table is the parent for Incident, Problem, Change, and many request tasks.
- Work notes are usually internal; additional comments are often requester-visible.
- Catalog items collect variables; fulfillment creates tasks/approvals/flows — not just a ticket title.
- CMDB/CSDM data supports impact, assignment, and change planning. CIS-DF is a prerequisite for a reason.
- Configure in non-prod, test with real roles, then promote. Know OOB lifecycle states before customizing.
- Major Incident is for high-impact coordination — not every P1 automatically equals MIM process maturity.
1. Incident architecture & scoping
Domain 1| Topic | Must know |
|---|---|
| Purpose | Restore normal service operation as quickly as possible. |
| Core tables | Incident extends Task; related SLAs, knowledge, CIs, callers/users. |
| Channels | Agent Workspace/UI, portal/Employee Center, email, integrations, Virtual Agent. |
| Scoping | Define categories, assignment groups, priorities, notifications, and integrations early. |
| Requirements | Capture intake, triage, escalation, communication, and closure rules before heavy config. |
Implementation tip — Start from OOB Incident process, map customer gaps, then configure states, UI policies, assignments, and notifications — avoid rewriting the whole lifecycle on day one.
2. Incident lifecycle configuration
Domain 1| Area | Must know |
|---|---|
| States | New → In Progress → On Hold → Resolved → Closed (and canceled variants as configured). |
| Priority | Impact + Urgency matrix drives priority and often SLA targets. |
| Assignment | Assignment group / Assigned to; routing via rules, workflows, or workspace. |
| SLAs | Response/resolution timers; pause conditions matter (On Hold reasons). |
| Resolution | Resolution code/notes; caller confirmation patterns; auto-close options. |
- Impact
- Urgency
- Priority
- SLA
- On Hold
Config tip: Every custom state/transition needs a business reason, reporting impact, and notification review.
3. Incident operations & major incident
Domain 1- Link CIs/services to explain impact and support major-incident decisions.
- Use knowledge for known errors/workarounds; promote good resolutions into articles.
- Child incidents / related records help coordinate widespread outages.
- Major Incident Management adds communication, war-room style coordination, and stakeholder updates.
- Agent Workspace experiences are common for high-volume incident work.
Fast contrast — A high-priority incident needs fast restore. A major incident needs coordinated response and communications across teams/stakeholders.
Recurring incidents with the same cause should spawn or link to a Problem — do not keep “resolving” symptoms forever.
4. Problem architecture & scoping
Domain 2| Topic | Must know |
|---|---|
| Purpose | Identify root cause, reduce recurrence, and document known errors/workarounds. |
| Inputs | Recurring incidents, major incidents, trend analysis, proactive detection. |
| Outputs | Root cause, workaround, known error, related changes/fixes. |
| Scoping | Who owns problems, how incidents link, when known errors are published. |
| Architecture | Problem extends Task; relates to Incidents, Changes, Knowledge, CIs. |
Exam tip — Problem is not a parking lot for unresolved incidents. It is a structured investigation record with a lifecycle.
5. Problem lifecycle configuration
Domain 2| Stage focus | What happens |
|---|---|
| New / Assess | Validate it is a true problem; prioritize and assign. |
| Root Cause Analysis | Investigate cause; capture analysis notes and related evidence. |
| Known Error | Document cause + workaround for faster incident handling. |
| Fix in Progress | Often tied to Change for permanent remediation. |
| Resolved / Closed | Confirm fix effectiveness; close related communications/knowledge updates. |
- Workaround
- Known Error
- RCA
- Related Incidents
- Communicate workarounds back to Incident teams quickly.
- Do not close problems that still need a permanent fix without a clear next action.
6. Change architecture & models
Domain 3| Topic | Must know |
|---|---|
| Purpose | Control risk while delivering improvements and fixes to production. |
| Change types | Normal, Standard (pre-approved), Emergency — different risk/approval paths. |
| Change models | Define states, transitions, UI, and process behavior per change pattern. |
| Risk / impact | Assessments drive approvals, CAB attention, and scheduling decisions. |
| CIs / services | Affected CIs and services are critical for conflict and impact analysis. |
Standard vs normal — Standard = low-risk, pre-authorized, repeatable. Normal = assessed and approved through the defined path. Emergency = accelerated for urgent fixes with post-review.
7. Change configuration & CAB
Domain 3| Config area | Must know |
|---|---|
| Lifecycle states | New → Assess → Authorize → Scheduled → Implement → Review → Closed (model-dependent). |
| Approvals | Group/user approvals; CAB approval for higher-risk changes. |
| CAB workbench | Agenda, scheduling, and decision support for change advisory activities. |
| Conflict detection | Overlapping changes on same CIs/blackout windows. |
| Success / backout | Implementation plans, backout plans, and post-implementation review. |
Config tip — Change success depends on CMDB quality, clear models, and disciplined scheduling — not just more approval checkboxes.
8. Change operations & integrations
Domain 3- Link Incidents/Problems to Changes for auditability of fixes.
- Use maintenance/blackout schedules to protect critical periods.
- Unauthorized or poorly documented changes are a top exam/process risk theme.
- Integrate with DevOps/release tools carefully — ServiceNow remains the control record.
- Measure change success rate, lead time, and caused incidents.
Fast contrast — Emergency change speeds authorization for urgent risk. It does not mean “skip documentation and review forever.”
- CAB
- Blackout
- Conflict
- PIR
9. Service portfolio management
Domain 4| Concept | Must know |
|---|---|
| Service portfolio | Full set of services across lifecycle stages (pipeline, catalog, retired). |
| Service catalog (SPM sense) | Live/offerable services available to customers/users. |
| Business / technical services | Align offerings to CSDM service ideas and ownership. |
| Value | SPM connects strategy and demand to what IT actually offers and retires. |
Exam tip — SPM is smaller by weight, but know portfolio vs request catalog: portfolio = service strategy/lifecycle; Service Catalog module = ordering experience for items/requests.
- Owners, status, and service definitions must stay current.
- Retired services should not remain orderable or heavily supported by accident.
10. Catalog & request architecture
Domain 5| Component | Must know |
|---|---|
| Catalog | Container of categories and items users can request. |
| Catalog Item | Orderable offering with variables, pricing/workflow as configured. |
| Record Producer | Creates a target record (often Incident/request-related) from catalog UI. |
| Order Guide | Bundles multiple items into one guided request experience. |
| Request / Requested Item / Catalog Task | REQ → RITM → SCTASK fulfillment chain. |
Scoping questions — Who can see/order? What variables are required? What approvals/tasks are created? What is the fulfilled outcome?
- REQ
- RITM
- SCTASK
- Variables
11. Request configuration & integrations
Domain 5- Configure item UI policies/client scripts for variable behavior.
- User criteria control catalog visibility by user/role/location/etc.
- Fulfillment via Flow Designer / Workflow Studio is the modern default path.
- Employee Center / Service Portal are common request storefronts.
- Integrations: HR, procurement, software/hardware fulfillment, external ticketing.
- Keep variables and fulfillment tasks aligned — unused variables create bad data.
Fast contrast — Incident = break/fix. Request = service offering fulfillment. Misrouting requests into Incident skews metrics and ownership.
Test ordering as an end user, then fulfill as the assignment group — both sides must work.
12. CMDB for ITSM + exam traps
Domain 6| ITSM use of CMDB | Why it matters |
|---|---|
| Affected CI / service | Impact analysis for Incident/Major Incident. |
| Change CIs | Conflict detection, risk, and stakeholder identification. |
| CSDM alignment | Standard service/CI relationships improve reporting and ownership. |
| Data quality | Bad CMDB data creates wrong assignments and risky changes. |
Troubleshooting / exam traps
| Symptom | Likely issue / fix |
|---|---|
| Incidents never leave New | Assignment/notification gaps or UI/state misconfig. |
| SLA keeps running on hold | Pause conditions not aligned to On Hold reason. |
| Problems unused | No intake criteria from recurring incidents; process not socialized. |
| Changes collide | Missing CI association or conflict/blackout setup. |
| Requests stuck | Flow/approval/task assignment broken; variables incomplete. |
| Wrong team gets work | Routing rules vs CMDB service ownership mismatch. |