Who Owns Vulnerabilities?

The Problem of Ownership in Vulnerability Management 

The question of ownership is one of the biggest reasons vulnerabilities persist in organizations far longer than they should. 

Who owns vulnerabilities? This isn’t just a theoretical debate—it’s a critical operational issue. Modern scanning solutions excel at identifying and prioritizing vulnerabilities, but without clear ownership, those vulnerabilities often linger unaddressed or improperly documented, increasing an organization’s risk exposure. 

Why Vulnerability Ownership Matters 

Let’s consider ownership from a different perspective. In physical security, you wouldn’t respond to an urgent issue by shouting, “Somebody help!” When responsibility is ambiguous, the ‘bystander effect’ takes hold—everyone assumes someone else will step in, so no one does. 

The same applies to vulnerability management. If a vulnerability isn’t assigned to a specific person or team, it’s unlikely to be remediated in a timely manner—if at all. 

Ownership isn’t just about fixing vulnerabilities; it’s also about managing risk. When a vulnerability can’t be patched, someone must formally accept the risk. But who should sign that risk acceptance? Too often, it’s passed up the chain until it lands on a VP’s desk, only for them to question why they’re responsible instead of someone else. This confusion can delay action, allowing risks to compound. 

Let’s explore how to determine ownership effectively and ensure risk acceptances don’t become career liabilities.

Identifying Ownership of Vulnerable Systems

Every organization has legacy systems with unclear ownership. These “orphaned” systems pose serious security risks. The best place to determine ownership is your Configuration Management Database (CMDB). Ideally, this information should be synchronized with your vulnerability management platform, such as Nucleus. 

If the CMDB lacks useful data, there are other ways to track down system owners. For Windows systems, vulnerability data often contains clues. In Nucleus, for example, you can: 

• Navigate to the asset’s Overview tab to review metadata. 
• Look for informational findings like “Last successful user login” under the Vulnerabilities section. 
• Check Instances to see who last accessed the system. 

With these insights, you can start conversations with potential owners. 

Between the additional asset metadata and the informational finding, you have some leads. Start talking to those people about the system.

Key Questions to Ask 

When approaching potential system owners, expect initial reluctance. Most will say, “That’s not my responsibility.” The best way to clarify ownership is to ask: 

• “Who is responsible for fixing this system if it breaks?” That person (or team) should also handle patching. 
• “Who enforces the rule that prevents you from updating this system?” If a system admin isn’t allowed to apply updates, the decision-maker enforcing that rule must be involved in the risk acceptance process. 

If ownership points to a non-VP, escalate to their leadership for sign-off. Ensuring clear accountability at the right level is crucial. 

What a Risk Acceptance Should Include 

Too many organizations treat risk acceptances as a ‘get-out-of-patching-free’ card. Accepting risk is a strategic decision to focus time and resources on the vulnerabilities that pose greater risk. 

A well-structured risk acceptance should document: 

1. The problem: What is the vulnerability, and why can’t it be remediated? 
2. A plan of action and milestones (POA&M): A concrete strategy to mitigate or address the risk over time. 
3. Sign-off from the right authority: Someone senior enough to take responsibility for the potential consequences. 

As an example, we worked with a government contractor that couldn’t patch Java due to a compatibility issue in the environment. The POA&M for this situation included: 

• Contacting the software vendor weekly for updates. 
• Deploying the update in a test environment as soon as it became available. 
• Rolling out the patch in production at the next maintenance window. 

Because the risk and plan were clearly outlined, senior leadership had confidence in the process and signed off without hesitation. 

Lessons for the Private Sector 

Most enterprises have at least one “untouchable” legacy system. These systems, often decades old, are critical to business operations but run on obsolete hardware and unsupported software. The longer they remain unaddressed, the riskier they become. 

We’ve worked with customers who have systems that are so outdated that replacement parts were only available on eBay and support was only available on hobbyist forums. We even encountered a situation where a system admin admitted he was running a system on a failed RAID array—one more disk failure away from total loss. 

There are cases where systems are so outdated that replacement parts are only available on eBay, and support can only be found on hobbyist forums. At one organization, an admin even admitted a critical system was running on a failed RAID array—one more disk failure away from total loss. 

When the risks were documented in a formal acceptance, that detail was included. The VP initially dismissed the issue until the following details were explained to him: 

• If the remaining drive failed, there was no recovery path. 
• Data restoration would require specialist recovery services, costing thousands of dollars. 
• Finding compatible replacement hardware would be nearly impossible. 

Understanding the full scope of risk changed the conversation. Within weeks, leadership prioritized migrating that system to modern infrastructure. 

Making Risk Visible 

Ultimately, vulnerabilities are rarely the sole issue. They’re often symptoms of deeper operational problems. By: 

• Identifying clear ownership, 
• Structuring risk acceptances properly, 
• Reviewing risks annually to prevent “forever acceptances,” 

…you can turn vulnerability management from a reactive firefight into a structured, accountable process. It starts with answering a simple but vital question: Who owns the risk?