What breaks when an ITSM platform is heavily customised?

Why This Matters for Security Teams

Heavy customisation turns an ITSM platform from a supportable product into a fragile business system. The immediate risk is not just broken upgrades, but also brittle workflows, inconsistent approvals, and controls that exist only in bespoke code. Once teams depend on custom scripts, plugins, and undocumented integrations, the platform becomes harder to patch, harder to audit, and harder to hand over between teams.

This matters because ITSM often sits at the centre of access requests, incident handling, change approvals, and service account workflows. If the platform cannot be upgraded cleanly, those processes inherit the same technical debt. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — The NHI Market, which is exactly the kind of blind spot that becomes harder to correct when the ITSM stack is heavily bespoke. The governance model also becomes less portable because the logic lives in customisations rather than documented policy.

Security teams usually see the failure mode only after an upgrade is delayed, an incident workflow misfires, or a privileged request path no longer behaves as expected.

How It Works in Practice

In practice, customisation risk shows up in three layers: application logic, operational process, and identity control. At the application layer, every modified form, trigger, workflow, or plugin adds a dependency that can break during vendor updates. At the process layer, teams often encode approval paths, exception handling, and ticket routing in ways that only the original implementers understand. At the identity layer, ITSM may orchestrate access for service accounts, API keys, and automation tools, so any drift affects both governance and execution.

A more durable approach is to treat the ITSM platform as a configurable control plane, not a development sandbox. That means using the vendor’s supported extension points, documenting each change, and separating policy from implementation wherever possible. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, change management, and recovery discipline rather than one-off technical fixes. For NHI-heavy environments, the Ultimate Guide to NHIs — The NHI Market is a reminder that service accounts and secrets should be visible, rotated, and recoverable independently of any single workflow engine.

• Keep custom code to a minimum and prefer supported configuration first.
• Map each custom workflow to a business owner, technical owner, and rollback path.
• Test upgrades against realistic access, incident, and approval scenarios, not just happy paths.
• Move identity and secrets logic into centrally governed controls where possible.

These controls tend to break down when the ITSM platform is also serving as the only workflow engine for dozens of business-critical automations, because upgrade testing cannot realistically cover every custom dependency.

Common Variations and Edge Cases

Tighter customisation often increases operational efficiency in the short term, requiring organisations to balance local workflow speed against long-term maintainability. That tradeoff is real, especially when the platform must fit complex approval chains or regulated change processes.

Best practice is evolving, but current guidance suggests distinguishing between configuration, supported extension, and unsupported code. That distinction matters because not all customisation is equally risky. Low-code field logic or approved workflow rules may be manageable, while deep modifications to core objects, authentication flows, or upgrade hooks create much higher failure potential. In regulated environments, the safer pattern is to document exceptions, keep change authority narrow, and ensure that platform upgrades are treated as security events rather than routine maintenance.

Edge cases appear when an organisation inherits a legacy ITSM instance with years of ad hoc changes. In those environments, a full redesign is rarely practical, so teams should prioritise high-risk dependencies first: privileged access workflows, incident escalation paths, and any process that touches secrets or service accounts. The most useful benchmark is not whether the platform is customised, but whether the custom logic can be explained, tested, and removed without breaking governance.

Related resources from NHI Mgmt Group

• What breaks when a platform cannot handle tenant-aware identity properly?
• What breaks when least privilege is not enforced in a zero trust model?
• What breaks when device-based trust is treated as a yes-or-no decision?
• What breaks when access policies are not continuously revalidated in a Zero Trust model?