InvGate Service Management
InvGate IT Operating Process Template
The definitive starting point for your IT operating model: six core IT processes with goals, roles, RACI, BPMN process maps, step descriptions, procedure-level work instructions, InvGate implementation guidance, and compliance alignment — ready to adapt to your organization.
Getting started
Overview & how to use this template
This document defines how your IT organization operates its six core processes. It is designed to be adopted incrementally: start with Incident and Service Request, add Change, mature into Problem and Knowledge, and run Asset Management as the data backbone underneath all of them. Each process chapter is self-contained but cross-references the others, because no IT process succeeds in isolation.
How to customize
1. Click Edit template in the top-right corner.
2. Replace organization name, owners, roles, and any step that doesn't match how you work. Every table cell is editable.
3. Delete what you don't need — fewer, honest process steps beat aspirational ones.
4. Click Save my copy to download your customized version. Re-open it any time to keep editing.
5. Use Print / PDF for a formatted document to circulate for sign-off.
Adoption sequence (recommended)
Weeks 1–4: Incident + Service Request live in InvGate Service Management with the service catalog and priority matrix configured.
Weeks 5–8: Change Enablement with the no-code Workflow Builder and approvals.
Weeks 9–12: Knowledge base seeded from resolved tickets; Problem Management begins with your top 5 recurring incidents.
Weeks 13–16: IT Asset Management: InvGate Asset Management discovery deployed, inventory reconciled, lifecycle and disposal procedures live.
How this template maps to InvGateEvery process step in this document names the InvGate Service Management capability that implements it — service catalog, no-code Workflow Builder, approvals, priority matrix, SLAs/OLAs, AI Hub, knowledge base, dashboards, and the ticket audit trail. Where a step touches InvGate Asset Management, it is tagged in purple. Configuration notes assume administrator access.
A note on right-sizingThis template is sized for mid-market IT teams (roughly 5–50 IT staff). One person can hold several roles — what matters is that each accountability in the RACI is assigned to somebody. Do not create a CAB of ten people if three will do. KPI targets and P1–P4 SLA times are sensible defaults; adjust them to your organization.
The operating system, not just the parts
Inter-process connections
Most process documentation fails at the seams: incidents that never become problems, changes that surprise the service desk, knowledge that never leaves people's heads. The map below shows the handoffs that make the six processes work as one system. Each arrow is a real artifact in InvGate — a linked ticket, a related record, an updated asset, or a published article — not a good intention.
Click any process block to open it. Every arrow should exist as a linked record in InvGate. If a handoff has no artifact, it isn't a handoff — it's a hope.
The handoff contract
| From → To | Trigger | Artifact in InvGate | Receiving process must… |
|---|---|---|---|
| Incident → Problem | 3+ similar incidents in 30 days, or any major incident | Problem ticket linked to source incidents (related-requests link) | Acknowledge within 5 business days; report RCA status monthly |
| Problem → Change | Root cause confirmed and permanent fix designed | RFC created from problem record, linked bidirectionally | Assess RFC in next CAB cycle; notify Problem Manager of outcome |
| Problem → Knowledge | Workaround validated or known error confirmed | Known-error KB article, linked from the problem record | Publish to agent view within 2 business days; review at fix deployment |
| Change → Incident | Change window opens / change fails | Change calendar entry; failed-change incidents linked to the RFC | Service desk checks change schedule during diagnosis of every P1/P2 |
| Knowledge → Incident / Request | Article published or updated | KB article surfaced in portal search and agent view | Agents attach the article used to the ticket (enables deflection reporting) |
| Request → Change | Request falls outside the pre-approved catalog scope | RFC linked to the originating request | Change Manager confirms classification within 2 business days |
| Incident ↔ Request | Ticket logged under wrong type | Type conversion in InvGate Service Management (history preserved in audit trail) | Reclassify without resetting the clock visible to the user |
| Request → Asset | Hardware/software fulfilled or returned | InvGate Asset Management asset record updated (assignment, status) via InvGate Service Management–InvGate Asset Management integration | Reflect assignment same day; flag mismatches at next reconciliation |
| Change → Asset / CMDB | Change closes affecting any CI | Updated CI record in InvGate Asset Management CMDB, linked to the RFC | Verify CI accuracy at post-implementation review — a stale CMDB fails audits silently |
| Asset → Incident / Change | Diagnosis or risk assessment needs asset context | InvGate Asset Management asset/CI data (owner, model, warranty, health, business impact) surfaced on the ticket | Check warranty/health before hardware troubleshooting; use business-impact mapping in change risk scoring |
Process 1
Incident Management
Restore normal service operation as quickly as possible when something breaks, and minimize the impact on the business. Speed first, root cause later — root cause belongs to Problem Management.
Process map (BPMN)
Green circle = start · red circle = end · diamonds = decisions · purple pills = handoffs to other processes in this document.
Goals & measures
Goals
• Restore service within agreed SLA targets, prioritized by business impact.
• Give users a single, effortless way to report issues and see status.
• Capture clean incident data (category, CI, resolution) so Problem Management has something to mine.
• Contain major incidents with a rehearsed, named-role response.
KPIs (InvGate Service Management dashboard)
| Metric | Starting target |
|---|---|
| SLA resolution compliance | ≥ 95% |
| Mean time to resolve (P1 / P2) | ≤ 4 h / ≤ 8 h |
| First contact resolution rate | ≥ 60% |
| Reopen rate | ≤ 5% |
| % incidents resolved with a linked KB article | ≥ 40% |
RACI
| Activity | End User | L1 Agent | L2/L3 Specialist | Incident Manager | Service Desk Manager |
|---|---|---|---|---|---|
| Detect & report | R | C | I | I | I |
| Log, categorize & prioritize | I | R | I | A | C |
| Initial diagnosis & KB search | C | R | C | A | I |
| Escalation to L2/L3 | I | R | I | A | C |
| Investigation & resolution | C | C | R | A | I |
| Major incident command | I | C | R | A/R | C |
| Verify with user & close | C | R | I | A | I |
| Trend review → Problem candidates | — | C | C | R | A |
R Responsible (does the work) · A Accountable (owns the outcome, one per row) · C Consulted · I Informed
Process steps
| # | Step | Description | Key output |
|---|---|---|---|
| 1 | Log & categorize | Every incident becomes a ticket, whatever the channel. InvGate Service Management auto-creates from portal, AI agent (Slack/Teams), and email; agents log walk-ups manually. Category and affected service/CI are set from the category tree. | Ticket with category, service, and reporter — the unit of all later evidence |
| 2 | Prioritize | Priority = impact × urgency from the priority matrix, not the loudest voice. P1/P2 definitions are documented in procedure 1.2 and encoded in InvGate Service Management so SLA timers start correctly. | Priority with SLA targets attached |
| 3 | Initial diagnosis | L1 searches the knowledge base (agent view + AI suggestions), applies known workarounds, and gathers diagnostic basics before any escalation. Checks the change calendar for recent related changes. | Resolution at L1, or an escalation package worth receiving |
| 4 | Escalate, investigate & diagnose | Functional escalation to the right L2/L3 group via InvGate Service Management assignment; @-collaboration keeps L1 and the user informed without ping-pong. Hierarchic escalation to the Incident Manager if SLA is at risk. | Confirmed cause of this occurrence (not root cause) |
| 5 | Resolve & recover | Apply the fix or workaround; if the fix requires altering production, raise an RFC — emergency change procedure for P1s. Confirm service is actually restored, not just the error gone. | Restored service; linked RFC if change was needed |
| 6 | Document resolution | Record resolution code and notes; attach the KB article used, or flag "KB gap" to draft one. This single habit powers deflection metrics and problem analysis. | Reusable resolution data |
| 7 | Verify & close | User confirms resolution via the portal; auto-close after 3 business days of silence (configurable). Closure requires category and resolution fields — enforced by InvGate Service Management required fields. | Closed ticket with complete data |
| 8 | Review trends | Weekly: Incident Manager reviews dashboards for repeats, SLA breaches, and aging tickets. Three similar incidents in 30 days or any major incident → problem record (see Problem Management). | Problem candidates; improvement actions |
Procedures
1.1 — Logging & categorization (L1 Agent)
- If the ticket arrived via portal, AI agent, or email, verify the auto-captured details; for calls/walk-ups, create the ticket in InvGate Service Management before troubleshooting — no ticket, no work.
- Confirm the reporter, location, and affected service. Select the category from the tree (max 3 levels deep — if agents can't find a category in 10 seconds, the tree is too deep).
- Write a symptom-based summary: what the user cannot do, since when, error text verbatim. Avoid diagnosis in the summary.
- Check for duplicates and existing outages; if a matching major incident exists, link this ticket as a child so users are informed together.
- If it's actually a "how do I / I need" — convert to a Service Request (type conversion preserves history).
1.2 — Prioritization & the priority matrix (L1 Agent)
- Set Impact: High = whole org or critical business service; Medium = department/team; Low = single user.
- Set Urgency: High = work stopped, no workaround; Medium = degraded, workaround exists; Low = inconvenience.
- InvGate Service Management's priority matrix computes priority: P1 (High/High) target 4h resolve · P2 8h · P3 2 business days · P4 5 business days. Adjust targets to your SLAs and encode them in InvGate Service Management so the timers match this document.
- Never lower a priority to protect an SLA. If priority changes, note why — the audit trail records who and when automatically.
1.3 — Escalation (L1 → L2/L3)
- Escalate when: you've exhausted KB and standard diagnostics, ~15 minutes on P1/P2, or the fix requires privileges/skills you don't have.
- Reassign to the correct InvGate Service Management group (not a named individual) with the escalation package: symptoms, steps tried, diagnostics, user impact, business context.
- Use @-mentions to consult specialists without transferring ownership — the assignee remains responsible.
- SLA-risk automation: InvGate Service Management workflow notifies the Incident Manager at 75% of SLA elapsed, and the Service Desk Manager on breach.
- Never bounce a ticket back without a comment explaining what's missing. Two bounces = Incident Manager arbitrates.
1.4 — Major incident procedure (Incident Manager)
- Declare: any P1 affecting a critical service or ≥30% of users. When in doubt, declare — you can always stand down. Mark the ticket with the Major Incident flag (custom field) which triggers the MI workflow.
- Roles: Incident Manager commands; a scribe keeps the timeline in the ticket; a communications lead owns stakeholder updates. Command ≠ fixing: the commander coordinates, specialists fix.
- Communicate: post a portal banner/announcement immediately; stakeholder updates every 30 minutes for P1 (even if the update is "no update"). Users find status themselves instead of calling.
- Fix: use the emergency change procedure (see Change Enablement) for any production fix — approval recorded, even if verbal first and documented within 24h.
- Stand down: confirm restoration with affected users, close comms, and schedule the post-incident review within 5 business days. A problem record is mandatory for every major incident.
1.5 — Resolution, verification & closure (L1 Agent)
- Record the resolution code and a note a future agent could reuse: cause of occurrence, fix applied, verification done.
- Attach the KB article used. If none existed, create a draft from the ticket (see Knowledge procedure 5.1) — this is how the KB grows from real demand.
- Move to Resolved; the user gets a portal/email prompt to confirm. Confirmed → Closed. Silence → auto-close after 3 business days with notice.
- If the user reopens, the same assignee picks it up — reopens are a quality signal, tracked on the dashboard.
InvGate implementation
| Process element | InvGate Service Management capability | Configuration notes |
|---|---|---|
| Omnichannel intake | Self-service portal, AI agent for Slack / MS Teams, email-to-ticket, mobile app | Enable the AI agent where users already work; map inbound mailboxes to the incident type with default category. |
| Categorization | Category tree + required fields; AI-assisted field suggestions | Keep the tree ≤3 levels; review "Other" usage monthly — it's your taxonomy debt signal. |
| Prioritization | Priority matrix (impact × urgency) | Encode the P1–P4 definitions from procedure 1.2; hide the raw priority field from users so the matrix governs. |
| SLA timers & escalation | Rules-based SLAs/OLAs + workflow automations | Response + resolution targets per priority; automations at 75% elapsed (notify Incident Mgr) and breach (notify SD Mgr). |
| Escalation & collaboration | Assignment groups, @-mentions, collaboration on tickets | Escalate to groups, not people; OLAs per group make internal handoff performance visible. |
| Major incidents | Major Incident flag + dedicated workflow, portal announcements | MI workflow spawns comms tasks and the post-incident review task automatically; banner template pre-written. |
| Knowledge at the point of work | KB surfaced in agent view; AI response improvement | Require the "article attached / KB gap" step at resolution — it feeds deflection reporting. |
| Reporting | Integrated analytics & dashboards | Build the KPI dashboard from the table above; schedule weekly delivery to the Incident Manager. |
| Evidence | Full ticket audit trail | Every status change, assignment, and field edit is logged with actor + timestamp — your audit sample source. |
Compliance alignment
| Framework | Requirement | How this process satisfies it | Evidence in InvGate Service Management |
|---|---|---|---|
| ISO 20000-1 | §8.6.1 Incident management | Documented procedure, prioritization scheme, major-incident procedure, records kept. | This chapter + ticket records + MI reviews |
| SOC 2 | CC7.3–CC7.5 (evaluate, respond, recover from security events) | Security-relevant incidents follow the same tracked lifecycle with escalation to the security owner; recovery verified with users. | Incident population export; audit trail per sample |
| ISO 27001 | A.5.24–A.5.28 (incident planning, assessment, response, learning, evidence), A.6.8 (event reporting) | Users report via portal/AI agent (A.6.8); assessment = prioritization step; lessons feed Problem Management (A.5.27); tickets preserve evidence (A.5.28). | Tickets + linked problem records |
| NIST CSF 2.0 | RS.MA (incident management), RS.AN (analysis), RC.RP (recovery) | Triage and priority = RS.MA; diagnosis steps = RS.AN; resolve & recover step with verification = RC.RP. | MI timeline in ticket; dashboards |
| HIPAA | §164.308(a)(6) Security incident procedures | Documented identify-respond-mitigate-document procedure; suspected ePHI exposure escalates to the Privacy/Security Officer (add as required routing). | Incident records incl. response & outcomes |
ConnectionsReceives from: Change (change schedule for diagnosis; failed changes generate incidents linked to the RFC) · Knowledge (articles and known-error workarounds). Sends to: Problem (recurring incidents, every major incident) · Change (RFCs for fixes touching production) · Knowledge (KB gaps flagged at resolution) · Service Request (misclassified tickets converted).
Process 2
Service Request Management
Deliver pre-defined, pre-approved services — access, hardware, software, information — through a catalog users actually enjoy using. Requests are not incidents: nothing is broken, so the game is throughput, predictability, and automation.
Process map (BPMN)
Green circle = start · red circles = end · diamonds = decisions · purple pills = handoffs to other processes.
Goals & measures
Goals
• One unified catalog where users never have to guess whether a request goes to IT, HR, or Facilities.
• Standardize fulfillment so identical requests take identical, predictable paths.
• Automate approvals and routing — humans only touch steps that need judgment.
• Make access requests auditable end-to-end (who asked, who approved, who provisioned, when).
KPIs (InvGate Service Management dashboard)
| Metric | Starting target |
|---|---|
| Fulfillment SLA compliance | ≥ 95% |
| Average approval wait time | ≤ 1 business day |
| % requests via catalog (vs. email/walk-up) | ≥ 80% |
| Requester satisfaction (CSAT) | ≥ 4.5 / 5 |
| % catalog items with automated workflow | ≥ 70% |
RACI
| Activity | Requester | Approver | L1 Agent | Fulfillment Team | Request Fulfillment Owner |
|---|---|---|---|---|---|
| Submit request via catalog | R | I | I | — | A |
| Validate & route | I | — | R | I | A |
| Approve / reject | I | R | I | — | A |
| Fulfill (provision, deliver, configure) | C | — | C | R | A |
| Verify delivery & close | C | — | R | C | A |
| Maintain catalog & workflows | C | C | C | C | A/R |
R Responsible · A Accountable · C Consulted · I Informed
Process steps
| # | Step | Description | Key output |
|---|---|---|---|
| 1 | Submit via catalog | Requester picks the item from the unified catalog (portal or AI agent) and completes the item-specific form. Required fields are defined per item, so fulfillment never starts with missing information. | Complete, routable request record |
| 2 | Approve | The InvGate Service Management workflow requests approval only where the item requires it (cost, access, license). Approvers act from email or portal without a license. Multi-step and conditional approvals per item; auto-escalate to the Approval Manager after 2 business days. | Recorded approval decision with timestamp |
| 3 | Execute workflow | InvGate Service Management's Workflow Builder runs the fulfillment path: parallel or sequential tasks to the right teams, integrations (AD, Azure DevOps, Jira) triggered where configured. | Tasks completed in a repeatable sequence |
| 4 | Provision / deliver | The fulfillment team grants access, ships hardware, installs software. Access grants follow least privilege — the request record documents exactly what was granted. | Delivered service; asset/access records updated |
| 5 | Verify & close | Requester confirms via portal prompt; CSAT survey attached at closure. Auto-close after 3 business days of silence. | Closed request + satisfaction signal |
| 6 | Maintain the catalog | Quarterly: Request Fulfillment Owner reviews demand, retires unused items, adds frequently emailed requests as catalog items, and tightens workflows where wait time concentrates. | A catalog that matches real demand |
Procedures
2.1 — Designing a catalog item (Request Fulfillment Owner)
- Define the offering in user language ("I need a laptop"), not IT language ("hardware provisioning request").
- Build the form: only ask what fulfillment actually needs. Every extra field costs adoption.
- Decide the approval rule: none (pre-approved standard), line manager, budget owner, or system owner — encode it in the item's workflow, not in agents' heads.
- Build the fulfillment workflow in the drag-and-drop Workflow Builder: tasks, assignment groups, conditions, integrations. Test with a dry run before publishing.
- Attach the SLA (fulfillment target) and the related KB article ("what to expect").
- Publish to the right audience — InvGate Service Management supports audience-scoped catalog visibility (e.g., only managers see "new hire onboarding").
2.2 — Access requests (Fulfillment Team)
- Verify the approval chain completed in the ticket — never grant access on a verbal ok. The approval record is the control auditors sample.
- Grant exactly what was requested and approved; document the entitlement granted (system, role, permission level) in the ticket.
- For privileged access, add the system owner as a second approver in the item workflow.
- Set a review date for temporary access; an InvGate Service Management automation creates the revocation task automatically.
- Offboarding is the mirror image: a single "leaver" catalog item spawns revocation tasks across all systems — target completion within 1 business day of departure.
2.3 — Handling requests outside the catalog (L1 Agent)
- If a request arrives by email/chat for something not in the catalog, log it under a generic "Other request" item — never fulfill untracked work.
- If it changes production services or infrastructure, convert the work into an RFC (see Change Enablement) and link it to the request.
- Tag it "catalog gap". Three of the same gap in a quarter = the Request Fulfillment Owner builds a proper catalog item.
InvGate implementation
| Process element | InvGate Service Management capability | Configuration notes |
|---|---|---|
| Unified catalog | Service catalog across IT, HR, Facilities, Finance | One catalog, department-scoped categories — users should never need to know which team owns fulfillment. |
| Request intake | Portal, AI agent for Slack/Teams, mobile app | The AI agent can raise catalog requests conversationally — highest-adoption channel for simple items. |
| Approvals | Multi-step, conditional approvals; approve from email; approval reassignment; cancellation branch | Approvers don't consume licenses. Configure the third branch (canceled/expired) so stuck approvals route to the Approval Manager instead of dying silently. |
| Fulfillment automation | No-code drag-and-drop Workflow Builder | Reusable building blocks per fulfillment pattern; mini-map/search helps maintain larger workflows. |
| Asset linkage | InvGate Asset Management integration (Insight) | InvGate Asset ManagementHardware items update asset assignment automatically — request record and asset record stay consistent. |
| Measurement | SLAs on fulfillment, workflow time measurement, CSAT surveys, dashboards | Measure total workflow time initiation→completion to find where waits concentrate (usually approvals). |
| Evidence | Approval records + ticket audit trail | The who-approved-what-when chain is the core evidence for access-control audits. |
Compliance alignment
| Framework | Requirement | How this process satisfies it | Evidence in InvGate Service Management |
|---|---|---|---|
| ISO 20000-1 | §8.6.2 Service request management | Requests recorded, prioritized, fulfilled to defined procedures; users kept informed of progress. | Request records + portal status |
| SOC 2 | CC6.1–CC6.3 (logical access: provisioning, authorization, removal) | Access granted only through approved catalog requests; offboarding item revokes access; every grant traceable to an approval. | Access-request population with approval chain per sample |
| ISO 27001 | A.5.16 identity management, A.5.18 access rights | Joiner/mover/leaver catalog items implement the identity lifecycle; entitlements documented per grant. | JML request records; revocation tasks |
| NIST CSF 2.0 | PR.AA (identity management, authentication & access control) | Access provisioning is authorized, least-privilege, and revocable on schedule via automation. | Approval + revocation records |
| HIPAA | §164.308(a)(3)–(4) workforce security & information access management | Access to systems holding ePHI granted via authorized, documented requests; terminated within 1 business day at departure. | Access & termination request records |
ConnectionsReceives from: Knowledge (how-to articles deflect simple requests; "what to expect" articles per item) · Incident (misclassified tickets converted). Sends to: Change (non-standard requests become RFCs) · Asset Management (assignment updates on hardware/software fulfillment) · Knowledge (catalog-gap and FAQ signals).
Process 3
Change Enablement
Maximize the number of successful changes while protecting the live environment. The goal is not to slow change down — it is to make risk visible, decisions fast, and every change to production traceable to an authorization.
Process map (BPMN)
Three routes by risk: standard (pre-approved), normal (assessed, CAB-advised), emergency (act fast, document within 24 h). Purple pills = handoffs.
Goals & measures
Goals
• Every production change is assessed, authorized, scheduled, and recorded — no exceptions, including emergencies.
• Route by risk: standard changes flow without friction, normal changes get proportionate review, emergencies get speed plus retrospective rigor.
• Grow the standard-change library so the CAB reviews less, not more, over time.
• Give the service desk a change calendar it actually checks.
KPIs (InvGate Service Management dashboard)
| Metric | Starting target |
|---|---|
| Change success rate | ≥ 95% |
| % changes that are standard (pre-approved) | ≥ 50%, growing |
| Emergency changes as % of all changes | ≤ 10% |
| Unauthorized changes detected | 0 |
| Incidents caused by change | Tracked, trending down |
RACI
| Activity | Initiator | Change Manager | CAB | Implementer | Service Owner |
|---|---|---|---|---|---|
| Raise & document RFC | R | A | — | C | I |
| Classify (standard / normal / emergency) | C | A/R | — | I | I |
| Risk & impact assessment | R | A | C | C | C |
| Authorize normal change | I | A/R | C | I | C |
| Schedule on change calendar | C | A/R | I | C | I |
| Build, test & implement | C | A | — | R | I |
| Post-implementation review | C | A/R | C | C | C |
R Responsible · A Accountable · C Consulted · I Informed
Process steps
| # | Step | Description | Key output |
|---|---|---|---|
| 1 | Raise RFC | Initiator submits the RFC via the catalog: what, why, when, affected services/CIs, implementation plan, test evidence, backout plan. Incomplete RFCs are returned, not queued. | Assessable RFC |
| 2 | Validate & classify | Change Manager routes by type: Standard (in the pre-approved library) flows straight to implementation; Emergency (active P1/major incident) takes the expedited path; everything else is Normal. | Classified RFC on the right track |
| 3 | Assess risk & impact | Initiator + Change Manager score likelihood × impact, considering affected services, timing, dependencies, and backout confidence. Low-risk normal changes can be authorized by the Change Manager alone. | Risk score driving the review depth |
| 4 | CAB review (high risk only) | CAB reviews asynchronously in InvGate Service Management where possible, meeting only for genuinely contentious changes. The CAB advises; the Change Manager decides. Standing agenda: failed changes, emergency changes, calendar conflicts. | Documented recommendation |
| 5 | Authorize & schedule | Approval recorded in InvGate Service Management (approver needs no license). Scheduled in the change calendar respecting freeze periods and business events; conflicts on shared CIs flagged. | Authorized, visible change window |
| 6 | Build & test | Implementer prepares and tests in non-production, including a backout rehearsal for high-risk changes. Test evidence attached to the RFC. | Tested change + proven backout |
| 7 | Implement | Execute in the approved window only. If the window is missed, reschedule — don't slide silently. Verify success criteria; if failing and unfixable in-window, back out. | Deployed (or cleanly backed-out) change |
| 8 | Review & close | Post-implementation review: success criteria met? Incidents caused? Docs and CI records updated? Failed changes get a mini-retrospective; repeat offenders become problem records. | Closed RFC with outcome recorded |
Procedures
3.1 — Risk assessment scoring (Change Manager)
- Score Likelihood of failure 1–3: proven+rehearsed / done before / novel or complex.
- Score Impact if it fails 1–3: single team / department or important service / org-wide or critical service.
- Risk = L × I. 1–2: Change Manager authorizes directly. 3–4: Change Manager + Service Owner. 6–9: CAB review required.
- Record scores in the RFC's custom fields so the InvGate Service Management workflow routes the approval path automatically.
- Auto-escalators regardless of score: touches authentication, backup, or network core; no tested backout; during a freeze period.
3.2 — Standard change library (Change Manager)
- Candidate criteria: performed ≥3 times as a normal change with 100% success, documented procedure, low impact, proven backout.
- Approve the candidate once at the CAB — that approval covers all future executions.
- Build it as a catalog item with its own workflow so execution is identical every time; the record is created automatically.
- Audit quarterly: any standard change that failed since last review returns to normal-change handling until re-proven.
- Target: the library grows every quarter. A shrinking CAB agenda is the health metric of this process.
3.3 — Emergency change (Change Manager / Incident Manager)
- Valid only to resolve an active P1/major incident or imminent security exposure. "I forgot to raise it earlier" is not an emergency.
- Get verbal/chat authorization from the Change Manager or designated deputy (the ECAB — two named people minimum, with an on-call rotation).
- Implement with a second person aware (no solo emergency changes on critical systems).
- Create the RFC in InvGate Service Management within 24 hours, backdated honestly, linked to the driving incident, with the approval noted.
- Every emergency change is reviewed at the next CAB. More than ~10% emergency rate means planning is failing — treat as a problem.
3.4 — Change calendar & freeze periods (Change Manager)
- Maintain the forward schedule of change in InvGate Service Management; the service desk checks it during diagnosis of every P1/P2 (procedure 1.3).
- Declare freeze periods (fiscal close, peak season, major business events) at least a quarter ahead; only emergency changes run during a freeze.
- Flag conflicts: two changes touching the same service/CI in overlapping windows require Change Manager arbitration.
- Publish a weekly "changes this week" announcement to the portal for business visibility.
InvGate implementation
| Process element | InvGate Service Management capability | Configuration notes |
|---|---|---|
| RFC intake | Change request type + catalog item with required fields | Make plan/backout/test-evidence required fields — incomplete RFCs can't be submitted. |
| Classification & routing | No-code Workflow Builder with conditional branches | One workflow, three branches (standard/normal/emergency) driven by the type field and risk score. |
| Approvals | Multi-option approvals; approval branching (approved/rejected/canceled); approval reassignment | CAB members approve from email without licenses; the canceled/expired branch returns the RFC to the Change Manager rather than stalling. |
| Risk scoring | Custom fields + automation rules | Likelihood, impact, and computed risk as fields; automations pick the approval path per procedure 3.1. |
| Scheduling | Change calendar / scheduled workflows | Freeze periods as recurring calendar blocks; weekly portal announcement automated. |
| Guardrails | Automated process guardrails; status-based permissions | Implementation tasks can't start until approval is recorded — the control auditors test, enforced by the tool. |
| Evidence | Audit trail + approval records + workflow history | The full population for SOC 2 CC8.1 sampling exports from one report: all changes with approver, date, and outcome. |
Compliance alignment
| Framework | Requirement | How this process satisfies it | Evidence in InvGate Service Management |
|---|---|---|---|
| ISO 20000-1 | §8.5.1 Change management | Change policy (this chapter), classification criteria, approval before deployment, review of outcomes. | RFC population + PIR notes |
| SOC 2 | CC8.1 (changes authorized, designed, tested, approved, implemented) | Guardrails prevent unapproved implementation; test evidence attached pre-approval; emergency path preserves authorization with 24 h documentation. | Full change export: approver, timestamps, test evidence per sample |
| ISO 27001 | A.8.32 Change management | All changes to information-processing facilities follow the documented, risk-assessed, authorized procedure. | Change records + risk scores |
| NIST CSF 2.0 | PR.PS (platform security — configuration & change), ID.RA (risk assessment) | Configuration changes controlled and logged; risk scored per change with escalating authority. | Risk-scored RFCs; calendar |
| HIPAA | §164.308(a)(8) Evaluation; §164.306(e) security measure maintenance | Technical changes affecting ePHI systems are evaluated for security impact before implementation, with documented outcomes. | RFCs affecting ePHI-scoped CIs |
ConnectionsReceives from: Problem (RFCs for permanent fixes) · Incident (emergency changes; fixes needing change control) · Service Request (non-standard requests). Sends to: Incident (change schedule for diagnosis; failed-change incidents linked to the RFC) · Knowledge (updated runbooks and documentation post-change) · Asset/CMDB (CI updates at closure).
Process 4
Problem Management
Find and remove the root causes of incidents so they stop happening. Incident Management buys time; Problem Management buys peace. This is the process that turns a firefighting team into an engineering organization.
Process map (BPMN)
Reactive triggers (trends, major incidents) and proactive triggers feed one pipeline. Purple pills = handoffs to Knowledge and Change.
Goals & measures
Goals
• Reduce recurring incident volume by eliminating root causes.
• Publish workarounds and known errors so incidents that can't yet be prevented are at least resolved fast.
• Guarantee every major incident gets a root cause analysis — blameless, written down, acted on.
• Feed a steady stream of well-justified RFCs into Change Enablement.
KPIs (InvGate Service Management dashboard)
| Metric | Starting target |
|---|---|
| Recurring-incident volume (top 10 categories) | −25% year over year |
| Major incidents with completed RCA in 5 days | 100% |
| Open problems with published workaround | ≥ 80% |
| Average problem age | ≤ 90 days |
| Incidents linked to a problem record | Tracked, growing |
RACI
| Activity | L1 Agent | Problem Manager | Technical SME | Change Manager | Service Owner |
|---|---|---|---|---|---|
| Identify problem candidates (trends, MI) | C | A/R | C | — | C |
| Log, categorize & prioritize problem | I | A/R | C | — | I |
| Root cause investigation | C | A | R | — | C |
| Document workaround / known error | I | A | R | — | I |
| Raise RFC for permanent fix | — | A/R | C | C | C |
| Verify fix & close problem | C | A/R | C | I | I |
R Responsible · A Accountable · C Consulted · I Informed
Process steps
| # | Step | Description | Key output |
|---|---|---|---|
| 1 | Identify & log | Weekly trend review of the incident dashboard (top categories, repeat CIs, repeat users); mandatory problem record for every major incident; proactive candidates from monitoring and vendor advisories. Source incidents linked to the problem. | Problem record with linked evidence |
| 2 | Categorize & prioritize | Priority by aggregate pain: incident frequency × impact × cost of workaround. A daily 5-minute annoyance for 200 people outranks a rare inconvenience for one VIP. | Ranked problem backlog |
| 3 | Investigate root cause | SME-led, Problem-Manager-facilitated analysis: timeline reconstruction from ticket audit trails, 5 Whys, change correlation (what changed before it started?). Time-boxed — findings documented even when inconclusive. | Root cause statement (or documented dead ends) |
| 4 | Publish workaround / known error | The moment a workaround is validated, it becomes a known-error KB article visible to agents (and to users when self-serviceable). Don't wait for the permanent fix to share the relief. | Known-error article linked to the problem |
| 5 | Raise RFC for permanent fix | If the fix is justified (cost of fix < cost of living with it), raise an RFC linked to the problem. If not justified, record the accepted-risk decision and review quarterly — that's a legitimate outcome, silence is not. | RFC in Change, or documented risk acceptance |
| 6 | Verify & close | After the fix deploys, watch for recurrence over an agreed period (e.g., 30 days). No recurrence → close the problem, retire or update the known-error article, and note the incident volume delta. | Closed problem with measured effect |
Procedures
4.1 — Weekly trend review (Problem Manager)
- Open the incident dashboard filtered to the last 30 days: top categories by volume, top affected CIs/services, SLA breach clusters, reopen clusters.
- Apply the trigger rule: 3+ similar incidents in 30 days → problem candidate. "Similar" = same category + same service/CI or same symptom signature.
- For each candidate: create the problem record, link the source incidents (related-requests), and add a one-line hypothesis.
- Review the open problem backlog: anything untouched for 30 days gets a status decision — active, parked (with reason), or closed.
- Publish a monthly one-page summary to IT leadership: problems opened/closed, incident volume avoided, top 3 risks.
4.2 — Root cause analysis session (Problem Manager facilitates)
- Prepare: timeline from the ticket audit trail(s), related change records, monitoring data. Send to participants beforehand.
- Run blameless: the question is "what allowed this?", never "who did this?". Name systems and gaps, not people.
- Walk the timeline, then apply 5 Whys to the pivotal event. Stop at a cause you can act on — "human error" is never a root cause; ask what made the error easy to make and hard to catch.
- Distinguish: root cause vs. contributing factors vs. detection gap (why didn't we know sooner?). Each may spawn its own action.
- Record findings in the problem ticket: cause, evidence, actions with owners and dates. Actions become tasks or RFCs — never bullet points that die in a document.
4.3 — Known error record standard (Problem Manager + Knowledge Manager)
- Title states the symptom the agent will search for, not the cause ("VPN disconnects every ~60 minutes" not "DHCP lease misconfiguration").
- Body: symptoms → affected services/versions → workaround steps (numbered, tested) → root cause (if known) → permanent fix status with RFC link.
- Publish to the agent view immediately; publish a user-facing variant if the workaround is safely self-serviceable.
- The article and problem record link to each other; when the fix deploys, update or retire the article the same week.
InvGate implementation
| Process element | InvGate Service Management capability | Configuration notes |
|---|---|---|
| Problem records | Problem request type with its own workflow & statuses | Statuses: Logged → Investigating → Known Error → Fix in Progress → Verifying → Closed. Add a "parked (risk accepted)" status with mandatory reason field. |
| Incident linkage | Related requests / parent-child links | Linking incidents to problems is what makes "incidents avoided" measurable — enforce it in the trend-review procedure. |
| Trend detection | Dashboards + saved views by category/CI/date | Build the "repeat offenders" view once; the weekly review then takes 20 minutes, not 2 hours. |
| Known errors | Knowledge base with agent-only visibility scopes | Known-error template as a KB article type; agent view surfaces matches during incident diagnosis. |
| Fix tracking | Problem ↔ RFC bidirectional links | The problem can't close until the linked RFC closes — enforce via workflow condition. |
| Evidence | Audit trail, linked-record graph, dashboards | RCA findings live in the ticket, not in slide decks — one system of record for auditors and engineers alike. |
Compliance alignment
| Framework | Requirement | How this process satisfies it | Evidence in InvGate Service Management |
|---|---|---|---|
| ISO 20000-1 | §8.6.3 Problem management | Problems identified and recorded, root causes analyzed, known errors and resolutions recorded and communicated. | Problem lifecycle records |
| SOC 2 | CC7.4–CC7.5 (respond, recover, and remediate identified issues) | Root-cause remediation of security-relevant incidents is tracked to completion through linked problem → RFC records. | MI → problem → RFC chains |
| ISO 27001 | A.5.27 Learning from information security incidents | Mandatory RCA on major incidents institutionalizes learning; actions tracked as tickets with owners. | RCA records with actions |
| NIST CSF 2.0 | ID.IM (improvement), RS.AN (incident analysis) | Post-incident analysis feeds improvements; problem backlog is the documented improvement pipeline. | Monthly problem summary; backlog |
| HIPAA | §164.308(a)(1)(ii)(D) Information system activity review | Weekly trend review of system activity (incident patterns) with documented follow-up on anomalies. | Trend-review outputs; problem records |
ConnectionsReceives from: Incident (recurring incidents, mandatory major-incident RCA) · monitoring and vendor advisories (proactive). Sends to: Change (RFCs for permanent fixes) · Knowledge (known-error and workaround articles) · Incident (known errors speed diagnosis; problem closure reduces volume).
Process 5
Knowledge Management
Capture what your team knows and put it where the work happens — the portal, the AI agent, and the agent's ticket view. Knowledge is the multiplier on every other process: it deflects tickets before they exist and speeds up the ones that do.
Process map (BPMN)
The loop matters more than the line: publish → measure → review → update. Purple pills = connections to the other four processes.
Goals & measures
Goals
• Grow the knowledge base from real demand — resolved tickets and flagged gaps, not aspirational wiki projects.
• Keep articles trustworthy: reviewed on a cycle, retired when stale. A wrong article is worse than no article.
• Deflect: users self-solve via portal search and the AI agent before raising a ticket.
• Accelerate: agents resolve with articles instead of tribal memory, making L1 as capable as its knowledge.
KPIs (InvGate Service Management dashboard)
| Metric | Starting target |
|---|---|
| Self-service deflection rate | ≥ 15%, growing |
| % incidents resolved with linked article | ≥ 40% |
| Articles past review date | ≤ 10% |
| Article helpfulness rating | ≥ 80% positive |
| New articles per month (from tickets) | Tracked, steady |
RACI
| Activity | Author (any IT staff) | SME Reviewer | Knowledge Manager | L1 Agent | End User |
|---|---|---|---|---|---|
| Identify knowledge gaps | C | C | A | R | C |
| Draft article | R | C | A | C | — |
| Technical review | C | R | A | — | — |
| Approve & publish | I | C | A/R | I | I |
| Use & give feedback | — | — | A | R | R |
| Periodic review / retire | C | R | A/R | C | — |
R Responsible · A Accountable · C Consulted · I Informed
Process steps
| # | Step | Description | Key output |
|---|---|---|---|
| 1 | Capture & draft | Articles originate from demand: "KB gap" flags at incident resolution (procedure 1.5), catalog gaps, known errors from Problem, and new-service launches. Author drafts from the ticket using the article template — 20 minutes, not a writing project. | Draft tied to demonstrated demand |
| 2 | Review | SME confirms technical accuracy (are the steps right, on current versions?); Knowledge Manager checks findability and standards (title, audience, category). One combined pass for simple articles — keep the bar proportionate. | Accurate, findable article |
| 3 | Publish | Audience-scoped: user-facing (portal + AI agent), agent-only (internal steps, known errors), or admin-only. Every article gets a review date at publish (default: 6 months; 3 for fast-changing topics). | Live article with an expiry conscience |
| 4 | Consume | Users hit articles via portal search and the AI agent's conversational answers; agents see suggested articles in the ticket view and attach the one they used (this powers step 5). | Deflected tickets; faster resolutions |
| 5 | Measure | Monthly: views, helpfulness ratings, attach-rate, searches with zero results (the demand signal for missing articles), deflection estimate. | Prioritized authoring & fix list |
| 6 | Review, update or retire | At review date or on feedback: verify, update, or retire. Retired articles are archived, not deleted — auditors and problem investigations sometimes need history. | A KB that stays trustworthy |
Procedures
5.1 — Creating an article from a resolved ticket (any agent)
- From the resolved ticket flagged "KB gap", create the article draft — carry over symptoms, environment, and resolution steps.
- Title = what the next person will type in the search box. Test: would you find this article with the words from the original ticket?
- Structure: Symptoms → Environment/versions → Steps (numbered, one action each, with screenshots where a click is ambiguous) → Expected result → If this didn't work (escalation path).
- Strip anything user-specific (names, hostnames with real data, credentials — never credentials).
- Set audience (user vs. agent) and submit for review. Link the article to the source ticket.
5.2 — Monthly KB health review (Knowledge Manager)
- Pull the KB dashboard: articles past review date, lowest-rated articles, most-viewed articles, zero-result searches.
- Past-due articles: assign re-verification to the owning SME with a 2-week deadline; auto-unpublish user-facing articles 30 days past due (stale public articles destroy trust fastest).
- Zero-result searches: the top recurring ones become the authoring backlog — this is your users telling you exactly what to write.
- Low-rated articles: read the feedback comments, fix or retire within the month.
- Report the four KPI numbers to the Service Desk Manager; celebrate the top-contributing authors (InvGate Service Management gamification does this visibly).
5.3 — New service knowledge package (Knowledge Manager + Service Owner)
- No service goes live without its knowledge package: user "how do I" article, agent troubleshooting article, and the catalog item's "what to expect" text.
- Add this as a task in the change workflow for service-introducing changes — the RFC can't close without it.
- Schedule the first review at 30 days post-launch (new-service articles are always wrong somewhere).
InvGate implementation
| Process element | InvGate Service Management capability | Configuration notes |
|---|---|---|
| Authoring from tickets | Create KB article from ticket; article templates | Template per article type (how-to, troubleshooting, known error, FAQ) keeps quality consistent at speed. |
| Review & approval | Article approval workflow with states (draft → review → published) | Simple two-step flow; don't build a publishing bureaucracy that makes agents stop contributing. |
| Audience scoping | Visibility by audience/group; agent-only articles | Known errors and internal procedures agent-only; end-user articles written in user language. |
| Delivery at point of need | Portal search, AI agent (Slack/Teams) answers, suggested articles in agent view | The AI agent answers from published articles — KB quality directly sets AI answer quality. Stale KB = confidently wrong bot. |
| Feedback & measurement | Ratings, view counts, search analytics, dashboards | Track attach-rate via the "article used" habit from Incident procedure 1.5. |
| Contribution culture | Gamification (points, badges, leaderboards) | Reward published-and-used articles, not raw article counts — you want useful, not many. |
Compliance alignment
| Framework | Requirement | How this process satisfies it | Evidence in InvGate Service Management |
|---|---|---|---|
| ISO 20000-1 | §7.6 Knowledge | Knowledge needed to operate services is identified, maintained, and available to those who need it. | Published KB with review dates |
| SOC 2 | CC2.2–CC2.3 (internal & external communication of information) | Operating procedures and user guidance are documented, current, and communicated through the portal. | Article review history |
| ISO 27001 | A.5.37 Documented operating procedures | Operational procedures (agent-scoped articles and this document) are documented, reviewed on a cycle, and access-controlled by audience. | Agent-only article set + review log |
| NIST CSF 2.0 | PR.AT (awareness & training) | Current, role-scoped guidance supports consistent secure operation; measurable consumption. | Usage analytics by audience |
| HIPAA | §164.308(a)(5) Security awareness (supporting control) | Security-relevant procedures and reminders published and maintained; article history shows currency. | Article version history |
ConnectionsReceives from: Incident (KB gaps flagged at resolution) · Problem (known errors and workarounds) · Change (documentation updates as workflow tasks) · Service Request (catalog gaps, FAQ demand). Sends to: Incident & Service Request (deflection via portal/AI agent; faster agent resolution) · every process (the AI agent is only as good as this process keeps the KB).
Process 6 · InvGate Asset Management
IT Asset Management
Know what you own, where it is, who has it, what it costs, and prove it — from acquisition to certified disposal. Asset Management is the data backbone under the other five processes, implemented in InvGate Asset Management.
Process map (BPMN) — the asset lifecycle
Purple tasks = InvGate Asset Management-managed lifecycle stages · blue pills = connections into the ITSM processes (note the reversed color convention in this chapter: here, ITSM is the "other" process).
Goals & measures
Goals
• One trustworthy inventory: every hardware, software, SaaS, and cloud asset discovered, recorded, and owned by someone.
• Full lifecycle control — plan, acquire, receive, deploy, manage, retire, dispose — with a record at every stage.
• Financial visibility: cost, depreciation, contracts, and license position ready for budget and audit without a spreadsheet scramble.
• Risk reduction: no unmanaged devices, no unlicensed software, no data walking out the door on retired drives.
KPIs (InvGate Asset Management dashboard)
| Metric | Starting target |
|---|---|
| Inventory accuracy (physical vs. recorded) | ≥ 98% |
| Discovery coverage (endpoints reporting) | ≥ 99% |
| Assets with named owner/assignment | 100% |
| Disposal certificates on file | 100% of disposed assets |
| Contract renewals actioned ≥ 30 days ahead | 100% |
| Unused licenses reclaimed per quarter | Tracked, growing |
RACI
| Activity | IT Asset Manager | Procurement / Finance | IT Technician | Security / GRC | End User (Custodian) |
|---|---|---|---|---|---|
| Plan & budget (refresh cycles, demand) | R | A/R | C | C | — |
| Procure (approved vendors, PO) | C | A/R | I | — | I |
| Receive, tag & record | A | I | R | — | — |
| Deploy & assign | A | — | R | C | C |
| Reconcile inventory (discovery vs. records) | A/R | I | C | C | — |
| License & compliance position | A/R | C | I | C | — |
| Contract & renewal management | R | A | — | I | — |
| Retire, sanitize & dispose | A | I | R | C | C |
R Responsible · A Accountable · C Consulted · I Informed
Process steps
| # | Step | Description | Key output |
|---|---|---|---|
| 1 | Plan & budget | Annual and rolling: refresh cycles by asset class (e.g., laptops 4 years), demand forecast from headcount and project plans, budget by department using InvGate Asset Management cost-allocation data. Standards defined here (approved models, configurations) make every later step cheaper. | Approved standards, refresh calendar, budget |
| 2 | Procure | Purchases only through approved vendors against defined standards, initiated from the service catalog where possible. PO number, vendor, cost, warranty, and contract recorded — acquisition is where clean asset data is born. | PO + contract data attached to incoming assets |
| 3 | Receive, tag & record | Physical receipt verified against PO; asset tagged and created in InvGate Asset Management with serial, model, cost, warranty (auto-detected where supported), location, and status "In stock". Non-connected devices (monitors, peripherals, lab gear) recorded too — if it can be lost or audited, it's an asset. | Complete asset record before first use |
| 4 | Deploy & assign | Configured to standard (deployment plans for software/patches), assigned to a named user or location, status "In use". Assignment recorded at handover — this is the accountability chain HIPAA and SOC 2 auditors follow. | Asset with a named custodian |
| 5 | Manage in service | The long middle: automated discovery keeps records honest (procedure 6.2), health-status rules and policy enforcement flag drift, contracts and warranties tracked with alerts, license position monitored via normalization and metering, financial data (depreciation) accrues automatically. | A living inventory that matches reality |
| 6 | Recover & sanitize | At end of life, leaver offboarding, or refresh: asset recovered (tied to the leaver catalog item), data sanitized per NIST SP 800-88 method appropriate to media and data sensitivity, sanitization recorded on the asset. Reusable assets return to stock. | Sanitized asset; documented method + operator |
| 7 | Dispose | Physical disposal only via certified ITAD partner (R2/e-Stewards); certificate of destruction/recycling attached to the asset record; status "Disposed"; finance notified for book removal. The asset record is retained — disposal ends the asset, not the evidence. | Closed lifecycle with audit-proof paper trail |
Procedures
6.1 — Receiving, tagging & recording (IT Technician)
- Verify delivery against the PO (model, quantity, condition); report discrepancies to Procurement before accepting.
- Apply the asset tag (barcode/QR). Tag before the asset leaves the receiving area — untagged assets in circulation are how inventories rot.
- Create the record in InvGate Asset Management: serial number, model, PO/cost, vendor, warranty (auto-detected where supported — verify), location, status "In stock". Link the linked catalog request if one exists.
- Record non-connected assets (monitors, docks, lab and network gear) manually or via bulk import — discovery won't see them, but auditors will.
- For software: record license entitlements (quantity, metric, contract) in InvGate Asset Management at purchase, before deployment. Entitlement first, install second.
6.2 — Discovery & reconciliation (IT Asset Manager, weekly)
- Confirm discovery health: agent check-in rate and network discovery coverage. Chase the gap — every silent agent is a blind spot.
- Reconcile discovered vs. recorded: ghosts (recorded but not discovered in 30 days → locate, mark in-storage, or investigate as lost/stolen) and zombies (discovered but not recorded → tag and record, or isolate as unauthorized).
- Review health-status rule violations (missing encryption, outdated OS, unauthorized software) and open remediation tasks — route security-relevant findings to Security/GRC.
- Verify assignment accuracy for a sample of moved/returned assets against recent Service Request activity.
- Log the reconciliation result (accuracy %) — the trend is your inventory-accuracy KPI and your audit evidence of an operating control.
6.3 — License compliance review (IT Asset Manager, monthly)
- Run the license position by product: entitlements (from contracts in InvGate Asset Management) vs. installs/usage (from normalization + metering).
- Over-deployed: remediate before it becomes a true-up — uninstall, reharvest, or buy. Document the decision.
- Under-used: reclaim licenses unused >60 days (InvGate Asset Management low-usage reports); feed savings into the quarterly program report.
- SaaS: review usage vs. seats ahead of each renewal (procedure 6.4) — renewal negotiations without usage data are donations.
- Keep the position export with the month's date — a dated, repeatable license position is exactly what a software auditor asks for first.
6.4 — Contract & renewal management (IT Asset Manager + Procurement)
- Every contract (support, warranty, lease, SaaS, maintenance) lives in InvGate Asset Management with dates, cost, renewal terms, and the assets/licenses it covers.
- Alerts at 90/60/30 days before expiry route to the Asset Manager and contract owner.
- At 90 days: pull usage and coverage data; decide renew / renegotiate / drop with the business owner. At 30 days: escalate anything undecided to Procurement leadership.
- Auto-renewal clauses are flagged at intake so the 90-day review happens before the opt-out window closes, not after.
6.5 — Secure retirement & disposal (IT Technician + IT Asset Manager)
- Trigger: refresh calendar, failure beyond economic repair, or leaver offboarding (recovery task from the leaver catalog item — Process 2).
- Recover the asset and set status "Retired — pending sanitization". Remove from active management (MDM, domain, licenses reclaimed).
- Sanitize per NIST SP 800-88 by media and sensitivity: Clear (standard overwrite) / Purge (crypto-erase, degauss) / Destroy (shred) — ePHI and regulated data always Purge or Destroy. Record method, operator, and date on the asset.
- Dispose only via the certified ITAD partner (R2 or e-Stewards); obtain and attach the certificate of data destruction/recycling to the asset record.
- Set status "Disposed", notify Finance for book removal, and retain the record — the evidence outlives the asset.
- Never: donate, resell, or bin a device that hasn't completed steps 3–4. One skipped laptop is a breach notification waiting to happen.
InvGate implementation
| Process element | InvGate Asset Management capability | Configuration notes |
|---|---|---|
| Discovery | Agent-based + network discovery; SCIM/SSO for identity | Deploy the agent via your software distribution at onboarding; schedule network discovery per subnet; alert on agents silent >7 days. |
| Full inventory incl. offline assets | Non-connected device records, smart tags, bulk import | Smart tags for refresh waves, projects, and audit scopes — they turn one inventory into many views. |
| Software intelligence | Software normalization, license metering, low-usage reports | Normalization cleans raw install data into products; metering powers reclamation and true-up defense. |
| Health & policy | Health-status rules, policy enforcement engine, remediation actions | Start with 5 rules that matter (encryption on, OS supported, agent present, AV current, no unauthorized admin tools); expand quarterly. |
| Contracts & warranties | Contract tracking, automatic warranty detection, expiration alerts | 90/60/30 alert cadence; auto-renewal flag as a required field at contract intake. |
| Financials | Automated depreciation, cost allocation, financial dashboards | Set depreciation schedules per asset class once; department/location allocation makes showback possible. |
| CMDB & business context | Business Applications CMDB with impact mapping | Map critical business apps to their supporting CIs — this is what Change risk scoring (procedure 3.1) reads. |
| Software deployment | Deployment plans for software, patches, updates | Standard-build deployment at step 4; patch waves as scheduled plans. |
| ITSM integration | InvGate Service Management ↔ InvGate Asset Management (Insight) integration | Asset context on tickets; catalog fulfillment updates assignments; CI links on RFCs. This integration is the connective tissue of the whole template. |
| Evidence | Audit-ready reports, timestamped logs, role-based access (ACLs) | Scope auditor access read-only via ACLs; saved reports for inventory, license position, and disposal register. |
| Deployment model | Cloud, on-prem, hybrid, or air-gapped | Choose per data-residency and security requirements. |
Compliance alignment
| Framework | Requirement | How this process satisfies it | Evidence in InvGate Asset Management |
|---|---|---|---|
| ISO 20000-1 | §8.2.5 Asset management; §8.2.6 Configuration management | Assets used to deliver services are managed to meet obligations; CIs recorded with controlled updates (via Change). | Asset register; CMDB with RFC-linked updates |
| SOC 2 | CC6.1 (asset inventory underpinning access control); CC6.5 (disposal — data destroyed before assets leave control) | Complete inventory with ownership; sanitization + certified destruction before any asset exits; certificates retained. | Inventory export; disposal register with certificates |
| ISO 27001 | A.5.9 inventory of assets; A.5.11 return of assets; A.7.10 storage media; A.7.14 secure disposal/re-use | Discovery-verified inventory with owners (A.5.9); leaver recovery task (A.5.11); media sanitized per NIST 800-88 before re-use or disposal (A.7.10/A.7.14). | Reconciliation logs; recovery tasks; sanitization records |
| NIST CSF 2.0 | ID.AM (hardware & software inventories maintained) | Automated discovery keeps hardware (ID.AM-01) and software (ID.AM-02) inventories current; unauthorized assets surfaced weekly. | Discovery coverage + reconciliation trend |
| HIPAA | §164.310(d) Device & media controls (disposal, re-use, accountability, movement) | Assignment records provide accountability for devices holding ePHI; movements tracked; disposal and re-use gated on documented sanitization. | Assignment history; sanitization + disposal records |
ConnectionsReceives from: Service Request (fulfillment and leaver items drive assignment changes and recovery) · Change (CI updates at RFC closure; refresh projects) · Procurement/Finance (POs, contracts, budgets). Sends to: Incident & Problem (asset, warranty, health, and history context on every hardware ticket) · Change (business-impact mapping feeds risk scoring; refresh calendar generates planned RFCs) · Finance (depreciation, cost allocation, disposal write-offs) · Security/GRC (policy violations, unauthorized assets).
Reference
Compliance frameworks: how to read the mappings
Each process chapter ends with a compliance mapping table. These mappings identify where the process, operated as documented in InvGate Service Management, produces the evidence an auditor asks for. They are a starting point for your compliance program, not a substitute for it — control applicability depends on your audit scope, and your compliance or legal team should validate each mapping.
| Framework | What it is | What auditors typically want from ITSM processes |
|---|---|---|
| ISO/IEC 20000-1:2018 | The international standard for service management systems (SMS). | Documented processes (clause 8), records of operation, defined roles, and evidence of continual improvement. |
| SOC 2 (Trusted Services Criteria) | Attestation report on controls for security, availability, and related criteria (CC-series common criteria). | Populations and samples: every change approved before deploy (CC8.1), incidents tracked to resolution (CC7.3–7.5), access provisioned with approval (CC6.1–6.3). |
| ISO/IEC 27001:2022 | Information security management system standard; Annex A controls. | Incident management records (A.5.24–A.5.28), change management (A.8.32), access provisioning (A.5.16, A.5.18), documented procedures (A.5.37). |
| NIST CSF 2.0 | US cybersecurity framework: Govern, Identify, Protect, Detect, Respond, Recover. | Common in public sector and as a maturity yardstick; maps ITSM processes to Respond/Recover (incident), Protect (change, access), Identify/Improve (problem). |
| HIPAA Security Rule | US healthcare regulation for protecting ePHI (45 CFR §164). | Security incident procedures §164.308(a)(6), workforce access management §164.308(a)(3)–(4), periodic evaluation §164.308(a)(8), activity review §164.308(a)(1)(ii)(D), device & media controls §164.310(d). |
The universal evidence engineAcross all six frameworks, the recurring audit asks are the same: a complete population of records, timestamps, approvals, and who-did-what. InvGate Service Management's ticket audit trail, approval records, workflow history, and dashboard exports provide these natively — the discipline this template adds is making sure every event actually becomes a ticket.
Reference
Role glossary
Roles, not job titles. In smaller teams one person holds several roles; record the assignments in the table below and keep it current — auditors ask for it, and so do new hires.
| Role | Accountability | Assigned to |
|---|---|---|
| Service Desk Agent (L1) | First contact. Logs, categorizes, prioritizes, resolves with knowledge, escalates with context. | — |
| Technical Specialist (L2/L3) | Deep diagnosis and resolution within a technical domain; contributes knowledge back. | — |
| Service Desk Manager | Runs the desk: staffing, queue health, SLA performance, quality of ticket data. | — |
| Incident Manager | Owns the incident process; commands major incidents; reviews trends. | — |
| Request Fulfillment Owner | Owns the service catalog and fulfillment workflows; keeps offerings and approvals current. | — |
| Change Manager | Owns change enablement; chairs the CAB; guards the change calendar; audits the standard-change library. | — |
| CAB (Change Advisory Board) | Cross-functional risk review for normal changes; advises, Change Manager decides. | — |
| Problem Manager | Owns problem investigations, the known-error record, and follow-through on permanent fixes. | — |
| Knowledge Manager | Owns article standards, review cycles, and knowledge base health metrics. | — |
| IT Asset Manager | Owns the ITAM program: inventory accuracy, lifecycle procedures, license position, contracts, and disposal evidence. | — |
| Asset Custodian | The named user or location an asset is assigned to; accountable for its care and return at offboarding or refresh. | Per assignment |
| Approver | Authorizes requests or changes within their scope (line manager, budget owner, system owner). In InvGate Service Management, approvers do not consume a license. | — |
| End User / Requester | Reports incidents, submits requests via the portal or AI agent, confirms resolution. | All staff |