Every vulnerability management program eventually hits the same wall: a critical finding sits unassigned for three weeks because nobody agreed, in writing, who closes it. The scanner did its job. The finding is confirmed. But “somebody should fix this” is not an assignment, and that ambiguity is the most common reason mean time to remediate looks fine on a dashboard while the actual finding quietly ages past a year in the ticket queue.
The recurring ownership dispute: finder vs fixer
Security teams find vulnerabilities. They rarely have shell access to fix them. IT operations and application teams hold the keys to patching, configuration changes, and code fixes, but they did not ask for the finding and often dispute its severity or its relevance to their system. That gap produces a predictable pattern: a ticket gets filed, the receiving team pushes back on scope or priority, the ticket sits in a queue with no clear owner, and thirty days later the same finding shows up on a different scan with a different ticket number.
The root cause is rarely bad faith. It is almost always that the asset owner field in the CMDB is stale, the scanning tool has no concept of organizational hierarchy, and nobody has written down, in a document people can actually find, who is accountable for a given class of finding on a given class of asset. A RACI (Responsible, Accountable, Consulted, Informed) matrix fixes this by naming roles, not people, against each stage of the vulnerability lifecycle, so the assignment logic survives staff turnover and does not depend on whoever answers Slack first.
Roles defined: security, IT operations, application teams, asset owner, risk, sponsor
Before building the matrix, define the roles precisely enough that two people reading the definition would assign the same finding to the same role. Vague titles like “the security team” or “engineering” produce vague matrices.
- Security / vulnerability management team: owns scanning cadence, validation of findings, severity scoring, and tracking against SLA. Does not typically execute the fix.
- IT operations: owns infrastructure patching, OS-level configuration, network device firmware, and third-party software updates on servers and endpoints it administers.
- Application / engineering teams: owns code-level vulnerabilities, dependency updates, and configuration changes inside applications they built or maintain, including anything surfaced through SAST, DAST, or software composition analysis.
- Asset owner: the named business function accountable for the asset existing at all. This role decides whether an asset gets decommissioned instead of patched, and signs off on downtime windows.
- Risk / GRC: owns the exception process, formal risk acceptance, and compliance mapping to frameworks such as ISO 27001 or PCI DSS control requirements. Risk does not fix vulnerabilities; it decides what happens when nobody can fix one on time.
- Executive sponsor: breaks ties between competing priorities, approves budget for remediation work that requires new tooling or headcount, and is the final escalation point before a finding becomes a board-level conversation.
A RACI matrix row per lifecycle stage
The matrix below maps each stage of the vulnerability lifecycle to the six roles above. Use R for Responsible (does the work), A for Accountable (owns the outcome and signs off), C for Consulted (input sought before action), and I for Informed (notified after the fact).
| Lifecycle stage | Security | IT Ops | App Team | Asset Owner | Risk/GRC | Sponsor |
|---|---|---|---|---|---|---|
| Discovery & scanning | R/A | I | I | I | – | – |
| Validation & triage | R/A | C | C | I | – | – |
| Risk scoring & prioritization | R | C | C | A | C | I |
| Assignment | R | I | I | A | – | – |
| Remediation execution | C | R/A (infra) | R/A (code) | C | – | – |
| Retest & closure | R/A | C | C | I | – | – |
| Exception / risk acceptance | C | I | I | C | R/A | C (over threshold) |
Two rows carry the most disputes in practice. Assignment fails when the asset owner field is empty or points to a distribution list nobody monitors, so accountability defaults back to security by omission. Remediation execution fails when a finding spans both infrastructure and code (a vulnerable library baked into a custom image, for example) and both IT ops and the app team assume the other is responsible; write a tie-breaker rule directly into the matrix, such as “the team that owns the deployment pipeline for that asset is Responsible.”
Retest is worth calling out separately because it is the stage most often skipped entirely. A ticket gets marked resolved based on the assignee’s own claim, or on a patch’s exit code, with no independent confirmation the vulnerability is actually gone. Platforms that automate this phase, such as SITEY, re-scan the specific finding against the original evidence rather than trusting a status field, which closes the loop on the “resolved but not verified” gap that RACI matrices alone cannot fix.
Who holds escalation authority and at what threshold
A matrix without escalation thresholds just tells you who missed the deadline; it does not tell you what happens next. Define numeric thresholds up front, tied to severity and to SLA breach count, not to subjective judgment calls made under deadline pressure.
- Critical (CVSS 9.0+ or CISA KEV-listed): 15-day SLA. First breach escalates from assignee to their direct manager automatically, no human decision required.
- High (CVSS 7.0-8.9): 30-day SLA. Escalates to manager on breach; escalates to the asset owner on a second consecutive missed SLA for the same finding.
- Medium (CVSS 4.0-6.9): 90-day SLA. Escalates to manager only after two breaches.
- Low (CVSS below 4.0): 180-day SLA, batched into a quarterly review rather than escalated individually.
Sponsor-level escalation should be rare by design: reserve it for any critical finding that breaches SLA twice, or for any exception request on a critical or high finding that exceeds 90 days. If the sponsor is being pulled in every week, the thresholds are set wrong, not the process.
Exception authority deserves its own rule, separate from ordinary escalation. Only Risk/GRC can grant a formal risk acceptance, and only with a documented compensating control and an expiration date, never an open-ended one. A common failure mode is letting IT ops or an app team “self-accept” risk by simply not acting on a ticket for six months; that is not an exception, it is an unmanaged gap, and the matrix should say so explicitly. Routing every exception request through a single approval gate instead of an email thread keeps a record of who approved what, and prevents the same finding from getting silently re-accepted every quarter by a different reviewer.
Writing ownership into policy so it survives reorganizations
A RACI matrix that lives in a slide deck from the last security offsite is dead within two reorgs. Write it into the vulnerability management policy itself, as a named section, with the roles tied to job functions rather than to individuals or even team names that might get renamed. “Infrastructure engineering (or its successor function)” survives an org chart change; “the Platform team” does not.
The policy section should include: the role definitions above, the matrix table, the SLA and escalation thresholds, the exception process, and a mandatory annual review date plus a trigger clause requiring re-review within 30 days of any reorganization that changes reporting lines for IT operations, application engineering, or security. Store it in the same policy management system used for other governance documents, version-controlled, with a changelog, not as a static PDF that nobody re-reads until an audit asks for it.
Tie the policy to the identity and access layer where possible. If your role-based access control already defines who can approve a production change or who owns a given asset group, reference those same role definitions in the RACI document instead of maintaining a second, parallel list that inevitably drifts out of sync with the first.
Copyable matrix and how to socialize it
Rolling out a new ownership model fails more often from lack of socialization than from a bad matrix. Present the table above (or your adapted version) to the actual role holders before it becomes policy, not after. Walk through three real recent findings that caused a dispute and show how the matrix would have resolved each one; abstract discussion about roles gets far less engagement than a concrete ticket everyone remembers arguing about.
Get written sign-off from a representative of each role, security, IT ops, app engineering, at least one asset owner, and risk/GRC, before publishing. Then embed the matrix into the tooling people actually use day to day: default assignee rules in the ticketing system, a required “asset owner” field on every new asset record, and an auto-escalation rule tied to the SLA thresholds rather than a manual reminder someone has to remember to send.
This is where automated assignment and workflow tooling earns its keep over a spreadsheet. A platform that reads asset ownership metadata and CVSS or exploitability signals at the same time, the way SITEY’s assignment phase does, routes a finding to the correct queue the moment it is validated rather than after a human has re-typed the same routing logic the matrix already specifies. The policy defines who; the tooling enforces it consistently, at 2 a.m., on the finding nobody was watching. Review the matrix itself every year regardless of whether reorgs happened, because scope creep, new asset classes, and new compliance obligations change what “ownership” needs to cover even when the org chart stays still.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.