Vulnerability management is no longer a side job for IT

In Part 1, I explored how vulnerability exploitation is accelerating, leaving organisations with less time to respond. Part 2 examined why greater visibility does not necessarily lead to better security decisions.

The remaining challenge is operational. Even when the vulnerabilities are identified and correctly prioritised, someone still needs to take responsibility for managing them.

In many organisations, that responsibility sits with an IT team already occupied with keeping the business running.

That creates a difficult conflict. Restoring a failed business system will understandably take priority over reviewing a vulnerability backlog, even when the security exposure is significant.

As attackers become faster and more automated, vulnerability management cannot depend on whatever time is left after the day’s operational incidents.

At a certain scale, vulnerability management needs dedicated attention, clear accountability and people whose primary responsibility is reducing security exposure.

The monthly cycle has become a liability

Traditional patching schedules were designed around operational stability. Systems need testing, changes require approval and businesses need predictable maintenance windows.

Those requirements have not disappeared.

What has changed is the speed of the threat.

AI and automation are helping attackers accelerate reconnaissance, exploit development and attack execution. A newly disclosed vulnerability may become an active threat long before the next scheduled patching window.

Monthly patching still has an important role for routine maintenance. But a monthly vulnerability review cannot be the organisation’s primary method of responding to emerging threats.

Critical exposures need to be assessed as new information becomes available, with a process capable of triggering action outside the normal maintenance cycle.

The organisation needs to operate at a speed that reflects the threat, while retaining the discipline required to keep critical systems running.

Vulnerability management is no longer a side responsibility

Consider an IT team supporting several hundred restaurants or retail locations.

Its primary responsibility is keeping the business operational. When connectivity fails, payment systems stop working or a location cannot trade, the response is immediate because the impact is immediate.

Now add thousands of vulnerability findings requiring investigation, prioritisation, remediation planning and verification.

Even a capable IT team will struggle to give both responsibilities equal attention. When the business is experiencing an operational incident, restoring service will understandably take priority.

The vulnerability backlog continues to grow, and issues requiring investigation can remain open longer than anyone intended.

This is an operating model problem.

At a certain scale, vulnerability management needs dedicated attention from people whose primary responsibility is reducing security exposure.

That capability may exist within the organisation or be provided by a specialist partner. What matters is that it operates continuously, with clear accountability, regardless of how busy the wider IT team becomes.

Patching is one part of the job

Another misconception is that having a patching program means having a vulnerability management program.

Patching is an important remediation method, but some vulnerabilities have no available patch. Others require configuration changes, network isolation, removal of exposed services or replacement of unsupported technology.

In some situations, applying a patch immediately may introduce more operational risk than implementing a temporary security control while a permanent solution is prepared.

The decision requires an understanding of the vulnerability, the affected infrastructure and its importance to the business.

It also requires verification. A successful patch deployment does not necessarily prove the exposure has been eliminated.

Effective vulnerability management follows the issue from discovery through assessment, remediation or risk treatment, and verification. Where risk must be accepted, that decision needs an accountable business owner and an agreed review period.

Someone needs to own the outcome

This is where vulnerability management often breaks down.

A security platform identifies an exploitable vulnerability on a business-critical server. A ticket is raised and assigned to infrastructure operations.

The infrastructure team determines that patching requires an application outage. The application owner requests more testing, and the next maintenance window is several weeks away.

Everyone has followed the process, yet the exposure remains.

Who is responsible for ensuring the risk is controlled in the meantime?

A dedicated vulnerability management function should remain accountable for coordinating that response, escalating delays, tracking temporary controls and ensuring the issue reaches an agreed outcome.

It does not necessarily perform every technical change. Infrastructure engineers, application owners and business stakeholders still have important responsibilities.

But there must be someone whose job is to keep the vulnerability moving toward resolution.

Assigning a ticket is not the same as accepting accountability for the risk.

Why dedicated vulnerability management is becoming necessary

Building this capability internally is possible, and many larger organisations already have dedicated security teams doing excellent work.

However, maintaining a specialist vulnerability management function requires ongoing investment in people, threat intelligence, tooling and operational processes.

It must also work closely with the teams responsible for infrastructure, networks and applications.

For many organisations, engaging a specialist partner can provide that dedicated focus without requiring the business to build and maintain the entire capability internally.

At DC9, this is how we believe vulnerability management should operate. Security intelligence needs to be connected directly to infrastructure operations, with clear responsibility for identifying material exposure, coordinating remediation and verifying that the appropriate controls are in place.

Our role is to help organisations establish and operate that capability, working alongside their internal teams rather than competing with their responsibility to keep the business running.

The objective is straightforward: give vulnerability management the dedicated attention it requires while allowing internal IT teams to remain focused on business operations.

Vulnerability management needs its own operating model

Across this series, we have explored how exploitation timelines are shrinking, why greater visibility does not automatically produce better decisions, and why remediation needs dedicated ownership.

Together, those changes point toward a different approach.

Vulnerability management needs to operate continuously, respond to changing threats and remain accountable for exposures until they are resolved or appropriately controlled.

Monthly reporting still has value. Scheduled patching still has value. Internal IT teams remain essential to delivering remediation.

But none of those things replaces dedicated responsibility for managing exposure.

As attackers accelerate, organisations need a vulnerability management capability that can keep pace.

If vulnerability management is everyone’s secondary responsibility, there is a real risk that it becomes nobody’s primary responsibility.

That is no longer a risk businesses should be comfortable carrying.

Nelson Lai

Previous: Your security tools found the risks. Why are you still exposed?