Service request management

“Service request management” is an operational control with direct audit impact because it is easy to test and easy to find gaps. If your organization provides IT services (internal or external), service requests are the routine asks: access, software installs, password resets, information requests, standard changes, and other pre-defined “request” items. ISO/IEC 20000-1 expects these to be handled through agreed procedures with consistent lifecycle handling.

Clause 8.6.2 is short, but it implies a lot: a standard intake path, a documented way to prioritize, a fulfillment model (including approvals and handoffs), and a defined closure standard. Your job as a Compliance Officer, CCO, or GRC lead is to make this requirement “audit-ready” without turning operations into paperwork. The fastest path is to implement a minimum viable request workflow in your service management tool, then tighten controls where risk is highest (identity/access requests, data requests, and requests fulfilled by third parties).

This page gives requirement-level implementation guidance you can apply immediately: who owns what, what procedures must say, what artifacts to retain, and what auditors commonly challenge.

Regulatory text

Requirement (verbatim): “The organization shall fulfil service requests in accordance with agreed procedures. Service requests shall be logged, prioritized, fulfilled, and closed.” ¹

What the operator must do

You must be able to show, for every service request:

1. It entered your system and was logged (not handled in an untracked channel).
2. It was prioritized using defined rules (not “whoever shouted loudest”).
3. It was fulfilled according to the agreed procedure (including approvals, validation, and competent assignment).
4. It was closed using a closure standard (confirmation, completion notes, and required fields).

The “agreed procedures” piece is what auditors use to test you. If you cannot produce the procedure, or if the procedure exists but does not match real practice, you fail the intent of the clause even if tickets exist.

Plain-English interpretation

You need a repeatable, documented way to handle service requests from start to finish, with records that prove each request was captured, queued based on importance, completed correctly, and formally finished. This is a control for reliability and accountability: it reduces lost requests, inconsistent access grants, and incomplete work that causes downstream incidents.

Who it applies to

Entity types: Service providers and organizations delivering services (internal shared services, IT, security operations, or a managed service business). ¹

Operational contexts where it matters most

• Central service desk / ITSM operations handling high request volume.
• Security and IAM teams processing access and privilege requests.
• Business application teams fulfilling “standard requests” (license grants, configuration updates).
• Environments with third-party fulfillment (outsourcers, MSPs, SaaS administrators) where you still need traceability and closure evidence.

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

1) Define what counts as a “service request”

Create a short scope statement your teams can apply consistently:

• Requests are pre-defined, repeatable services (examples: new user setup, access request, standard report request, software install).
• Incidents are unplanned interruptions and belong in incident management, even if they start as a “help” email.

Operator tip: If staff argue about classification, set a default: “If it’s unplanned service degradation, log as incident; otherwise request.”

2) Publish an “agreed procedure” that matches reality

Minimum contents your procedure should include:

• Intake channels (portal, email-to-ticket, API) and which are approved.
• Required ticket fields (requester, service, category, description, affected user, due date or SLA target if you use one).
• Prioritization rules and who can override them.
• Approval requirements by request type (especially access/data).
• Assignment model (service owners, resolver groups).
• Validation steps (what “fulfilled” means).
• Closure requirements (closure codes, user confirmation rules, documentation).

Keep it short enough that service desk leads will actually follow it.

3) Implement controlled intake and logging

Operational goal: all requests become tickets.

• Configure automatic ticket creation for common channels (portal and email).
• Block “shadow queues” (team inboxes, chat threads) by routing them into the tool.
• Set a rule for “walk-up” or verbal requests: the agent logs the request before work begins.

Evidence to plan for: ticket ID, created timestamp, requester identity, request category.

4) Build a prioritization model you can defend

Clause 8.6.2 requires prioritization, but it does not dictate a formula. Use a simple rule set:

• Define priority drivers (business impact, urgency, user type, service tier).
• Define who assigns initial priority (service desk triage).
• Define who can change priority (duty manager, service owner) and require a reason field for overrides.

Audit focus: Can you show prioritization occurred consistently and wasn’t arbitrary?

5) Fulfillment: define “done” and control risky request types

Fulfillment needs two layers:

• Standard fulfillment workflow: steps, assignment, work notes, handoffs, and completion checks.
• Higher-control tracks for sensitive requests:
  • Access requests: approvals, separation of duties, verification that access granted matches request.
  • Data requests: identity verification, authorization to receive data, secure delivery method.
  • Requests fulfilled by third parties: clear instructions, acceptance criteria, and confirmation back into your ticket.

If you use a platform like Daydream, map these workflows into checklist-based procedures attached to request types so fulfillment steps and evidence are captured in the same system of record.

6) Closure: make it consistent and testable

Define closure rules:

• Minimum closure fields (resolution summary, closure category, who completed the work, completion timestamp).
• User confirmation rules (when required vs. auto-close after documented completion).
• Reopen criteria (what happens if the requester disputes completion).

Closure is where examiners find weak controls: vague notes (“done”), missing approver identity, and tickets closed without fulfillment evidence.

7) Monitor and correct drift

Add light governance:

• Weekly spot checks by service desk lead (ticket quality, required fields, approvals present).
• Monthly reporting to management (volume, aging, reopen trends, top request types).
• Procedure refresh when the catalog changes.

