Vulnerability Management Is Just the Beginning: Six SecOps Workflows Agentic ITSM Can Transform

Part 3 of the series From Security Signal to Governed Action. Read Part 1 and Part 2 by clicking the hyperlinks.

The first two parts of this series made two arguments.

1. Security detection is accelerating, while enterprise remediation often still moves through human queues and disconnected processes (learn more here).
2. Solving that gap requires more than adding an LLM to a ticketing platform. It requires a dynamic enterprise context graph, an agent plane, agentic change management, policy-based authority, execution integrations, closed-loop verification and continuous evidence (learn more here).

Now the important question is - What can enterprises actually do with that architecture?

Vulnerability management is the clearest starting point, but it is only the beginning. The same operating model can reshape a much broader set of workflows at the intersection of SecOps and IT operations.

The common pattern is;

Signal → Context → Reason → Govern → Act → Verify → Prove

Let's look at six examples.

1. Vulnerability management: from scanner finding to verified remediation

Vulnerability management illustrates the problem almost perfectly. The security stack is already very good at finding vulnerabilities. Tools such as Qualys, Tenable and Microsoft Defender can continuously identify affected systems and software.

The operational challenge begins when the finding has to become action. Below is a workflow that can help address this.

Step 1: Detect and create accountable work

A scanner finding should not disappear into an inbox or depend on someone manually creating a task. The platform can create or update the appropriate ITSM record, attach the affected configuration items, identify ownership and begin the remediation clock automatically.

That establishes accountability immediately. But ticket creation is the easy part.

Step 2: Prioritize with real context

A vulnerability's CVSS score matters, but severity alone is not enough to determine enterprise priority. CISA recommends its Known Exploited Vulnerabilities catalog as an input to vulnerability-management prioritization because the catalog identifies vulnerabilities known to have been exploited in the wild.[1]

FIRST's EPSS provides another useful signal by estimating the probability that a published CVE will be exploited in the wild within the next 30 days.[2]

An agentic prioritization process can combine those signals with enterprise context, and include;

• CVSS severity
• CISA KEV status
• EPSS or other exploit-likelihood data
• current threat intelligence
• exploit availability
• internet exposure
• whether the vulnerable component is actually enabled or reachable
• business-service criticality
• asset ownership
• identity privilege
• compensating controls
• active security incidents
• upcoming maintenance windows

The question changes from:

How severe is this CVE?

to:

How urgent is this vulnerability for us, on this asset, right now?

That is a much better operational question.

Step 3: Create the change, not just the ticket

Once remediation is required, the system can prepare the change.

The agent can use the context graph to identify affected services and dependencies, check for conflicting changes, analyze similar historical changes, determine owners and approvers, build implementation and rollback steps, and propose an appropriate deployment window.

For a routine endpoint patch, policy may allow automatic remediation. For a critical production database, the same platform may generate a CAB-ready change and route it for accelerated human approval.

The decision is governed by both cyber risk and change risk.

Step 4: Execute through the right platform

ITSM should not become the patch engine.

It should coordinate the tool that already owns execution: Intune, an RMM system, an endpoint platform, a configuration-management tool, a cloud API or another remediation system.

The key is to preserve one connected operational record from detection through execution.

Step 5: Verify with the authoritative source

This is where many processes stop too early. A patch command returning success does not prove the vulnerability is gone. NIST's enterprise patch-management guidance explicitly includes verification as part of the patch-management lifecycle.[3]

So the platform should re-check the originating scanner or another authoritative security source. If the finding is gone, close the loop, and if it remains, reopen automatically and investigate why.

Step 6: Generate evidence automatically

By this point, the enterprise should have a complete chain of evidence:

Finding → priority decision → context → change → approval → execution → rescan → closure

That record is valuable not only to operations, but also to security leadership, risk teams and auditors. This is what it means to treat vulnerability management as an ITSM journey, not simply a scanner output.

2. Security incident orchestration

The same pattern applies to security incidents. A SIEM or XDR platform may detect suspicious behavior, but significant incidents quickly become cross-functional.

Security may need infrastructure, network, endpoint, identity, application, legal, communications or business teams to act.

The traditional model often creates a parallel operational universe: one incident in the security platform, another incident in ITSM, a war room in Teams or Slack, tasks in email, and manual status updates between them.

