When does ITSM customisation create governance risk?

Why This Matters for Security Teams

ITSM customisation becomes a governance issue when the service desk stops being a controlled workflow and starts behaving like a set of local policy engines. That is where approvals, evidence collection, and exception handling drift across teams. NHI Management Group has repeatedly found that lifecycle complexity is one of the main reasons organisations lose control of non-human identities, which is why its Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs matters here.

The risk is not customisation itself. The risk is customisation without a clear control owner, a testable approval model, and a defined retirement path. When every queue has a different request form or exception rule, audit teams cannot easily prove that access was granted consistently, revoked on time, or reviewed under the same standard. That problem is especially visible in environments trying to align with the NIST Cybersecurity Framework 2.0, where repeatable governance outcomes matter more than cosmetic process variation. In practice, many security teams encounter control drift only after an audit exception, delayed deprovisioning, or an access abuse investigation has already exposed the inconsistency.

How It Works in Practice

The safest model is to treat the ITSM platform as a governed workflow layer, not as a place to encode local policy logic in dozens of different ways. Standard requests should share the same approval structure, evidence fields, retention rules, and ownership model. Where business needs truly differ, the variation should be explicit, documented, and mapped to a named control requirement. That approach fits the NHI operating model described in Top 10 NHI Issues, because approval inconsistency and weak lifecycle governance are common failure points.

Practitioners usually reduce governance risk by separating configuration from policy:

• Use one baseline request path for common access, secrets, or account changes.
• Apply role-based routing only where the approver and evidence set are genuinely different.
• Keep every custom branch tied to a process owner who can maintain it and answer audit questions.
• Log the same minimum evidence across all variants so reviews remain comparable.
• Review custom paths on a schedule and retire duplicates when the control need no longer exists.

This is especially important for NHI-related requests, where credential issuance, rotation, and revocation often depend on ticketing outcomes. If the ITSM design allows one team to approve long-lived exceptions while another enforces short-lived access, the organisation ends up with inconsistent exposure even when the ticket system appears orderly. Current guidance suggests documenting those differences in policy rather than scattering them across hidden form logic or one-off workflow branches. These controls tend to break down in large federated service desks because teams inherit local changes faster than governance teams can review them.

Common Variations and Edge Cases

Tighter standardisation often increases friction for specialist teams, so organisations have to balance consistency against legitimate operational exceptions. That tradeoff is real, especially in regulated environments or in teams that manage privileged automation, release pipelines, or third-party integrations. The question is not whether every path must be identical, but whether every deviation is justified, visible, and owned.

There is no universal standard for ITSM customisation depth, but best practice is evolving toward minimal divergence with strong change control. Some organisations allow custom forms but prohibit custom approval logic. Others permit workflow branches only when tied to a formal control objective, such as segregation of duties or emergency access review. The key is that the exception must not become a shadow process that bypasses auditability. The NHI governance perspective in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here, because auditors usually care less about the tool and more about whether the control outcome is repeatable.

Where customisation most often creates risk is in high-change environments with multiple service desk administrators, inherited templates, and no single owner for the process design. In those settings, the safest rule is simple: customise only when the requirement is explicit, measurable, and sustainable across the full lifecycle.

Related resources from NHI Mgmt Group

• Why do duplicate SaaS apps create identity governance risk?
• Why do SaaS apps create identity governance risk as they spread across the business?
• Why do SaaS buying decisions create access governance risk?
• Why do vendor relationships create identity governance risk?