Incident and service request management

The incident and service request management requirement means you must run a consistent, documented, and measurable process to log, classify, prioritize, route, resolve, and close incidents and service requests, with evidence that the process works in day-to-day operations. For ISO/IEC 20000-1 alignment, your goal is repeatability: defined workflows, clear ownership, target response/resolution times, and auditable records ¹.

Key takeaways:

• One system of record must capture the full lifecycle: intake → triage → assignment → resolution → closure → reporting.
• Separate “incidents” from “service requests” in workflow and metrics; treat them differently operationally even if they share tooling.
• If you can’t produce tickets, timestamps, approvals, and trend reports on demand, you will struggle to evidence the incident and service request management requirement ¹.

Compliance leaders get burned on incident and service request management because teams “do the work” but can’t prove it consistently. Auditors and certification bodies look for an operational system, not good intentions: defined categories, triage rules, ownership, service targets, and records that show each ticket moved through the process the way your procedures say it should ¹.

This requirement is usually owned by ITSM, but it becomes a GRC problem the moment you support regulated customers, run outsourced services, or depend on third parties for critical components. Poor incident handling creates customer impact, SLA breaches, and weak root-cause discipline. Poor request fulfillment creates access sprawl, uncontrolled changes, and “shadow IT” workarounds.

This page translates the incident and service request management requirement into a build list: what to document, what to configure in the ticketing tool, what metrics to track, what evidence to retain, and what examiners commonly challenge. If you need to operationalize quickly, treat this as your minimum viable control design for ISO/IEC 20000-1-aligned service management ¹.

Regulatory text

Provided excerpt (do not treat as the full ISO standard text): “Baseline implementation-intent summary derived from publicly available framework overviews; licensed standard text is not reproduced in this record.”
Requirement summary: “Operate consistent processes for incident handling and request fulfillment.” ¹

What the operator must do:

• Define and run documented processes for incident management and service request management that are used consistently across the in-scope services.
• Ensure tickets are recorded, tracked, and measured end-to-end so you can demonstrate performance and control operation during audit or certification review ¹.

Plain-English interpretation (what “good” looks like)

You need a single, repeatable way to handle (1) things that are broken (incidents) and (2) things people ask for (service requests). “Consistent” means:

• Everyone knows how to open a ticket and what information is required.
• The service desk (or equivalent) triages and routes work the same way every time.
• Priority is assigned using defined rules, not whoever shouts the loudest.
• Resolution and closure are controlled, recorded, and reviewable.
• You can report trends and performance without manual spreadsheet archaeology ¹.

A practical test: pick any recent incident and any recent request. Can you show the full timeline, ownership, approvals (if required), communications, and closure rationale in minutes? If not, your incident and service request management requirement evidence is thin.

Who it applies to (entity + operational context)

Primary scope: IT service providers and internal IT organizations operating an IT service management system aligned to ISO/IEC 20000-1 ¹.

Typically in scope:

• Service desk operations supporting production services
• SRE/operations teams handling outages and degradations
• Application support teams providing break/fix and user support
• Teams fulfilling access, equipment, software, and standard service requests
• Third parties who provide support tiers, NOC/SOC functions, or managed services (you still need oversight and integrated evidence)

Where it becomes high friction in audits:

• Multiple intake channels (email, chat, phone, portal) with inconsistent logging
• Engineering teams “handling incidents in Slack” without tickets
• Requests fulfilled via informal approvals, especially access and data pulls
• Third-party support where the third party holds the ticket data but you can’t produce it quickly

What you actually need to do (step-by-step)

Step 1: Define scope and ticket taxonomy

1. List in-scope services (customer-facing and internal shared services).
2. Define what qualifies as an incident vs a service request.
3. Create categories/subcategories that match your services (examples: “Email,” “Identity,” “Endpoint,” “Customer Portal,” “Billing System”).
4. Establish a required minimum data set per ticket: requester, service, category, impact, urgency, priority, timestamps, assignment group, resolution code, closure notes.