An agentic ITSM layer can connect those worlds. Imagine a high-confidence compromise signal arrives from XDR.

An agent can;

1. Identify the affected asset, user and identities.
2. Traverse the context graph to find dependent applications and business services.
3. Check related incidents, vulnerabilities and recent changes.
4. Create or update the ITSM security incident.
5. Determine the appropriate resolver and escalation path.
6. Establish a collaboration channel or war room when policy requires it.
7. Propose containment actions.
8. Route disruptive actions for approval when necessary.
9. Track tasks across infrastructure, identity and application teams.
10. Maintain a synchronized timeline and evidence record.

The point is not to replace the SIEM or XDR. The security platform still remains the source of detection and telemetry. But, ITSM becomes the mechanism for enterprise-wide coordination, ownership, change control and evidence.

This becomes especially important when the security response itself creates operational risk. For e.g., isolating a laptop may be low impact, but isolating a production server supporting a critical service is a different decision.

The context graph helps the system understand that difference before action is taken.

3. Privileged access and identity operations

Security risk increasingly travels through identity. The operational intersection with ITSM is therefore not limited to vulnerabilities and incidents.

Consider privileged access. A user asks for administrative access to a production system. A simple workflow can route the request to a manager. But an agentic workflow can evaluate much more context before making or recommending a decision.

It can ask;

• Who is requesting access?
• What role does the person have?
• What system is involved?
• What business service does it support?
• Is there an approved change or incident that justifies the request?
• Is the requested privilege broader than necessary?
• Is there an active security concern involving the identity or device?
• How long should access last?
• What approvals are required by policy?

The operating loop becomes;

Request → Context → Risk evaluation → Approval → Provision → Monitor → Revoke → Evidence

Instead of granting persistent access because it was once approved, the system can favor just-in-time and time-bound privilege where the identity platform or PAM system supports it.

Again, ITSM does not replace IAM or PAM. The identity system still enforces the entitlement. But, the ITSM layer provides the business context, process, approval, audit trail and connection to the work that justified the access in the first place. That connection can be powerful.

A temporary administrative role granted for Change CHG-12345 should be able to expire automatically when the maintenance activity ends, rather than waiting for someone to remember to remove it.

4. Security configuration management

Many security findings are not software vulnerabilities at all. They are configuration problems;

• encryption disabled
• an unsafe firewall rule
• an exposed storage bucket
• insecure protocol settings
• an unsupported operating-system configuration
• weak endpoint policy
• overly permissive cloud access
• a missing security control

Security platforms can identify these conditions, but remediation often belongs to another operational team. The agentic ITSM model is almost identical to vulnerability remediation:

Detect → understand impact → determine owner → plan change → approve → execute → verify

The context graph is especially valuable here because a seemingly simple configuration change can have broad dependency effects - like closing a network port may break an application integration, or tightening a policy may block an older endpoint, or changing an authentication setting may affect a business-critical service account.

A reasoning layer can evaluate those relationships before the change is made. This is where agentic change management becomes one of the most important bridges between SecOps and IT operations.

Security may know that the current state is unsafe. ITSM has to help the enterprise move from unsafe to safe without creating a different outage in the process.

5. Endpoint security + DEX + RMM

Endpoints reveal another dimension of the SecOps/ITSM intersection: the employee is part of the remediation architecture. Suppose an urgent security update is required across 5,000 laptops.

The technical action may be straightforward, but the operational journey is not.

Some devices may be offline, some may have insufficient disk space, some updates may fail. Some users may be presenting to customers, and so on. This is where security, DEX, RMM and employee support converge.

An agentic platform can combine;

• security posture
• device inventory
• device health and telemetry
• installed software
• employee identity
• support history
• business context
• patch policy
• current device state

Then it can coordinate a much more effective remediation journey.

For example:

A critical security update is required on your laptop. It will take approximately eight minutes and requires a restart. I can install it now, at 7:00 PM, or before your next login tomorrow morning.

The employee does not need to understand the CVE or open a helpdesk ticket. If the update succeeds, the device can be verified automatically. If it fails, the agent can collect diagnostics, attempt approved remediation and escalate with the logs already attached.

This creates two benefits at once;

1. Security closes exposure faster.
2. IT avoids turning every endpoint exception into manual helpdesk work.

The same model can extend beyond patching to encryption posture, unsupported software, endpoint-control failures, certificate issues and device compliance.

