Configuration changes how the tool behaves through settings and parameters, while customisation changes the software itself, often through code. Configuration is easier to maintain across upgrades, but customisation can create long-term support and compatibility risk. Teams should prefer configuration unless business requirements truly justify modifying the platform.
How configuration and customisation differ in an ITSM tool
Configuration uses the options the vendor already exposes, so you can adapt workflows, forms, fields, rules, permissions, and notifications without changing the product’s core code. Customisation goes further by altering the software itself, often with scripts, plugins, extensions, or direct code changes. The practical difference is control: configuration stays closer to the supported product path, while customisation creates a bespoke variant that must be maintained over time.
The distinction matters because ITSM tools are usually upgraded, patched, and integrated repeatedly. The more you stay within supported configuration, the easier it is to absorb vendor releases, keep documentation accurate, and preserve supportability. Once you change the underlying application logic, you are no longer just adjusting behaviour, you are inheriting a software maintenance problem.
Why configuration is usually the safer default
Configuration is normally the preferred first choice because it lets teams meet business needs without taking on unnecessary engineering debt. Most mature ITSM platforms are designed to be configured extensively, so the right question is usually not “can we tailor it?”, but “can we achieve the outcome through supported settings first?” That approach reduces upgrade friction and keeps the platform closer to the vendor’s tested baseline.
Configuration also makes change control more transparent. Administrators can usually review, export, test, and document settings in a way that is harder to do with code changes. If a process change later proves unnecessary, configuration can often be reversed with less effort than unwinding a custom module or refactoring a workflow that has become embedded in production operations. For a control-oriented perspective on keeping systems aligned with supported baselines, see CISA Secure by Design.
Where customisation becomes a long-term support risk
Customisation is not automatically wrong, but it raises the bar for governance. A custom build can become fragile when a vendor changes APIs, data structures, release cycles, or extension points. The risk is not only technical breakage, but also hidden dependency: a critical business process may come to rely on code that only one team understands. At that point the organisation has less resilience and more operational lock-in.
That is why security and control frameworks often emphasise maintaining supported, manageable system states. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because its configuration management and change-control expectations align with the idea that system behaviour should remain traceable, reviewable, and recoverable after change. In practice, customisation should be treated as a governed exception, not the default design pattern.
Risk and Threat Considerations
Customisation increases exposure when it creates unsupported paths, undocumented logic, or inconsistent behaviour across environments. The bigger the gap between the vendor’s standard product and your deployed version, the more likely upgrades, troubleshooting, and security fixes become slow, incomplete, or error-prone.
Failure mechanism: Custom code or heavy platform tailoring can introduce defects, weaken test coverage, and create version conflicts when patches or releases are applied. If the customised path bypasses normal product safeguards, the organisation may also lose predictable security behaviour.
Impact: The result can be higher outage risk, slower remediation, missed vendor fixes, and a longer-lived support burden. In an ITSM context, that can directly affect incident handling, service restoration, and the integrity of operational records.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | ITSM tools need controlled, supported configuration rather than risky bespoke changes. |
| Recommendation — Maintain supported configurations and restrict unsupported customization to approved exceptions. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | The question hinges on separating supported settings from software changes against a managed baseline. |
| CM-3 — Configuration Change Control | Customisation creates change-control and upgrade risk that this control directly addresses. | |
| CM-6 — Configuration Settings | Configuration in ITSM tools is primarily about defined settings and parameters. | |
| Recommendation — Establish and maintain approved configuration baselines before permitting platform customizations. Review, approve, test, and document any ITSM customizations through formal change control. Set security-relevant platform behaviour through controlled configuration settings wherever possible. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | The distinction between configuration and customisation is fundamentally a configuration-management issue. |
| Recommendation — Control software and platform settings so changes remain authorised, tracked, and supportable. | ||
Practitioner Guidance
What to prioritise: Start by classifying every requested change as configuration, extension, or code modification. If the business need can be met with supported settings, workflow design, or standard integration points, choose that route first. Reserve customisation for cases where the requirement is genuinely differentiating and cannot be met safely within the product.
What to verify: Before approving customisation, confirm who will own it through upgrades, how it will be tested, and whether there is a rollback path. If the answer depends on a single developer or an unversioned script, treat that as a supportability red flag rather than a minor implementation detail.
Practitioner takeaway: Configuration is about shaping behaviour within the product’s support model, while customisation is a deliberate trade-off that should be justified by business value, not convenience. In most ITSM environments, the safest long-term posture is to configure first and customise only when the operational cost is understood and accepted.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?