How to Embed Risk-Based Security into ITSM

IT service management (ITSM) and IT security have long been two IT management “islands.” However, the traditional separation between IT operations and cybersecurity is no longer sustainable as, with cyber threats growing, ITSM teams must integrate risk-based security into their processes. Importantly, not as an afterthought, but as a core part of IT service delivery and support.

This blog explains what’s needed. But first, it explains what risk-based security is and why ITSM, when aligned with risk-based security, can help prevent, detect, and respond to security threats more effectively.

Risk-based security explained

The risk-based security approach focuses on your organization’s most critical assets and vulnerabilities, rather than trying to defend every security threat equally. Your organization’s security investments better align with business priorities, targeting the threats that could:

• Disrupt your operations
• Harm customers
• Damage your organization’s reputation.

To start, security teams analyze which assets (across data, applications, systems, and infrastructure) are most valuable, plus the security threats most likely to affect them. Then, they assess the associated vulnerabilities, rank the risks, and build a prioritized security action plan.

Embedding risk-based security into ITSM

The integration of the risk-based security approach with ITSM platforms is a growing trend. This allows organizations to embed risk controls directly into change management (or change enablement in ITIL 4), incident management, and IT asset management workflows. Such that ITSM controls are also security controls.

Examples of how risk-based security can be embedded into ITSM follow for:

• Change management (or change enablement)
• Incident management
• IT asset management.

Change management and risk-based security

The starting point is to include a security-risk assessment in your change workflow that considers the proposed change’s security impact. You can use a risk matrix to evaluate:

• The likelihood of vulnerability exposure
• The impact on critical assets or services
• Threat surface expansion.

Then prioritize and tag changes by risk level. High-risk or sensitive changes need to be routed through additional approval layers. While low-risk changes employ automation to speed up safe deployment. It’s important to appreciate that some changes will need multiple risk tags. For example, a critical-system patch might be low risk technically but high risk operationally during peak usage periods.

Automate your risk checks using artificial intelligence (AI) or rules engines. These should scan proposed changes for known vulnerabilities, misconfigurations, or missing controls.

Incident management and risk-based security

Include risk scoring in incident categorization by adding a risk impact assessment field to incident tickets. Incidents can then be scored based on the business criticality of the affected service or asset, likelihood of threat exploitation, and regulatory or reputational impact. This allows IT support to align incident prioritization with business risk, not just the relevant service level target.

Link incidents to critical assets in your configuration management database (CMDB), such that incidents involving assets tagged as “high risk” can be automatically flagged. For example, systems processing personally identifiable information (PII) or financial data.

Incorporate risk into incident escalation and response playbooks. For example, escalate incidents based on security-impact severity, not just time-to-resolution service level targets, and employ risk-tiered incident response playbooks such that high-risk incidents require a cross-functional team and legal notification.

IT asset management and risk-based security

Start by classifying assets by business and security risk, assigning risk ratings to each asset in your CMDB or asset register, based on business criticality, data sensitivity, and exposure level. Enhancing your asset (or configuration item) records with security-relevant attributes, such as:

• Patch status/last update
• Known vulnerabilities
•  Compliance requirements

Integrate asset data into incident and change risk decisions to help prioritize incidents and route high-risk changes for additional security review. Automate security workflows using asset risk context – build automations that take asset risk into account and auto-create high-priority tickets for vulnerabilities on critical assets. For example, if an asset with “critical” data classification is detected with ransomware behavior, it’s auto-quarantined and flagged for action.

You can also link your asset lifecycle management to risk controls by applying different security policies across various stages of the asset lifecycle. For example:

• Enforce encryption on all corporate laptops tagged as high-risk
• Require secure wipe procedures for end-of-life critical assets
• Ensure that decommissioning a retired finance server includes verified data destruction, security validation, and compliance sign-off.

Increasing risk visibility through ITSM dashboards

Simply having security risk factors added to change, incident, and asset records is not enough. Instead, there’s a need to increase management-level visibility of these risks and their potential impact. A way to achieve this is to build unified dashboards that combine ITSM metrics and security risk indicators. For example, making critical service health, service level target breaches, and security issues available in one view.

Ultimately, embedding risk-based security into ITSM isn’t just about compliance; it’s also about better serving business and creating resilience. Your ITSM teams can help with these business-level needs by changing the service management status quo through the addition or embedding of the threat-aware, business-aligned security practices that form the backbone of risk-based security management.