IT Service Request Checklist

Runbook a service desk technician follows to fulfill an end-user IT service request — from PSA intake through provisioning of accounts, software, hardware, or network access, to ticket closure and CMDB documentation.

6 sections 25 steps Collects data
1

Request Intake and Authorization

  1. Log ticket in PSA or ITSM
    • Open the ticket in your PSA (ConnectWise, Autotask, Halo) or ITSM (ServiceNow, Jira Service Management, Freshservice). Capture requester name, manager, department, cost center, and SLA tier from the AD/HR record so downstream automation pulls the right baselines.

  2. Capture the service request type
    • The request type drives which fulfillment section is in scope and the expected SLA. Multi-type requests (e.g., new-hire bundle covering account + laptop + SaaS) should be split into linked tickets so each section's audit trail stays clean.

    Collects list
  3. Verify manager approval against role baseline
    • Confirm the requester's manager has approved in writing — PSA approval workflow, signed form, or email forwarded into the ticket. Compare against the role-based access baseline; flag any request that exceeds what peers in the same role hold.

  4. Flag privileged access requests for review
    • Privileged = Domain Admin, Tier 0 access, financial-system admin, EHR admin, or anything covered by SOX ITGC or SOC 2 access controls. These require a second approver and a CyberArk/BeyondTrust/Delinea PAM session rather than standing rights.

    Collects list
  5. Get security approval for privileged access
    • Route to IT Security or the CISO-designate per your privileged-access policy. Document the business justification, scope, and expiration date — standing privilege creep is the most common SOX ITGC audit finding.

2

User Account Provisioning

  1. Check existing identity in Entra ID
    • Search Entra ID / AD and your HR system (Workday, BambooHR, Rippling) before creating anything. Rehires, contractors-turned-employees, and name changes are the common sources of duplicate identities — duplicates cause license double-billing and orphan-permission audit findings.

  2. Provision account in directory services
    • Use SCIM provisioning from the HR system if configured; otherwise create the account in Entra ID / AD per the naming convention. Set the OU, manager attribute, and department fields — downstream GPOs and dynamic groups depend on them.

  3. Assign role-based group membership
    • Add to the role-based security groups defined in your access matrix — never grant direct ACLs. Avoid adding to Domain Users for share access; that's the path to the every-user-can-read-finance-share audit finding.

  4. Enroll user in MFA
    • Send the Microsoft Authenticator / Duo / Okta Verify enrollment link via the user's manager (not directly to the user) to prevent enrollment-link phishing. Confirm Conditional Access policies block legacy basic auth so the MFA isn't bypassable via IMAP/POP/SMTP.

3

Software Deployment

  1. Verify license entitlement in vendor portal
    • Check seat availability in the vendor admin console (M365, Adobe Admin Console, Salesforce, Autodesk) before provisioning. License true-ups during a Microsoft or Adobe audit are six-figure surprises; reconcile each request against the SAM record at provisioning time, not annually.

    Collects list
  2. Procure additional license seat
    • Submit the procurement request through the standard channel — purchasing portal, CSP partner, or vendor self-service. Capture the PO number on the ticket so finance can reconcile the cost-center charge-back.

  3. Deploy package via Intune or SCCM
    • Push from your endpoint management platform — Intune, SCCM/MECM, JAMF, or Kandji depending on OS. Avoid manual installs; they bypass the inventory record and the patch-management ring assignment.

  4. Confirm install with screenshot proof
    • Verify the install reported success in the management console and attach a screenshot or RMM check showing the application launching for the user. Self-reported success without verification leaves you with phantom installs at the next license audit.

    Collects image
4

Hardware Allocation

  1. Confirm specs against role baseline
    • Match the request to the standard hardware tier for the role — knowledge worker, engineer, design, exec. Off-baseline requests (32GB RAM for a CSM, dedicated GPU for finance) require manager justification documented in the ticket.

  2. Check asset inventory in CMDB
    • Pull from the on-hand pool in IT Glue / Hudu / ServiceNow CMDB before procuring. Returned-and-reimaged devices from offboardings should age out of the pool on a defined cycle so you're not deploying 5-year-old laptops to new hires.

  3. Provision device per gold image
    • Use Autopilot / DEP / zero-touch enrollment so the device joins Entra ID, BitLocker or FileVault keys escrow to the directory, and the MDM baseline applies on first boot. Confirm the recovery key is visible in the admin portal before shipping.

  4. Deliver tagged asset to user
    • Update the CMDB with serial, asset tag, assigned user, location, and ship date before the device leaves IT custody. Capture a signed acknowledgment of the acceptable-use policy on receipt.

5

Network Access Provisioning

  1. Validate request against least-privilege baseline
    • Map the request to a defined network segment — corp VLAN, guest, IoT, OT, or a per-app ZTNA policy. Full-tunnel VPN to flat corp network is the path to lateral movement during an endpoint compromise; prefer per-app authorization where the platform supports it.

  2. Configure VLAN firewall or VPN profile
    • Apply changes in Meraki, FortiGate, Palo Alto, or your SD-WAN controller. For ZTNA / SSL VPN, push the user-to-app mapping rather than blanket subnet access. Stage the change for the maintenance window unless it qualifies as a standard pre-approved change.

  3. Test connectivity from user endpoint
    • Verify from the user's actual device — not from a jump host. Test the application path the user actually needs, not just ping; many access issues hide behind a firewall rule that allows ICMP but blocks the app port.

  4. Log change in CAB record
    • Record the change ticket — pre-state, post-state, approver, rollback plan — in your change management system. Network-rule audits during SOC 2 Type II testing pull directly from this record; missing CAB documentation is a common qualified opinion.

6

Closure and Handoff

  1. Confirm completion with requester
    • Reach out via the channel the user actually reads — Teams DM, email, or phone for VIPs. Don't auto-close on silence; users who never confirm tend to file a duplicate ticket the following week, polluting MTTR metrics.

    Collects list
  2. Escalate to Tier 2 engineer
    • Reopen the ticket, attach the user's specific failure (error message, screenshot, time of attempt), and route to the Tier 2 queue. Do not close-and-reopen; a single ticket lifecycle is what auditors and QBR reports are calculated against.

  3. Update CMDB and IT Glue runbook
    • Sync the user-to-asset, user-to-license, and user-to-group mappings into the CMDB and your MSP documentation platform. Stale documentation is what turns a 15-minute future ticket into a two-hour archaeology session.

  4. Close ticket with resolution notes
    • Write the resolution as if the next technician will read it cold — what was requested, what was provisioned, which approvals attached, and which systems were touched. This becomes the audit trail during the next SOC 2 or SOX access-review cycle.

Use this template

Copy it to your account, customize the steps, and run it with your team in minutes.


Sections 6
Steps 25
Category Systems Administration
Price Free to start
Need a different process

Browse hundreds of free templates across every team and industry.

Back to template library

Run IT Service Request Checklist with your team

Customize the steps, assign roles, set a schedule, and keep a complete record for every run.