Your security team's growing backlog is not their fault
When every vulnerability alert lands on the security team's desk, the result is not accountability. It is a queue that never shrinks. A clearer split of duties is the only fix.
Key points
- Most organisations wrongly assign both the discovery and the fixing of security weaknesses to the same small security team, creating a backlog that grows faster than it can be cleared.
- The U.S. National Institute of Standards and Technology (NIST) explicitly describes patching, which means applying software updates to fix known weaknesses, as routine business maintenance, not a specialist security task.
- CISA, the U.S. Cybersecurity and Infrastructure Security Agency, publishes a free Known Exploited Vulnerabilities Catalog that helps organisations decide which weaknesses to fix first based on real-world criminal activity.
- Stricter deadlines alone cannot shrink a backlog when the teams responsible still lack the time or authority to do the work.
- Executives, not security staff, must make the final call when a fix clashes with a product launch or a budget limit.
Picture a hospital maintenance team expected to inspect every fire door, replace the hinges, repaint the frames, and then chase ward managers to sign off the paperwork. Their inspection log would grow forever, and they'd be blamed for a problem that was never really theirs to solve.
That is precisely how most organisations run cybersecurity today.
Who actually owns the problem?
Security teams should own the list of risks and set the priorities. They should not own the act of fixing things. That distinction, straightforward on paper, is ignored constantly in practice.
When a scanning tool, software that automatically checks systems for known weaknesses, flags an outdated piece of software, the security team is expected to patch the server. If a cloud platform, meaning an organisation's rented computing infrastructure hosted online, flags an open storage bucket exposing company data, security gets called in to redesign the setup. An audit finding that too many staff can access a sensitive business system somehow becomes security's job to negotiate with the relevant department.
None of those things is a security job. Each is an operational job that security spotted.
CSO Online made a related point recently: patching deadlines, known in the industry as SLAs or service-level agreements, should be the floor of a strategy, not the strategy itself. Green compliance numbers can hide the small handful of genuinely dangerous risks that matter most.
Why stricter deadlines make it worse
Tightening the deadline changes nothing about capacity. Telling an engineering team that critical vulnerabilities must be fixed within 15 days doesn't give that team an extra 15 days of spare time. The servers still need maintaining. Friday's product release doesn't move.
A backlog is a record of unanswered management decisions: who owns this system, who can approve the change, what else gets delayed if this jumps the queue. When leadership doesn't answer those questions, the finding simply ages on the dashboard, and the security team gets blamed for a list they can read but cannot clear.
How should the work actually be split?
The model recommended by NIST's Cybersecurity Framework 2.0 and its enterprise patch management guidance is straightforward.
| Role | Responsibility |
|---|---|
| Security team | Risk inventory, prioritisation, escalation, closure verification |
| Infrastructure teams | Patching servers, endpoints, and network devices |
| Cloud platform teams | Fixing identity, storage, and logging controls |
| Application teams | Updating code dependencies, redesigning vulnerable features |
| Business system owners | Approving workflow and access changes |
| Executives | Resolving conflicts between remediation and business priorities |
For prioritisation, CISA recommends using its Known Exploited Vulnerabilities Catalog as a primary input. A medium-severity flaw that criminals are actively exploiting in the wild is more urgent than a critical-rated flaw sitting on an isolated test machine no one outside the building can reach. Our 6 August story "Patched Doesn't Mean Safe" found that fewer than one in three organisations check whether a fix actually stopped an attacker, which means even a well-divided workload can leave real exposure unclosed.
What should ordinary employees watch for?
If your organisation is telling a small IT security group to both find and fix every weakness, raise it. Staff who own systems or approve access requests are part of the fix chain whether or not they hold a security title.
When a security team flags a risk in your area, ask your manager directly: who has the authority to get this fixed, and do they know about it yet?