Operator tip: Keep categories stable. Frequent category churn destroys trending and makes audits painful.

Step 2: Design workflows that match real operations

For incidents, define:

• Intake and logging (including major incident trigger)
• Triage and prioritization rules (impact/urgency matrix)
• Assignment and escalation path (including after-hours)
• Customer/user communications cadence and templates
• Resolution, recovery validation, and closure criteria
• Linkage to problem management and change management when relevant

For service requests, define:

• Request catalog items (what people can request)
• Approval rules (who must approve what, and when)
• Fulfillment steps and handoffs
• Standard completion criteria and closure

Control intent: Incidents optimize restoration; requests optimize predictable fulfillment.

Step 3: Implement the process in the tool (don’t stop at a policy)

Configure your ticketing system so it enforces the process:

• Separate ticket types for incident vs request.
• Mandatory fields for priority and category.
• SLA timers or service targets for response and resolution.
• Status values that reflect your workflow (avoid free-form statuses).
• Assignment groups mapped to services.
• Audit logs enabled and retained.

If a team works outside the tool, your process becomes optional. That is the fastest way to fail the “consistent processes” expectation ¹.

Step 4: Define service targets and measurable outcomes

Create service targets that you can actually measure from the ticket system, such as:

• Time to acknowledge
• Time to restore service (incidents)
• Time to fulfill (requests)
• Reopen rate / repeat incident rate
• Backlog aging

You don’t need fancy metrics. You need metrics you can reproduce on demand from system records.

Step 5: Establish operational governance

Put light governance around the process:

• Daily/weekly review for backlog, breaches, and major incidents
• Monthly trend reporting to service owners
• Periodic sampling/QA of tickets for completeness and correct classification
• Defined ownership (process owner + tool owner + service owners)

Step 6: Integrate third parties into the workflow

Where third parties perform support:

• Contractually require ticket evidence, timestamps, and status updates.
• Require major incident notification rules and escalation contacts.
• Ensure you can export or receive ticket records for audit and trending.

GRC angle: Treat third-party ticket data as part of your control evidence. If you can’t get it, the control is not verifiable.

Step 7: Prove it works (evidence-driven testing)

Run a basic operating effectiveness check:

• Sample a set of incidents and requests across services.
• Verify required fields, correct priority assignment, documented resolution, and closure approval where required.
• Validate SLA calculations match what you report.
• Document findings and fixes.

Daydream can help here by turning your requirement into an evidence checklist and tracking which services and third parties have produced audit-ready tickets and metrics, without relying on tribal knowledge.

Required evidence and artifacts to retain

Maintain artifacts that map cleanly to “operate consistent processes” ¹:

Process documentation

• Incident management procedure (version controlled)
• Service request management procedure (version controlled)
• Priority matrix and escalation rules
• Major incident process (if applicable)
• RACI/ownership (service desk, resolver groups, service owners)

System configuration evidence

• Ticket type definitions and workflows
• Required fields and validation rules
• SLA/service target configuration
• Assignment group/service mapping
• Audit log settings and retention settings

Operational records (your strongest evidence)

• Incident and request tickets showing end-to-end lifecycle
• Communications logs (status updates, customer notifications)
• Post-incident reviews for significant incidents (if performed)
• Monthly/quarterly KPI reports generated from the system
• Backlog and breach reports plus remediation notes

Third-party evidence

• Third-party support procedures and escalation paths
• Extracted ticket samples from third-party systems (or API exports)
• SLA reports provided by the third party and your review notes

Common exam/audit questions and hangups

Auditors/certification reviewers tend to ask:

