Who Owns Patching? A RACI Model for Security and IT Ops

When a scan turns up a critical finding on a production host, the first real question is rarely “how do we fix this.” It is “whose job is it.” Security owns detection, scoring and risk context. IT operations owns the systems that need to be changed. Between the two, tickets sit unassigned, bounce between queues, or get closed by whoever had access that week without anyone confirming the fix actually worked. A RACI model, responsible, accountable, consulted, informed, does not patch anything by itself, but it removes the ambiguity that lets a triaged, prioritized finding sit open for months.

The classic standoff: security finds, IT patches, nobody closes

The pattern is familiar to anyone who has run a vulnerability management program past its first quarter. Security runs the scan, validates the finding, and assigns it a severity. The ticket lands in an IT operations queue, usually grouped by asset owner or team, and from there it competes with incident response, capacity work and unrelated change requests. IT patches what it can during the next maintenance window, closes the ticket in its own system, and security has no visibility into whether the underlying vulnerability is gone.

Three failure modes repeat across organizations of very different sizes:

• Ownership by default, not by design. A finding gets routed to whichever team’s name is on the asset in the CMDB, even when that team no longer manages the software stack that introduced the vulnerability.
• Closure without verification. A patch ticket is marked done when the change was deployed, not when the vulnerability was confirmed absent. Reboots get skipped, services fail to restart cleanly, or the wrong package version gets installed silently.
• No single accountable owner. When a finding spans a shared platform, for example a hypervisor host running VMs for three different application teams, everyone assumes someone else has already escalated it.

A RACI chart forces each of these ambiguities into a decision made once, in advance, rather than negotiated finding by finding under time pressure. Platforms that automate the discovery and triage phases, such as SITEY, still hand the actual remediation step to a human or a scripted action inside the customer’s own infrastructure, so the RACI assignment has to live somewhere the fix owner will actually see it, not just in a policy document nobody opens during an incident.

A RACI grid for OS, third-party apps, firmware, network gear and hosted VMs

Generic RACI templates fail for patching because “patch owner” means something different depending on the asset class. Firmware updates require physical or out-of-band access that application teams rarely have. Third-party desktop software is often centrally packaged but locally installed. Network gear changes carry outage risk that OS patches on a single web server do not. Build the grid at the asset-class level, not at the organization level, and keep it to one row per class so it fits on a single page people will actually reference.

Notice that security is Consulted in every row, never Responsible or Accountable, for the patch itself. Security’s job is to supply the risk context, exploit availability and business impact that inform prioritization; it should not be the team pushing package managers or rebooting hosts unless it also runs its own dedicated security tooling infrastructure. Keeping security out of the Accountable column is what prevents the “security owns the vulnerability, so security should fix it” argument that quietly turns a detection team into an unstaffed patching team.

Who approves downtime and who owns the rollback decision

Downtime approval and rollback authority are two separate decisions and should never share an owner by default, because the person who wants the patch applied urgently is rarely the best judge of when to back it out. Set both explicitly, tied to severity, before the first critical finding of the quarter shows up.

The SLA clock matters as much as the number. Starting it at discovery instead of at validation quietly inflates every metric, because raw scanner output includes duplicates and false positives that take time to rule out. Start the clock when a finding is confirmed exploitable and assigned an owner, not when the scan first flagged it.

For rollback, write the trigger condition down as a number, not a feeling. A workable default: roll back automatically if error rate on the affected service rises more than 5 percent above the pre-change baseline within 30 minutes, or if three consecutive health checks fail after the patch is applied. Anything vaguer than that gets argued about at 2 a.m. instead of executed.

Handoff rules that survive vacations and on-call rotations

RACI charts break down exactly when they are needed most: during a rotation change, a vacation, or an on-call handoff mid-incident. Three rules close most of the gap.

• Every open patch ticket has a named individual, not just a team. “Network engineering” is not an owner; “network engineering, assigned to J. Alvarez, backup R. Chen” is. If the named owner is out, the backup is contacted directly, not the team’s shared queue.
• Auto-escalation on silence, not on request. If a critical finding’s owner has not acknowledged the ticket within a fixed window, commonly 4 hours during business hours or 1 hour for KEV-listed vulnerabilities, escalate automatically to the Accountable role in the RACI grid. Waiting for someone to notice the ticket is stale defeats the purpose of having an SLA.
• On-call calendars and ticketing assignment stay in sync. A patch ticket assigned to whoever was on-call last Tuesday, after the rotation has moved on, is functionally unassigned. Sync the on-call schedule (PagerDuty, Opsgenie, or an internal rotation tool) with the ticketing system so reassignment happens automatically when the rotation changes, not manually when someone remembers.

These rules matter more for firmware and network gear than for OS patching, because the pool of people with the access and vendor knowledge to execute those changes is usually smaller, sometimes a single person per region. Document a named backup for every asset class where the primary owner is effectively a single point of failure, and test the handoff at least once before you need it in a real incident.

Making ownership visible in the ticket, not just the org chart

A RACI document that lives in a wiki page nobody opens during an incident is a RACI document in name only. Ownership needs to be visible inside the actual ticket the engineer is looking at, at the moment they are looking at it. Concretely, every patch ticket should carry these fields, populated automatically wherever possible rather than typed in by hand:

• Responsible owner (named individual) and backup
• Accountable manager, auto-populated from the asset class mapping
• SLA due date, computed from validation timestamp plus the severity-based target, not from ticket creation date
• Link to the original finding and its evidence, so nobody has to re-derive why the ticket exists
• Retest status: open, patched-pending-verification, or closed-verified

That last field is the one most homegrown processes skip, and it is the one that causes the most silent recurrence. A ticket marked “patched” based on a deployment log is not the same claim as “patched and confirmed absent on rescan.” Closing the loop requires re-running the specific check that found the issue against the specific asset, not a general sweep next quarter. This is the mechanism where automated platforms earn their keep: a tool that stores the RACI assignment as a structured field on the vulnerability record, tracks the SLA clock against validation time rather than discovery time, and blocks closure until a targeted retest confirms remediation removes an entire category of “we thought this was fixed” incidents. SITEY’s approach ties each finding’s remediation plan to a named owner and a required retest before the record is allowed to close, which keeps the ticket itself, not a separate spreadsheet, as the source of truth for who did what and whether it worked.

Whatever tooling sits underneath, the underlying discipline is the same: assign ownership by asset class in advance, separate downtime approval from rollback authority, name a backup for every single point of failure, and never let a ticket close on a deployment log alone. Get those four things right and the standoff between security and IT operations mostly disappears, not because the two teams start agreeing on everything, but because there is nothing left to argue about when the finding shows up.

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.