In a working vulnerability management program, the security team finds, prioritizes and verifies vulnerabilities, but it rarely owns the fix. IT operations and system owners remediate infrastructure, application owners and developers fix code, business or asset owners decide whether to accept risk, change management approves and schedules the work, and leadership handles escalations and resourcing. Write those roles into a RACI matrix with a single accountable party per activity, agree on escalation triggers in advance, and give every asset a default owner so no finding is left without one.
The rest of this post defines each role, gives you a RACI you can adapt and covers the two places ownership usually breaks: escalation and orphaned assets.
Why does vulnerability ownership break down?
Most programs don't fail because nobody can find vulnerabilities. They fail because the finding lands in a queue and nobody agrees whose job it is.
The same patterns show up again and again:
- Tickets bounce. A finding moves between the server team, the application team and security, with each assuming another team owns it.
- Security becomes the owner by default. Because security raised the finding, everyone treats it as security's problem, even though security can't change the system.
- The wrong person accepts risk. A security analyst or a system administrator quietly marks a finding as accepted, making a business decision they aren't positioned to make.
- Nobody escalates. Overdue findings sit untouched because escalating feels like blaming a colleague.
Clear roles fix all four. They also help as teams become more distributed, as many did this year with remote work. Informal handoffs are harder to rely on when people aren't in the same room.
What are the core roles in vulnerability management?
Six roles cover most organizations. In a small company, one person may hold several of them, but it still helps to name each role separately.
Security team: identify, prioritize and verify
The security team runs the scanning tools, consumes vendor advisories and turns raw findings into a prioritized list with deadlines. After remediation, it verifies that the fix worked, usually by rescanning. It also reports on program health.
What the security team usually doesn't do is make the change. It rarely has the access, the context or the maintenance windows to patch production systems safely, and it shouldn't be the one deciding to accept business risk.
IT operations and system owners: remediate infrastructure
IT operations and system owners patch and configure operating systems, middleware, network devices and other infrastructure. They plan maintenance windows, handle reboots and test that systems still work afterward.
They're also the best source of practical information during prioritization. They know which systems are fragile, which have dependencies and which can be patched on short notice.
Application owners and developers: fix code
When the vulnerability is in custom code or in a library bundled with an application, the fix belongs to the application team. That includes updating dependencies, changing code and releasing a new build.
Application owners need vulnerability work to compete fairly with feature work. Agreeing on deadlines ahead of time, and building them into planning, avoids a negotiation every time a finding arrives.
Business or asset owners: accept risk
Every system supports some business service, and someone owns that service. When a vulnerability can't be fixed on time, or at all, the business owner decides whether to accept the risk, fund a fix or change how the service runs.
That decision belongs with the person who owns the consequences. Security's role is to explain the risk clearly enough for that person to decide.
Change management: approve and schedule
Change management makes sure fixes are scheduled, tested and approved without disrupting the business. For routine patching, a pre-approved standard change keeps this fast. For urgent fixes, an emergency change path means critical work doesn't wait for the next weekly meeting.
Leadership: escalation and resourcing
Leadership sets the policy, approves remediation deadlines and resolves the conflicts other roles can't. When a team repeatedly misses deadlines because it doesn't have the people or time, only leadership can fix that. It's also the final stop for risk decisions above an agreed threshold.
A RACI matrix for vulnerability management
A RACI matrix assigns each activity to four types of involvement:
- Responsible (R): does the work
- Accountable (A): owns the outcome and signs off; exactly one per activity
- Consulted (C): gives input before the work is done
- Informed (I): is told about progress or decisions
Here's a starting point you can adapt:
| Activity | Security | IT ops / system owner | App owner / developers | Business / asset owner | Change management | Leadership |
|---|---|---|---|---|---|---|
| Set policy and remediation deadlines | R | C | C | C | I | A |
| Maintain asset inventory and ownership | C | A/R | R | C | I | I |
| Scan and identify vulnerabilities | A/R | C | C | I | ||
| Prioritize findings and set due dates | A/R | C | C | C | ||
| Remediate OS and infrastructure | C | A/R | C | I | C | |
| Fix application code and dependencies | C | C | A/R | I | C | |
| Approve and schedule changes | C | C | C | C | A/R | |
| Verify remediation | A/R | I | I | I | ||
| Assess and approve risk acceptance | R | C | C | A | I | |
| Escalate overdue findings | R | I | I | I | A | |
| Report program metrics | A/R | I | I | I | I | |
| Provide resources and resolve conflicts | C | C | C | C | A/R |
Two rules keep the matrix useful. First, keep one "A" per row. If two roles are accountable, neither is. Second, put named teams or people against each role in a separate list, so the matrix doesn't need editing every time someone changes jobs.
Adjust the risk acceptance row to match your organization's appetite. Many companies let business owners accept medium and low risks, but require leadership approval for critical findings or anything on an internet-facing system.
When one person holds several roles
In a small organization, the IT manager might run scans, patch servers and chair the change meeting. That's fine, as long as the roles stay distinct on paper.
Watch the conflicts in particular. The person who patched a system shouldn't be the only one verifying it, and the person who missed a deadline shouldn't approve their own exception. Where separation isn't possible, have a second person review those decisions.
How should escalation work?
Escalation should be routine and predictable, not personal. Agree on the triggers in advance so that raising an overdue finding is part of the process rather than an accusation.
A time-based path tied to your remediation deadlines works well:
| Trigger | Escalate to | Expected outcome |
|---|---|---|
| Finding reaches its due date without a fix or an approved plan | Remediation owner's manager | A committed fix date or a request for an exception |
| Finding is two weeks past due | Department head and business owner | Extra resources, reprioritized work or a formal risk decision |
| Critical internet-facing finding is overdue, or the same team is repeatedly late | Executive leadership | A resourcing decision or executive risk acceptance |
| Disagreement over priority or ownership | Leadership | A decision within an agreed number of days |
The exact timings are yours to set. What matters is that each step names a person, a trigger and the decision you expect from them.
Make each escalation easy to act on. Include the finding, the affected system, how long it's been open, what's blocking it and the options available. A leader who has to go find the context will usually ask for another week.
What about assets without a clear owner?
Every environment has them: an old server nobody remembers building, a test system left running, a cloud resource created by someone who has since left, or a device the scanner found that isn't in the inventory. Findings on these assets have nowhere to go.
Handle them with a defined process:
- Assign a default owner. Decide in advance that unowned assets belong to a specific team, often IT operations, until someone else claims them. The default owner is accountable for the findings in the meantime.
- Search for the real owner, with a time limit. Check inventory history, DNS records, cloud account tags, change records and the teams that use the network segment. Two weeks is a reasonable limit.
- Decide what happens if nobody claims it. With leadership approval, isolate the asset from the network, then decommission it after a notice period. If someone objects, they've just identified themselves as the owner.
- Require an owner at creation. Make an owner field mandatory in your inventory and when provisioning servers or cloud resources.
- Recertify ownership regularly. Ask owners to confirm their assets once or twice a year, and reassign assets when people leave or change roles.
Shared infrastructure, such as hypervisors, directory services or core network devices, needs a clear primary owner too. List the teams that depend on it as consulted, but give one team accountability for patching it.
Putting the model into practice
A RACI only helps if people know about it and agree to it. Write the roles into your vulnerability management policy or standard, get leadership to approve it and share it with every team that appears in the matrix.
Then test it against real work. Take a sample of recent findings and trace who handled each step. Where the actual path differs from the matrix, either the matrix is wrong or the process isn't being followed, and both are worth knowing. Review the roles at least once a year and whenever the organization changes shape.
Frequently asked questions
Should the security team patch systems itself?
Generally, no. Security teams usually lack the operational context and change authority to patch production safely, and a team that fixes its own findings can't verify them independently. There are exceptions, such as security tools the security team runs, but those should be listed explicitly.
Who should be allowed to accept vulnerability risk?
The owner of the business service or asset, within limits leadership sets. Security should document the risk and recommend an option, but it shouldn't be the approver. Every acceptance needs a reason, an approver and an expiry date.
How do we handle shared infrastructure with many dependent teams?
Give one team accountability for remediation, usually the team that operates the platform. The dependent teams are consulted on timing and testing. Without a single accountable owner, shared systems tend to wait for someone else to schedule the downtime.
We're a small team. Is a RACI overkill?
No, and it can be very short. Even if two people cover every role, writing down who approves exceptions and who verifies fixes prevents the most common conflicts. A one-page matrix is enough.
Next steps
- List the six roles and put a named team or person against each.
- Adapt the RACI table so every activity has exactly one accountable party.
- Set the thresholds for who can accept which level of risk.
- Agree on escalation triggers and publish them with your remediation deadlines.
- Name a default owner for unowned assets and start a time-boxed search for real owners.
- Make an owner field mandatory for new assets and schedule an ownership review.