• “Show me how an incident is logged, prioritized, escalated, and closed.” Bring a real ticket trail.
• “How do you distinguish incidents from requests?” Expect scrutiny if everything is labeled “incident.”
• “How do you know SLAs are met?” You need tool-based timestamps and definitions.
• “How do you handle tickets created via email/chat/phone?” They still must become tickets.
• “How do third parties participate?” You need a provable interface, not verbal assurances ¹.

Hangups that create findings:

• Missing timestamps (acknowledgment/assignment/resolution not captured)
• Priority set late or changed without reason
• Tickets closed with vague notes (“fixed,” “done”)
• Reopened tickets without analysis
• Reports built manually in spreadsheets without reproducible queries

Frequent implementation mistakes (and how to avoid them)

1. One workflow for everything. Fix: separate incident and request types, even if the tool is shared.
2. Policy-only compliance. Fix: implement validations and required fields in the ticketing system.
3. Uncontrolled intake channels. Fix: enforce “no ticket, no work,” and add easy intake (portal/email-to-ticket).
4. Resolver groups bypass the service desk. Fix: define triage authority and escalation paths; monitor “direct-to-engineer” work.
5. No evidence from third parties. Fix: bake ticket evidence delivery into contracts and QBRs; test it early.
6. Metrics that aren’t auditable. Fix: generate KPIs directly from the system of record; document metric definitions.

Risk implications (why compliance should care)

Weak incident management increases downtime, repeat failures, and inconsistent customer communications. Weak request management increases unauthorized access, uncontrolled service consumption, and inconsistent fulfillment outcomes. From an ISO/IEC 20000-1 perspective, the biggest risk is inability to demonstrate consistent operation with records and measurement ¹.

Practical 30/60/90-day execution plan

Day 0–30: Stabilize the minimum viable process

• Confirm in-scope services and support groups.
• Publish incident vs request definitions and a simple priority matrix.
• Standardize required ticket fields and closure codes.
• Require all support work to be tracked in the ticketing tool.
• Start weekly reporting: volume, breaches, backlog, reopen rate ¹.

Day 31–60: Make it measurable and auditable

• Configure SLA/service target timers and reports in the tool.
• Implement major incident triggers, comms templates, and escalation contacts.
• Build a ticket QA checklist and perform sampling reviews.
• Map third-party support into your workflows and start collecting ticket evidence.

Day 61–90: Prove consistency across services (and fix gaps)

• Run an operating effectiveness review with sampled tickets across teams.
• Tune categories, assignment rules, and approval steps based on failure modes.
• Establish monthly service review cadence with service owners.
• Centralize evidence (procedures, configs, reports, ticket samples) in a control repository; Daydream can track evidence requests and keep an audit-ready packet tied to the incident and service request management requirement ¹.

Frequently Asked Questions

Do we need separate tools for incident management and service request management?

No. One tool is fine if it supports distinct ticket types, workflows, and reporting for incidents vs requests. Auditors care that the processes are consistent and evidenced in records ¹.

What’s the minimum evidence set to satisfy the incident and service request management requirement?

Keep current procedures, tool configuration evidence, and real ticket samples that show lifecycle timestamps, ownership, priority, resolution, and closure. Add trend reports that are reproducible from the system of record ¹.

How do we handle incidents worked in Slack or Teams?

Allow chat for collaboration, but require a linked ticket as the system of record. Capture key decisions and timestamps in the ticket so the audit trail is complete.

Are access requests part of service request management?

Yes in most organizations, if you fulfill access as a standardized request. If approvals or segregation-of-duties checks apply, make those steps explicit in the request workflow and retain approval evidence.

What if a third party runs our service desk and keeps all tickets in their system?

Require contractual rights to ticket data exports and SLA reports, and test retrieval. If you can’t obtain records promptly, you can’t evidence consistent process operation.

How do we prevent teams from gaming SLAs by reclassifying tickets?

Lock down priority change permissions or require change reasons and approvals in the ticket. Review audit logs and run periodic sampling focused on priority changes and reopen patterns.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. ISO/IEC 20000-1 overview