6. Continuous compliance and audit: Evidence as a product of operations

Most enterprises still treat audit evidence as something that must be assembled after the fact.

A control owner is asked to prove that critical vulnerabilities are remediated within policy. Teams export scanner reports, ticket histories, change approvals and spreadsheets, then try to reconcile them.

An agentic ITSM model can turn that around. If the operational journey is connected end to end, the evidence already exists;

• when the issue was detected
• what assets and services were affected
• how the issue was prioritized
• which intelligence and context informed the decision
• who approved the action
• what remediation was executed
• whether exceptions occurred
• when the authoritative system verified closure

Compliance becomes continuous evidence, not periodic archaeology. This does not remove the need for auditors, control owners or independent review.

It improves the quality and availability of the underlying evidence, and also enables more useful operational questions;

Which critical vulnerabilities breached remediation policy last quarter, and why?

Which emergency changes bypassed the normal approval path under an approved exception?

Which privileged-access grants lasted longer than the work that justified them?

Which systems repeatedly fail patch verification?

Where are security findings accumulating because of change constraints rather than detection gaps?

Those questions turn ITSM data into a source of security-management insight.

The common architecture behind all six workflows

Although these use cases look different, the underlying operating model is strikingly consistent.

1. Signal

A specialized system detects something: a vulnerability, suspicious event, identity request, misconfiguration or endpoint posture problem.

2. Context

The dynamic enterprise graph establishes what the signal means in this environment: asset, owner, service, dependency, identity, exposure, control and operational state.

3. Reasoning

Agents gather evidence, investigate and recommend or select an appropriate course of action.

4. Governance

ITSM records, change controls, policy and human approvals define accountability and authority.

5. Action

The appropriate endpoint, cloud, identity, security or automation platform executes the change.

6. Verification

The authoritative system confirms whether the security outcome was actually achieved.

7. Evidence

The full chain of decisions and actions becomes part of a durable audit trail.

That is the pattern enterprises can reuse again and again.

What ITSM should and should not become?

This distinction is important. Agentic ITSM should not attempt to replace the security stack. It should not pretend to be the best vulnerability scanner, SIEM, EDR, XDR, PAM or CSPM platform.

Instead, it should solve the problem that begins after those systems identify something important.

A useful division of labor is;

• Security tools generate signals
• The context graph establishes meaning
• Agents investigate and reason
• Policy defines authority
• ITSM coordinates ownership, change and governance
• Execution tools act
• Security tools verify

That creates a closed operational loop without destroying the value of the systems enterprises have already invested in.

From alert queues to agentic operations

This shift matters because the scale and speed of the problem are changing.

Verizon's 2026 DBIR reports that vulnerability exploitation became the leading breach entry point in its dataset, at 31% of breaches.[4] CrowdStrike's 2026 report says the average eCrime breakout time it observed fell to 29 minutes and reported an 89% increase in attacks by AI-enabled adversaries.[5]

Those figures come from different methodologies, and no single metric defines the threat landscape. But they reinforce a practical reality: defenders cannot assume that human coordination time will remain available after detection.

That is the larger strategic opportunity at the intersection of SecOps and ITSM. The security industry has spent years making signals faster and richer.

Now the operational enterprise has to become equally good at turning those signals into safe, governed and verifiable action.

Vulnerability management is an ideal place to begin because the journey is easy to understand:

Detect → Prioritize → Change → Remediate → Verify → Evidence

But once the architecture exists, the same pattern can extend across security incidents, identity, configurations, endpoints and compliance.

The future of ITSM is therefore not simply more automation around tickets. It is an intelligent operating layer that can connect security context to enterprise action.

Or, put more simply:

The future of ITSM is not the ticket. It is the governed agentic loop.

---

Sources and further reading

CISA, Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

FIRST, Exploit Prediction Scoring System (EPSS). https://www.first.org/epss/

NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology. https://csrc.nist.gov/pubs/sp/800/40/r4/final

Verizon, 2026 Data Breach Investigations Report and related summary. https://www.verizon.com/business/resources/reports/dbir/ and https://www.verizon.com/about/news/breach-industry-wide-dbir-finds

CrowdStrike, 2026 Global Threat Report. https://www.crowdstrike.com/en-us/press-releases/2026-crowdstrike-global-threat-report/