Required evidence and artifacts to retain

Retain artifacts that prove the lifecycle requirement was met:

Core artifacts

• Service Request Management procedure (versioned, approved).
• Service catalog or request type list (even if minimal).
• Ticket records showing: logged, prioritized, fulfilled, closed.
• Role/permission documentation for who can approve, fulfill, and close specific request types.

Ticket-level evidence (what auditors sample)

• Intake record (source channel and requester).
• Priority field plus reason for overrides.
• Approval records (who approved, when, what was approved) for controlled request types.
• Work notes and fulfillment evidence (screenshots where appropriate, system logs references, completion checks).
• Closure code and closure note with acceptance criteria met.

Operational oversight artifacts

• Quality review checklist results or audit logs from the ticketing tool.
• Metrics dashboard exports (trend evidence). Keep it factual; don’t invent targets.

Common exam/audit questions and hangups

Auditors commonly test:

• “Show me your agreed procedure. Who approved it, and when did it last change?”
• “Pick a sample of requests and show logging, prioritization, fulfillment notes, and closure evidence.”
• “How do you prevent sensitive access requests from being fulfilled without approval?”
• “How do you ensure requests handled by a third party are still closed with proof of completion?”
• “How do you distinguish incidents from service requests, and what happens if misclassified?”

Hangups that slow audits:

• Multiple intake channels with inconsistent logging.
• Priority field exists but is not used, or everyone sets everything to “high.”
• Closure notes are inconsistent, missing, or copied/pasted.

Frequent implementation mistakes (and how to avoid them)

1. Procedure exists, but it’s a “paper process.”
   Fix: align the procedure to the ticket workflow you actually run. If the tool can’t enforce it, add required fields and validation.

2. Requests completed outside the ticketing system.
   Fix: make the ticket the “work container.” If work happens in another system, reference the change ID, access log, or admin console record in the ticket notes.

3. No special handling for access and data requests.
   Fix: define request subtypes with mandatory approvals and evidence fields. Make it hard to close without them.

4. Closure is treated as optional hygiene.
   Fix: define closure codes and required resolution summaries. Train agents that “closed” is part of completion, not administrative cleanup.

5. Third-party fulfillment breaks traceability.
   Fix: require your third party to provide completion confirmation and attach it (or log it) in the ticket before closure. Tie this to contract/SOW operating procedures.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

Practically, weak service request management creates audit findings because it looks like uncontrolled operations. It also creates real risk: unauthorized access, incomplete deprovisioning, inconsistent service delivery, and poor customer outcomes. In ISO/IEC 20000 audits, sampling is straightforward, so gaps surface quickly.

Practical execution plan (30/60/90)

Use these phases as an execution sequence (adjust to your environment and change control cadence).

First 30 days (stabilize the workflow)

• Confirm scope: what teams and services are in the ISO/IEC 20000 service management system.
• Draft and approve the Service Request Management procedure.
• Standardize intake channels and require logging for all requests.
• Define priority rules and implement required ticket fields.
• Choose 3–5 highest-volume request types and create request forms.

Next 60 days (add controls and evidence quality)

• Add approval workflows for access and data-related request types.
• Train service desk and resolver groups on classification, priority rules, and closure standards.
• Start ticket quality reviews and correct recurring issues.
• If third parties fulfill requests, add confirmation steps and update operating procedures.

Next 90 days (make it audit-proof and resilient)

• Expand the service catalog coverage to additional request types.
• Implement dashboarding for aging, reopen reasons, and priority distribution.
• Run an internal audit-style sample test: trace tickets end-to-end and document gaps.
• Tune tool configuration (required fields, templates, automation) to reduce human error.
• If you use Daydream, centralize procedures, evidence attachments, and review workflows so sampling and reporting are faster.

Frequently Asked Questions

Do we need a separate tool for service requests, or can we use email and spreadsheets?

ISO/IEC 20000-1 requires requests be logged, prioritized, fulfilled, and closed, so you need a system that preserves records and workflow consistently. Email and spreadsheets often fail on traceability, approval capture, and consistent closure evidence.

What’s the minimum “agreed procedure” content an auditor will accept?

The procedure must define how you log, prioritize, fulfill, and close requests, plus roles and any required approvals. If the procedure omits how sensitive request types are controlled, expect follow-up questions during sampling.

How should we handle requests that are actually incidents?

Define a triage rule and train agents to reclassify quickly. Keep a record of the reclassification in the ticket notes so you can show consistent application of your procedure.

Do we need user confirmation before closing every request?

Not for every request, but you do need a documented closure standard. Many teams require confirmation for higher-impact requests and allow documented completion for low-risk standard requests, as long as the rule is written and followed.

How do we show prioritization if we don’t have formal SLAs?

Use a priority model based on impact and urgency, and record the priority on each ticket. The auditor is looking for consistent prioritization decisions, not necessarily contractual SLAs.

What if a third party fulfills the request in their own system?

Keep your ticket as the system of record and record the handoff, completion confirmation, and acceptance criteria in your ticket before closure. If possible, attach the third party’s confirmation or reference their ticket ID in your record.

Footnotes

1. ISO/IEC 20000-1:2018 Information technology — Service management