IT Service Request Checklist

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.